Category: Uncategorized

UEFITool 0.20.7 released

~ hucktech ~ Leave a comment

Nikolaj Schlej just released version 0.20.7 of UEFITool.

https://github.com/LongSoft/UEFITool/releases/tag/0.20.7

Since last release, 4 changed files, 34 additions and 3 deletions:
https://github.com/LongSoft/UEFITool/commit/63e5a4dd1cf187fe6b62bd0da60529746f2ff7a1

“UEFITool is a cross-platform C++/Qt program for parsing, extracting and modifying UEFI firmware images. It supports parsing of full BIOS images starting with the flash descriptor or any binary files containing UEFI volumes. Original development was started on the MyDigitalLife (MDL) forums as a cross-platform analog to PhoenixTool’s structure mode with some additional features, but the program’s engine was proven to be useful for another projects like UEFIPatch, UBU and OZMTool.”

Intel Advanced Threat Research, when describing the Hacker Team’s UEFI malware, used UEFITool, see:
http://www.intelsecurity.com/advanced-threat-research/blog.html

If you’ve never used UEFITool, and you’re reading this blog, you should probably check out the tool… 🙂
https://firmwaresecurity.com/tag/chipsec/

Supplyframe acquires Tindie

~ hucktech ~ Leave a comment

Earlier this week, Cabe Atwell at Make Zine wrote an article about Supplyframe’s acquisition of Tindie. Supplyframe is the group behind Hackaday. Excerpt of Cabe’s article:

“In an effort to make it easier for users to get their hands on the electronics needed for their varying projects, Supplyframe has recently acquired online marketplace Tindie — a place where Makers can buy and sell their respective products. Supplyframe feels that their recent acquisition will fill an important gap between prototyping and manufacturing where crowdfunding is not an option for some just yet. Users may be working on revision 1 for the project and want to see what “lean manufacturing” can do before committing or revising their projects, while others may simply want to produce only a few copies of their projects. Crazy, purchasable gear is sure to flood in the second it opens. This couldn’t be a smarter purchase, in my opinion. Ever read the comments at Hack-A-Day, every thread has a “where can I buy one” entry… that place will now be close.”

Read the full article:

Supplyframe and Hackaday Acquire DIY Online Marketplace Tindie

Tindie Becomes A Part Of The Hackaday Family

Big News from Tindie!

Openstack vulnerability with QCOW2 images

~ hucktech ~ Leave a comment

Today Tristan Cacqueray of Red Hat — and of the OpenStack Vulnerability Management Team — reported a CVE-backed issue with Glance, and it’s use of QCOW2 (“QEMU Copy On Write”, a QEMU-based image format). Glance is the OpenStack Image Service, which provides discovery, registration, and delivery services for disk and server images, as well as a REST-based API.

Glance v2 API host file disclosure through qcow2 backing file
OSSA 2015-014, CVE-2015-5163

“Eric Harney from Red Hat reported a vulnerability in Glance. By importing a qcow2 image with a malicious backing file, an authenticated user may mislead Glance import task action, resulting in the disclosure of any file on the Glance server for which the Glance process user has access to. Only setups using the Glance V2 API are affected by this flaw. This fix will be included in the future 2015.1.2 (kilo) release.”

For the full announcement, including more URLs to patches, see the openstack-announce or oss-security mailing lists. Look to the CVE link in the future, there’s nothing there yet.
http://lists.openstack.org/pipermail/openstack-announce/2015-August/000527.html
https://launchpad.net/bugs/1471912
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5163
http://docs.openstack.org/developer/glance/
https://wiki.openstack.org/wiki/Glance

(Openstack aside, I wonder if codebases are vulnerable to an “importing a qcow2 image with a malicious backing file” attack?)

Libreboot ported to modern ARM Chromebook

~ hucktech ~ Leave a comment

Earlier this month, Paul Kocialkowski announced some work of his: getting Libreboot running on an ARM-based Chromebook, the Asus C201 “veyron_speedy”). Paul is a developer on the Replicant project, a free-as-in-freedom Android distribution.

Some quotes from Paul’s announcement:

“It should require no proprietary code nor any proprietary firmware load or microcode update to boot, thus it would be a good fit for Libreboot, as a fully free distribution of Coreboot.”

“At this point, I’ve been able to boot up Debian on the device, and the xfce4 interface is quite usable. It even runs big programs like Iceweasel/Firefox and LibreOffice without inconveniences.”

