Elvis Wiki - User contributions [en]

Bleichenbacher Attack

2020-12-21T23:24:55Z

MLengl:

== Description ==

The popular RSA asymmetric encryption has a deterministic nature. Therefore PKCS was added to RSA which uses padding to remove this deterministic property and add two functionalities. This are the signature and the encryption of packets and each of those are indicated at the second MSB. Following is a picture of a valid PKCS 1.5 packet (bytes are displayed as hex):

[[File:pkcs-paket.png]]

In this picture you see a 0 Byte as MSB followed by a "2" to indicate encryption. Following is the variable length random padding with at least 8 Byte, delimited by another 0 Byte. After this delimiter you find the data you want to send or like to receive. At the sender side this packet is now encrypted with RSA and on the receiver side the data is extracted after RSA decryption. This encryption and most important decryption is only successful if the validity of such a PKCS packet is given. Therefore decrypted data is checked upon the validity.

Daniel Bleichenbacher published a method in 1998 called the "Bleichenbacher Attack" to use this validity check to decrypt a previous captured packet. An attacker therefore captures a packet sent from client to server and multiplies it with a number. This number can be chosen randomly and due to the fact, that the public key of the server previously used by the client is also available to the attacker, he or she is able to compute a new packet and send it to the target system. This system acts as an oracle and answers most likely with an error due to the invalid PKCS packet because of an unknown structure. For example there is no 0 as MSB after modifying this packet. After receiving the first answer, the attacker computes a new packet with another number and sends it again to the oracle. This procedure is now constantly repeated until no error message is answered. The attacker now knows that his comuted packet produced a decrypted packet between:

'''020000000... << 030000000...'''

By further continuing this procedure the attacker learns more intervals and can eventually derive the originally encrypted message. Because of the amount of messages that have to be sent, this attack also is called the "Million Message Attack". In case of SSL encryption the RSA key exchange is using PKCS 1.5 to transmit the so called pre_master_secret. If an attacker can capture and decrypt this packet, he or she can read the entire transmitted data between this client and the server within this specific ssl session.

== Requirements ==

There are a couple things which are needed for an effective Bleichenbacher Attack. Basically this attack works with RSA PKCS 1.5 and the initial captured packet itself must be PKCS conform. But there is one main important requirement: a Bleichenbacher Oracle.
Such an oracle is a target system which answers repeated questions concerning the validity of an PKCS packet. To create such an oracle there are basically three ways:

* Plain Encryption: if implementation is without signature, the target system will only check the validity of the PKCS packet and sending an error message if the packet is invalid
* Detailed Error Messages: if encryption and signature is applied, but the target system generates specific errors regarding the validity of an pkcs packet
*Timing Attack: if encryption and signature is applied in a proper way, you can still check the time between responses to generate a side channel regarding the validity of the packet

== Affected Products ==
There are many implementations that are vulnerable. The product list includes:

* F5
* Citrix
* Cisco
* Java / JSSE
* IBM GSKit
* Bouncy Castle
* SSL 1.0 - 1.3
* TLS 1.0 - 1.2

Implementations in TLS 1.1 and 1.2 may not be practicably vulnerable if implemented with the attack in mind. Due to the complexity of an correct implementation, this easily can be done wrong and there's still a side channel to generate an oracle. With TLS 1.3 RSA PKCS key exchange is fully dropped regarding the encryption.

== References ==

* https://link.springer.com/content/pdf/10.1007/BFb0055716.pdf
* https://robotattack.ogr
* https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-bock.pdf
* https://www.hjp.at/doc/rfc/rfc2313.html

[[Category:Basic]]

Bleichenbacher Attack

2020-12-21T20:40:07Z

MLengl:

== Description ==

The popular RSA asymmetric encryption has a deterministic nature. Therefore PKCS was added to RSA which uses padding to remove this deterministic property and add two functionalities. This are the signature and the encryption of packets and each of those are indicated at the second MSB. Following is a picture of a valid PKCS 1.5 packet (bytes are displayed as hex):

