Bypassing SRP

ssj100 wrote:Excellent points p2u! Perhaps one point that you missed out was backing up - I make at least monthly byte for byte system images and ensure I back up large (eg. video) and important files on external isolated drives.

Here I go again, not agreeing with you.
Backup is not really a preventive measure. When you need it, it just means that somehow your policies have failed and you are in for similar trouble in the future. Besides, you can never say for sure that your backup is clean. Therefore, 'reflatten and rebuild' may turn out to be your only option. Believe it or not, but in my work (I mainly clean out infected computers) I have seen cases in which even backup fails. What's even worse: deep formatting may not be enough in some cases.

Paul

Haha, of course you agree with me - you're just making some other important points. In saying that, your response was not entirely appropriate to what I wrote. Your response would have been more appropriate if I wrote something like "backing up is completely a preventive measure and is all you ever need to be 100% safe" - I never said that, nor did I even remotely imply it.

I mean, the world may end tomorrow, but does that mean we don't bother saving money? Of course not.

But yes, I understand where you're coming from - I completely agree that backing up is not really a preventive measure, but I just wanted to point out that it's an extremely important process to carry out. It's funny that you've responded the way you did though - I remember I posted on Wilders (before I got permanently banned without warning/reason) an almost identical response to someone saying that backing up is the most important security measure - I completely disagreed with him. However, as I've said before, you can argue anything in life.

One aspect of your comments I don't quite agree with is the implication that backing up can fail frequently. Perhaps that's putting words in your mouth, but if the average reader read what you wrote above, they'd probably not bother backing up or learning how to make a byte for byte system image - that would be a bad outcome.

My advice is, once you've freshly installed Windows, configured all the settings you like, installed all the important programs/drivers and the latest updates, you should then make a byte for byte system image - I call this my "Baseline" image (and it's clean for sure). This should be stored away on an isolated external hard-drive and left alone. In this way, if your computer gets hosed, you can always just load up that image - trust me, this is much faster than doing everything from scratch - just updating Windows itself can take at least 30 minutes to an hour in my experience, and often you'll forget the various settings you had before (I'm actually quite pedantic about that and have made notes just in case haha), among other things.

With regards to not knowing if your back up image is clean for sure, that's true, but not really the point. The point is to make regular byte for byte image back ups as well as separate frequent back-ups of important files. This is so that you can always revert to the last clean image or restore files that would have otherwise taken a long time to obtain again.

In saying all that, realistically for me, I'm more worried about primary hard-drive failure and losing information that way - that's the main reason I back up on to external isolated hard drives. If my current hard drive fails, I won't be fretting too hard haha.

'ALWAYS' and 'NEVER' are just extremes. I'm, of course, talking about more or less targeted attacks. The average not too reckless person may sleep tight and just do his or her thing, don't worry.

Paul

Of course, but even the "average not too reckless person" will have eg. backed up important family photos etc, or at least they should (that is, have more than one copy on at least 2 separate data storing devices). One can never know exactly when the hard drive will suddenly die, a five year old child "accidentally" deletes data when you're not looking/supervising, or a virus slips through and formats C:\.

ssj100 wrote:Of course, but even the "average not too reckless person" will have eg. backed up important family photos etc, or at least they should (that is, have more than one copy on at least 2 separate data storing devices).

Sure! Just don't rely on automated technology to save your [insert body part here]; do it yourself immediately after the files have been created successfully, or you might get burned when you're expecting it least...

Paul

p2u wrote:Sure! Just don't rely on automated technology to save your [insert body part here]; do it yourself immediately after the files have been created successfully, or you might get burned when you're expecting it least...

I don't even know how to use this "automated technology" - out of curiosity, what are some of the programs that can achieve this?

By the way, this "automated" backing up process must mean that the external storage device is often (or always?) connected to the main system - bad idea, in my opinion - you'd always risk getting the external device infected (no matter how small the risk, it's still there). Instead, if the device is generally always isolated (disconnected), good luck to the malware trying to infect the device by jumping across air haha.

ssj100 wrote:
Sure, Microsoft may not have intended AppLocker to operate at kernel level specifically to prevent a malicious Office macro bypassing it, but lo and behold it does! Didier Stevens claims that AppLocker can't be bypassed from a Limited User Account without a Privilege Escalation Exploit, while SRP can be bypassed.