“Overall, I truly hope this device creates an incentive to free the last remaining parts that can only work with proprietary software to this day. Its potential would be huge, especially since it’s a good fit for travellers. With the security model inherited from Chromium OS, this would be one of the safest laptops to be used by journalists or activists. If Tails was to be ported to it, it would become easy to have a secure and anonymous setup.”

See the below libreboot mailing list post for full announcement. It’s not perfect, there are some issues with the Mali T764 Mali, and free software support, and some other rough edged, but perhaps these can be worked out over time.

Also, as mentioned in an earlier post, Paul will be at Chaos Communications Camp (CCCamp) 2015 later this week:

“I’ll be at CCCamp 2015 to talk about Replicant (as well as other things that I’m working on, like porting Libreboot to the C201 Chromebook), starting tomorrow.”

Very nice work Paul!!

http://blog.replicant.us/
http://lists.nongnu.org/archive/html/libreboot/2015-08/msg00009.html

Replicant and friends at Chaos Communication Camp 2015

new resource: Broken UEFI Implementations wiki

~ hucktech ~ Leave a comment

Watch this site to grow over time (and contribute to it, if you can help):
http://wiki.osdev.org/Broken_UEFI_implementations
http://wiki.osdev.org/index.php?title=Broken_UEFI_implementations&action=history

Apple, Lenovo, GIGABYTE: note that there’s some stuff about your products in the initial database.

As mentioned earlier:

Debian calls for UEFI packaging help

Intel update on Debian and UEFI

Steve McIntyre of the Debian project is working with other open source OS developers to maintain a list of broken UEFI implementations, to help OS vendors:

“I’ve been talking to a number of other UEFI developers lately, and we’ve agreed to start a cross-distro resource to help here – a list of known-broken UEFI implementations so that we can share our experiences. The place for this in in the OSDev wiki at http://wiki.osdev.org/Broken_UEFI_implementations. We’re going to be adding new information here as we find it. If you’ve got a particular UEFI horror story on your own broken system, then please either add details there or let me know and I’ll try to do it for you.”

See Steve’s blog post for more information:
http://blog.einval.com/2015/08/02

 

more research on Domas’ x86 memory sinkhole

~ hucktech ~ Leave a comment

As reported earlier, Christopher Domas gave a talk at Black  Hat Briefings with an interesting Intel vulnerability:

Domas’ x86 vulnerability

Post-Domas Intel BIOS update

Beyond the earlier presentation, there’s now more research on this, a whitepaper:

Click to access us-15-Domas-TheMemorySinkhole-wp.pdf

as well as sample code:
https://github.com/xoreaxeaxeax/sinkhole/blob/master/sinkhole.asm

tool mini-review: Read Universal utility (RUEXE)

~ hucktech ~ Leave a comment

[Correction: the .EXE is for MS-DOS, not for Windows.]

Feedback from a very smart reader:

“The Read Universal utility is a Swiss-Army-Knife for BIOS debugging, the tools that provides direct access to almost all resources like memory, IO space, PCI, SMBIOS data, UEFI variables and so on. The tool is written by AMI’s UEFI engineer James Wang.”

James site say: “I wrote RU.EXE for debugging BIOS problems in 1993. It was a simple tool but it turns out to be too complex now. And yes, I am still working for a BIOS company.”

The release includes MS-DOS-based ru.exe and UEFI-based ru.efi binaries. AFAICT, there are no sources on Google Code, it looks like this is a closed-source freeware tool. The release page for each release includes a password. Read the blog for multiple articles that describe new features.
[I’m just learning about this tool, obviously. I’ve been using open source tools for so long that I’m a bit nervous about using closed-source freeware binaries, but recommendation is from someone smart, so I’m setting up a safe environment to learn to use this tool. 🙂 ]

http://ruexe.blogspot.de/
https://code.google.com/p/ru-uefi/

Cisco ROMMON advisory

~ hucktech ~ Leave a comment

Security Activity Bulletin
Evolution in Attacks Against Cisco IOS Software Platforms
IntelliShield ID:    40411
First Published:    2015 August 11 18:17 GMT

