10 Jan 2013
After telling you about the impending SSH Apocalypse and releasing the SSH super virus, I received a number of good suggestions on improving my ssh_super_virus.py script. I didn't want to modify ssh_super_virus.py though because I want to keep it for posterity's sake. Instead I rewrote ssh_super_virus.py and included the suggested changes.
So, I give you ssh_pwn.py. This script will read the 'users' file and the SSH keys in the current directory and use them to authenticate to the list of hosts in the 'hosts' file, also in the current directory. If authentication is successful, the script will attempt to download additional SSH keys, the .bash_history file for the user, and SSL private keys. In addition, the script can be configured to automatically add new users , from /etc/passwd, and new hosts, from .ssh/known_hosts, to the list of users and hosts to test. Finally, you can give ssh_pwn.py your own list of post exploitation commands, which it will attempt to run and will save the output in the 'postexploit' file in the current directory.
You can get ssh_pwn.py from my pentest scripts repository at github.com. Enjoy, and as always let me know if there are any problems or if you have any suggested changes.
03 Jan 2013
The other day I read this article by Shaun Waterman at the Washington Times and it ticked me off a bit because of its obvious FUD (fear, uncertainty, and doubt). Mr. Waterman tells us about a flaw in SSH that will bring about data destruction of apocalyptic proportions. The flaw of impending doom? Key management. Apparently people leave SSH private keys lying around unprotected and because of this "most of the data on the servers of every company in the developed world" could get "wiped out." I can't blame Mr. Waterman for that gem, he is quoting Tatu Ylonen, the CEO of SSH Communications Security Corp.
I'm not saying SSH key management is not a problem. As a pentester, I look for unprotected SSH keys to dig my way deeper into a client's network. What I am saying is Mr Waterman and Mr. Ylonen are blowing this thing way out of proportion for no other reason than to sell SSH key management software, which SSH Communications Security Corp just happens to sell.
My favorite part of the article was this quote:
Mr. Ylonen said a computer programmer could create a virus that would exploit SSH’s weaknesses and spread throughout servers to steal, distort or destroy confidential data.
“It would take days, perhaps only hours,” to write such a virus, he said.
So as not to disappoint Mr. Waterman and Mr. Ylonen, I decided to create an SSH super virus. It's actually a Python script, which you can get here, and Mr. Ylonen was right, it only took me a few hours.
To use the script, follow the instructions below:
- Create a directory and place all the private keys you want to test and ssh_super_virus.py in the directory.
- Create a file called 'hosts' in the same directory and add each host you want to test to the file, one per line.
- Create a file called 'users' in the same directory and add each user you want to test to the file, one per line.
Ssh_super_virus.py will attempt to login to each host with each user/key combination. If a login is successful, ssh_super_virus.py will download all of the private keys in the users .ssh directory and test those against each user/host combination. You can also edit the script to add a list of evil_commands that will be run on successful login.
As always, use the script only for legal purposes and let me know if there are any problems with the script.
30 Nov 2012
So, I discovered a small problem with my Web server the other day. I host the fwcheck.com firewall rule analyzer on an Amazon EC2 server running the Apache web server. Being a security nut, I decided that this server needed to be HTTPS only so I configured my my Apache server to redirect all HTTP traffic to HTTPS like so.
RewriteEngine on
RewriteCond %{HTTP_HOST} ^fwcheck.com$
RewriteRule ^/(.*)$ https://fwcheck.com/$1 [NC,L,R]
RewriteCond %{HTTP_HOST} ^www.fwcheck.com$
RewriteRule ^/(.*)$ https://www.fwcheck.com/$1 [NC,L,R]
RewriteCond %{HTTP_HOST} ^54.245.114.39$
RewriteRule ^/(.*)$ https://fwcheck.com/$1 [NC,L,R]
After a little bit of testing, I was satisfied the redirection was working. Then I was looking at the server instance in the Amazon AWS console and I noticed the Amazon public DNS* name and decided to connect to my server using that name.
I got a directory listing, which I did not expect. So I went back to my Apache config and added another redirect as well as a directive to disallow directory listings.
<Directory />
Options -Indexes
AllowOverride None
</Directory>
RewriteCond %{HTTP_HOST} ^ec2-54-245-114-39.us-west-2.compute.amazonaws.com$
RewriteRule ^/(.*)$ https://fwcheck.com/$1 [NC,L,R]
It was a simple fix but it made me curious as to whether other servers were improperly configured like mine. So, I downloaded the Alexa top 1 million web sites and started writing some Python code. My goal was to find domains that were hosted on Amazon EC2 and that returned different results when accessing the web server with the domain name and with the Amazon DNS name.
First, I wrote a script that finds domains hosted on EC2. The script calls the host command to get a list of IP addresses associated with each domain. It then calls the host command again for each IP address, and parses the results to see which IP addresses were hosted at Amazon. The Amazon addresses are prefixed with 'ec2_'.
Next, I wrote a script to make an HTTP connection to both the domain name and the Amazon DNS name for each IP address and checked the two responses to see if they differed. I then wrote the results to an HTML file for manual verification.
The results were not as good as I had hoped. Of the 1 million web sites checked, I found 15,877 unique domains on 11,842 unique servers were hosted on Amazon. Of those 15,877 domains only 3,183 domains did not match the results from one or more of the Amazon EC2 servers on which the domain was hosted. Although I was disappointed in the results, I did find a few gems**, which I won't mention because I don't want to end up like this guy.
* Amazon assigns a public DNS name to all of its externally accessible instances. The DNS name is based on the IP address and the data center in which the instance is located.
** All identified vulnerabilities were reported to the appropriate people.
28 Nov 2012
At Tenable, I write text-based, single-purpose API tools in Python. I often need to display data in table format and wanted an easy way to do this. So, I wrote a simple Python module to draw text tables. Texttable allows you to add a header, column names, and specify column alignments. You can get the code here.
Usage
import texttable
t1 = texttable.TextTable()
t1.header = 'A Table of Numbers'
t1.add_col_names(['Col1', 'Col2', 'Col3', 'Col4'])
t1.add_col_align(['<', '<', '^', '>'])
rows = [[1, 2, 3, 4],
[5, 6, 7, 8],
[9, 10, 11, 12],
[111111, 22222222, 3333333333, 444444444444]]
t1.add_rows(rows)
print t1
t2 = texttable.TextTable()
t2.header = 'Another Table of Numbers'
t2.add_col_names(['Col1', 'Col2', 'Col3', 'Col4'])
t2.add_row([1, 2, 3, 4])
t2.add_row([5, 6, 7, 8])
t2.add_row([9, 10, 11, 12])
print t2
14 Nov 2012
One of the things I love about the Infosec community is building on other people's work and having them build on mine. My friend @tatanus from Seeds of Epiphany saw my Phishing with Webscript.io post and decided to take it to a whole new level.
If you need to setup a phishing campaign quickly, then checkout safelogin.co. You need to agree to the terms of service, provide a website to phish, and a name for your phishing site; safelogin.co will do the rest.
After you enter your data safelogin.co will provide you with two links. The first is for the phishing site and the second is where you can pickup your harvested credentials.
The phishing site has a simple CSS popup box that asks for credentials and has a picture or iframe of the actual site in the background. Once the credentials are entered the victim is redirected to the actual site.
And here is the data collected during the phishing campaign.
