New ASLR-busting JavaScript is about to make drive-by exploits much nastie

New ASLR-busting JavaScript is about to make drive-by exploits much nastier

-- Tom

 

"When combined with attack code that exploits vulnerabilities in browsers or operating systems"

 

"A Chip Flaw Strips Away Hacking Protections for Millions of Devices...

...Meanwhile, Gras [one of the researchers that discovered the vulnerability] suggests some band-aids. You can enable plug-ins, like NoScript for Firefox or ScriptSafe for Chrome, to block javascript on web pages. And browser-makers could conceivably reduce the exactness of the timing measurements they allow scripts to make, preventing them from monitoring the MMU’s speed.

At least one company has already worked to mitigate the dangers; Apple published a software update designed to “harden” Safari but didn’t reveal exactly what that update does. An Apple spokesperson says the company also distributed a plan of action to other affected vendors—likely the companies that build the chips it uses.

A full fix will ultimately require replacing hardware, not software...

...Intel, Microsoft, and Mozilla, meanwhile, downplayed the issue. [Sad] 'We’ve determined it does not represent a security issue,' says a statement Microsoft PR emailed to WIRED. Intel writes that the research 'doesn’t represent a significant change in the security of Intel...'

...It’s little comfort, however, for Microsoft and Intel to point out that defeating ASLR alone doesn’t allow someone to hack an operating system, Oren says. With ASLR broken, hackers will go back to hunting the kind of commonplace memory corruption bugs that ASLR rendered useless. Old bugs could learn new tricks..."

https://www.wired.com/2017/02/flaw-...-key-hacking-defense-software-cant-fully-fix/

 

That's the "rub" and also the issue with PC software development. Security implications are far down on the priority list if they are considered at all.

 

This means that one of protections could be circumvented and exploits could be easier found. As said in Wired article - we can expect to see old bugs again. Good news for bad guys, bad news for users and those that defend systems.

 

"A full fix would require replacing hardware..." Right. I wonder if anything could be done or added via UEFI/BIOS.. Every little bit helps.

 

Install MemProtect free (I have Chromium in stead of Chrome and Firefox installed in Mozilla, so Program Files and AppData folders are the same). I am on Windows7, therefore protecting explorer (which is allowed in Secure Folders) against hollow process attacks from user folders (on Windows10 all HPMA alert exploit attacks fail on explorer, enable RFG for extra protection).

