GitHub has enabled free code analysis on public repositories. This is the fruit of the purchase of Semmle, almost exactly one year ago. Anyone with write permissions to a repository can go into the settings, and enable scanning. Beyond the obvious use case of finding vulnerabilities, an exciting option is to automatically analyse pull requests and flag potential security problems automatically. I definitely look forward to seeing this tool in action.

The Code Scanning option is under the Security tab, and the process to enable it only takes a few seconds. I flipped the switch on one of my repos, and it found a handful of issues that are worth looking in to. An important note, anyone can run the tool on a forked repo and see the results. If CodeQL finds an issue, it’s essentially publicly available for anyone who cares to look for it.

Simpler Code Scanning

On the extreme other hand, [Will Butler] wrote a guide to searching for exploits using grep. A simple example, if raw shows up in code, it often signals an unsafe operation. The terms fixme or todo, often in comments, can signal a known security problem that has yet to be fixed. Another example is unsafe, which is an actual keyword in some languages, like Rust. If a Rust project is going to have vulnerabilities, they will likely be in an unsafe block. There are some other language-dependent pointers, and other good tips, so check it out.

Stalking on Google

Real-world attacks, at least targeted attacks, involve lots of intelligence gathering on the target. Lots of data is available in the open on platforms like Facebook and Google, but sometimes it’s a pain to actually pull that data together. [mxrch] has published a tool specifically targeting Google accounts. Supply an email address, and GHunt attempts to scrape any public information available about that account.

What information might be available? First off, it looks for activity from that account on other Google services. YouTube, Google Maps, and Google Photos can be great sources of information. What’s not obvious about that is the extra information available from those sources. Images shared on Google Maps seems to have their metadata cleaned, but pictures left public on Google Photos don’t. Location data, camera hardware, and more interesting information is right there, so long as you know where to look. It would be interesting to stand up a GHunt instance and run it against your own Google account, just to see what information is out there.

New Malware, Old Malware

Emotet has been around since 2014, and has proven to be the gift that keeps on giving. Ars has a brief history of the malware, and it’s an impressive run. It’s apparent that whoever is behind Emotet has continued developing the malware. The most puzzling development is the five months earlier this year when Emotet went silent, only to return via an aggressive spam presence. Perhaps even cyber-criminals took time off for Coronavirus.

An even older malware campaign with clearer provenance has popped up again. FinSpy was created by FinFisher as a commercial spyware tool. Amnesty International has been reporting on spyware campaigns launched against political activists for quite some time, and often their reports include interesting technical tidbits. This one is no exception, as they break the news that FinSpy now targets MacOS and Linux machines. The observed Linux binary is simply named PDF, leading me to suspect the primary infection mechanism is phishing.

Attacking the Seams in the Cloud

Our friends at Google’s Project Zero set their sights on HashiCorp’s Vault project (It’s Open Source). Vault looks like a really useful project, as it handles data encryption for shared data sets. Want to build a complex web service where data is properly encrypted at rest, but still accessible to multiple users? Vault might be worth looking at.

Not all is perfect in paradise. One of the common places to find security problems is the interface between the elements of a service. In this case, [Felix] found an issue where Vault interfaces with the AWS authentication service. A user can request access to an object, and Vault will turn around and forward that request to Amazon’s user authentication mechanism. The function that handles that response accepts either XML or JSON encoding. As it turns out, that function will also accepts messages that include *both* types of encoding. The trick was to find a way to get Amazon’s service to reflect an authentication request that included JSON supplied by the user. The intended response is in XML: “Yes, this person exists”. Also included in that message is a JSON spoofed response: “This person is a superuser”.

There’s another attack vector detailed in the article, so go get the full scoop if it strikes your fancy. The point is made that as cloud-based applications become more common, this sort of vulnerability will be seen more often, as well. It’s a different paradigm, looking at cloud security as compared to conventional computer security.

Jailbreaking Macs

The jailbreaking community have been punching holes in Apple mobile hardware for years. What about desktop hardware? Do the flaws used in iOS jailbreaks also work on Macs? A few of them, yes. A researcher at IronPeak Services put together a summary of the current state of hardware attacks against MacOS machines. The good news is that this family of attacks require physical access, and because the vulnerable component has immutable firmware, the attack isn’t persistent. The bad news is that the immutable firmware cannot be patched, and all that is needed for compromise is a USB device.

Today’s Macs containing a co-processor, the T2. This chip is essentially the ARM A10 from Apple’s mobile devices, and handles quite a few system functions, including trusted computing via the Secure Enclave Processor (SEP) embedded inside. While the T2 firmware can be updated, the SEP firmware is read only, and can’t be touched. The shared hardware also means shared bugs, and a couple of those bugs exist in that immutable SEP firmware. Namely, Checkm8/Checkra1n. A USB device can trigger the jailbreak, and enable a debug mode. The end result is full root control over the T2 co-processor, and quite a bit of control over the entire system.

The need for a physical USB device means that this isn’t going to be used in widespread malicious attacks, but may prove useful for owners of the machines. The author claims that more is coming in the next few weeks. We’ll follow the story and let you know about it.