Saturday, 23 February 2013

Stored XSS in Using Embed

Back in December I came across a stored XSS vulnerability in I was unfortunately too slow in my reporting and was beaten to it by Subho Halder. It was quite funny as he plastered the site with his own swf file to demonstrate the vulnerability.

This is a quick post covering the vulnerability and how it was exploited.


When it comes to sites that allow direct modification of html, the likelihood of XSS can go up massively. In the case of they used a home-grown (or what appeared to be home-grown) comment system for their forum that let you edit the HTML of your comments. Although there were some protections in place to stop you inserting <script>, <object> and <applet> tags, they did allow you to use <img> and <embed>.

Note: For more info on tags and insertion of malicious code I found the following URL really useful:

I first tried <img> based XSS and it worked when previewing the post but when actually posting the onerror was stripped.



Instead of trying to find a filter bypass I decided to take a look at the embed tag.

Our friend the SWF file

Some of you may have read my previous post on SWF analysis where i looked at exploiting an SWF for XSS:

In that post I focused on exploiting a poorly built SWF, however we can just build a malicious SWF that contains a javascript payload. Subho's SWF can be found here:

Using SWFScan to analyse the file its really easy to spot the exploit code he used:

public static function main ()
    var __callResult_20 = getURL("javascript:alert(\"XYSEC TEAM
\"+document.domain)", "_self");

Looking up getURL from the Adobe site:
Loads a document from a specific URL into a window or passes variables to another application at a defined URL.

So we could grab a payload from a remote site or to perform XSS we could use "javascript:" which simply runs javascript locally in the browser in the security context of the current site.

And to deploy our SWF as a stored XSS attack all we need to do is embed our malicious content in a comment:
<embed allowscriptaccess="always" src="" height=1 width=1></embed>

The allowscriptaccess parameter allows our remote script to communicate with the domain in which its embedded and I've used height=1 and width=1 to effectively make it invisible.

Whenever anyone viewed the comment the remote SWF would be loaded and they would be pwned XSS style, sweet!

Final Thoughts

Allowing users to edit HTML on your site can be a risky feature. Script, applet, object, iframe, image and embed tags need to be carefully filtered to prevent abuse. In this case it was a lack of SWF filtering that allowed us to use the embed tag for stored XSS.

Congrats to Subho for reporting this before me, his site can be found here:

Pwndizzle out

Saturday, 9 February 2013

Parsing Nmap smb-enum-shares Output

This is quick post about the Nmap smb-enum-shares script.

I wanted to track down open shares on a /16 and was having some difficulty parsing the results. I did some googling but couldn't find any help. In the end a grep/awk one liner saved the day and that's what I'll be talking about.

Pew pew with nmap scripts

Before I delve into smb-enum-shares I wanted to big up one of my favourite posts about nmap scripts by Matt at

He covers some of the most useful scripts http-enum, smb-check-vulns, smb-enum-users to name a few, and also looks at handling the output using some perl kungfu. The one script he missed out though was smb-enum-shares!

Your company and its shares

From a defensive perspective open shares are a pain in the ass. It can be difficult preventing users from creating shares, difficult to manage permissions and difficult to classify what information should/shouldn't be shared. Not to mention the risks of SMB and pass the hash.

Removing local admin rights, properly enforcing GPOs, using a host based firewall/ips or a document repository can help but there's always going to be some folks who slip by. This is where nmap and smb-enum-shares comes in. To find open shares just run the following:

nmap -T4 -v -oA myshares --script smb-enum-shares --script-args smbuser=pwndizzle,smbpass=mypassword -p445

Replacing the ip range and domain creds as necessary.

The nmap grepable format and xml format are usually easy to manipulate either on the command line or with Excel. However when you run the smb-enum-shares script the output isn't uniform and in my case I had such a large data set it was proving difficult to filter effectively.

Below is a demo output, notice the variety of data and the way it is spread over multiple lines:

Nmap scan report for
Host is up (0.0024s latency).
445/tcp closed microsoft-ds

Nmap scan report for (
Host is up (0.023s latency).
445/tcp open  microsoft-ds

Host script results:
| smb-enum-shares: 
|   ADMIN$
|     Anonymous access: <none>
|     Current user ('pwndizzle') access: <none>
|   SecretShare
|     Anonymous access: <none>
|     Current user ('pwndizzle') access: READ/WRITE
|   C$
|     Anonymous access: <none>
|     Current user ('pwndizzle') access: <none>
|   IPC$
|     Anonymous access: READ <not a file share>
|_    Current user ('pwndizzle') access: READ <not a file share>

For two machines it's easy to understand. How about if you had 2000 machines? Not so easy :)

Bring on the Grep, Awk, Sed

My aim was to get a list of IP's and associated shares. No doubt there's a million and one ways to do this with different linux utilities, perl or python and the different nmap outputs. The simplest technique I could find was using a bit of awk/grep to parse the data from the basic nmap output file (.nmap):

cat sharescan.nmap|grep '|\|192'|awk '/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/ { line=$0 } /\|/ { $0 = line $0}1'|grep \||grep -v -E '(smb-enum-shares|access: <none>|ADMIN\$|C\$|IPC\$|U\$|access: READ)'|awk '{ sub(/Nmap scan report for /, ""); print }'
  • I first selected only the lines that contain an ip or a pipe character (lines with shares)
  • Then, as the share and ip are on different lines we select the ip column and copy it in front of the share lines.
  • We do some more grepping to remove unneeded nmap output and default shares.
  • And finally we perform a substitution to remove the starting text.

Here's the final output:

As either an attacker or defender you've now got yourself a clear list of shares that may contain sensitive information.

Regarding the one-liner, there are one or two points to note:
  • There are probably better ways to implement this! I'm no awk/sed master.
  • You'll need to change the "192" to fit your network.
  • By excluding shares we might actually exclude something we want to see.
  • When scanning you need to use valid AD credentials for the best results.
  • Although the nmap script output says READ,READ/WRITE, I didn't always find this was accurate. Often readable shares, well, weren't readable. However you may want to remove the "access: READ" exclusion as this also filters WRITE folders which can be pretty handy!

Although it hasn't been the focus of this post, the smb-enum-shares script can verily easily be used for network wide pass the hash and remote access testing. There's a great blog post about this by Zeknox here:

Final thoughts

Although often seen as an offensive tool, Nmap's ability to provide a quick view of your assets and running services make it an awesome tool for attackers and defenders alike.

Network wide scans are extremely quick, it's analyzing the results that actually takes some time. But with a little manipulation you can usually speed this process up. And when it comes to manipulation you can't get better than grep/awk/sed!

Also if anyone can come up with a simpler one liner let me know! ;)

Pwndizzle over and out