Author: hucktech

QubesOS, Invisible Things Lab, and Purism

~ hucktech ~ Leave a comment

Purism ships Debian-derived PureOS, and used to ship QubesOS. Now, Qubes is not really an option. I don’t know the full story, below posts give some background.

https://groups.google.com/forum/#!topic/qubes-users/2GfyEz0eYCE

https://puri.sm/posts/2017-07-shipping-update-for-qubes-orders/

https://forums.puri.sm/t/no-longer-listed-on-the-qubes-websites-certification-page/1050/5

https://www.qubes-os.org/news/2015/12/09/purism-partnership/

https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops

https://www.qubes-os.org/doc/system-requirements/

https://www.qubes-os.org/hcl/

https://web.archive.org/web/20170506112157/https://www.qubes-os.org/doc/certified-laptops/

 

Collabora: Changing the Android boot animation

~ hucktech ~ Leave a comment

Quick hack: Changing the Android boot animation

Posted on 21/04/2017 by Robert Foss

For various reasons you might want to change the Android boot animation to something other than the stock one, this is how you do it. There exists official documentation for how to create a custom boot animation, but unfortunately it is lacking in actual examples. So this guide is a bit more hands-on. Without covering too much of the same gound as the documentation, let’s have a quick look at what is in a simple bootanimation.zip.[…]

https://www.collabora.com/news-and-blog/blog/2017/04/21/quick-hack-changing-the-android-boot-animation/

https://android.googlesource.com/platform/frameworks/base/+/master/cmds/bootanimation/FORMAT.md

DR.CHECKER: Linux kernel driver vulnerability detection tool

~ hucktech ~ Leave a comment

 DR.CHECKER : A Soundy Vulnerability Detection Tool for Linux Kernel Drivers

usage: run_all.py [-h] [-l LLVM_BC_OUT] [-a CHIPSET_NUM] [-m MAKEOUT] [-g COMPILER_NAME] [-n ARCH_NUM] [-o OUT] [-k KERNEL_SRC_DIR] [-skb] [-skl] [-skp] [-ske] [-ski] [-f SOUNDY_ANALYSIS_OUT]

optional arguments:
-h, –help show this help message and exit
-l LLVM_BC_OUT Destination directory where all the generated bitcode files should be stored.
-a CHIPSET_NUM Chipset number. Valid chipset numbers are:
1(mediatek)|2(qualcomm)|3(huawei)|4(samsung)
-m MAKEOUT Path to the makeout.txt file.
-g COMPILER_NAME Name of the compiler used in the makeout.txt, This is
needed to filter out compilation commands. Ex: aarch64-linux-android-gcc
-n ARCH_NUM Destination architecture, 32 bit (1) or 64 bit (2).
-o OUT Path to the out folder. This is the folder, which
could be used as output directory during compiling
some kernels. (Note: Not all kernels needs a separate out folder)
-k KERNEL_SRC_DIR Base directory of the kernel sources.
-skb Skip LLVM Build (default: not skipped).
-skl Skip Dr Linker (default: not skipped).
-skp Skip Parsing Headers (default: not skipped).
-ske Skip Entry point identification (default: not
skipped).
-ski Skip Soundy Analysis (default: not skipped).
-f SOUNDY_ANALYSIS_OUT Path to the output folder where the soundy analysis output should be stored.

https://github.com/ucsb-seclab/dr_checker

Huawei boot loader vulnerability

~ hucktech ~ Leave a comment

3 boot loader/smartphone security vulnerabilities from Huawei. Text of two and links to all 3 are below:

Security Advisory – Out-of-Bounds Memory Access Vulnerability in the Boot Loaders of Huawei Mobile Phones
SA No:huawei-sa-20170816-01-smartphone
Initial Release Date: 2017-08-16
The boot loaders of some Huawei mobile phones have an out-of-bounds memory access vulnerability due to the lack of parameter validation. An attacker with the root privilege of an Android system may trick a user into installing a malicious APP. The APP can modify specific data to cause buffer overflow in the next system reboot, causing out-of-bounds memory read which can continuous system reboot. (Vulnerability ID: HWPSIRT-2017-01070)
This vulnerability has been assigned a CVE ID: CVE-2017-8149. Huawei has released software updates to fix this vulnerability. Successful exploit could cause out-of-bounds memory read, leading to continuous system reboot.
This vulnerability can be exploited only when the following conditions are present: 1) The attacker has gained the root privilege of an Android system and successfully tricked a user into installing the malicious APP. 2) An attacker with the root privilege of an Android system may trick a user into installing a malicious APP. The APP can modify specific data to cause out-of-bounds memory read, leading to continuous system reboot. This vulnerability was reported to Huawei PSIRT by Aravind, Machiry. Huawei would like to thank Aravind, Machiry for working with us and coordinated vulnerability disclosure to protect our customers.[…]