Cisco PSIRT has released information regarding increasingly complex attacks against platforms running Cisco IOS Software. Cisco PSIRT has contacted customers to describe an evolution in attacks against Cisco IOS Classic platforms. Cisco has observed a limited number of cases where attackers, after gaining administrative or physical access to a Cisco IOS device, replaced the Cisco IOS ROMMON (IOS bootstrap) with a malicious ROMMON image. In all cases seen by Cisco, attackers accessed the devices using valid administrative credentials and then used the ROMMON field upgrade process to install a malicious ROMMON. Once the malicious ROMMON was installed and the IOS device was rebooted, the attacker was able to manipulate device behavior. Utilizing a malicious ROMMON provides attackers an additional advantage because infection will persist through a reboot. No product vulnerability is leveraged in this attack, and the attacker requires valid administrative credentials or physical access to the system to be successful. The ability to install an upgraded ROMMON image on IOS devices is a standard, documented feature that administrators use to manage their networks. No CVE ID will be assigned. The Cisco PSIRT has recently updated a number of technical documents to include information regarding the ROMMON attack as well as other threats to Cisco IOS devices. The following white papers are publicly available and provide information for preventing, detecting, and remediating potential compromise on Cisco IOS devices.

  Cisco IOS Software Integrity Assurance
  Cisco Guide to Harden IOS Devices
  Telemetry-Based Infrastructure Device Integrity Monitoring

Read Cisco’s full announcement:

http://tools.cisco.com/security/center/viewAlert.x?alertId=40411

http://www.pcworld.com/article/2970952/cisco-warns-customers-about-attacks-installing-rogue-firmware-on-networking-gear.html

Cisco Warns Customers About Attacks Installing Malicious IOS Bootstrap Images


http://www.infoworld.com/article/2970500/network-security/cisco-warns-customers-about-attacks-installing-rogue-firmware-on-networking-gear.htm

US-CERT: Lenovo Service Engine (LSE) BIOS Vulnerability

~ hucktech ~ Leave a comment

Today US-CERT issued a warning about Lenovo’s LSE:

Lenovo Service Engine (LSE) BIOS Vulnerability

Certain Lenovo personal computers contain a vulnerability in LSE (a Lenovo BIOS feature). Exploitation of this vulnerability may allow a remote attacker to take control of an affected system. Users and administrators are encouraged to review the Lenovo Security Advisories for notebooks and desktops and apply the necessary updates and mitigations.

https://www.us-cert.gov/ncas/current-activity/2015/08/12/Lenovo-Service-Engine-LSE-BIOS-Vulnerability
https://support.lenovo.com/us/en/product_security/lse_bios_notebook
https://support.lenovo.com/us/en/product_security/lse_bios_desktop

 

Intel update on Debian and UEFI

~ hucktech ~ Leave a comment

Yesterday Brian Richardson of Intel UEFI posted a new blog entry on 32-bit UEFI and Linux support, with specific information about Debian.  It was NICE to see the Debian swirl as the icon on an Intel.com-hosted blog post! 🙂 I am sometimes concerned that UEFI Forum and Intel only think about UEFI Forum-member Linux OSVs (Canonical, RedHat, SuSE) when it comes to UEFI and Linux. It’s NICE to see Intel working with non-UEFI Forum members on UEFI issues, especially Debian!

Blog excerpt:

“Thanks to Steve McIntyre from the Debian team for pointing out my error. Steve’s also helping organize a repository for information on UEFI implementations that don’t play nice with Linux. I think this is a great idea, so check it out if you have any relevant info. I’ll share my tips for testing UEFI & Linux in an upcoming post, in case you want to contribute to their project.”

Brian@Intel’s full blog post:
http://blogs.intel.com/evangelists/2015/08/11/update-on-ia32-uefi-and-linux-support/

Steve@Debian’s blog post:
http://blog.einval.com/2015/08/02#intel_justifies_mixed_efi

This repo of Linux UEFI information sounds GREAT!. Amongst the things it tracks, I hope it tracks the various Secure Boot strengths that Linux distributions have:

Secure Boot strength varies by Linux implementation

Interview with LegbaCore (and: their OpROM checker ships!)

~ hucktech ~ Leave a comment

A while ago, I emailed Corey and Xeno of LegbaCore, and sent them a few questions for an ‘interview’ for this blog. Well, here’s the results (also see EOM for URLs):

