Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

8/13/2019
12:20 PM
50%
50%

700K Guest Records Stolen in Choice Hotels Breach

Cybercriminals reportedly stole the information from an exposed MongoDB database on a third-party server.

Hotel franchisor Choice Hotels has confirmed a breach in which attackers stole 700,000 guest records from a publicly available MongoDB database without a password or any authentication.

The unsecured server, which the hotel chain says belonged to a third-party vendor, contained multiple databases holding more than 5.6 million records. Choice Hotels says most of this was "test data," including fields referring to reservation details, passwords, and payment cards. Most of the 700,000 compromised records were in a database of 2.4 million records labeled "privacy log" and located in the same MongoDB instance. Exposed consumer data included names, physical and email addresses, phone numbers, and consent statuses, Comparitech reports.

Security researcher Bob Diachenko found the database on July 2, shortly after it was indexed by search engine BinaryEdge, and worked with Comparitech to analyze it. A ransom note demanding 0.4 Bitcoin was already there, likely left by an automated script targeting publicly accessible MongoDB databases, he believes. Diachenko notified Choice Hotels following his discovery; the firm secured the database on July 2 and began an investigation on July 28.

Choice Hotels says it will not be collaborating with this vendor in the future, and it's taking a closer look at its vendor relationships to put additional controls in place. It also plans to implement a responsible disclosure program to learn of future security incidents.

Read more details here.

Dark Reading's Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
tdsan
50%
50%
tdsan,
User Rank: Ninja
8/13/2019 | 4:22:56 PM
Re: And the circle goes round and round .....
I am with you buddy, it seems the "SAGA" continues, it seems that companies and people are not familiar with the technology so they are just putting it out there without having a third-party vendor validate their design/implementation.

He also stated that it was a test environment to give Choice a new tool to test out new functionality. If that was the case, then why wasn't the system put in an enclosed network that does not allow Internet access and encrypt the data using AES2048 bit encryption, even if they got the data it would not be any good to them (of course if they happen to get the keys, then that is another story).

Choice Hotels Bitcoin Reply

I am like you, "come on people", and why did they use live data (700,000 records were real-data). Why wasn't the data created in an artificial scripted manner (per another article, they said 5.6 million records were artificial, so it looks like a marketing coverup but oh well, same story, different day)?

Time of Breach

Also, look at the timeline when Diachenko identified the issue:
  • June 30: The exposed database was first indexed by search engine BinaryEdge.
  • July 2: Security researcher Bob Diachenko discovered the database and immediately notified Choice Hotels about the exposure. It already contained the ransom note. Choice Hotels says it unintentionally filtered the email so that it was not read.
  • July 2: Database access was secured.
  • July 28: Diachenko sent a second notification and Choice Hotels began its investigation of the incident.

All I can say is wow.

T

 

 
REISEN1955
50%
50%
REISEN1955,
User Rank: Ninja
8/13/2019 | 1:07:31 PM
And the circle goes round and round .....
External individual discovered the breech - not internal staff.  No passwords - not locked down.  Oh and minimal exposure of data - exactly what most firms say.  Have we not heard this before and before?  Oh and discovered June  but not investigated until June 28????    
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
US Sets $5 Million Bounty For Russian Hacker Behind Zeus Banking Thefts
Jai Vijayan, Contributing Writer,  12/5/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19719
PUBLISHED: 2019-12-11
Tableau Server 10.3 through 2019.4 on Windows and Linux allows XSS via the embeddedAuthRedirect page.
CVE-2019-19720
PUBLISHED: 2019-12-11
Yabasic 2.86.1 has a heap-based buffer overflow in the yylex() function in flex.c via a crafted BASIC source file.
CVE-2019-19707
PUBLISHED: 2019-12-11
On Moxa EDS-G508E, EDS-G512E, and EDS-G516E devices (with firmware through 6.0), denial of service can occur via PROFINET DCE-RPC endpoint discovery packets.
CVE-2019-19708
PUBLISHED: 2019-12-11
The VisualEditor extension through 1.34 for MediaWiki allows XSS via pasted content containing an element with a data-ve-clipboard-key attribute.
CVE-2019-19709
PUBLISHED: 2019-12-11
MediaWiki through 1.33.1 allows attackers to bypass the Title_blacklist protection mechanism by starting with an arbitrary title, establishing a non-resolvable redirect for the associated page, and using redirect=1 in the action API when editing that page.