UDeck: USB Deck

Yesterday code was released for a USB pentest project, as presented at DEF CON 23 a few weeks ago by Dr. Phil Polstra, Professor of Bloomsburg University, at his talk: “One Device to Pwn Them All“.

The code uses Deck Linux, a pentest distro for the BeagleBone Black, and adds new scripts for USB pentesting.

Abstract: This talk will present a device that can be used as a dropbox, remote hacking drone, hacking command console, USB writeblocker, USB Mass Storage device impersonator, or scripted USB HID device. The device is based on the BeagleBone Black, can be battery operated for several days, and is easily constructed for under $100. The dropbox, remote hacking drone, and hacking command console functionality were presented at DEF CON 21. This talk will emphasize the new USB-based attack functionality. Topics will include injecting payloads by emulating an optionally write-protected USB mass storage device, rapidly executing commands on a target using the BeagleBone Black operating as a scripted USB HID device, USB mass storage device impersonation, and other attacks that can be performed with brief physical access to the target. Some familiarity with Linux and USB devices would be helpful, but not required. All hardware and software to be discussed is 100% open source.

Bio: Phil was born at an early age. He cleaned out his savings at age 8 in order to buy a TI99-4A computer for the sum of $450. Two years later he learned 6502 assembly and has been hacking computers and electronics ever since. Dr. Phil currently works as a professor at Bloomsburg University of Pennsylvania. His research focus over the last few years has been on the use of microcontrollers and small embedded computers for forensics and pentesting. Phil has developed a custom pentesting Linux distro and related hardware to allow an inexpensive army of remote pentesting drones to be built using the BeagleBone Black computer boards. This work is described in detail in Phil’s book “Hacking and Penetration Testing With Low Power Devices” (Syngress, 2015). Prior to entering academia, Phil held several high level positions at well-known US companies. He holds a couple of the usual certs one might expect for someone in his position. When not working, he likes to spend time with his family, fly, hack electronics, and has been known to build airplanes.

The UDeck or USB Deck is an addon to Deck Linux. Deck Linux is a pentesting Linux which was created for the BeagleBoard and BeagleBone family of devices and also for similar devices. Scripts include:
* mount-usb.sh: Exports a USB drive attached to the BBB as read-only to a PC which the BBB is plugged in to.
* mount-usb-rw.sh: Makes a drive previously exported with mount-usb.sh writeable.
* impersonator.sh: This will cycle through the VID/PID combinations in vidpid-list until it is killed. This allows you to bypass endpoint security software that filters based on VID/PID. If you know the appropriate VID/PID that should work you can easily modify this script to go directly to the appropriate VID/PID.
* create-hid.sh: This creates a scriptable USB HID keyboard device on the BBB. You could then send HID reports directly to this new device or you can use udeckHid.py to make this easy.
* udeckHid.py: This is defines a set of Python classes that make scripting a HID keyboard much easier. There is also an example Linux script in this file.
* attackWindows.py: This is an example of how the scriptable HID keyboard can be used under Windows.

https://github.com/ppolstra/UDeck
https://www.defcon.org/html/defcon-23/dc-23-speakers.html#Polstra
http://beagleboard.org/project/TheDeck/

http://www.philpolstra.com/
http://sourceforge.net/projects/thedeck/

Numato Opsis

A new USB-firmware-based open hardware product is being funded on CrowdSupply: Numato Lab’s Opsis, an FPGA-based HDMI2USB video capture device:

The Opsis was designed to run the HDMI2USB firmware developed by the TimVideos.us project. This firmware makes it easy to build automated conference/event recording systems. The HDMI2USB.tv firmware emulates a standard UVC webcam, allowing any video software, such as Skype, Google Hangouts, or WebRTC, to then send it to an online audience.

https://www.crowdsupply.com/numato-lab/opsis
http://hdmi2usb.tv/home/

Open Hardware talk from Chicago 2600 Meeting