Q: This October in Singapore you’re giving 3-days of training at HITB. Besides new Apple EFI skills, can you give us some other new things that’ll be in this training?
A: The course introduces the basics of evaluating firmware and SMM on modern platforms for security vulnerabilities, as well as for potential compromises. Specifically we work through methodologies for identifying whether or not your system contains publically known vulnerabilities (which a great majority of them do). We also introduce a firmware forensic and reverse engineering methodology for identifying potential firmware compromises… so say if you got comprised by something like the hacking team UEFI rootkit, we’d talk about the tools and procedures that would be useful for identifying and analyzing this threat both on one particular system and at scale across your enterprise.
    The most important point of the training is it will be focused on real hardware that is deployed in real environments. A large portion of the course will involve evaluating the hardware that students bring with them. This way if you’re in charge of malware detection/response in an enterprise, you’ll walk away with actionable information related to the hardware you are deploying on your network.

Q: You had a Twitter post a few weeks (months?) back, saying that you were going to start releasing information about OEM systems’s vulnerabilities. What’s up with that project, I’m eager to see this data, as Consumer Reports and other computer review sources are useless for this most crucial pre-sales information. Any chance you could give FirmwareSecurity.com a teaser of this information, perhaps one new OEM model released in the last 6 months that’s insecure? 🙂
A: We anticipate that the project to start making some vendors’ firmware security failings more apparent (via a public website) will probably kick off in early 2016. We want to give all vendors that we think may have an interest in improving their security a chance to either talk with us about working with them, or show that they can make measurable security improvements on their own within this timeframe.

Q: You had a Twitter post a few days ago, pointing to a new LegbaCore Github repository for a new Option ROM checking tool. This sounds very interesting! What kinds of Option ROM(s) will it support? What platform(s) will it run on? When can we expect initial release?
A: It will only integrity check the Apple Thunderbolt to Ethernet adapter’s option ROM. It will work in conjunction with a port of the linux tg3 kernel driver to run on Macs to dump the OROM. The “ethtool” command can also be run to dump the OROM on linux systems that have a thunderbolt port and the tg3 driver available. The tool will be released to coincide with the talk at BlackHat, August 6th.

Q: Beyond this new Option ROM checker, does LegbaCore have any additional tool plans in the works? If so, any details to reveal?
A: Our current thinking on tools is that we expect that we will make clean-slate “best effort” tools freely available at some point in the future. These tools would be like all typical security tools, being not particularly trustworthy, and thus vulnerable to attacker subversion. They would mostly be useful for catching attackers as they first enter into the domain, and are not particularly sophisticated. However we will only make those tools available once we have commercial-grade tools available, that have a trust argument for why these paid tools have the ability to stand up to sophisticated and well-resourced adversaries. And in the background we will work with vendors to add capabilities such as SMM Dual Monitor mode, which significantly strengthen the trust arguments

Q: The Copernicus release is mostly Windows-centric, but also includes a cross-platform, bios_diff.py tool in the release. Will the new LegbaCore github tree include a open source bios_diff project, perhaps to get open source patches for improved BIOS parsing beyond EFIPWN, perhaps like that in UEFITool?
A: While bios_diff.py continues to provide the only simple, semantically aware integrity checking capability for BIOS, it has a number of issues. E.g. in the context of our latest work, it simply doesn’t work to integrity check Apple firmware, because Apple firmware update structure does not look the same as the structure on-disk.

Q: Post-October/HITB, what’s the next LegbaCore BIOS/UEFI security training event you’ll be giving?
A: Later in October I’ll be offering a similar training at Ruxcon breakpoint. Beyond that we are fairly busy with private training engagements.

Q: Any hints what kind of new firmware vulnerability research you’re working on, and when we might see some of the results?
A: We are branching out to the security of peripheral devices such as network cards, HDs/SSDs, embedded controllers, GPUs, the Intel Management Engine, etc. We are shooting to have our first talk on one of these topics around December.

Q: Recently Stephan of coreboot mentioned that in the past MITRE said that Chrome OS firmware was more secure than UEFI. Both coreboot+depthcharge’s Verified Boot and UEFI’s Secure Boot both seem pretty similar, in terms of PKI usage. Have you an opinion on the security strength of either of these firmware solutions?
A: We have never evaluated CoreBoot to any level of depth. Hardware-wise, we like the Chromebook requirement to provide physical write protection for the flash chip via a screw. The way that Chromebooks supposedly root their boot trust in the embedded controller hardware, as described to us, sounded like a good idea. But without having actually spent time looking at the platforms, we cannot say much in terms of the security (or lack thereof) relative to UEFI-based systems.

—-[End of interview.]

Thanks Corey and Xeno!
Links:

<blink>THEIR OPROM CHECKER IS RELEASED!</blink>
The code was added 5 days ago, and I missed it!
https://github.com/legbacore/t2e_integrity_check

