Category: Uncategorized

ss7MAPer: SS7 pentest toolkit

~ hucktech ~ Leave a comment

ss7MAPer – A SS7 pen testing toolkit

While running some SS7 pentests last year, I developed a small tool automating some of the well-known SS7 attack cases. Today I’m releasing the first version of ss7MAPer, a SS7 MAP (pen-)testing toolkit. The toolkit is build upon the Osmocom SS7 stack and implements some basic MAP messages. At its current state tests against the HLR are ready for use, in future versions tests against VLR, MSC and SMSC will follow. […]


https://github.com/ernw/ss7MAPer

ss7MAPer – A SS7 pen testing toolkit

Intel Developer Forum

~ hucktech ~ Leave a comment

IDF is happening later this month in San Francisco, and there are multiple firmware presentations there. I counted about a dozen presentations that focus on UEFI, BIOS, Redfish, and related topics. Use the Search dialog in below URL to find things.

http://www.intel.com/content/www/us/en/intel-developer-forum-idf/san-francisco/2016/idf-2016-san-francisco-technical-sessions.html

Intel open sources Redfish-based rack

~ hucktech ~ Leave a comment

[…]Intel Rack Scale Design is the first framework to be based upon and use the Redfish™ industry standard from DMTFOpens in a new window for modern and secure management of scalable platform hardware in the modern data center. The framework allows for dynamic management of compute, memory, PCIe, and storage resources and the pooling of those resources for more efficient use of data center assets. The framework simplifies advanced technology to accelerate the adoption of open, interoperable solutions for tomorrow’s data centers today.[…]

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

http://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-design-overview.html

http://itpeernetwork.intel.com/intel-rack-scale-design-now-ready-open-source-development/

Google fork of CHIPSEC

~ hucktech ~ Leave a comment

[[UPDATE: this tweet from answers my below question:

]]

GRR (Google Rapid Response), a remote live forensics for incident response, has forked CHIPSEC and updated it to work with GRR. I wonder if the CHIPSEC team will fold back these changes into the trunk version of CHIPSEC?

https://testpypi.python.org/pypi/grr-chipsec/1.2.3

https://github.com/google/grr

kernelscan

~ hucktech ~ Leave a comment

Colin Ian King has written kernelscan, a tool to help parse Linux kernel messages.

[…] The Linux kernel contains lots of error/warning/information messages; over 130,000 in the current 4.7 kernel.  One of the tests in the Firmware Test Suite (FWTS) is to find BIOS/ACPI/UEFI related kernel error messages in the kernel log and try to provide some helpful advice on each error message since some can be very cryptic to the untrained eye. The FWTS kernel error log database is currently approaching 800 entries and I have been slowly working through another 800 or so more relevant and recently added messages.  Needless to say, this is taking a while to complete.  The hardest part was finding relevant error messages in the kernel as they appear in different forms (e.g. printk(), dev_err(), ACPI_ERROR() etc). In order to scrape the Linux kernel source for relevant error messages I hacked up the kernelscan parser to find error messages and dump these to stdout.  kernelscan can scan 43,000 source files (17,900,000 lines of source) in under 10 seconds on my Lenovo X230 laptop, so it is relatively fast. […]

http://smackerelofopinion.blogspot.com/2016/07/scanning-linux-kernel-for-error-messages.html

http://kernel.ubuntu.com/git/cking/kernelscan.git/

NIST SP 800-183: Network of Things

~ hucktech ~ Leave a comment

NIST has a new IoT-related document, focusing on the “Network of Things”. Abstract:

System primitives allow formalisms, reasoning, simulations, and reliability and security risk-tradeoffs to be formulated and argued. In this work, five core primitives belonging to most distributed systems are presented. These primitives apply well to systems with large amounts of data, scalability concerns, heterogeneity concerns, temporal concerns, and elements of unknown pedigree with possible nefarious intent. These primitives are the basic building blocks for a Network of ‘Things’ (NoT), including the Internet of Things (IoT). This document offers an underlying and foundational understanding of IoT based on the realization that IoT involves sensing, computing, communication, and actuation. The material presented here is generic to all distributed systems that employ IoT technologies (i.e., ‘things’ and networks). The expected audience is computer scientists, IT managers, networking specialists, and networking and cloud computing software engineers. To our knowledge, the ideas and the manner in which IoT is presented here is unique.

Click to access NIST.SP.800-183.pdf

Secure Boot and driver signing changes in latest Windows 10

~ hucktech ~ Leave a comment

Joshua Baxter of Microsoft posted a new article in the Windows hardware certification blog, about changes in Win10 driver signing:

Driver Signing changes in Windows 10, version 1607
Last year, we announced that beginning with the release of Windows 10, all new Windows 10 kernel mode drivers must be submitted to the Windows Hardware Developer Center Dashboard portal (Dev Portal) to be digitally signed by Microsoft. However, due to technical and ecosystem readiness issues, this was not enforced by Windows Code Integrity and remained only a policy statement. Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal. OS signing enforcement is only for new OS installations; systems upgraded from an earlier OS to Windows 10, version 1607 will not be affected by this change. We’re making these changes to help make Windows more secure. These changes limit the risk of an end-user system being compromised by malicious driver software. […]

