Downclimb

2017.04.30

RSS feed

Weekly infosec news summary for 2017.04.23 – 2017.04.30

Quotes

"sometimes, you gotta ask yourself important questions.
Like, how do I put a light bulb on a isolated VLAN so it doesn't hack my TV?" Paul Querna

Top stories

Dangers of providing access to emails

In the wake of some of the bad news about Uber in recent weeks, an article appeared in the NY Times that included information about Uber's competivive intelligence aganst Lyft (link). In order to gauge the health of Lyft's business, Uber purchased data from Slice Intelligence which owns Unroll.me. Unroll.me markets itself as a solution to enable it's users to easily unsubscribe from subscription emails, and to do so users grant Unroll.me access to their email. Data is collected about the emails it sees and then anonymized and sold. This brings up an important problem that users often don't understand the risks of handing out access to their email like this. If unroll.me gets hacked, it would be the same as the users' accounts being hacked. As an example, this would let the attackers perform password resets on users' bank accounts to compromise those. Andy Baio in Wired magazine first pointed out this concern with Unroll.me 5 years ago back in 2012 (link). Unroll.me has collected a lot of email since then, and I'd wager has no where near as good security over those as Google does.

News came out this week from Trend Micro that APT28 (Pawn Storm/Russia) used a similar technique where instead of trying to get victims to enter their usernames and passwords, the attacker would abuse OAuth to have the victim grant their app access to their email (link). This circumvents the incident response processes of many businesses where the procedures to deal with incidents may only be to roll passwords and wipe a laptop. APT28 created their own fake OAuth applications for both Google and Yahoo mail. Hopefully we'll see Google and other companies being more restrictive on what OAuth applications they allow to connect to them, similar to some sort of app store review process, but even then we should expect legitimate OAuth application companies to be compromised so they can be abused for this strategy.

For this specific OAuth problem, you can look at https://myaccount.google.com/permissions on your gmail accounts to see which services you've granted access to your emails. Ryan McGeehan did an excellent job last month of describing other ways your accounts can be backdoored by an attacker in his post The Account Takeover Runbook. In his twitter feed for @badthingsdaily, which describes fictitous incidents, he also proposed an idea for a similar problem:

"Large security company that filters attacks via email has been breached. Email passing through your MX record visible to unknown adversary." @badthingsdaily

OSX/Dok

Ofer Caspi from Checkpoint describes a new malware targetting macOS named OSX/Dok
(link). This is one of the most advanced malwares yet for macOS. The app is legitimately signed and it begins it's installation by setting up persistence for itself in the user's loginitems with the name "AppStore". It has language localization for both English and German for a message it then displays to the user in order to prompt the user for the admin password. It then modifies /etc/sudoers to maintain that admin access. It changes the proxy settings and adds a new certificate authority so it can monitor and manipulate all network traffic. This not only gives the attacker possible collection capabilities, but also another means of obtaining access to the system if it's ever kicked off, because it could modify any installer downloads even over HTTPS. This gives it "fileless" backdoor capabilities, because it can maintain persistent access to an endpoint by having modified it's configurations as opposed to solely through an executable file.

FlexiSpy hacked

Motherboard has been doing a series on "Stalkerware" titled When Spies Come Home about companies that sell software to spy on spouses to see if they are cheating on them. From a technical perspective, these "legitimate" businesses are nearly indistinguishable from malware, and have the advantage that their software can be installed by someone with physical access to the victim's phones and laptops. FlexiSpy and Retina-X are two such vendors, and they've been hacked. Between them the hacker states 130,000 people have held accounts with these companies, making this problem much more widespread than many might think. The hacker has written up how this hack was performed (link), which is similar to the write-ups by Phineas Fisher who had hacked Hacking Team. FlexiSpy has since started a bug bounty (link).