Drew Fustini (@pdp7) gave a talk on Open Source Hardware at the Chicago 2600 meeting. Nice slides, I wish I could’ve attended. Lots of topics covered, OSHWA style license, mention of FSF’s Free Software, multiple projects, one book.

The Antivirus Hacker’s Handbook released

New book release:

The Antivirus Hacker’s Handbook
Joxean Koret, Elias Bachaalany
ISBN: 978-1-119-02875-8
September 2015

The Antivirus Hacker’s Handbook guides you through the process of reverse engineering antivirus software. You explore how to detect and exploit vulnerabilities that can be leveraged to improve future software design, protect your network, and anticipate attacks that may sneak through your antivirus’ line of defense. You’ll begin building your knowledge by diving into the reverse engineering process, which details how to start from a finished antivirus software program and work your way back through its development using the functions and other key elements of the software. Next, you leverage your new knowledge about software development to evade, attack, and exploit antivirus software—all of which can help you strengthen your network and protect your data.

http://www.wiley.com/WileyCDA/WileyTitle/productCd-1119028752.html

coreboot conference 2015 announced

What: coreboot conference 2015
When: October 9-11 2015 (after ELC-E)
Where: Bonn, Germany

Carl-Daniel Hailfinger announced the 2015 coreboot conference on the coreboot-announce list today. Excerpted announcement follows, see below URL for full details:

This conference and developer meeting is geared towards manufacturers of hardware (processors, chipsets, mainboards and servers/ laptops/ tablets/ desktops/ appliances) as well as developers of firmware with an interest in coreboot and the possibilities it offers as well as (potential) coreboot users. Both professionals and hobbyists are invited. The date of the coreboot conference is Friday October 9 to Sunday October 11, 2015. This is scheduled directly after Embedded Linux Conference Europe to make travel arrangements easier for people attending both events.
Call for presentations: We are looking for interesting talks/presentations about coreboot related topics for the first (and possibly second) day of the conference.
Call for discussion topics and development suggestions: We hope to stimulate discussion and foster new ideas as well as explore ways to improve code, development and deployment.
Call for profiles: This is the chance to tell others what you’re doing, what you can offer and in what area you’d like to collaborate.
Call for developers: If you want to do development all day, every day, just come and do it.

More Info:
http://www.coreboot.org/pipermail/coreboot-announce/2015-September/000021.html
http://coreboot.org/coreboot_conference_Bonn_2015

Rust and UEFI

Rust is a relatively new programming language.

Back in 2013, Eric Holk started adding UEFI support in Rust:
http://blog.theincredibleholk.org/blog/2013/11/18/booting-to-rust/
https://github.com/eholk/Boot2Rust

There’s also a 2014 UEFI Rust library by “project kernel”, which includes a UEFI boot loader, among other things:
https://github.com/project-kernel/uefi-lib
https://github.com/project-kernel/kernel

Starting last month, there’s another Rust UEFI library, by William Kunkel:
https://github.com/wkunkel/libuefi

I don’t know how to program in Rust yet, so I can’t say how usable Rust is with UEFI yet. The last library looks promising, perhaps more general-purpose than the previous projects, as far as I can tell. I guess I am going to have to learn Rust…

More Information:
https://www.rust-lang.org/

Lots of router vulnerabilities

CERT has been issuing a lot of warnings about insecure routers, I’m falling behind…

More Information:

http://www.kb.cert.org/vuls/

ACPI _DSD update

Early last month, the UEFI Forum updated this spec:

_DSD (Device Specific Data) Implementation Guide, v1.1
http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm

The main thing added to the above HTML document was a pointer to this spec:

Click to access _DSD-hierarchical-data-extension-UUID-v1.pdf

It describes a new Hierarchical Properties Extension UUID. I don’t know much about _DSD, it has been around for a while, so not sure if this 1.1 change is interesting or not.

I wish UEFI Forum would announce updates to ACPI specs. There web site has multiple press/news pages and RSS feeds, only a few of them are operational.

More Information:

http://uefi.org/acpi
https://lkml.org/lkml/2015/8/27/746

Bootloader article by .Bx

