TP-Link Kasa App: SSL Verification Disabled (Fixed)

For an unknown period of time prior to December 2017, the Kasa "Smart Home" control application for Android failed to validate any TLS certificates when communicating to TP-Link's servers. This app is used for control of the company's line of smart plugs, light bulbs, and home hub, and affected all phases of the use of the app, including user registration, authentication, and device control.

A Cheap and Compact Bench Power Supply

I wanted a bench power supply for powering small projects and devices I'm testing. I ended up with a DIY approach for around $30 and am very happy with the outcome. It's a simple project that almost anyone can do and is a great introductory power supply for any home lab.

Even With the Cloud, Client Security Still Matters

Despite the move of resources to the cloud, security of your clients and endpoints remains important. Some believe that only servers need to be secured, but it's important to remember that the clients with access to servers are equally vulnerable to compromise and use to gain access.

2017 Christmas Ornament

After playing around with a custom DEF CON badge, I wanted to do another electronics project just for fun. What better time to share electronics with others than Christmas? So I decided to do a custom ornament for friends and family.

Though it shared some characteristics with my DEF CON badge (blinken lights, battery powered, etc.), the similarities ended there. In this case I want something lightweight (it’s going on a tree branch), simple (the XXV badges took a long time to assemble by hand), and that could run off a coin cell battery for days.

Not being the most artistic of individuals, I went with a simple snowflake design and 6 LEDs at the points. At first, I wanted to do white LEDs, but since they have a forward voltage around 3.2V, that wouldn’t work well with a single 3V coin cell, so I settled for 1.8V Red LEDs. (The battery will be unable to produce much current at all long before it reaches 1.8V.)

Snowflake Ornament Front

The ornament base is a red soldermask PCB with gold-plated (ENIG) copper. The boards were produced at Elecrow and I hand assembled the parts. The microcontroller is the ATTiny2313A, chosen both for low power consumption and low cost. (Driving 6 LEDs doesn’t take much in the way of CPU.) I chose not to use the ATTiny25/45/85 series because I didn’t want to deal with multiplexing pins to drive the LEDs and in-circuit programming (ICSP) header.

Schematic

The schematic is pretty straight forward. There’s a battery holder and a couple of power supply capacitors (due to PWM of the lights, I didn’t want the input voltage bouncing around too much), the microcontroller, a single resistor network, and the 6 LEDs which are on the front of the board. The full bill of materials includes:

1
2
3
4
5
6
7
8
9
Label   Description
---------------------------------------------------------------
BT1     20mm SMD Coin Cell Holder
C1      0.1uF Ceramic Capacitor (0805)
C2      10uF Ceramic Capacitor (0805)
U1      ATTiny2313A (QFN20)
RN1     Resistor Network, 8 Independent, 100 Ohm Each
D1-D6   Red SMD LED (0805)
J1      2x3 Header, SMD, 2.54mm Spacing (AVR ICSP)

On the actual ornaments, the ICSP header is unpopulated – I manually held a connector to it to program each one. I left the connector in a standard format instead of a pogo pin arrangement in case any of my recipients wanted to hack on the firmware. (Since it’s Open Source.)

Snowflake Ornament Back

It was a fun little project and I’m already considering how I can improve for a new one next year. Full schematics, design files, and source code are on Github.

[CVE-2017-17704] Broken Cryptography in iStar Ultra & IP ACM by Software House

Introduction

Vulnerabilities were identified in the iStar Ultra & IP-ACM boards offered by Software House. This system is used to control physical access to resources based on RFID-based badge readers. Badge readers interface with the IP-ACM board, which uses TCP/IP to communicate with the iStar Ultra controller.

These were discovered during a black box assessment and therefore the vulnerability list should not be considered exhaustive; observations suggest that it is likely that further vulnerabilities exist. It is strongly recommended that Software House undertake a full whitebox security assessment of this application. Additionally, it is our suggestion that all communications be conducted over TLS. While alternatives are suggested below, cryptography is very difficult even for experts, and so using a well-understood cryptosystem like TLS is preferable to home-grown solutions. The version under test was indicated as: 6.5.2.20569. As of the time of disclosure, the issues remain unfixed.

Issues Found

The communications between the IP-ACM and the iStar Ultra is encrypted using a fixed AES key and IV. Each message is encrypted in CBC mode and restarts with the fixed IV, leading to replay attacks of entire messages. There is no authentication of messages beyond the use of the fixed AES key, so message forgery is also possible. A working proof of concept has been demonstrated that allows an attacker with access to the IP network used by the IP-ACM and iStar Ultra to unlock doors connected to the IP-ACM. (This PoC will not be disclosed at this time, due to the issue remaining unfixed.)

Impact & Workaround

An attacker with access to the network can unlock doors without generating any log entry of the door unlock. An attacker can also prevent legitimate unlock attempts. Organizations using these devices should ensure that the network used for IP-ACM to iStar Ultra communications is not accessible to potential attackers.

Timeline

  • 2017/07/01-2017/07/14 - Issues discovered
  • 2017/07/19 - Issues disclosed to Software House
  • 2017/08/29 - Issues acknowledged & proposed fixes discussed. Informed that current hardware could not be fixed and fixes would only apply to new products.
  • 2017/10/19 - 90 day window elapsed in accordance with disclosure policy.
  • 2017/12/18 - Public disclosure.

Credit

These issues were discovered by David Tomaschik of the Google Security Team.