Security Advisory – Authentication Bypass Vulnerability in Huawei Honor 5S Smart Phones
SA No:huawei-sa-20170816-03-smartphone
Initial Release Date: 2017-08-16
Huawei Honor 5S smart phones have an authentication bypass vulnerability due to the improper design of some components. An attacker can get a user’s smart phone and install malicious apps in the mobile phone, allowing the attacker to reset the password and fingerprint of the phone without authentication. (Vulnerability ID: HWPSIRT-2017-07037). This vulnerability has been assigned a CVE ID: CVE-2017-8151. Huawei has released software updates to fix this vulnerability. Successful exploit could allow the attacker to reset the password and fingerprint of the phone. This vulnerability can be exploited only when the following conditions are present: 1) The attacker obtains a user’s smart phone in unlocked state. An attacker can get a user’s smart phone and install malicious apps in the mobile phone, allowing the attacker to reset the password and fingerprint of the phone without authentication. This vulnerability was reported to Huawei PSIRT by security researcher Zhang Qing. Huawei would like to thank Zhang Qing for working with us and coordinated vulnerability disclosure to protect our customers.

http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20170816-01-smartphone-en
http://www.huawei.com/my/psirt/security-advisories/huawei-sa-20170807-01-smartphone-en
http://www.huawei.com/en/psirt/security-advisories/2017/huawei-sa-20170816-03-smartphone-en
http://www.huawei.com/us/psirt

https://www.linkedin.com/in/aravind-kumar-machiry-00459923

https://cn.linkedin.com/in/%E6%B8%85-%E5%BC%A0-4b37b2108

 

Frida 10.4 released

~ hucktech ~ Leave a comment

Frida provides quite a few building blocks that make it easy to do portable instrumentation across many OSes and architectures. One area that’s been lacking has been in non-portable use-cases. While we did provide some primitives like Memory.alloc(Process.pageSize) and Memory.patchCode(), making it possible to allocate and modify in-memory code, there wasn’t anything to help you actually generate code. Or copy code from one memory location to another. Considering that Frida needs to generate and transform quite a bit of machine code for its own needs, e.g. to implement Interceptor and Stalker, it should come as no surprise that we already have C APIs to do these things across six different instruction set flavors. Initially these APIs were so barebones that I didn’t see much value in exposing them to JavaScript, but after many years of interesting internal use-cases they’ve evolved to the point where the essential bits are now covered pretty well. So with 10.4 we are finally exposing all of these APIs to JavaScript. It’s also worth mentioning that these new bindings are auto-generated, so future additions will be effortless.[…]

https://www.frida.re/news/2017/08/15/frida-10-4-released/

Android 8.0 (“Oreo”) security changes

~ hucktech ~ Leave a comment

https://android-developers.googleblog.com/2017/08/introducing-android-8-oreo.html

https://developer.android.com/about/versions/o/android-8.0-changes.html#security-all

https://developer.android.com/topic/security/index.html

https://developer.android.com/about/versions/o/index.html

 

The Android boot process

~ hucktech ~ Leave a comment

The Android boot process
Punya Vashist

[…] Android, by the looks of it, seems to be a simplistic Operating System. However, in contrast, the processes and functions that add up to the OS a majority of the smartphone consumer uses are a lot more complex. The boot process, for starters, is nothing but a bunch of fancy images and animations for the end user. This post aims at breaking the boot process down for those very end users. And I promise a thorough read is all you need to understand the process. Nothing is too complicated if explained the right way.[…]

https://thecyberfibre.com/android-boot-process/

Finnbarr on state of Intel ME hacking tools

~ hucktech ~ Leave a comment

Finbarr has a new article on Intel ME, in which he’s wondering if current tools are acquiring bitrot:

[…]It seems to me there is little ongoing work to enhance existing ME analysis tools such as me_unpack or the meloader IDA plugin to support ME firmware versions 9.5.X.X or later. Possible reasons for this state of affairs include the lack of available documentation for ME versions above 9, no ROMB-enabled ME firmware later the version 9 in the wild, or simply that the ME tool developers have moved on to other projects.

https://blog.fpmurphy.com/2017/08/has-intel-me-analysis-tool-development-petered-out.html

