ESP8266 Swiss Army Knife RazorEvzr

While my Grid Computing Library (GridMan) has been updated and is now performing a brute-force on the WPA which i intend to use later to POC  i started working on a 1Tool to rule them all on ESP.

zxzx

oo
GridMan offsite Lab

 

GridMan Manager App on iPhone

I noticed that when i play with pen-testing i always have hard time to decide and setup on the tools i will be using. So i figured out i might be actually able to try to utilise ESP8266 at it’s max to do most of the ‘dummy’ work for me either acting as a throwie or simply having him in my pocket.

Most of the times i need to run Kali, play with the shell scripts and this is painful as it always requires me to hook up the keyboard, find out the scripts which i already forgot about and basically, it takes too long.

I needed something quick, where i just choose an option, start and leave it for results.

That is how RazorEvzr was born, which is basically my Swiss army knife tool for pen-testing. The idea behind this tool is that i power it up, i select a plugin and let it go. If power is loss, it auto resumes when plugged in again. All that kind of stuff had to work automatically, plugins should be easy to develop and that’s how i got it after few days of playing.

koko
RazorEvzr EvilTwin running

So far i have made 3 basic plugins for a pen-testing start so far.

  1. EvilTwin attack – which basically clones the victim AP and kicks off the captiva portal by redirecting all DNS queries to the ESP. Captiva is there to grab the password by forcing eventual victim connected to provide an AP password (as it was upgraded) – when input is sent, ESP tries to connect with provided password and if succeeds stores it.
  2. MIMi – that’s something i wanted initially as more complex solution but became a simple tool to sniff for the DNS queries. It’s a MIM, so i need to have an access already to play it. What it does is connects to AP, fires off own DNS server, fires off own DHCP server that offers own pool of addresses with a DNS server set to ESP, for DNS Queries logging. The rest of the DHCP Addresses stay the same (gateway, netmask,…) only DNS is set to ESP, to allow traffic to flow to the proper gateway/router but DNS queries to be sent to ESP.
  3. MIMI2 – where we basically use the lwip library to start ESP as a NAT router. What it does? You just select an AP you wish ESP to connect to, let’s say a public AP somewhere in the city center. ESP connects obtains ip addresses, internet works fine – but then it starts also AP mode (so all in all AP_STA). You wait for the victim to join ESP AP, and log the traffic down to a file while routing it to the public available WiFi – thanks to this, a simple WiFi Proxy allows for a great MIM in public places.
    Just go there, fire off ESP – it will create a public network, connect to a WiFi hotspot already existing, but will advertise with some catchy name (either with A at the beginning to be first on the list) or anything else you can think of.
  4. To Come – Probes are still alive, so a good example of a plugin would be to sniff for probes in the air and setup/respond with beacons and immediately setup the AP for the client devices to think that the network they Probe for is in range. Why? Well besides POC, it is a good technique to play with to see how many devices will actually connect, and if that works use MIMI2 to start sniffing for the traffic in the MIM manner.
  5. Will rewrite more of the previous examples i had (i.e Bruteforcers )

 

All of the plugins store data in a central log file on the SPIFFS that i can review later on when device let’s me know something good happened. I hooked up a LED so it blinks when plugin returns success i.e EvilTwin has password stored or MIMI2 has clients connected.

 

Zrzut ekranu 2018-06-23 o 21.27.12.png
RazorEvzr charging

 

Unfortunately ESP8266 is heavily limited by Espressif. It would be a great open hardware for security research but it’s not even half way through. With a limited functionality of the packet sniffer, possibility to craft and send own 802.11 packets – we’re left with what they give and try to use it as much as possible. There would be much more security tools made on this hardware but not much more can be done. Imagine if we could sniff and inject the packets freely.

 

Hack the planet.

Advertisements

esp8266 Bruteforce #2 CRAR

Zrzut ekranu 2018-03-27 o 22.40.18

Next day – next step.

So while being at the hotel after hours i finally decided to spend time on coding CRAR instead of watching the German Eurosport. One – i don’t understand a word, two time flies 3x faster during coding – so as i’m pretty much waiting for end of week to depart from here i started coding and testing.

First of all – Victim

