Rufus: insecure online behavior

[[update: see: https://github.com/pbatard/rufus/commit/c3c39f7f8a11f612c4ebf7affce25ec6928eb1cb ]]

 

 

Vulnerability Note VU#403768
Akeo Consulting Rufus fails to update itself securely

Akeo Consulting Rufus fails to securely check for and retrieve updates, which an allow an authenticated attacker to execute arbitrary code on a vulnerable system. Akeo Consulting Rufus 2.16 retrieves updates over HTTP. While Rufus does attempt to perform some basic signature checking of downloaded updates, it does not ensure that the update was signed by a trusted certificate authority (CA). This lack of CA checking allows the use of a self-signed certificate. Because of these two weaknesses, an attacker can subvert the update process to achieve arbitrary code execution. An attacker on the same network as, or who can otherwise affect network traffic from, a Rufus user can cause the Rufus update process to execute arbitrary code. The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workarounds:
* Don’t use built-in update capabilities
* Because Rufus does not include the ability to securely install updates, any Rufus updates should be obtained from https://rufus.akeo.ie/ directly, using your web browser.
* Avoid untrusted networks
* Avoid using untrusted networks, including public WiFi. Using your device on an untrusted network increases the chance of falling victim to a MITM attack.

https://github.com/pbatard/rufus

https://rufus.akeo.ie/

http://pete.akeo.ie/

Ulf: Attacking UEFI over DMA

Attacking UEFI:
Unlike macs many PCs are likely to be vulnerable to pre-boot Direct Memory Access (DMA) attacks against UEFI. If an attack is successful on a system configured with secure boot – then the chain of trust is broken and secure boot becomes insecure boot. If code execution is gained before the operating system is started further compromise of the not yet loaded operating system may be possible. As an example it may be possible to compromise a Windows 10 system running Virtualization Based Security (VBS) with Device Guard. This have already been researched by Dmytro Oleksiuk. This post will focus on attacking UEFI over DMA and not potential further compromises of the system.[…]

https://github.com/ufrisk/pcileech

http://blog.frizk.net/2017/08/attacking-uefi.html

 

WinDbg updated

 

New WinDbg available in preview!
We are excited to announce a preview version of a brand new WinDbg. We’ve updated WinDbg to have more modern visuals, faster windows, a full-fledged scripting experience, built with the easily extensible debugger data model front and center. I’ll start this by saying that WinDbg Preview is using the same underlying engine as WinDbg today, so all the commands, extensions, and workflows you’re used to will still work just as they did before.

https://blogs.msdn.microsoft.com/windbg/2017/08/28/new-windbg-available-in-preview/

Windbg always had restrictions in what UI widgets it could use, since Windbg was used to debug those same UI widgets (OLE, COM, etc.) and had to work even those widgets did not work.

Two new Rust/UEFI projects by Jiří Zárevúcky

Two new Rust/UEFI projects:

rust-efi-app: High-level bindings for writing UEFI applications in Rust. Currently in very early stages. The goal is that the library will make it easy and safe to write an application (e.g. an OS kernel) that is capable of functioning across call to ExitBootServices() without depending on the programmer’s judgement for safety, transparently dealing with issues like memory allocations and console output.

https://github.com/le-jzr/rust-efi-app

rust-efi-types:  Autogenerated Rust bindings for UEFI types and methods. Generated using bindgen from the headers distributed with gnu-efi. The headers are included. Only works on x86_64, and I don’t plan to extend it to other platforms, or clean it up in any way, because it’s all just a giant hack so that I don’t have to waste much time on proper bindings at this moment. Eventually, it will outlive its usefulness and be unceremoniously dumped into trash.

https://github.com/le-jzr/rust-efi-types

 

PTSecurity on Intel ME

Our team of Positive Technologies researchers has delved deep into the internal architecture of Intel Management Engine (ME) 11, revealing a mechanism that can disable Intel ME after hardware is initialized and the main processor starts. In this article, we describe how we discovered this undocumented mode and how it is connected with the U.S. government’s High Assurance Platform (HAP) program.

Disclaimer: The methods described here are risky and may damage or destroy your computer. We take no responsibility for any attempts inspired by our work and do not guarantee the operability of anything. For those who are aware of the risks and decide to experiment anyway, we recommend using an SPI programmer.[…]

http://blog.ptsecurity.com/2017/08/disabling-intel-me.html

https://github.com/ptresearch/unME11

https://github.com/ptresearch/me-disablement

TrustedSec’s PTF (PenTesters Framework)

It is a few years old, but I just learned about this tool. After you’ve installed a new OS, with all the tools that that come with that distro/marketplace, then you run PTF with a list of all your Github-based tools which don’t have binary packages, and it installs them for you. I guess some people use this as an alternative to pre-built security distros like Kali or BlackArch. I’ve heard that PTS works on more OSes than the below readme excerpt hints at. Ignore the “pentest” part of the name, it is applicable to non-pentesters, it is useful for people who have a list of Git/Svn-hosted source tools that do not have binary packages, which you want to have installed when you install a fresh OS. You can modify PTF with your list of source projects. If you have a custom script that sets up some firmware-related tools, please leave a Comment on the blog! The only firmware-related tool I noticed a PTF module for was for BinWalk.

The PenTesters Framework (PTF) is a Python script designed for Debian/Ubuntu/ArchLinux based distributions to create a similar and familiar distribution for Penetration Testing. As pentesters, we’ve been accustom to the /pentest/ directories or our own toolsets that we want to keep up-to-date all of the time. We have those “go to” tools that we use on a regular basis, and using the latest and greatest is important. PTF attempts to install all of your penetration testing tools (latest and greatest), compile them, build them, and make it so that you can install/update your distribution on any machine. Everything is organized in a fashion that is cohesive to the Penetration Testing Execution Standard (PTES) and eliminates a lot of things that are hardly used. PTF simplifies installation and packaging and creates an entire pentest framework for you. Since this is a framework, you can configure and add as you see fit. We commonly see internally developed repos that you can use as well as part of this framework. It’s all up to you. The ultimate goal is for community support on this project. We want new tools added to the github repository. Submit your modules. It’s super simple to configure and add them and only takes a few minute.

https://github.com/trustedsec/ptf/
https://github.com/trustedsec/ptf/blob/master/modules/reversing/binwalk.py
https://www.trustedsec.com/2015/05/new-tool-the-pentesters-framework-ptf-released/
https://www.trustedsec.com/pentesters-framework/

NVIDIA seeks Embedded Firmware Security Lead

We are looking for an engaged individual with an ability to assimilate complex software designs in order to identify security vulnerabilities and advocate for solutions. The applicant should demonstrate ability to use formal methods such as threat models and attack-trees to support appropriate architectural decisions.You should understand and be able to mentor others in security fundamental and principles of design. This includes testing techniques and a familiarity with static code analysis, dynamic analysis, fuzzing, negative testing and other techniques. Experience with secure code quality practices and tooling to support quick engagements and rapid analysis – static analysis tools (Coverity, Checkmarx, or similar), dynamic scanning (Rapid 7, AppSider, or similar), Fuzzing (AFL, Peach, or similar) and code coverage (Bullseye, LDRA, etc). 

https://www.linkedin.com/jobs/view/356235238

Booting Windows from USB drive

Here’s a MSDN blog entry on how to boot Windows via a thumbdrive. It is basically an introduction to Rufus…

Installing Windows with Secure Boot from USB drive
July 18, 2017
by Anders Lybecker

Once and a while I reinstall my machine. It feels nice with a clean slate as I tend to install all kinds of applications that pollutes my machine. A newly installed machine just runs better somehow. My machine needs to be secure, so Secure Boot and encrypted drive via BitLocker is a must. It limits the risk of someone messing with my machine and stealing my data. Here is how…[…]

https://blogs.msdn.microsoft.com/lybecker/2017/07/18/installing-windows-with-secure-boot-from-usb-drive/

http://www.lybecker.com/blog/2017/07/18/installing-windows-with-secure-boot-from-usb-drive/

https://github.com/pbatard/rufus

https://rufus.akeo.ie/

BTW, these days it is pretty rare to see a modern open source GUI tool that is written to use the native Windows Win32 GUI (GDI). These days, most GUIs are written using friendlier GUI frameworks/languages. Rufus is an ‘old school’ Windows tool, no drag-and-drop IDE-generated GUI code… 🙂

https://github.com/pbatard/rufus/blob/master/src/rufus.c

PureOS joins Debian derivatives census

PureOS is the Debian-based Linux distribution by Purism for their laptops.  Jonas Smedegaard has apparently joined Purism to help with PureOS:

“I am long time Debian developer with a special interest in Pure Blends (a.k.a. friendly assimilation of derivatives into Debian). Since about a month ago I am hired by Purism to help develop PureOS – a Debian derivative for which I will act as Derivatives Census contact.”

https://wiki.debian.org/Derivatives/Census/PureOS

Hector Oron of Debian, who invited PureOS into the Debian Derivative census, made a few interesting initial comments evaluating PureOS, some things that need I hope Purism addresses:

“The page says that PureOS modifies Debian binary packages. It is quite rare that distributions modify Debian binary packages instead of modifying source packages and rebuilding them. Does PureOS actually do this? If so could you describe what kind of modifications you are making? If not I guess the page needs to be fixed. The apt repository for PureOS does not contain source packages [for the contrib and non-free section], including for packages licensed under the GNU GPL. This may or may not be a copyright violation depending on whether or not you distribute those elsewhere. In any case, please add source packages to your repository so that Debian can automatically create patches to be presented to Debian package maintainers.”

For more info, read the thread on the debian-derivatives@lists.debian.org mailing list.

https://puri.sm/?s=Debian

Radare Conference 2017

https://rada.re/con/2017/

http://radare.org/con/2017/

Training:
Beginner Training (pancake, alvarofe)
Intro to Unpacking on Windows (newlog, Giomismo, zlowram)
Beginner Training (maijin, xvilka)
Tiny uControllers firmware reversing and exploiting (dark_k3y)

Presentations:
r2frida (@mrmacete)
SIOL – condret
CFG-based fussy hash for malware classification using r2 (robin marsollier)
zdbg (@zutle)
GSoC talks (gdbserver, windows support and backstepping) @xvilka
r2anal (alvaro) + limits of esil (killabyte)
RAIR (@oddcoder)
r2 module for Yara (@plutec_net + @mmorenog)
Anal clemency (@raysong)
Intro to Reversing Windows Malware Using r2 @ newlog
Surprise talk by @oleavr
Diaphora and r2 (@pancake, @matalaz)
Road to the kernel (@nighterman)
Pimp my Triton (ak42)

AMI announces NVMe UEFI Option ROM service for OEMs

American Megatrends Provides Service for Developing NVMe UEFI Option ROMs for UEFI BIOS Firmware

AMI is pleased to announce new service for developing NVMe® UEFI Option ROMs. Recently, AMI added support for technologies such as NVMe metadata/data encryption and NVMe namespace management. Continuing its support for NVMe-related technologies, AMI has also developed UEFI NVMe Option ROMs. This service for developing UEFI NVMe Option ROMs enables OEMs and NVMe device manufacturers to ship NVMe devices with Option ROMs embedded in them. OEMs and NVMe device manufacturers will have the ability to add features that are traditionally unavailable with generic UEFI drivers and can implement vendor-specific commands and features within their devices. Some of the additional features that are available for NVMe Option ROMs include disk management for namespace management in BIOS setup, metadata/end-to-end data protection, NVMe firmware updates in BIOS setup and SMART data information. Interested OEMs and NVMe drive manufacturers should contact their AMI sales representative for more information.

https://ami.com/en/news/press-releases/american-megatrends-provides-service-for-developing-nvme-uefi-option-roms-for-uefi-bios-firmware/
http://ami.com/products/bios-uefi-firmware/aptio-v/

Linux kernel ACPI-centric CVE-2017-13694: Awaiting Analysis

CVE-2017-13694
Source: MITRE
Last Modified: 08/25/2017
CVE-2017-13694

This vulnerability is currently awaiting analysis.

The acpi_ps_complete_final_op() function in drivers/acpi/acpica/psobject.c in the Linux kernel through 4.12.9 does not flush the node and node_ext caches and causes a kernel stack dump, which allows local users to obtain sensitive information from kernel memory and bypass the KASLR protection mechanism (in the kernel through 4.9) via a crafted ACPI table.

https://nvd.nist.gov/vuln/detail/CVE-2017-13694

https://github.com/acpica/acpica/pull/278/commits/4a0243ecb4c94e2d73510d096c5ea4d0711fc6c0
https://patchwork.kernel.org/patch/9806085/

HPE iLO: multiple remote vulnerabilities (HPESBHF03769 rev.1)

 

Hewlett Packard Enterprise Support Center
HPESBHF03769 rev.1 – HPE Integrated Lights-out 4 (iLO 4) Multiple Remote Vulnerabilities
Document ID: hpesbhf03769en_us
Last Updated: 2017-08-24
Potential Security Impact: Remote: Authentication Bypass, Code Execution:
A potential security vulnerability has been identified in HPE Integrated Lights-out (iLO 4). The vulnerability could be exploited remotely to allow authentication bypass and execution of code. […] Hewlett Packard Enterprise would like to thank Fabien Perigaud of Airbus Defense and Space CyberSecurity for reporting this vulnerability.

https://www.hpe.com/us/en/servers/integrated-lights-out-ilo.html

http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=hpesbhf03769en_us

https://tools.cisco.com/security/center/viewAlert.x?alertId=54930

“Limited details are available to describe this vulnerability or how this vulnerability could be exploited by an attacker. However, a successful exploit of this vulnerability could result in a complete system compromise.”

more on Google Titan

Earlier I pointed out some Google Titan info but didn’t have much info on it:

Google “Titan” secure microcontroller

(nobody left a comment, but a few people commented on it on Twitter.)

In the last few days, there’s more info available now:

https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html

https://www.blog.google/topics/google-cloud/bolstering-security-across-google-cloud/

https://cloud.google.com/security/

 

 

probably unrelated?:
https://github.com/GoogleCloudPlatform/titan