[[File:pkcs-paket.png]]

In this picture you see a 0 Byte as MSB followed by a "2" to indicate encryption. Following is the variable length random padding with at least 8 Byte, delimited by another 0 Byte. After this delimiter you find the data you want to send or like to receive. At the sender side this packet is now encrypted with RSA and on the receiver side the data is extracted after RSA decryption. This encryption and most important decryption is only successful if the validity of such a PKCS packet is given. Therefore decrypted data is checked upon the validity.

Daniel Bleichenbacher published a method in 1998 called the "Bleichenbacher Attack" to use this validity check to decrypt a previous captured packet. An attacker therefore captures a packet sent from client to server and multiplies it with a number. This number can be chosen randomly and due to the fact, that the public key of the server previously used by the client is also available to the attacker, he or she is able to compute a new packet and send it to the target system. This system acts as an oracle and answers most likely with an error due to the invalid PKCS packet because of an unknown structure. For example there is no 0 as MSB after modifying this packet. After receiving the first answer, the attacker computes a new packet with another number and sends it again to the oracle. This procedure is now constantly repeated until no error message is answered. The attacker now knows that his comuted packet produced a decrypted packet between:

'''020000000... << 030000000...'''

By further continuing this procedure the attacker learns more intervals and can eventually derive the originally encrypted message. Because of the amount of messages that have to be sent, this attack also is called the "Million Message Attack". In case of SSL encryption the RSA key exchange is using PKCS 1.5 to transmit the so called pre_master_secret. If an attacker can capture and decrypt this packet, he or she can read the entire transmitted data between this client and the server within this specific ssl session.

== Requirements ==

There are a couple things which are needed for an effective Bleichenbacher Attack. Basically this attack works with RSA PKCS 1.5 and the initial captured packet itself must be PKCS conform. But there is one main important requirement: a Bleichenbacher Oracle.
Such an oracle is a target system which answers repeated questions concerning the validity of an PKCS packet. To create such an oracle there are basically three ways:

* Plain Envryption: if implementation is without signature, the target system will only check the validity of the PKCS packet and sending an error message if the packet is invalid
* Detailed Error Messages: if encryption and signature is applied, but the target system generates specific eroors regarding the validity of an pkcs packet
*Timing Attack: if encryption and signature is applied in a proper way, you can still check the time between responses to generate a side channel regarding the validity of the packet

== Affected Products ==
There are many implementations that are vulnerable. The product list includes:

* F5
* Citrix
* Cisco
* Java / JSSE
* IBM GSKit
* Bouncy Castle
* SSL 1.0 - 1.3
* TLS 1.0 - 1.2

Implementations in TLS 1.1 and 1.2 may not be practicably vulnerable if implemented with the attack in mind. Due to the complexity of an correct implementation, this easily can be done wrong and there's still a side channel to generate an oracle. With TLS 1.3 RSA PKCS key exchange is fully dropped regarding the encryption.

== References ==

* https://link.springer.com/content/pdf/10.1007/BFb0055716.pdf
* https://robotattack.ogr
* https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-bock.pdf
* https://www.hjp.at/doc/rfc/rfc2313.html

[[Category:Basic]]

Bleichenbacher Attack

2020-12-21T20:17:25Z

MLengl:

== Description ==

The popular RSA asymmetric encryption has a deterministic nature. Therefore PKCS was added to RSA which uses padding to remove the deterministic and add two functionalities. This two are the signature and the encryption of packets and each of those are indicated at the second MSB. Following is a picture of a valid PKCS 1.5 packet (bytes are displayed as hex):

[[File:pkcs-paket.png]]

In this picture you see a 0 Byte as MSB followed by a "2" to indicate encryption. Following is the variable length random padding with at least 8 Byte, delimited from another 0 Byte. After this delimiter you find the data you want to send or like to receive. At the sender side this paket is now encrypted with RSA and on the receiver side the data is extracted after RSA decryption. This encryption and most important decryption is only possible if the validity of such a PKCS packet is given. Therefore decrypted data is checked upon the validity.