So in order to test CRAR properly i had to find a good victim. Quickly downloaded the LAN Scan tool to figure out what’s happening here. The Hotel has a free WiFi connection so there should be also some router here that you can login to manage it. Quick scan revealed a good target for the game.

A

I opened the web page to figure out what am i trying to achieve here and i found what i was looking for. Simple login page using a POST to a PHP script – meaning we can easily craft the data and keep on sending. The web page presents itself as : Tiger IP Connect 5.1

Zrzut ekranu 2018-03-27 o 21.56.28

Googled quickly to figure out what is this – seems like a dedicated software to control/manage access to AP (see here). Doesn’t really mater as long as i can test CRAR on it. So, knowing we have a page to login, let’s see how data is posted to this http server. No fancy investigation was done just a view into the html output from this server.

Zrzut ekranu 2018-03-27 o 21.56.34

I easily found that the form with user/password is POSTing to index.php. Well with all that in hand i was ready to launch the ESP (well took one for a trip, knowing i will be bored as hell after hours hehehe).

Secondly – the configuration

Right, i hooked up my ESP to my Macbook and as the software was done  i started configuring the brute-forcer as per the details taken from the web page form.

B

There are couple updates here since my last post, mainly done for ease of setting up the whole process. Let me guide you through what are these settings.

  1. ESP starts in AP_STA mode, so that i can access it’s own WIFI when craxor is connected to victim AP. Thanks to this i don’t have to connect to victim’s WiFi anymore, i can reconfigure CRAR by connecting to the hotspot it creates.C

Settings are as follows:

  • WiFi – self explanatory, target (victim) AP SSID
  • Password – target (victim) AP Password – in this case, no password, public hotspot
  • Host – the HTTP ip address
  • URL – the URL for the POST
  • Body – the arguments for the POST (taken from the html form definition above), here i assume that the username is admin, why not. It’s just testing, nothing serious 😉
  • Min characters – this is to indicate minimum characters for Wordlist generator
  • Max characters – this is to indicate maximum characters for Wordlist generator
  • Socket Timeout – this is for the socket connect function, so it doesn’t get stuck waiting for socket to timeout, i make it 200ms
  • Charset – this is for the wordlist generator i basically say here that i want to generate 6 characters long including lower case, upper case and numbers.
  • Success Word – hehe bad naming but this is the text that when NOT found means we got this form cracked. Why ‘not’ found ? Well it’s because it’s hard to guess what page displays when login is OK, so it’s better to see if failure text is present every time we check new word from generator. If Failure text is not present, we might be already logged in!

Controls

  • Start – which is to start the bruteforce process
  • Pause – which is to pause the bruteforce
  • Reset – which is to restart the ESP (start from setup())

Status

  • Started flag (1/0)
  • Current Word – that’s basically the word we test against now
  • Total Epochs – number of epochs passed (iterations basically)
  • Epochs / sec – number of iterations per second
  • WiFi Signal – yeah, signal to the AP
  • WiFi Connected – just a flag if we’re connected

Results

Self explanatory 🙂

Page down there are more debug things you might be interested in, so here is the screen

Zrzut ekranu 2018-03-27 o 21.56.57

Basically what we see here is

Sent – what we have sent to the server

Received – what we have received from the server
Based on  received text area  you can deduct why i put “Invalid” in the Success Word field.

If Invalid is found, it means we have probably logged in. As long as this word is present in the response, we know we have provided invalid credentials.

Ok, so i’m leaving this soft running until the last day, we will see what happens, overall it’s just a test of the soft and the overall POC. As resuming the wordlist generation is also implemented, i can easily turn off and on ESP and cracking will continue from the last word saved.

Zrzut ekranu 2018-03-27 o 22.44.18

Will see where we are on Friday with that 😉

 

Peace

 

esp8266 bruteforce #1 CRAR

Zrzut ekranu 2018-03-26 o 20.43.02.png

Synopsis

Warrning – i have not enough photos in this post – basically writing it in a hotel.

Sundays are lazy days, that one was no different – with a cup of coffee and e-cig i was looking around for an idea when i realised i still have my Kali Linux laptop lying around and i can actually try to see if there is anything interesting around (last time i checked it was months ago). I moved last year to new home and pretty much haven’t played with Kali for some time. It was a good exercise to do and i just went for it.

