Hacker News Reader

Comment by eps | Hacker News Reader

They pack malware code into an alpha channel of the ad image and then use inoccuous looking JS code (which happens to be delivered with the ad) to extract and execute it. This allows them to sneak their goods past the ad network review.

Neat, but not that impressive.

View on HN

The real attack is via Adobe Flash. The image thing is only to get past some virus scanners.

There have been so many vulnerabilities in Adobe Flash one has to wonder if they're deliberate. It's not a large body of code, after all.

> It's not a large body of code, after all.

Oh, of course it is. A complete scripting runtime engine (ActionScript), support for a boatload of video streaming formats including realtime communication, ...

And rather advanced 2D and 3D rendering engines.

It once all fit in a 1MB executable, and it hasn't gained much functionality since then.

One might say the same thing about browsers - as Flash bloated in scope over time, so do browsers now.

Firefox clocks in at a healthy ~50 MB, as does Google Chrome, for the offline installers - Chrome expands to ~360MB app size, and Firefox to ~180MB (both current versions on OS X 10.11). I won't even get started on the RAM usage - a typical 10-tab session can easily munch happily through 4 GB RAM and more (especially when there are lots of ads).

It's a pity that a 3-year-old netbook (or cellphone) is basically unusable because browsers creep up so much in featuritis :(

Throw in security updates twice a week for years on end...

Thank goodness that nightmare is over.

> It's not a large body of code, after all.

The Flash runtime is big, the API surface is huge and Adobe doesn't feel like it pours a lot of resources into maintenance today. The tech was nice but it should be banned from browsers today.

I'd certainly appreciate that. At least Twitch has an HTML5 player now, that cuts out a major use case for me.

I just wish i could tell those overly clever "adaptive" video quality systems (HLS, MPEG-DASH) to get out of my freaking way and give me a video file at a given bit-rate.

That might cause problems for a live stream...

But how can attack over Adobe Flash still works when Flash is disabled by default on FF and Chrome?

this particular attack targets IE users

Wait, why don't they just ship the evil code right away? If some blocking routine would be able to detect the malicios code as-is, shouldn't it be able to detect this as malicious code? It's code that builds javascript code and evals() it!

You shouldn't need any kind of blocking for that, the browser should block it out of the box.

Yeah, it seems like treating eval() as acceptable would allow for many other less elaborate nasty things. I mean, couldn't you just do eval('edoc dab'.split().reverse().join())?

Reviewers are probably taught what to look out for. In this case, training is the vulnerability.

You mean people at the ad-networks, reviewing the code that advertisers want to use?

Seems like a single occurrence of "eval" should both fail that automatic review AND be blocked by default in all browsers using default security settings.

I think this just shows that ad networks shouldn't be using js at all. Just dumb images. (Yes I know, no tracking then which makes it useless yada yada - deal with it)

> Seems like a single occurrence of "eval" should both fail that automatic review

You're not wrong, but there are difficult customers with money to consider.

> You're not wrong, but there are difficult customers with money to consider.

In google's case I can see the conflict - they both make a browser and live off ads. But apart from that minor issue I don't see why browser vendors don't just block "eval()"?

(Also, they have started blocking flash, thank god - so maybe this will all be a thing of the past soon)

Not only tracking, also fraud prevention (which they cannot actually 'deal without it')

If the ads are dumb enough (i.e. you don't count impressions/clicks/conversions etc) then there is also very little room for fraud.

My point is: online ads should become what bus stop ads have always been. You buy a space and display a dumb image. Did it work? You have to do your own A/B testing in half the city. What was it worth? You have to trust those you buy ad space from on how many people read their paper or pass by their bus stop.

Who said anything about including the word "eval"? Javascript is really rather bad for allowing surprising things: eval is possible in just 6 innocuous-looking characters - see http://www.jsfuck.com

Wth is that? How does it work? How does the token become 'eval'? Could this sonehow be blocked in browsers?

Weird type conversion rules in JS, see the examples at the bottom of the page and the linked source.

Yeah I saw them but didn't quite understand the ones at the bottom e.g."eval". I get the weird type conversions at the top, not how they magically become function calls at the bottom.

Edit: Wikipedia article explains - you can call functions by name with that "filter" thing.

This should be pretty easily blockable though - if you block "eval" then just block most of the obscure jsfuck constructs too.

the jsfuck.js parses the obfuscated string to generate valid javascript code. One one the patterns that jsfuck.js supports is "run the followin as eval()" https://github.com/aemkei/jsfuck/blob/master/jsfuck.js line 282

Moral of the Story: There's no such thing as an innocuous eval()?

I use PHP's eval() for an interactive testing environment on a live smallish server. It's like open-heart surgery, so I agree it's not innocuous. Of course I took care to protect the access. This environment is useful for some quick hacks and tests. If this were a bigger deployment with more at stake, I would remove this environment from the production systems. Because, you know, it's not innocuous.

This isn't a useful answer for you at all, but I thought I'd mention that there are "kind of" innocuous eval()'s such as Angular's eval() [1] where instead of JS being evaluated (which can lead to nasty things), an Angular expression is evaluated, which is a bit safer.

Obviously what I've just said doesn't help solve any problems here, but thought I'd throw it in there anyway :)

[1] https://docs.angularjs.org/api/ng/type/$rootScope.Scope#$eva...

This is false, Angular expressions / sandbox are NOT security. They are not safer at all. Do not execute untrusted Angular expressions.

Unless the language supports first class environments, and you're binding to that. (Like Common LISP, Scheme, Lua, ...)

And it needn't look like eval: http://www.jsfuck.com

JavaScript demos have been using a similar trick for several years.

https://news.ycombinator.com/item?id=9319526

I find the impressive part the stenography they did to make sure that the code wasn't being monitored in a security researcher's sandbox.

This also sneaks past CORS. I'm thinking _that's_ a problem.

Why do you think this bypasses CORS?

Well, it bypasses the spirit, which was to exert some control over what got loaded into the browser via the back door. Now, malicious code can just come in the front door.

If anything it's a useful demonstration of how CORS is more theater than security for anything beyond the most trivial scenarios.

I wonder how hard it would be to come up with a "containerization" mechanism for the web so as to separate scripts/resources better.

Reply on news.ycombinator.com