More info, including a FAQ on how Secure Boot impacts this:

https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/

UEFI Fall plugfest schedule announced

~ hucktech ~ Leave a comment

More details for this:

Fall UEFI Forum plugfest is in September in Seattle

The details for the Fall UEFI Forum plugfest have been announced:

Out of Band BIOS Remote Management – AMI
This session will provide an overview of Out of Band BIOS remote management. The REST protocol, which allows for operations with server processes staging Out Of Band requests, can be layered on the platform interface with an integrated baseboard management controller (BMC) or with remote servers. UEFI provides extensive networking support for the pre-boot environment, including secure communication protocols like HTTPS. Checking for staged Out Of Band requests provides a highly manageable solution applicable to a variety of platform with or without a BMC.

Innovative Software Tools & Methods to Profile, Test and Optimize UEFI Firmware Improving Test Coverage and Debug Results – Kevin Davis, VP of Kernel Engineering, Insyde Software
How effective are your test tools for analyzing UEFI firmware applications? Learn how using key x86 processor capabilities and UEFI executable analysis, like Insyde’s tools can report exactly which lines of code were executed during boot.

Microsoft Security Built on UEFI Security 2.n (P1 and P2)
Attend this interactive session to learn about: The Hardware Security Test Interface (HSTI) v2, Customized Deployment of UEFI Secure Boot, including user mode, audit mode and deployment mode, Device Guard  and Credential Guard, VSM (Virtualization enabled by default), WSMT (Windows SMM Security Mitigations Table)

UEFI Network and Security Update – Vincent Zimmer, Sr. PE, Intel Corporation
How does the UEFI Forum evolve new capabilities for networking and security?  From business requirements to use-cases, threat models, and adjacent industry efforts, the Forum has evolved the footprint of capabilities in this area. This session will provide a brief history of features for networking and security, future areas of application and a depiction of how these technologies are evolving.

Update on TPM 2.0 Firmware Requirements – Dick Wilkins, Ph.D.  Phoenix Technologies Ltd.
As a follow-up to the last session at the UEFI Plugfest in Taipei, “The TPM 2.0 Specs Are Here, Now What?” the Trusted Computing Group (TCG) PC Client Working Group has incorporated several changes in their specifications, requiring updates to the functionality and the addition of new features. The updated TCG specifications will be ready for public review soon. Join this session to learn more about the upcoming enhancements and new requirements for these specifications.

More info:
http://uefi.org/events/upcoming

Awesome Vehicle Security list created

~ hucktech ~ Leave a comment

In the beginning, Yahoo! Directory was the place to go for list of sites, then DMOZ was briefly useful. These days, it appears the “awesome <topic>” set of ‘curated links’ are the new place to go for lists of links. There is a new list for car hacking:

https://github.com/jaredmichaelsmith/awesome-vehicle-security

Here are some others:
https://github.com/HQarroum/awesome-iot
https://github.com/sbilly/awesome-security
https://github.com/rshipp/awesome-malware-analysis
https://github.com/paragonie/awesome-appsec
https://github.com/carpedm20/awesome-hacking
https://github.com/enddo/awesome-windows-exploitation
https://github.com/sindresorhus/awesome

I’m about half done with an ‘awesome firmware’ list…

EBC adds AArch64 support!

~ hucktech ~ Leave a comment

UEFI has a bytecode, the uEfi ByteCode (EBC). It has traditionally been a bytecode used to consolidate all 3 Intel platforms (x86, x64, Itanic), into a single bytecode, so there only needs to be a single driver on the flash, saving flash memory. Unfortunately, it only supported Intel platforms, not ARM, so it was not a universal bytecode for EFI, only a bytecode for Intel systems. Now, someone has ported AArch64 to ARM, so now EBC may now be more interesting!

Import the AArch64 EBC implementation from
https://source.codeaurora.org/external/server/edk2-blue/

Tested with MdeModulePkg/Application/HelloWorld built for EBC.
Would appreciate some reviewing and testing.

Jeff Brasen (1):
  MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

Leif Lindholm (1):
  ArmVirtPkg: enable EBC interpreter for AArch64 QEMU

More info:
http://lists.01.org/pipermail/edk2-devel/

FreeBSD UEFI status update

~ hucktech ~ Leave a comment

FreeBSD’s quarterly status update is out.

There’s two entries on UEFI, excerpted below:

EFI Refactoring and GELI Support: The EFI bootloader has undergone considerable refactoring to make more use of the EFI API. The filesystem code in boot1 has been eliminated, and a single codebase for filesystems now serves both boot1 and loader. This codebase is organized around the EFI driver model and it should be possible to export any filesystem implementation as a standalone EFI driver without too much effort. Both boot1 and loader have been refactored to utilize the EFI_SIMPLE_FILE_SYSTEM interface. In the loader, this is accomplished with a dummy filesystem driver that is just a translation layer between the loader filesystem interface and EFI_SIMPLE_FILE_SYSTEM. A reverse translation layer allows the existing filesystem drivers to function as EFI drivers. The EFI refactoring by itself exists in a branch on github. Additionally, GELI support has been added using the EFI refactoring. This allows booting from a GELI-encrypted filesystem. Note that the EFI system partition, which contains boot1, must be a plaintext msdosfs partition. This patch adds an intake buffer to the crypto framework, which allows injection of keys directly into a loaded kernel, without the need to pass them through arguments or environment variables. This patch only uses the intake buffer for EFI GELI support, as legacy BIOS GELI support still uses environment variables. EFI GELI support depends on the efize branch. These patches have been tested and used and should be able to handle use by early adopters. Note that the LOADER_PATH variable has been changed to /boot/loader.tst, to facilitate safe testing.

loader.efi has been updated to use an event timer to implement its internal time function. This is needed, as many UEFI implementations do not handle the GetTime runtime service method. This means that loader.efi will now correctly count down before automatically booting.

https://www.freebsd.org/news/status/report-2016-04-2016-06.html

ARM IoT security using TLS

~ hucktech ~ Leave a comment

Wilfred Nilsen of ARM wrote a new post on the ARM IoT blog, click on blog URL below for video:

IoT Security: Creating X.509 Chain of Trust
Learn the entire process of setting up the chain of trust for your IoT solution. The video, which is available on YouTube, provides a practical example that you can follow and setup on your own computer for learning purposes. The comprehensive video tutorial guides you through the process of setting up secure and trusted communication. After completing the hands-on tutorials, you will be an expert in using SSL for secure communication and how to create and manage SSL certificates. The video shows how to create an Elliptic Curve Cryptography (ECC) certificate for the server, how to install the certificate in the server, and how to make the clients connecting to the server trust this certificate. The server in this video is installed on a private/personal computer on a private network for test purposes.

https://community.arm.com/groups/internet-of-things/blog/2016/07/06/iot-security-creating-x509-chain-of-trust

 

Thread Group and Open Connectivity Foundation

~ hucktech ~ Leave a comment

“Today the Thread Group and the Open Connectivity Foundation (OCF) announced that the two alliances will work together in their mission to advance the adoption of connected home products. The Thread Group and OCF share many member companies who will benefit from this liaison agreement, and both groups are committed to driving improved cross-application interoperability and device connectivity in the connected home […]”

http://threadgroup.org/
https://openconnectivity.org/http://www.businesswire.com/news/home/20160727005150/en/Thread-Group-Open-Connectivity-Foundation-Create-Liaison

http://www.eetimes.com/author.asp?section_id=36&doc_id=1330203&_mc=sm_eet_editor_rickmerritt

FWTS 16.07.00 released

~ hucktech ~ Leave a comment

Ivan Hu of Canonical announced the release of FirmWare Test Suite 16.07.00:

New Features:
   * acpi: method: add _FIT test
   * acpi: pcct: add ACPI PCCT test
   * opal/prd_info: Add OPAL Processor Recovery Diagnostics
   * olog: olog.json: Add OPAL skiboot errors for olog scan
   * Add klog checking for errors from drivers/acpi/tables.c
   * klog: data.json: Add klog checking for kernel NUMA errors from drivers/acpi/numa.c
   * klog: data.json: Add klog checking for kernel EC errors from drivers/acpi/ec.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/acpi_cmos_rtc.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/nfit.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/pci_root.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/pci_mcfg.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/cppc_acpi.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/battery.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/processor_idle.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/sleep.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/acpica/rsmisc.c
   * klog: data.json: Add klog checking for errors from drivers/acpi/evged.c
   * efi: enable module loading to load legacy or new efi driver
   * acpi: madt: Add support for ACPI 6.0a
   * acpi: madt: Add support for ACPI 6.1
   * uefi: update reset type to uefi 2.6
   * acpi: dbg2: Add missing debug port types

See the full release notes for list of bugfixes.

http://fwts.ubuntu.com/release/fwts-V16.07.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/16.07.00
https://launchpad.net/ubuntu/+source/fwts

additional Apple device property support for Linux efistub

~ hucktech ~ Leave a comment

Lukas Wunner submitted a 6-part patch to the Linux-(EFI,Kernel) lists with additional Apple EFI firmware support.

Apple device properties
Apple EFI drivers supply device properties which are needed to support Macs optimally. This series extends the efistub to retrieve the device properties before ExitBootServices is called (patch [1/6]). They are assigned to devices in an fs_initcall (patch [5/6]). As a first use case, the Thunderbolt driver is amended to take advantage of the Device ROM supplied by EFI (patch [6/6]). A by-product is a parser for EFI Device Paths which finds the struct device corresponding to a given path. This is needed to assign properties to their devices (patch [3/6]). […]

For more info:
https://github.com/l1k/linux/commits/apple_properties_v1
http://vger.kernel.org/majordomo-info.html