Daniel Bleichenbacher published a method in 1998 called the "Bleichenbacher Attack" to use this validity check to decrypt a previous packet. An attacker therefore captures a packet sent from client to server and multiplies it with a number. This number can be chosen randomly and due to the fact, that the public key of the server previously used by the client is also available to the attacker, he is able to compute a new packet and send it to the target system. This acts as an oracle and answers most likely with an error due to the invalid PKCS packet because of an unknown structure. For example there is no 0 as MSB. After receiving the first answer, the attacker computes a new packet with another number and sends it again to the oracle. This procedure is now constantly repeated until no error message is answered. The attacker now knows that his comuted packet produced a decrypted paket between:

'''020000000... << 030000000...'''

By further continuing this procedure the attacker learns more intervals and can eventually derive the originally encrypted message. Because of the amount of messages that have to be sent, this attack also is called the "Million Message Attack". In case of SSL encryption the RSA key exchange is using PKCS 1.5 to transmit the so called pre_master_secret. If an attacker can capture and decrypt this packet, he or she can read the entire transmitted data between this client and the server within this ssl session.

== Requirements ==

There are a couple things which are needed for an effective Bleichenbacher Attack. Basically this attack works with RSA PKCS 1.5 but there is one important requirement: a Bleichenbacher Oracle.
Such an oracle is a target system which answers repeated questions concerning the validity of an PKCS paket. To create such an oracle there are basically three ways:

* Plain Envryption: if implementation is without signature, the target system will only check the validity of the PKCS paket and sending an error message if the paket is invalid
* Detailed Error Messages: if encryption and signature is applied, but the target system generates specific eroors regarding the validity of an pkcs paket
*Timing Attack: if encryption and signature is applied in a proper way, you can still check the time between responses to generate a side channel regarding the validity of the paket

== Affected Products ==
There are many implementations that are vulnerable. The product list includes:

* F5
* Citrix
* Cisco
* Java / JSSE
* IBM GSKit
* Bouncy Castle
* SSL 1.0 - 1.3
* TLS 1.0 - 1.2

Implementations in TLS 1.1 and 1.2 may not be practicably vulnerable if implemented with the attack in mind. Due to the complexity of an correct implementation, this easily can be done wrong and there's still a side channel to generate an oracle. With TLS 1.3 PKCS key exchange is fully dropped regarding the encryption.

== References ==

* https://link.springer.com/content/pdf/10.1007/BFb0055716.pdf
* https://robotattack.ogr
* https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-bock.pdf
* https://www.hjp.at/doc/rfc/rfc2313.html

[[Category:Basic]]

Bleichenbacher Attack

2020-12-21T20:16:59Z

MLengl:

Bleichenbacher Attack

2020-12-21T20:09:08Z

MLengl:

== Description ==

The popular RSA asymmetric encryption has a deterministic nature. Therefore PKCS was added to RSA which uses padding to remove the deterministic and add two functionalities. This two are the signature and the encryption of packets and each of those are indicated at the second MSB. Following is a picture of a valid PKCS 1.5 packet:

[[File:pkcs-paket.png]]

In this picture you see a 0 Byte as MSB followed by a "2" to indicate encryption. Following is the variable length random padding with at least 8 Byte, delimited from another 0 Byte. After this delimiter you find the data you want to send or like to receive. At the sender side this paket is now encrypted with RSA and on the receiver side the data is extracted after RSA decryption. This encryption and most important decryption is only possible if the validity of such a PKCS packet is given. Therefore decrypted data is checked upon the validity.

Daniel Bleichenbacher published a method in 1998 called the "Bleichenbacher Attack" to use this validity check to decrypt a previous packet. An attacker therefore captures a packet sent from client to server and multiplies it with a number. This number can be chosen randomly and due to the fact, that the public key of the server previously used by the client is also available to the attacker, he is able to compute a new packet and send it to the target system. This acts as an oracle and answers most likely with an error due to the invalid PKCS packet because of an unknown structure. For example there is no 0 as MSB. After receiving the first answer, the attacker computes a new packet with another number and sends it again to the oracle. This procedure is now constantly repeated until no error message is answered. The attacker now knows that his comuted packet produced a decrypted paket between:

'''020000000... << 030000000...'''

By further continuing this procedure the attacker learns more intervals and can eventually derive the originally encrypted message. Because of the amount of messages that have to be sent, this attack also is called the "Million Message Attack".

== Requirements ==

There are a couple things which are needed for an effective Bleichenbacher Attack. Basically this attack works with RSA PKCS 1.5 but there is one important requirement: a Bleichenbacher Oracle.
Such an oracle is a target system which answers repeated questions concerning the validity of an PKCS paket. To create such an oracle there are basically three ways:

* Plain Envryption: if implementation is without signature, the target system will only check the validity of the PKCS paket and sending an error message if the paket is invalid
* Detailed Error Messages: if encryption and signature is applied, but the target system generates specific eroors regarding the validity of an pkcs paket
*Timing Attack: if encryption and signature is applied in a proper way, you can still check the time between responses to generate a side channel regarding the validity of the paket

== Affected Products ==
There are many implementations that are vulnerable. The product list includes:

* F5
* Citrix
* Cisco
* Java / JSSE
* IBM GSKit
* Bouncy Castle
* SSL 1.0 - 1.3
* TLS 1.0 - 1.2

Implementations in TLS 1.1 and 1.2 may not be practicably vulnerable if implemented with the attack in mind. Due to the complexity of an correct implementation, this easily can be done wrong and there's still a side channel to generate an oracle. With TLS 1.3 PKCS key exchange is fully dropped regarding the encryption.

== References ==

* https://link.springer.com/content/pdf/10.1007/BFb0055716.pdf
* https://robotattack.ogr
* https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-bock.pdf
* https://www.hjp.at/doc/rfc/rfc2313.html

[[Category:Basic]]

Bleichenbacher Attack

2020-12-21T19:38:22Z

MLengl:

File:Pkcs-paket.png

2020-12-21T19:37:13Z

MLengl: MLengl uploaded a new version of File:Pkcs-paket.png

Bleichenbacher Attack

2020-12-21T19:36:31Z

MLengl:

Bleichenbacher Attack

2020-12-21T19:30:51Z

MLengl:

File:Pkcs-paket.png

2020-12-21T19:30:31Z

MLengl:

Bleichenbacher Attack

2020-12-21T19:29:02Z

MLengl:

Bleichenbacher Attack

2020-12-21T19:00:12Z

MLengl:

== Description ==

Description what this documentation is about

== Requirements ==

There are a couple things which are needed for an effective Bleichenbacher Attack. Basically this attack works with RSA PKCS 1.5 but there is one important requirement: a Bleichenbacher Oracle.
Such an oracle is a target system which answers repeated questions concerning the validity of an PKCS paket. To create such an oracle there are basically three ways:
* Plain Envryption: if implementation is without signature, the target system will only check the validity of the PKCS paket and sending an error message if the paket is invalid
* Detailed Error Messages: if encryption and signature is applied, but the target system generates specific eroors regarding the validity of an pkcs paket
*Timing Attack: if encryption and signature is applied in a proper way, you can still check the time between responses to generate a side channel regarding the validity of the paket

== Affected Products ==
There are many implementations that are vulnerable. The product list includes:

* F5
* Citrix
* Cisco
* Java / JSSE
* IBM GSKit
* Bouncy Castle
* SSL 1.0 - 1.3
* TLS 1.0 - 1.2

Implementations in TLS 1.1 and 1.2 may not be practicably vulnerable if implemented with the attack in mind. Due to the complexity of an correct implementation, this easily can be done wrong and there's still a side channel to generate an oracle. With TLS 1.3 PKCS key exchange is fully dropped regarding the encryption.

== References ==

* https://link.springer.com/content/pdf/10.1007/BFb0055716.pdf
* https://robotattack.ogr

[[Category:Basic]]

Bleichenbacher Attack

