modzero Security: keylogger in HP audio driver

https://twitter.com/__ths__/status/862589402140352514

[EN] Keylogger in Hewlett-Packard Audio Driver
Security reviews of modern Windows Active Domain infrastructures are – from our point of view – quite sobering. Therefore, we often look left and right, when, for example, examining the hardening of protection mechanisms of a workstation. Here, we often find all sorts of dangerous and ill-conceived stuff. We want to present one of these casually identified cases now, as it’s quite an interesting one: We have discovered a keylogger in an audio driver package by Hewlett-Packard. A keylogger is a piece of software for which the case of dual-use can rarely be claimed. This means there are very few situations where you would describe a keylogger that records all keystrokes as ‘well-intended’. A keylogger records when a key is pressed, when it is released, and whether any shift or special keys have been pressed. It is also recorded if, for example, a password is entered even if it is not displayed on the screen.[…]There is no evidence that this keylogger has been intentionally implemented. Obviously, it is a negligence of the developers – which makes the software no less harmful. If the developer would just disable all logging, using debug-logs only in the development environment, there wouldn’t be problems with the confidentiality of the data of any user[…]

https://www.modzero.ch/modlog/archives/2017/05/11/en_keylogger_in_hewlett-packard_audio_driver/index.html

https://www.modzero.ch/advisories/MZ-17-01-Conexant-Keylogger.txt

Secure Boot BOF at DebConf17

Helen Koike of Collabora has proposed a BOF on UEFI Secure Boot at DebConf17, this August:

DebConf17 – BoF proposal to discuss secure boot
I want to send a BoF proposal to DebConf17 so we can meet there and discuss about secure boot. I would like to know if you are interested in attending and also which topics you suggest for discussion. I would appreciate if you could put your name and suggestions in this form in case you are interested https://goo.gl/forms/lHoEibY1H6FmSHSJ2 , or just reply to this email thread.

For full message, see the debian-efi mailing list archives.

https://lists.debian.org/debian-efi/2017/05/threads.html

https://docs.google.com/forms/d/e/1FAIpQLSdtHYNy9212iXP26tkjbb6XvgVSMjJzn2DYoAilFT1l89vemw/viewform?c=0&w=1

https://debconf17.debconf.org/

 

 

Linux kernel EGP_PGT_DUMP build option

Sai Praneeth Prakhya of Intel submitted V2 of an Intel UEFI diagnostic patch for the Linux kernel, the new version adds x86 support.

[PATCH V2] x86/efi: Add EFI_PGT_DUMP support for x86_32, kexec
EFI_PGT_DUMP, as the name suggests dumps efi page tables to dmesg during kernel boot. This feature is very useful while debugging page faults/null pointer dereferences to efi related addresses. Presently, this feature is limited only to x86_64, so let’s extend it to other efi configurations like kexec kernel, efi=old_map and to x86_32 as well. This doesn’t effect normal boot path because this config option should be used only for debug purposes.

Changes since v1:
1. Call efi_dump_pagetable() only once from efi_enter_virtual_mode() – as suggested by Boris

For more info, see the patch on the linux-(kernel,efi) lists.

Windows Internals new edition out

https://twitter.com/aionescu/status/862741520301965312

http://www.alex-ionescu.com/?p=335

https://blogs.msdn.microsoft.com/microsoft_press/2017/05/09/new-book-windows-internals-seventh-edition-part-1/

https://www.microsoftpressstore.com/store/windows-internals-part-1-system-architecture-processes-9780735684188

 

 

 

 

 

 

 

Wow, this book has gone a long way from “Inside Windows NT” by Helen Custer, the original author:

http://dl.acm.org/citation.cfm?id=138407

https://archive.org/details/insidewindowsnt00solo

Signing boot images for Android Verified Boot

Signing boot images for Android Verified Boot (AVB)
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme. Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images. Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM’s keys). This depends on the device, bootloader version, and bootloader unlock state. For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM’s. Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.[…]

https://forum.xda-developers.com/android/software-hacking/signing-boot-images-android-verified-t3600606

More Info:
https://source.android.com/security/verifiedboot/
https://source.android.com/security/verifiedboot/verified-boot
http://blog.andrsec.com/android/2016/03/26/android-verified-boot.html

 

Apple to prevent future firmware modifications?

” I have just come accross a piece of news on a German tech news site that states that Apple is working on anti-firmware modifications that may affect future installations od MacOS on Hackintosh: https://www.heise.de/newsticker/mel…r-Firmware-Modifikationen-warnen-3708495.html (if anyone has an alternative source in English please post it).”

https://www.tonymacx86.com/threads/anti-firmware-modification-from-apple.221647/

Image

https://www.heise.de/security/meldung/macOS-Sierra-Apple-will-vor-Firmware-Modifikationen-warnen-3708495.html?wt_mc=rss.security.beitrag.rdf

ME Analyzer 1.11.1 released

ME Analyzer is a tool which can show various details about Intel Engine Firmware (Management Engine, Trusted Execution Engine, Service Platform Services) images. It can be used to identify whether the firmware is updated, healthy, what Release, Type, SKU it is etc.[…]

https://github.com/platomav/MEAnalyzer

http://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html#msg10191

http://www.win-raid.com/t840f39-ME-Analyzer-Intel-Engine-Firmware-Analysis-Tool.html#msg14803

Intel AMT story, continued

https://www.us-cert.gov/ncas/current-activity/2017/05/07/Intel-Firmware-Vulnerability

https://github.com/CerberusSecurity/CVE-2017-5689

https://github.com/chipsec/chipsec/issues/212

https://support.lenovo.com/us/en/product_security/len-14963

