lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 27 Jul 2017 22:19:12 -0400
From: Nightwatch Cybersecurity Research <research@...htwatchcybersecurity.com>
To: fulldisclosure@...lists.org
Subject: [FD] Boozt Fashion Android App Didn’t Use SSL for Login [CVE-2017-11706]

[Original post here:
https://wwws.nightwatchcybersecurity.com/2017/07/27/boozt-fashion-android-app-didnt-use-ssl-for-login-cve-2017-11706/]

SUMMARY

Boozt Fashion App for Android did not use encryption (SSL) for
information transmission during login, exposing usernames and
passwords to anyone monitoring the network. The vendor fixed this
issue and users should install the latest version (2.3.4 or above).
MITRE has assigned CVE-2017-11706 to track this issue.

DETAILS

Boozt Fashion / Boozt.com is a Nordic-based, EU-spanning online store
selling  various fashion brands. The vendor makes available an Android
application that allows users to shop, checkout and pay for their
orders.

While performing network level testing, we discovered that the calls
made by the application to the server during login did not use any
kind of encryption (SSL). This potentially exposed the usernames and
passwords of those using the app to a network-level attacker.
According to the vendor, financial information like credit card
numbers were not exposed since SSL was used during the checkout
process.

To replicate the issue on v2.0.2:

1. Install the application on the device (may be restricted to EU-only
users and require sideloading).
2. Open the application, tap on the “person” icon until you reach the
login screen.
3. Setup an MITM proxy but do not install the SSL certificate on the
device (we used PacketCapture).
4. Start the proxy. At this point all network traffic will be going
through the proxy with the SSL traffic being encrypted by a
self-signed certificate which is not trusted by the device.
5. Go back to the app, put in a fake username and password, and tap
the Login button.
6. Flick away the application.
7. Go back to the proxy and observe captured traffic.

All testing was done on Android 7 and application version 2.0.2.
Network captures were performed using an on-device proxy
(PacketCapture) without a trusted SSL certificate.

VENDOR RESPONSE

The issue was reported to the vendor via HackerOne. The vendor
provided the following comments:

------------------------
Thanks for the report. At the moment that is an accepted risk. We only
have https on the checkout part of the site (most sensitive). However
we have a planned change in the roadmap regarding HTTPS introduction
in the customer login part.
…
We are not arguing that the report is not valid. We just inform you
that based on our program guidelines this is considered as
non-qualifying report. This is because we are aware of the issue and
are already working on rolling HTTPS through out the site.
------------------------

Follow-up testing in July 2017 showed that this was fixed in current
version (2.3.4) but may have been fixed earlier as well.

REFERENCES

CVE ID: CVE-2017-11706
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11706

Google Play Link: Google Play Store (may not be available outside of Europe)
https://play.google.com/store/apps/details?id=com.boozt&hl=en

HackerOne Report # 166712
https://hackerone.com/reports/166712

BOUNTY INFORMATION

The vendor classified this bug as being outside the guidelines of
their bounty program and no bounty was paid.

CREDITS

Advisory written by Yakov Shafranovich.

TIMELINE

2016-09-07: Initial report to the vendor via HackerOne
2016-09-08: Report triaged by the vendor and closed via HackerOne
2016-09-08: Follow-up communication with the vendor via HackerOne
2016-09-18: Request for disclosure sent via HackerOne
2016-09-19: Follow-up communication with the vendor via HackerOne
2017-07-27: Public disclosure request granted via HackerOne
2017-07-27: Re-testing, CVE request and publication

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