This Week In Security: Baltimore, MacOS Zipfile Security, And App Store Monopolies

Baltimore. The city was breached, crippled and held for ransom. The ransomware attack was discovered on May 7th, shutting down a major portion of the city’s infrastructure. The latest news is that an NSA-written tool, EternalBlue, is responsible for the attack. Except maybe it isn’t? First off, digging back through the history of an attack is challenging. It’s often hard to determine the initial attack vector with certainty.

The “initial attack vector” is the patient zero of the attack — how the first machine was compromised. An organization generally has a firewall separating the outside internet from the internal network. Once an attacker has found a way to access a machine inside the network, the separation is not nearly so strict. This takes many forms, but the most common is phishing. Close contenders are RDP and SMB (Remote Desktop and Windows File Sharing). A report at Ars Technica indicates that the initial vector into the Baltimore network was a phishing email.

The second step to consider is what’s called “lateral movement”, which describes an attacker using the compromised machine to target other machines in the organization. Often an attacker will have an entire toolkit of exploits to attempt to compromise other machines. One of the exploits used in this case was the same exploit contained in the NSA tool, EternalBlue. A clever program called psexec is usually part of any lateral movement campaign. While the exploit associated with EternalBlue was probably used to compromise a few of the machines on the Baltimore network, placing all the blame on the shoulders of the NSA is missing the point. The tool is only a small part of this attack.

MacOS and NFS Shares Inside Zipfiles

MacOS has a sometimes irritating feature, Gatekeeper, that only allows running signed binaries by default. The point of Gatekeeper is to prevent a user from running a malicious binary that has been downloaded from the internet. While it is sometimes an annoyance, it is helpful for some users. [Filippo Cavallarin] announced an exploit that completely bypasses Gatekeeper on the 24th. This exploit takes advantage of the fact that Gatekeeper considers network shares to be trustworthy, and doesn’t run the normal check before executing a binary located there. While interesting, this isn’t useful unless there is a way for an attacker to mount a malicious location as a network share. Enter the Mac’s ability to automatically mount network locations through the use of the /net path. The last piece of this puzzle is the fact that zip files can contain symbolic links. A zip file can be built with a link to the /net location, automounting an arbitrary NFS location. If binary files are located in this location, the OS will happily allow the user to execute those binaries whether signed or not.

This exploit may not be the most serious of the year, but it’s still a problem that needs fixing. [Filippo] contacted Apple back in February and disclosed the problem, even getting an assurance that they would fix it within 90 days. 90 days have passed, and Apple has begun ignoring his emails, so he has made the announcement and published steps to reproduce on his website.

There has been discussion in the comments of this column about vulnerability disclosure and publishing proof of concept code. This is a perfect example of why researchers publish their work. As far as [Filippo] knows, Apple has no intention of fixing the issue he discovered. He also has no reason to believe that no one else has stumbled on this discovery before he did. We mentioned EternalBlue above. The NSA discovered the SMB vulnerability that exploit targeted and used it silently for up to five years before it was stolen and finally disclosed to Microsoft and fixed. Make no mistake, public disclosures and proof of concepts get vulnerabilities fixed. For any given vulnerability, there is no guarantee that someone else hasn’t already found it.

Just a Little Document Leak

OK, maybe not so little. A Fortune 500 company, First American, managed to host millions of private documents in an accessible format. Imagine you upload a document to a company, and get a confirmation link that looks like “test.com/documents.php?id=0252234”. If you’re like me, you’re very curious what is at id=0252233. [Ben Shoval] is a real estate developer who apparently also wanted to know the answer to that question. To his surprise, millions of uploaded documents were available for anyone to view. He tried reaching out to First American, and when there was no response to his emails, he forwarded his findings on to Krebs on Security. After what was likely years of exposure, the database was finally taken offline Friday the 24th.

Walled Garden Monopolies

Staying on the Apple train, the App Store is pretty obviously a monopoly. Someone has finally asked whether it’s an illegal monopoly. As most of these questions go, it’ll take a drawn out court battle to decide. How is this security news? If the court finds that Apple has been violating antitrust laws, one possible remediation is to allow alternative app stores. While there is always the potential for a high quality alternative store like F-droid, sketchy app stores and downloaded are a real possibility. On the other hand, it would be nice to have an iOS app store that is compatible with the GPL.

