In search of a new trick for that Windows 7 Launch Party you’re invited to? 😉
Here’s one:
You can download a beta version of my UserAssist tool here. Soon I’ll be posting a final version with details and source code.
Wednesday 21 October 2009
Wednesday 14 October 2009
Update: WhoAmI? Version 0.1.3
I’ve updated my WhoAmI? Firefox add-on for Firefox version 3.5.
You can download it here or get it from the Mozilla site. I’ve nominated it to leave the Sandbox. If you use it, please post a review on the Mozilla page to help it on its way out of the the Sandbox (or keep it there if it’s too buggy).
Tuesday 13 October 2009
Update: PDFiD Version 0.0.9 to Detect Another Adobe 0Day
PDFiD is updated to detect the latest Adobe 0day, CVE-2009-3459.
I’ll provide more details in an upcoming post, just now for know that PDFiD detects a /Colors name followed by a very big number (larger than 2^24 or 16777216).
You can download PDFiD here.
Monday 5 October 2009
Preventing Applications From Starting (Malicious) Applications
Another very effective way to prevent malicious documents from infecting PCs, is to prevent vulnerable applications from starting other applications. As almost all shellcode found in malicious documents in-the-wild (again, I’m excluding targeted attacks) will ultimately start another process to execute the trojan, blocking this will prevent the trojan from executing.
This is an old idea you’ll find implemented in many sandboxes and HIPS. I added a new DLL to my basic process manipulation tool kit to prevent applications from creating a new process. Loading this DLL inside a process will prevent this process from creating a new process. I’ll explain the technique used in my DLL and how to load it in vulnerable applications in upcoming blogposts, but I want to start with showing how it prevents malicious documents from infecting a PC.
When the DLL is loaded inside a process, it will patch the Create Process API to intercept and block calls to it:
As a first test, we’ll use my eicar.pdf document.
Clicking the button will save the eicar.txt file to a temporary folder and launch the editor.
Adobe Acrobat reader will warn you when an application is to be launched:
But when you accept, the editor will be prevented to execute:
That’s because the DLL intercepted and blocked the Create Process call:
As a second test, let’s use a real malicious PDF document. The hooks installed by the DLL prevent it from executing the trojan:
Adobe Reader starts and then just crashes, without spawning another process:
When opening the same malicious PDF, but without the protecting DLL, the machine gets trojaned (execution of 1.exe and Internet Explorer):
This simple way of preventing applications from launching other applications comes with some drawbacks. For example, the Check Update function in Adobe Reader will not function anymore.
When you have a sandboxing system of HIPS installed on the machines you manage, check if you can use it to prevent vulnerable applications from starting other applications. If it doesn’t provide such a feature, try the new DLL I’ll be posting in the new version of bpmtk.
Monday 28 September 2009
Quickpost: SAFER and Malicious Documents
I wasn’t going to mention SAFER to restrict the rights of an application, because Software Restriction Policies can be bypassed. But a Tweet by Edi Strosar made me review my viewpoint. In this particular case, bypassing SRP is a non-issue, because the user is already local admin!
Software Restriction Policies allow you to force specific applications to run with a restricted token. As Michael explained it with AD GPOs, I’ll show it with local policies.
Enable SAFER policies for SRPs by adding DWORD registry key Levels (value 0x31000) to HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers:
Start the Local Security Policy administration tool and go to the Software Restriction Policies. You’ll have to create new policies if this is the first time you configure SRPs.
Create a new rule in Additional Rules. We’ll identify the application to restrict by its path and name, so create a Path Rule:
For the security level, select Basic User:
If you have no Basic User option, you forgot to update the registry before launching the administration tool:
Select the application to restrict:
This rule will force Adobe Reader to run with a restricted token:
Writing to SYSTEM32 is denied:
Sunday 27 September 2009
Preventing Malicious Documents from Compromising Windows Machines
Almost all shellcode I see in malicious documents (PDF, Word, Powerpoint, …) found “in the wild” does the following:
- download a trojan from the Internet using HTTP
- write the downloaded executable to SYSTEM32
- execute the downloaded executable
This infection method only works if the user is local admin. If the exploited program has no rights to write to SYSTEM32, the shellcode will just fail and the trojan will not infect the machine.
To protect yourself and/or your users against this type of attack (I’m not talking about targeted attacks), restrict the user rights. Windows Vista and later versions do this for you with UAC, even if you’re an administrator.
On Windows XP, you have to use a normal user account in stead of an admin account to achieve this. But running non-admin on Windows XP is not always easy. If you really need to allow admin rights on Windows XP, you can still prevent high-risk applications (like Adobe Acrobat and Microsoft Office) from having full control over the system by restricting their rights. This is done by using a restricted token for the processes of these applications.
There are 2 popular tools to launch programs with a restricted token:
- DropMyRights by Michael Howard
- StripMyRights by Kåre Smith
Both tools create a restricted token (by removing privileges and denying groups that provide local admin rights) and then launch the target program with this restricted token.
It’s not always easy to launch a program with DropMyRights, as there are many ways a program can be launched on Windows. For example with a file-type association or from a browser. To help you configure Windows to always restrict the rights of a specific program, StripMyRights also support the “Image File Execution Options” method with the /D option. The “Image File Execution Options” is designed to allow you to launch a program automatically inside a debugger. In the “Image File Execution Options” registry key, you specify the debugger to use. But this can really be any executable.
Example: to restrict the rights of Adobe Reader, add StripMyRights to the AcroRd32.exe Image Execution path like this:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\acrord32.exe] "Debugger"="StripMyRights.exe /D /L N"
This way, each time AcroRd32.exe is executed, StripMyRights executes first, creates a restricted token and then launches AcroRd32.exe with this restricted token.
But executing StripMyRights before executing the target application doesn’t always yield satisfactory results, sometimes it breaks the application, because of the broken process tree.
That’s why I developed an alternative, LowerMyRights.dll, to be presented in an upcoming blogpost.
Friday 21 August 2009
Update: Time Lapse Photography with a Nokia Mobile
I’ve debugged the issues some people had with my Nokia time lapse Python script, you can find a new version here.
Tuesday 11 August 2009
Update: UserAssist Tool Version 2.4.3
I had an interesting discussion with Hans Heins concerning the timestamp displayed by my UserAssist tool.
The first version of the UserAssist tool would only decode the UserAssist registry keys of the account under which it was running. And thus it made sense to display the timestamp in local time format, even if the entry is stored in UTC.
I added a warning about the time zones when I added registry file import functions, but this was confusing.
This new version of the UserAssist tool adds an extra column, with the timestamp in UTC:
And I’ll be posting a new version to support the new UserAssist registry key format of Windows 7 and Windows 2008 R2.
Download:
MD5: A5244C7F83E0DE70600E27F5D3B8AD7D
SHA256: 7E2D107BE84FBBF7E79F1BD11703401A374B5138B2F77E4FF8AFE1A3E749CCDA
Thursday 6 August 2009
Update: pdf-parser Version 0.3.5
After PDFiD, it’s pdf-parser’s turn to get updated.
The major change is support for /Names obfuscation through canonicalization. Now that these obfuscation techniques are found in in-the-wild samples, this feature became a necessity. For example, searching for /JavaScript when the PDF document contains /Java#53cript will also retrieve this obfuscated instance.
And if you need to see the obfuscated names like they are, use option –nocanonicalizedoutput
Support for filter ASCII85Decode has been added.
And option –hash displays the MD5 hash value of objects, making it easier to compare 2 PDF documents.
Download:
MD5: 07EA2C47766ADF248102E378C65D03F3
SHA256: 5EAD0F9BE9693EF836CF67FF2B796324ED5E7053D34BF4FA588D250A7DA2E761
Wednesday 5 August 2009
Update: PDFiD Version 0.0.8
PDFiD is updated.
Changes:
- It detects Flash in PDF (/RichMedia)
- Actions launched by Forms (/AcroForm)
- Less stringent %PDF header checking, because I saw some samples designed to bypass pddfid
- Updated the date format
- New option –force: force the scanning of a file, even if no valid %PDF header was found
- Accepts stdin for pipes, example: pdf-parser.py –filter –type /ObjStm flash.pdf | pdfid.py –force
This will scan objects “hidden” in object streams (/objStm)
Download:
MD5: 9769FB96899F3AD15510C903A4FB29EF
SHA256: 542734C2613439851AF99B59725B1607F96A6E9396B447C5BD3AF197AABB0231