Plugged my laptop into a socket (one of these laptops that do not work on a battery anymore 🙂 ) and sat again on the same couch. Quick scan and i realised there is some week/poor WPA2 / WPS signal broadcasted, isn’t something that i could use as a backup internet, but still was ok-ish to check against WPS (reaver) attack.

I kicked off Reaver and started cracking and went around the WPS weakness even though the signal wasn’t that good. After couple of hours pinning the WiFi router i finally got the key and connected. After adjusting the antenna several times i figured out that the network i have connected was running near my home, the distance was around 30m (garden). Signal was absolutely weak.

Quick scan of the LAN revealed two interesting hosts one of which was a router with some sharing enabled (ftp,http opened).

As usual, the dumb-mode test has been executed and i found there is no admin/admin, admin/password or even anonymous access granted to both the http / ftp. Opening the web page of the router gave pretty much a login screen and that was it.

The quality of the connection wasn’t enough to keep alive for longer than couple of minutes, either it was dropped or i had pings lost, so checking above credentials took me some time and patience.

I figured out at that point that there is absolutely no sense to push on testing it that way and it would be more beneficial if i think of a solution to leave this process automated close to the garden fence and forget about it until something is found.

Let’s get dirty and prepare a plan

What do i want to automate?

I want to get into that http://192.168.0.1 which is serving the HTTP login, forget the FTP for now – i guess when access to HTTP will be granted, we will get access to all services there.

How do i want to automate it?

Brute-force – just go with the most simple approach but keep the process flow inteligent by ensuring that when power is lost, we don’t start from the beginning, that we can get a wordlist or go full hardcore by doing a words generation for fun. Also, i don’t need a process that takes me minutes to setup – the game itself is considered a waste of time, so need myself spending +10minutes on starting laptop, bash scripting and stuff – i need something low level and firing up straight away when switched on.

Deciding on the right hardware

Knowing all of the above i realised that the best solution for my exercise would be a esp8266. I always believed ESP’s are made for more than just turning the light on/off as an IOT device. I see two possible options here

  1. Put the ESP8266 with a power-bank into a Coca Cola bottle (to make it water resistant / rain / snow ). Fantastic idea to drop these kind of things wherever needed, but there’s a big problem here – Battery.Zrzut ekranu 2018-03-26 o 22.02.59Well as this is just a fun project  i don’t mind; i know brute forcing can take ages so i don’t mind to pick it up from time to time and recharge. Software however needs to tackle this properly – as mentioned earlier, once dropped i never get back to it for setting up, only recharging.

    Above require a software to notify about the low battery – but i’ll get to that later on.

    Ps. How cool would it be to have it running for weeks on batteries, in that case you could drop it in some distance place and come back for it in days.

  2. Install the ESP8266 in the garden lamp (already 12Volt enabled) – and keep it running there for ages – seems like the simplest solution without any cons. But, i don’t like it – i like the idea of having an option to drop a cracker somewhere or stick it. Lamps are generally already installed, i doubt i will get a good signal out of them – so this is a NONO – however a possibility.
    Zrzut ekranu 2018-03-26 o 21.29.10

 

So out of these 2, i choose option one and try to ensure it gets ultra small size – don’t want a 2L coca cola bottle lying in my garden whole summer 😉

For that i’ve seen already good projects for IOT gardens – i’ll copy a good solution and post a photo in next update.

So having hardware plan already, i move on to the next step.

Software – bringing life

Let’s start with the assumption that CRAR is not a WiFi cracker, so in order to operate it already needs wifi credentials – but that’s all clear.

Now the logic behind it should be ultra simple:

  1. Start
  2. Load config (contains last word from which to resume and other settings)
  3. Check if WiFi connected
  4. If not, reconnect, goto 3
  5. If yes, connect to the specific IP address (tcp)
    1. if not connected goto 6
    2. if connected
      1. send a prepared url as an HTTP packet
      2. check for the response
        1. if response contains “SPECIFIC_WORD/CONTENT” – cracking completed
        2. if response does not contain “SPECIFIC_WORD/CONTENT” – not cracked
      3. generate next word (wordlist generator)
      4. Save Config
  6. Serve HTTP web page so we can access this esp and check for stats
  7. Send out notification (via pushover) when Cracking completed / Battery level low