The attacker first searched for all the public subnets of FlexiSpy, and then attempted to brute force password logins to one host (admin.flexispy[.]com). Upon finding that test/test worked as a login, they discovered an IDOR issue that allowed them to enumerate and reset the passwords of all other accounts. Enforcing rules for password complexity, and more importantly having rate-limiting (and two factor) on the login would have helped avoid the initial login. The IDOR issue could have been avoided, but also alerts should have been created for enumeration like this and for any access to canary accounts which should have been created. They also had a Sonatype Nexus repo publicly exposed to the Internet which allowed the attacker to find some default creds and API keys, including a Mailchimp API key to read outgoing emails. One of the publicly exposed SSH servers not only allowed password based logins (which is bad), but also had an admin account with the password tcpip123 which was found in one of the jars from the Nexus server. Once they had access to the internal network, they port scanned. You should have alerts for connections to ports for any services you don't normally use. They obtained access to more boxes including admin accounts, SSH keys, and got on their domain controller. Oddly, the attackers were worried pulling 100GB of network traffic might get them caught, despite all of the other noise they were making. Finally, they tried to destroy as much as they could, including backups and their accounts on various services such as Cloudflare and Rackspace.

Tools

  • docbleach/DocBleach: Java project to remove dynamic content (javascript and macros) from Office, PDF, and other files, for those that are constantly reading content from unknown sources, such as resumes.
  • trailofbits/manticore: Provides symbolic execution, taint analysis, and instrumentation to analyze binaries.

Conference materials and publications

Other reads

  • Verizon 2017 DBIR: Last year the Verizon Data Breach Investigations Report was a mess. It tried too hard to be funny and incorporated a lot of bad data. For example, it said that the FREAK attack (a MiTM issue) was one of the top 10 most exploited vulnerabilities. This year, they've gone back to focusing more on data breach data and less on humor, which is good. Honestly though these reports still don't provide much value other than helping to give some basic stats to show to execs to convince them to give you more budget. For example, it states 25% of breaches involve insiders, and 27% were discovered by third-parties. That last number is interesting because Mandiant's breach report from a month ago stated that 47% of the breaches it was involved with were discovered by third parties. It's difficult to compare these numbers though because Verizon and Mandiant may have similar stats, but could be categorizing them differently. Either way, companies still do not detect breaches themselves as well as we'd like.
  • Russian-controlled telecom hijacks financial services’ Internet traffic: MasterCard, Visa, and more than two dozen other financial services companies were briefly routed through a Russian government-controlled telecom due to a BJP hijack. It's unknown what impact this may have had. People often say that these could just be mistakes, but that is itself distressing that there aren't better controls around this critical feature of the Internet.
  • Webroot pushes bad signature: The AV company Webroot pushed a signature that caused their software to quarantine all signed Windows executables, thereby bricking many computers. Administrators manage their networks through Webroot's web interface which then fell over as admins all desperately tried to change their configurations to stop the damage being done across their networks.
  • Hipchat security notice: Hipchat announced they had a security incident. It's unclear if this was a breach or if they accidentally publicly exposed a server they shouldn't have, although they did say "This is an ongoing investigation and Atlassian is actively working with law enforcement authorities on the investigation of this matter." They also said "The incident involved a vulnerability in a popular third-party library used by HipChat.com." For 0.05% of their customers, messages and password hashes may have been exposed. This is interesting for a couple of reasons. First, they had nearly the exact same incident write-up in 2015 (link), when 2% of customers were exposed. Next, it leaves the unresolved question of how a fraction of their password hashes get dumped, but not all. One way this might happen is if they shard their application such that some quantity of their customers, say 1-100, are on one server, 101-200 are on another, etc. and they must have had an incident on only one server, which also means they are not configuring all of their servers in the same way.
  • Malicious Documents: The Matryoshka Edition: Didier Stevens shows how to use his tools to analyze a malicious PDF and Word document that is contained inside, and then shows some of the mitigations that Adobe and Microsoft have added for these.
  • Chrome to show Not Secure for HTTP sites when input is entered: Currently, the Chrome browser shows "Not Secure" in the URL field for HTTP pages with a password field. In October, Google will get more aggressive with HTTP shows by showing "Not Secure" when any input is entered on an HTTP page.
  • DOUBLEPULSAR infections: After wikileaks dumped an SMB exploit from EquationGroup, it's been used to compromise a number of exposed SMB shares. You should never expose SMB to the public Internet (or really use it at all), and this proves it. Estimates vary, but there seem to be around 1.7M servers with exposed SMB shares, of which perhaps 30K initially had been exploited with DOUBLEPULSAR, but now, due to the exploit being made public, the number exploited is now estimated as high as 400k.