Daily Archives: August 2, 2019

Welcoming the Irish Government to Have I Been Pwned

Welcoming the Irish Government to Have I Been Pwned

Over the last year and a bit I've been working to make more data in HIBP freely available to governments around the world that want to monitor their own exposure in data breaches. Like the rest of us, governments regularly rely on services that fall victim to attacks resulting in data being disclosed and just like the commercial organisations monitoring domains on HIBP, understanding that exposure is important. To date, the UK, Australian, Spanish and Austrian governments have come onboard HIBP for nation-wide government domain monitoring and today, I'm happy to welcome the Irish government as well. They now have access to all .gov.ie domains and a handful of other government ones on different TLDs.

A big welcome to the Irish National Cyber Security Centre!

Adopting the Arm Memory Tagging Extension in Android

As part of our continuous commitment to improve the security of the Android ecosystem, we are partnering with Arm to design the memory tagging extension (MTE). Memory safety bugs, common in C and C++, remain one of the largest vulnerabilities in the Android platform and although there have been previous hardening efforts, memory safety bugs comprised more than half of the high priority security bugs in Android 9. Additionally, memory safety bugs manifest as hard to diagnose reliability problems, including sporadic crashes or silent data corruption. This reduces user satisfaction and increases the cost of software development. Software testing tools, such as ASAN and HWASAN help, but their applicability on current hardware is limited due to noticeable overheads.

MTE, a hardware feature, aims to further mitigate these memory safety bugs by enabling us to detect them with low overhead. It has two execution modes:

  • Precise mode: Provides more detailed information about the memory violation
  • Imprecise mode: Has lower CPU overhead and is more suitable to be always-on.

Arm recently published a whitepaper on MTE and has added documentation to the Arm v8.5 Architecture Reference Manual.

We envision several different usage modes for MTE.

  • MTE provides a version of ASAN/HWASAN that is easier to use for testing and fuzzing in laboratory environments. It will find more bugs in a fraction of the time and at a lower cost, reducing the complexity of the development process. In many cases, MTE will allow testing memory safety using the same binary as shipped to production. The bug reports produced by MTE will be as detailed and actionable as those from ASAN and HWASAN.
  • MTE will be used as a mechanism for testing complex software scenarios in production. App Developers and OEMs will be able to selectively turn on MTE for parts of the software stack. Where users have provided consent, bug reports will be available to developers via familiar mechanisms like Google Play Console.
  • MTE can be used as a strong security mitigation in the Android System and applications for many classes of memory safety bugs. For most instances of such vulnerabilities, a probabilistic mitigation based on MTE could prevent exploitation with a higher than 90% chance of detecting each invalid memory access. By implementing these protections and ensuring that attackers can't make repeated attempts to exploit security-critical components, we can significantly reduce the risk to users posed by memory safety issues.

We believe that memory tagging will detect the most common classes of memory safety bugs in the wild, helping vendors identify and fix them, discouraging malicious actors from exploiting them. During the past year, our team has been working to ensure readiness of the Android platform and application software for MTE. We have deployed HWASAN, a software implementation of the memory tagging concept, to test our entire platform and a few select apps. This deployment has uncovered close to 100 memory safety bugs. The majority of these bugs were detected on HWASAN enabled phones in everyday use. MTE will greatly improve upon this in terms of overhead, ease of deployment, and scale. In parallel, we have been working on supporting MTE in the LLVM compiler toolchain and in the Linux kernel. The Android platform support for MTE will be complete by the time of silicon availability.

Google is committed to supporting MTE throughout the Android software stack. We are working with select Arm System On Chip (SoC) partners to test MTE support and look forward to wider deployment of MTE in the Android software and hardware ecosystem. Based on the current data points, MTE provides tremendous benefits at acceptable performance costs. We are considering MTE as a possible foundational requirement for certain tiers of Android devices.

Thank you to Mitch Phillips, Evgenii Stepanov, Vlad Tsyrklevich, Mark Brand, and Serban Constantinescu for their contributions to this post.

Grasshoppers, Dead Cow, and Controlled Chaos: What We’re Looking Forward to at Black Hat USA

Veracode Black Hat USA 2019 Las Vegas

Usually, Black Hat USA is all the rage this time of year when it comes to Las Vegas; however, it seems the excitement about the show has been eclipsed by a grasshopper invasion. I admit, I was puzzled when my colleagues informed me of the news and proceeded to show me the horrifying photographic and video evidence. I joked that I would need to wear a Veracode-branded beekeeper suit, and wondered what the symbolism of the grasshopper is. So before I get to what you really care about – Black Hat – I leave you with two fun facts:

  1. Upon asking my mother – a Las Vegas resident – about the grasshopper invasion, she informed me that this happens every year, but it usually isn’t this bad. And that her side of town has significantly less grasshoppers.
  2. Grasshoppers can’t move sideways or backwards, they can only take big leaps forward. Seems apt when we’re considering the future of security and development.  