Also, this post pointed out an Intel ME web site I had not seen before:

http://me.bios.io/Main_Page

It has an invalid HTTPS cert, and appears to have been last updated a few years ago.

PS: Also, if you are using Finnbarr’s UEFI-Utilities, note that he’s recently started including ThinkPwn as one of the binaries, so be careful how you deploy it. CHIPSEC blacklists ThinkPwn as one of handful of known UEFI malware modules.

Manticore 0.1.4 released

~ hucktech ~ Leave a comment

https://twitter.com/feliam/status/898677002789462016

https://github.com/trailofbits/manticore/blob/master/CHANGELOG.md#014—2017-08-18

https://github.com/trailofbits/manticore

Manticore: Symbolic execution for humans

New x86 microcode tool

~ hucktech ~ 2 Comments

https://twitter.com/ryanmaple/status/898616746717741058

https://github.com/RUB-SysSec/Microcode

“This repository contains a collection of x86 CPU microcode samples in binary and rtl form. The samples are compiled from scratch and specifically work with AMD’s K10 processor family.”

LLVM can now emit/parse/diff Windows PDBs

~ hucktech ~ Leave a comment

PDBs are the sidecar symbol files for Windows. The spec used to be private, now is public, and now it is great to see Clang supporting them. Last time I looked, GCC does not support them.

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

http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html

Cr4sh’s DmaHvBackdoor.c: Hyper-V backdoor for UEFI

~ hucktech ~ Leave a comment

Cr4sh is having fun with Windows Device Guard:

DmaHvBackdoor.c comments:

Part of UEFI DXE driver code that injects Hyper-V VM exit handler backdoor into the Device Guard enabled Windows 10 Enterprise. Execution starts from new_ExitBootServices() — a hook handler for EFI_BOOT_SERVICES.ExitBootServices() which being called by winload!OslFwpKernelSetupPhase1(). After DXE phase exit winload.efi transfers exeution to previously loaded Hyper-V kernel (hvix64.sys) by calling winload!HvlpTransferToHypervisor(). To transfer execution to Hyper-V winload.efi uses a special stub winload!HvlpLowMemoryStub() copied to reserved memory page at constant address 0x2000. During runtime phase this memory page is visible to hypervisor core at the same virtual and physical address and has executable permissions which makes it a perfect place to store our Hyper-V backdoor code. VMExitHandler() is a hook handler for VM exit function of hypervisor core, it might be used for interaction between hypervisor backdoor and guest virtual machines.

WordPress chokes on Github gist-based URLs, so click on initial Tweet above for URL. Or look for entry that matches date:

TPM microconf at 2017 Linux Plumbers Conference

~ hucktech ~ Leave a comment

Matthew Garrett has announced a TPM microconference at the upcoming Linux Plumbers Conference:

I’m pleased to say that after the success last year, there will be another TPM microconference at this year’s Linux Plumbers Conference. The current schedule has this taking place on Wednesday the 13th of September, so just under 4 weeks from now. We have a list of proposals for discussion at http://wiki.linuxplumbersconf.org/2017:tpms but please feel free to add more! I intend to finalise the schedule by the end of next week, so please do so as soon as you can. For those of you who weren’t there, the Linux Plumbers conference is an event dedicated to bringing together people working on various infrastructural components (the plumbing) of Linux. Microconferences are 3 hour long events dedicated to a specific topic, with the focus on identifying problems and having enough people in the room to start figuring out what the solutions should be – the format is typically some short presentations coupled with discussion.

From James Bottomley’s comments on the LPC entry on this microconf:

Following on from the TPM Microconference last year, we’re pleased to announce there will be a follow on at Plumbers in Los Angeles this year. The agenda for this year will focus on a renewed attempt to unify the 2.0 TSS; cryptosystem integration to make TPMs just work for the average user; the current state of measured boot and where we’re going; using TXT with TPM in Linux and using TPM from containers.

http://wiki.linuxplumbersconf.org/2017:tpms

http://www.linuxplumbersconf.org/2017/trusted-platform-module-microconference-accepted-into-the-linux-plumbers-conference/

Full text of Matthew’s email:
https://lists.sourceforge.net/lists/listinfo/linux-ima-devel

kAFL: Hard­ware-As­sis­ted Feed­back Fuz­zing for OS Ker­nels

~ hucktech ~ Leave a comment

kAFL: Hard­ware-As­sis­ted Feed­back Fuz­zing for OS Ker­nels