.Bx has a new article on boot loaders:

As a teaser here’s the first paragraph:

Welcome neighbors. In this blog I will be publishing notes I have taken on UEFI, BIOS, bootloading, ELF, and other technical topics that interest me and seem to lack documentation or explanation. I will also be keeping a list of UEFI, bootloading, and other resources I have found useful on my resources page. The rest of this post will be a whirlwind toure of bootloading and thus fairly introductory, so if you are already familiar with the world of bootloaders you might as well move on and read something else (although I would like to encourage you to look at the section where I propose new general bootloader terminology). In case you want to stick around for the full blog post I will be discussing: my motivations behind studying bootloading, bootloader terminology, how to navigate the plethora of bootloader implementations, specifications that relate to bootloading, BIOS, UEFI, and how they came to be, and how to write a simple boot sector.

Full post:

http://www.cs.dartmouth.edu/~bx/blog/2015/09/03/a-toure-of-bootloading.html

tool: Edb

Edb is a system debugger, written by Evan Teran (@eteran). It’s been around for a while, but recently updated to use the Capstone engine, where I noticed it:

Edb is a cross platform x86/x86-64 debugger, inspired by OllyDbg, but aims to function on x86 and x86-64 as well as multiple OS’s. Linux is the only officially supported platform at the moment, but FreeBSD, OpenBSD, OSX and Windows ports are underway with varying degrees of functionality. It is written in C++ using Qt. It contains these plugins: Analyzer, Assembler, BinaryInfo, BinarySearcher, Bookmarks, BreakpointManager, CheckVersion, DebuggerCore, DumpState, FunctionFinder, HardwareBreakpoints, HeapAnalyzer, OpcodeSearcher, ProcessProperties, ROPTool,References, and SymbolViewer.

Some security researchers may not know of OllyDbg, but only of Immunity Debugger (ImmyDbg), which is a fork of the GPL OllyDBg (but Immunity doesn’t seem to provide source…). Edb is also GPL-licensed, but source is easily available, and with Capstone backing it, looks to be very interesting!

https://github.com/eteran/edb-debugger
https://github.com/eteran/edb-debugger/wiki

Open Hardware updates

One problem with being a small hardware vendor is keeping supply in stock. Bunnie Studios’s Novena, or Purism’s  Librem, or Inverse Path’s  USB Amoury, all IMO 3 leaders of the Open Hardware movement, are all currently in stock, or are restocking, or have a few left. Novena has a handful of laptops remaining, Librem v2 has a few days remaining for current funding program, and USB Armory is getting restocked. To paraphrase an open source term, for open hardware use: “Buy early, buy often.” 🙂

ACPI testing with BITS Python

Recently, Josh Triplett of Intel gave a talk on using BIOS Interface Test Suite (BITS) at LinuxCon North America.
http://events.linuxfoundation.org/events/linuxcon-north-america/program/slides

Demystifying ACPI and EFI via Python and BITS

Click to access bits-with-demo.pdf

BTW, Josh also gave this talk at LinuxConNA’15 as well:

Everything’s a File Descriptor

Click to access fd_0.pdf

I think I’ve mentioned BITS in this blog before. But just in case I’ve not, BITS is a powerful, strange set of BIOS diagnostic tools. BITS started as a BIOS-centric tool, but now includes some UEFI support as well. BITS uses the GRUB boot manager as it’s UI, using GRUB menus for different features, see the screenshots page for a better understanding:
http://biosbits.org/screenshots/

BITS also includes a Python interpreter, so you can do interactive Python, or write scripts to test firmware. BITS has interfaces for BIOS, UEFI, and ACPI data.
http://biosbits.org/scripting/

Jake Edge wrote an excellent follow-up to Josh’s LinuxCON talk, with an article in LWN.net, discussing BITS’s Python for UEFI and ACPI investigations.