2020-12-21T18:44:06Z

MLengl:

Bleichenbacher Attack

2020-12-20T22:49:04Z

MLengl:

Bleichenbacher Attack

2020-12-20T22:37:19Z

MLengl:

== Description ==

Description what this documentation is about

== Requirements ==

* Operating system: Ubuntu 18.04 bionic amd64
* Packages: git emacs

In order to complete these steps, you must have followed [[Some Other Documentation]] before.

== Affected Protocols ==

== References ==

* https://wikipedia.org
* https://google.com

[[Category:Basic]]

Category:Basics

2020-12-20T09:47:45Z

MLengl: MLengl moved page Category:Basics to Bleichenbacher Attack over redirect: Move didn't work, moving back to Documentations

#REDIRECT [[Bleichenbacher Attack]]

Bleichenbacher Attack

2020-12-20T09:47:45Z

MLengl: MLengl moved page Category:Basics to Bleichenbacher Attack over redirect: Move didn't work, moving back to Documentations

== Summary ==

Description what this documentation is about

== Requirements ==

* Operating system: Ubuntu 18.04 bionic amd64
* Packages: git emacs

In order to complete these steps, you must have followed [[Some Other Documentation]] before.

== Description ==

=== Step 1 ===

Enter these commands in the shell

echo foo
echo bar

=== Step 2 ===

Make sure to read

* War and Peace
* Lord of the Rings
* The Baroque Cycle

== Used Hardware ==

[[Device to be used with this documentation]]
[[Maybe another device to be used with this documentation]]

== Courses ==

* [[A course where this documentation was used]] (2017, 2018)
* [[Another one]] (2018)

== References ==

* https://wikipedia.org
* https://google.com

[[Category:Documentation]]

Bleichenbacher Attack

2020-12-20T09:45:25Z

MLengl: MLengl moved page Bleichenbacher Attack to Category:Basics: Cannot write into Basics, but can write to Documentations. Trying now to move Page to Basics Category

Bleichenbacher Attack

2020-12-20T09:39:20Z

MLengl: Created page with "== Summary == Description what this documentation is about == Requirements == * Operating system: Ubuntu 18.04 bionic amd64 * Packages: git emacs In order to complete the..."

Install c't'-Raspion on Raspberry PI

2020-06-03T19:43:45Z

MLengl:

== 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].

=== Findings ===
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.

Install c't'-Raspion on Raspberry PI

2020-06-03T19:00:01Z

MLengl:

== 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 s
Direkt beim Einschalten (cap power_on_gateway) werden von der App einige DNS anfragen gestellt um IPs von fw.ota.homesmart.ikea.net zu erhalten. In den DNS Antworten sind ebenfalls IPs zu d262cmbxmzphsu.cloudfront.net enthalten. Ikea nutzt dabei AWS.

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

Weiters findet man eine http Verbindung:

[[File:wireshark-cap-http.png|600px]]

Die unter fw.ota.homesmart.ikea.net/feed/version_info.json vorhandenen Daten sind nicht allzu spektakulär: Es sind lediglich Versionsinfos.

Sobald über die Ikea Smart Home App das Setup gestarted wird versucht die App mit mDNS queries den Tradfri Gateway zu finden.

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

Bei dem verwendeten Setup schlägt dies natürlich fehl, jedoch bietet die App direkt die option eine IP manuell einzugeben. Nach Eingabe der IP muss entweder der QR Code auf der Rückseite des Gerätes gescannt werden oder der Sicherheitscode eingegeben werden der sich ebenfalls auf der Rückseite des Geräts befindet.

Der Sicherheitscode ist dabei der PSK der DTLS Verbindung. Sobald der App der QR Code bzw der Sicherheitscode bekannt sind bauen App und Gateway eine DTLS Verbindung auf. Über diese Verbindung werden alle Applikationsdaten gesendet.

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

Auch beim Verbinden von weiteren SH Geräten baut die App keine gesonderten Verbindung auf sondern kommuniziert ausschließlich über DTLS.

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