http://en.community.dell.com/support-forums/laptop/f/3518/p/20011922/20995860

http://en.community.dell.com/techcenter/extras/m/white_papers/20443914

http://en.community.dell.com/techcenter/extras/m/white_papers/20443937

https://support.hp.com/us-en/document/c05507350

https://community.qualys.com/thread/17263-qids-or-scanning-advice-for-intel-amt-sa-00075

https://www.tenable.com/sc-dashboards/intel-sa-00075-detection

https://www.tenable.com/blog/intel-amt-vulnerability-detection-with-nessus-and-pvs-intel-sa-00075

https://vuldb.com/?id.100794

Intel AMT chip bug suspected backdoor, but likely coding error
[…]Some researchers accused the vulnerability of being a backdoor. Tatu Ylonen, the inventor of the Secure Shell protocol told SC Media Charlie Demerjan, the researcher who spotted the flaw, claims to have been in discussions over bug with Intel for years urging them t to fix it. “If his claim is true (I have no reason to doubt it but have no independent evidence), then it begins to sound very much like a backdoor,” Demerjan said. “I mean, if someone knows their product has a vulnerability that undermines the security of pretty much every enterprise server in the world and most security tools, wouldn’t they want to disclose it to the government, one of their biggest customers?”[…]

https://www.scmagazine.com/intel-amt-flaw-likely-just-coding-error/article/655449/

[…]What is clear, however, is that this flaw (which has existed for more than 9 years) truly is somewhere between nightmarish and apocalyptic. Taking no action is not an option.

http://www.securityweek.com/exploitable-details-intels-apocalyptic-amt-firmware-vulnerability-disclosed

Red Hat Satellite GRUB UEFI PXE script

Satellite 6 TFTP boot file legacy grub conversion script

This script is used to convert the tftp boot files (found in /var/lib/tftpboot/pxelinux.cfg/) which are automatically generated by Satellite 6 into the old legacy grub format. Why is this useful? Recently I encountered some HP servers which have an additional 10GbE card in one of the PCI-E slots on the machine which is used for the PXE boot. Unfortunately this additional interface only supports UEFI boot and not classic bios boot. By default Satellite 6 uses the shim image for UEFI but this doesn’t work with the older Linux kernel used by RHEL6.X. If this script is executed on a capsule or satellite server which has TFTP enabled, it will automatically replace the boot files using the old format which gives a successful boot for RHEL6.

https://github.com/RedHat-Consulting-UK/sat6-efi-converter

 

coreboot 4.6 released!

Martin Roth posted a new entry on the coreboot blog, announcing coreboot 4.6, excerpting his announcement below, see the full announcement here:

Announcing coreboot 4.6

The full announcement is many pages long, too long to properly summarize.

“Since the last release in October 2016, the coreboot project had 1708 commits by 121 authors.”

There’s a new payload called cbui:

“We provide the libpayload project which is used for writing own payloads from scratch. The library is MOSTLY licensed under BSD and recently received new functionality in order to prepare for the upcoming replacement for the old nvramcui payload. This new payload is called cbui and is based on the nuklear graphics library including keyboard and mouse support. The cbui payload is currently expected to be merged into the main coreboot tree before the next release.  The upstream repository is here: https://github.com/siro20/coreboot/tree/cbui/payloads/cbui

coreboot now integrates ME Cleaner in it’s build system, and has a new tool called blobtool:

“Fighting blobs and proprietary HW components: coreboot’s ultimate goal would be to replace any closed source firmware stack with free software components. Unfortunately this is not always possible due to signed binaries such as the Intel ME firmware, the AMD PSP and microcode. Recently, a way was discovered to let the Intel ME run in a functional error state and reduce it from 1.5/5MB to 80KB. It’s not perfect but it works from Nehalem up to Skylake based Intel systems. The tool is now integrated into the coreboot build system. The upstream repository is https://github.com/corna/me_cleaner

“Another ongoing improvement is the new utility blobtool. It is currently used for generating the flash descriptor and GbE configuration data on older mainboard which are known to be free software. It can easily be extended for different binaries with well-defined specifications.”

coreboot supports the Ada programming langauge:

“coreboot now supports Ada, and a lot work was done integrating Ada into our toolchain. At the moment only the support for formal verification is missing and will be soon added. At that point, we can prove the absence of runtime errors in our Ada code. In short, everybody can start developing Ada code for our project. The existing Ada code which can be used from now on is another native graphics initialization which will replace in the long term the current implementation. The native graphics code supports all Intel platforms up to skylake. We offer support for HDMI, VGA, DVI and DP external interfaces as well and is ready to be integrated into our mainboard implementations.”

Home

https://www.coreboot.org/

Intel AMT story, continued

Business-class personal computers *ARE* impacted.

 

There is an NMap module for AMT now:

https://svn.nmap.org/nmap/scripts/http-vuln-cve2017-5689.nse

http://thehackernews.com/2017/05/intel-amt-vulnerability.html

https://www.ssh.com/vulnerability/intel-amt/

https://github.com/bartblaze/Disable-Intel-AMT

https://github.com/travisbgreen/intel_amt_honeypot

https://isc.sans.edu/forums/diary/Do+you+have+Intel+AMT+Then+you+have+a+problem+today+Intel+Active+Management+Technology+INTELSA00075/22364/

Intel ME: based on Minix?

https://twitter.com/lordbaco/status/861216983488004098

“[…]In addition, when we looked inside the decompressed vfs module, we encountered the strings “FS: bogus child for forking” and “FS: forking on top of in-use child,” which clearly originate from Minix3 code. It would seem that ME 11 is based on the MINIX 3 OS developed by Andrew Tanenbaum :)[…]”

http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html

http://www.minix3.org/