Voilla, that’s it.
This logic ensures that when this nitty device gets plugged in – it loads up the latest word  and resumes from it. That we have a wifi reconnection tackled and that we are serving a Web server – at any time we can control the device with a simple web server, and that we finally get a notification when things are done / about to be off (battery)

As usual i started coding

Zrzut ekranu 2018-03-26 o 20.22.33

This is a screen shot of an esp running a brute force against a Raspberry PI PHP crafted page to see if all works fine – looking at this already, i spot a place for a more distributed approach to this cracking, but it’s not a rocket science so i leave it up to you:)

Next step is to move it really to a production environment, meaning i will be sharing more shots of the victim’s router, hardware and some code snippets – where finally i will drop it in the garden and we will all start the timers. We will see if CRAX0R makes anything out of it 😉 If not, it’s still a great fun!

Stay tuned.

Market games

Interesting sshots of BTC Markets games.

1. Forcing price to go up? (Quote) Spoofing?
zrzut-ekranu-2016-10-28-o-16-13-37

One of the market kicks in simulating trades at a very high price, trying to fire an order to catch ARB on this obviously misses the orders. Both because of latency ( BTC markets serving their API through CloudFlare cause a significant delay ) and because of the fact they do it ‘locally’ – probably to force the price to move up and speculate. Or i am not reading this correctly?

IoT – The WiFi Probe REQ an RTLS. Tracking WiFi Devices for a penny.

zrzut-ekranu-2016-09-14-o-08-35-27

Every WiFi enabled device that you have (laptop, phone, tablet, kindle, watch, … ) is sending a PROBE REQuest packets in background to figure out if there are any known AP’s.
It’s done transparently, wether you are in a shopping center, outside in a park, or in the mountains – it’s a continuous process.
If an AP is found the device automatically associates to let you stay online ASAP. This is built in the 802.11 protocol. (More)

Knowing that every single device is broadcasting a Probe packet i figured out that it might be interesting to place couple of ESP8266 around with sniffer mode enabled to listen to these Probe Requests and forward them to a central server for analysis. The idea behind that is to be able to track every device between zones (places where ESP8266 are located) and guess what, i had couple of hours free to code and try it out.

I placed couple of nodes in different places within the city and enabled sniffer mode that looks for 0x40 802.11 type packets (PROBE REQUEST). When a packet is received it is sent out to a central server where packets are stored and presented later on on a web page.


This time i used ESP8266 on a ‘Witty’ chip – it’s a cool 2cmx2cm sized board that has a single button, rgb led built in and obviously an USB power. Pretty cheap, you can get tons of them for almost ‘no money’.

Every single ESP8266 device in this system that listens for packets is called ZONE, so if you place 4 of them in different locations – you have 4 zones. I have placed 2 of them for tests, one in the Garage and one outside in the area where i live. This is to figure out if i can determine wether people (and at what time) travel between garage and main area, how often and at what time. Time for a start, ESP’s placed, kick started – analysis time.

zrzut-ekranu-2016-09-14-o-08-51-13

The above graph shows number of packets for every hour in last 24hours, there’s a quite number of packets received as you can see, big-data time 😉

As i have two zones, let’s see how active they are – meaning, when was the last packet received at which zone – this helps me out to determine the Per-zone activity and eventual down-times of the zone nodes.

zrzut-ekranu-2016-09-14-o-08-52-49

You can clearly see that both zones received their last packets 2/3 seconds ago – so somebody was hanging around there with a device sending probe requests, good! Let’s move on, let’s find out what is the packet per zone distribution.

zrzut-ekranu-2016-09-14-o-08-54-28

Sensible, the MAIN zone that is outside in the main area of my home is definitely more active, garage makes only 6.7% of all the packets received. Let’s find out what happened in GARAGE in last 24 hours.

zrzut-ekranu-2016-09-14-o-08-55-52

Ahh more graphs, more stats – fantastic. GARAGE Zone received 62 Probe packets in last 24hrs, the peak was around 7 am (where people started to jump into their cars to drive to work).  In total there are 17 UNIQUE devices found, so potentially we can assume there were 17 persons in the zone. Need more info…

