Viele Unternehmen stehen vor der Entscheidung, Windows 10 oder vielleicht doch was anderes? Aber was wäre denn „das Andere“?

Die Nachrichten häuften sich mit immer neueren Bekanntmachungen des ‚nach Hause telefonierenden Windows 10‘. Hat Microsoft auf die kritischen Stimmen gehört? Ein aktueller Security-Kurztest des in Windows 10 umgesetzten „Privacy by Design“ ergab folgendes: Basis für eine aktuelle Bewertung ist der im November für Windows 10 Enterprise ausgelieferte „Gib mir mehr Privacy Settings“-Patch. Dieser bietet Unternehmen eine weitaus größere Möglichkeit an Privacy-Einstellungen als die Versionen Home oder Professional. Nach Angaben von Microsoft ist das eine Reaktion auf Unternehmensforderungen nach einer höheren Transparenz im Bereich Sicherheit und Datenschutz als bei Professional.

Enterprise-Kunden wird dennoch empfohlen, die neu angebotenen Einstellungen doch bitte nicht zu benutzen:

“Our enterprise feature updates later this year will enable enterprise customers the option to disable this telemetry, but we strongly recommend against this.”

By Terry Myerson / Executive Vice President, Windows and Devices Group

In dem Dokument „disconnect your organization from microsoft“ empfiehlt Microsoft dagegen Privacy-Einstellungen, um die Verbindung zu ihren Servern zu kappen.
Sollte Microsoft tatsächlich plötzlich seinen Enterprise-Kunden die Möglichkeit der vollen Kontrolle über die Enterprise-Kunden eigenen Daten geben?

Weniger Daten – ABER…

In mehreren Testumgebungen wurde Windows 10 Enterprise mit den von Microsoft vorgeschlagenen Privacy-Einstellungen analysiert. Zwar werden weitaus weniger Daten als früher und bei den Home- und Professional-Versionen an Microsoft gesendet, dennoch werden auch bei Userinteraktionen Verbindungen zu Microsoft aufgebaut, die keine erkennbare Kommunikation mit Microsoft-Servern benötigen. Z.B. führt eine einfache Dokumenten-Suche auf dem Windows 10 Enterprise System zu einer verschlüsselten Verbindung zu www.bing.com. Werden die verschickten Pakete entschlüsselt, erkennt man HTTPS Anfragen an die URL www.bing.com/manifest/threshold.appcache. Diese beinhalten mindestens 10 verschiedene Cookies, die es Microsoft ermöglichen, User eindeutig zu identifizieren.

Richtig ist, dass bei einer Suchanfrage weitaus weniger Daten an Microsoft gesendet werden als früher: Da wurde für jeden eingegebenen Buchstaben eine Verbindung aufgebaut. Es fehlt ein Hinweis, warum und vor allem was Microsoft an den eingegebenen Suchanfragen interessieren könnte. Unter IT-Sicherheits- und Datenschutzaspekten dürfte dies als kritisch bewertet werden.

Spezielle Tools nötig

Nur mit den von Microsoft zur Verfügung gestellten Mitteln kann kein ausreichendes Privacy-Niveau erreicht werden. Daher stellen einige Drittanbieter spezielle Tools zur Verfügung mit denen weitere Privacy Einstellungen vorgenommen werden können. Z.B. die entgeltfreien Produkte Ashampoo® AntiSpy for Windows 10 und W10Privacy. Diese bieten, zum Teil über die Registry oder Windows 10 Firewall-Einstellungen, weitere Möglichkeiten, Kommunikationsversuche von Microsoft zu blockieren.

Bei Unternehmen, die wertvolle Sachdaten und/oder personenbezogene Daten verarbeiten, sollte eine sorgfältige zum großen Teil manuelle Analyse des Netzwerkverkehrs durchgeführt werden, um alle Services zu blocken, die trotz aktivierter Privacy-Einstellungen ins Internet unkontrolliert kommunizieren. Hierbei muss natürlich beachtet werden, dass die Services nicht mehr benutzbar sein könnten, die bestimmte Kommunikationsverbindungen voraussetzen.

Fazit

