cemu – Cheap EMUlator: Qt GUI of Keystone, Unicode, Capstone

Hugsy has created cemu, the Cheap EMUlator that shellcoders will enjoy:

Cheap EMUlator is a simple tool to combine together all the features of Keystone, Unicorn and Capstone engines in a Qt powered GUI. It allows to test binary samples, check your shellcodes or even simply learn how to write assembly code, all of this for the following architectures:

    x86-32 / x86-64
    Arm / AArch64
    MIPS / MIPS64
    SPARC / SPARC64
    (more to come)

Pre-Requisites:
    unicorn and its Python bindings, as the emulation engine
    keystone and its Python bindings, as the assembly engine
    capstone and its Python bindings, as the disassembly engine
    PyQt5 for the GUI
    pygments for the text colorization

Moar info:
https://github.com/hugsy/cemu

 

QEMU 2.6.0 released

QEMU 2.6.0 has been released. A few highlights include:

  * Headless support for OpenGL-capable displays via Virgil/virtio-gpu are now available via Spice client.
  * Support for IPMI through internally emulated BMC or an external BMC interface
  * PCIe multi-root support via pxb-pcie bridge, allowing devices to be exposed to guest on specifically-defined NUMA nodes
  * x86: KVM and TCG emulation support for PKU memory protection feature of newer Intel CPUs within guest

http://article.gmane.org/gmane.comp.emulators.qemu/410994
http://wiki.qemu.org/Download
http://wiki.qemu.org/ChangeLog/2.6

fwexpl – PC Firmware Exploitation Tool and Library

Dmytro Oleksiuk (aka Cr4sh) has a VERY INTERESTING new firmware tool for Windows

PC firmware exploitation tool and library

Project includes the following components:
 * libfwexpl — Hardware abstraction library for Windows (see include/libfwexpl.h).
 * libdsebypass — Windows x64 DSE bypass exploit based on Secret Net 7.4 0day privileges escalation vulnerability (see include/libdsebypass.h).
 * driver — Kernel mode part of libfwexpl.
 * application — Application that implements System Management Mode code execution exploit for 1day vulnerability in SystemSmmAhciAspiLegacyRt UEFI SMM driver of Lenovo firmware.

Options:
  –target <N> — Select known target where <N> is a target number. If –target and –target-addr options are not specified — exploit will use heuristics to find EFI_BOOT_SERVICES structure address that neccessary for SystemSmmAhciAspiLegacyRt driver vulnerability exploitation.
  –target-list — Print all known targets information.
  –target-addr – Use manual address of EFI_BOOT_SERVICES.LocateProtocol field for SystemSmmAhciAspiLegacyRt exploit. This option will be ignored if –target was specified.
  –target-smi – Use manual SMI handler number for SystemSmmAhciAspiLegacyRt exploit. This option will be ignored if –target was specified. If –target-addr was specified without –target-smi — SystemSmmAhciAspiLegacyRt exploit will check all of the possible SMI handlers from 0 to 255.
  –smram-dump — Determinate current SMRAM address and dump it’s contents to file specified by –file option.
  –phys-mem-dump — Full raw physical memory dump into the file specified by –file option.
  –phys-mem-read <addr> — Read physical memory starting from specified address.
  –phys-mem-write <addr> — Write physical memory starting from specified address.
  –length <bytes> — Number of bytes to read or write for –phys-mem-read and –phys-mem-write.  
  –file <path> — Memory dump path to read or write, in case of –phys-mem-read this parameter is optional and when it’s not specified — application will print a hex dump of physical memory to stdout. In case of –smram-dump this parameter is mandatory.
  –exec <addr> — Execute SMM code at specified physical memory address.
  –dse-bypass — Install and exploit Secret Net 7.4 driver to bypass Windows x64 DSE.  
  –test — Run some basic libfwexpl tests.

To learn more about this project please read his blog post, “Exploiting SMM callout vulnerabilities in Lenovo firmware”:
http://blog.cr4.sh/2016/02/exploiting-smm-callout-vulnerabilities.html

https://github.com/Cr4sh/fwexpl

UFS Erase Block command added to UEFI

Hao Wu of Intel added Erase Block support to UFS (Universal Flash Storage) devices. Since UFS uses SCSI model in UEFI, the SCSI Unmap command was also added, but SCSI Unmap is not fully-implemented for SCSI devices, only for UFS Erase Block support.

[PATCH 0/2] Add Erase Block Protocol support for UFS devices

This patch series add the Erase Block Protocol implementation for UFS devices. Since the UFS transport layer follows the SCSI architecture, therefore, the implementation is added in the ScsiDiskDxe driver.

MdePkg IndustryStandard/Scsi.h: Add Unmap command support
MdeModulePkg ScsiDiskDxe: Add Erase Block Protocol support for UFS devices

