Erik's Security Blog Practicing Constant Vigilence

Go take a break!

I’m on vacation for the week, and while I considered posting a technical article as usual, I decided this would be good opportunity to highlight the importance of taking a break every now and then. For some of you this news will come as no surprise, but there may be others who are more focused on productivity and think “sleep is for the weak!” or “I’ll rest when I’m dead!”. For better or worse, I sometimes lean towards the latter category, so this post is for others who have difficulty with the choice between taking a break and maintaining an unbroken streak of productivity. I’m not suggesting long vacations are the most productive approach to every goal, but I would advocate that taking a rest can be extremely helpful when done right. By using the weasel words “when done right”, I admit the implementation details (frequency and length) of how breaks are taken will vary from one person to another, but the reasons why breaks should be taken is more consistent. So I am not here to advocate how one should take breaks in detail - I am only here to remind you to take the occasional break.

Perhaps the best reason to take breaks is to avoid burnout, which has gotten a bit of press in security. If you are unable to avoid burnout, your productivity will take a substantial hit regardless of whether you take a break or not, and no doubt you will improve your mindset if you choose to take breaks rather than take the burnout route. But a second reason where breaks can be useful is in your daily routine itself. One example would be the Pomodoro technique, which I have found useful when I am focused on a single topic or project for large chunks of time. If you wish to try out the Pomodoro technique, there are plenty of mobile apps and websites that offer a free Pomodoro timer.

Another approach to breaks in a daily routine is to focus your energy during your most productive hours of the day, leaving the less productive parts of the day open for breaks (such as meals, etc.). Everyone’s internal clock operates a bit differently, and because of this we have different times during the day that we are more likely to do our best work. We hear frequently of people working 6 days a week or other stories of intense struggle, but we hear less about how efficiently some people use just a few hours per day to accomplish great things. I speculate this is because it is easier and more common to be productive than to be effective. To apply this second approach, I would suggest recording your work output in half-hour chunks for 1-3 weeks to determine what parts of the day you are more productive, and review Peter Drucker’s timeless book “The Effective Executive” to go further and remove unnecessary tasks from your work or person to-do list.

Now if only my future self would heed these words, since I did not take a break from writing a blog post… Wisdom is the ability to follow your own advice!

Why you should start hacking Android

Android application security is like the land that time forgot. Mobile security is behind the times - issues like hard-coded sensitive data, unencrypted transmission of sensitive data, and other simple vulnerabilities abound. Billions of devices run Android applications, and only a handful of security researchers are seriously focused on analyzing them. Meanwhile, there’s a wild bonanza in web application security, where some of the cutting edge research looks like the equivalent of a graduate level thesis! Why does reality look like this? I don’t know, but I’m convinced that Android app security has been underappreciated and should see a surge of interest soon. Let me share what has convinced me to focus my energy on Android security.

First, let’s look at a graph from HackerOne’s 2020 annual report showing how many hackers on the platform hack mobile applications:

HackerOne 2020 Report Graph HackerOne 2020 Annual Report

That dark blue sliver, around 3% of the graph, is the amount of interest that exists in Android application security compared to other assets on HackerOne. While the folks looking at web apps spend substantial effort to find undiscovered assets, Android apps sit alone in the corner, unloved. HackerOne even tried to drum up more interest in Android Security with #AndroidHackingMonth blogposts in February 2020, and one researcher who started looking at Android after seeing these blogposts (that’s less than 6 months ago) already scooped up $30k in bounties from a single vulnerability. Let’s check BugCrowd’s 2020 report:

BugCrowd 2020 Report Graph BugCrowd 2020 ITMOAH Report

Huh, BugCrowd’s graph implies that Android is where hackers are “weakest”. Not much competition there either. Let’s look elsewhere, at Sebastian Porst (Google Play Protect’s engineering manager) presenting at Bugcrowd’s LevelUp 0x05. The two interesting tidbits I picked up on in the 4 minutes of video between minute 7 and minute 11 of this talk are that 1. 75% of the bug bounty payments that Google made on their Google Play Security Reward program occurred in the 90 days before the presentation (so between July and Oct 2019), which means interest was ramping up and 2. The number of vulnerabilities fixed in the 3 years prior to this talk (so 2016-2019) may make the Android app ecosystem security initiative the biggest application security program to date. Conveniently, Sebastian proceeds to outline different bug categories that you can start looking for.