Fazit dieses Kurztests: selbst mit dem von Microsoft zusätzlich für Unternehmen bereitgestellten Mitteln werden Daten wie z.B. Nutzerverhalten an Microsoft gesendet. Bei der Entscheidung für oder gegen ein Betriebssystem, muss eine Bewertung hinsichtlich einer ganzen Reihe von Parametern wie Nutzen des Betriebssystems und Kontrollverlust über die eigenen Daten vorgenommen werden – insbesondere zu Security und Privacy.

Autoren:

Prof. Dr. Hartmut Pohl, Geschäftsführender Gesellschafter softScheck GmbH

Veröffentlicht von Martina Bartlett-Mattis auf Trendreport.de
Aufmacherbild / Lizenz / Quellen
„Computer Security“ (CC BY 2.0) by  IntelFreePress 

The post Datensammelwut beherrscht? appeared first on softScheck GmbH.

While cloud communication was found to be reasonably secure for an IoT device, we discovered two insecure proprietary local configuration protocols: A human-readable JSON protocol “encrypted” with an easily reversible autokey XOR cipher and a binary DES-encrypted configuration and debugging protocol (TDDP – TP-Link Device Debug Protocol). TDDP is in use across most of the TP-Link product line including routers and access points and thus merits further research. We also release a Wireshark dissector and two python clients for the proprietary protocols on GitHub.

View on GitHub

Contents

1. Security Analysis Summary
2. Device Setup
3. Reverse Engineering the firmware
4. Busybox
5. Portscan
6. TP-Link Smart Home Protocol
7. Test Mode
8. TP-Link Device Debug Protocol

1. Security Analysis Summary

The Good:

• Cloud functionality can be turned off
• Cloud communication uses HTTPS and CA pinning
• Stores energy monitoring data locally
• Firmware update checks signature against RSA keys

The Bad:

• Useless encryption for local communication
• No authentication: Anybody on the local network can turn the Smart Plug on and off, reset it or render it inoperable
• TLS cloud connection could be intercepted with any valid Symantec EV certificate (only Root CA is checked)
• Phones home even if set up as local-only
• Undocumented configuration and debug service (TDDP)

2. Device Setup

The Smart Plug has two physical buttons: An on/off relay switch and a device reset button that resets the device if pushed for five seconds or longer. When plugged in, an unconfigured or freshly reset Smart Plug will start an unsecured open Access Point with the SSID “TP-LINK_Smart Plug_XXXX” where XXXX are four hexadecimal numbers. A quick search on WiGLE reveals several unconfigured TP-Link Smart Plugs in the wild:

 
TP-Link’s Smart Home app “Kasa” makes the smartphone connect to this access point, sends UDP broadcast packets to 255.255.255.255 to find the Smart Plug IP and proceeds to configure it with the SSID and password that the user entered into the app. The Smart Plug then turns off the Access Point and connects to the configured WiFi as a client.

We perform a KARMA attack using the Sensepost MANA Toolkit, forcibly deauthenticating the Smart Plug and trying to get it to connect to a rogue Access Point with the same SSID and no security. The attack is not successful; however repeated deauthentication can be used to perform a temporary Denial of Service attack against the device.

3. Reverse Engineering the TP-Link HS110 firmware

We download the current official firmware for the device (HS110(US)_V1_151016.zip) and use binwalk to extract the contents of the .bin file:

 
As we can see, the firmware is a typical embedded Linux system and contains three parts:

• U-Boot Bootloader 1.1.4 (Oct 16 2015 – 11:22:22)
• Linux Kernel 2.6.31—LSDK-9.2.0_U11.14 (yt@yangtao.localdomain)
• Squashfs filesystem

Examining the contents of the filesystem, we find the following interesting files:

• /bin/busybox v1.01 (2015.10.16-03:17+0000)
• /etc/newroot2048.crt

This is the certificate used to verify the identity of the cloud server. The file contains the “VeriSign Class 3 Public Primary Certification Authority – G5” root certificate. This means the only check performed when establishing a TLS connection to the cloud is if the provided server certificate has been signed by the Symantec/VeriSign CA for Extended Validation (EV) certificates (CA pinning). A determined attacker could buy his own EV certificate and use it to impersonate a cloud server.

• /etc/shadow

root:7KBNXuMnKTx6g:15502:0:99999:7:::

The oldschool descrypt password is trivially broken, the password is “media”.

• /usr/bin/shd – the main server application
• /usr/bin/shdTester – client for energy monitor calibration
• /usr/bin/calDump – dumps wifi calibration data from /dev/caldata

All proprietary server logic is contained in the shd (“Smart Home Daemon”) binary, which is MIPS32 R2 Big Endian:

shd: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-uClibc.so.0, corrupted section header size

The shd binary also contains a copy of OpenSSL 1.0.1j 15 Oct 2014 for establishing TLS connections to the cloud server.
We load the shd binary into IDA and start analyzing!

4. Busybox

The busybox version provided in the firmware is vulnerable to CVE-2011-2716, a command injection vulnerability in the udhcpc DHCP client component of busybox, which allows to inject shell commands into one of the following DHCP options: (12) Hostname, (15) Domainname, (40) NIS Domain or (66) TFTP Server Name. For this to work, those values have to be actually used by the shell script invoking udhcpc. Analyzing the firmware we find that the shd binary creates a shell script /tmp/udhcpc.script containing:

#!/bin/sh
if[ $1 = renew –o $1 = bound]
then
    ifconfig $interface $ip netmask $subnet
    route del default
    route add default gw $router
   echo "nameserver $dns" > /tmp/resolv.conf
fi

It then executes udhcpc:

/sbin/udhcpc –b –H "HS100(US)" –i br0 –s /tmp/udhcpc.script

As we can see, the hostname is hardcoded and none of the other options are used. Unfortunately, the udhcpc vulnerability is not exploitable in this case.

5. Portscan

An nmap port scan on all TCP and UDP ports reveals the following:

The Webserver on Port 80 replies with a meaningless ellipsis, no matter what the request is:

HTTP/1.1 200 OK
Server: TP-LINK Smart Plug
Connection: close
Content-Length: 5
Content-Type: text/html

…

Looking through the shd binary we see that the HTTP Server routine is called “fake_httpd” and will always return this hardcoded reply.

Port 9999 TCP is used for controlling the Smart Plug on the local network via the Kasa app and is described in the TP-Link Smart Home Protocol section. Port 1040 UDP is described in the TP-Link Device Debug Protocol section.

6. TP-Link Smart Home Protocol

Sniffing the local wireless network traffic reveals that the TP-Link Kasa SmartHome app talks to the HS110 Smart Plug on TCP port 9999 using what looks like encrypted data.

After decompiling the Kasa app for Android, we find the encryption function:

We see the initial key (initialization vector) i has a hardcoded value of -85 (= 171). The first byte of the plaintext is XORed with the key. The key is then set to the plaintext byte. During the next iteration, the next plaintext byte is XORed with the previous plaintext byte. Decryption works the same, with the keystream made out of cyphertext bytes. This is known as an autokey cipher and while it has better statistical properties than simple XOR encryption with a repeating key, it can be easily broken by known plaintext attacks.

Now that we know the algorithm and the key, we implement a Wireshark dissector in LUA which automatically decrypts TP-Link Smart Home packets on port 9999. It turns out that the protocol uses JSON, so we also pass the decrypted contents to the JSON dissector. We can now monitor communications between the Kasa app and the Smart Plug on the local WiFi:

 
The Smart Plug commands are grouped into the following categories:

• system
• netif (WLAN interface commands)
• cnCloud (cloud connection)
• time
• emeter (energy meter)
• schedule (scheduled on/off)
• count_down (countdown on/off)
• anti_theft (random scheduled on/off)

We provide a comprehensive list of JSON commands (tplink-smarthome-commands.txt) and a python client to send them with (tplink-smartplug.py).

System Commands

We can read out information about the system using the get_sysinfo command:

{"system":{"get_sysinfo":{}}}

To send the command using our python client, invoke it with the –c info option:

./tplink-smartplug.py –t 192.168.0.1 –c info

We provide several predefined commands to read out information from the HS110 Smart Plug using –c options.
Alternatively, you can use the –j option and provide the full JSON string:

./tplink-smartplug.py –t 192.168.0.1 –j '{"system":{"get_sysinfo":{}}}'

This allows to send any of the commands listed in tplink-smarthome-commands.txt.
The get_sysinfo reply will contain the following information:

 
We can turn the HS110 Smart Plug on and off using the set_relay_state command, using 1 for on and 0 for off:

{“system":{"set_relay_state":{"state":1}}}

We can reboot the HS110 Smart Plug using the reboot command which requires a delay parameter in seconds:

{"system":{"reboot":{"delay":1}}}

The HS110 Smart Plug can be reset to factory settings, making it act as an open Access Point again:

{"system":{"reset":{"delay":1}}}

Note that since the protocol does not provide authentication, anybody on your network can send this command and force a reset. Here, a prankster would set a high delay value, giving them time to leave the premises.

There are further commands to change the MAC address, change the Device and Hardware IDs, turn off the device LED (night mode) etc.

Of special interest are the firmware flashing commands. You can download a  firmware file from an arbitrary URL using:

{"system":{"download_firmware":{"url":"http://..."}}}

While downloading, you can get the download state using:

{"system":{"get_download_state":{}}}

Once the download is finished, you can flash the firmware using:

{"system":{"flash_firmware":{}}}

Flashing a modified image will not work since the image’s signature has to match one of four hardcoded RSA keys (we won’t go into wild speculations why there are four keys here):

 
WiFi Commands

You can instruct the HS110 Smart Plug to scan for a list of nearby Access Points:

{"netif":{"get_scaninfo":{"refresh":1}}}

This will return a list of all the available visible APs in the area.

Connecting to an AP with a given SSID and password is done using the command set_stainfo (key_type 3 indicates WPA2):

{"netif":{"set_stainfo":{"ssid":"WiFi","password":"123","key_type":3}}}

Note that all JSON commands are accepted independent of the device state! Connecting to an Access Point would only be necessary in the unconfigured state when the HS110 Smart Plug is acting as an AP. Using the set_stainfo command you can force the Plug to connect to a different WiFi on the fly.

Cloud Commands

The HS110 Smart Plug regulary tries to connect to the TP-Link cloud server at devs.tplinkcloud.com:50443 using TLS. This behavior continues even if the HS110 Smart Plug is configured as “local only” in the Kasa app. Fortunately for us, there is a command to change the cloud server URL:

{"cnCloud":{"set_server_url":{"server":"devs.tplinkcloud.com"}}}

The shd binary tries to establish a TLS 1.0 connection with the provided URL and checks if the server certificate is signed by Symantec’s EV Root CA stored under /etc/newroot2048.crt. An attacker with the necessary funds could purchase a valid EV certificate and perform a Man-in-the-Middle attack on the communication between HS110 Smart Plug and cloud.

To register the device with the cloud we issue the bind command and provide a valid cloud account name and password:

{"cnCloud":{"bind":{"username":alice@home.com, "password":"secret"}}}

It’s interesting to note that registration will fail if the Smart Plug’s hwID is unknown to the cloud server. This means TP-Link either performs a checksum or other type of plausibility check or checks against a complete list of devices. Either way, this allows TP-Link to track all devices throughout their lifetime.

You can unregister a device from the cloud account using unbind:

{"cnCloud":{"unbind":null}}

This allows an attacker on the local network to unregister the device, forcing the device owner to register again. The attacker can then capture the bind registration command sent by the Kasa app and sees the owner’s tplinkcloud.com credentials in cleartext!

7. Test Mode

Analyzing the shd binary, we discovered a hidden “test mode” in the HS110 Smart Plug. It can be invoked remotely or via a command-line argument to the shd binary.

7.1 Command-Line Test Mode

The shd binary can be launched using a –t option which makes it enter test mode:

 
This calls a function called wlan_start_art which looks promising because it executes the Atheros Radio Test (ART) client code for performance-testing Atheros wireless adapters.  This piece of debugging code already led to a vulnerability in TP-Link Routers in 2013 where it could be triggered using a hidden URL on the device webserver: TP-Link http/tftp backdoor

The function wlan_start_art runs the following system commands:

LD_LIBRARY_PATH=/tmp
arping –I br0 –c 1 192.168.0.100
tftp –g 192.168.0.100 –r ap_bin/ap121/art.ko –l /tmp/art.ko
insmod /tmp/art.ko
tftp –g 192.168.0.100 –r ap_bin/ap121/nart.out –l /tmp/nart.out
chmod +x /tmp/nart.out
/tmp/nart.out –instance 0 &

The commands connect to a TFTP Server, download a file called nart.out, make it executable and run it. This can be easily used to root the device. All one would need to do is to host a shell script called nart.out on a TFTP server with the IP 192.168.0.100 under the path ap_bin/ap121/. The shell script would start the busybox telnetd daemon:

/bin/busybox telnetd –l/bin/sh &

However, we have no way of invoking the shd binary on the device with the –t option.

7.2 Remote Test Mode
 
Going through all the JSON commands in the shd binary we find a command called set_test_mode. This means test mode can be enabled remotely!

This is the only JSON command which, as a primitive sort of protection, requires the request to originate from the IP 192.168.0.100. The easiest way to do this is to reset the HS110 Smart Plug and connect to its AP since the DHCP server is configured to issue IPs starting with 192.168.0.100. Next, send the set_test_mode command:

./tplink-smarthome.py -t 192.168.0.1 -j '{"system":{"set_test_mode":{"enable":1}}}'

This writes a special test mode flag into the device’s NVRAM. The flag is checked during boot, and if set the HS110 Smart Plug boots into test mode.

Reboot the Smart Plug using:

./tplink-smarthome.py -t 192.168.0.1 -c reboot

The Smart Plug will try to connect to a WPA2-secured Access Point with the SSID “hs_test” and password “12345670” and then turn on the plug’s relay:

To set up the hs_test AP, we use hostapd with the following hostapd.conf:

interface=wlan0
driver=nl80211
ssid=hs_test
wpa=2
wpa_passphrase=12345670
channel=1

As expected, the HS110 Smart Plug connects to our hs_test AP. We then observe the Smart Plug going through its regular setup: Request an IP via DHCP, synchronize the time using a server from the NTP-Pool (cn.pool.ntp.org) and connect to the TP-Link Cloud server at devs.tplinkcloud.com:50443.

Unfortunately, the Smart Plug’s behavior was no different in test mode than after a regular boot. While there is a reference to the wlan_start_art function in the remote test mode code, it is in a part without any references leading to it. This likely means that the function call to that part was commented out.

8. TP-Link Device Debug Protocol

A portscan of the HS110 Smart Plug revealed an open UDP port of 1040. Analyzing the shd binary for setsockopt() calls, we could see the port was being bound by a component called “TDDP”. The protocol seemed to be binary and designed in a very stealthy manner so that no reply is given whatsoever unless a fully valid packet was sent to the port. Reverse-engineering the protocol would have been a major new undertaking and fortunately, we didn’t have to.

Hacked by Patent

After quite a bit of googling for “TP-Link” and “TDDP”, we discovered the protocol had been patented in China as patents “CN 102096654 A” and “CN 102123140 B” which Google handily auto-translates into English:

http://www.google.com/patents/CN102096654A?cl=en

A complete protocol specification is included in the patent description and shows you how to construct a TDDP packet.

TDDP can be used to ping or discover a TP-Link Device on the network through broadcasts, read and set configuration options and execute special device-specific commands. TDDP provides integrity through an MD5 digest of the whole packet included in the packet header:

It also encrypts the packet payload using DES. This means that any configuration data we read out will be encrypted in the reply, and any configuration we want to write needs to be sent encrypted.

The DES key is determined by concatenating the device’s username and password, building an MD5 hash of that string, and then using the first half of the MD5 (16-digit hex number or 8 bytes) or as the DES key:

md5(username + password)[:16]

Since the HS110 Smart Plug does not provide any authentication, the username and password are hardcoded into the shd binary as admin/admin:

For other TP-Link devices this means an attacker has a highly efficient way to check for default passwords and perform an offline bruteforce attack on the login.
With a single UDP packet, they can request information that is already known (we found a “Heartbeat”/ping request in the SmartPlug that always returns “ABCD0110) or can be easily determined (e.g. MAC address). The encrypted reply can then be bruteforced offline trying different combinations for username (likely “admin”) and password.

We provide a very basic proof-of-concept TDDP client which tries to read out one of three values from a TP-Link device by using a packet type of 0x03 and specific hex-values in the “SubType” header field:

0x0A returns the test string “ABCD0110“, 0x012 return the deviceID and 0x14 returns the hardwareID. They might return different types of information on other types of TP-Link devices. We also found additional values which changed the deviceID (0x13, 0x15), the hardwareID (0x12) and the MAC address (0x06).

The binary TDDP protocol merits further research since it is available on a broad range of TP-Link devices. The possibility for device-specific special commands (CMD_SPE_OPR) has potential to uncover undocumented functions, vulnerabilities or even backdoors. As a next step, different TP-Link devices should be fuzzed with the full range of hex values in the TDDP header and their behavior monitored and analysed.

The post Reverse Engineering the TP-Link HS110 appeared first on softScheck GmbH.

The post Security Testing Open Source Webinar appeared first on softScheck GmbH.

The post Tag-Cloud appeared first on softScheck GmbH.

• No successful Attack without a vulnerability!
• Only software products without vulnerabilities are really secure!

Improve with us: softScheck identifies Zero-Day-Vulnerabilities in every type of software and hardware. We offer „Security Testing as a Service“ in form of a whole process.

softScheck makes your software, apps and hardware secure against attacks.

The post softScheck Intro (en) appeared first on softScheck GmbH.

Prof. Dr. Hartmut Pohl CEO

The post About softScheck appeared first on softScheck GmbH.

09.10.2015 – softScheck als Prüfungspartner der tekit Consult auf der it-sa 2015

21.09.2015 – Zertifizierte Entwicklung sicherer Software, Firmware, Apps & Systems

22.07.2015 – Verteidigungsanstrengungen der Bundesregierung gegen Cyberangriffe aus dem Internet unzureichend

The post 2015 appeared first on softScheck GmbH.

07.11.2014 – Open-Xchange GmbH veröffentlicht Details zu der von softScheck identifizierten Sicherheitslücke

14.10.2014 – SQL-Injection in Open-Xchange Server / OX AppSuite

10.10.2014 – Eine Welt ohne Passwörter?

11.08.2014 – Unsichere Provider – Anwender hilflos gegen Milliarden-fachen Passwort-Diebstahl

07.08.2014 – Keine Sicherheit mit Passwörtern

30.06.2014 – Keine Sicherheit für das Kanzler-Handy

07.05.2014 – Millionen Anwender durch schwere, kritische Sicherheitslücke in Microsofts Outlook in Gefahr

28.04.2014 – Handlungsbedarf: In 5 Schritten gegen Heartbleed

02.04.2014 – Denial of Service in Microsoft Outlook 2007–2013

20.02.2014 – Wirtschaftskriminelle beherrschen das Internet – vollständig

The post 2014 appeared first on softScheck GmbH.

24.10.2013 – Telefon und das Internet werden vollständig abgehört – auch die Bundeskanzlerin

18.09.2013 – Sicherheitssoftware ist unsicher

09.07.2013 – Hiobsbotschaften sind berechtigt: Das Internet ist völlig unsicher

24.06.2013 – Das Internet ist völlig unsicher

18.04.2013 – Kommentar zum “Gesetz zur Förderung der elektronischen Verwaltung”

25.03.2013 – Anmerkungen zum “Entwurf eines Gesetzes zur Erhöhung der Sicherheit informationstechnischer Systeme”

08.02.2013 – Melden allein macht nicht sicher – Ablehnung der Meldepflicht von Cyber-Attacken

05.02.2013 – Vollständige IT-Sicherheit im Smart Grid: Security Testing E-world

21.01.2013 – SNMP-Fuzzer erfolgreich an PLC S7-1200 getestet

07.01.2013 – Industrie 4.0 Security 5-stufiger Prozess zur Absicherung von Industriesteuerungen

07.01.2013 – Hoch-kritische Sicherheitslücke in S7 Software identifiziert Speicherprogrammierbare Steuerung S7-1200

The post 2013 appeared first on softScheck GmbH.

27.11.2012 – Security Testing as a Service Process

25.10.2012 – Kostengünstiges Security Testing auf Smart Devices

19.10.2012 – Erfolgreiche Fachgespräche auf der it-sa mit Unternehmen aus acht Branchens

11.10.2012 – Die OpenLimit SignCubes AG und die softScheck GmbH sind eine strategische Sicherheitspartnerschaft eingegangen.

The post 2012 appeared first on softScheck GmbH.