zrzut-ekranu-2016-09-14-o-08-57-28

Brilliant, i can see which device was the most ‘popular’ one, meaning was having the biggest ratio of PROBEs sent across the 24hrs time and in total. Beside i can see live packets coming in from the ESP. Let’s look at this B0:79 – looks like the most popular one, a single click on the device and we’re entering a Device tracker sub-page where..

zrzut-ekranu-2016-09-14-o-08-58-54

I can figure out that it is a Motorola device (based on MAC OUI) and

zrzut-ekranu-2016-09-14-o-08-59-04

This Motorola sent 32 packets in last 24hrs, it was seen only in one zone (GARAGE) and it was most active today at 07:00 AM. Great, let’s go deeper…

zrzut-ekranu-2016-09-14-o-09-01-03

Above is a confirmation of the fact that Motorola was seen only in Garage (wasn’t captured by MAIN zone) – live packets on the right hand side. But let’s see the whole history of this device shall we?

zrzut-ekranu-2016-09-14-o-09-02-31

You can clearly look at each of the devices found and track it’s activitiy. What’s even more i can see the RSSI value – that tells me the distance of the device to the zone node.
This Motorola was first found today at 02:52 AM, interesting. The RSSI tells me it was probably on the opposite side of the garage (which is quite big) – meaning far away from the node! Knowing the Garage i can immediately figure out where this person was moving.

Let’s go back and pick up different device.

zrzut-ekranu-2016-09-14-o-09-17-25

zrzut-ekranu-2016-09-14-o-09-17-48

This one is more interesting, somebody was seen in both zones with this device, i wonder at what distance and time.

zrzut-ekranu-2016-09-14-o-09-18-50

First seen at 7:54 today, wen to a garage (7:55) and was pretty close to the NODE at 7:56. Then the signal is getting weaker (jumped into the car probably) as minute later the signal was lost.

As you can see a simple system that costs $3.20 for each node can be turned into a quite sensible real time location service. Knowing that a deployment of 100 of nodes is still low cost – you can imagine how this can help out in business stats, emergency tracking, and advertisement targetting systems (tv screens knowing the profiles  (vendor) of candidates per week/month/season can push targeted ads). There is a big space for project like this to go live and for sale. It’s nothing new – but it’s definitely the most affordable one you can get ($3.20 for a node!).

zrzut-ekranu-2016-09-14-o-09-23-25

zrzut-ekranu-2016-09-14-o-09-23-44

In terms of the project – i keep it live, costs almost nothing so i’ll be adding nodes just for fun 😉

Update. I recalculate RSSI to Meters (distance), it makes more sense now.

zrzut-ekranu-2016-09-14-o-12-05-40

 

WPA Bruteforce test

Just a side note, i’ll be getting to the crackers i wrote later on – but been testing WPA update since couple of days now on WPA Handshakes and the cracker is a success.

ddd

This is a single core task – but have a Distributed Task for GridMan in place already.
The cracker goes through all WPA handshakes that i have sniffed and tries to crack them with a wordlist or a bruteforce generator.

macs

Above a dump from a modified version of a handshake stripper, i take the airmon dump file and strip all WPA Handshakes that were found for a crack-all-at-once approach.

Ok, let’s find out what’s sitting there and let me tell you that i hate Linux support for WiFi – it’s just a mess if you need to do things quick, but as i’m left now with a Raspberry PI on the balcony that has Kali installed, there’s no other option around.

Couple of command line entries and we’re in.

aaaa

 

Now that we know we’re in, let’s checkout the AP.

Zrzut ekranu 2016-08-06 o 22.58.04

Aha! A login form, i can bet the owner didn’t even change admin password.
admin/admin is the default setting for WR340g.

Zrzut ekranu 2016-08-06 o 22.59.05

dodo

Fuzzing continues

Just made a simple fuzzing strategy that shoots random characters on arguments for binary. I am testing this on my MacOSX – and it seems like it works 😉
Zrzut ekranu 2016-08-05 o 23.36.23

The tool itself is dirty coded yet, however fuzzing Rez with argv0 gave

SIGSEGV 11 Invalid memory segment access (ANSI)

 

Splendid.