BugCrowd LevelUp 0x05 Android app vulnerabilities presentation

So basically Google’s Android bug bounty program, which covers any app with over 100 million installs (that’s around 500 targets, according to, is known to have many vulnerabilities and pays well. Okay, sounds like that’s motivation enough, but there’s more data from Google. This one comes directly from the Google Play Security Rewards Program website. To summarize the chart below, Google is saying that easy-to-find vulnerabilities exist in Android apps, and instead of classifying them as out of scope, Google instead describes these vulnerabilities and still offers a reward. Very kind of them!

Google Play Security Rewards Known Issues chart Google Play Security Rewards Known Issues Chart

Of course, that chart is only for the low hanging fruit. The more complete list of rewards contains higher rewards, naturally. And remember that HackerOne, BugCrowd, Intigriti, and other sites have additional Android targets, many of which are conveniently curated in this Github repo.

Google Play Security Rewards full chart Google Play Security Rewards Chart

Oh, and let’s wrap up by reminding everyone that you can download and decompile Android applications, instrument them with Frida on a rooted device, and basically examine all the ins and outs of the application that you might want to see. How many other target assets can claim to be this close to whitebox open-source testing? I don’t see many hands being raised.

Let’s recap: we have many targets, a large number of expected vulnerabilities, decent rewards, not much competition, and open source assets ready for examination. Not to mention that it’s possible to download hundreds of applications and use scripts to statically analyze the applications quickly. I’m sold, and in the coming months, I hope to share more info about my adventures looking at Android application security. If you can’t wait to dive in, take a look at @0xteknogeek’s #AndroidHackingMonth Guide for a decent primer on how to get started.

DEF CON 28 Highlights

The first year of virtual DEF CON wrapped up last week, and what a firehose of information it was! I first must admit this was my first DEF CON where I was watching talks live (does watching a recorded talk on Twitch count as live?) as opposed to on YouTube after the event. Overall, I was impressed with how smoothly the event ran (or at least the parts that I saw). One perk of the online conference was that the 30 minute Q&A sessions seemed to move faster and more smoothly than in-person Q&As, and 30 minutes was enough to ask quite a few questions! The five talks that I highlight below are not in any particular order, since picking highlights is always a matter of opinion anyway.

DEF CON 28 logo

  1. I think Joshua is rightfully getting substantial attention for his “When TLS hacks you” talk, as this appears to be a new web security attack. A summary of this new attack surface is SSRF over TLS, but I think the idea of using TLS for web attacks is relatively unexplored in itself. Joshua’s Q&A session was very relaxed and indicated that he hadn’t poked around this new attack surface fully, which leaves a lot of room for others to fill in the gaps and move this further. On a related note, the “Domain Fronting Using TLS 1.3” talk by Erik Hunstad (which also featured novel research!) also found a new way to use TLS, and I appreciate the creativity of these researchers using technology that’s in plain sight in new ways.

  2. Having spent some time diving into the depths of the Bluetooth core specification, I have been keeping track of the new Bluetooth-related CVEs that have been popping up over the last several years (summarized in this blog post). After unveiling InternalBlue at 35C3 a couple years ago, Jiska presented with Francesco Gringoli about a creative new attack on Bluetooth/WiFi combo chips. Since space is at a premium in smartphones, and because WiFi and Bluetooth operate at the same frequency, most phones today use combination chips that implement both WiFi and Bluetooth. However, the phone has a clock that coordinates which protocol is able to transmit to avoid interference, and it’s this coordination mechanism that was attacked. Since phones will not be moving away from Bluetooth/WiFi combo chips (because of how compact and cheap they are), this and similar bugs at the intersection of different technologies will continue to be an interesting research area.

  3. Server-side template injection (SSTI) was something I first learned about thanks to PortSwigger’s fantastic Web Security Academy, and I suspect it is underrated because many of the findings to date rely on specific old versions of software to be running. However, discovering new vulnerabilities in the latest software versions is one solution to this! Munoz and Mirosh have had other awesome collaborations in the past (Friday the 13th JSON Attacks is worthwhile to read or skim), and this one produced over 30 CVEs - quite a collection. While the CVE in Microsoft Sharepoint seems to be getting a lot of press, there are many other well-known CMS software (HubSpot, Atlassian Confluence) that will likely be seeing the impact of this over the coming months, if they’re not patched.

  4. An astronaut. At DEF CON! With cool space photos!! Pam’s talk was lots of fun and gave a lot of cool insider information about experiences and observations based on experience of American spaceflight. To paraphrase one thing Pam said, the security risks are magnified when human lives are involved, and the ISS has people living up there 24/7/365. There’s obviously concerns with GPS security and other satellite hacking (a topic which got a substantially larger amount of interest this year), but this talk offered a perspective on the human element. Combining astronauts, space, and security just seems like a fantastic combo.

  5. Pedro Umbelino and Joao Morais presented some awesome vulnerabilities they uncovered in some of the most installed Android apps - the Google camera application and Samsung’s Find My Mobile application. The impact they were able to demonstrate with their findings was pretty impressive, as they put a fair bit of effort into adding capabilities to their proof of concept apps.

BONUS: Let’s face it, security can get pretty technical and no one likes being the dummy in the room. The War Story Bunker was an entertaining audio-only session on Discord where people chimed in with their stories of DEF CON and pen testing experiences. There were many epic wins and epic fails! Are you worried about deleting data during a pentest? Some of this year’s stories described accidentally taking down entire networks over substantial geographic areas! With these crazy stories to compare to, I expect to feel a lot better about any of the (reasonable) mistakes I might make.

Unfortunately, there’s no recording of the audio-only War Story Bunker session that I know of!

Analyzing Recent Bluetooth CVEs

A growing number of Bluetooth security vulnerabilities have been published in recent years, and I decided to dig into whether there was a common cause behind the many vulnerabilities being published. For those without much background in Bluetooth, I’ll give a brief introduction. Much like the internet, Bluetooth was created at a time when security was not a top priority. It has gotten security upgrades as the years have passed, but the need for backward compatibility and device interoperability has resulted in a massive 3000+ page Bluetooth core specification. This specification has many shortcomings. For instance, it’s well organized, it often leaves implementation details open for interpretation, and it’s obviously quite complex. And the 3000+ page specification doesn’t cover everything - there are many supplements and additional pieces of documentation that exist for understanding the details of the Bluetooth protocol. This complexity can obscure insecurity, and it makes the protocol less approachable for a researcher who has minimal time to spend learning all about a new protocol.

I find Bluetooth interesting because it’s found in so many devices, and yet it doesn’t seem to get much love. In fact, the security-conscious OpenBSD even removed their default support for Bluetooth. I can’t claim to have advanced knowledge of Bluetooth, given the enormous complexity held within the Bluetooth core specification alone, but I was able to piece together a few things by looking at the details behind some of the recent vulnerabilities. Here is a table showing some of the notable Bluetooth vulnerabilities I examined. The same table, as well as other useful Bluetooth security resources, are stored in this “awesome” Bluetooth security repo.

Name Con & Year published Site URL Paper URL Video URL SIG Notice Impacted CVE
BlueBorne Black Hat Europe 2017 Site Paper Video No Notice BR/EDR CVE-2017-8628, CVE-2017-0781, CVE-2017-0782, CVE-2017-0783, CVE-2017-0785, CVE-2017-14315, CVE-2017-1000250, CVE-2017-1000251, CVE-2017-14315, CVE-2017-1000410
Bleedingbit 2018 Site Paper Video No Notice LE CVE-2018-7080, CVE-2018-16986
Fixed Coordinate Invalid Curve Attack 2018 Site Paper No Video SIG Notice BR/EDR/LE CVE-2018-5383
SweynTooth 2019 Site Paper Video No Notice LE CVE-2019-16336, CVE-2019-17060, CVE-2019-17061, CVE-2019-17517, CVE-2019-17518, CVE-2019-17519, CVE-2019-17520, CVE-2019-19192, CVE-2019-19193, CVE-2019-19194, CVE-2019-19195, CVE-2019-19196, CVE-2020-10061, CVE-2020-10069, CVE-2020-13593, CVE-2020-13594, CVE-2020-13595
KNOB USENIX 2019 Site Paper Video SIG Notice BR/EDR CVE-2019-9506
BIAS IEEE S&P 2020 Site Paper Video SIG Notice BR/EDR CVE-2020-10135
Pairing Method Confusion 2020 No Site No Paper No Video SIG Notice BR/EDR/LE CVE-2020-10134
BlueFrag 2020 Article No Paper No Video No Notice Android CVE-2020-0022
Spectra Black Hat USA 2020 Abstract ? ? ? ? ?

I wanted to investigate the techniques that the vulnerability researchers were using to find and test out the new vulnerabilities they uncovered, and here’s what I found. The 2017 Blueborne research paper was the earliest attack examined, and perhaps the first in the most recent wave of Bluetooth vulnerabilities. The Blueborne research relied heavily on open source Bluetooth stacks (Android’s stack and Linux’s BlueZ stack), with some firmware reversing for Apple’s Bluetooth-based stack. The other vulnerability discovery from Armis followed a similar pattern, as did the Fixed Coordinate Invalid Curve Attack, though they both relied more on reverse engineering of firmware. However, in late 2018, a presentation at 35C3 unveiled the InternalBlue tool, which allows a Broadcom Bluetooth chip to be instrumented in such a way that it can act like an SDR. This allows for the injection of custom packets and many other features, without the need to buy expensive SDR hardware with a configurable Bluetooth stack on top of it. The introduction of this tool clearly assisted the discovery of more Bluetooth vulnerabilities, since after this tool’s release, practically every major Bluetooth vulnerability discovery used InternalBlue during the research phase. I found it interesting that the BlueFrag vulnerability was the only recent vulnerability in the list that was found with fuzzing, since fuzzing has uncovered so many vulnerabilities in other projects. Will more Bluetooth vulnerabilities be found once a better Bluetooth fuzzing tool is released? I’d be willing to bet yes, but time will tell.

The table below is a summary of the tools and techniques I saw used in the papers describing these vulnerabilities. The Pairing Method Confusion vulnerability does not appear to have a paper published, which explains my uncertainty around the techniques used to find it.

Name Firmware Reversing? Internal Blue? Fuzzing?
BlueBorne Yes No No
BleedingBit Yes No No
Fixed Coordinate Invalid Curve Attack Yes No No
Sweyntooth Yes Yes Maybe
KNOB Maybe Yes No
BIAS Yes Yes No
Pairing Method Confusion ? ? ?
BlueFrag Yes Yes Yes

Before you get overly concerned about your Bluetooth devices being attacked, it should be noted that many of the above attacks require an attacker to perform a man-in-the-middle (MiTM) attack, which is harder in some circumstances than in others. While Bluetooth is considered a short-distance radio communication protocol, Bluetooth’s commonly quoted maximum range of 100 meters is only limited by the radios used. Radio transmissions can be sent and received from a much further distance than 100 m if proper radio equipment is used, as shown back in 2004 by the trifinite group. New attacks impacting the underlying Bluetooth specification are certainly something to watch out for due to the number of devices they impact. While a malicious Bluetooth worm has yet to appear in the wild, attacks such as BlueFrag make such a scenario a possibility. And since many IoT devices and older phones supporting Bluetooth are unlikely to receive Bluetooth firmware updates to mitigate attacks at the Bluetooth stack layer, these type of findings may have consequences in the coming years.


“awesome” Bluetooth security repository:

Secure your browser: Chrome

For details about securing Firefox, see the equivalent Firefox post

Firefox is my preferred browser, but Chrome is currently the clear marketshare leader among browsers. As of early 2020, around 65% of browser usage is Chrome. In addition, at least a couple of other popular web browsers, the Brave browser and the new Microsoft Edge browser, borrow from Chrome’s codebase.

Chrome vs. Chromium

First, we must clarify the difference between the Chrome browser and the Chromium browser, because a lot of confusion exists between the Google’s two. open source project that is the foundation for Google Chrome. Chrome uses the Chromium source code as well as Google’s proprietary modifications. Therefore, while Chromium is licensed as open source software, Google Chrome is licensed as proprietary freeware.

Can’t have Chrome without the Google

If you are concerned about privacy as well as security, remember that Google creates the Chrome browser. Google makes the majority (~80%) of its revenue from advertisements. Because targeted advertising is more valuable, Google has incentive to gather data on web users to better target advertisements. By default, Chrome has some built-in features that can reduce a user’s privacy. Fortunately, there are several Chromium project forks that are built for improved privacy. For example, “Ungoogled Chromium” removes google dependencies in the Chromium code, in addition to other privacy improvements. If you choose to use this Chromium fork, I highly recommend reviewing the FAQ, as it explains how to overcome common hurdles, such as installing extensions from the Chrome web store. While the rest of this article will reference Chrome, Chromium can benefit from the same security improvements.

Don’t login to Chrome

This first suggestion is obvious if you wish to minimize Google’s data collection. Logging into the Chrome browser for extended periods can provide Google with insight into your web browsing habits. Note that in the most recent Chrome releases, you are automatically logged into Chrome when you login to Google services, such as Gmail, so logging in to Chrome can happen without you even noticing.

Add features to Chrome shortcut

Some of the security features in Chrome cannot be modified in a menu of settings, but instead need to be arguments provided to Chrome when Chrome is started. To provide arguments to Chrome, you need to find the shortcut that you use to start Chrome, right click this shortcut, and select “Properties” (or “Edit”, depending on your OS), and change the path or command that starts Chrome. Several examples of features that can be added with this approach are:

  • Opening Chrome in private browsing mode (AKA “incognito” in Chrome), where no history is saved, requires passing an argument to chrome, specifically -incognito
  • To use DNS over HTTPS, use the argument --enable-features="dns-over-https<DoHTrial" --force-fieldtrials="DoHTrial/Group1" –force-fieldtrial-params="DoHTrial.Group1:server/https%3A%2F%2Fcloudflare-dns%2Ecom%2Fdns-query/method/POST"
  • If you wish to disable canvas fingerprinting entirely (which might not be the best approach, compared to spoofing a false canvas fingerprint value), you can use the --disable-reading-from-canvas argument

After deciding which features you want to enable, you may end up with a shortcut to start Chrome that contains a list of command arguments such as the following:

/usr/bin/google-chrome-stable %U -incognito --enable-features="dns-over-https<DoHTrial" --force-fieldtrials="DoHTrial/Group1" --force-fieldtrial-params="DoHTrial.Group1:server/https%3A%2F%2Fcloudflare-dns%2Ecom%2Fdns-query/method/POST" --disable-reading-from-canvas


Fortunately, many of the browser extensions that I am familiar with in Firefox are also found in Chrome. Below is a list of Chrome extensions I prefer, but I have chosen most of these because I am familiar with using them on Firefox.

Use chrome://flags??

The most confusing part of my exploration of improving Chrome’s security is the lack of information about privacy-related and security-related flags that can be set on the special chrome://flags page. I assumed that this is the Chrome equivalent of Firefox’s about:config, but it appears to allow for much less granular control. I couldn’t even come up with a list of 5 good security features to enable on this page, so if I’m missing something obvious, please reach out and let me know! My current conclusion is that Google is targeting the average user who wants technology that “just works”, even at the cost of privacy, and therefore they don’t see the value in providing detailed configuration settings.

Other best practices

This list only is only a summary of the many ways that your browser can be secured. For good measure, I will list a few miscellaneous suggestions that can also help for various reasons:

  • Use strong, unique passwords and change them at least once per year. Weak or compromised passwords are still one of the most common ways that security is broken. If your password is leaked (for example, if all the accounts for a certain website were leaked onto the internet), this limits the timeframe when another person may be able to access your account.
  • If you use Chrome on your mobile device, secure your mobile browser with the same steps used here. Some of these settings require a different process to set on your mobile device, such as always opening Chrome in private browsing (AKA incognito) mode.
  • Change your default search engine to DuckDuckGo. Since Google attempts to target ads by gathering data on users, the privacy-centric DuckDuckGo is a great choice for anyone wishing for a little less Google in their life. Or if you want an alternative to DuckDuckGo, you could try Searx.
  • Test your browser to make sure your expectations are aligned with reality. Some useful website are Panopticlick (to check your browser’s fingerprint), Cloudflare’s ESNI checker (to check DNS over HTTPS), and BrowserLeaks (to check a variety of browser settings).

Overall, I’d still suggest Firefox as the best web browser for someone who wants to customize their browser for security and privacy needs. The lack of easy configuration for multiple useful settings (always private browsing, DNS over HTTPS) create a privacy and security drawback in Chrome. After all, there is a reason why the Tor browser is built on Firefox. If you’re interested in switching to Firefox, check out the first article explaining how to secure Firefox and compare those features with Chrome’s.