Without further ado, here are three events I’m most looking forward to attending at this year’s show:

Controlled Chaos: The Inevitable Marriage of DevOps & Security

Kelly Shortridge, VP of Product Strategy at Capsule8, and Dr. Nicole Forsgren, Research & Strategy at Google Cloud, will take a closer look at the choice information security has to make when it comes to DevOps: marry with their DevOps colleagues and embrace the philosophy of controlled chaos, or eventually lose the race, because software – secure software especially – is a competitive differentiator in today’s global economy. I’m curious to see Shortridge and Forsgren’s take on DevOps, the concepts of resilience and chaos engineering, and the impact on the future of security programs.

Where: South Pacific When: Aug. 7 from 4-4:50 p.m. Read More: Here

All Things Cult of the Dead Cow

Remember when much of the nation was astonished to learn that presidential candidate Beto O’Rourke was a member of America’s oldest hacking group, The Cult of the Dead Cow (cDc)? This was after Reuters reporter Joseph Menn published a special report that was adapted from his book Cult of the Dead Cow: How the Original Hacking Supergroup Might Just Save the World. While I’ll be sure to check out the briefing at BHUSA, at Veracode, we’re excited to host a conversation with Menn, Chris Wysopal, Veracode's CTO, Christien Rioux, Software Architect at Flowmill, and Luke Benfey - Deth Veggie – cDc Minister of Propaganda, for a discussion about the new book at our booth. Plus, we’re donating $2 to BuildOn for every booth visit.

Where: Booth #854 When: Aug. 7 from 5-6:30 p.m. Read More: Here

DevSecOps: What, Why and How

When it comes to development, security is often added towards the end of the DevOps cycle through a manual/automated review – but we know it doesn’t have to be that way. Security can actually be integrated – and automated – at each stage of the DevOps pipeline. In this briefing, Anant Shrivastava from NotSoSecure will dive into the technology and cultural aspects of DevSecOps, and the changes needed to get tangible benefits. Shrivastava will also present case studies on how critical bugs and security breaches affecting popular software and applications could have been prevented using a simple DevSecOps approach.

Where: South Pacific When: Aug. 8 from 11-11:50 a.m. Read More: Here

We’d love to talk to you about your own development shop and security practices during the show, so please stop by Booth #854 – we’ve got demos, spun chairs, and we’ll send you home with a one-of-a-kind custom t-shirt.

I’m not sure I’ll be able to score that branded beekeeper suit, but I’m looking forward to seeing everything Black Hat has to offer. If you’re open to sharing what you’re looking forward to at the show, let’s connected on Twitter (@lauraleapaine) so I can get your perspective. Make sure to check back here for live coverage – or subscribe to get our content updates sent directly to your inbox.

DHCP Client Remote Code Execution Vulnerability Demystified


CVE-2019-0547 was the first vulnerability patched by Microsoft this year. The dynamic link library, dhcpcore.dll, which is responsible for DHCP client services in a system, is vulnerable to malicious DHCP reply packets.

This vulnerability allows remote code execution if the user tries to connect to a network with a rogue DHCP Server, hence making it a critical vulnerability.

DHCP protocol overview

DHCP is a client-server protocol used to dynamically assign IP address when a computer connects to a network. DHCP server listens on port 67 and is responsible for distributing IP addresses to DHCP clients and allocating TCP/IP configuration to endpoints.

The DHCP hand shake is represented below:

During DHCP Offer and DHCP Ack, the packet contains all the TCP/IP configuration information required for a client to join the network. The structure of a DHCP Ack packet is shown below:

The options field holds several parameters required for basic DHCP operation. One of the options in the Options field is Domain Search (type field is 119).

Domain Search Option field (RFC 3397)

This option is passed along with OFFER and ACK packets to the client to specify the domain search list used when resolving hostnames using DNS. The format of the DHCP option field is as follows:

To enable the searchlist to be encoded compactly, searchstrings in the searchlist are concatenated and encoded.

A list of domain names, such as  www.example.com and dns.example.com are encoded thus:


There is a vulnerability in the DecodeDomainSearchListData function of dhcpcore.dll.

The DecodeDomainSearchListData function decodes the encoded search list option field value. While decoding, the function calculates the length of the decoded domain name list and allocates memory and copies the decoded list.

A malicious user can create an encoded search list, such that when DecodeDomainSearchListData function decodes, the resulting length is zero. This will lead to heapalloc with zero memory, resulting in an out-of-bound write.


The patch includes a check which ensures the size argument to HeapAlloc is not zero. If zero, the function exits.


A rogue DHCP server in the network can exploit this vulnerability, by replying to the DHCP request from the clients. This rogue DHCP server can also be a wireless access point which a user connects. Successful exploitation of this vulnerability can trigger a code execution in the client and take control of the system.

McAfee NSP customers are protected from this attack by signature “0x42602000”.

The post DHCP Client Remote Code Execution Vulnerability Demystified appeared first on McAfee Blogs.