Malicious Utility Can Defeat Windows PatchGuard

In 2012, my colleagues Deepak Gupta and Xiaoning Li explained in a white paper how some malware can operate at the kernel level to bypass Microsoft’s security for 64-bit Windows systems.

Today a small utility program named KPP-Destroyer can be found online.
Previous versions of KPP-Destroyer had some bugs on a Windows 8.1 computer, but the fourth release, posted on July 1, seems fully operational. When you run the tools, it asks for the boot sequence you wish to patch. In my test computer (with secure boot disabled) I had three options and asked the tool to act on the current one.
After a reboot, I had a new entry (Windows 8.1 Patched) in my multiboot menu:
Running BCDEDIT, I saw some changes:
A flag nointegritycheck is enabled to disable integrity checks. The file d6gt2rg.exe has taken the place of winload.exe. The default kernel (ntoskrnl.exe) has been replaced by  sei2f4v4g9.exe.

  • When the flag nointegritycheck is enabled there is no warning when you attempt to install an unsigned driver. In this case, no integrity check allows the patched winload.exe to load. If you restore or disable the parameter (bcdedit /set nointegritychecks OFF) the boot fails and a blue screen explains the Automatic Repair process couldn’t repair your PC.
  • To keep the original winload.exe (Windows Boot Loader), the patched version is given a random name (d6gt2rg.exe in this case) and added to the boot process. Its job is to load the patched ntoskrnl.exe, the core part of Windows. During this task, a code integrity check point (ImgpValidateImageHash) must be skipped. The malware does this by changing five bytes.


- Three bytes at offset 42D94h (to avoid ImgpValidateImageHash)

- Two bytes in the file header to correct the PE checksum

  • Ntoskrnl.exe is also patched and saved under another random name (sei2f4v4g9.exe). To override the winload default selection of the kernel, the kernel option was set to point to the new filename.


In my test, three symbols for module ntoskrnl.exe were affected:


  • nt!SeCompareSigningLevelsForAuditableProcess
  • nt!SeValidateImageDataFP_BLOG_140728_8
  • nt!MiValidateSectionCreate (to bypass the return of the nt!SeValidateImageHeader call)FP_BLOG_140728_9

And finally, a single test with GMER alerting about numerous SSDT hooks proves that PatchGuard has been bypassed. (The following screen, from another test, shows the patched ntoskrnl.exe as 17h1kwrl4t.exe.)



Malware developers found ways to bypass PatchGuard for Windows 7, and now with this program we can see it is also possible to automate the job under Windows 8. Unfortunately, I am sure this process will be used in future malicious threats.


The post Malicious Utility Can Defeat Windows PatchGuard appeared first on McAfee.

Chinese military “hacked” Israel’s Iron Dome

Iron Dome

The technology behind Iron Dome, the missile defense system Israel has been using since 2011, was allegedly stolen by Chinese military hackers.

That claim was made by Cyber Engineering Services to Brian Krebs of security news site Krebs On Security, and it identifies Elisra Group, Israel Aerospace Industries (IAI), and Rafael Advanced Defense Systems as the three defense companies that were compromised during the cyber assault. The perpetrators, Cyber Engineering Services says, are the same ones behind a spate of attacks that have come to light in the past few years, all attributed to Unit 61398, a Shanghai-based arm of the Chinese army. The five Chinese military officers indicted by the US earlier this year for allegedly hacking energy firms in the country also belong to the same unit.

The hacks took place from October 2011, some six months after Iron Dome became operational, and continued up until August 2012. Israel Defense Forces (IDF) has said that many hundreds of rockets fired from Gaza, particularly during the current military operation and a series of clashes in 2012, have been scuppered by the system, which is thought to be one of the most effective missile-defense technologies in the world.

Read 7 remaining paragraphs | Comments

Instasheep: Coder builds tool to hijack Instagram accounts over Wi-Fi

This isn't the only way Instagram and sheep are related.
Sean Gallagher

Stevie Graham, a London-based developer, recently submitted a bug report to Facebook outlining what he saw as a security vulnerability in Instagram that would allow someone to hijack a user’s session based on data captured over a public Wi-Fi network. When he was told that he wouldn’t get a bug bounty from Facebook, which owns Instagram, he tweeted about it—and set about building a proof-of-concept tool to exploit it. “Denied bug bounty. Next step is to write automated tool enabling mass hijacking of accounts,” he wrote. “Pretty serious vuln, FB. please fix.”

As we reported in our recent coverage of mobile application privacy holes, Instagram uses HTTP for much of its communications, passing the user’s account name and an identifying account number in the clear. And as Graham demonstrated, there are other pieces of data sent between Instagram’s iOS client and the service that are passed in the clear. Even though the user’s credentials are submitted using a secure connection, information passed back by Instagram’s application interface to the phone client provides a cookie that can be used on the same network without reauthentication to connect via the Web to Instagram as that user and gain access to private messages and other data. “Once you have a cookie, any endpoint can be authenticated with the cookie, HTTPS or HTTP,” he wrote. Graham said that he has known about the flaw for years.

Graham posted the following steps to reproduce his findings:

Read 3 remaining paragraphs | Comments

Android crypto blunder exposes users to highly privileged malware

A slide from next week's Black Hat talk titled Android Fake ID vulnerability.
Bluebox Security

The majority of devices running Google's Android operating system are susceptible to hacks that allow malicious apps to bypass a key security sandbox so they can steal user credentials, read e-mail, and access payment histories and other sensitive data, researchers have warned.

The high-impact vulnerability has existed in Android since the release of version 2.1 in early 2010, researchers from Bluebox Security said. They dubbed the bug Fake ID, because, like a fraudulent driver's license an underage person might use to sneak into a bar, it grants malicious apps special access to Android resources that are typically off-limits. Google developers have introduced changes that limit some of the damage that malicious apps can do in Android 4.4, but the underlying bug remains unpatched, even in the Android L preview.

The Fake ID vulnerability stems from the failure of Android to verify the validity of cryptographic certificates that accompany each app installed on a device. The OS relies on the credentials when allocating special privileges that allow a handful of apps to bypass Android sandboxing. Under normal conditions, the sandbox prevents programs from accessing data belonging to other apps or to sensitive parts of the OS. Select apps, however, are permitted to break out of the sandbox. Adobe Flash in all but version 4.4, for instance, is permitted to act as a plugin for any other app installed on the phone, presumably to allow it to add animation and graphics support. Similarly, Google Wallet is permitted to access Near Field Communication hardware that processes payment information.

Read 8 remaining paragraphs | Comments