Elvis Wiki - User contributions [en]

File:Keysy.jpg

2021-02-27T08:04:07Z

FChallakhi:

KeySy: Copying and Replaying RFID Tags

2021-02-27T08:03:25Z

FChallakhi: /* Summary */

== Summary ==

The KeySy is an low-frequency RFID duplicator by Tiny Labs, which can be used to store, replay and duplicate 125kHz RFID Tags. It comes with the KeySy remote and an additional rewriteable keyfob, onto which stored data can be duplicated.

[[File: Keysy.jpg | 300 px]]

== Hardware Used ==

* KeySy RFID Duplicator (includes CR2032 battery)
* programmed 125 kHz RFID Tag
* empty 125 kHz RFID Tag

== Copying RFID Tags ==

==== Step 1 ====

On the KeySy remote, press the button you wish to program until the light starts blinking red (approx. 8 seconds)

==== Step 2 ====
Place the remote on the keycard to be copied until the light stops blinking.
If the copying process was successful, the light will now be green otherwise it will turn amber and you should proceed to Step 3.

==== Step 3 ====
If the light turned amber, the copying process failed. Turn over the tag and repeat Steps 1 & 2 while slowly moving the KeySy remote over the tag.

''' If the copying process keeps failing: '''
* Change the battery: Copying a tag uses a lot more energy than just replaying one. This means, even if the LED lights up, the battery could be too weak to complete the copying process.
* Check KeySy compatibility: The Tag you want to copy is simply not readable by the remote. Refer to Section [[#Hardware Limitations| Hardware Limitations]] or Tiny Labs website under KeySy compatibility for further information.

''Note:'' Any buttons that have already been programmed can be rewritten using the same steps. It is not necessary to explicitly delete information from the remote beforehand.

== Replaying and Duplicating Tags ==

When you press one of the buttons on the KeySy remote, the LED will either flash red (there is nothing programmed on the button) or green (there is currently something programmed on this button).

=== Replaying ===
To replay a stored RFID tag from the remote, simply press and release the corresponding button in front of the RFID reader. Replay distance of the KeySy is about 5cm. The reader should blink or beep when the tags has been read successfully.

=== Duplicating Tags ===
The KeySy remote can also be used to program empty RFIDs tags with the information stored on one of the buttons.

==== Step 1 ====
Position the remote on top of the empty RFID tag.

==== Step 2 ====
Press the button you wish to copy 5 times, after which the LED will start blinking.

==== Step 3 ====
When programming is finished the LED will blink 3 times green or red, if programming the keyfob failed. In this case please refer to Section [[#Copying RFID Tags| Copying RFID Tags]] Step 3.

== Hardware Limitations ==
The KeySy is designed to only work with RFID Tags which operate on the 125kHz Frequency. This means, NFC tags which operate on '''13.56 MHz cannot be read or copied'''. While perimeter access control systems frequently use low-frequency RFID (e.g., gym cards, garage doors, building key cards), many building key cards provided by employers use NFC, because the require additional functionality such as authentication and are incompatible with the KeySy. Phones also use high frequency RFID, so as a rule of thumb you can remember: ''Any tag your phone can read, the KeySy cannot and vice versa''.

This limitation has been put on the KeySy purposefully for security reasons to prevent the copying of sensitive information, e.g., debit cards.

== References ==

* https://tinylabs.io/keysy/
* https://www.iso.org/standard/56692.html

[[Category:Documentation]]

File:Keysy.png

2021-02-27T07:58:44Z

FChallakhi:

KeySy: Copying and Replaying RFID Tags

2021-02-27T07:58:13Z

FChallakhi: /* Summary */

== Summary ==

The KeySy is an low-frequency RFID duplicator by Tiny Labs, which can be used to store, replay and duplicate 125kHz RFID Tags. It comes with the KeySy remote and an additional rewriteable keyfob, onto which stored data can be duplicated.

[[File: Keysy.png | 300 px]]

== Hardware Used ==

* KeySy RFID Duplicator (includes CR2032 battery)
* programmed 125 kHz RFID Tag
* empty 125 kHz RFID Tag

== Copying RFID Tags ==

==== Step 1 ====

On the KeySy remote, press the button you wish to program until the light starts blinking red (approx. 8 seconds)

==== Step 2 ====
Place the remote on the keycard to be copied until the light stops blinking.
If the copying process was successful, the light will now be green otherwise it will turn amber and you should proceed to Step 3.

==== Step 3 ====
If the light turned amber, the copying process failed. Turn over the tag and repeat Steps 1 & 2 while slowly moving the KeySy remote over the tag.

''' If the copying process keeps failing: '''
* Change the battery: Copying a tag uses a lot more energy than just replaying one. This means, even if the LED lights up, the battery could be too weak to complete the copying process.
* Check KeySy compatibility: The Tag you want to copy is simply not readable by the remote. Refer to Section [[#Hardware Limitations| Hardware Limitations]] or Tiny Labs website under KeySy compatibility for further information.

''Note:'' Any buttons that have already been programmed can be rewritten using the same steps. It is not necessary to explicitly delete information from the remote beforehand.

== Replaying and Duplicating Tags ==

When you press one of the buttons on the KeySy remote, the LED will either flash red (there is nothing programmed on the button) or green (there is currently something programmed on this button).

=== Replaying ===
To replay a stored RFID tag from the remote, simply press and release the corresponding button in front of the RFID reader. Replay distance of the KeySy is about 5cm. The reader should blink or beep when the tags has been read successfully.

=== Duplicating Tags ===
The KeySy remote can also be used to program empty RFIDs tags with the information stored on one of the buttons.

==== Step 1 ====
Position the remote on top of the empty RFID tag.

==== Step 2 ====
Press the button you wish to copy 5 times, after which the LED will start blinking.

==== Step 3 ====
When programming is finished the LED will blink 3 times green or red, if programming the keyfob failed. In this case please refer to Section [[#Copying RFID Tags| Copying RFID Tags]] Step 3.

== Hardware Limitations ==
The KeySy is designed to only work with RFID Tags which operate on the 125kHz Frequency. This means, NFC tags which operate on '''13.56 MHz cannot be read or copied'''. While perimeter access control systems frequently use low-frequency RFID (e.g., gym cards, garage doors, building key cards), many building key cards provided by employers use NFC, because the require additional functionality such as authentication and are incompatible with the KeySy. Phones also use high frequency RFID, so as a rule of thumb you can remember: ''Any tag your phone can read, the KeySy cannot and vice versa''.

This limitation has been put on the KeySy purposefully for security reasons to prevent the copying of sensitive information, e.g., debit cards.

== References ==

* https://tinylabs.io/keysy/
* https://www.iso.org/standard/56692.html

[[Category:Documentation]]

File:ChameleonButton.PNG

2021-02-27T07:51:28Z

FChallakhi:

Chameleon Mini RevE rebooted Usage

2021-02-27T07:48:23Z

FChallakhi: Added a description of the Chameleon Mini and more about the usage with the GUI in Window

== Summary ==

Functionality and usage of Chameleon Mini RevE rebooted

== Requirements ==

* Chameleon Mini RevE Rebooted
* Operating systems are referred as:
** Linux: Ubuntu 18.04 bionic amd64
** Windows: Windows 10 (tested in a VM)

== Description ==

The RFID Multitool ChameleonMini is a powerful and portable RFID emulation and manipulation tool that can emulate RFID tags, read tokens and sniff the radio communication. The credit card-shaped housing and integrated battery make it suitable for mobile use. In addition, transmissions can be read out and all data can be conveniently processed on the computer. Using a freely available open-source application, the ChameleonMini can be conveniently configured via a graphical user interface. Otherwise, it can be connected to a smartphone via USB cable or, in part, via Bluetooth and can thus also be configured on the move. This makes it possible, for example, to read an access card in passing and emulate it directly with the ChameleonMini and thus open a (actually protected) door. The ChameleonMini hardware is capable of emulating various ISO 14443, NFC and ISO 15693 cards, as well as other types of RFID transponders operating at 13.56 MHz. The ChameleonMini hardware consists of a PCB antenna driven by power transistors on the board to generate a 13.56 MHz RFID field. They thus function as an active RFID reader. An integrated Li-Ion battery can be charged via USB and enables stand-alone operation. The core of the hardware is an Atmel ATXMega128A4U microcontroller. The AES and DES hardware engines in the microcontroller enable very fast calculation of the cryptographic algorithms.

[[File:Chameleon-Mini-RevE-Rebooted.jpg|500px]]

=== Functionality of Chameleon Mini RevE rebooted ===

Chameleon Mini RevE rebooted has 8 card slots to simulate cards/UIDs, each slot can be set in an own configuration mode to
* simulate cards/UIDs to readers
* help getting a first auth key from a dialogue with a reader
* only first slot allows up to 4K dumps/uploads because of memory limitations
* the default firmware can only configure MIFARE cards
* RevE does not copy cards

Chameleon Mini RevE rebooted is a stand-alone device powered by CR2032 button battery

===Card configurations supported by default firmware===

* NONE: No functionality, ChameleonMini does nothing, the current setting is skipped when cycling through the settings
* MF_ULTRALIGHT: Emulates a MiFare Ultralight card
* MF_ULTRALIGHT_EV1_80B: Emulates a MiFare Ultralight EV1 80B card
* MF_ULTRALIGHT_EV1_164B: Emulates a MiFare Ultralight EV1 164B card
* MF_CLASSIC_1K: Emulates a MiFare Classic 1k card
* MF_CLASSIC_4K: Emulates a MiFare Classic 4k card
* MF_CLASSIC_1K_7B: Emulates a MiFare Classic 1k card with 7b UID
* MF_CLASSIC_4K_7B: Emulates a MiFare Classic 4k card with 7b UID
* MF_DETECTION: Emulates a MiFare Classic 1k card and saves nonces which can be used for mfkey32 attack in GUI

(Source: https://github.com/iceman1001/ChameleonMini-rebooted/wiki/Configurations, Feb 2,2020)

=== Hardware Description ===
[[File:Chameleon mini.png|200px|thumb|left|Chameleon Mini RevE rebooted]]

* Red Leds on left side:
: - 8 red LEDs which indicate the active slot
* Black Button - "KEY":
: - “short press” referred as BUTTON in commands and GUI and let you switch the active slot
: - “long press” - BUTTON_LONG
: - “long press while plugging USB cable” - BOOTLOADER Mode
* Red Buttern - "POWER":
: - used to power on the device when used stand-alone on battery

 
=== Device Recognition ===

==== Linux ====
The linux kernel recognizes a usb device from the idVendor 03eb with the product id 2fe4

dmesg | grep usb
[ 167.571731] usb 1-3: USB disconnect, device number 3
[ 180.768751] usb 1-3: new full-speed USB device number 11 using xhci_hcd
[ 180.917821] usb 1-3: New USB device found, idVendor=03eb, idProduct=2fe4, bcdDevice= 0.04
[ 180.917829] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0

The chameleon RevE is seen as a USB modem

lsusb
Bus 001 Device 011: ID 03eb:2fe4 Atmel Corp. ATxmega32A4U DFU bootloader

==== Windows ====

* in the Windows device manager should appear an Atmel USB Device: ATxmega32A4U
![](https://i.imgur.com/EJXyvdJ.png)

== Usage ==
===GUI Usage with Chameleon Mini GUI v1.3.0.5 in Windows===
First you need to install the software in order to have a GUI to use the Chameleon Mini. The Version 1.3.0.5 can be downloaded here (http://www.icesql.se/download/ChameleonMiniGUI/publish.htm)
Afterwards connect the Chameleon Mini RevE Rebooted with an USB-Cable to your PC. The first LED with the label "TAG1" now lights up red.

==== Device Recognition ====
On start of the Windows GUI the device should be recognized and following lines should appear in the output window

[=] Connecting to USB Serial Device (COMX) at COMX
[+] Success, found Chameleon Mini device on 'COMX' with Firmware RevE rebooted installed

[[File:ChameleonMiniSuccess.PNG|500px]]

If this is not the case and you are using Windows in a VM verify that the USB device is redirected to the VM and test to connect again in the submenu "Settings"

==== Use of the Chameleon Mini with the GUI in Window ====

In the first tab "Operation" of the Chameleon Mini GUI, up to eight different memory slots can be freely configured. In order to change an entry, the corresponding box of the entry must first be marked. Then one of four different variants can be selected in the "Mode" selection and any ID can be entered in the UID input field as shown below in the screenshot.

[[File:ChameleonOperation.PNG|500px]]

Below this, you can configure what happens when the button is pressed briefly or for a long time.
[[File:ChameleonButton.PNG|300px]]

To save the changes made, the "Apply" button must be clicked at the bottom. It is possible to edit several entries at the same time. To do this, simply select the corresponding checkboxes.

To emulate an RFID tag, first press the red button on the ChameleonMini RevE Rebooted. Now the memory slot that was marked as active in the software is active. Accordingly, the red LED lights up. Alternatively, ChameleonMini RevE Rebooted is activated when an RFID reader is detected. Then it activates automatically and the corresponding LED lights up. Depending on how the buttons have been configured, it is possible to switch through to RFID emulation through the corresponding memory loads.

==Command Line Interface==

==== Command return codes ====
Status numbers beginning with a '1' denote an informational item and those beginning with a '2' denote an error.
{|class="wikitable"
|-
! Response
! Description
|-
|100:OK
|The command has been successfully executed
|-
| 101:OK WITH TEXT
| The command has been successfully executed and this response is appended with an additional line of information, terminated with CR+LF
|-
| 110:WAITING FOR XMODEM
| The Chameleon is waiting for an XMODEM connection to be established
|-
| 120:FALSE
| The request is answered with false
|-
| 121:TRUE
| The request is answered with true
|-
| 200:UNKNOWN COMMAND
| This command is unknown to the Chameleon
|-
| 201:INVALID COMMAND USAGE
| This action is not supported by this command
|-
| 202:INVALID PARAMETER
| The format or value of the given parameter value is invalid
|-
| 203:TIMEOUT
| The timeout of the currently active command has expired
|+ Command response codes
|}

== Used Hardware ==

[[Chameleon Mini: RevE Rebooted]]

== References ==

* Wiki: https://github.com/iceman1001/ChameleonMini-rebooted/wiki
* Linux GUI: https://github.com/WolfgangMau/chamgo-qt/releases
* Windows GUI: https://github.com/iceman1001/ChameleonMini-rebootedGUI
* Product description: https://lab401.com/products/chameleon-mini-reve-rebooted
* https://scheible.it/chameleon-mini/

[[Category:Documentation]]

File:ChameleonOperation.PNG

2021-02-24T20:36:31Z

FChallakhi: FChallakhi uploaded a new version of File:ChameleonOperation.PNG

File:ChameleonOperation.PNG

2021-02-24T20:35:21Z

FChallakhi:

ChameleonMini RevE Rebooted

2021-02-24T20:35:04Z

FChallakhi: Added the chapter ChameleonMini in Use

== Introduction ==

The RFID Multitool ChameleonMini is a powerful and portable RFID emulation and manipulation tool that can emulate RFID tags, read tokens and sniff the radio communication. The credit card-shaped housing and integrated battery make it suitable for mobile use. In addition, transmissions can be read out and all data can be conveniently processed on the computer. Using a freely available open-source application, the ChameleonMini can be conveniently configured via a graphical user interface. Otherwise, it can be connected to a smartphone via USB cable or, in part, via Bluetooth and can thus also be configured on the move. This makes it possible, for example, to read an access card in passing and emulate it directly with the ChameleonMini and thus open a (actually protected) door. The ChameleonMini hardware is capable of emulating various ISO 14443, NFC and ISO 15693 cards, as well as other types of RFID transponders operating at 13.56 MHz. The ChameleonMini hardware consists of a PCB antenna driven by power transistors on the board to generate a 13.56 MHz RFID field. They thus function as an active RFID reader. An integrated Li-Ion battery can be charged via USB and enables stand-alone operation. The core of the hardware is an Atmel ATXMega128A4U microcontroller. The AES and DES hardware engines in the microcontroller enable very fast calculation of the cryptographic algorithms.

[[File:Chameleon-Mini-RevE-Rebooted.jpg|500px]]

== Requirements ==

* ChameleonMini
* PC having Windows (it is also possible to use a Android Phone, but this setup will be will on a Windows-PC.

== Setup ==

=== Step 1 ===

First you need to install the software in order to have a GUI to use the Chameleon Mini. The Version 1.3.0.5 can be downloaded here (http://www.icesql.se/download/ChameleonMiniGUI/publish.htm)
Afterwards connect the ChameleonMini RevE Rebooted with an USB-Cable to your PC.

=== Step 2 ===

The first LED with the label "TAG1" now lights up red. Now switch to the "Settings" tab, a photo is displayed there and there is a green message with the designation "CONNECTED! In the lower area with the messages, "Success, found Chameleon Mini device on 'COMX' with Firmware RevE rebooted installed" appears like in the screenshot below. The ChameleonMini RevE Rebooted is now ready for use.

[[File:ChameleonMiniSuccess.PNG|500px]]

== ChameleonMini in Use ==

In the first tab "Operation" of the Chameleon Mini GUI, up to eight different memory slots can be freely configured. In order to change an entry, the corresponding box of the entry must first be marked. Then one of four different variants can be selected in the "Mode" selection and any ID can be entered in the UID input field as shown below in the screenshot.

[[File:ChameleonOperation.PNG|500px]]

Below this, you can configure what happens when the button is pressed briefly or for a long time.
[[File:ChameleonButton.PNG|300px]]

To save the changes made, the "Apply" button must be clicked at the bottom. It is possible to edit several entries at the same time. To do this, simply select the corresponding checkboxes.

To emulate an RFID tag, first press the red button on the ChameleonMini RevE Rebooted. Now the memory slot that was marked as active in the software is active. Accordingly, the red LED lights up. Alternatively, ChameleonMini RevE Rebooted is activated when an RFID reader is detected. Then it activates automatically and the corresponding LED lights up. Depending on how the buttons have been configured, it is possible to switch through to RFID emulation through the corresponding memory loads.

== References ==

* https://github.com/iceman1001/ChameleonMini-rebootedGUI
* https://scheible.it/chameleon-mini/

[[Category:Documentation]]

ChameleonMini RevE Rebooted

2021-02-24T20:29:41Z

FChallakhi: changed the size of the pictures

File:ChameleonMiniSuccess.PNG

2021-02-24T20:28:33Z

FChallakhi:

File:Chameleon-Mini-RevE-Rebooted.jpg

2021-02-24T20:28:03Z

FChallakhi:

ChameleonMini RevE Rebooted

2021-02-24T20:27:07Z

FChallakhi: Created page with "== Introduction == The RFID Multitool ChameleonMini is a powerful and portable RFID emulation and manipulation tool that can emulate RFID tags, read tokens and sniff the rad..."

OPTIGA Trust X

2021-01-30T15:57:54Z

FChallakhi:

== Introduction ==

OPTIGA Trust X is a turnkey security solution for embedded systems based on a secure
microcontroller. It can be deployed for smart homes, industrial control and automation
systems, consumer electronics and medical devices.
Through a unique elliptic curve keypair and a corresponding X.509 certificate on
each device, easy integration into existing PKI infrastructure is enabled by the OPTIGA Trust X.

[[File:OptigaTrustX.png]]

===Key Features and Benefits===

The OPTIGA Trust X comes with some key feature and benefits:

* High-end security controller
* Turnkey solution
* Network node protection such as TLS or DTLS
* Compliant with the USB Type-C™ Authentication standard
* I2C interface
* One-way authentication using ECDSA
* Cryptographic support: ECC256, AES128 (via on-chip DTLS client), SHA-256, TRNG, DRNG
* Up to 10 KB user memory
* Mutual authentication using DTLS client (IETF standard RFC 6347)
* Secure communication using DTLS
* Standard and extended temperature ranges
* PG-USON-10-2 package (3 x 3 mm)
* Full system integration support
* Lifetime for Industrial Automation and Infrastructure is 20 years and 15 years for other Application Profiles
* Cryptographic Tool Box based on ECC NIST P256, P384 and SHA256 (sign, verify, key generation, ECDH, session key derivation)
* Common Criteria Certified EAL6+ (high) hardware

===Use Cases===

The OPTIGA Trust X has several use cases, including:

* Network node protection such as TLS or DTLS
* Protect the Authenticity, Integrity and Confidentiality of your product, data and IP
* Mutual Authentication
* Secure Communication
* Datastore Protection
* Lifecycle Management
* Platform Integrity Protection
* Secure Updates \cite{AppNote}

== Installation ==

In this section we are going the the step that are needed to install the Optiga Trust X.

=== Step 1 ===

The OPTIGA Trust X offers on their GitHub page, a repository that you can get via GIT and which contains the code you need to start the OPTIGA Trust X functions.
The repository can be found on https://github.com/Infineon/getstarted-optiga-trustx.git.

=== Step 2 ===

For the project we use the DAVE IDE from Infineon, because for an OPTIGA project we need DAVE specific files and folders that help us to use the functions of the OPTIGA Trust X security chip. The DAVE software can be downloaded with a free Infineon account.
After downloading you can install DAVE by unpacking the downloaded file DAVE3.1.10.zip. In the Eclipse Folder there should be a DAVE-3.1.10.exe file. By double clicking it DAVE should start. After that choose a workspace as shown in the figure below. Now the DAVE development environment should be seen.

[[File:DaveWorkspace.PNG|500px]]

=== Step 3 ===

Having DAVE open, open the following window '' File -> Import...''. Choose then the folder ''Infineon'' and the file ''DAVE Project'' as shown in the picture.

[[File:SelectDave.PNG|500px]]

Next you should choose as root directory the repository you got from git and select all in the Project List. At the end press finish.

[[File:DaveRepos.PNG|500px]]

The final project should look like the picture below.

[[File:finalproject.PNG|700px]]

=== Step 4 ===

Press ''Project -> Build Active Project'' menu item to build the project. In the picture you can see how the console output of building the project.

[[File:Building.PNG|700px]]

=== Step 5 ===

The OPTIGA Trust X has a build-in debugger that can be accessed via a Micro USB port on the XMC Microcontroller.

To debug or flash the microcontroller, you have to create the debug configuration via the DAVE. To do this, press the green bug symbol in the instrument panel. Then a new ''GDB SEGGER J-Link debugging'' should be created. After that it should look like the picture below. You do not have to change something in the configuration just click Debug. The board should be connected to the PC while debugging.

[[File:debug.jpg|500px]]

== Used Hardware ==

The used hardware was the [[Optiga_Trust_X_evaluation_kit]].

[[Category:Documentation]]

File:Building.PNG

2021-01-30T15:35:57Z

FChallakhi:

File:Finalproject.PNG

2021-01-30T15:35:46Z

FChallakhi:

File:DaveRepos.PNG

2021-01-30T15:35:34Z

FChallakhi:

File:SelectDave.PNG

2021-01-30T15:35:18Z

FChallakhi:

File:DaveWorkspace.PNG

2021-01-30T15:35:01Z

FChallakhi:

File:Debug.jpg

2021-01-30T15:34:07Z

FChallakhi:

File:OptigaTrustX.png

2021-01-30T15:33:47Z

FChallakhi:

OPTIGA Trust X

2021-01-30T15:32:43Z

FChallakhi:

== Introduction ==

OPTIGA Trust X is a turnkey security solution for embedded systems based on a secure
microcontroller. It can be deployed for smart homes, industrial control and automation
systems, consumer electronics and medical devices.
Through a unique elliptic curve keypair and a corresponding X.509 certificate on
each device, easy integration into existing PKI infrastructure is enabled by the OPTIGA Trust X.

[[File:OptigaTrustX.png]]

===Key Features and Benefits===

The OPTIGA Trust X comes with some key feature and benefits:

* High-end security controller
* Turnkey solution
* Network node protection such as TLS or DTLS
* Compliant with the USB Type-C™ Authentication standard
* I2C interface
* One-way authentication using ECDSA
* Cryptographic support: ECC256, AES128 (via on-chip DTLS client), SHA-256, TRNG, DRNG
* Up to 10 KB user memory
* Mutual authentication using DTLS client (IETF standard RFC 6347)
* Secure communication using DTLS
* Standard and extended temperature ranges
* PG-USON-10-2 package (3 x 3 mm)
* Full system integration support
* Lifetime for Industrial Automation and Infrastructure is 20 years and 15 years for other Application Profiles
* Cryptographic Tool Box based on ECC NIST P256, P384 and SHA256 (sign, verify, key generation, ECDH, session key derivation)
* Common Criteria Certified EAL6+ (high) hardware

===Use Cases===

The OPTIGA Trust X has several use cases, including:

* Network node protection such as TLS or DTLS
* Protect the Authenticity, Integrity and Confidentiality of your product, data and IP
* Mutual Authentication
* Secure Communication
* Datastore Protection
* Lifecycle Management
* Platform Integrity Protection
* Secure Updates \cite{AppNote}

== Installation ==

In this section we are going the the step that are needed to install the Optiga Trust X.

=== Step 1 ===

The OPTIGA Trust X offers on their GitHub page, a repository that you can get via GIT and which contains the code you need to start the OPTIGA Trust X functions.
The repository can be found on https://github.com/Infineon/getstarted-optiga-trustx.git.

=== Step 2 ===

For the project we use the DAVE IDE from Infineon, because for an OPTIGA project we need DAVE specific files and folders that help us to use the functions of the OPTIGA Trust X security chip. The DAVE software can be downloaded with a free Infineon account.
After downloading you can install DAVE by unpacking the downloaded file DAVE3.1.10.zip. In the Eclipse Folder there should be a DAVE-3.1.10.exe file. By double clicking it DAVE should start. After that choose a workspace as shown in the figure below. Now the DAVE development environment should be seen.

[[File:DaveWorkspace.PNG]]

=== Step 3 ===

Having DAVE open, open the following window '' File -> Import...''. Choose then the folder ''Infineon'' and the file ''DAVE Project'' as shown in the picture.

[[File:SelectDave.PNG]]

Next you should choose as root directory the repository you got from git and select all in the Project List. At the end press finish.

[[File:DaveRepos.PNG]]

The final project should look like the picture below.

[[File:finalproject.PNG]]

=== Step 4 ===

Press ''Project -> Build Active Project'' menu item to build the project. In the picture you can see how the console output of building the project.

[[File:Building.PNG]]

=== Step 5 ===

The OPTIGA Trust X has a build-in debugger that can be accessed via a Micro USB port on the XMC Microcontroller.

To debug or flash the microcontroller, you have to create the debug configuration via the DAVE. To do this, press the green bug symbol in the instrument panel. Then a new ''GDB SEGGER J-Link debugging'' should be created. After that it should look like the picture below. You do not have to change something in the configuration just click Debug. The board should be connected to the PC while debugging.

[[File:debug.jpg]]

== Used Hardware ==

The used hardware was the [[Optiga_Trust_X_evaluation_kit]].

[[Category:Documentation]]

OPTIGA Trust X

2021-01-24T22:50:24Z

FChallakhi:

== Summary ==

OPTIGA Trust X is a turnkey security solution for embedded systems based on a secure
microcontroller. It can be deployed for smart homes, industrial control and automation
systems, consumer electronics and medical devices.
Through a unique elliptic curve keypair and a corresponding X.509 certificate on
each device, easy integration into existing PKI infrastructure is enabled by the OPTIGA Trust X.

== Installation ==

=== Step 1 ===

The OPTIGA Trust X offers on their GitHub page, a repository that you can get via GIT and which contains the code you need to start the OPTIGA Trust X functions.
The repository can be found on https://github.com/Infineon/getstarted-optiga-trustx.git.

=== Step 2 ===

For the project we use the DAVE IDE from Infineon, because for an OPTIGA project we need DAVE specific files and folders that help us to use the functions of the OPTIGA Trust X security chip. The DAVE software can be downloaded with a free Infineon account.
After downloading you can install DAVE by unpacking the downloaded file DAVE3.1.10.zip. In the Eclipse Folder there should be a DAVE-3.1.10.exe file. By double clicking it DAVE should start. After that choose a workspace as shown in the figure below. Now the DAVE development environment should be seen.

=== Step 3 ===

== Used Hardware ==

The used hardware was the [[Optiga_Trust_X_evaluation_kit]].

[[Category:Documentation]]

File:SetupDriver.png

2020-12-27T23:34:44Z

FChallakhi:

File:OperatingSystemsEU4206.png

2020-12-27T23:34:31Z

FChallakhi:

File:DeviceManagerASIX.png

2020-12-27T23:34:10Z

FChallakhi:

OPTIGA Trust X

2020-12-27T23:30:55Z

FChallakhi: /* Step 1 */

== Summary ==

OPTIGA Trust X is a turnkey security solution for embedded systems based on a secure
microcontroller. It can be deployed for smart homes, industrial control and automation systems,
consumer electronics and medical devices. In this Article you will learn how to install it on your PC.

== Requirements ==

* Operating systems: Windows XP. Windows Vista, Windows 7 or Windows 8/Windows8.1 (the Version that I have is not for Windows 10)
* CD/DVD ROM drive
* Router/Switch/Hub

== Description ==

=== Step 1 ===

For the installation you need to insert the installation CD into your computer's CD/DVD ROM drive and the the following picture should appear. If not check the autorun.exe on the CD. Click then on the picture of the USB Fast Etherenet adapter.

[[File:WelcomeEU4208.png]]

To begin the installation you have to select option "Setup Driver".

[[File:SetupDriver.png]]

Then you need to select your operating system. As mentioned in the Requirements the installation is only for Windows XP, Windows Vista, Windows 7 or Windows8/Windows 8.1 possible.

[[File:OperatingSystemsEU4206.png]]

After finishing you may need to restart your computer.

=== Step 2 ===

When the installation finished you have to connect the ethernet cable that is part of the [[Optiga_Trust_X_evaluation_kit]] to the ether port on the adapter which is also port of the kit.

The other end of the Ethernet cable should be connected to your network hub, switch or router.

Conntect the end of the Ethernet adapter to a free USB port of your computer. Then you will be notifed by a pop-up message that the installation is completed. The Link LED on the Microcontroller should light up in yellow to indicate a proper physical connection between the adapter and the network.

=== Step 3 ===

To check if the driver of the adapter is verifed, open on Windows the Device Maanger.

In the Network adapters group, an item named ASIX AX88772B USB2.0 to Fast Ethernet Adapter should be listed.

[[File:DeviceManagerASIX.png]]

In the case that there is a question or exclamation mark next to that item then the driver is not properly installed and you need to delete the item, unplug the adapter and repeat the installation steps. The driver can be uninstalled in the Programs and Features panel of Windows.

== Used Hardware ==

The used hardware was the [[Optiga_Trust_X_evaluation_kit]].

[[Category:Documentation]]

File:WelcomeEU4208.png

2020-12-27T23:30:34Z

FChallakhi:

OPTIGA Trust X

2020-12-27T23:24:15Z

FChallakhi: Inserted the text

== Summary ==

OPTIGA Trust X is a turnkey security solution for embedded systems based on a secure
microcontroller. It can be deployed for smart homes, industrial control and automation systems,
consumer electronics and medical devices. In this Article you will learn how to install it on your PC.

== Requirements ==

* Operating systems: Windows XP. Windows Vista, Windows 7 or Windows 8/Windows8.1 (the Version that I have is not for Windows 10)
* CD/DVD ROM drive
* Router/Switch/Hub

== Description ==

=== Step 1 ===

For the installation you need to insert the installation CD into your computer's CD/DVD ROM drive and the the following picture should appear. If not check the autorun.exe on the CD. Click then on the picture of the USB Fast Etherenet adapter.

[[File:WelcomeEU4206.png]]

To begin the installation you have to select option "Setup Driver".

[[File:SetupDriver.png]]

Then you need to select your operating system. As mentioned in the Requirements the installation is only for Windows XP, Windows Vista, Windows 7 or Windows8/Windows 8.1 possible.

[[File:OperatingSystemsEU4206.png]]

After finishing you may need to restart your computer.

=== Step 2 ===

When the installation finished you have to connect the ethernet cable that is part of the [[Optiga_Trust_X_evaluation_kit]] to the ether port on the adapter which is also port of the kit.

The other end of the Ethernet cable should be connected to your network hub, switch or router.

Conntect the end of the Ethernet adapter to a free USB port of your computer. Then you will be notifed by a pop-up message that the installation is completed. The Link LED on the Microcontroller should light up in yellow to indicate a proper physical connection between the adapter and the network.

=== Step 3 ===

To check if the driver of the adapter is verifed, open on Windows the Device Maanger.

In the Network adapters group, an item named ASIX AX88772B USB2.0 to Fast Ethernet Adapter should be listed.

[[File:DeviceManagerASIX.png]]

In the case that there is a question or exclamation mark next to that item then the driver is not properly installed and you need to delete the item, unplug the adapter and repeat the installation steps. The driver can be uninstalled in the Programs and Features panel of Windows.

== Used Hardware ==

The used hardware was the [[Optiga_Trust_X_evaluation_kit]].

[[Category:Documentation]]

OPTIGA Trust X

2020-12-27T21:15:56Z

FChallakhi: 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..."

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

Optiga Trust X evaluation kit

2020-12-20T20:54:56Z

FChallakhi:

{{Device|device_name=Optiga Trust X evaluation kit|manufacturer=Infineon|link=|image_link=https://stuff.elvis.science/uploads/models/optigajpg.jpg|description=|technicalSpecification=|supportedTechnologies=|includedEquipment=}}

wird bis 27.12.2020 fertiggestellt

Install c't'-Raspion on Raspberry PI

2020-07-02T13:25:12Z

FChallakhi: /* mitmproxy */

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

In the figure below you can see how the DNS query is displayed. You can view information such as time, type, domain, client, etc.
[[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.

Here we see an example of an overview of the system in ntopng. As you can see, it displays information about the CPU, RAM, Last Log Trace of ntopng and so on:
[[File:ntopng_system.jpeg|800px]]

In this screenshot we see the network information like devices, flows, total traffic, total packets of the interface "br0" and much else.
[[File: ntopng_interface.jpeg|800px]]

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

There are many options for the search, as you can see in the 2 screenshots below.

[[File: mitmproxy_option.jpeg|800px]]
[[File: mitmproxy_option_search.jpeg|800px]]

Below is a little preview of what you get when you click on "Editing Options Alpha".

[[File: mitmproxy_option_alpha.PNG|800px]]

== 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-07-02T13:24:54Z

FChallakhi: /* mitmproxy */

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

In the figure below you can see how the DNS query is displayed. You can view information such as time, type, domain, client, etc.
[[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.

Here we see an example of an overview of the system in ntopng. As you can see, it displays information about the CPU, RAM, Last Log Trace of ntopng and so on:
[[File:ntopng_system.jpeg|800px]]

In this screenshot we see the network information like devices, flows, total traffic, total packets of the interface "br0" and much else.
[[File: ntopng_interface.jpeg|800px]]

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

There are many options for the search, as you can see in the 2 screenshots below.

[[File: mitmproxy_option.jpeg|800px]]
[[File: mitmproxy_option_search.jpeg|800px]]

Below is a little preview of what you get when you click on "Editing Options Alpha".

[[File: mitmproxy_option_alpha.png|800px]]

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

File:Mitmproxy option alpha.PNG

2020-07-02T13:24:18Z

FChallakhi:

Install c't'-Raspion on Raspberry PI

2020-07-02T13:22:26Z

FChallakhi: /* mitmproxy */

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

In the figure below you can see how the DNS query is displayed. You can view information such as time, type, domain, client, etc.
[[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.

Here we see an example of an overview of the system in ntopng. As you can see, it displays information about the CPU, RAM, Last Log Trace of ntopng and so on:
[[File:ntopng_system.jpeg|800px]]

In this screenshot we see the network information like devices, flows, total traffic, total packets of the interface "br0" and much else.
[[File: ntopng_interface.jpeg|800px]]

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

There are many options for the search, as you can see in the 2 screenshots below.

[[File: mitmproxy_option.jpeg|800px]]
[[File: mitmproxy_option_search.jpeg|800px]]

Below is a little preview of what you get when you click on "Editing Options Alpha".

[[File: mitmproxy_option_alpha.jpeg|800px]]

== 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-07-02T13:18:23Z

FChallakhi: /* Pi-hole */

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

In the figure below you can see how the DNS query is displayed. You can view information such as time, type, domain, client, etc.
[[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.

Here we see an example of an overview of the system in ntopng. As you can see, it displays information about the CPU, RAM, Last Log Trace of ntopng and so on:
[[File:ntopng_system.jpeg|800px]]

In this screenshot we see the network information like devices, flows, total traffic, total packets of the interface "br0" and much else.
[[File: ntopng_interface.jpeg|800px]]

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

There are many options for the search, as you can see in the 2 screenshots below.

[[File: mitmproxy_option.jpeg|800px]]
[[File: mitmproxy_option_search.jpeg|800px]]

== 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-07-02T13:15:12Z

FChallakhi: /* mitmproxy */

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

Here we see an example of an overview of the system in ntopng. As you can see, it displays information about the CPU, RAM, Last Log Trace of ntopng and so on:
[[File:ntopng_system.jpeg|800px]]

In this screenshot we see the network information like devices, flows, total traffic, total packets of the interface "br0" and much else.
[[File: ntopng_interface.jpeg|800px]]

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

There are many options for the search, as you can see in the 2 screenshots below.

[[File: mitmproxy_option.jpeg|800px]]
[[File: mitmproxy_option_search.jpeg|800px]]

== 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-07-02T13:14:53Z

FChallakhi: /* ntopng */

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

Here we see an example of an overview of the system in ntopng. As you can see, it displays information about the CPU, RAM, Last Log Trace of ntopng and so on:
[[File:ntopng_system.jpeg|800px]]

In this screenshot we see the network information like devices, flows, total traffic, total packets of the interface "br0" and much else.
[[File: ntopng_interface.jpeg|800px]]

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

There are many options for the search, as you can see in the 2 screenshots below.

[[File: mitmproxy_option.jpeg]]
[[File: mitmproxy_option_search.jpeg]]

== 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-07-02T13:14:07Z

FChallakhi: /* ntopng */

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

Here we see an example of an overview of the system in ntopng. As you can see, it displays information about the CPU, RAM, Last Log Trace of ntopng and so on:
[[File:ntopng_system.jpeg|200×269px]]

In this screenshot we see the network information like devices, flows, total traffic, total packets of the interface "br0" and much else.
[[File: ntopng_interface.jpeg]]

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

There are many options for the search, as you can see in the 2 screenshots below.

[[File: mitmproxy_option.jpeg]]
[[File: mitmproxy_option_search.jpeg]]

== 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-07-02T13:09:23Z

FChallakhi: /* mitmproxy */

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

Here we see an example of an overview of the system in ntopng. As you can see, it displays information about the CPU, RAM, Last Log Trace of ntopng and so on:
[[File: ntopng_system.jpeg]]

In this screenshot we see the network information like devices, flows, total traffic, total packets of the interface "br0" and much else.
[[File: ntopng_interface.jpeg]]

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

There are many options for the search, as you can see in the 2 screenshots below.

[[File: mitmproxy_option.jpeg]]
[[File: mitmproxy_option_search.jpeg]]

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

File:Mitmproxy option.jpeg

2020-07-02T13:09:05Z

FChallakhi:

File:Mitmproxy option search.jpeg

2020-07-02T13:08:44Z

FChallakhi:

Install c't'-Raspion on Raspberry PI

2020-07-02T13:05:35Z

FChallakhi: /* ntopng */

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

Here we see an example of an overview of the system in ntopng. As you can see, it displays information about the CPU, RAM, Last Log Trace of ntopng and so on:
[[File: ntopng_system.jpeg]]

In this screenshot we see the network information like devices, flows, total traffic, total packets of the interface "br0" and much else.
[[File: ntopng_interface.jpeg]]

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

There are many options for the search, as you can see in the 2 screenshots below.

[[File: mitmproxy_option.png]]
[[File: mitmproxy_option_search.png]]

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

File:Ntopng interface.jpeg

2020-07-02T13:05:14Z

FChallakhi:

File:Ntopng system.jpeg

2020-07-02T13:03:58Z

FChallakhi:

Install c't'-Raspion on Raspberry PI

2020-07-02T13:00:10Z

FChallakhi:

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

Here we see an example of an overview of the system in ntopng. As you can see, it displays information about the CPU, RAM, Last Log Trace of ntopng and so on:
[[File: ntopng_system.png]]

In this screenshot we see the network information like devices, flows, total traffic, total packets of the interface "br0" and much else.
[[File: ntopng_interface.png]]

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

There are many options for the search, as you can see in the 2 screenshots below.

[[File: mitmproxy_option.png]]
[[File: mitmproxy_option_search.png]]

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

File:Pi-hole.png

2020-06-09T14:18:24Z

FChallakhi: FChallakhi uploaded a new version of File:Pi-hole.png

File:Pi-hole.png

2020-06-09T14:18:11Z

FChallakhi: FChallakhi uploaded a new version of File:Pi-hole.png

File:Pi-hole.png

2020-06-09T14:17:41Z

FChallakhi: FChallakhi uploaded a new version of File:Pi-hole.png

File:Pi-hole.png

2020-06-09T14:17:33Z

FChallakhi: FChallakhi uploaded a new version of File:Pi-hole.png