Comma Operator
One thing I've seen in obfuscated code is excessive use of the comma operator. But, does that count as evasion or just obfuscation?
A honeypot project operated by Japanese comms company NTT has turned up a bunch of new approaches to malware obfuscation. Yuta Takata of NTT's Secure Platform Laboratories has published an analysis at the Asia Pacific Network Information Centre (APNIC) here. In it, he wrote that since JavaScript can be used to identify …
To clarify; it's a question requesting clarification.
The article's description and the initial example seem to pin the definition on some manner of conditional so that the exploit is only invoked for apparent weak users, e.g. those using older browsers, which frankly, is more than just obfuscation.
Yet, the table provided further on includes things that I'm not convinced fit the definition; and if I'm missing something, which is quite possible, then did I miss something about the delineation, or does that table need clarification.
As you mentioned, the initial example is a simple conditional code, aka browser fingerprinting code. On the other hand, evasive code listed in the table is a technique that abuses differences among JavaScript implementations. Attackers abuse such JS code to exploit only old browsers.
Please check details (case studies) of each JS behavior in the following slide;
https://www.first.org/resources/papers/conf2018/Takata-Yuta_FIRST_20180531.pdf
From the author :)
> but why would IE object to "setTimeOut(10)" ?
It's a probable syntax error in IE and every other browser (there is a setTimeout function but no setTimeOut).
Aside from that, setTimeout is not an ECMAScript function, but a common vendor addition. In this case, IE's function signature is different than Mozilla's and V8's in that it requires at least two arguments (a third argument is also accepted but with different semantics than the other implementor's).
It is just one way of fingerprinting IE. They could have equally passed a VBScript function as its first argument and a corresponding third argument and see if that run. If it did, you have IE, else it's something else.
Do sites serve up some other form of malware if they can't run JavaScript at all?
I ask because I have my browsers security locked to not run scripts at all & have found sites like CBC.ca that hardlock my browser as a result. My browser throws up the notice that "this site is timed out waiting for a script to run" which makes me think "No shit Sherlock, you can wait until Hell freezes over since it will never run at all!" What if you're using NoScript to block JS (from them/at all) & the site is rebuffed from running JS in the first place - does it throw up the same error message or does it simply serve up malware from a different vector?
"there are dozens of others."
Excluding things that exploit Intarweb Exploiter, (aka Microsoft's Internet Explorer}, can you name some please? Because the last time I checked, methods that use fonts or graphics files have been patched, long ago. At this point you would be required to actively visit an exploit site and enter information (like a phishing site), rather than having them run in background (using script or other 'executables') and harvest it somehow. Or steal your bandwidth. etc.
For the IE-specific exploits, the list may still be pretty long. It may no longer include ActiveX though. It's why I don't use IE. In fact, I don't web surf at ALL with a Windows OS. It's part of my 'Safe Surfing' rules, after all.
Safe surfing:
a) use NoScript or its equivalent, as restrictively as possible
b) NEVER use a Microsoft browser
c) Avoid web-surfing while running Windows
d) *ALWAYS* be logged in as a NON-PRIVILEGED user when web surfing
etc.
(not perfect, but generally effective)
and THAT is why I *ALWAYS* run the 'NoScript' plugin, except for those SPECIFIC web sites that for some reason I must use (let's say certain electronics parts suppliers), and their clueless "developers" require so damned much scripting via so many different CDN servers (_AND_ google metrics shhhtuff) that it's pathetic, and hard to 'allow for this session' all of the time because I do _NOT_ want to 'permanently allow' anything from google, and so I have a 'special browser' [named in a pejorative sense] set up JUST for THEM, that runs in a 'special' login context and deletes _ALL_ _HISTORY_ when I close it.
Javascript on the web is EVIL, NOT NECESSARY (use HTML5, CSS like a *REAL* developer), and RIFE with exploits, tracking, slurping, ad-targeting, yotta yotta.
Javascript on the web is EVIL, NOT NECESSARY (use HTML5, CSS like a *REAL* developer), and RIFE with exploits, tracking, slurping, ad-targeting, yotta yotta.
And when HTML5 rendering is deficient in a specific browser, do what? The same with CSS implementation.
Security by obfuscation or removal of useful technology isn't the answer. Otherwise, we'd all go back to banging rocks together in the presence of flammable rubbish to start to begin to get warm in winter.
Demanding better security is one method, legislating fines for insecure software another, finding behavioural methods of detection a much better method, which was what was done here.
"and their clueless "developers" require so damned much scripting via so many different CDN servers (_AND_ google metrics shhhtuff) that it's pathetic"
Firstly, you would be complaining that the page takes too long to load all those assets from halfway around the globe if "developers" weren't so "clueless".
Secondly - do you really think its the devs that want to put all that "google metrics shhhtuff" on the page?
"Javascript on the web is EVIL, NOT NECESSARY (use HTML5, CSS like a *REAL* developer)"
Technically HTML5 is an umbrella term that includes Javascript so I feel you don't know what you're talking about.
And considering a large proportion of professionally built websites use AngularJS it's pretty hard to avoid.
Although there are many attack surfaces the vast majority of browser malware depends (depended?) on javascript at some point even if the flaw being exploited was not in javascript itself. If you are a little fish disabling javascript makes you considerably safer (unless lots of other little fish find the off switch). If you are a whale then it could be worth someone's time to create some software just for your unusual configuration.
Well, there's flash...
Just to name one.
Then, move onto BHO's and accessory programs that are vulnerable.
One of the reasons I prefer to use a honeyclient and sniffer, to actually see what goes on behind the scenes.
I've dissected real world attacks that otherwise would've been complete mysteries. Some, using really old tricks, such as dumping binary data into a text editor that didn't test for text data, via a remote session link. Others, using some innovative and novel methods, which my employer and their overlords were quite keen on.
A member on SANS forums discovered a bunch of websites that contain obfuscated javascript that redirects users browsing on their mobile devices.
The scripts use HEX to obfuscate the URL's that mobile browsers will get redirected to.
Do a Google search for: \x72\x65\x2E\x69\x6E\x66\x6F\
copy and paste the hex strings found in the source code of an infected webpage into any hex conversion site such as: ddecode.com to reveal the URL.
you can then enter ithe unobfuscated URL into a site that allows you to spoof the useragent strings such as: https://urlscan.io and use a useragent string from a mobile browser to see the redirect in action.
Virus writers have been doing similar things for years. Over a decade ago, I found an infected website that used similarly obfuscated code to extract the browser and JS engine version numbers and sent them as part of a GET request to another domain, which presumably delivered the actual virus. Visiting that domain without providing a vulnerable version returned an empty document. Not too surprising that they'd be looking for other, more subtle ways to identify browsers.