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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-Id: <201510081357.t98DvJA5006188@sf01web1.securityfocus.com>
Date: Thu, 8 Oct 2015 13:57:19 GMT
From: securityresearch@...ftek.biz
To: bugtraq@...urityfocus.com
Subject: Potential vulnerabilites in PayPal Beacons

Original at:
http://securityresearch.shaftek.biz/2015/10/potential-vulnerabilites-in-paypal-beacons.html

Overview
Hardware beacons made by PayPal have some potential vulnerabilities. However, because we have been unable to obtain a physical beacon for testing, these remain theoretical.

Background
Paypal offers a hardware Bluetooth LE device called "Paypal Beacon" that communicates with the PayPal apps running on users' devices to support things like sending deals and coupons when customers visit stores.

Card.io, one of PayPal subsidiary companies operates several servers which provide firmware and firmware updates for these beacons. These are indexed in search engines and include the following URLs:

http://beaconlog.card.io/
http://beaconpkg.card.io/

Details

Our analysis of the firmware packages made available at the firmware server points to some potential vulnerabilities. However, because we lack access to a physical beacon for testing, these remain theoretical and unconfirmed.

Issue #1 - firmware update process is using HTTP, and not HTTPS

The firmware update script is located here:

http://beaconpkg.card.io/images/reberry.sh

The script is using HTTP, and not HTTPS to download firmware images. With DNS or domain spoofing, it would be possible to have malicious hardware being downloaded and replaced on the beacons. Excerpt as follows:
fi                                                       
                              
wget http://beaconlog.card.io/images${IMAGES_TYPE}/ppbeacon-latest.zip
if [ $? != 0 ]; then
  abort "cannot download image, exiting"
fi
However, it is unclear whether this script is used for development purposes only or for production.

Issue #2 - firmware update process did not verify signatures

The firmware update script is located here:

http://beaconpkg.card.io/images/reberry.sh

The analysis of the script shows that it does not verify signatures of the download firmware images, resulting in a possibility of malicious firmware being installed on the beacons. HOWEVER, it is unclear whether this is actually used in production.

Furthermore, the same servers provide two directories with encrypted and digitally signed images that are used for releases later than r129. Those potentially mitigate this issue. The directories are located here:

http://beaconpkg.card.io/ppbeacon-packages/dists/testing/main/binary-armel/
http://beaconpkg.card.io/ppbeacon-packages/dists/stable/main/binary-armel/


Issue #3 - root password for the firmware available publicly

A collection of scripts is accessible publicly in the following files (previous versions are not effected):

http://beaconpkg.card.io/images-develop/scripts-1.18.tar.gz
http://beaconpkg.card.io/images-develop/scripts-1.19.tar.gz
http://beaconpkg.card.io/images-develop/scripts-1.21.tar.gz

Within those files, a script named "led_pass.sh" contains what appears to be the root password for the Linux distribution running the beacon hardware as follows (we blanked out the password):

#!/bin/sh
#
# Shell script is triggered by the test script when all the tests pass
# It is continuos loop with LED colors changing from white, red, green, blue, yellow and purple after each
# second
#

# Password to SSH into beacon
PASSWORD='XXXXXXXXXX'

#LED TESTS
However, it is unclear whether the same password is used in release versions of the beacon or this is for development purposes only.

Vendor Response
The following response was received from the vendor: 
We have reviewed your vulnerability submission, However, it seems that the real world risk associated with this product and the submission is not significant to Paypal or our customers. As we have determined this is not actionable you may publish your findings.

References
PayPal Tracking ID: EIBBP-32271


Timeline
2015-08-10: Vendor notified
2015-08-10: Initial vendor response
2015-08-24: Vendor triage completed
2015-09-09: Vendor response received
2015-10-07: Public disclosure

Version Information
Version 1
Last updated on 2015-09-20

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