In a talk that could easily be seen as a follow-on to his PyCon 2015 talk, Josh Triplett presented at LinuxCon North America on using Python to explore the low-level firmware of today’s systems. The BIOS Implementation Test Suite (BITS) provides an environment that hearkens back to the days of BASIC, PEEK, and POKE, as he demonstrated at PyCon in Montréal in April, but it is much more than that. In Seattle at LinuxCon, he showed that it can also be used to look at and use the EFI and ACPI code in a system—all from Python.

The article is part of LWN.net subscriber-only content, and has been ‘leaked’ (see next URL below), and as the link on the page mentions, an occasional leak isn’t too bad, and helps with subscriptions. If you don’t have a LWN subscription, please think about it, they are probably the best news source for low-level Linux technologies. They have a 1-month free trial.

After reading this article, Laszlo Ersek of Red Hat started up a thread with Josh on the QEMU and UEFI dev mailing lists, with some new ways of thinking about using BITS Python for ACPI testing. Lots of good ideas on this thread, if you care about QEMU, ACPI, AML, or ACPICA tools please read the thread: sorry, I’m too lazy to summarize all of the ACPI nuances in the thread, it’s only a few messages.

Using Python to investigate EFI and ACPI
Newsgroups: gmane.comp.emulators.qemu, gmane.comp.bios.edk2.devel
http://thread.gmane.org/gmane.comp.emulators.qemu/358997

I hope some of the ACPI/AML testing ideas in this thread happen!

More Information:

https://github.com/biosbits/bits

Intel porting KGT to UEFI

The other day I learned about Intel KGT:

Intel KGT

Then I noticed Matthew Garrett’s twitter feed, saying that it didn’ t work with UEFI… But today I note that Vincent Zimmer of Intel has a new Twitter post,  saying that Intel is working on porting KGT to work with UEFI:

Looking forward to UEFI-enabled iKGT!

tool: ReadPhysMem

Found on the Twitter feed of the The EFI Monster (@osxreverser):
https://twitter.com/osxreverser/status/639452846090551296

ReadPhysMem is a small utility to read and write to Macs physical memory using default AppleHWAccess.kext. Quoting the readme:

(c) fG! – 2015 – reverser@put.ashttps://reverse.put.asA small utility to read and write to Macs physical memory using default AppleHWAccess.kext.

This kext is loaded by default on Mavericks and Yosemite. It has (finally) been disabled on El Capitan since beta 7 release, since it was a obvious way to bypass and disable the new rootless protection 😉

Trammell Hudson wrote a similar utility using DirectHW.kext (also blacklisted on El Capitan B7). Available at https://github.com/osresearch/rwmem.

The same warning as rwmem applies here. Use with caution, it can easily kernel panic your machine both on reads and writes (particularly on devices mapped areas, SMM ram, etc). If you already know PCI BAR addresses you need to use 4 bytes read size instead of default 8.

It works great to read kernel and other memory, and also BIOS (since it’s mapped/shadowed in physical memory). See also https://github.com/gdbinit/diagnostic_service2 for a real world rootkit application.

DirectHW.kext is a bit more powerful since it allows to read port info. AppleHWAccess.kext only implements memory reads and not ports. For example, it can’t be used to read PCI configuration.

Have fun,

fG!

https://github.com/gdbinit/readphysmem

Seagate, LaCie hard drive vulnerabilities, firmware update available

Found on the Twitter feed of Frank Denis:

Note there is a firmware update. See the full Vulnerability Note, excerpted below:

http://www.kb.cert.org/vuls/id/903500

Vulnerability Note VU#903500
Seagate wireless hard-drives contain multiple vulnerabilities

Last revised: 02 Sep 2015

Multiple Seagate wireless hard-drives contain multiple vulnerabilities.

CWE-798: Use of Hard-coded Credentials – CVE-2015-2874
Seagate wireless hard-drives provides undocumented Telnet services accessible by using the default credentials of ‘root’ as username and the default password.

CWE-425: Direct Request (‘Forced Browsing’) – CVE-2015-2875
Under a default configuration, Seagate wireless hard-drives provides an unrestricted file download capability to anonymous attackers with wireless access to the device. An attacker can directly download files from anywhere on the filesystem.

