Learning from Jenkins, Slack, Twitter and an undisclosed financial institution

For the second issue of A Learning Opportunity, we’re highlighting 4 different stories that hopefully we can all learn from (and not repeat)! If you think this newsletter would be useful to you, please subscribe!


Jenkins Double Release

A recent Jenkins bug made it possible for attackers to get the HTTP response headers from other users. The issue was introduced when they modified how buffer overflows were handled. The new flow would catch the exception and release the header buffer to a pool of available buffers. Then a call to an onCompleteFailure function would add the buffer to the pool again. Once this happens, it was possible for two users to claim, use, and then return the same buffer. From the bug report:

Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with other data. Thread1 then proceeds to write the buffer that now contains different data. This results in client1, which issued request1 seeing data from another request or response which could contain sensitive data belonging to client2 (HTTP session ids, authentication credentials, etc.).

Read more at The Hacker News

Slack Remote Code Execution

In a recently disclosed bug bounty, a security researcher was able to inject HTML into the Slack app and achieve RCE. The researcher also disclosed ax XSS vulnerability with the way Slack stores emails that are sent to it. I encourage reading the bounty itself, but below I’ve tried to create a quick gist of each:

Starting with the RCE vulnerability: when you create a Slack Post, it creates a new JSON file on files.slack.com. It’s possible then to edit this file in the Slack web app to change what’s displayed in the post. Slack blocks javascript execution with its CSP and it blocks a handful of HTML tags (e.g. iframe, applet, meta, script, form etc. and target attribute is overwritten to _blank for A tags). However, it doesn’t block map or area. The researcher used these tags to render a clickable image in the post, which when clicked would load malicious HTML into the app. Within that HTML was a script that would create a new BrowserWindow object. With this object, the attacker can do all kinds of things, including launching child processes or taking control of Slack.

Regarding the XSS email vulnerability: Slack offers the ability to forward your emails to slack and have them shared with channels. The researcher found that you could email plaintext emails to this address with HTML contents, which would then be stored on files.slack.com and served up as text/html. This could be used to create phishing pages or all sorts of other nefarious things.

Read more at Dark Reading

Read Slack Engineering’s Related Post about sandboxing with Electron Apps

A Quick Tangent

Reading about the custom email addresses Slack provides jogged my memory about an issue from years ago. I couldn’t find the original articles, but the crux was something like: Suppose I run a note-taking app that has the ability to email custom-email@mynotes[.]com with your notes, and they’ll show up in the app. When adding this functionality, consider if there are any company services you have that assume only company employees have a mynotes[.]com email address. For example, maybe the only requirement to join your chat app is using a @mynotes[.]com email. The verification would just be sent to their notes and then they could potentially impersonate an employee.

Twitter Fixes Caching Settings

In June, Twitter fixed an issue with its Twitter Ads and Analytics Manager that was storing the user’s billing information in the browser’s cache. If you accessed the site on a shared computer, other users may have been able to access the cached details. They’ve since added cache-control: no-store  to the requests to fix the issue.

Read more at Bleeping Computer

Learn More about cache-control

Malicious AWS Community AMIs

Details about malicious AWS community AMIs were recently released. In this case, the malicious AMI has been mining cryptocurrencies on some undisclosed financial institution’s EC2 instances for five years. All things considered a malicious actor could have achieved much more harmful results with how much power this comes with. This is a great reminder to always be extremely cautious when running things that don’t come from an official, vetted source, AMI or otherwise.

Read more at Threatpost


That’s it for this edition. If you have any feedback on the formatting of the message or suggestions for vulnerabilities to break down, feel free to contact me on Twitter.

Please share this newsletter with your friends and co-workers!

Share