Upcoming training:
http://gsec.hitb.org/sg2015/sessions/tech-training-6-introductory-bios-smm-attack-defense/
https://ruxconbreakpoint.com/training/bios/
http://www.legbacore.com/Training.html

Stephan’s comment on coreboot security:

UEFI upstreaming OpenSSL patch

~ hucktech ~ Leave a comment

UEFI has an optional build directive to enable “Secure Boot”. Secure Boot’s crypto is backed by the Open Source library libOpenSSL. For a long time, Tianocore’s OpenSSL was based on 0.98x release of OpenSSL. It sucks for UEFI that every time OpenSSL issues a new release (which is often, these months), the UEFI patch sometimes has to get updates to reflect OpenSSL changes. Plus, it was scary to see UEFI using such an ancient 0.98x release of OpenSSL for so long. Recently, UEFI updated to 1.0x releases of OpenSSL, and have been doing a lot of patch churning, due to frequent OpenSSl releases. So, it’s nice to see that there’s a effort by David Woodhouse of Intel’s Open Source Technology Centre, to make an effort to upstream the UEFI patches to OpenSSL, for the first time filing an issue in the RT. (Previously, AFAICT, the only effort to upstream was brief email on the OpenSSL mailing list, no RT filed.) I don’ t think UEFI Forum is one of the members of the OpenSSL Foundation; it might be nice if they were, given their Secure Boot dependence on this library. (OEMs/IBVs can swap out OpenSSL with another crypto lib, unclear which do…)

I  hope the OpenSSL Foundation and it’s developers accept this patch, or work with UEFI Forum’s developers to come up with acceptable patch to upstream.  I may be biased, but UEFI Secure Boot might be one of OpenSSL’s most important uses. Having UEFI target code in main OpenSSL trunk will save UEFI developers time, but also help with OpenSSL developers to understand the UEFI codepath differences, and may help reduce UEFI-centric code issues later. Imagine if Windows or Linux target support for OpenSSL was a separate patch, yuck.

Even if OpenSSL Foundation doesn’t accept the patch, it is still a significant new OpenSSL patch for UEFI, worth a review.

http://rt.openssl.org/Search/Simple.html?q=UEFI

Below is David’s posting to the edk2-devel list at 01.org:

——– Forwarded Message ——–
Subject: [edk2] [PATCH v3 0/16] CryptoPkg: OpenSSL update
From: David Woodhouse

Not sure which version this is; let’s call it v3 despite the fact that I think it’s actually the first time all this lot has been posted together in a single coherent series.

All the OpenSSL fixes are filed in upstream RT and in my git tree at http://git.infradead.org/users/dwmw2/openssl.git/ and backported to OpenSSL 1.0.2 in the OpenSSL_1_0_2-stable branch of the same repo.

This series cleans up a number of our outstanding OpenSSL patches to match what’s been submitted upstream, including the use of OPENSSL_SYS_UEFI instead of abusing OPENSSL_SYSNAME_UWIN.

It also cleans up places in our code where we access OpenSSL “internal” structures which are going to be made opaque in OpenSSL 1.1 and accessor functions should be used instead.

The build infrastructure is fixed to be more consistent with the way that OpenSSL is usually built all the OPENSSL_NO_xxx definitions are moved into opensslconf.h, and the file list is properly synchronised with the result of ‘make files’ in the suitably-configured OpenSSL source.

A script is provided which allows the opensslconf.h file and the list of files in OpensslLib.inf to be automatically updated. This script is not required during a normal build; it’s only for when we update the OpenSSL which is used by the EDK II repository.

Finally, we remove CryptoPkg/include/openssl and instead use the real OpenSSL include directory. This Just Works on POSIX-compliant platforms, and has symlinks to the original files. In OpenSSL 1.1 it’ll work even on Windows, as those files have been *moved* to the include/openssl/ directory of the OpenSSL source tree. For the time being, Install.sh can die and Install.cmd is updated to copy the files to $(OPENSSL_PATH)/include/openssl to work around Windows’ lack of symlinks.