Finally, to drive home my point, what if the video I showed used a "arbitrary code execution vulnerability for some MS ActiveX component" which was able to bypass SRP and execute a malicious file, and then I posted another video showing that AppLocker successfully prevented this malicious file from being executed? This situation would have nothing to do with Macro protection or lack of. It would basically show that SRP is bypassed, while AppLocker is not. 1-0 to AppLocker.

Do you think that's reason enough to upgrade to Win 7?

apoptosis wrote:

ssj100 wrote:It would basically show that SRP is bypassed, while AppLocker is not. 1-0 to AppLocker.

Do you think that's reason enough to upgrade to Win 7?

If I may, I would say "no, not enough reason" since 1) AppLocker can be bypassed too with similar attacks and 2) you will have to buy one of the more expensive versions of Win7 to get it. Besides, with Win7 you get a lot of new attack vectors (Aero, Widgets, 124 or so services, instead of 86, just to name a few). And there's another point; you may know XP rather well, but Vista and Win7 are not so easy to configure to your taste, since MS has hidden a lot from the user and has rather drastically changed service dependencies, probably in an attempt to discourage disabling them. To give and example: while on XP you may safely disable the Task Scheduler, on Vista and Win7 you may not be able to boot the system if you do that, especially on a laptop. Even experienced administrators may have a hard time trying to get everything right. We are told that Vista and Win7 are "so new and so much safer", but it turns out that most malware and most exploits work equally well in Win7. Sorry to say so, but if you have the choice, stick to XP as long as you can.

Paul

Thanks Paul, I'll stick with XP as long as SRP is not under attack from real world malware.

p2u, that's great to hear from a professional like yourself. And I was already planning to stick with Windows XP until at least 2014. Seems I have more reason to now!

It would be nice to see a POC pdf that bypasses SRP and test it against the recently introduced Adobe Reader X which comes with a sandbox.

apoptosis wrote:It would be nice to see a POC pdf that bypasses SRP and test it against the recently introduced Adobe Reader X which comes with a sandbox.

Does anyone happen to know why there should ever be active content present in ReadOnly PDF-files at all? Most of the time, it's the javascript implementation that is to blame for exploitation. But with every new update, javascript is again enabled. Is that just only because the Reader has to take a thumbnail screenshot of the documents you read, or are there any other good reasons? Even when you have removed Acrobat from startup; if you move your mouse in the direction of a PDF file (you don't have to open it), check your task manager and see Acrobat shine. It stays there even after you close the document. I hate this kind of behavior...

Paul

p2u wrote:Even when you have removed Acrobat from startup; if you move your mouse in the direction of a PDF file (you don't have to open it), check your task manager and see Acrobat shine. It stays there even after you close the document. I hate this kind of behavior...

Yes, "AcroRd32Info.exe" pops into memory and stays there for about 15 seconds even after the document closes - really dislike this too, and I have no idea why it's implemented like that. I've even considered force sandboxing "AcroRd32Info.exe" haha.

ssj100 wrote:I've even considered force sandboxing "AcroRd32Info.exe" haha.

When you rename AcroRd32Info.exe into AcroRd32_Info.exe, the behavior stops, but then you are still left with uncontrolable automatic updates. I replaced Acrobat Reader with SumatraPDF; none of the PDF-exploits I've seen work with that one.

Paul

How bizarre. So you're saying that "AcroRd32Info.exe" is required to disable automatic updates?

By the way, I just thought of a way to exploit this - by default, Sandboxie, DefenseWall etc don't automatically run this process sandboxed/untrusted. So if a hacker could place malicious code into the pdf file and use something like this technique, the user could be potentially bypassed without even opening the file. Scary stuff!

ssj100 wrote:How bizarre. So you're saying that "AcroRd32Info.exe" is required to disable automatic updates?

No, no. I phrased that incorrectly. I was actually trying to say that if legitimate applications behave like "the enemy" (settings that can't be undone through the interface by the average user), they should be removed.

ssj100 wrote:By the way, I just thought of a way to exploit this - by default, Sandboxie, DefenseWall etc don't automatically run this process sandboxed/untrusted. So if a hacker could place malicious code into the pdf file and use something like this technique, the user could be potentially bypassed without even opening the file. Scary stuff!

Yes, that's right. That's "user convenience" going a bit too far. Binary stream handling vulnerabilities are the worst.

Paul

Thanks for the clarification. Again, this emphasises the need to be careful with what one recovers "out of the sandbox" and on to the REAL system. For example, it's probably unlikely you'll be hacked via an exploit when downloading and running a pdf file from "microsoft.com", but it'll probably be more likely if you downloaded it from "destroy_your_system.com" - if the malicious data doesn't make it on to your REAL system first, it can't do (much) harm.

ssj100 wrote:
By the way, I just thought of a way to exploit this - by default, Sandboxie, DefenseWall etc don't automatically run this process sandboxed/untrusted. So if a hacker could place malicious code into the pdf file and use something like this technique, the user could be potentially bypassed without even opening the file. Scary stuff!

The latest version of Adobe Reader doesn't have such vulnerability because it is sandboxed by default, right?

I don't know anything about the latest version of Adobe Reader, so I'm afraid I can't help you there.

Didier has explained to me how this exploit works:
http://blog.didierstevens.com/2009/03/04/quickpost-jbig2decode-trigger-trio/

Basically it involves a bug being triggered in the "explorer.exe" process (where the Adobe DLLs are loaded). Therefore, sandboxing the Adobe Reader processes will do nothing to stop this. However, sandboxing "explorer.exe" will contain this.

Given this piece of information, I have slightly modified my "security approach" - more specifically, I have slightly changed the way I manage newly introduced files on the REAL system. I'm hoping to do another video to demonstrate this.

Before, I was recovering newly introduced files straight to the desktop. Now, I have created a folder on the desktop called "Downloads". All newly introduced files will go directly into this folder. In this way, I will theoretically never need to browse the files with a REAL "explorer.exe". Again, similar programs like DefenseWall offer no such feature, and therefore people running programs like DefenseWall are vulnerable to these exploits.

If I wanted to delete the contents of the "Downloads" folder, I also wouldn't need to browse the folder with a REAL "explorer.exe" - I can use batch commands instead. If I wanted to copy or transfer something out of the "Downloads" folder (after verifying that it's probably safe with on-demand scanners), I would simply do so as per usual via the sandboxed "explorer.exe" window. If I wanted to copy something from untrusted USB drives, I would again use batch commands to transfer the files/folders into my "Downloads" folder.

ssj100 wrote:Basically it involves a bug being triggered in the "explorer.exe" process (where the Adobe DLLs are loaded). Therefore, sandboxing the Adobe Reader processes will do nothing to stop this. However, sandboxing "explorer.exe" will contain this.

Handlers in Windows are a mess; they just do anything automagically, especially if they are registered in the Explorer context menu (Wow! Ole! - pun intended).
If you don't want to sit in a sandbox, then the only good solution would be: install a PDF reader that doesn't display this automagic behavior.

Paul

p2u wrote:If you don't want to sit in a sandbox, then the only good solution would be: install a PDF reader that doesn't display this automagic behavior.

And also hope that no one is trying to exploit that PDF reader I suppose.

ssj100 wrote:And also hope that no one is trying to exploit that PDF reader I suppose.

No idea. At least I have the benefit of "Security through Obscurity" or "Security through Diversity". Besides, I just don't download stuff from resources I don't know to be absolutely safe. Signatures don't mean anything to me, since they are bought, not earned. The "Trusted Computing" principle (let THEM decide what is trusted and what not) is flawed and dangerous.

Paul

p2u wrote:Signatures don't mean anything to me, since they are bought, not earned.

Very wise words. Security applications are becoming increasingly reliant on verifying signatures to determine whether the app is 'good' or 'bad'. That trust model broke down years ago with domain-validated SSL certificates (requiring the move to Extended Validation SSL certs), and the same may well happen with application signing. We're already seeing malware that's digitally signed and the trend is probably only going to increase.

By the way, have a look at Sandboxie's motto:

ssj100 wrote:By the way, have a look at Sandboxie's motto:

Nice.
P.S.: I assume that "IE" within the sandbox is just a coincidence?

Paul