Weekly infosec news summary for 2017.08.27 – 2017.09.03
"Poor malware analyst. He took various RE courses, bought an IDA Pro license and all he gets are obfuscated JS/PS/VBS scripts." Florian Roth
Account recovery issues
Fortune ran a story two weeks ago about Coinbase customers having their accounts hacked and their bitcoin stolen due to phone number hijackings (link). That same story get's written every month for Coinbase and sometimes other services. The issue is that phone numbers can be hijacked and it sounds like the problem is usually due to password reuse coupled with SMS 2FA codes being compromised. However, often phone numbers play an important role in account recovery where when someone forgets their password and they want access to their account again. Krebs also talks about account recovery issues this week and mentions how email accounts are often a critical anchor for all other accounts (link).
At your company, you should investigate what the account recovery paths are for the services you depend on. How easy would it be for someone to compromise your account at your DNS registrar, your hosting provider, etc? If an attacker compromised your email would they be able to take control of these things? If they compromised your helpdesk, would they be able to compromise your email? One strategy some employ is to use a separate email account outside of their normal corporate email for certain services to mitigate this. However, they then need to ensure they are regularly checking that other account for any relevant communications (ex. billing issues, etc.) which means perhaps mail forwarding rules which potentially circumvents the whole purpose of having this second account. For disaster recovery, you also need to ensure that others at the company have access to that "secret" email account in case something happens to that employee. Usually email distro lists are used for these critical services, but that potentially means that if any of the employees on the distro list get compromised then the attacker could click the incoming password reset email links. Reach out to your vendors to find out what their account recovery paths are.
For your own customers, review what the critical anchors are for how you identify customers and what your own processes are for account recovery. Who has the ability to recover accounts? How are new credentials delivered to customers (ie. Do your employees have knowledge of these in order to read them off over the phone)? What speed can this be performed at? You may wish to enforce that an account cannot be recovered in less than some number of business days to mitigate the speed of an attack. This is a tricky balance between not wanting to lose customers or impact their businesses if they lose control of their accounts, and ensuring you don't accidentally give an attacker control of an account. Take into consideration if your customers are consumers (ex. Facebook) or businesses (ex. AWS). You may also include in your account recovery logic some branching based on characteristics of the customer, for example, you may have stricter procedures for paying customers, more active customers, or ones that bring in some revenue threshold. Some non-traditional options to consider include delegated account recovery from Facebook and Github, and PGP encrypted email communications as offered by Facebook. AWS requires a document be notarized (link).
Dissecting the Chrome Extension Facebook malware
Frans Rosén of Detectify along with Kaspersky Lab analyzed malware that was spreading via Facebook, using Google Docs, and a Chrome extension (link). What I find interesting here is the diversity of technologies.
- The starting point is link shared on Facebook which lands on Google Docs where a PDF is being shared in preview mode, that bounces through redirectors that identify the browser and branch based on that.
- Firefox and Safari users will be asked to install a fake Flash installer, but Chrome users are asked to install a Chrome extension. The Chrome extension communicates with a C2 to provide it the next stage scripts to run.
- The Chrome extension ultimately then targets Facebook to send out links to restart the cycle on new victims. In interacting with Facebook, it grabs a special access token used by an iOS app for Facebook (without the user using iOS) as this has no expiration and can't be revoked by the user.
Conference materials and publications
- BSides Manchester videos: Conference in Manchester, England this month. The talk Cracking The Lens: Targetting HTTP's Hidden Attack Surface and associated paper by James Kettle is especially worth learning from.
- Windbg: A new version of the Windows debugging tool Windbg is in preview.
- Pharos Binary Static Analysis: Static analysis tools for doing things like identifying function calls statically (such as what mutexes are going to be created), automatically generating YARA signatures, and more.
- The two metrics that matter for host security: Diogo Mónica makes that case that important stats for security to monitor on servers is how long they've been up for (lower is better as there will be less drift from the golden image), and freshness of the golden image (more recent is better as it will have incorporated more recent patches).
- Stealing contact form data on www.hackerone.com using Marketo Forms XSS with postMessage frame-jumping and jQuery-JSONP: Frans Rosén appears again this week with a bug bounty against HackerOne due to an issue with Marketo, showing the dangers of including third-party content on your site.
- SharknAT&To: Vulns for the Arris modems provided by AT&T U-verse were identified and full-disclosed. These include a number of hard-coded credentials for such things as SSH access with the ability to upload new firmware.
- RTP bleed: Asterisk and RTPproxy software tries to address NAT limitations in such a way that it allows attackers to send RTP traffic to the RTP proxy and receive the proxied RTP traffic meant for the caller or callee of a different stream.
- Gazing at Gazer: A new APT sample was identified this week by Kaspersky and ESET. The malware and report is largely uninteresting, but what I liked is the identification of the discrepancy between the compilation time of the file, where the PE header shows it as being compiled in 2002, but the certificate that signed the file wasn't valid until 2015. Although it's possible to sign an old file, it's odd, and therefore the timestamp was likely fake. There are many other logical inconsistencies that can happen related to timestamps (I mentioned some related to the Vault7 Longhorn leak in April, link), and I wish more work would be done on that. NCC Group followed up on the Gazer post with the release of a YARA signature for this specific issue (link).
- 320 Million Hashes Exposed: Recently Troy Hunt, of haveibeenpwned.com released 320M SHA1 hashes of plaintext passwords compiled from various non-hashed data breaches to allow future passwords to be cross-checked in a secure manner in the hopes of preventing password re-use (link). These researchers were able to find the original plain-text passwords for 99.9999% of them.