13 thoughts on “This Week In Security: Baltimore, MacOS Zipfile Security, And App Store Monopolies

  1. “A report at Ars Technica indicates that the initial vector into the Baltimore network was a phishing email.”

    Better reason to abandon HTML mail, and use some PGP so you know it’s legitimate.

  2. “This exploit may not be the most serious of the year, but it’s still a problem that needs fixing. [Filippo] contacted Apple back in February and disclosed the problem, even getting an assurance that they would fix it within 90 days. 90 days have passed, and Apple has begun ignoring his emails, so he has made the announcement and published steps to reproduce on his website.”

    And here we though Apple was one of the good guys with their “user matters” stance against the FBI.

  3. Can’t really blame the NSA when the bug was patched by Microsoft back in 2017. This is all about stupid municipal IT systems which are notoriously horrible.

  4. “Make no mistake, public disclosures and proof of concepts get vulnerabilities fixed. For any given vulnerability, there is no guarantee that someone else hasn’t already found it.”

    Yes, lets give those nasty hackers a big help to infiltrate everyone’s computers!

    These researchers, many demanding a ransom for discovering them, give a company 90 days to fix it, and have those patches verified that they don’t break something else, and then have them installed by users around the world. After 90 days those “researchers” then release the how-to code into the wild just waiting for a hacker to use the exploit.

    Have you ever tested the software like Apple/Microsoft/Google/Intel/etc/etc ? This can take months and still not work correctly. You only have to look at Windows 10 1809 to see this problem.

    I say prosecute those that publicly disclose the bugs because they are aiding and abetting the criminal hackers in their criminal activity, and to top this off they are IMHO committing another crime if they demand payment (or receive payment because that is the implication) of ransom. IMHO no better than the hacker.

    1. Wait, does Microsoft tests code/products ? The windows 10 problems I encounter/read about seem to deny that concept.

      And yes, a big company has the responsibility to understand and be able to fix their product in a reasonable time frame. Given a bug is a localized event, 90 days is enough for fixing and testing. After they publish a patch in the correct channels, it is up to their users to apply said patch, but at least the patch now exists.

      And for Baltimore, etc : why do we accept excuses ? The computers/networks that control important pieces of infra-structure do not need free access to internet/email/www whatever. Just a correct implementation, instead of a slapped-together-by-an-intern one, goes a long way to protect from this kind of problem.

    2. while i agree that demanding payment or face disclosure is ransom and should be looked down upon, it is not ransom if someone says “i will disclose this in 90 days regardless of payment”

      Your argument about prosecuting those that disclose vulnerabilities has the unintended consequence of removing any motivation for companies to take these bugs seriously. If a company doesnt have to worry about disclosure of a bug then what motivation do they have to fix the actual problem? You cant punish the people making the disclosure if you arent punishing the companies responsible for the fix, so you would have to create rather harsh punishments for the companies whose software is responsible for data breeches otherwise companies will not see the benefit of spending the money on a programmer fixing the problem over developing new sellable features.

      Now, we can debate the timeline of when is a reasonable amount of time for disclosure and I believe that if a company is working on a fix then security researchers should work with the companies and give them more than 90 days for a fix if the company is actively working on a fix. That being said, saying that disclosure is bad and should be actively punished is a step back in computer security and benefits hackers much more then disclosing vulnerabilities as hackers will just share the vulnerabilities amongst them selves. Disclosure also forces I.T. staff to implement updates and fixes to protect their own systems, so the blame for systems being vulnerable after disclosure not only lies at the companies who need to make the fix but for companies whose I.T. departments are not testing and implementing the fixes.

    3. I agree. 90 days is wrong. I would give them three. Millions of documents were exposed, and it is all but certain that somebody was exploiting it. Giving them free reign for an additional 90 days is wrong. If the company is unable to fix the issue or take the server offline in three days, they deserve to go out of business.

Leave a Reply to Jonathan Bennett Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.