For more information, see the patch on the EDK2-devel list, see the UFS 2.0 spec (including section 11.3.9.2). Hmm, unless I’m misreading things, the UFS spec is for members only, not public. 😦

https://lists.01.org/mailman/listinfo/edk2-devel
http://news.gmane.org/gmane.comp.bios.edk2.devel
http://search.gmane.org/search.php?group=gmane.comp.bios.edk2.devel&query=UFS
https://en.wikipedia.org/wiki/Universal_Flash_Storage

Universal Flash Storage (UFS) support added to UEFI

Rowhammer for AMD

A Tale of Two Hammers: A Brief Rowhammer Analysis of AMD vs. Intel
May 2016
Mark Lanteigne, CTO and Founder, Third I/O Inc.
This is the first addendum to Third I/O’s March 2016 Rowhammer report.

 

Click to access rowhammera1.pdf

Click to access rowhammer.pdf

Microsoft’s new Security Auditing and Monitoring Reference

Microsoft has published a new  guide on Windows’ security events. It’s a 700+ page doc!

Windows 10 Security Auditing and Monitoring Reference V1

You can record and store security audit events for Windows 10 to track key system and network activities, monitor potentially harmful behaviors, and mitigate risks. You control the amount of data you collect by controlling the categories of security events you audit, for example, changes to user account and resource permissions, failed attempts to access resources, and attempts to modify system files. The reference in this download can help you decide what to monitor and how to interpret the data you collect.

https://www.microsoft.com/en-us/download/details.aspx?id=52630

 

 

IPMIPWN

IPMIPWN came out 2 months ago and I missed it. 😦 IPMIPWN’s readme excerpt:

IPMI cipher 0 attack tool

There are a few good tools out there (Metasploit) to help you find and identify the IPMI cipher 0 vulnerability, but because its relatively trivial to exploit I have seen nothing that helps you pwn it. While it is easy to exploit, I have found I keep having to brush up on commands and junk every time I come across it which is where my tools comes in. My IPMIPWN tool does all the real work for you, it will attempt to exploit the cipher 0 vulnerability using a list of predefined default user accounts and setup an backdoor account with a semi-random username and random password. All successful backdoors are logged in loot.log. This tool works best on Kali, it does require you to have ipmiutils “apt-get install ipmitool” and NMAP installed. Enjoy.
https://github.com/AnarchyAngel/IPMIPWN

Besides IPMIPWN, and Metasploit, the tools FreeIPMI and IPMItool are also worth checking out. There is an IPMI Util  tool for Windows, and an Intel IPMI tool for MS-DOS, both of which I have not tried out.
https://sourceforge.net/projects/ipmitool/
http://www.gnu.org/software/freeipmi/
http://ipmiutil.sourceforge.net/
http://www.intel.com/design/servers/ipmi/ipmi_tool.htm

If you are new to IPMI security, start here:
https://www.us-cert.gov/ncas/alerts/TA13-207Ahttps://search.us-cert.gov/search?utf8=%E2%9C%93&affiliate=us-cert&query=IPMI&commit=Search
https://community.rapid7.com/community/metasploit/blog/2013/07/02/a-penetration-testers-guide-to-ipmi
http://fish2.com/ipmi/
http://www.cisco.com/c/en/us/about/security-center/ipmi-vulnerabilities.html

UEFI Secure Boot exploit for Windows Surface??

A kind reader of this blog pointed this out to me:

It appears that Longhorn has a UEFI exploit, related to Windows surface devices. I’m not sure yet if it requires ARM or Intel system, and I don’t know the details of the exploit, it appears that it has not been released.

https://twitter.com/never_released/status/723144680507117568
https://twitter.com/never_released/status/723146681940738055
https://twitter.com/never_released/status/724506763240833025
https://twitter.com/never_released/status/725355698431905793
https://twitter.com/never_released/status/725355698431905793
https://twitter.com/never_released/status/725034729599307777
https://twitter.com/never_released/status/724984950584446976
https://twitter.com/never_released/status/724506763240833025
https://twitter.com/never_released/status/723896207475675136
https://twitter.com/never_released/status/723796480281182208

Intel OpenCIT 2.0.7 released

Adolfo V Aguayo of Intel announced the 2.0.7 release of OpenCIT  (Open Cloud Integrity Technology) library. The first time I’ve heard of OpenCIT, and they’re already at a 2.x release. 😦 Excerpted announcement:

Open CIT is the next generation attestation solution.  Open CIT provides features and capabilities in its entirety, as was made available in the Premium version, including support for ESX and Citrix-Xen, in addition to KVM on Ubuntu and RHEL.  Open CIT provides ‘Trust’ visibility of the cloud infrastructure and enables compliance in cloud datacenters.  The solution leverages Intel processors with Intel® Trusted Execution Technology (Intel® TXT) to establish HW root of trust and builds the chain of trust across hardware, OS, hypervisor and including asset tagging for Location and boundary control.  The Platform trust and asset tag attestation information is used by Orchestrators and/or Policy Compliance management to ensure workloads are launched on trusted and location/boundary compliant platforms, and they provide the needed visibility and Auditability of your infrastructure in both public and private cloud environments.

We are proud to announce the release of Open CIT. Open CIT provides features and capabilities in its entirety, as was made available in the Premium version, including support for ESX and Citrix-Xen, in addition to KVM on Ubuntu and RHEL.  OpenCIT provides ‘Trust’ visibility of the cloud infrastructure and enables compliance in cloud datacenters. Below are the key features for Open CIT:
– Establish chain of trust of BIOS, firmware, OS kernel & hypervisor by verifying against configured good known values (Whitelists)
– Ability to tag/verify hosts with custom attributes (Asset Tags) stored in TPM. Ex: Location attributes
– Open Stack integration to utilize Platform Trust and asset tags for advanced VM management
– Mutual SSL authentication supported across all the communication channels.
– RESTful API interface for easier 3rd party integration
– Audit logging for all changes including tracking of the host trust status changes
– Self-extracting installers for ease of setup & Reference UI portal
– User defined TLS policy management for host’s connections.

Distributions currently supported and the Open Stack version used for our extensions:
– Linux distributions: Ubuntu 12.04 LTS, 14.04 LTS, RHEL 6.5 and 7.x, on KVM
– OS platforms that are supported for remote attestation: Citrix XenServer 6.2, VMWare ESXi 5.5, 6, Ubuntu 12.04 LTS, 14.04 LTS, RHEL 6.5 and 7.x,
– Open Stack extensions supported: Kilo & Liberty.

https://github.com/opencit
https://01.org/opencit

For more information, see the OAT-devel post:
https://lists.01.org/mailman/listinfo/oat-devel

Is there a Firmware Exploit Database?

Is there a firmware exploit database? If you know of any, please leave a Comment to this blog!

The Debian project just started collecting a list of public exploits that can be used for jailbreaking locked-down devices:
https://wiki.debian.org/Exploits

The UEFI Forum maintains a list of EDK2 exploits, but those are over a year old, nothing recent, and they don’t cover OEM-centric variations.
https://github.com/tianocore/tianocore.github.io/wiki/Security
https://sourceforge.net/projects/edk2/files/Security_Advisory/

The Exploit Database is pretty large, but not firmware-centric. However, many of the app exploits that get root on a device often count as firmware exploits.
https://www.exploit-db.com/
https://twitter.com/exploitdb/with_replies

Dangerous Prototypes’ Dirty Decapper

Dangerous Prototypes has a decapper for sale:

http://dev.dangerousprototypes.com/store/decap

[…] This isn’t a $5,000 super high resolution decapping, this is Dirty Decapping. Chip decapping is now available to the masses! The top of the chip is etched away, generally with nitric acid based nasties, to reveal the die and bonding wires. A series of medium resolution photos are taken through a microscope and stitched together. The resulting image is clear enough to verify a chip’s identity, and generally determine different areas on the die. You definitely won’t be able to identify individual gates or reverse engineer the chip, for that you need to find a $5,000+ high quality service. Be sure to check if this real example will suit your needs before ordering. […]

SuSE adds BIOS/UEFI to their certification bulletins

Drew of SuSE has a new blog post clarifying UEFI -vs- BIOS:

SuSE even has a certification program, as this blog mentions:

“[…] All YES CERTIFICATION bulletins list how the hardware and operating system were configured and tested during certification. On a bulletin, under the tested configuration section there is a BIOS/UEFI line, it will list either UEFI, BIOS or UEFI-Legacy. This indicates how the system was configured and tested. It then lists the version and date of the system firmware installed on the hardware. […]”

This certification program doesn’t cover [implementation differences in] UEFI Secure Boot. While the current change in their certification — to clarify if system has a UEFI class 1-3 firmware — is nice, what would be USEFUL would be to list CHIPSEC version and a list a list of which security modules it fails. And the results of FWTS’s tests (does Canonical’s FWTS build on SuSE?). When a system is tested, I’d like to see the test results, please. And does this mean that SuSE will not ship any coreboot- or U-Boot-based systems, but always UEFI/BIOS-based ones? Given how crucial firmware is to a system, I am amazed at how little consumers care about this information. I guess I should be happy SuSE is giving 1-line of data to firmware. I’d like a paragraph.

 

https://www.suse.com/communities/blog/comparison-uefi-bios-operating-system-perspective/