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
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.
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.
6 thoughts on “This Week In Security: Code Scanning, Information Gathering, And Seams In The Cloud”
RE: The T2 Mac Vulnerability by ironPeak.
I was all about sticking it to Apple publicly for ignoring a security researcher who clearly had a working exploit. Responsible disclosure can be a rough dance to get right. Sometimes you HAVE to do a public disclosure if you feel the problem is big enough and you aren’t getting a response.
…Then I looked at his timeline.
18/08/2020 I reached out to Apple Product Security with vulnerability details
07/09/2020 I requested response, lack of feedback
16/09/2020 I requested response, lack of feedback
22/09/2020 I requested response, lack of feedback
30/09/2020 I requested response, lack of feedback, cc Tim Cook
Are you fucking KIDDING me? 6 fucking weeks! What the fuck is WRONG with this person??!!
6 MONTHS is barely acceptable. And even THEN it had better be BIG. Like ‘Oops major 0-day in Cisco IOS’ or “Uh oh, Useable attack on TLS’
“…You could argue I’m not following responsible disclosure…” You’re fucking RIGHT we can argue it! Getting butt-hurt because you don’t get a response in a few weeks? A few weeks during the shitstorm-that-is 2020?
This is some torches and pitchforks behavior right here…
“Are you fucking KIDDING me? 6 fucking weeks! What the fuck is WRONG with this person??!!”…
You are absolutely right! How can anybody expect a tiny company like apple (with such limited resources) to send an email saying “thank you – we are looking into it” in less than 6 months.
Personally (and I’m probably not the only one here) I would suspect that apple doesn’t want to start the clock on when it has known about the problem.
Project Zero is always 3 months…
I have NO love for Apple. Not a single bit.
But being big doesn’t suddenly mean they can do things quickly. Quite the opposite actually.
First, they would have to see it. And Apple SURELY get’s so much garbage in it’s official channels that it takes a long time to sift the important bits from the sludge.
Then it’s got to actually be evaluated.
Then go through the legal team and probably the engineering/security team too.
And all of that before they EVER respond.
How much longer than ‘normal’ do you think that takes during a pandemic?
I’m not sure what it’s like where you are, but here, we still can’t eat-in restaurants, stores only have 1-2 registers open at a time since we are all encouraged to order ahead and pick up in the parking lot, and even basic stuff like getting an appt. for a 60 minute call with a lawyer over Zoom takes 3-6 weeks.
But, we don’t know the whole story. This could TOTALLY be like when Cisco dragged it’s feet for a year and used the courts to silence security researchers instead of fixing a critical bug.
But it could also be an unreasonable researcher who jumped the gun…Hell, if they took the time to mention that what they were doing might not be responsible disclosure, maybe they should have tried to work through a few more channels before releasing.
I’m sorry but you’re talking pure shit!!!
“Apple brings in about $70,000 in profit every 60 seconds” That’s profit NOT turnover!!! This means it can afford to bring on board 2 new highly skilled devs every five minutes to deal with new issues. And don’t even get me started on “they would have to find space for them”… Have you seen the apple corporate headquarters, all 2,800,000 square feet!!!
Being big is no excuse for avoiding issues. If anything, being big should make you better able to cope with issues when they arise.
By your criterion we should expect better service from smaller companies who have infinitely less resources to deal with problems then apple do.
“I have NO love for Apple. Not a single bit”…
I begin to wonder if this is not the exact opposite. Are you one of those employees that is paid to deliberately mislead the public.
“But it could also be an unreasonable researcher who jumped the gun…”…
They didn’t even get an acknowledgement within 6 weeks and they are the bad guys – give me a break. So if someone takes over your Mac (while you’re working from home because of COVID-19) and sends an email spoofed as coming from Apple then maybe you should pay Apple compensation for any possible inconvenience to them?
Honestly people like you just make me want to puke
I wonder if that T2 exploit could be used to bypass primary SSD lockout…
Please be kind and respectful to help make the comments section excellent. (Comment Policy)