Oddly enough, the face of Network and Data Security may be changing, and rather grotesquely. Because DNA works in much the same way as machine language, researches have been copying software hackers for methods of reverse engineering genetic code. Probably the most frightening aspect is that virus fabrication costs as little as $20,000 for a complete setup. The code for viruses can be found all over the internet, and run through a DNA synthesizer. Because of the basic nature of a virus, it is the equivalent of a script. It does not need to be compiled, and can even be self executing.
The synthesizer works by printing enzymes for the viral protein onto an organic media, much like a inkjet printer squirts ink onto a sheet of paper. Once the code is completed, the virus actually pulls together into a living organism.
Thanks to advancements in computing technology, and a little hacker know-how, there are high school programs popping up world wide which allow students to do just this.
This video shows a
conference on hacking biology.
I believe that a field of information and data security in the future will include bioinformatics.
Showing posts with label hacking. Show all posts
Showing posts with label hacking. Show all posts
Sunday, March 9, 2008
Wednesday, February 6, 2008
Hacking WPA
DISCLAIMER: Yes, this will show you how to hack into a wireless network. This is very much ILLEGAL. The purpose of this writeup is for educational purposes only. I am demonstrating the weakness of WPA encryption on my own network. If you wish to try this for yourself, I suggest you buy a wireless router and attempt to crack that.
_____________________________________________________________________
Okay, so I'm not going to back track (forgive the pun) through the previous tutorial. If you aren't certain how to get to where I'm beginning this tutorial at, scroll down and read hacking WEP. It will fill you in on everything except putting your card into monitor mode and such.
So, first you will need to start up airodump-ng and capture packets from the AP. This time, however, do not add the --ivs, as you will want ALL the data in the packets. Look in the upper right corner of the window, just after the date and time. You will notice that the area is black and empty. This is where the four-way WPA handshake will show up when you have attained it. I will explain that in more detail later.
I will assume that you are now collecting packets in monitor mode. Packets by themselves are completely useless for cracking WPA. What we are interested in is the four-way handshake. To get this, we will use aireplay-ng to perform a deauth (de-authentication) attack, disconnecting the client from the AP, and forcing it to reconnect... also giving away the four-way handshake.
To do this, type in aireplay-ng -0 1 -a (AP MAC) -c (Client MAC) (your NIC)
Mine was aireplay-ng -0 1 -a 00:40:05:26:B3:C0 -c 00:16:CF:0B:0D:FD eth2
Now you should see a handshake appear in the window containing your running (you did leave it running, right?) airodump-ng program:
Now we need to get the key. Just as in the WEP cracking tutorial, I am going to make you do some of your own leg work. You will need to find a dictionary word list. You can also make your own, and add the pass phrase to the list. This screenshot shows an example of the list I made in a few seconds to show you the next steps:
Okay okay, you got me. This was done in Windows XP. I forgot to take a screenshot of the list in BackTrack 3b, and was too lazy to go back and do it again. You'll just have to pretend its all black and fancy and cool looking like the BackTrack GUI is.
Alright, so you have your dictionary list ready to run with aircrack-ng. Type in aircrack-ng -w (dictionary.lst/txt) -b (AP MAC) (dumpfile.cap)
Mine has aircrack-ng -w crack.txt -b 00:40:05:26:B3:C0 psk-02.cap
Now, if it finds the correct pass phrase in the dictionary list, you will be presented with the word:
Okay, so what did we learn here? Well, WPA-psk is more secure than WEP in that you must run a dictionary attack against it, and stronger passwords will require a rainbow table (don't worry, I may go into that in another blog). So it is theoretically more secure than WEP.
However, the pass phrase is only as secure as you make it. In this case, I set mine up to be very simple to facilitate this demonstration. However, using real words greatly diminishes the effectiveness of WPA, and it is highly suggested that you use special characters, upper case, lower case, and numbers in your passwords.
The second weakness in WPA-psk, is the reliance on the four-way handshake, in which the key is transmitted. It takes only a moment to run a deauth attack to force a handshake and grab the key.
Finally, WPA has the advantage of requiring a client to be connected before an attempt to crack can occur. Where WEP can be coaxed into transmitting packets, and therefore give the attacker IVs, WPA cracking needs that handshake with the pass phrase before any further progress can be made.
So WPA is far from perfect, but it can foil someone who is unprepared to run a dictionary attack, or with an unsuitable dictionary list.
TO BE CONTINUE
_____________________________________________________________________
Okay, so I'm not going to back track (forgive the pun) through the previous tutorial. If you aren't certain how to get to where I'm beginning this tutorial at, scroll down and read hacking WEP. It will fill you in on everything except putting your card into monitor mode and such.
So, first you will need to start up airodump-ng and capture packets from the AP. This time, however, do not add the --ivs, as you will want ALL the data in the packets. Look in the upper right corner of the window, just after the date and time. You will notice that the area is black and empty. This is where the four-way WPA handshake will show up when you have attained it. I will explain that in more detail later.
I will assume that you are now collecting packets in monitor mode. Packets by themselves are completely useless for cracking WPA. What we are interested in is the four-way handshake. To get this, we will use aireplay-ng to perform a deauth (de-authentication) attack, disconnecting the client from the AP, and forcing it to reconnect... also giving away the four-way handshake.
To do this, type in aireplay-ng -0 1 -a (AP MAC) -c (Client MAC) (your NIC)
Mine was aireplay-ng -0 1 -a 00:40:05:26:B3:C0 -c 00:16:CF:0B:0D:FD eth2
Now you should see a handshake appear in the window containing your running (you did leave it running, right?) airodump-ng program:
Now we need to get the key. Just as in the WEP cracking tutorial, I am going to make you do some of your own leg work. You will need to find a dictionary word list. You can also make your own, and add the pass phrase to the list. This screenshot shows an example of the list I made in a few seconds to show you the next steps:
Okay okay, you got me. This was done in Windows XP. I forgot to take a screenshot of the list in BackTrack 3b, and was too lazy to go back and do it again. You'll just have to pretend its all black and fancy and cool looking like the BackTrack GUI is.
Alright, so you have your dictionary list ready to run with aircrack-ng. Type in aircrack-ng -w (dictionary.lst/txt) -b (AP MAC) (dumpfile.cap)
Mine has aircrack-ng -w crack.txt -b 00:40:05:26:B3:C0 psk-02.cap
Now, if it finds the correct pass phrase in the dictionary list, you will be presented with the word:
Okay, so what did we learn here? Well, WPA-psk is more secure than WEP in that you must run a dictionary attack against it, and stronger passwords will require a rainbow table (don't worry, I may go into that in another blog). So it is theoretically more secure than WEP.
However, the pass phrase is only as secure as you make it. In this case, I set mine up to be very simple to facilitate this demonstration. However, using real words greatly diminishes the effectiveness of WPA, and it is highly suggested that you use special characters, upper case, lower case, and numbers in your passwords.
The second weakness in WPA-psk, is the reliance on the four-way handshake, in which the key is transmitted. It takes only a moment to run a deauth attack to force a handshake and grab the key.
Finally, WPA has the advantage of requiring a client to be connected before an attempt to crack can occur. Where WEP can be coaxed into transmitting packets, and therefore give the attacker IVs, WPA cracking needs that handshake with the pass phrase before any further progress can be made.
So WPA is far from perfect, but it can foil someone who is unprepared to run a dictionary attack, or with an unsuitable dictionary list.
TO BE CONTINUE
Wednesday, January 23, 2008
New Methods of Hacking
This is where I will be talking about the new generation of hacking and theories.
Password Profiling
Okay, so everyone knows that the current brand of password cracking involves one of three different methods. One is a dictionary attack using real words from a dictionary list. Another is a brute force attack that systematically tries every possible number, letter, and character combination over a large amount of time. The third is to use a rainbow table.
What if there was an easier method to discover someone's password, that doesn't use random generation, but profiling? That is, a program that can scan a person's personal folders and files and look for patterns.
It looks as though the Wyd Password Profiler will do just that. By looking for patterns in the targets behavior or personality, the program is able to construct viable passwords.
As an example: Tom loves baseball. He has pictures of his favorite team, scores, screen savers, etc stored on his system. It is logical, therefore, that his password will contain something about this sports team, or one of the players. By knowing this information, the attacker can focus on that attack vector, instead of running a dictionary attack list that may only contain the word baseball (which would not be sufficient).
The purpose of this type of attack is not to build an extensive list to attack the victim with, but is instead used to take out false positives, and narrow down the possible passwords significantly.
Rogue Access Point Attack
Remember Microsoft Windows' ability to automatically connect you to your favorite networks? Well, that may not be the best feature Microsoft has thought up. By exploiting a bug in the wireless manager, an attacker can sniff out your favored networks, and change the SSID of their rogue network to match it. Windows will automatically connect you to that network, without alerting you. At this point, they are free to start scanning your computer, transmit malware, or or use a program like wireshark to capture your packets.
More information on this attack can be found here.
However, there is a potential defense against this, which uses the same program used to disconnect the victim from a good network (void11) and uses a matchlist that you generate to automatically refuse connections. However, it is limited to prism cards, and requires a bit of technical knowledge. You can find information on it here.
Password Profiling
Okay, so everyone knows that the current brand of password cracking involves one of three different methods. One is a dictionary attack using real words from a dictionary list. Another is a brute force attack that systematically tries every possible number, letter, and character combination over a large amount of time. The third is to use a rainbow table.
What if there was an easier method to discover someone's password, that doesn't use random generation, but profiling? That is, a program that can scan a person's personal folders and files and look for patterns.
It looks as though the Wyd Password Profiler will do just that. By looking for patterns in the targets behavior or personality, the program is able to construct viable passwords.
As an example: Tom loves baseball. He has pictures of his favorite team, scores, screen savers, etc stored on his system. It is logical, therefore, that his password will contain something about this sports team, or one of the players. By knowing this information, the attacker can focus on that attack vector, instead of running a dictionary attack list that may only contain the word baseball (which would not be sufficient).
The purpose of this type of attack is not to build an extensive list to attack the victim with, but is instead used to take out false positives, and narrow down the possible passwords significantly.
Rogue Access Point Attack
Remember Microsoft Windows' ability to automatically connect you to your favorite networks? Well, that may not be the best feature Microsoft has thought up. By exploiting a bug in the wireless manager, an attacker can sniff out your favored networks, and change the SSID of their rogue network to match it. Windows will automatically connect you to that network, without alerting you. At this point, they are free to start scanning your computer, transmit malware, or or use a program like wireshark to capture your packets.
More information on this attack can be found here.
However, there is a potential defense against this, which uses the same program used to disconnect the victim from a good network (void11) and uses a matchlist that you generate to automatically refuse connections. However, it is limited to prism cards, and requires a bit of technical knowledge. You can find information on it here.
BackTrack
DISCLAIMER: Yes, this will show you how to hack into a wireless network. This is very much ILLEGAL. The purpose of this writeup is for educational purposes only. I am demonstrating the weakness of WEP encryption on my own network. If you wish to try this for yourself, I suggest you buy a wireless router and attempt to crack that.
_____________________________________________________________________
I wanted to post a live instructional movie instead of a set of pictures. However, I am still attempting to get my wireless card working in a virtual environment and/or an open source video capturing utility that runs in Back Track 3.
I could list the set of programs I will be using here, but they are listed throughout the blog. I believe it is better to say that I am using Back Track 3 (beta) using a live install and a Linksys WMP11 wireless NIC. You can find details on downloading and installing Back Track 2 and 3 here.
Alright, there are a few things I'm leaving off the beginning. The first is setting your wireless card to monitor mode. I had a little trouble with this at first. I have to extend a thank you to Brian for pointing me in the right direction.
Another is the list of compatible wireless cards. You can find those circulating around the net (at the ubuntu website, the aircrack site, and a few others). I am also leaving off driver installation. Some wireless cards require madwifi drivers to work. You can find out more about this via the Madwifi webpage.
It is actually very easy to set your wireless NIC to monitor mode in Back Track 3. Play around with some of the programs, and if you are still having trouble, try the Remote Exploit Forums.
Okay, so you have your card in monitor mode (or you're just curious and want to read on). The first step is to make certain that your card is in fact running in monitor mode. To do this, open the terminal and type iwconfig Look for your wireless card. The window should be displaying as such:
Notice the second line in eth2? It says "Mode:Monitor." This confirms that the wireless card is set to monitor.
Now, you can do one of two things. The first is run a wireless sniffing program, that will allow you to see hidden SSID's. I will not be demonstrating that in this tutorial. Instead, we will use a program called airodump to capture the packets and create a file that we can use in a cracking program. There are several options you can set when using Airodump.
This may seem overwhelming at first, but its easy to figure out. The options we are interested in right now are: --ivs, -w, and -channel 6.
This is because I already know the target is using channel 6, and don't need to scan any other channels. --ivs will store only captured ivs. Ivs are initialization vectors that preamble the key. There are 16.7 million varieties, which may sound like a lot. However, they are only 3 bytes in size, and so even a weak computer can run an algorithm that checks for patterns and eventually breaks the wep key. For our purposes, we only need to record these. Finally, the -w or write option will write the stored information to a .cap file that we can use at a later time.
So we type in the command airodump-ng -w --ivs -channel 6 eth2
\
Alright. Now airodump is running and pulling ivs out of packets. How long does this need to run for? It varies depending on the type of encryption and complexity of the code. In this case, it is a 64 bit hex code using WEP encryption. I'll let it run for 20 minutes, but I could probably do it in as few as 5 if I'm lucky.
Notice that there is a second wireless AP that popped up? Airodump will capture all available information on any selected channel, or even scan every channel within the range specified.
Now that the 20 minutes is up, we can press ctrl+c to stop the dump and exit back to the konsole. The -w command now creates a capture file with all the information we need.
We can see the name of the capture file is ivs-01.cap. Now, in the konsole, type aircrack-ng --help.
This brings up the aircrack options. Aircrack is the program we will use to crack the encryption and discover the code.
We really don't need any of the special options at this point. So simply type aircrack-ng ivs-01.cap. We are now presented with an option. Remember that other AP that came up when airodump was running? It saves all of this information in the file. If there were 10 ap's during the airodump process, there would be 10 ap's to choose from now. We are only interested in the first, which is airwave (the SSID of my router). So we type 1 and press enter.
Congradulations! There is the key to my wireless network. It took about .5 seconds to produce, though it is a very weak key with the worst possible encryption. I will look into cracking 128 bit WEP, and possibly WPA in the future.
_____________________________________________________________________
I wanted to post a live instructional movie instead of a set of pictures. However, I am still attempting to get my wireless card working in a virtual environment and/or an open source video capturing utility that runs in Back Track 3.
I could list the set of programs I will be using here, but they are listed throughout the blog. I believe it is better to say that I am using Back Track 3 (beta) using a live install and a Linksys WMP11 wireless NIC. You can find details on downloading and installing Back Track 2 and 3 here.
Alright, there are a few things I'm leaving off the beginning. The first is setting your wireless card to monitor mode. I had a little trouble with this at first. I have to extend a thank you to Brian for pointing me in the right direction.
Another is the list of compatible wireless cards. You can find those circulating around the net (at the ubuntu website, the aircrack site, and a few others). I am also leaving off driver installation. Some wireless cards require madwifi drivers to work. You can find out more about this via the Madwifi webpage.
It is actually very easy to set your wireless NIC to monitor mode in Back Track 3. Play around with some of the programs, and if you are still having trouble, try the Remote Exploit Forums.
Okay, so you have your card in monitor mode (or you're just curious and want to read on). The first step is to make certain that your card is in fact running in monitor mode. To do this, open the terminal and type iwconfig Look for your wireless card. The window should be displaying as such:
Notice the second line in eth2? It says "Mode:Monitor." This confirms that the wireless card is set to monitor.
Now, you can do one of two things. The first is run a wireless sniffing program, that will allow you to see hidden SSID's. I will not be demonstrating that in this tutorial. Instead, we will use a program called airodump to capture the packets and create a file that we can use in a cracking program. There are several options you can set when using Airodump.
This may seem overwhelming at first, but its easy to figure out. The options we are interested in right now are: --ivs, -w, and -channel 6.
This is because I already know the target is using channel 6, and don't need to scan any other channels. --ivs will store only captured ivs. Ivs are initialization vectors that preamble the key. There are 16.7 million varieties, which may sound like a lot. However, they are only 3 bytes in size, and so even a weak computer can run an algorithm that checks for patterns and eventually breaks the wep key. For our purposes, we only need to record these. Finally, the -w or write option will write the stored information to a .cap file that we can use at a later time.
So we type in the command airodump-ng -w --ivs -channel 6 eth2
\Alright. Now airodump is running and pulling ivs out of packets. How long does this need to run for? It varies depending on the type of encryption and complexity of the code. In this case, it is a 64 bit hex code using WEP encryption. I'll let it run for 20 minutes, but I could probably do it in as few as 5 if I'm lucky.
Notice that there is a second wireless AP that popped up? Airodump will capture all available information on any selected channel, or even scan every channel within the range specified.
Now that the 20 minutes is up, we can press ctrl+c to stop the dump and exit back to the konsole. The -w command now creates a capture file with all the information we need.
We can see the name of the capture file is ivs-01.cap. Now, in the konsole, type aircrack-ng --help.
This brings up the aircrack options. Aircrack is the program we will use to crack the encryption and discover the code.
We really don't need any of the special options at this point. So simply type aircrack-ng ivs-01.cap. We are now presented with an option. Remember that other AP that came up when airodump was running? It saves all of this information in the file. If there were 10 ap's during the airodump process, there would be 10 ap's to choose from now. We are only interested in the first, which is airwave (the SSID of my router). So we type 1 and press enter.
Congradulations! There is the key to my wireless network. It took about .5 seconds to produce, though it is a very weak key with the worst possible encryption. I will look into cracking 128 bit WEP, and possibly WPA in the future.
Friday, January 18, 2008
Watching a hack attempt from the other side
Alright, I'm going to bounce back to hacking for a moment. I currently run an FTP server for friends and classwork. I am using filezilla, an opensource FTP server program available from http://filezilla-project.org/.
After installing a new router, I had let it sit idle. I recently wished to share some pictures with a friend, and so I opened the ports. As soon as I did so, someone started using a dictionary attack against it.
So I contemplated a few things. I needed to keep my server available, of course, but these attacks would eat up system resources, and though my passwords are secure, its impossible to say what the complexity of their program is.
I already have a timeout scheme set (5 seconds between failed attempts) but I decided to go one step further. I implemented a ban system. After 10 failed attempts in a single hour, they would be banned for an hour.
I could also have instituted an permanent ban. However, this would hamper availability too much. People forget their passwords.
So the result looks like this:
I also have some important information in the log files. One is the time of the attacks, the other is the IP address of the attacker. Notice that, despite there are multiple IPs, they are all in the same block. First, I wanted to know exactly where the attacks were originating. To do this, I used a simple website called the Community Geotarget IP Project. I entered the attacker's IP address into the whois, and was able to discover the country of origin, but little else:
So, I have the country of origin, Thailand, but I want to know more. So I decided to visit another IPWHOIS site. This one is DNS Stuff. A quick IP search was much more revealing:
This has revealed that the IP is owned by the Ministry of Education. It has contact information, probably for a network administrator and the head of the Ministry of Education.
At this point, its up to my discretion whether I wish to notify the Network Administrator, or go on about my business. If this was a major network, I would need to employ a large staff just to handle these situations, and so I would not pursue any action unless the attack was successful.
Let me step back for a moment and speak of the security implications.
As previously stated, my FTP server had been online, but the port was blocked, so nobody could actually "see" my server.
Two days ago, I opened the ports so that a friend could download from the server. In those two days, I counted at least 5 attacks. I can't be sure of exactly how many yet, because I have not checked the recorded log, only the displayed log:
How could so many attacks start from such remote places without any knowledge that my server even exists? Well, my first assumption is a port scanner. That is, a program that scans IP's, and checks to see if it gets any response from specific ports. In this case, it would scan for port 21, which is reserved for FTP programs. I decided to do a google search and see if I could turn up a program that does this.
My very first search turned up this.
So the software is very easy to find and install, and is not complicated to use. We can safely assume that the attacker is using this method to find my server. And if the process is that simple, how can I step up my security? I will be researching methods for this. However, I believe that if I push integrity too hard, I will lose too much availability.
Log File
Okay, so I've gone back and reviewed my log files. The main log file is over 8 megabytes now of pure, single line text. I pulled some of the IP's, but this is not nearly a comprehensive list:
217.204.34.34
75.94.180.204
202.143.182.204
80.229.40.186
134.39.100.71
222.211.79.106
209.252.98.185
222.200.161.12
61.135.142.220
86.105.40.246
61.129.52.230
This is about 20% of the total IP's that are in the log file. Each one has at least 30 failed attempts to brute force past the login prompt.
From this I've learned a couple things.
1. Log files suck. It's not too much fun to dig through thousands of log entries to find information, and further more, most of the information is rather useless. Do I need to know that I was attacked, unsuccessfully, 50 times by the same IP? Probably. But do I need a new log entry for each attack by the same IP address? No, I don't. Not in this format, anyway. A program that sorts and organizes this information using drop down menus or some such would be very nice.
2. Security is pretty important. If I had an administrator account with a weak password, all the information on the FTP server would be compromised.
3. Trying to balance Availability, Integrity, and Confidentiality is more difficult than it seems.
I am looking into a new hosting format that functions like FTP, but uses a web interface and works on port 80 instead of 21. This will increase availability, while hopefully increasing security as well. Port sniffing for port 80 is a pretty big waste of time. The program can be found at the HFS website.
I will post another blog when I have more information, or have decided on a course of action for the server.
After installing a new router, I had let it sit idle. I recently wished to share some pictures with a friend, and so I opened the ports. As soon as I did so, someone started using a dictionary attack against it.
So I contemplated a few things. I needed to keep my server available, of course, but these attacks would eat up system resources, and though my passwords are secure, its impossible to say what the complexity of their program is.
I already have a timeout scheme set (5 seconds between failed attempts) but I decided to go one step further. I implemented a ban system. After 10 failed attempts in a single hour, they would be banned for an hour.
I could also have instituted an permanent ban. However, this would hamper availability too much. People forget their passwords.
So the result looks like this:
I also have some important information in the log files. One is the time of the attacks, the other is the IP address of the attacker. Notice that, despite there are multiple IPs, they are all in the same block. First, I wanted to know exactly where the attacks were originating. To do this, I used a simple website called the Community Geotarget IP Project. I entered the attacker's IP address into the whois, and was able to discover the country of origin, but little else:
So, I have the country of origin, Thailand, but I want to know more. So I decided to visit another IPWHOIS site. This one is DNS Stuff. A quick IP search was much more revealing:
This has revealed that the IP is owned by the Ministry of Education. It has contact information, probably for a network administrator and the head of the Ministry of Education.
At this point, its up to my discretion whether I wish to notify the Network Administrator, or go on about my business. If this was a major network, I would need to employ a large staff just to handle these situations, and so I would not pursue any action unless the attack was successful.
Let me step back for a moment and speak of the security implications.
As previously stated, my FTP server had been online, but the port was blocked, so nobody could actually "see" my server.
Two days ago, I opened the ports so that a friend could download from the server. In those two days, I counted at least 5 attacks. I can't be sure of exactly how many yet, because I have not checked the recorded log, only the displayed log:
How could so many attacks start from such remote places without any knowledge that my server even exists? Well, my first assumption is a port scanner. That is, a program that scans IP's, and checks to see if it gets any response from specific ports. In this case, it would scan for port 21, which is reserved for FTP programs. I decided to do a google search and see if I could turn up a program that does this.
My very first search turned up this.
So the software is very easy to find and install, and is not complicated to use. We can safely assume that the attacker is using this method to find my server. And if the process is that simple, how can I step up my security? I will be researching methods for this. However, I believe that if I push integrity too hard, I will lose too much availability.
Log File
Okay, so I've gone back and reviewed my log files. The main log file is over 8 megabytes now of pure, single line text. I pulled some of the IP's, but this is not nearly a comprehensive list:
217.204.34.34
75.94.180.204
202.143.182.204
80.229.40.186
134.39.100.71
222.211.79.106
209.252.98.185
222.200.161.12
61.135.142.220
86.105.40.246
61.129.52.230
This is about 20% of the total IP's that are in the log file. Each one has at least 30 failed attempts to brute force past the login prompt.
From this I've learned a couple things.
1. Log files suck. It's not too much fun to dig through thousands of log entries to find information, and further more, most of the information is rather useless. Do I need to know that I was attacked, unsuccessfully, 50 times by the same IP? Probably. But do I need a new log entry for each attack by the same IP address? No, I don't. Not in this format, anyway. A program that sorts and organizes this information using drop down menus or some such would be very nice.
2. Security is pretty important. If I had an administrator account with a weak password, all the information on the FTP server would be compromised.
3. Trying to balance Availability, Integrity, and Confidentiality is more difficult than it seems.
I am looking into a new hosting format that functions like FTP, but uses a web interface and works on port 80 instead of 21. This will increase availability, while hopefully increasing security as well. Port sniffing for port 80 is a pretty big waste of time. The program can be found at the HFS website.
I will post another blog when I have more information, or have decided on a course of action for the server.
Sunday, January 13, 2008
Hacking x2
Now that I've established a little information on hacking and hackers, I'll update with some information that shows the procedures of hacking, and the dangers of being hacked. Once again, I will use publicly available material as references.
Injections
Not the kind that that was developed to rip off your insurance company, but the type that alters database and scripting code to allow admittance to otherwise locked sites. This is one of the more simple hacks, and requires surprisingly little skill. It does require that the target system lack necessary security and sanitation code. However, because many admins and webhosts are rather lazy, these hacks have remained useful for quite some time.
SQL Injection
A SQL (pronounced "sequel") Injection relies on the very basic database programming msSQL or mySQL to implement. Note that SQL is not the only language used for databases, but is quite common. It uses plain English (or country of choice) commands, such as "Select fieldlist from table ... etc etc"
These commands are entered from exposed fields on the internet. If you have ever seen a page that asks for your user name and password, for example, you are possibly looking at a SQL form. When you enter your user name and password, the database compares it to a field of user names, and then the password associated with the typed user name. If they match, you are allowed access. If not, you are given an error message.
Think of it as an excel spreadsheet. Each row corresponds to a certain type of data. So row one might be your user name, row two your password, and row three your email. When you type your user name, it finds that unique user name, and then checks to see if the password you entered is the same. If it returns true, you are allowed access.
Because SQL cannot interpret by itself if a benign user name and password was entered, or if another, malicious SQL command was given, it simply carries out the orders as it was designed to.
So an attacker will first begin by establishing these things:
1. Is this a SQL Database? If yes, skip to 2. If no, Skip to end
2. What is the field name for "username"
3. What is the field name for "password"
4. What is the field name for "email"
To establish if the target uses a SQL database, the attacker will feed it a short SQL snippet. Remember that a SQL database will understand any SQL commands, even if it can't run them or they produce an error. What is typed into the login field is not important, after all, passwords are used as the universal key, user names are merely a reference point. In the password field, a command such as x' or '1'='1 will be typed.
In any SQL database, when a comparison is called between two fields, if they match a value of true will be returned. Because "or" automatically interrupts the search, 1=1 is tacked onto the end of the resulting search. The password is most definately not "x" but before the database returns false, it reads the "or" statement and the subsequent "1=1." This statement, is of course, true. Because the database is looking for a true answer, not a false, it pushes the "true" value.
Now, you might think it silly to have the database "look" for a true answer instead of being stoic and neutral. However, you must think about a query in conventional terms. Say you are going to the grocery store to buy a gallon of milk. When you ask a sales clerk where the milk is, you do not say "where is the milk not?" He would have to take you to every part of the store the milk is not at before you could determine where the milk is. Instead, you ask "where is the milk?" Now he will take you to the precise location the milk is kept. Keep in mind that there is not a single jug with "milk" stenciled into it, but all forms of milk. He cannot tell you where the 2% milk is unless you ask him specifically.
The initial discovery of the milk would result in a return of "true." You can, of course, refine your search if possible, but the point remains.
Now, using this analogy, imagine you went into Sears and said "Where is the milk or drills?" The clerk would tell you that there is no milk, but he will not then tell you to go away. The "or" statement will inspire him to take you to the drills. There was no milk, but the query for drills returned true.
So, if the attacker initiates an injection such as x' or '1'='1, the database must respond. To do this, the attacker can use the "mail me my password" feature. Though there are other ways to do this, it must be a method that will return some sort of value. Remember that the attacker will be unable to see the actually SQL code.
Let us say that the return was "We have sent you an email with your password in it." This will tell the attacker that they have found a SQL database, and what's more, it is not "sanitized." That is, there is nothing checking the code before it is executed to ensure that an attack is not occurring. Keep in mind that this is executing code in the database, so someone was just sent an email with steps to recover their password. Just as no systems can keep hackers out, no hackers can crack undetected. There is always a log, some trace to tell they were or are working.
Okay, so the attacker knows this is a SQL database with little or no security. Now they need to build an image of what the database looks like in their mind. Though it is better to use a pen and paper or open a text document. Each field has a unique name. The password list, for example, may be password, passwrd, pword, secret, etc. Each field that must be exploited by the attack must be named. There is no easy way to do this, but almost all databases use the same basic words to denote the field. This is again attributed to the laziness of the designers or admins.
To begin this, the attacker will change the code slightly. Now it will look more like x' AND password IS NULL; --
AND is substituted for OR, because we don't want it to return true. This is especially true when working with the email field. The attacker doesn't want 10 change of password emails going out to all 10,000 people in the database. If an error such as "missing syntax" is returned, its the wrong field name. However, if the attacker gets a response such as "no match found" then they know it is the correct field name. The three most important fields for the attacker to acquire are "logon/user name, password, and email. Other fields can be found this way, but they really serve no purpose. Once the attacker has access to all the resources by hacking into the system, they can acquire the same information in a fraction of the time.
Now that the attacker has figured out the correct field names, they are ready to move on to gaining full access. To do this, they must either guess a password, or use a much easier method of overriding an existing user and changing their password with a SQL injection.
Note that the attacker may have access to one SQL database, but it may not be the database that stores login credentials. To verify this, first the table name must be acquired. The code for this is x' AND 1=(SELECT COUNT(*) FROM tabname); --. Note that the attacker must guess the table's name, however, as usual the names are generally obvious. Members, users, etc. The command x' AND tabname.email IS NULL; -- wil l verify that this is in fact the table that is being actively used for login credentials.
After all this is settled, the attacker will need a valid login. Remember that this information is readily available. Many sites set the user name to match the account name. On a forum, for example, the name you login with is the name that is displayed when you post in threads. Also some variation will be used for the real name of the webmaster or contact listed on the website.
Using that user name and the command:
x';
UPDATE listname
SET email = 'victim's@email.com'
WHERE email = 'youremail@email.com
The attacker injects the command to change the table, deleting the original email and substituting it with theirs.
Now the attacker simply initiates the "reset my password" function, and it sends the password reset link to their email.
They now have full administrator privileges to the system, or the credentials of another user which they can cause havoc with. At their victim's expense, of course.
A written source for this can be found here
Here are some video's of the attacks in action:
So...
Consider this a warning! Don't be lazy. Nobody can guess a password field named "Iowatachata" ... okay, so you aren't likely to tell your boss that you changed all the SQL fields to random sesame street characters. You can, however, sanitize the input so that only characters which are allowed for passwords can be entered into the database. The characters =, ;, and ' should never be valid characters for passwords or user names. Ensure that they will be rejected.
There are many more steps to securing a SQL database. However, as with all security operations, the methods of securing a system is far harder than the methods used to break the security.
Injections
Not the kind that that was developed to rip off your insurance company, but the type that alters database and scripting code to allow admittance to otherwise locked sites. This is one of the more simple hacks, and requires surprisingly little skill. It does require that the target system lack necessary security and sanitation code. However, because many admins and webhosts are rather lazy, these hacks have remained useful for quite some time.
SQL Injection
A SQL (pronounced "sequel") Injection relies on the very basic database programming msSQL or mySQL to implement. Note that SQL is not the only language used for databases, but is quite common. It uses plain English (or country of choice) commands, such as "Select fieldlist from table ... etc etc"
These commands are entered from exposed fields on the internet. If you have ever seen a page that asks for your user name and password, for example, you are possibly looking at a SQL form. When you enter your user name and password, the database compares it to a field of user names, and then the password associated with the typed user name. If they match, you are allowed access. If not, you are given an error message.
Think of it as an excel spreadsheet. Each row corresponds to a certain type of data. So row one might be your user name, row two your password, and row three your email. When you type your user name, it finds that unique user name, and then checks to see if the password you entered is the same. If it returns true, you are allowed access.
Because SQL cannot interpret by itself if a benign user name and password was entered, or if another, malicious SQL command was given, it simply carries out the orders as it was designed to.
So an attacker will first begin by establishing these things:
1. Is this a SQL Database? If yes, skip to 2. If no, Skip to end
2. What is the field name for "username"
3. What is the field name for "password"
4. What is the field name for "email"
To establish if the target uses a SQL database, the attacker will feed it a short SQL snippet. Remember that a SQL database will understand any SQL commands, even if it can't run them or they produce an error. What is typed into the login field is not important, after all, passwords are used as the universal key, user names are merely a reference point. In the password field, a command such as x' or '1'='1 will be typed.
In any SQL database, when a comparison is called between two fields, if they match a value of true will be returned. Because "or" automatically interrupts the search, 1=1 is tacked onto the end of the resulting search. The password is most definately not "x" but before the database returns false, it reads the "or" statement and the subsequent "1=1." This statement, is of course, true. Because the database is looking for a true answer, not a false, it pushes the "true" value.
Now, you might think it silly to have the database "look" for a true answer instead of being stoic and neutral. However, you must think about a query in conventional terms. Say you are going to the grocery store to buy a gallon of milk. When you ask a sales clerk where the milk is, you do not say "where is the milk not?" He would have to take you to every part of the store the milk is not at before you could determine where the milk is. Instead, you ask "where is the milk?" Now he will take you to the precise location the milk is kept. Keep in mind that there is not a single jug with "milk" stenciled into it, but all forms of milk. He cannot tell you where the 2% milk is unless you ask him specifically.
The initial discovery of the milk would result in a return of "true." You can, of course, refine your search if possible, but the point remains.
Now, using this analogy, imagine you went into Sears and said "Where is the milk or drills?" The clerk would tell you that there is no milk, but he will not then tell you to go away. The "or" statement will inspire him to take you to the drills. There was no milk, but the query for drills returned true.
So, if the attacker initiates an injection such as x' or '1'='1, the database must respond. To do this, the attacker can use the "mail me my password" feature. Though there are other ways to do this, it must be a method that will return some sort of value. Remember that the attacker will be unable to see the actually SQL code.
Let us say that the return was "We have sent you an email with your password in it." This will tell the attacker that they have found a SQL database, and what's more, it is not "sanitized." That is, there is nothing checking the code before it is executed to ensure that an attack is not occurring. Keep in mind that this is executing code in the database, so someone was just sent an email with steps to recover their password. Just as no systems can keep hackers out, no hackers can crack undetected. There is always a log, some trace to tell they were or are working.
Okay, so the attacker knows this is a SQL database with little or no security. Now they need to build an image of what the database looks like in their mind. Though it is better to use a pen and paper or open a text document. Each field has a unique name. The password list, for example, may be password, passwrd, pword, secret, etc. Each field that must be exploited by the attack must be named. There is no easy way to do this, but almost all databases use the same basic words to denote the field. This is again attributed to the laziness of the designers or admins.
To begin this, the attacker will change the code slightly. Now it will look more like x' AND password IS NULL; --
AND is substituted for OR, because we don't want it to return true. This is especially true when working with the email field. The attacker doesn't want 10 change of password emails going out to all 10,000 people in the database. If an error such as "missing syntax" is returned, its the wrong field name. However, if the attacker gets a response such as "no match found" then they know it is the correct field name. The three most important fields for the attacker to acquire are "logon/user name, password, and email. Other fields can be found this way, but they really serve no purpose. Once the attacker has access to all the resources by hacking into the system, they can acquire the same information in a fraction of the time.
Now that the attacker has figured out the correct field names, they are ready to move on to gaining full access. To do this, they must either guess a password, or use a much easier method of overriding an existing user and changing their password with a SQL injection.
Note that the attacker may have access to one SQL database, but it may not be the database that stores login credentials. To verify this, first the table name must be acquired. The code for this is x' AND 1=(SELECT COUNT(*) FROM tabname); --. Note that the attacker must guess the table's name, however, as usual the names are generally obvious. Members, users, etc. The command x' AND tabname.email IS NULL; -- wil l verify that this is in fact the table that is being actively used for login credentials.
After all this is settled, the attacker will need a valid login. Remember that this information is readily available. Many sites set the user name to match the account name. On a forum, for example, the name you login with is the name that is displayed when you post in threads. Also some variation will be used for the real name of the webmaster or contact listed on the website.
Using that user name and the command:
x';
UPDATE listname
SET email = 'victim's@email.com'
WHERE email = 'youremail@email.com
The attacker injects the command to change the table, deleting the original email and substituting it with theirs.
Now the attacker simply initiates the "reset my password" function, and it sends the password reset link to their email.
They now have full administrator privileges to the system, or the credentials of another user which they can cause havoc with. At their victim's expense, of course.
A written source for this can be found here
Here are some video's of the attacks in action:
So...
Consider this a warning! Don't be lazy. Nobody can guess a password field named "Iowatachata" ... okay, so you aren't likely to tell your boss that you changed all the SQL fields to random sesame street characters. You can, however, sanitize the input so that only characters which are allowed for passwords can be entered into the database. The characters =, ;, and ' should never be valid characters for passwords or user names. Ensure that they will be rejected.
There are many more steps to securing a SQL database. However, as with all security operations, the methods of securing a system is far harder than the methods used to break the security.
Subscribe to:
Posts (Atom)