CWE-434: Unrestricted Upload of File with Dangerous Type – CVE-2015-2876
Under a default configuration, Seagate wireless hard-drives provides a file upload capability to anonymous attackers with wireless access to the device’s /media/sda2 filesystem. This filesystem is reserved for the file-sharing.

These vulnerabilities were confirmed by the reporter as existing in firmware versions 2.2.0.005 and 2.3.0.014, dating to October 2014. Other firmware versions may be affected. The following devices are impacted by this issue: Seagate Wireless Plus Mobile Storage, Seagate Wireless Mobile Storage,  and LaCie FUEL. Impact: A remote unauthenticated attacker may access arbitrary files on the harddrive, or gain root access to the device. Solution: Update the firmware.  Seagate has released firmware 3.4.1.105 to address these issues in all affected devices. Affected users are encouraged to update the firmware as so on as possible. Customers may download the firmware from Seagate’s website. Seagate encourages any customer encountering issues to contact customer service at 1-800-SEAGATE.

https://apps1.seagate.com/downloads/request.html
http://knowledge.seagate.com/articles/en_US/FAQ/207931en
http://cwe.mitre.org/data/definitions/425.html
http://cwe.mitre.org/data/definitions/434.html
http://cwe.mitre.org/data/definitions/798.html

Arium, ASSET InterTech, and Intel IE

Though I’ve discussed some Intel UEFI debugging so far:

Low-cost UEFI debugging options for Intel


I’ve not mentioned Arium’s debugger yet. The Intel Tunnel Mountain UEFI dev board can be used with the Intel UDK Debugger Tool, a 2-system debugging solution that uses Windbg on Windows, GDB on Linux. If you want to trace into silicon, you need to buy some debugging hardware, and a debugger that works with that hardware. One solution is to use Arium’s ITP widget and their debugger. It is EXPENSIVE, so you have to be well-funded to have one of these units, but I’ve heard it is powerful. They have products for ARM and Intel.

ASSET InterTech acquired Arium a while ago, though I still think of them as Arium. 😦

The other week at Intel IDF, Intel announced the Innovation Engine (Intel IE), but no details yet, except for this blog post:

Intel’s new Innovation Engine

ASSET just blogged about updating their product to support Intel IE, excerpt here:

At this past Intel Developers Forum (IDF) in San Francisco, Intel unveiled some preliminary information on the new Innovation Engine (IE). In a nutshell, the IE is an embedded processor which allows system builders and their partners to build unique, differentiating firmware for server, storage, and networking markets. Differentiation has always been, and always will be, a key challenge for OEMs in the Intel space. Hardware, in and of itself, is very common across platforms designed with Intel silicon. There can be some differentiation based upon using some custom Intel SKUs (if you are a large enough customer), or designing circuit boards which deviate from the platform design guideline recommendations, but these come at a high cost – either in terms of Bill of Materials (BOM) cost, or risk of having a product with lower overall operating margins. Competitive advantage on Intel designs often comes from the embedded firmware, either the BIOS or the Baseboard Management Controller (BMC) code. And in the server world, OEMs are often beholden to the UEFI vendors for customization. So OEMs often invest in customization of system management to create differentiation – which is where the IE comes in. The IE can supplement or replace much of the functionality that may exist on today’s BMCs. In addition, for lower-end systems that may not require BMCs, the IE can provide a platform which delivers system management capabilities at no extra BOM cost. In Intel’s words, “some possible uses include hosting lightweight manageability features in order to reduce overall system cost, improving server performance by offloading BIOS and BMC routines, or augmenting the Intel® Management Engine for such things as telemetry and trusted boot.”

I’m waiting for Intel to release real information on their Innovation Engine.

Read the full ASSET blog post here, to see how they are using Intel IE with their diagnostic products:

http://blog.asset-intertech.com/test_data_out/2015/08/intel-innovation-engine-with-scanworks-embedded-diagnostics.html

http://arium.com/

Home