Einige Verbindungen zur AWS Cloud baut die App dennoch auf. Dies steht anscheinend im Zusammenhang mit dem Verbinden von Geräten da immer direkt nach dem Verbinden eines Gerätes diese Seiten abgefragt werden:

[[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].

=== Findings ===
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.

Install c't'-Raspion on Raspberry PI

2020-06-02T20:10:31Z

MLengl: /* Ikea Tradfri Setup Sniff */

== 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 ==
Als Testgerät wurde ein möglich leergeräumtes iPhone verwendet. Alle deinstallierbaren Services wurden entfernt, wo möglich Synchronisierung deaktiviert.
Jedoch sind Apple geräte mäßig geeignet, es werden zu viele Verbindungen vom Betriebssystem hergestellt (auch von deaktivierten iOs Services).

Um Pihole auch zur Aufzeichnung von DNS queries vom Tradfri Gateway zu nutzen muss eine USB Netzwerkadapter verwendet werden oder ein externer Router als WiFi Bridge konfiguriert werden. Ohne diese Hardwareänderungen lässt sich ein Tradfri Gateway nicht in das Raspion Netzwerk integrieren. Um dennoch Pakete mitschneiden zu können wurde arpspoofing verwendet.

Vorab Übersicht IP config

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

Direkt beim Einschalten (cap power_on_gateway) werden von der App einige DNS anfragen gestellt um IPs von fw.ota.homesmart.ikea.net zu erhalten. In den DNS Antworten sind ebenfalls IPs zu d262cmbxmzphsu.cloudfront.net enthalten. Ikea nutzt dabei AWS.

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

Weiters findet man eine http Verbindung:

[[File:wireshark-cap-http.png|600px]]

Die unter fw.ota.homesmart.ikea.net/feed/version_info.json vorhandenen Daten sind nicht allzu spektakulär: Es sind lediglich Versionsinfos.

Sobald über die Ikea Smart Home App das Setup gestarted wird versucht die App mit mDNS queries den Tradfri Gateway zu finden.

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

Bei dem verwendeten Setup schlägt dies natürlich fehl, jedoch bietet die App direkt die option eine IP manuell einzugeben. Nach Eingabe der IP muss entweder der QR Code auf der Rückseite des Gerätes gescannt werden oder der Sicherheitscode eingegeben werden der sich ebenfalls auf der Rückseite des Geräts befindet.

Der Sicherheitscode ist dabei der PSK der DTLS Verbindung. Sobald der App der QR Code bzw der Sicherheitscode bekannt sind bauen App und Gateway eine DTLS Verbindung auf. Über diese Verbindung werden alle Applikationsdaten gesendet.

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

Auch beim Verbinden von weiteren SH Geräten baut die App keine gesonderten Verbindung auf sondern kommuniziert ausschließlich über DTLS.

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

Einige Verbindungen zur AWS Cloud baut die App dennoch auf. Dies steht anscheinend im Zusammenhang mit dem Verbinden von Geräten da immer direkt nach dem Verbinden eines Gerätes diese Seiten abgefragt werden:

[[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].

=== Findings ===
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.

File:Ip-config.png

2020-06-02T20:09:53Z

MLengl: MLengl uploaded a new version of File:Ip-config.png

Install c't'-Raspion on Raspberry PI

2020-06-02T20:03:14Z

MLengl: /* Kommunikation entschlüsseln */

== 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 ==
Als Testgerät wurde ein möglich leergeräumtes iPhone verwendet. Alle deinstallierbaren Services wurden entfernt, wo möglich Synchronisierung deaktiviert.
Jedoch sind Apple geräte mäßig geeignet, es werden zu viele Verbindungen vom Betriebssystem hergestellt (auch von deaktivierten iOs Services).

Um Pihole auch zur Aufzeichnung von DNS queries vom Tradfri Gateway zu nutzen muss eine USB Netzwerkadapter verwendet werden oder ein externer Router als WiFi Bridge konfiguriert werden. Ohne diese Hardwareänderungen lässt sich ein Tradfri Gateway nicht in das Raspion Netzwerk integrieren. Um dennoch Pakete mitschneiden zu können wurde arpspoofing verwendet.

Vorab Übersicht IP config

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

Direkt beim Einschalten (cap power_on_gateway) werden von der App einige DNS anfragen gestellt um IPs von fw.ota.homesmart.ikea.net zu erhalten. In den DNS Antworten sind ebenfalls IPs zu d262cmbxmzphsu.cloudfront.net enthalten. Ikea nutzt dabei AWS.

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

Weiters findet man eine http Verbindung:

[[File:wireshark-cap-http.png|600px]]

Die unter fw.ota.homesmart.ikea.net/feed/version_info.json vorhandenen Daten sind nicht allzu spektakulär: Es sind lediglich Versionsinfos.

Sobald über die Ikea Smart Home App das Setup gestarted wird versucht die App mit mDNS queries den Tradfri Gateway zu finden.

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

Bei dem verwendeten Setup schlägt dies natürlich fehl, jedoch bietet die App direkt die option eine IP manuell einzugeben. Nach Eingabe der IP muss entweder der QR Code auf der Rückseite des Gerätes gescannt werden oder der Sicherheitscode eingegeben werden der sich ebenfalls auf der Rückseite des Geräts befindet.

Der Sicherheitscode ist dabei der PSK der DTLS Verbindung. Sobald der App der QR Code bzw der Sicherheitscode bekannt sind bauen App und Gateway eine DTLS Verbindung auf. Über diese Verbindung werden alle Applikationsdaten gesendet.

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

Auch beim Verbinden von weiteren SH Geräten baut die App keine gesonderten Verbindung auf sondern kommuniziert ausschließlich über DTLS.

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

Einige Verbindungen zur AWS Cloud baut die App dennoch auf. Dies steht anscheinend im Zusammenhang mit dem Verbinden von Geräten da immer direkt nach dem Verbinden eines Gerätes diese Seiten abgefragt werden:

[[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].

=== Findings ===
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.

File:Ip overview muzik.png

2020-06-02T20:00:54Z

MLengl: MLengl uploaded a new version of File:Ip overview muzik.png

File:Mitm findings.png

2020-06-02T19:59:11Z

MLengl: MLengl uploaded a new version of File:Mitm findings.png

File:Mitm findings.png

2020-06-02T19:58:34Z

MLengl:

Install c't'-Raspion on Raspberry PI

2020-06-02T19:27:09Z

MLengl:

== 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 ==
Als Testgerät wurde ein möglich leergeräumtes iPhone verwendet. Alle deinstallierbaren Services wurden entfernt, wo möglich Synchronisierung deaktiviert.
Jedoch sind Apple geräte mäßig geeignet, es werden zu viele Verbindungen vom Betriebssystem hergestellt (auch von deaktivierten iOs Services).

Um Pihole auch zur Aufzeichnung von DNS queries vom Tradfri Gateway zu nutzen muss eine USB Netzwerkadapter verwendet werden oder ein externer Router als WiFi Bridge konfiguriert werden. Ohne diese Hardwareänderungen lässt sich ein Tradfri Gateway nicht in das Raspion Netzwerk integrieren. Um dennoch Pakete mitschneiden zu können wurde arpspoofing verwendet.

Vorab Übersicht IP config

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

Direkt beim Einschalten (cap power_on_gateway) werden von der App einige DNS anfragen gestellt um IPs von fw.ota.homesmart.ikea.net zu erhalten. In den DNS Antworten sind ebenfalls IPs zu d262cmbxmzphsu.cloudfront.net enthalten. Ikea nutzt dabei AWS.

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

Weiters findet man eine http Verbindung:

[[File:wireshark-cap-http.png|600px]]

Die unter fw.ota.homesmart.ikea.net/feed/version_info.json vorhandenen Daten sind nicht allzu spektakulär: Es sind lediglich Versionsinfos.

Sobald über die Ikea Smart Home App das Setup gestarted wird versucht die App mit mDNS queries den Tradfri Gateway zu finden.

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

Bei dem verwendeten Setup schlägt dies natürlich fehl, jedoch bietet die App direkt die option eine IP manuell einzugeben. Nach Eingabe der IP muss entweder der QR Code auf der Rückseite des Gerätes gescannt werden oder der Sicherheitscode eingegeben werden der sich ebenfalls auf der Rückseite des Geräts befindet.

Der Sicherheitscode ist dabei der PSK der DTLS Verbindung. Sobald der App der QR Code bzw der Sicherheitscode bekannt sind bauen App und Gateway eine DTLS Verbindung auf. Über diese Verbindung werden alle Applikationsdaten gesendet.

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

Auch beim Verbinden von weiteren SH Geräten baut die App keine gesonderten Verbindung auf sondern kommuniziert ausschließlich über DTLS.

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

Einige Verbindungen zur AWS Cloud baut die App dennoch auf. Dies steht anscheinend im Zusammenhang mit dem Verbinden von Geräten da immer direkt nach dem Verbinden eines Gerätes diese Seiten abgefragt werden:

[[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.

=== 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].

=== Findings ===
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.

Install c't'-Raspion on Raspberry PI

2020-06-02T19:26:23Z

MLengl:

== 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 ==
Als Testgerät wurde ein möglich leergeräumtes iPhone verwendet. Alle deinstallierbaren Services wurden entfernt, wo möglich Synchronisierung deaktiviert.
Jedoch sind Apple geräte mäßig geeignet, es werden zu viele Verbindungen vom Betriebssystem hergestellt (auch von deaktivierten iOs Services).

Um Pihole auch zur Aufzeichnung von DNS queries vom Tradfri Gateway zu nutzen muss eine USB Netzwerkadapter verwendet werden oder ein externer Router als WiFi Bridge konfiguriert werden. Ohne diese Hardwareänderungen lässt sich ein Tradfri Gateway nicht in das Raspion Netzwerk integrieren. Um dennoch Pakete mitschneiden zu können wurde arpspoofing verwendet.

Vorab Übersicht IP config

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

Direkt beim Einschalten (cap power_on_gateway) werden von der App einige DNS anfragen gestellt um IPs von fw.ota.homesmart.ikea.net zu erhalten. In den DNS Antworten sind ebenfalls IPs zu d262cmbxmzphsu.cloudfront.net enthalten. Ikea nutzt dabei AWS.

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

Weiters findet man eine http Verbindung:

[[File:wireshark-cap-http.png|600px]]

Die unter fw.ota.homesmart.ikea.net/feed/version_info.json vorhandenen Daten sind nicht allzu spektakulär: Es sind lediglich Versionsinfos.

Sobald über die Ikea Smart Home App das Setup gestarted wird versucht die App mit mDNS queries den Tradfri Gateway zu finden.

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

Bei dem verwendeten Setup schlägt dies natürlich fehl, jedoch bietet die App direkt die option eine IP manuell einzugeben. Nach Eingabe der IP muss entweder der QR Code auf der Rückseite des Gerätes gescannt werden oder der Sicherheitscode eingegeben werden der sich ebenfalls auf der Rückseite des Geräts befindet.

Der Sicherheitscode ist dabei der PSK der DTLS Verbindung. Sobald der App der QR Code bzw der Sicherheitscode bekannt sind bauen App und Gateway eine DTLS Verbindung auf. Über diese Verbindung werden alle Applikationsdaten gesendet.

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

Auch beim Verbinden von weiteren SH Geräten baut die App keine gesonderten Verbindung auf sondern kommuniziert ausschließlich über DTLS.

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

Einige Verbindungen zur AWS Cloud baut die App dennoch auf. Dies steht anscheinend im Zusammenhang mit dem Verbinden von Geräten da immer direkt nach dem Verbinden eines Gerätes diese Seiten abgefragt werden:

[[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]]

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.

=== 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].

=== Findings ===
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.

File:Ip overview muzik.png

2020-06-02T19:24:29Z

MLengl: