Hey there,

I hope you’ve been doing well!

Last week I attended ShellCon in southern California, which was awesome. Expect some talk summaries next week.

FYI: several of the links this week are from Marco Lancini’s Cloud Security Reading List, which I’ve consistently enjoyed. Check it out!

Nicole Schwartz told me about pocketsorgtfo.com, a site to help women find great looking clothing that has decent pockets🤘

Joel Margolis released an SSRF testing sheriff written in Golang.

Mozilla has released an ESLint plugin for detecting potential XSS in JavaScript code. See the “Finding XSS in Firefox’s UI” section below for more details.

Rory McCune wrote a blog post about how a YAML “Billion Laughs” payload could cause a DoS when sent to a Kubernetes API server, in some cases as an unauthenticated user.

  • The twist: he tracked the root cause down to the go-yaml library, which is used by many Go projects. Because the vulnerable code was compliant to the YAML spec, the maintainer didn’t feel a CVE was necessary.
  • Interesting to see here the same issue that was pointed out in the Autonomy and the Death of CVEs article: we rely on CVEs to know when we should patch, yet clearly that data set is incomplete for a variety of reasons.

How we built a queryable Application Inventory by Sqreen. Unintentionally, asset inventory has become a through thread of the past 2 newsletters.

  • Being a RASP, Sqreen lives in an app’s runtime, so it knows each app’s stack (e.g. NodeJS), frameworks in use (e.g. Express), and third-party dependencies. They created an App Inventory page that lets you view all of your assets and query them based on these and other properties.
  • Limitations: of course, you don’t have visibility in apps that do not have the agent installed.

On Talks and Conference Submissions

Sarah Harvey shared her accepted Enigma 2020 submission on third-party integration security, including the reviews. It’s neat to see how other people structure their CFPs, much appreciated 🙏

Maddie Stone started a thread asking people to recommend their favorite keynotes. Haroon Meer and Halvar Flake were linked the most.

policy_sentry - IAM Least Privilege Policy Generator

Salesforce released policy_sentry, which conceptually has similar goals to Repokid, one of my favorite tools from Netflix.

So I asked my friend Travis McPeak, the author of Repokid, what he thought, and he said:

I see them as complimentary. Policy Sentry aims to make it easy to create initial least privilege policies and then Repokid takes away unused permissions.

Creating policies is difficult, so Policy Sentry creates policies based on top level goals and target resources, and then on the backend substitutes the applicable action list to generate the policy. This is very helpful for anybody creating the first version of a policy.

To help with simplicity these permissions will be assigned somewhat coarsely. So Repokid can use data to remove the specific actions that were granted and aren’t required. Also Repokid will repo down unused permissions once an application stops being used or scope changes.

Cloudflare on Security

Talk transcript about How Cloudflare Thinks about Security by CTO John Graham-Cumming.

  • Culture statements are nonsense, it matters what you do. Cloudflare has a blame-free culture, which makes employees comfortable emailing the Security Incident mailing list, which is an important first line of defense.
  • Their public bug bounty program tends to be pretty low signal. They also have a paid program with ~150 researchers.
  • For many years they had separate logins and passwords for various internal systems, which was a mess to clean up when someone left. They then created Cloudflare Access so now you mostly just need 1 set of creds. Further, a user’s system access is now automatically removed if it hasn’t been used in a given period of time.
  • Being incredibly open about security issues (e.g. Cloudbleed) has improved public trust in the company and even lead to sales.
  • Keyless SSL lets sites use Cloudflare’s SSL service while retaining on-prem custody of their private keys.

Select quotes:

If I could tell companies one thing they can do to improve their security it would be: sort out identity and authentication. We did and it made things so much better.

Being open about mistakes increases trust.

You can often spot malware just by the DNS queries it makes from a machine. Make sure all your machines use a single DNS resolver and get its logs.

Finding XSS in Firefox’s UI

Frederik Braun gave a Global AppSec Amsterdam 2019 talk: Remote Code Execution in Firefox beyond memory corruptions.

  • Firefox’s UI is written in JS, HTML, and an XML-dialect called XUL. An XSS in the UI gives you arbitrary code execution in the main browser application process. Remnants of XUL in FF include about:preferences and Developer Tools.
  • Grep was too noisy, so he built an ESLint plugin that looks for potential XSS sinks (assignments to innerHTML or outerHTML or calls to document.write(), document.writeln(), eval, and insertAdjacentHTML).
    • This matched 32 code locations, rather than 414-1,000, as with grep.
    • I thought this was a great example of the power of AST matching, which I’m a fan of. So much so in fact that it’s the basis for my ShellCon talk this year 😎
  • Manual review found several exploitable bugs, for example, when hovering over markup that points to an image in the web developer tools. The bugs were fixed in 2017.
  • This security linter was rolled out to their existing set of linters, so the vuln class was solved! Well… gradually more instances of these anti-patterns were added to the code base and then white-listed: // eslint-disable-next-line no-unsanitized/property
  • To mitigate the impact of future similar vulns, they changed how DOM parsing works for privileged JavaScript.

✉️ Wrapping Up

Have questions, comments, or feedback? Just reply directly, I’d love to hear from you.

If you find this newsletter useful and know other people who would too, I’d really appreciate if you’d forward it to them🙏

Thanks for reading!

Cheers,
Clint

@clintgibler @programanalysis