Tuesday, February 26, 2013
Ruby Rox!
I'm having fun learning Ruby these days, hope to have some more stuff up soon. Maybe some horrible advice on coding in Ruby, maybe some more sploits. Promise to bring some interesting fun back soon.....stay tuned!
Thursday, November 29, 2012
Hacking Cold Fusion Servers - Part II
Now I will go over two more additional vulnerabilities which can be potentially leveraged to attack Cold Fusion Servers. This time we will be looking at exploiting a weak uploader as well as another LFD/LFI vulnerability but with small twist. If you didn't catch the first part then I encourage you to read that thread before reading this one as it makes for better attack flow in general this way. Assuming your all set, let's begin....
Now one thing to be aware of is that Cold Fusion packed an FCKEditor in with v8 when it was first released and they didn't due proper checking on the upload types. If you give it a file as .txt but write to .cfm or .jsp it thinks this is ok! This exploit will take some coding abilities on your behalf or the ability to use Metasploit as it has a nice pre-built exploit for this one (Java Meterpreter works best for payload). You basically shoot and point with MSF and hope for the best. If the uploader is present it will try to send a multi-part upload request via POST. If successful you should be able to find a shell in '/userfiles/file/' directory of the site. Now I have coded my own script for this and tried with Metasploit but have not successfully exploited this myself so not going to post my code just yet, would like to confirm it first. You have MSF as a crutch for now, can find the module by referencing CVE-2009-2265, or just type 'use exploit/windows/http/coldfusion_fckeditor'; I will update this section when I have confirmation of working code on my part.....
OK, so in addition to the previously shown LFD/LFI to RCE vulneranility we demonstrated in part I of this series, there is another LFD/LFI vulnerability. This time it is XML External Entities (XEE) Injection in the Data Services which allows a wide range of XML based attacks, including Local File Disclosure, TCP scans and Denial of Service condition, which can be achieved by recursive entity injection, attribute blow up and other types of injection. For more information about the implications associated to this vulnerability, refer to the RFC2518 (17.7 Implications of XML External Entities): http://www.ietf.org/rfc/rfc2518.txt. I will show you how we can exploit this to map out the target server and read files. Basically we send a carefully crafted XML request to the Data Service file handler and if it is vulnerable to XEE Injection it will spit back the results we ask for. Here are some common files to check:
Now the cool thing here is that it works regardless of OS, since it is due to how the Data Services are handling and parsing the XML data being passed, just make sure you request the proper file type for designated system type (check server response if you have no idea)...
Also in addition to reading files, you can simply pass a directory and it will spit back the directory content, making it very easy to map things out and find files worth reading. Now limited privileges may restrict some file reading but still plenty enough to cause trouble, enumerate lots of info, and possibly even read the site configuration details...
In addition to these named exploits in this Cold Fusion series, the same old usual suspects are still fair game here. SQL injection vulnerabilities just as common as on PHP or ASP based sites, and 'cfincludes' can enable source disclosures. In many cases the db can be compromised and Java commands maybe leveraged to further extend the potential attack vectors and escalation platform from that of a standard injection so keep your eyes out and don’t be afraid to take on a new site just cause it has .CFM or .JSP files instead of the oh so popular .PHP or .ASP. Hope you enjoyed this short series on hacking Cold Fusion Servers. All material for the series was available on the net in various places, all I did was wrap it up for you and try to make it a little easier to understand. If you have any questions or suggestions please post em here or let me know via PM.
Until next time, Enjoy!
foo
bar
Now one thing to be aware of is that Cold Fusion packed an FCKEditor in with v8 when it was first released and they didn't due proper checking on the upload types. If you give it a file as .txt but write to .cfm or .jsp it thinks this is ok! This exploit will take some coding abilities on your behalf or the ability to use Metasploit as it has a nice pre-built exploit for this one (Java Meterpreter works best for payload). You basically shoot and point with MSF and hope for the best. If the uploader is present it will try to send a multi-part upload request via POST. If successful you should be able to find a shell in '/userfiles/file/' directory of the site. Now I have coded my own script for this and tried with Metasploit but have not successfully exploited this myself so not going to post my code just yet, would like to confirm it first. You have MSF as a crutch for now, can find the module by referencing CVE-2009-2265, or just type 'use exploit/windows/http/coldfusion_fckeditor'; I will update this section when I have confirmation of working code on my part.....
OK, so in addition to the previously shown LFD/LFI to RCE vulneranility we demonstrated in part I of this series, there is another LFD/LFI vulnerability. This time it is XML External Entities (XEE) Injection in the Data Services which allows a wide range of XML based attacks, including Local File Disclosure, TCP scans and Denial of Service condition, which can be achieved by recursive entity injection, attribute blow up and other types of injection. For more information about the implications associated to this vulnerability, refer to the RFC2518 (17.7 Implications of XML External Entities): http://www.ietf.org/rfc/rfc2518.txt. I will show you how we can exploit this to map out the target server and read files. Basically we send a carefully crafted XML request to the Data Service file handler and if it is vulnerable to XEE Injection it will spit back the results we ask for. Here are some common files to check:
- /flex2gateway/
- /flex2gateway/http
- /flex2gateway/httpsecure
- /flex2gateway/cfamfpolling
- /flex2gateway/amf
- /flex2gateway/amfpolling
- /messagebroker/http
- /messagebroker/httpsecure
- /blazeds/messagebroker/http
- /blazeds/messagebroker/httpsecure
- /samples/messagebroker/http
- /samples/messagebroker/httpsecure
- /lcds/messagebroker/http
- /lcds/messagebroker/httpsecure
- /lcds-samples/messagebroker/http
- /lcds-samples/messagebroker/httpsecure
"<?xml version="1.0" encoding="utf-8"?><!DOCTYPE test [ <!ENTITY x3 SYSTEM "<INSERT_PATH/FILE_HERE>"> ]><amfx ver="3" xmlns="http://www.macromedia.com/2005/amfx"><body><object type="flex.messaging.messages.CommandMessage"><traits><string>body</string><string>clientId</string><string>correlationId</string><string>destination</string><string>headers</string><string>messageId</string><string>operation</string><string>timestamp</string><string>timeToLive</string></traits><object><traits /></object><null /><string /><string /><object><traits><string>DSId</string><string>DSMessagingVersion</string></traits><string>nil</string><int>1</int></object><string>&x3;</string><int>5</int><int>0</int><int>0</int></object></body></amfx>"Simply replace '<INSERT_PATH/FILE_HERE>' with the path to read an let the requests rip, like so:
Now the cool thing here is that it works regardless of OS, since it is due to how the Data Services are handling and parsing the XML data being passed, just make sure you request the proper file type for designated system type (check server response if you have no idea)...
Also in addition to reading files, you can simply pass a directory and it will spit back the directory content, making it very easy to map things out and find files worth reading. Now limited privileges may restrict some file reading but still plenty enough to cause trouble, enumerate lots of info, and possibly even read the site configuration details...
In addition to these named exploits in this Cold Fusion series, the same old usual suspects are still fair game here. SQL injection vulnerabilities just as common as on PHP or ASP based sites, and 'cfincludes' can enable source disclosures. In many cases the db can be compromised and Java commands maybe leveraged to further extend the potential attack vectors and escalation platform from that of a standard injection so keep your eyes out and don’t be afraid to take on a new site just cause it has .CFM or .JSP files instead of the oh so popular .PHP or .ASP. Hope you enjoyed this short series on hacking Cold Fusion Servers. All material for the series was available on the net in various places, all I did was wrap it up for you and try to make it a little easier to understand. If you have any questions or suggestions please post em here or let me know via PM.
Until next time, Enjoy!
foo
bar
Hacking Cold Fusion Servers - Part I
Today I will go over part I of a few tricks we can use to attack Cold Fusion Servers of various versions using a few published methods. Cold Fusion is an Adobe product targeted at Enterprise and Small Business owners. Probably most commonly known for and associated with CFML or Cold Fusion Markup Language, most visually associated with .cfm files on web servers. CF platforms are built on a Java core and as such it also has some built in features which also allow command execution and database interaction. The following should present you with a few methods you can use to check for common vulnerabilities on these platforms, as well as how to exploit them. Most of these were published ages ago in 2010 but there are still many sites which are either running versions which are un-patchable or just simply running unpatched software still....
I will start this series off with the most common vulnerability first, which is the known Local File Disclosure, or LFI, in the 'locale' parameter (also referenced under: CVE-2010-2861). The LFI vulnerability allows us to read files off of the target system, without any authentication. The neat thing that makes this one different than most LFD is that if we play our cards right we can use this vulnerability as a foothold to further penetrate our target, read and see. We first try to find the admin page, as it is the most commonly vulnerable page, but certainly not the only one. You can typically find it at one of the following locations:
Knowing the version is important as it helps us to determine the appropriate path to use to try and turn this LFD into something useful. Now if you know the full path to the CF '.properties' file then you're in business as it contains the CF admin password hashes. The list of possible paths worth trying are as follows:
NOTE: In version 6 & 7 encryption is not enabled by default, although i never seen a server which did not encrypt the password in hash form.
Now you can crack the password hash and login with clear text pass or we can use a little trick to bypass authentication requirements by using a pass-the-hash technique. The login form uses a bit of JavaScript magic to actually create a HMAC hash from the admin password hash and a salt value which is changed every 30 seconds. You can find this salt value by simply viewing the source code for login page, look at second occurrence of the term 'salt' or review form input details. Due to this, we pass the hash and generate the HMAC hash on our own and submit - simulating a successful login! You need to grab the salt from source:
OK, so you now have Password hash and salt in hand....
Here is some code I whipped up to accomplish this task of logging in real quick for you to get the authenticated cookie.
Quickly enter the needed details and run it. If successful, you will have the authenticated cookie presented to you in terminal, like so:
Now once you have the authenticated cookie, you're pretty much in. You can use your favorite cookie editor to load up the new 'CFAUTHORIZATION_cfadmin=<SOMEVALUEHEREONSUCCESS>'. Once loaded you simply refresh your browser and your now logged into the administrative panel for Cold Fusion. Now to try and get a shell up on the server....
If you already know the server path to web facing directory then you can move forward, if not you can check the 'Mappings' link on the left under 'Server Settings'. This will show a mapping of all paths for CF, by default the /CFIDE dir should be mapped giving us a usable path in the majority of cases. Mappings page looks like this:
Once path is known we will move to the 'Schedule Tasks' page located under 'Debugging & Logging' on left menu links.
Now you simply point the task scheduler at your remote CFM/JSP shell hosted on a server you control, stored in txt format like an RFI attack payload. You can schedule for a onetime event, it will default to current time so no need to calculate things if your on different time zone :) If you need a username/password to access the remote shell file source then provide as needed in appropriate fields of task scheduler. The next is key, mark the option to 'Publish" to true so it saves the results to a file (i.e. grab our remote shell source, and save to executable). You then provide it with the full path to where you want to write to. In the majority of cases /CFIDE is writable, otherwise poke around or generate errors in SQL queries on site to get path (standard Full Path Disclosure rules still apply here). When you form is all setup you can submit to create the scheduled task.
You will need to click on the green check-mark icon to run the scheduled task, which actually executes it and grabs our shell. If it has problems with remote file you will likely get a warning message of some kind in admin panel, edit and retry. Upon success, you can point your browser at the path you uploaded your shell to. In most cases Cold Fusion is running on Windows system with full NT AUTHORITY/SYSTEM privileges which means you pretty much own the local box now :)
If you find that 'cfexecute' is disabled and blocking your CFM shell from working properly, you can simply re-enable it from the admin panel since you already have access :)
NOTE: JSP is only supported on Enterprise versions of ColdFusion. You can actually determine Enterprise vs Standard by requesting a non-existant .jsp file and judging how the server responds!
You have now successfully shelled a Cold Fusion Server at this point and in most cases have admin privileges to do what you want (create new user, add to admin group, add/enable RDP, enjoy new RDP). In the rare *nix instances your likely running as nobody or another non-elevated user so the usual post exploit game plan still applies if you want to takeover the whole server (i.e. root the box). Hope you enjoyed this first part of this series, second part to follow shortly....
Until next time - Enjoy!
I will start this series off with the most common vulnerability first, which is the known Local File Disclosure, or LFI, in the 'locale' parameter (also referenced under: CVE-2010-2861). The LFI vulnerability allows us to read files off of the target system, without any authentication. The neat thing that makes this one different than most LFD is that if we play our cards right we can use this vulnerability as a foothold to further penetrate our target, read and see. We first try to find the admin page, as it is the most commonly vulnerable page, but certainly not the only one. You can typically find it at one of the following locations:
- /CFIDE/administrator/index.cfm
- /CFIDE/administrator/enter.cfm
- /CFIDE/componentutils/index.cfm
- /CFIDE/componentutils/login.cfm
Knowing the version is important as it helps us to determine the appropriate path to use to try and turn this LFD into something useful. Now if you know the full path to the CF '.properties' file then you're in business as it contains the CF admin password hashes. The list of possible paths worth trying are as follows:
- v6: locale=..\..\..\..\..\..\..\..\CFusionMX\lib\password.propertiesen
- v7a: locale=..\..\..\..\..\..\..\..\CFusionMX7\lib\password.propertiesen
- v7b: locale=..\..\..\..\..\..\..\..\opt\coldfusionmx7\lib\password.propertiesen
- v8: locale=..\..\..\..\..\..\..\..\ColdFusion8\lib\password.propertiesen
- vJRun: locale=..\..\..\..\..\..\..\..\..\..\JRun4\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\password.propertiesen
NOTE: In version 6 & 7 encryption is not enabled by default, although i never seen a server which did not encrypt the password in hash form.
Now you can crack the password hash and login with clear text pass or we can use a little trick to bypass authentication requirements by using a pass-the-hash technique. The login form uses a bit of JavaScript magic to actually create a HMAC hash from the admin password hash and a salt value which is changed every 30 seconds. You can find this salt value by simply viewing the source code for login page, look at second occurrence of the term 'salt' or review form input details. Due to this, we pass the hash and generate the HMAC hash on our own and submit - simulating a successful login! You need to grab the salt from source:
OK, so you now have Password hash and salt in hand....
Here is some code I whipped up to accomplish this task of logging in real quick for you to get the authenticated cookie.
Quickly enter the needed details and run it. If successful, you will have the authenticated cookie presented to you in terminal, like so:
Now once you have the authenticated cookie, you're pretty much in. You can use your favorite cookie editor to load up the new 'CFAUTHORIZATION_cfadmin=<SOMEVALUEHEREONSUCCESS>'. Once loaded you simply refresh your browser and your now logged into the administrative panel for Cold Fusion. Now to try and get a shell up on the server....
If you already know the server path to web facing directory then you can move forward, if not you can check the 'Mappings' link on the left under 'Server Settings'. This will show a mapping of all paths for CF, by default the /CFIDE dir should be mapped giving us a usable path in the majority of cases. Mappings page looks like this:
Once path is known we will move to the 'Schedule Tasks' page located under 'Debugging & Logging' on left menu links.
Now you simply point the task scheduler at your remote CFM/JSP shell hosted on a server you control, stored in txt format like an RFI attack payload. You can schedule for a onetime event, it will default to current time so no need to calculate things if your on different time zone :) If you need a username/password to access the remote shell file source then provide as needed in appropriate fields of task scheduler. The next is key, mark the option to 'Publish" to true so it saves the results to a file (i.e. grab our remote shell source, and save to executable). You then provide it with the full path to where you want to write to. In the majority of cases /CFIDE is writable, otherwise poke around or generate errors in SQL queries on site to get path (standard Full Path Disclosure rules still apply here). When you form is all setup you can submit to create the scheduled task.
You will need to click on the green check-mark icon to run the scheduled task, which actually executes it and grabs our shell. If it has problems with remote file you will likely get a warning message of some kind in admin panel, edit and retry. Upon success, you can point your browser at the path you uploaded your shell to. In most cases Cold Fusion is running on Windows system with full NT AUTHORITY/SYSTEM privileges which means you pretty much own the local box now :)
If you find that 'cfexecute' is disabled and blocking your CFM shell from working properly, you can simply re-enable it from the admin panel since you already have access :)
NOTE: JSP is only supported on Enterprise versions of ColdFusion. You can actually determine Enterprise vs Standard by requesting a non-existant .jsp file and judging how the server responds!
You have now successfully shelled a Cold Fusion Server at this point and in most cases have admin privileges to do what you want (create new user, add to admin group, add/enable RDP, enjoy new RDP). In the rare *nix instances your likely running as nobody or another non-elevated user so the usual post exploit game plan still applies if you want to takeover the whole server (i.e. root the box). Hope you enjoyed this first part of this series, second part to follow shortly....
Until next time - Enjoy!
Saturday, October 13, 2012
Nessus Part II: Integration with Metasploit
Previously I showed you how to install Nessus vulnerability scanner on your Linux system and run some basic scans. Today I would like to show a few more steps on how you can make the most of this and import your scan results directly into Metasploit, as well as how you can actually run the entire scan from within Metasploit itself. You will need to read the previous write up if you are unfamiliar with Nessus, it can be found here. Assuming you have the basics down we can now begin....
Prerequisites:
Click on 'Download Report' in the upper right corner and choose the ".nessus" format which is easily imported and parsed by Metasploit.
Since I am using Metasploitable 2.0 for my target, my report file is now saved on Desktop as "nessus_report_Metasploitable_2.0.nessus" and now we can shift our attention to Metasploit. You will need to fire up the old MSFCONSOLE to get started. Once you have Metasploit started you need to make sure your database is connected so you can actually store what you import, you can use 'db_status' command to confirm database connection status...
Now we issue the 'db_import' command and point it at the file you want to import.
COMMAND: db_import /path/to/your/nessus_report.nessus
You can use this feature for more than just Nessus by the way, it currently supports a wide variety of tools like Acunetix, Amap, Burp Suite, NeXpose, NMAP, OpenVAS and a few more (issue 'db_import' with no arguments to see a full list). You should see a message indicating your import was successful or not, hopefully it was :) You can verify the imported details by use of the 'hosts' , 'services' and 'vulns' commands which will show what is currently in the database, like so:
SIDE-NOTE: You can share scan results from other tools like NMAP scans by following the same steps, although for NMAP you might use 'services' instead of 'vulns' to see the results. You can also scan directly from within MSF by simply using the 'db_nmap' command followed by your usual NMAP syntax and results will be stored directly into the database for continued reference and use.
OK, this covers how to import things from previously run scans as well as any other supported tool which has ability to parse output in a format MSF can use (usually XML based).
Now to see how we can actually run the Nessus scan itself directly from within the MSFCONSOLE. We can delete our imported results by simply issuing the 'hosts -d <TARGET-IP>' which will remove all records for this host IP which is contained in the database from the previous steps. Now we can start fresh and run from the console and check the database for results when its all said and done. First we need to load Nessus plugin since it is not loaded by default. This is done by simply issuing the following command:
COMMAND: load nessus
Now you can issue the suggested 'nessus_help' command to see all the options that are available to use...
OK, so Nessus plugin is now loaded into MSFCONSOLE but it is not actually connected yet. We now need to actually connect MSF to the running Nessus server. We can accomplish this with the 'nessus_connect' command and a set of valid credentials for Nessus, syntax like so:
COMMAND: nessus_connect userName:Password@<NessusServerIP>:8834 ok
NOTE: the 'ok' at the end to avoid issues with connecting due to certs
Now we are connected, we need to setup our scan as we would do in the Browser based GUI configurator. We can check the available scan "policies" by issuing the 'nessus_policy_list' command. You will need to take note of the policy ID number for the scan type you want to run as we will use it in a sec to launch the actual scan...
NOTE: It's odd but the actual '-' prefix to each number should be used to identify the ID :p
Now to launch the actual scan we put it all together:
COMMAND: nessus_scan_new <policy id> <scan name> <targets>
After you initiate the scan Metasploit doesn't try to bother you with a lot of verbose junk since they know your console space is valuable, so it runs in background and with the Nessus Server. In order to check if the scan is still running you can issue the 'nessus_scan_status' command with no arguments. You will be presented with a table of active running scans if still running otherwise it will simply state that there are no scans running, like so:
NOTE: if you need to pause a scan for some reason you can issue the 'nessus_scan_pause <scanid>' command which will pause your scan.
Once your scan has finished you might notice that the results have not yet actually been imported into Metasploit's database. This is because they are still on the Nessus server we connected to. We need to import them as we learned earlier so that everything pulls in. In order to do it this time we will use the Nessus plugin to handle it. You can issue the 'nessus_report_list' command to see a list of finished reports available to download and import, again you need to take note of the ID for the one you wish to work with. Once you know, you simply get it with the 'nessus_report_get' command followd by the report ID., and now we have a scan run from completely within MSFCONSOLE and all results fully populated in the MSF database of our choosing. You can now take your time to search through the results and what is available in Metasploit to exploit each finding.
Hope you enjoyed this follow up to the previous Nessus write-up. I referenced it before and received a few questions so hopefully this covers things in enough details to get you on your way. More to come soon, so stay tuned and until next time - Enjoy!
Prerequisites:
- A Vulnerable Machine (Metasploitable 2.0 being used for today's demo, download available here
- Stable up to date Metasploit installation, see here if you need some help gettting started you can see this here
- Nessus v5 fully installed and running
- Nessus scan profiles and scan types already setup as well as a already completed scan
- a little patience
Click on 'Download Report' in the upper right corner and choose the ".nessus" format which is easily imported and parsed by Metasploit.
Since I am using Metasploitable 2.0 for my target, my report file is now saved on Desktop as "nessus_report_Metasploitable_2.0.nessus" and now we can shift our attention to Metasploit. You will need to fire up the old MSFCONSOLE to get started. Once you have Metasploit started you need to make sure your database is connected so you can actually store what you import, you can use 'db_status' command to confirm database connection status...
Now we issue the 'db_import' command and point it at the file you want to import.
COMMAND: db_import /path/to/your/nessus_report.nessus
You can use this feature for more than just Nessus by the way, it currently supports a wide variety of tools like Acunetix, Amap, Burp Suite, NeXpose, NMAP, OpenVAS and a few more (issue 'db_import' with no arguments to see a full list). You should see a message indicating your import was successful or not, hopefully it was :) You can verify the imported details by use of the 'hosts' , 'services' and 'vulns' commands which will show what is currently in the database, like so:
SIDE-NOTE: You can share scan results from other tools like NMAP scans by following the same steps, although for NMAP you might use 'services' instead of 'vulns' to see the results. You can also scan directly from within MSF by simply using the 'db_nmap' command followed by your usual NMAP syntax and results will be stored directly into the database for continued reference and use.
OK, this covers how to import things from previously run scans as well as any other supported tool which has ability to parse output in a format MSF can use (usually XML based).
Now to see how we can actually run the Nessus scan itself directly from within the MSFCONSOLE. We can delete our imported results by simply issuing the 'hosts -d <TARGET-IP>' which will remove all records for this host IP which is contained in the database from the previous steps. Now we can start fresh and run from the console and check the database for results when its all said and done. First we need to load Nessus plugin since it is not loaded by default. This is done by simply issuing the following command:
COMMAND: load nessus
Now you can issue the suggested 'nessus_help' command to see all the options that are available to use...
OK, so Nessus plugin is now loaded into MSFCONSOLE but it is not actually connected yet. We now need to actually connect MSF to the running Nessus server. We can accomplish this with the 'nessus_connect' command and a set of valid credentials for Nessus, syntax like so:
COMMAND: nessus_connect userName:Password@<NessusServerIP>:8834 ok
NOTE: the 'ok' at the end to avoid issues with connecting due to certs
Now we are connected, we need to setup our scan as we would do in the Browser based GUI configurator. We can check the available scan "policies" by issuing the 'nessus_policy_list' command. You will need to take note of the policy ID number for the scan type you want to run as we will use it in a sec to launch the actual scan...
NOTE: It's odd but the actual '-' prefix to each number should be used to identify the ID :p
Now to launch the actual scan we put it all together:
COMMAND: nessus_scan_new <policy id> <scan name> <targets>
After you initiate the scan Metasploit doesn't try to bother you with a lot of verbose junk since they know your console space is valuable, so it runs in background and with the Nessus Server. In order to check if the scan is still running you can issue the 'nessus_scan_status' command with no arguments. You will be presented with a table of active running scans if still running otherwise it will simply state that there are no scans running, like so:
NOTE: if you need to pause a scan for some reason you can issue the 'nessus_scan_pause <scanid>' command which will pause your scan.
Once your scan has finished you might notice that the results have not yet actually been imported into Metasploit's database. This is because they are still on the Nessus server we connected to. We need to import them as we learned earlier so that everything pulls in. In order to do it this time we will use the Nessus plugin to handle it. You can issue the 'nessus_report_list' command to see a list of finished reports available to download and import, again you need to take note of the ID for the one you wish to work with. Once you know, you simply get it with the 'nessus_report_get' command followd by the report ID., and now we have a scan run from completely within MSFCONSOLE and all results fully populated in the MSF database of our choosing. You can now take your time to search through the results and what is available in Metasploit to exploit each finding.
Hope you enjoyed this follow up to the previous Nessus write-up. I referenced it before and received a few questions so hopefully this covers things in enough details to get you on your way. More to come soon, so stay tuned and until next time - Enjoy!
Wednesday, October 3, 2012
Cracking Password Protected Zip Files on Linux with FCRACKZIP
I recently was given the keys to the castle and once inside I did the usual snooping around and well in the end I found myself with a collection of password protected Zip files that I knew had all kinds of juicy info inside. Now I have cracked protected Zip files in the past on Windows using a few tools some friends of mine made, but I had never done it since I had moved to my new Linux setup. I decided to make a little tutorial out of the whole incident for anyone interested or in a similar situation. In my search and review I ended up using a tool called FCRACKZIP, and this will be the focus for today's writeup. They actually support a Windows binary version which syntax should be identical to what your about to read. You can download the appropriate package for you from the makers homepage here: FCRACKZIP.
If you are on a Linux machine you can install it using apt-get, like so:
COMMAND: sudo apt-get install fcrackzip
Now if you have some protected Zip files laying around then that's great, but if you don't you can perform a quick command to make one. Here is the syntax and quick example:
COMMAND: zip --encrypt -r <ArchiveName> </target/U/want/2/zip>
EXAMPLE: zip --encrypt -r sup3rs3cr3t /home/hood3drob1n/Desktop/fcrackzip-TuT.txt
You will get a prompt after you hit enter which will ask you to type in the password, and then again to confirm it. You should then have a password protected Zip file to use for further testing.
First, as with any tool, we start by quickly reviewing the documentation and then the help menu. Here is quick shot of the main features as outlined in the help menu:
COMMAND: fcrackzip --help
I will note since it may not be clear at first that the '-c' charset option has a few options which will aid you if you are going to perform a straight bruteforce attack on the password:
a => lower aplha charset [a-z]
A => UPPER aplha charset [A-Z]
1 => numerical charset [0-9]
! => Special charset [!:$%&/()=?[]+*~#]
: => Used to mark additional characters to add into the charset
You should typically start with a wordlist and then move to bruteforcing after. In order to perform Dictionary based attack just point it at the wordlist and zip file you want to crack open:
COMMAND: fcrackzip -D -p 500-worst-passwords.txt -u -v --method 2 sup3rs3cr3t.zip
=> try to cracking using 500-worst-passwords.txt as our pass list
NOTE: I experienced app crashes if I didn’t place the password list in same location i was running fcrackzip from so just do some copying or moving if you experience similar issues to work around the issue...
Once you have exhausted your wordlist options you can move to bruteforce attacks. Now you can use the '-l <min>-<max>' option to set the min and max password lengths for bruteforce attacks, or you can use the '-p' init option to set the default value and starting string for cracking, for example:
COMMAND: fcrackzip -b -c a -l 1-8 -u -v sup3rs3cr3t.zip
=> bruteforce attack using the lower aplha charset, testing for lengths 1-8
NOTE: use of the '-u' option cuts down on the false positives as it actually tries to unzip the file using the password. It may increase load and time a little but will greatly cut down on false detections. I highly recommend using this option for pretty much all attacks...
Another example using a bruteforce attack against a fixed length via the -p/init option. It works like so:
COMMAND: fcrackzip -u -c a1 -p saaaaa sup3rs3cr3t.zip
=> test a-z0-9 but only for those of 6 char in length, starting at string 'saaaaa'
This sums up the general usage of fcrackzip and you should now be on your way to opening up all those pesky zip files you don't seem to have passwords for. I'm sure there are other tools out there, but this one worked well for me so thought I would share....
Until next time, Enjoy!
If you are on a Linux machine you can install it using apt-get, like so:
COMMAND: sudo apt-get install fcrackzip
Now if you have some protected Zip files laying around then that's great, but if you don't you can perform a quick command to make one. Here is the syntax and quick example:
COMMAND: zip --encrypt -r <ArchiveName> </target/U/want/2/zip>
EXAMPLE: zip --encrypt -r sup3rs3cr3t /home/hood3drob1n/Desktop/fcrackzip-TuT.txt
You will get a prompt after you hit enter which will ask you to type in the password, and then again to confirm it. You should then have a password protected Zip file to use for further testing.
First, as with any tool, we start by quickly reviewing the documentation and then the help menu. Here is quick shot of the main features as outlined in the help menu:
COMMAND: fcrackzip --help
I will note since it may not be clear at first that the '-c' charset option has a few options which will aid you if you are going to perform a straight bruteforce attack on the password:
a => lower aplha charset [a-z]
A => UPPER aplha charset [A-Z]
1 => numerical charset [0-9]
! => Special charset [!:$%&/()=?[]+*~#]
: => Used to mark additional characters to add into the charset
You should typically start with a wordlist and then move to bruteforcing after. In order to perform Dictionary based attack just point it at the wordlist and zip file you want to crack open:
COMMAND: fcrackzip -D -p 500-worst-passwords.txt -u -v --method 2 sup3rs3cr3t.zip
=> try to cracking using 500-worst-passwords.txt as our pass list
NOTE: I experienced app crashes if I didn’t place the password list in same location i was running fcrackzip from so just do some copying or moving if you experience similar issues to work around the issue...
Once you have exhausted your wordlist options you can move to bruteforce attacks. Now you can use the '-l <min>-<max>' option to set the min and max password lengths for bruteforce attacks, or you can use the '-p' init option to set the default value and starting string for cracking, for example:
COMMAND: fcrackzip -b -c a -l 1-8 -u -v sup3rs3cr3t.zip
=> bruteforce attack using the lower aplha charset, testing for lengths 1-8
NOTE: use of the '-u' option cuts down on the false positives as it actually tries to unzip the file using the password. It may increase load and time a little but will greatly cut down on false detections. I highly recommend using this option for pretty much all attacks...
Another example using a bruteforce attack against a fixed length via the -p/init option. It works like so:
COMMAND: fcrackzip -u -c a1 -p saaaaa sup3rs3cr3t.zip
=> test a-z0-9 but only for those of 6 char in length, starting at string 'saaaaa'
This sums up the general usage of fcrackzip and you should now be on your way to opening up all those pesky zip files you don't seem to have passwords for. I'm sure there are other tools out there, but this one worked well for me so thought I would share....
Until next time, Enjoy!
Subscribe to:
Posts (Atom)