TL;DR

I found following vulnerabilities on the Airtame Device (Before Version 3)

1. Session Fixation (CVE-2017-15304)
2. Updating Firmware via HTTP
3. Using Weak Cryptographic Hash Function For File Integrity
4. Using Weak Cryptographic Hash Function For Storing Passwords
5. Using Hardcoded Credentials

Problem 1, 4, 5 are gone since they removed their Php web panel. It's not possible for me to retest the problem 2 and 3 since I don't have the device anymore. Since 2,5 months have passed from initial report submission, I don't think it's an ethical issue to share them publicly.

Introduction

In July, I got an Airtame Device and decided to test it. First of all, let me introduce the Airtame:

"Airtame is an enterprise-grade wireless HDMI solution for offices, meeting rooms and classrooms. Users can share content from their laptop or mobile device to one or more screens. Airtame's digital signage capabilities will also help in utilizing screens by showing relevant information when nobody's using those screens." - https://help.airtame.com/general/faqs/what-is-airtame-including-video

After initial setup, I noticed that it has a web panel for device configuration. I did my blackbox test on this panel.

I was also capturing the traffic while I was digging the functionalities on the panel. I noticed that it updates it's firmware from this URL: http://repos-cdn.airtame.com/firmware/beta/

This URL doesn't require any authentication and provides the firmware of all versions. I also reported this URL to Airtame team but they said that page is publicly available on purpose, so I can share it with you.

After I downloaded latest.tar.gz file from here, I noticed that it's an img file. I mounted it to see what is inside (Following screenshot shows firmware version 3 but this article is about version 2.3, don't get confused)

 mount -o loop,offset=159383552 airtame-fw-v3.0.0-b6.img /mnt/disk3 

After then, it was possible to check the source code of Php web panel. I found following vulnerabilities during my test.

Session Fixation (CVE-2017-15304)

This vulnerability occurs in login functionality in the Web Panel. It’s possible to set our own cookie by editing “PHPSESSID” header in the POST request of the login action. Following screenshot shows our login request. Note that PHPSESSID value is changed to “a”:

Application accepts this value and sets it as our session id. Following screenshot shows the response to the request above.

To prove that our valid session id is “a”, I changed PHPSESSID value to something else and navigated to /bin/get_config.php which requires login. Application denied our request since the PHPSESSID wasn’t valid.

Now, I changed back it to “a” again to prove that this is the valid session id. Application accepts that value.

The important point is, this session id is not invalidated via logout functionality. So if attacker knows the correct admin password, he can set a custom session id for the admin user. After then, even if the admin user changes his password, since the session id will be still valid, attacker can login the application.

Updating Firmware via HTTP

By listening the traffic of the application, I noticed that it downloads firmware file via HTTP. Which means that firmware files can be altered during transmission.

Since I don't have the Airtame device anymore, I could only retest the vulnerabilities via latest firmware file. Update is triggered via "airtame-device-update" binary file. Since I can't reverse engineer shit, best option for me to grep an URL

It's still HTTP. But doesn't mean that it will download the firmware file via HTTP. That "checkfw.php" checks the given version and -probably- returns true or false. In my case, it was always false since there is no new update. As a result, I don't know if this is fixed but earlier Airtame team said they will carry the update channel to HTTPS.

Using Weak Cryptographic Hash Function For File Integrity

By listening the traffic of the application, I noticed that integrity check is done with MD5 hashing algorithm.

http://repos-cdn.airtame.com/firmware/beta/latest.rootfs.md5

To be honest, if you are using HTTP to download updates, hash comparison doesn't mean anything. Attacker can change the update file and it's hash on air. Even if you use HTTPS for update and put the file and it's hash to the same server, it's still doesn't provide anything. If an attacker can compromise the server, he can change both file and it's hash. For me the best practise should be getting update file and it's hash from different servers.

I'm not sure if this vulnerability is fixed.

Using Weak Cryptographic Hash Function For Storing Passwords

In source code analysis,  I noticed that application stores user passwords with MD5 hashes.

Using Hardcoded Credentials

I observed that application uses hardcoded credentials for communicating with server.

Result

Airtame team was very kind and they commented every vulnerability seriously. They sent me a t-shirt, some stickers and this beatiful note with a team picture.

Disclosure Timeline

-Report submitted to Airtame (3 August 2017)

-Airtame team confirmed the vulnerabilities and said they will be gone in next update (7 August 2017)

-New Airtame update available (9 October 2017)