RSS feed

Downclimb: Summit Route’s Weekly Infosec News Recap
2016.06.05 – 2016.06.12:
To receive a weekly email notification of this newsletter, email

Top stories

Intel Control-flow Enforcement Technology

Intel announced it’s new Control-flow Enforcement Technology (CET) which is a mitigation against Return-Oriented Programming (ROP) by providing instruction level support for a shadow stack. Microsoft’s Control Flow Guard (CFG) and grsecurity’s RAP also have sought to mitigate ROP. It’s yet to be seen how effective Intel’s CET will be (Microsoft’s CFG has had workarounds), but if nothing else, we know that the technology will take years for not only people to have the hardware that supports it, but also for programs to be compiled to use it. For example, support for NX, which came out in 2005, still isn’t in many commonly used applications.

Account compromise by phone account hijacking

The FTC reports on an experience of one of their employees of having their phone account hijacked, where someone pretends to be the victim and uses the victim’s free phone upgrades to get a new phone and transfer the victim’s number to this new phone. The danger of this is many online accounts are associated with someone’s phone number for account recovery. For example, someone had their Twitter account taken over this week via this method (see here). Many account recovery processes rely on the concept of someone’s phone, tied to their number, as being something they have. For example, see last week’s mention of Twilio’s coming IPO which is largely used for this purpose. This assumption is unfortunately not true, as the phone number can be stolen, resulting in the accounts being compromised. Expect more of this. Companies like Twitter and Facebook, I believe, are more interested in your phone number for de-anonymizing purposes for marketing, and not for security, which is why few services offer TOTP as opposed to SMS (which is more expensive and less secure) for 2FA.

XSS on desktop apps leads to RCE

In the post Hacking Mattermost #2: Year of Node.js on the Desktop, Andreas Lindh shows the dangers of Electron apps, and all the other desktop apps that are just web browsers. The danger is that XSS on these apps, as opposed to normal web browsers, leads to RCE on the desktop, without a sandbox.

State of Bug Bounty 2016

This report from Bug Crowd has the following high-lights:

  • 63% of all bounty programs launched are private, with the trend being more being private than public. The benefit of private programs is the researchers that participate in them must maintain at least a 50% acceptance rate of their bugs reported. This results in public bounties having 13% of bug submissions result in pay-outs, whereas private bounties pay out for 29% of submissions. Describing this differently, the majority of bug bounty reports are invalid, but for private bug bounties the reports are less likely to be invalid.
  • 25% of vulns discovered are XSS, representing the largest category. This is followed by CSRF (7%), Mobile (whatever that means, is 3%), SQLi (1.3%), Clickjacking (0.62%), and the remaining 61% being uncategorized.
  • Average pay out per paid bug is $295, which is up 47% from last year, and the first quarter of this year is at $505, which is a 150% increase. This could be read a lot of ways, such as companies are becoming more liberal with their payouts, bugs have gotten harder to find or more of the easy ones have been found already, bounty hunters are getting more aggressive at demanding higher payouts, companies need to bump up their payouts to attract more researchers, or some other reason. If you work in bug bounties, you should give thought as to why this massive increase is happening and if it will continue or reverse.
  • A few researchers make a lot more money than others with a long tail of very small payouts. The top 10 researchers received 23% of all payouts. Given that the total payout was $2M, this means the top 10 researchers averaged $47K each, which is not enough to attract talent in some countries.
  • At least 50% of bug bounty hunters are from countries where a little money goes further (India, Pakistan, Philippines, Egypt). 15% of the bug bounty hunters view this as their full-time job.

Typosquatting programming language package managers

Back in February 2015, we saw news of a mis-spelled python library in the story Hostility in the Cheese Shop from Shodan on the package “setuptool” that would beacon home, instead of doing what “setuptools” (the correct spelling) would do. This latest story discusses a thesis that ran an experiment with this idea across a number of package repos, resulting in 17,000 hosts executing their code.

Taking a break from Downclimb for a while

I’ve written a weekly infosec news summary every week for the past 3 years. Although my readers skim it in a minute, it takes a surprising amount of time to put together. I’ll probably get back to it in a few weeks, but I want to do some other things right now.


  • Help Make Open Source Secure: Mozilla has started a fund, with $500K currently allocated, to pay for auditing and remediating any vulns found in key open source software. This is similar to the Internet Bug Bounty sponsored by Facebook and Microsoft for vulns found in widely used Internet software, such as Python, Apache, nginx, etc. and Google’s Patch Rewards program. The difference between Mozilla’s program and the others, is that the others pay only for results, whereas Mozilla’s seems to pay for auditing, whether or not vulns are found, and Mozilla will work on the other aspects of getting these bugs fixed, such as working with the maintainers and getting the patches verified.
  • Morgan Stanley To Pay $1M SEC Fine For Security Lapse: A Morgan Stanley employee copied customer data to his personal laptop, which was subsequently hacked, resulting in the SEC fine for failing to protect customer data.
  • Cybersecurity Snapshot May 2016: Momentum Partners is now doing monthly updates of funding and M&A in the cyber security space.

Conference materials and publications


  • Commit Watcher: From SRC:CLR, a tool to avoid committing important secrets (ex. AWS keys) to git repos.

Other reads

  • Angler exploit kit evading EMET: Despite the title of this article, the evasion used is not specific to EMET. It could have been developed to evade any number of similar security products, but just happened to also work against EMET, or the exploit developer might have just used some of the existing code in memory for his exploit because it was easiest, which happened to evade EMET. In any case, EMET’s anti-ROP capabilities have always been simply a hurdle, and are unlikely to ever be 100% effective. It’s ASR (Attack Surface Reduction which denies DLL’s from being loaded) is a “strong” protection that can completely deny some attacks. DEP and ASLR are also somewhat “strong” in the sense that they force an additional vulnerability to be found (an arbitrary memory read). The anti-ROP techniques are “weak” in comparison, in that no new vulnerability is needed to bypass them, you simply need to spend a bit more time with your existing exploit.
  • OneLogin authentication bypass on WordPress sites: This bug bounty report from Uber has a number of discussion points. The researcher found an authentication bypass in OneLogin’s WordPress integration allowing for RCE. So none of this was Uber’s code, and this problem impacts a range of companies, but OneLogin has not notified it’s customers. It did silently patch the problem. So that’s problematic, but then another interesting point is this is the second time this researcher has found RCE on Uber, but Uber didn’t acknowledge the first RCE (the first was arguably RCE), so this time the researcher backdoored their server as proof of RCE in order to obtain a higher bounty, resulting in Uber’s response “during the investigation of the issue we noticed that you placed an unauthenticated web shell into our web root (bugb.php) which could’ve been used by other malicious users to compromise our website”.
  • Vulnerability spotlight: pdfium vulnerability in Google Chrome: Google Chrome’s PDF viewer had a vulnerability in it due to them having compiled the pdfium project without the needed security flags as the default project has. This brings up the interesting problem that when you look for bugs in code, be aware of all the ways that code is used in different projects, as assumptions in one project might be different in another.