Have you ever thought about all the complexities of a Single Sign On (SSO) implementation? A lot of engineering effort has gone into hardened against cross-site attacks — you wouldn’t want every site you visit to be able to hijack your Google or Facebook account. At the same time, SSO is the useful ability to use your authentication on one service to authenticate with an unrelated site. Does SSO ever compromise that hardening? If mistakes are made, absolutely, as [Zemnmez] discovered while looking at the Apple ID SSO system.
It all starts with the observation that icloud.com has a sign-on that talks to apple.com, two separate domains. The sneaky trick used to make this work is an iframe that embeds the Apple sign-on page in the icloud.com site. There are several security measures that are intended to prevent abuse of that embedded site. The first that must be overcome is the Oauth2 redirect_uri is used to check for a white-listed domain, as well as setting the allowed domain for the content-security-policy header. Put simply, the attack must set a single string that appears to be icloud.com to the Oauth2 backend, but OurEvilSite.com to the browser checking the security policy header. How is this seemingly impossible feet accomplished? By abusing the extreme flexibility inherent in URI encoding. https://OurEvilSite.com;@icloud.com The two different security mechanisms understand it differently, allowing the embed.
The next problem to solve is that the embedded iframe passes messages back and forth with the icloud.com page, and nothing happens if that handshake doesn’t complete. This handshake can be spoofed fairly easily, except for one minor detail. The domain is specified again, based on that same redirect_uri. The trick here is realizing that this URI passes through the decodeURIComponent function two separate times, at various points in the page-load process. Double-encoding a question mark character allows for the needed additional trickery, controlling what this security check sees.
The last hurdle to overcome is the message origin check, a similar security feature. Rather than a clever parser attack, this is overcome with another loophole. If the message source is NULL, this check never happens. The way to accomplish this? Leave off the allow-same-origin flag. That creates an iframe that is partially sandboxed from the rest of the page. Sounds useless? The solution is to embed both iframes in the attacker page, and pass messages through the frame that has permission to do so. With this crazy combination, an attacker can successfully embed the apple.com login widget on their own page.
I know what you’re thinking. So what? Just rip the HTML, CSS, and images from that iframe, and you can replicate it yourself with none of the extra fuss. One more vulnerability turns this attack into something really impressive. To understand it, you first need to understand the handlebars JavaScript library for HTML templates. This library lets you write your page template, and include expressions. You then run the template, specifying the data called by the expressions. The apple.com SSO page uses this library to display custom information from the calling page, like privacy information and the like.
The handlebar library has a special type of expression, }, that allows for unsafe HTML insertion. Put it together, and you could create a valid “Log in with Apple” button that redirects the user to Apple’s idmsa.apple.com page, but inject arbitrary code onto that page. Check out the demo below for the goods.
Hacktivism and Iran
Checkpoint Research brings us a report on recent cyberattacks against Iranian transportation infrastructure. The attack used Active Directory to deploy the payload to connected computers, which were wiped and then modified to hang while booting, showing a message from the attackers. The goal seems to be disruption of the transportation system, and there was a clever exception coded into the wiper program. Machines bearing a handful of hostnames containing “PIS” were automatically skipped. That acronym stands for “Passenger Information System” — the big digital billboards showing status and delays. The attackers wanted waiting passengers to be able to see exactly how badly the system was affected.
Checkpoint believes this is the same actors as a previous attack on Iran, and a pair of incidents against targets in Syria. The self-claimed name is Indra, named after a Hindu god of war. For those of us not up-to-date on Hindu theology, Indra could be thought of as a character similar to Thor. The group claims to be essentially hacktivists against Iran and their funding for terror groups. While Indra has not claimed responsibility for the latest attack, Checkpoint does a good job making their case that the same attack is being used.
CVE Sluething — And Perl Quirks
[Justin Kennedy] from Atredis was in the middle of a red-team exercise, and he came across the Sophos UTM9 threat management appliance. This particular install hadn’t been updated to mitigate CVE-2020-25223, a pre-auth RCE. This was a big break for demonstrating an attack against the client, but there was one little problem. This CVE never got fully disclosed, and no one seemed to have exploitation details. He grabbed a pair of install ISOs, and ran virtualized instances of the vulnerable and patched appliance. Doing a diff on the two versions would be easy on some systems, but these employ a couple tricks to obfuscate the code. First, the Perl is compiled into plx binaries. This can be overcome through use of a debugger, and copying the deobfuscated script from memory. The second problem was that the Perl modules that do the heavy lifting weren’t a part of that recovered code. A fellow engineer at Atredis discovered that the needed modules were actually hidden in a BFS filesystem, appended to the end of the webserver plx. Now with the original Perl source in hand, he could get to business.
There was all of one change in the code itself, an added Perl regex in asg_connector.pm, that checked an incoming SID (Session ID) and potentially threw it out as invalid. Now Perl regex has quite a reputation for being unwieldy and hard for humans to parse. And this is an example of just that.
if ($sid =~ m/[^a-zA-Z0-9]/) { #SID is invalid .... }
[Justin] took a look at this, and thought to himself, ‘Oh, it’s a match string, looking for alphanumeric. And it starts with a caret, meaning it’s only checking the first character of the string.’ I know that’s approximately his thought process, because he wrote, “The updated code shows a check being added to the switch_session subroutine make sure the SID (Session ID) does not start with any alphanumeric characters.” In his defense, he took the hint and looked at how to abuse the SID value on incoming connections as the probable vulnerability, but that’s not what that regex does.
This is worth a quick detour into Perl regex to explain. The =~ m/MyRegex/ construction is the match operator, and returns true if the string it’s acting on contains the text described by the pattern. Bracketed character classes are one of the ways to describe those patterns. So [a-z] would match a single lower case alphabetical character. You can combine them, as is done in the Sophos code: [a-zA-Z0-9] would match any upper or lower alphanumeric character. Now what about the caret “^”, what does that do? Here we see the complexity. Usually, a caret in a Perl regex represents the beginning of the line. This would match on the SID starting with an alphanumeric. However, when the caret is *inside* the brackets, it has a totally different effect. In this case, it works to invert the selection. All this to say, the regex above is actually checking for any characters other than simple alphanumerics, and marking the SID invalid if it finds them. Regex is hard sometimes.
That aside completed, what harm could be done through an SID containing special characters? To answer that, we have to drill down through the code, and see where that gets used. The Sophos system creates a file on the appliance filesystem in the name of each valid SID, and on a new connection, attempts to read that file with a Perl open() call. I hear you groaning, another Perlism. Yes. Perl has a very handy mechanism, that you can open() a pipe to or from another command on the system. It looks something like open(Handle, "netstat -i -n |") Perl will make the system call, and collect the output for you, just as if you were reading it in from a file. It’s very handy, but a terrible security problem if the end user has control over the filename — just like the SID in this case.
Our protagonist found this, and was elated! He had found the vulnerability! He tried it… and it didn’t work. The pipe symbol was removed, and his SID was oddly changed. But wait, while there was a single change in the code itself, there was also a change in a configuration file, the Apache vhost config. The version with the vulnerability fix removed a few settings, most notably an input filter that removes the pipe symbol. He worked for a while trying to find a hole in the sed string, to no avail. And then the answer became obvious: There was a rewrite rule that allowed requests to be sent to /var, and it would re-route to the webadmin endpoint, skipping the filter. And that is the pre-auth RCE. Simply make a request to /var on the device, and set the SID to | touch /tmp/pwned.
T-Mobile Breach
T-Mobile has suffered another huge data breach. Name, date of birth, Social Security Number, and driver’s license information for 40 million customers — anyone that applied for credit at T-Mobile. Additionally, something like 8.6 million current customers had data of some sort compromised as well. If you’re a T-Mobile customer, watch out for scams and fraud targeting you and your accounts. So far not much is known about how the breach happened, besides the standard official statement that it was a “highly sophisticated cyberattack”.
QNX Baddalloc
A series of vulnerabilities have just recently surfaced in the QNX embedded OS. This Unix System developed by Blackberry may not be one of the ones you are familiar with, but it shows up in quite a few devices around us. Just an example, the Driverack PA2 speaker management system runs an older version of QNX. (An older version that happens to have its own pre-auth RCE via a debug port, but that’s another story for another time) The most concerning place that QNX can be found is in transportation and medical workloads. Being a true real-time OS makes it a good candidate for some of those time-critical workloads, which is why CISA has stepped up with the warning.
Airtags for Justice
And finally, an uplifting story where a stolen electric scooter is recovered through technology. [Dan Guido] wasn’t your normal victim when his ride was swiped. He had hidden a pair of Apple Airtags in it ahead of time. Sure enough, he got a ping through Apple’s system, and knew about where the pilfered device was at. He contacted the police, and tried to convince them to help him recover it, and was met with understandable resistance.
Airtags are new, and police are the targets of scams like the rest of us. After taking a break for Black Hat, he went back to the police station to try to recruit official help once again. It took a crash course on Airtags and some skilled convincing, but he did manage to get an escort to go look around the indicated location for the scooter. The used e-bike store seemed like an obvious starting point, and his phone linked directly to his Airtag when he walked in the door. He was able to prove ownership, and take his scooter home.
My scooter was stolen last week. Unknown to the thief, I hid two Airtags inside it. I was able to use the Apple Find My network and UWB direction finding to recover the scooter today. Here’s how it all went down:
— Dan Guido (@dguido) August 10, 2021
At the end of the thread, [Dan] gives his advice for replicating his success. First, hide the tags well, as thieves are already on the lookout for them. Second, don’t use Lost mode. The audible tones give the game away. Third, time is of the essence. Apple has rightly implemented a system to alert potential stalking victims if an Airtag seems to be following them too tightly. And finally, don’t try to play hero. Get the police involved and do the recovery the right way.
No comments:
Post a Comment