From September:
https://twitter.com/jjstevensjj/status/660175493023559681
http://centrifuge.tacnetsol.com/
I can’t find any presentations or documentation about Centrifuge. If you spot any, please leave a Comment (see left of page). Thanks.
Month: January 2016
MyROP: new ROP tool for ARM
Hitmoon has created MyRop, a ROP tool based on Capstone that targets ARM systems.
Ubuntu’s UEFI Secure Boot: not a security measure
[[UPDATE: As Teddy Reed points out, this information is in the Ubuntu wiki, not just in a Ubuntu bug report:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532
“IMPORTANT: Canonical’s Secure Boot implementation in Ubuntu 15.10 and early is primarily about hardware-enablement and this page focuses on how to test Secure Boot for common hardware-enablement configurations, not for enabling Secure Boot to harden your system. If you want to use Secure Boot as a security mechanism, an appropriate solution would be to use your own keys (optionally enrolling additional keys, see above) and update the bootloader to prohibit booting an unsigned kernel. Ubuntu 16.04 LTS is planned to enable enforcing secure boot (see LP: #1401532 for details). “]]
Research the implementation of UEFI Secure Boot by a Linux/FreeBSD distro before presuming to rely on it to provide any security. 😦
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1475954/comments/1
CanSecWest firmware training!
CanSecWest is around the corner, and some of the training has been announced.
The USB Armory group is giving a day of TrustZone training.
John Butterworth, one of the group of MITRE BIOS researchers — along with LebaCore — who created Copernicus, is giving FOUR days of UEFI training! I am not sure I’ve seen John offer BIOS/UEFI training for a while, so this is exciting!
https://cansecwest.com/dojo.html
March 15, Mastering ARM TrustZone with USB armory by Andrea Barisani & Andrej Rosano
March 12-13, UEFI BIOS Platform Security2 Understanding Attacks and Defense by John Butterworth
March 14-15, UEFI BIOS Platform Security: Understanding Attacks and Defense by John Butterworth
EDK II specifications updated
Laurie Jarlstrom of Intel has announced a documentation update to the UEFI Forum’s EDK II Specifications:
“Announcing the V1.25 and V1.26 updates to the EDK II Specifications. Go to the EDK II Specifications page to download the latest documentation.”
These are the specs beyond the UEFI Forum’s PI and UEFI specs, focused on development implementation details of Tianocore’s EDK-II.
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications
http://article.gmane.org/gmane.comp.bios.edk2.devel/6371
ADVDroid
Firmware and RISC-V workshop
At the 3rd RISC-V Workshop, there have been presentations by coreboot and UEFI. The below blog has some notes on these presentations:
http://riscv.org/workshop-jan2016.html
http://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-one/
Apparently, someone is porting UEFI to RISC-V. I wonder what company is funding/doing it??
How GRUB works
0xAX has a new blog post, discussing how GRUB works.
It is a nicely-detailed blog post, one day I wish I hope to be able to have blog posts with such rich content.
http://0xax.github.io/how-does-gnu-grub-work.html#.VovK1179mV4
Pau Oliva: UnTrusted Execution Environments
Pau Oliva has a presentation at NO CON NAME 2015 on Untrusted Execution Environments, presentation slides and video available online. Focus appears to be mostly ARM-centric. Presentation video is in Spanish.
Vimeo.com URL:
SysInternals tools updated
SysIntenals, now acquired by the Microsoft TechNet team, has some new tool announcements:
Sigcheck v2.4
Sysmon v3.2
Process Explorer v16.1
Autoruns v13.51
AccessChk v6.01
TCG blog on IoT security
The Trustworthy Computing Group has a new blog post, talking about IoT security, specifically about Industrial IoT Security Working Group involvement.
http://www.iiconsortium.org/wc-security.htm
GPU security
Someone just pointed out that Mozilla Firefox treats GPUs differently when it uses WebGL:
https://hg.mozilla.org/mozilla-central/file/tip/widget/windows/GfxInfo.cpp#l817
This got me thinking how little I know about GPU security. 😦
There’s a bit on GPU security in the August Intel security report:
http://www.securityweek.com/gpu-malware-not-difficult-detect-intel-security
Click to access rp-quarterly-threats-aug-2015.pdf
I noticed the tool Cryptohaze, but it appears to have not been updated since 2013 or so:
http://www.cryptohaze.com/
http://blog.cryptohaze.com/
http://sourceforge.net/projects/cryptohaze/files/
“Cryptohaze is the home of high performance, open source, network-enabled, US-based cross-platform GPU and OpenCL accelerated password auditing tools for security professionals. The tools run on all platforms that support CUDA or OpenCL (currently Windows, Linux, OS X). If you don’t have a GPU – the OpenCL code will run just fine on your host CPU!”
If you know of other useful GPU security tools, please speak up!
BITS: new network-enabled release (and new mailing list)
Burt Triplett of Intel has announced the version 2070 release of BITS (BIOS Implementation Test Suite). The main new feature is network support, but also includes new UEFI and ACPI and Python features, better command line features, and other new features. I’ve just excerpted the first paragraph of the networking-centric portion of the announcement below, there are a lot of implementation caveats to read. See the full announcement for the list of features and bugfixes.
Note that there is also a new BITS mailing list, see below URL for ‘first post’ message in the archives:
BITS on EFI now supports TCP networking, using the Python socket module and various modules built atop it. On EFI systems that provide `EFI_IP4_CONFIG_PROTOCOL` and `EFI_TCP4_SERVICE_BINDING_PROTOCOL`, we implement a `_socket` module in Python with support for TCP sockets over IPv4. We then include Python’s higher-level socket module that runs on top of `_socket`.
https://lists.01.org/mailman/listinfo/bits
https://lists.01.org/pipermail/bits/2016-January/000000.html
http://biosbits.org/news/bits-2070/
http://biosbits.org/downloads/bits-2070.zip
https://github.com/biosbits/bits
screenshot-taking UEFI DXE driver
Nikolaj has written a UEFI DXE driver that takes screenshots. In addition to a useful new UEFI tool (since taking pre-OS screenshots outside of a VMM are often a PITA), the article is a nice introduction to EFI development. Attackers can use techniques like this to capture display activity in the background, just like they do in OS-level malware.
UEFI DXE driver to take screenshots from GOP-compatible graphic console: This DXE driver tries to register keyboard shortcut (LCtrl + LAlt + F12) handler for all text input devices. The handler tries to find a writable FS, enumerates all GOP-capable video devices, takes screenshots from them and saves the result as PNG files on that writable FS. The main goal is to be able to make BIOS Setup screenshots for systems without serial console redirection support, but it can also be used to take screenshot from UEFI shell, UEFI apps and UEFI bootloaders.
See the readme and the blog post (in Russian) for more information:
https://github.com/NikolajSchlej/CrScreenshotDxe
FreeBSD’s 2015 UEFI update
From the FreeBSD Foundation’s December 2015 (end-of-year) update, in summarizing their development efforts, they mention firmware (as well as improvements to x86 hardware support, and AArch64 support):
UEFI and secure boot: FreeBSD’s UEFI boot support needs to interoperate with many different EFI firmware implementations, and it’s only after broad testing that we were able to identify some incompatibilities. Through effort from Foundation staff and from volunteers in the FreeBSD community we’ve fixed UEFI boot on a variety of hardware and virtualization platforms, including Apple Macbook and Mac Pro computers and VirtualBox and VMware. These improvements will be available in FreeBSD 11.0 and 10.3. We also started working on support for secure boot. To date we’ve been working on individual tools — the uefisign(8) utility to add Authenticode signatures to EFI files, and the sysutils/pesign, sysutils/sbsigntool and sysutils/shim ports. Next year we’ll integrate these components into a broader secure boot implementation.
More information: click on the tiny-URL PDF in the below tweet:
EFI_BruteForce: EFI PIN of Apple MacBooks
I just noticed an old article and tool by Kooftness, for brute-forcing the (or an) Apple EFI firmware password. As I understand the article, the original code didn’t generate results while they had access to the laptop, but since then the code has been revised (7 months ago) and others claim success with the code. I am unclear if this is a 3rd party PIN tool or the main Apple Firmware Password feature.
These Teensyduino sketches (for Teensy embeded boards) and shell scripts are tools to bruteforce EFI or iCloud locks.
Recently I got my hands on a MacBook Pro that after three weeks of being bought the seller desided that he wanted it back. He expressed this by locking it with a 4 digit PIN and a message that stated “Give me back the laptop and give you back the money”, with out calling or anything. […] I was told that an alternative solution would be to get a fresh MBP, extract its firmware and flash it using a PIC programmer. He also told me that there are ways to get around this attacking the thunderbolt port but these two options have a high risk in bricking the $2.000 laptop. […] I have received confirmation that this code is working, as we can see in this thread at MacRumors […]
http://orvtech.com/atacar-efi-pin-macbook-pro-en.html
https://github.com/Kooftness/efi_bruteforce
https://github.com/Kooftness/efi_bruteforce/blob/master/efi_attack_modifyed
https://support.apple.com/en-us/HT204455
https://support.apple.com/en-us/HT203409
“If you can’t remember the firmware password for your Mac, schedule a service appointment with an Apple Retail Store or Apple Authorized Service Provider.”
It appears that any current/former Apple Store “genius” can most likely bypass the Apple Firmware Password protection. 😦 I suppose any vendor who can reset the PIN can use it like the above merchant, to blackmail the customer for access to their device.
I look forward to seeing the results of LegbaCore working at Apple …though I am afraid that their new models will become less configurable, more like modern Windows boxes, unable to run anything but Apple-approved OSes and pre-OS code (eg, rEFInd).
Ultrasoc diagnostic hardware
It appears Ultrasoc has some hardware-level diagnostic abilities that will be interesting to some:
http://electronicdesign.com/blog/turning-debug-hardware-based-iot-security
“Our products allow engineers to look inside systems-on-chip (SoCs) during the development process, and understand exactly how they operate under real-life conditions. Development teams are using our on-chip monitoring and analytics IP to equip their SoCs with an exciting range of new capabilities, applicable in markets from network infrastructure to mobile phones, and from safety-critical systems to the Internet of Things (IoT). These include value-add functions such as service level agreement (SLA) enforcement and in-service performance enhancement – functionality enabled by chips with hard-wired self-monitoring capabilities. UltraSoc’s “smart” modules operate across the whole SoC: reporting rich information in real-time, non-intrusively, from hardware and software. And because the system is vendor-neutral, it provides an efficient way to integrate IP from different vendors, into one coherent framework, including legacy solutions or in-house custom logic.”
ARM TrustZone support for QEMU
“Experimental version of QEMU with basic support for ARM TrustZone (security extensions)”
VirtualKD 3.0 released
If you do Windows kernel debugging in VMWare/VirtualBox VMs, and don’t know about VirtualKD, this will be exciting for you:
http://securityblog.gr/3092/faster-windows-kernel-debugging-with-virtual-machines/
IOKit-Dumper
OS X tool for dumping and reconstructing the IOKit classes hierarchy. iokit-dumper directly generates DOT files (see here, which can then be processed with dot tool. Keep in mind this tool is in its early release, so stuff may happen. Also, careful when playing with the code, since a wrong read in the kernel will cause a kernel panic. Remember to always slide kernel addresses before reading from them.
Firmware Security 
“Ubuntu’s support for secure boot is solely intended as a compatibility measure so that media can boot on secure boot enabled computers. There are no current plans to enable secure boot as a security measure.”