[LETHAL]
[#LOGGING]
[WHITELIST]
[DEFAULTALLOW]
!*\Chromium\*>*\chromium\*
!*\Mozilla\*>*\Mozilla\*
!*\PDFCreator\*>*\PDFCreator\*

!C:\Program Files\*>*SumatraPDF.exe
!C:\Program Files\*>*splwow64.exe

[BLACKLIST]
*\Chromium\*>*
*\Mozilla\*>*
*\PDFCreator\*>*

*SumatraPDF.exe>*

C:\Users\*>explorer.exe
D:\*>explorer.exe
[EOF]

 

Hm, and what about sandboxing? I'm not familiar with sandboxing technologies on Windows, but on Linux seccomp-bpf is used by, e.g., Chromium and Firejail in order to filter syscalls. Would that mitigate this problem?

 

MemProtect is a memory sandbox using Protected Processes feature of Windows itself. In above settings Chromium is only allowed to mess with Chromium (whitelist !*\Chromium\*>*\Chromium\*), but Chromium is not allowed to touch others (blacklist *\Chromium\*>*), so javascript exploits are caged in their host application (chromium) and the intrusion stops right there

 

Sounds good - but do you have any evidence that this really protects against this ASLR bypass or this side channel?

 

As the article stated (see post#2) you still need an browser or OS-exploit. So I have no hard evidence other than running HPMAlert testtool exploit test against a MemProtect caged windows process, which proofs that all intrusions fail according to this PoC-test tool.

Do you have evidence that firejail does what it promises (by the way thx for helping with firejail when I was playing with Xubuntu)

 

No, I haven't. That's why I asked above question. BTW, I don't think that Firejail "promises" protection against ASLR bypasses. I simply don't know if that would be a side-effect of filtering/blocking specific syscalls.

 

Link me the exploit and I'll test it for you
Firejail does what it promises.

Personally I'm not worried about this.

 

You know as well as I do, that the exploit is the missing link, testing in a VM is the easy part.

You don't know what you can't test, so let's say your trust in firejail equals mine for MemProtect

 

Isn't this stuff the reason why tools like anti-exploit and anti-executable exist? There is nothing scary about this.

 

I'm not sure that we'll know until it hits, but what are some examples of those tool categories you mentioned?

 

Ummmm. "invisible, fileless malware" (https://arstechnica.com/security/20...alware-is-infecting-banks-around-the-globe/); "ASLR-busting JavaScript" (https://arstechnica.com/security/20...about-to-make-drive-by-exploits-much-nastier/)...

The problem with paradigms is they tend to victimise their adherents. I mean, who ever thought that injecting code didn't need a file (storage) structure? So the old paradigm morphed, or so I thought. But AnC? Come ON!!!! It's in the chip innit? Da. Now the paradigm has morphed.

BTW, disclaimer. I'm not a coder. I have trouble running ReactOS in Virtual Box and I still don't have a good handle on PuTTY. I'm an analyst, effect and cause.

So, "Isn't this stuff the reason why tools like anti-exploit and anti-executable exist? There is nothing scary about this" (Rasheed187).

I'm sorry Rasheed, but you're right. There's nothing scary. It's TERRIFYING.

Let me illustrate. We all know the rough location of the 3-finger salute intercept, yes? And I guarantee that any cracker worth his salt has a much better understanding than we do. So how about a little app that neuters the anti-virus and also replaces the SysTray icon to keep the user calm, so we can now simply replace, quietly now, the intercept code with nop commands? (I'm keeping this down to basic ideas and concepts.) Now let's create, quietly now, a new God Account and (quietly now) delete all others. While we're here, let's rewrite some or all the MBR. And now let's reboot. All your boxes is me.

Please tell me where curr////old security paradigms can stop this? Anti-executables need file names. Anti-exploits need to see bad behaviour, which is why we neutralise them ASAP, and I'm pretty sure they also need file names.

While we're here, I tried (again) to reach Apple Support (https://support.apple.com/en-us/HT207482). I can't go there! Not because my box is Win7, but because Apple's web-facing security is still SSL, where most responsible vendors--Microsoft take a bow!--have bitten the bullet and moved on to TLS. Do I really believe Apple has--or can--harden Safari?



This bit is not off-topic. I promise. "Is the Linux Desktop less secure than Windows 10?" (https://fosdem.org/2017/schedule/event/linux_desktop_versus_windows10/)

So where do we go? ECMA/JS is now more broken than SSL, it will take a decade to fix it to everybody's satisfaction. Oh, it can be repaired right now, a couple of months perhaps, but well before the New Financial Year. But not "fixed". "Fixing" means every last deprecated install has to be deleted and replaced. Browser manufacturers need to be beaten into submission. The list goes on.

What other scripting methods can be used to attack hardware? Don't worry about getting them into browsers, just what they need to get into the CPU.

And I correctly guess the CPU makers are probably looking at a minimum 24-month program which doesn't help anybody now reading this and some of us cannot replace our boxes that soon anyway.

Who else makes CPU chips?

 

The way I understood it, is that hackers who write exploits have always tried to bypass stuff like DEP and ASLR, this is simply a new method that makes it a lot easier. But tools like AE simply block the goal of exploits, which is to run malware via memory corruption techniques.

And it doesn't matter if the malware runs from disk or completely in-memory (file-less attack), if it is blocked from running, then it can't do any damage. It would be terrifying if this new attack completely bypasses current AE mitigation techniques. Do you think that this is the case?

 

Tools like HMPA and MBAE who can both block in-memory exploits. You can also use less advanced tools (that cause less problems) like ERP and AG who can only block disk-based exploits. But most exploits are actually disk-based, this means they will always try to write malware to disk, and run it as a malicious child process.

http://filehippo.com/download_malwarebytes_anti_exploit/
https://www.hitmanpro.com/en-us/alert.aspx
http://www.appguardus.com/
http://www.novirusthanks.org/products/exe-radar-pro/

 

Hi Rasheed - I'm not sure if this is the case... Yet. It would appear we only have a reported vulnerability, however I personally would not bother advertising to the world I have an exploit in the wild What we need ASAP is a realistic test of the reported vulnerability, which (obviously, duh!) would involve an unsuspecting victim, who is most likely to have a "typical" security setup.

I don't think I'm alone in confessing a less than omniscient knowledge of AE mitigation techniques, nor am I alone in distrusting anyone who does claim that type of knowledge.

FWIW, I made a quick/dirty scan through MBAE and HMP.A support-ish forums:
~~~~~~~~
From MBAE FAQ:
Posted June 26, 2014: Which vulnerability exploits does MBAE protect against? ...MBAE will not protect against exploits which take advantage of insufficient or incorrect configuration or information disclosures, XSS, SQL injection, etc.

Posted June 26, 2014: Which applications are shielded by MBAE? ...Custom shields can be created in MBAE Premium and For Business for any number of third-party or legacy applications. It is suggested to do so for Internet-facing applications and not for Operating System components.

Posted June 26, 2014: How is MBAE different from Enhanced Mitigation Experience Toolkit (EMET)? ... *MBAE comes pre-configured to protect popular applications such as Firefox, Chrome, etc. whereas EMET needs to be configured manually to protect some popular non-Microsoft applications.
*Adding protection to a new application is extremely easy in MBAE whereas it is extremely difficult in EMET. Users have to have some advanced knowledge of vulnerabilities and exploits in order to configure EMET to protect new applications.

https://forums.malwarebytes.com/topic/191297-shield-off-for-some-users-in-mmc/

From BleepingComputer https://www.bleepingcomputer.com/forums/t/634499/hitman-pro-alert-scan-fail/
Hitman Pro Alert Scan fail? Posted 10 December 2016:
Q: Hello, Just got Hitman pro alert installed on my PC, after installation whenever i click the gray scan box i get an error saying failed?
(pic)
Shows scan has failed, i don't know why? I do have Avast antivirus installed but i don't think that's conflicting it or is it? Any idea why the scan showing fail?
...
A: My firewall was abit too aggressive, so it blocked the outgoing connection to hitmanpro. I just whitelisted HitmanPro and Alert on my firewall and all is working fine Let me know if this works for you. ... ESET Interactive mode
~~~~~~~~

I would not be confident any Anti-Exploit is capable of protection if the aggressive firewall will disable it.

I am also of the opinion that any AE which needs to be set for individual apps is perhaps yesterday's technology.

I would refer you back to the fileless malware report from ArsTechnica, which indicates we can no longer protect selected apps, and perhaps we can no longer protect from assumed scripting technologies.

I must also make the observation that just because the fileless malware has been reported only against banks, that should indicate only that banks make very convenient low-hanging fruit. I think the next level will be botnet wars.

 

No offense, but if you don't really have that much knowledge about AE, then you're probably not in a position to make certain conclusions. I have read about this new ASLR bypassing method, and no where did they mention that it will make it easier to bypass current AE mitigations. So again, if AE is still capable of blocking the payload/malware from running (file-less or not), there is no problem.

 

Afaik a lot of AE migitations protect against techniques that try to 'bypass'/work-around ASLR. If ASLR itself can be rendered useless with this new attack then those techniques that the AE protects against are no longer necessary to pull off a succesfull attack. I don't have enough knowledge about exploits, so perhaps the developers of AE or smart users like @ropchain can comment on this. But it seems to me that the assumption that AE protects against this may be false.
Also the fact that it is not mentioned that that it will make it easier to bypass AE migitations doesn't mean a thing. It is also not mentioned that it doesn't. And since only a very small fraction of users have AE installed they probably did not take AE into consideration.

Yes, that is self explanatory. ALSR migitates succesfull exploitation of vulnerabilities. Not much point in defeating ASLR if you don't use it to exploit a vulnerability.

 

Ref.: https://www.exploit-db.com/docs/17914.pdf​

 

What they're describing is the cloud on-demand scanner HitmanPro, which won't work without Internet connection; not HitmanPro.Alert

 

In laymen terms: ALSR randomizes loaded modules in memory, so a module is loaded in a different part of the memory each time it is executed. ALSR is not a protection but an obfuscation mitigation. It makes life harder for exploits to change the flow of events in a predictable and controlable manner in another program. Read this article for a better explanation

In C/C++ languages there is no memory protection, so in Program A it is possible to define a table with 10 elements and access memory by using the 16th element even when this 16th element is outside the memoy space allocated of program A. This 16th element can be the memory space of another program (program B) which can be used to define a return value of a routine of that other program. So when program A changes that return value the flow of control in program B can be changed.

Most AE techniques make life harder for a malware writer by obfuscating stuff, trying to discover memory breaches after they have occurred or are looking at behavior typical for exploits having taken over control (e.g. downloading code). So adding AE software to the mix complicates stuff for malware writers reducing the chance of a "predictable and controllable" exploitation of a program vulnerability. DEP reduces attack surface (article) while ASLR scrambles the attack surface. Most AE protections also work without ASLR. Protected Processes
http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/process_vista.doc
is also a 'hard' mitigation.

Evolution of memory protection by the OS: Windows XP = DEP, Vista = SEHOP and ASLR, (I don't recall Windows 7 improvements), Windows 8 = Heap protection, Windows 10 = Control Flow Guard and Return Flow Guard