Both the final commit (using OpenSSL HEAD) and the penultimate (still using a patched 1.0.2d) have been build-tested for IA32 and X86 both using GCC on Linux and VS2008 under Windows. And also using MinGW32/MingGW64 under Linux, although the final link there fails due to calls to __chkstk_ms (see GCC PR#67169).

Git tree at http://git.infradead.org/users/dwmw2/edk2.git

David Woodhouse (16):
CryptoPkg/BaseCryptLib: Add missing OpenSSL includes
CryptoPkg/BaseCryptLib: Use i2d_X509_NAME() instead of abusing X509_NAME
CryptoPkg/BaseCryptLib: Use accessor functions for X509_ATTRIBUTE
CryptoPkg/BaseCryptLib: Use accessor functions for ASN1_OBJECT
CryptoPkg/BaseCryptLib: Clean up checking of PKCS#7 contents type
CryptoPkg/BaseCryptLib: Use X509_V_FLAG_PARTIAL_CHAIN
CryptoPkg/BaseCryptLib: Use X509_V_FLAG_NO_CHECK_TIME
CryptoPkg/OpensslLib: Undefine NO_BUILTIN_VA_FUNCS to fix varargs breakage
CryptoPkg: Fix OpenSSL BN wordsize and OPENSSL_SYS_UEFI handling
CryptoPkg/OpensslLib: Eliminate GETPID_IS_MEANINGLESS definition
CryptoPkg/OpensslLib: Move OPENSSL_NO_xxx defines into opensslconf.h
CryptoPkg: Use OpenSSL include directory directly
CryptoPkg/OpensslLib: Include complete copy of opensslconf.h
CryptoPkg/OpensslLib: Update OpenSSL patch
CryptoPkg/OpensslLib: Automatically configure OpenSSL and generate file list
CryptoPkg: Support building with OpenSSL HEAD (1.1.0-devel)

CryptoPkg/CryptoPkg.dec                                               |   2 +
CryptoPkg/Include/OpenSslSupport.h                                    |  26 ++
CryptoPkg/Include/openssl/README                                      |   1 –
CryptoPkg/Library/BaseCryptLib/InternalCryptLib.h                     |  10 +-
CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c                 |   7 +-
CryptoPkg/Library/BaseCryptLib/Pk/CryptDh.c                           |   1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c                  |  94 +—
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaBasic.c                     |   1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaExt.c                       |   1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c                           | 102 +—
CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c                         |  18 +-
CryptoPkg/Library/BaseCryptLibRuntimeCryptProtocol/InternalCryptLib.h |   8 –
CryptoPkg/Library/OpensslLib/EDKII_openssl-1.0.2d.patch               | 380 —————
CryptoPkg/Library/OpensslLib/Install.cmd                              |  77 —
CryptoPkg/Library/OpensslLib/Install.sh                               |  79 —-
CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt                        |  44 ++
CryptoPkg/Library/OpensslLib/OpensslLib.inf                           | 480 ++—————–
CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt                          |  61 —
CryptoPkg/Library/OpensslLib/opensslconf.h                            | 488 ++++++++++++++++++++
CryptoPkg/Library/OpensslLib/process_files.sh                         |  38 ++
20 files changed, 691 insertions(+), 1227 deletions(-)

Kali 2.0 ships …without Metasploit

~ hucktech ~ 1 Comment

Kali releases 2.0:
https://www.kali.org/releases/kali-linux-20-released/
https://www.kali.org/downloads/

But now Kali no longer includes Metasploit:

“At the request of Rapid7, we have removed the Metasploit Community / Pro package from Kali Linux and now host the open-source metasploit-framework package only. For all of you who require Community or Pro, you will now need to download it from Rapid7 and then register and submit your personal details in order to get a license. In addition, the Rapid7 team no longer maintains the Metasploit package in Kali, which has brought with it some substantial changes – we’ve moved to a “native” setup, where rather than bundling all the required software needed to run Metasploit in one big package, we use native dependencies within Kali to support the metasploit-framework package. This results in a faster, smoother work experience and easier integration with Metasploit dependencies. For more information about this, check out our Metasploit Framework in Kali documentation page.”

In related ironic news, Rapid7 gave out Open Source love tshirts at DEF CON 23:
https://community.rapid7.com/community/metasploit/blog/2015/07/30/weekly-metasploit-wrapup
I wonder long long it’ll take for Rapid7 to make Metasploit a commercial-only product? 😦

Intel Boot Guard

~ hucktech ~ 1 Comment

Intel Boot Guard

As defined by Wikipedia: “Intel Boot Guard is a processor feature that prevents the computer from running firmware images not released by the system manufacturer. When turned on, the processors verifies a signature contained in the firmware image before executing it, using the hash of the public half of the signing key, which is fused into the system’s Platform Controller Hub (PCH) by the system manufacturer (not by Intel). Intel Boot Guard is an optional processor feature, meaning that it does not need to be activated during the system manufacturing. As a result, Intel Boot Guard, when activated, makes it impossible for end users to install replacement firmware such as Coreboot.”

Boot Guard attempts to protect the system before Secure Boot starts. Boot Guard is a big new player in the security -vs- user-control equation. To conserve words, I’ll just point to a few other blog posts on this topic by others:

http://patrick.georgi-clan.de/2015/02/17/intel-boot-guard/
https://hacked.com/quick-hack-bios-passwords-computer/
https://mjg59.dreamwidth.org/33981.html
https://news.ycombinator.com/item?id=9135767
http://www.pcworld.com/article/2883903/how-intel-and-pc-makers-prevent-you-from-modiying-your-pcs-firmware.html

Security must be addressed, but the cost might be General Purpose Computing?

Lockdown: The coming war on general-purpose computing


http://readwrite.com/2012/01/13/the-four-horsemen-of-the-gener
https://github.com/jwise/28c3-doctorow/blob/master/transcript.md

I hope Intel — or other chip vendors — can help both audiences, not only enterprise vendors who want to use the OEM’s installation of Windows and never change their systems. The locally-present user should be able to override features like this, and install what they want, at firmware, pre-OS and OS-level software. Some systems may need to be tamper-resistant to local users, but that’s just for enterprise bank employees, not for citizens. Intel: please give us more control over the products we purchase.

OTA releases draft IoT Trust Framework spec

~ hucktech ~ Leave a comment

As found on Dark Reading, yesterday the IoT Working Group of the Online Trust Alliance (OTA) released a trust framework draft.

Internet of Things Lacks Safety Today, Opening Door to Major Threats Tomorrow, Warns OTA

BELLEVUE, Wash. – The Online Trust Alliance (OTA), the non-profit with the mission to enhance online trust, today released its Internet of Things Trust Framework, the first global, multi-stakeholder effort to address IoT risks comprehensively. The framework presents guidelines for IoT manufacturers, developers and retailers to follow when designing, creating, adapting and marketing connected devices in two key categories: home automation and consumer health and fitness wearables. In the spirit of collaboration, OTA openly invites industry leaders to review the document and provide feedback. With members that include ADT, AVG Technologies, Microsoft, Symantec, Target, TRUSTe, Verisign and nearly 100 other subject matter experts, the OTA IoT Working Group was formed in January 2015. Through extensive research, this taskforce concluded that the safety and reliability of any IoT device, app or service depends equally on security and privacy, as well as a third, often overlooked component: sustainability.

IoT Trust Framework – Security, Privacy & Sustainability

The Internet of Things (IoT) moniker is being applied to 1000’s of devices, offering increased utility, functionality and other consumer and business benefits.  In the rapid race to bring products to market, many lack basic security protocols, privacy considerations and related safeguards.  Others have insecure processes and appear to be failing to consider fundamental privacy principles. While it is recognized there is no “perfect security” or “absolute privacy”, the lack of standards and controls increases the risk of exploits, data breaches and abusive data use policies to consumers and businesses worldwide.

https://otalliance.org/initiatives/internet-things
https://otalliance.org/news-events/press-releases/internet-things-lacks-safety-today-opening-door-major-threats-tomorrow

Click to access iot_trust_frameworkv1.pdf

http://www.darkreading.com/endpoint/iot-working-group-crafts-framework-for-security-privacy-/d/d-id/1321708

Lenovo Service Engine

~ hucktech ~ Leave a comment

A bit more on this topic from yesterday:

Lenovo LSE, WPBT and wpbbin.exe


Lenovo has a response:

Lenovo Statement on Lenovo Service Engine (LSE) BIOS
http://news.lenovo.com/article_display.cfm?article_id=2013

There are more news agencies reporting on this story:
http://thetechportal.in/2015/08/12/lenovo-in-a-soup-for-secretly-downloading-update-and-software-even-after-system-wipe/
http://gadgets.ndtv.com/laptops/news/lenovo-covertly-downloading-installing-software-on-its-windows-pcs-reports-727109

Lenovo once again in hot waters over Lenovo Service Engine BIOS


http://thenextweb.com/insider/2015/08/12/lenovo-used-a-hidden-windows-feature-to-ensure-its-software-could-not-be-deleted/

Yuck, is each OS vendor using UEFI as a crutch? I wish the Linux Foundation (or some other group) has advise for chip vendors, IBVs, IHVs, and pre-OS ISVs on how to use Linux properly on UEFI systems. It should require that this Windows-centric BIOS code to NOT be present on a Linux system. What other OS-specific crud is in my closed-source BIOS?!

UEFI HTTP Boot support announced

~ hucktech ~ Leave a comment

I’ve been wondering about UEFI 2.5’s HTTP Boot support since the Tianocore checkins started, a few months ago:

https://firmwaresecurity.com/tag/uefi-http-boot/

Intel announced more on this today, preparing for their upcoming IDF presentations on the topic:

https://twitter.com/Intel_UEFI/status/630806998951407616

https://twitter.com/Intel_UEFI/status/630807551664263168

UEFI 2.5 also added DNS support to complete the network stack needed for UEFI HTTP boot. I’ve yet to see any vendor except HP announce a product yet, perhaps IDF will unveil new products from other vendors.

Firmware at Intel Developer Forum

~ hucktech ~ Leave a comment

IDF, Intel’s Developer Forum, is happening shortly, August 18-20 (or so). It appears Brian and Vincent of Intel UEFI will be speaking, at least:

Vendors usually announce/release new things at their annual conferences, so I’m looking forward to seeing what Intel does… With 201 sessions, only a 2-minute glance at the schedule, here’s a teaser (but not all) of the more interesting presentations I noticed:

STTS001 — Firmware in the Data Center: Building a Modern Deployment Framework Using Unified Extensible Firmware Interface (UEFI) and Redfish REST APIs
STTS002 — Building a Firmware Component Ecosystem with the Intel® Firmware Engine
ACAS002 — Defense Against the Dark Arts – Introduction to Malware Research
STTS003 — Developing Best-in-Class Security Principles with Open Source Firmware
DCWC005 — Tech Chat: Trusted Networks in the Cloud – Attestation of Network Elements for Secure Cloud
ISGC003 — Tech Chat: A Primer on Intel® Software Guard Extensions (Intel® SGX)
SFTC003 — Tech Chat: Securing the Internet of Things with Intel® Micro Runtime (Intel® MRT)
ARCS003 — Intel® Architecture Code Name Skylake Deep Dive: Hardware-Based Security for Windows® 10
SPCS012 — Zoom-in on Your Code with Intel® Processor Trace and Supporting Tools
ISGC001 — Tech Chat: Intel® Security Controller – The Platform to Automate Your Security Application for Software-Defined Infrastructure
MAKE003 — Hands-on Maker Lab: Bring Up a MinnowBoard, the Intel® Atom™ Processor Based Open Hardware Platform
STTC003 — Tech Chat: Using Intel® Firmware Engine to Generate Simulated Platforms for Wind River Simics*
DCWC007 — Tech Chat: Differentiating Your Data Center Platforms in Firmware
ISGC003 — Tech Chat: A Primer on Intel® Software Guard Extensions (Intel® SGX)
SFTC003 — Tech Chat: Securing the Internet of Things with Intel® Micro Runtime (Intel® MRT)
SPCC002 — Tech Chat: A Wireless Smartphone-Based Pulmonary Function Analyzer
HSTS004 — Thunderbolt™ 3 Technology and USB-C*
INFS009 — Trusted Containers and VMs in Cloud Environments
ISGS004 — Biometric Authentication in Trusted Execution Environments
RPCS009 — Developer Training on Intel® Active Management Technology
SSDS004 — The Future of Storage Security

http://www.intel.com/content/www/us/en/intel-developer-forum-idf/san-francisco/2015/idf-2015-san-francisco-agenda.html

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

NSA Playset from BHB

~ hucktech ~ Leave a comment

The “NSA Playset” has been going on for a while; the latest update from Black Hat Briefings last week is worth checking out:

The NSA Playset: A Year of Toys and Tools
Michael Ossmann
“Inspired by the contents of the leaked NSA ANT catalog, the NSA Playset project has produced an array of gadgets with capabilities similar to those employed by the spooks. I will review the entire collection since the start of the project. This includes new tools for USB, PCI Express, I2C, GSM, Bluetooth, and a family of RF retroreflectors for eavesdropping on a wide variety of electronic devices. Now you can play along with the NSA!”

Click to access us-15-Ossmann-The-NSA-Playset-A-Year-Of-Toys-And-Tools.pdf

https://greatscottgadgets.com/
http://www.nsaplayset.org/