Weekly infosec news summary for 2017.07.09 – 2017.07.16

Quotes

“Realistically & under relevant threat models, we can’t have & don’t need constant time; we need time & resource usage independent of secrets” Solar Designer

 

“A benefit of executing both top-down and bottom-up authentication strategies is sometimes the audience you reach is bigger than you expect. e.g. U2F looks like a “top-down” authentication technology, (relatively) expensive and built to protect Google employees against APT. But then my friend tells me he set up his elderly father, a stroke victim, with U2F for his Gmail. He doesn’t need to remember a password. And he literally can’t self-compromise his account to someone scamming him on the phone, even if he believes and wants to help the person. Protecting a cognitively vulnerable population like that is very difficult, and a YubiKey looks _very_cheap compared to the alternatives.” Brad Hill

 

“Don’t assume you’re not important enough to hack. One of DC Leaks’ victims was a WH intern. And phishing is easy and low risk for hackers.” Pwn All The Things‏

Top stories

The .io Error

Matthew Bryant shows how he was able to register the domain ns-a1[.]io that all .io domains use as a name server, thereby allowing him to take-over any .io domain (link). Many people have chosen domains with TLDs such as .io or .ly (ex. bit.ly) because they couldn’t find the domains they wanted as .com or the they liked the look of the name better. Choosing these other TLD’s has consequences though, both in terms of their security as this .io issue high-lights, or in terms of the regime that ultimately controls the TLD, such as .ly being owned by Libya which has censorship laws, such as not allowing sex related web-sites, and removed the vb[.]ly domain of author Violet Blue in 2010.

Authentication bypass on Uber’s Single Sign-On via subdomain takeover

A bug bounty researcher was awarded $5K for finding a sub-domain take-over on Uber that they then showed how it could be used in combination with other issues to abuse Uber’s SSO in order to sign into any other Uber sub-domain (link). This is an interesting display of “privilege escalation” using web technologies.

Account compromises

This incident report from Nettitude describes how to obtain logs from Office365 and how they identified an attack that had been performed (link). An attacker in a previous compromise of an employee had downloaded the Global Address Book from the compromised account, giving them the account names of all the other employees. They then applied a brute force attack by trying common passwords against each account, resulting in less than one login attempt per hour per account, but one attempt per second across all accounts. This allowed the attacker to compromise 12 accounts, after having only tried an average of 60 common passwords across over a 1000 accounts.

For all cloud accounts, you should enforce strong password policies, ideally prohibiting the top 100K most common passwords, as is now the guidance from NIST’s Digital Identity Guidelines. That will need to be enforced by the identity provider. You should also enforce MFA.

Microsoft’s security team should be doing a better job of identifying brute force attempts, such as doing per IP lockouts. If you’re an enterprise customerof Office 365, you should be asking Microsoft about this, as the attacker was able to make roughly 60K login requests in 24 hours based on the info provided by Nettitude.

Similarly, the Internet radio company 8tracks was compromised this week with a copy of their user database stolen (including user password hashes). This was due to an employee’s Github account being compromised. The account did not have MFA and seems to have been reusing a password that was compromised elsewhere. Your employees should be using password managers to avoid that.

It seems that the compromise of the Github then led the attacker to compromise a system containing backups of the database. It’s unclear if that meant secrets were in the code, Github SSO was used, or how that happened. In any case, backups should be encrypted or protected at the same level as the production servers that host that data.

Tools

• uber/sql-differential-privacy: Uber has released a tool to implement Elastic Sensitivity which modifies the results of queries to a database to preserve the privacy of the contents.
• scriptjunkie/hoarder: Tool that helps compile a Windows executable that makes all syscalls directly. This can bypass many HIPS products as they’ll have nothing to hook in userland.
• BinDiff: The reverse engineering tool for diff’ing binaries, BinDiff from Zynamics, is now available for macOS in addition to Windows and Linux (for free).

Other reads

• Verizon partner leaked data on 14M customers from a public S3 bucket: There are stories about public S3 buckets every week, so I’ve tried to limit how often I report on them. In this story though a public S3 bucket exposed names, addresses, account details, and account personal identification numbers (PINs) of Verizon customers, due to a publicly exposed S3 bucket belonging to a partner. I wrote an entire tutorial to expose the problem of public S3 buckets at flAWS.cloud and Frans Rosen of Dectify has written up more about how to identify public S3 buckets as a ‏security researcher looking for issues with companies (link). Many of these public S3 buckets have problems caused by vendors, such as the leak of Scottrade customers in April (link). This leak though is especially concerning given the problems of attackers taking over victim’s phone numbers to abuse 2FA. This leak includes the PINs of the Verizon customers that are supposed to protect these numbers from being taken over.
• Gandi incident report: Gandi (a domain registrar for 2M domain names across 730 TLDs), had an unauthorized login to a technical partner, that appeared to be from Gandi, that resulted in the modification of the name servers of 751 domain names which then pointed traffic to the impacted domains to a malicious site. Many of the hijacked domains were used for drive-by exploit kits (link), but the MX records were also reconfigured with valid SPF records. This would allow the attackers to read incoming emails (such as password resets) and send outgoing emails as if from the victims. Little information is known about what the attacker did beyond what I’ve mentioned.