Ser­gej Schu­mi­lo, Cor­ne­li­us Ascher­mann, Ro­bert Gaw­lik, Se­bas­ti­an Schin­zel, Thors­ten Holz

26th USE­NIX Se­cu­ri­ty Sym­po­si­um, Van­cou­ver, Ca­na­da, Au­gust 2017

Many kinds of me­mo­ry sa­fe­ty vul­nerabi­li­ties have been end­an­ge­ring soft­ware sys­tems for deca­des. Amongst other ap­proa­ches, fuz­zing is a pro­mi­sing tech­ni­que to un­veil va­rious soft­ware faults. Re­cent­ly, feed­back-gui­ded fuz­zing de­mons­tra­ted its power, pro­du­cing a steady stream of se­cu­ri­ty-cri­ti­cal soft­ware bugs. Most fuz­zing ef­forts—es­pe­ci­al­ly feed­back fuz­zing—are li­mi­ted to user space com­po­n­ents of an ope­ra­ting sys­tem (OS), alt­hough bugs in ker­nel com­po­n­ents are more se­ve­re, be­cau­se they allow an at­ta­cker to gain ac­cess to a sys­tem with full pri­vi­le­ges. Un­for­t­u­n­a­te­ly, ker­nel com­po­n­ents are dif­fi­cult to fuzz as feed­back me­cha­nis­ms (i.e., gui­ded code co­ver­a­ge) can­not be ea­si­ly ap­p­lied. Ad­di­tio­nal­ly, non-de­ter­mi­nism due to in­ter­rupts, ker­nel thre­ads, sta­te­ful­ness, and si­mi­lar me­cha­nis­ms poses pro­blems. Fur­ther­mo­re, if a pro­cess fuz­zes its own ker­nel, a ker­nel crash high­ly im­pacts the per­for­mance of the fuz­zer as the OS needs to re­boot. In this paper, we ap­proach the pro­blem of co­ver­a­ge-gui­ded ker­nel fuz­zing in an OS-in­de­pen­dent and hard­ware-as­sis­ted way: We uti­li­ze a hy­per­vi­sor and Intel’s Pro­ces­sor Trace (PT) tech­no­lo­gy. This al­lows us to re­main in­de­pen­dent of the tar­get OS as we just re­qui­re a small user space com­po­nent that in­ter­acts with the tar­ge­ted OS. As a re­sult, our ap­proach in­tro­du­ces al­most no per­for­mance over­head, even in cases where the OS cras­hes, and per­forms up to 17,000 exe­cu­ti­ons per se­cond on an off-the-shelf lap­top. We de­ve­lo­ped a frame­work cal­led ker­nel-AFL (kAFL) to as­sess the se­cu­ri­ty of Linux, macOS, and Win­dows ker­nel com­po­n­ents. Among many cras­hes, we un­co­ver­ed se­ver­al flaws in the ext4 dri­ver for Linux, the HFS and APFS file sys­tem of macOS, and the NTFS dri­ver of Win­dows.

https://www.syssec.rub.de/research/publications/kafl/

https://github.com/RUB-SysSec/kAFL

SELinux Switch for Android

~ hucktech ~ Leave a comment

The SELinux Switch is a New Tool for Toggling SELinux Between Enforcing and Permissive
by Doug Lynch
Some applications and modifications for Android require that SELinux be set to Permissive instead of Enforcing. Many who want this on their phone or tablet likely know of an alternative called SELinuxModeChanger or The SELinux Toggler. So XDA Senior Member Ibuprophen came out with a new tool called The SELinux Switch that lets you change a device’s SELinux state without having to permanently modify the boot script files. So your device will still boot with SELinux in Enforcing mode, but will then automatically launch and change the devices SELinux Mode after the boot process is completed.[…]

https://www.xda-developers.com/selinux-switch-toggle-permissive/

 

Apple Secure Enclave Processor (SEP) firmware hacked

~ hucktech ~ 1 Comment

“Hacker xerub has posted the decryption key for Apple’s Secure Enclave Processor (SEP) firmware.”

https://developer.apple.com/library/content/documentation/Security/Conceptual/CertKeyTrustProgGuide/SecureKeyGen.html

https://www.theiphonewiki.com/wiki/Greensburg_14G60_%28iPhone6,1%29

http://www.techrepublic.com/article/hacker-claims-to-have-decrypted-apples-secure-enclave-destroying-key-piece-of-ios-mobile-security/

http://www.iclarified.com/62025/hacker-decrypts-apples-secure-enclave-processor-sep-firmware