We now have a new website dedicated to the RIT Honeynet Project.
http://honeynet.rit.edu
We will be posting the honeynet updates there, as well as data once we go live. Stay tuned for more updates!
Tuesday, March 31, 2009
Monday, March 30, 2009
Using MD5 with new PHPbb
MD5 is one of today’s biggest security weaknesses. So why would anyone ever want to use it or worse migrate away from a stronger scheme to it? The answer to these questions is the ever looming interoperability. Even though SPARSA is a security group we also face these challenges and while writing code to allow for Blowfish interfacing with all these programs might be more secure it would also be much more time consuming.
As a result we here at SPARSA are completing an endeavor to migrate all our usernames systems ( Drupal, Linux, PHPbb3, Gallery2…etc ) to a single username and password scenario. The problem we face is that we have significant presence already established via PHPbb. As such we would want to use our PHPbb database and group structures to propagate all the databases and passwd files.
In order to do this in the easiest way and the way that currently allows for the most expansion is to revert PHPbb3's PHPass library usage and replace it with MD5 that was featured in PHPbb2.
The PHPass library creates hash's based on a structure similar to MD5 but with pseudo-random salt values.
The reason we decided against this course of action is because PHPBB’s next incarnation will probably not accept MD5 at all or will certainly discourage its use. Instead we decided to pursue a course of action that would make a new column in the PHPbb database explicitly for MD5 Passwords for security reasons the naming of this database should be something that hides its true purpose and an additional hash function should be placed over it making it difficult for anyone who might break into your database to break your MD5 passwords.
It is at this time less than feasible to reverse each hash and then re-encrypt into MD5 for the other databases although that would be optimum this is of course the exact opposite of the purpose of the hash and this is action is of questionable ethics. An additional concern is we do not want any users to experience lockout time or have to reset their password.
This problem turns out to be a relatively easy fix, almost too easy and would prove an interesting local attack against PHPbb by an attacker to gain passwords even if they were encrypted in those most sophisticated encryption.
There is only one file that one needs to edit.
phpbb3/includes/auth/auth_db.php – Where success and plain text password are handeled.
add these lines right before
// Successful login... set user_login_attempts to zero...
Add in the lines
$password_new = md5( $password );
$sql = "UPDATE " . USERS_TABLE . "
SET column_name = '$password_new'
WHERE user_id = " . $row['user_id'];
$db->sql_query($sql);
Thursday, January 29, 2009
ImagineRIT here we come!
As of January 23, 2009 SPARSA has officially submitted a proposal to ImagineRIT. ImagineRIT is RIT's innovation fair where clubs gather and display different projects to the public. This year SPARSA has proposed to build an automated security test system that will generate security reports for individuals at the event. This system uses off the shelf hardware and software which is combined in an innovative way. It starts off by having a Prism based cards with HostAP drivers in a computer. The card will sniff the network for wireless probe packets, and once it receives a probe it will change the Access Point name to fit that request. Additionally, there will also be a wireless access point offered for users who have no preferred network saved and desire to have the tests performed. Upon connecting to the network the user will be treated to a captive portal which will present them terms allowing for network scanning. If the user rejects the terms they will be redirected to normal RIT internet; However if they accept the terms they will be asked to create a password. The password will be a key to their report if they choose to visit the booth. Once the user is in the network they will be given an IP address and be able to surf the internet freely. While they are surfing, our servers will scan their computers for common vulnerabilities. A report will then be generated and secured pending arrival of the user to our both. From that report anonymous security statistics will be generated and be displayed on a screen. When the user arrives they will be given access to a terminal that they are able to enter their computer name and the password on. They will be given a summery of their current security weaknesses and how to fix them, along with the option to print them for future use. The project although developing only some code will itself make the RIT campus safer and hopefully be an interesting insight into the world of security for those who would not normally be privy to it.
Saturday, January 17, 2009
RIT Honeynet Project
The RIT Honeynet Project has finally taken off. We were approved by the department heads a while back, and have been waiting for them to obtain the hardware for us. We now have an assortment of hardware to play with including about 12 machines, a KVM, a switch and a hub. We also have a rack and cooling. This is currently set up in projects lab but may shift depending on space concerns. When we have time, we will start configuring the honeynet systems and playing with Honeywall (https://projects.honeynet.org/honeywall/). Future updates about the honeynet project will be posted here once it has been configured.
Tuesday, November 4, 2008
RIT Honeynet Project
Good news. The proposal sent in for the RIT Honeynet Project was accepted today. A small group of students, including myself, have been planning out the project for about a month now, and the NSSA Department has agreed to supply us with the materials we requested. We will post more information regarding our project on this blog, as well as post a link to our RIT Honeynet webpage once it is created.
Wednesday, October 22, 2008
Nmap tarpits
There are two main types of Nmap scans: those which simply check whether ports are open (TCP SYN / RST scanning), and those which try to do fingerprint analysis of each service (connect completely, wait for response, check response against known responses). The following is a technique which makes both of these attacks much more difficult.
Typically, an Nmap scan will scan the low-numbered privileged ports such as ports 1-1023, since these are where most services will listen for connections. Common services an attacker might hope to find include FTP (21), SSH (22), SMTP (25), and HTTP (80), all within this range. Because of this, our tarpit script will focus on this range.
The approach is simple - open all otherwise unused ports and do nothing with them. This has two consequences: a simple scan will identify all ports as open and render no useful information, while a fingerprinting scan will wait for each port in the range to respond until max timeout (since our listening program will never reply). This means that scans will either return unless information or the scan will be slowed dramatically (those configured with a low timeout per port), which can also sometimes cause inaccurate results. While this will not stop serious attackers, it will stave off any wide-area scans of your network or anyone with only an elementary knowledge of network security.
Here is a simple implementation in Perl:
This script must be run as root to access the privileged ports. It should also be noted that while this script is active, no new services can be started in the privileged port range. This tends not to be an issue with already-configured servers as services aren't usually changed, but stopping the script while a new service is added is trivial.
A more advanced script could also detect when a single IP connects several times on different ports (this is safe because no legitimate user will connect to any of the ports listened to by the script) and add that IP to a systemwide blacklist or software firewall deny list.
If an attacker decides to DDoS the script, it will begin using memory to store the unread messages. If this is a concern, you could have the script occasionally read from the sockets and discard the data or simply restart the script occasionally.
Typically, an Nmap scan will scan the low-numbered privileged ports such as ports 1-1023, since these are where most services will listen for connections. Common services an attacker might hope to find include FTP (21), SSH (22), SMTP (25), and HTTP (80), all within this range. Because of this, our tarpit script will focus on this range.
The approach is simple - open all otherwise unused ports and do nothing with them. This has two consequences: a simple scan will identify all ports as open and render no useful information, while a fingerprinting scan will wait for each port in the range to respond until max timeout (since our listening program will never reply). This means that scans will either return unless information or the scan will be slowed dramatically (those configured with a low timeout per port), which can also sometimes cause inaccurate results. While this will not stop serious attackers, it will stave off any wide-area scans of your network or anyone with only an elementary knowledge of network security.
Here is a simple implementation in Perl:
#!/usr/bin/perl -w
use strict;
use IO::Socket;
my @port = ();
for (1..1023) {
$port[$_] = IO::Socket::INET->new(
Proto => 'tcp',
LocalPort => $_,
Listen => SOMAXCONN,
Reuse => 1);
next if $! =~ /already in use/i;
}
sleep 10 while 1;
This script must be run as root to access the privileged ports. It should also be noted that while this script is active, no new services can be started in the privileged port range. This tends not to be an issue with already-configured servers as services aren't usually changed, but stopping the script while a new service is added is trivial.
A more advanced script could also detect when a single IP connects several times on different ports (this is safe because no legitimate user will connect to any of the ports listened to by the script) and add that IP to a systemwide blacklist or software firewall deny list.
If an attacker decides to DDoS the script, it will begin using memory to store the unread messages. If this is a concern, you could have the script occasionally read from the sockets and discard the data or simply restart the script occasionally.
Tuesday, October 21, 2008
Unpacking UPX
This was a presentation I gave at a SPARSA meeting. It's just a basic overview of how packers work and how one might go about unpacking a packed executable.
A packer is a compression tool (in this example used for PE files) for binary files. Other types of compression could be: Zip, rar, tar, bzip, gzip, etc. When UPX compresses the PE file, it has to know how to decompress it once the program is run. This version of UPX (http://upx.sourceforge.net/#download) uses a decompression loop that is inserted during compression. Once the binary executes the decompression loop, it is unpacked in to memory. If we wish to obtain the original unpacked binary, we just have to dump the process from memory..sounds easy enough. Why would we want to obtain the unpacked executable? If we weren't sure of the packer, or it wasn't UPX (which you can decompress using the command "upx -d") we would be unable to understand the disassembled code in your favorite disassembler.
To start, I'll show the PEiD (http://www.peid.info/) output of winmine.exe to show it isn't packed. PEiD works much like antivirus products do. It uses a signature database to find byte-matching patterns within the file.
To pack the executable, we simply run the UPX command on the command line.
We can still run the new executable, winmine_packed.exe, from the command line because it simply decompresses the binary file in to memory. To show that the file was successfully packed, we can throw the new executable back in to PEiD.
Ok, now for the fun part. We have to open the packed executable in a debugger. For this presentation I used OllyDBG (http://www.ollydbg.de/download.htm). OllyDBG will complain that the file is compressed but we already know this. Once we get in to OllyDBG, the first comamnd we see is PUSHAD. This command pushes all the registers on to the stack. This way they can be decompressed in to memory. The call we are looking for is POPAD, which would make sense because it pops the registers back off the stack after the decompression loop.
If you scroll down in Olly, you should find POPAD near the bottom of the loop.
You can see at the end of the loop the program compares the ESP (stack pointer) with the EAX register. If it is not decompressed, it jumps back to the the PUSH 0 call. If however, the decompression loop is complete, it uses a JMP command. This is exactly what we're looking for. If we follow this jump, we will find our original entry point in the program (OEP). The original entry point is where the unpacked binary starts. We will start by placing a breakpoint on the final JMP call. This way, once we start the program, it will hault on that call. You can set a breakpoint in OllyDBG by pressing F2 on the JMP call.
You then would start the program execution either by clicking the Play button in Olly, or by pressing F9. It should hit the breakpoint you set and hault execution. Now, the JMP should lead us back to the OEP. To move one step in Olly, rather than execution the remaining code, you can press F7 (step into). You should now be at the oep and olly should display something like this:
Now that we have gone through the decompression loop, our binary is unpacked in memory. The next step is to dump the process from memory. To do this, I used a tool called LordPE (http://www.woodmann.net/collaborative/tools/index.php/LordPE). Open up LordPE and select the winmine_packed.exe process that is running through OllyDBG. Right click the process, and select "Dump Full".
I would suggest naming it something that you will remember such as winmine_dumped.exe. Now that the program has been dumped from memory, lets try to run it.
As you may have thought, the fun is not over yet. Once the dumped program is executed, you are confronted with an error saying it was unable to initialize properly. When a process is dumped from memory, this can mess up the import table. A PE file's import table is used to know which files it needs to dynamically link to when mapping in to memory (DLLs). So how do we fix this? We use another program I used in this presentation called ImportREC (http://vault.reversers.org/ImpRECDef). Again, select winmine_packed.exe from the process list. The program should finish loading the process, and give you an Image Base. Lets go back to our Olly window that's still open, and get the address of our OEP.
As seen earlier, our address of the OEP is 01003E21. Back in ImportREC, we need to set the OEP in the IAT Info section. If our image base is already 01000000, then our OEP would be at 0003E21 (Image base plus + OEP = relative location in memory). We then click the IAT AutoSearch button in ImportRec:
You should see a good looking message stating that it found an address which may be in the original IAT. If we follow the instructions in the dialog box, we would click Get Imports at the bottom of ImportREC.
ImportREC should look something like the screenshot above. It has successfully found imports for winmine_packed.exe. We then click Fix Dump, and select our previously dumped winmine file (winmine_dumped.exe). ImportREC will then save the file as winmine_dumped_.exe. Let's throw that file back in to PEiD to see if it's still packed:
We are back to where we started, and the dumped binary is able to run successfully.
A packer is a compression tool (in this example used for PE files) for binary files. Other types of compression could be: Zip, rar, tar, bzip, gzip, etc. When UPX compresses the PE file, it has to know how to decompress it once the program is run. This version of UPX (http://upx.sourceforge.net/#download) uses a decompression loop that is inserted during compression. Once the binary executes the decompression loop, it is unpacked in to memory. If we wish to obtain the original unpacked binary, we just have to dump the process from memory..sounds easy enough. Why would we want to obtain the unpacked executable? If we weren't sure of the packer, or it wasn't UPX (which you can decompress using the command "upx -d") we would be unable to understand the disassembled code in your favorite disassembler.
To start, I'll show the PEiD (http://www.peid.info/) output of winmine.exe to show it isn't packed. PEiD works much like antivirus products do. It uses a signature database to find byte-matching patterns within the file.
To pack the executable, we simply run the UPX command on the command line.
We can still run the new executable, winmine_packed.exe, from the command line because it simply decompresses the binary file in to memory. To show that the file was successfully packed, we can throw the new executable back in to PEiD.
Ok, now for the fun part. We have to open the packed executable in a debugger. For this presentation I used OllyDBG (http://www.ollydbg.de/download.htm). OllyDBG will complain that the file is compressed but we already know this. Once we get in to OllyDBG, the first comamnd we see is PUSHAD. This command pushes all the registers on to the stack. This way they can be decompressed in to memory. The call we are looking for is POPAD, which would make sense because it pops the registers back off the stack after the decompression loop.
If you scroll down in Olly, you should find POPAD near the bottom of the loop.
You can see at the end of the loop the program compares the ESP (stack pointer) with the EAX register. If it is not decompressed, it jumps back to the the PUSH 0 call. If however, the decompression loop is complete, it uses a JMP command. This is exactly what we're looking for. If we follow this jump, we will find our original entry point in the program (OEP). The original entry point is where the unpacked binary starts. We will start by placing a breakpoint on the final JMP call. This way, once we start the program, it will hault on that call. You can set a breakpoint in OllyDBG by pressing F2 on the JMP call.
You then would start the program execution either by clicking the Play button in Olly, or by pressing F9. It should hit the breakpoint you set and hault execution. Now, the JMP should lead us back to the OEP. To move one step in Olly, rather than execution the remaining code, you can press F7 (step into). You should now be at the oep and olly should display something like this:
Now that we have gone through the decompression loop, our binary is unpacked in memory. The next step is to dump the process from memory. To do this, I used a tool called LordPE (http://www.woodmann.net/collaborative/tools/index.php/LordPE). Open up LordPE and select the winmine_packed.exe process that is running through OllyDBG. Right click the process, and select "Dump Full".
I would suggest naming it something that you will remember such as winmine_dumped.exe. Now that the program has been dumped from memory, lets try to run it.
As you may have thought, the fun is not over yet. Once the dumped program is executed, you are confronted with an error saying it was unable to initialize properly. When a process is dumped from memory, this can mess up the import table. A PE file's import table is used to know which files it needs to dynamically link to when mapping in to memory (DLLs). So how do we fix this? We use another program I used in this presentation called ImportREC (http://vault.reversers.org/ImpRECDef). Again, select winmine_packed.exe from the process list. The program should finish loading the process, and give you an Image Base. Lets go back to our Olly window that's still open, and get the address of our OEP.
As seen earlier, our address of the OEP is 01003E21. Back in ImportREC, we need to set the OEP in the IAT Info section. If our image base is already 01000000, then our OEP would be at 0003E21 (Image base plus + OEP = relative location in memory). We then click the IAT AutoSearch button in ImportRec:
You should see a good looking message stating that it found an address which may be in the original IAT. If we follow the instructions in the dialog box, we would click Get Imports at the bottom of ImportREC.
ImportREC should look something like the screenshot above. It has successfully found imports for winmine_packed.exe. We then click Fix Dump, and select our previously dumped winmine file (winmine_dumped.exe). ImportREC will then save the file as winmine_dumped_.exe. Let's throw that file back in to PEiD to see if it's still packed:
We are back to where we started, and the dumped binary is able to run successfully.
Subscribe to:
Comments (Atom)