In early August, “Flash Gordon” (@s7nsins on Twitter) contacted me to say that he discovered a leak involving the House of Representatives. In light of all the talk about Russia trying to hack our elections, I decided that we probably should notify the House right away in case there was any kind of sensitive files exposed. At the very least, Flash had informed me that there were email addresses and passwords in the exposed intranet files, although the passwords were not in plain text, he reported. Ironically, perhaps, the exposed material contained more than 17,000 references to “security,” including cybersecurity attacks. Notifying the House of their leak was one of those misadventures in notification that I should probably write a book about one day. Calling the House switchboard and asking to speak to whomever was responsible for their cybersecurity resulted in me being bounced from extension to extension for the next hour or so. No one seemed to know what office I should be connected to. And in the middle of this frustrating weirdness, an intern, who shall go nameless, even said to me that the cybersecurity team already knew that the intranet was leaking and they were probably working on it. What?? Eventually I found someone who was willing to take a message. Within a few hours, I received a call back from someone who was actually involved in cybersecurity. He told me that I should have asked for the “Chief Administrative Officer of the House.” I told him that they needed to review with the switchboard how to direct or escalate calls, as I doubt most callers would know to ask for that chief administrative officer, and when people get bounced all over the effing place, they may give up and not notify the House of a leak. The person I spoke with agreed and said the feedback was helpful and that he had never heard that before. Well sure. He probably never heard it before because everyone else gave up before they ever got through to him. In any event, they locked down the leak and I decided not to report publicly on everything at the time. But then last week, yet another researcher (Lee Johnstone, @Cyber_War_News on Twitter) got in touch with me and told me that the House was leaking. This leak appeared to involve a different IP address and a backup directory. The files reportedly contained a number of usernames and passwords, although once again, the passwords were not plain text. And unlike the first leak, this had sql databases for several members of Congress: Rep Dave Joyce of Ohio, Rep. Billy Long of Missouri, and Rep. Richard Neal of Massachusetts. According to Johnstone: The three subdomains leaked by congress are joyce.house.gov, long.house.gov, neal.house.gov, then there is also configuration files for carter.house.gov. Configuration files within all subdomains file systems show that they are connecting to a shared database as the root user with a common password [actual password redacted by DataBreaches.net] and that this appears repeated for each installation of drupal being used. Somewhat curious as to what would happen when I called the House and asked for the Chief Administrative Officer of the House, I called the House switchboard. My request for the Chief Administrative Officer of the House was transferred to a recording identifying the extension as “First Call.” I duly left a detailed message my name/number, their IP address and port, and said that I would be reporting on it because this was the second time in a few months that researchers were finding and contacting me about leaks from the House – and the files contained usernames and passwords. I asked them to get back to me. I fully anticipate that if and when they do call me, there will be an attempt to minimize the importance of these leaks, so let me state clearly that yes, I realize that the material leaked may not be the most sensitive, although since I haven’t gone through it all, I can’t be sure of that. And it’s not like people might ever re-use their passwords, right? Oh wait… It’s now noon on Monday, and I received no call back yesterday or today. And as of my last check, the door is still wide open. So I’ve decided to report on this now and tweet it to members of Congress. Maybe their staff can get through to the right person to secure their data. Update 1:38 pm. One of my followers on Twitter has a contact in the Chief Administrative Office, it seems, and he alerted the contact, who said he’ll check into it. That would be nice. Update 5:14 pm. More than 24 hours after I called them, the data now appear to have been secured, although I’m not sure whether it would have been secured if not for a follower’s contact.
This story is going to be straight up, forward and simple. What not to do when a researcher like myself contacts you about a security incident. Every day all around the world researchers are being ignored by those who they attempt to help out. Recently another researcher discovered a open s3 bucket that belong to a company based in australia called sustainablecertification.com.au who gives out certifications for various fields including IT and operates in various different countrys across asia. The open data was discovered first by @random_robbie and then again by @s7nsins who alerted me to it. After checking the data it was discovered that thousands of certification details and payment details had been left in this unsecured s3 bucket and that anyone with the url could go and download any of the 34,000 or so files that are located on their bucket. Data includeds but is not limited to full certifcations, invoices, management & internal files, emails, email attachments, HCCAP reports/audits, audi service agreements. After digging around and finding contact for the CEO i attempted to contact them via email which after getting a reply left me without words on how stubborn some people truely are. The contact i put forward always has "who" i am, "what" i do, and "what" i am contacting them about, however it appears that the CEO of Sustainable Certification, Swami Nathan can not process this basic information and the only reply i ever got back from him was "who are you" In reply to this i re-sent most of my orginal email back to him stating who i was, to this day the s3 bucket is still open and swami has never contacted back. So to this day and at least for the passed couple of months all clients and persons who have taken any certifications or used other services that Sustainable Certification offers then you may of had some of your personal information left unsecured online by the company it self. some basic statistics from this Countrys: AU,IN,IR,KR,MY,SG,TR Total Files: 34,468 Total Folders: 139 Total Size: 13.3GB So in simple if a researcher contacts you, make a effort to speak to them properly, it could save your business image and even more by doing so.
Homeland Security has subpoenaed Twitter for the account information of an independent researcher who has been the source of a number of this site’s reports. Is this just another chapter in the war on independent researchers to try to chill speech? Or is there more to the story that we do not yet know? Zack Whittaker of ZDNet reports that Homeland Security served Twitter with a subpoena demanding the account information of the Twitter user known as @s7nsins (“Flash Gordon”). Flash has been a frequent source of information on leaks and exposed databases, and this site has reported on just some of the many leaks he has uncovered and shared with this site. His Twitter timeline is filled with examples of his many finds. Flash, who self-identifies as being in New Zealand, first revealed the export enforcement subpoena in a tweet last month, and provided this site with a copy: Just recieved a subpoena email from twitter today regarding my twitter account. Would be easier if they just talked to me in regards to what its about. You are obviously reading my tweets. — Flash Gordon (@s7nsins) June 14, 2018 The April 24 subpoena required Twitter to supply the following information: Subscriber’s screen name Subscriber address Subscriber’s telephone number or numbers, the e-mail address or addresses, account or login name or names, or any other information pertaining to the identity of the subscriber, including type and number of credit cards used for billing purposes, or any other identifying information. The types of services subscribed to or utilized by the subscriber and the lengths of such services This should include means of payment of any such account and associated IP logs for these accounts; member lists; and other IP logs including all ISS logs Any complaints that Twitter, Inc. may have received regarding this said account or any related screen names. This non-governmental explanation of export control may help readers understand the basis for DHS/ICE getting involved: What is an Export? When we think of exports, we typically envision the shipment of a physical item from the U.S. to another country. While this is one form of an export, another involves the export of information from a U.S. individual to a non-U.S. person, and such so-called “deemed exports” can take place completely within the United States. A “deemed export” is an export of controlled “technology” (typically, information necessary for the production, development, or use of an item) to a non-U.S. person. These exports are “deemed” to be exports to the home country of the individual to whom the information is released. While exports of information are commonplace at institutions all around the United States, some “deemed exports” require government authorization in the form of a deemed export license from the U.S. Department of Commerce, or a foreign national employment license issued as a DSP-5 License by the U.S. Department of State. If the technology shared with a non-U.S. person could not be physically exported as printed material to the home country of the non U.S. person, then generally a deemed export license must be obtained prior to sharing the technology with the non-U.S. person in the U.S., unless a license exception is available. But how would that apply to this situation? There is no U.S. individual here who is exporting information to a non-U.S. person, is there? In his report, Zack hypothesizes that the subpoena might be related to a leak involving ALERRT.org, an organization that provides training for active shooter responders. ZDNet recently reported on the leak that Flash had uncovered. But how likely is that leak to be responsible for an ICE subpoena? The ALERRT leak/exposure was discovered by @s7nsins in March and it was shared with DataBreaches.net immediately upon discovery. The data were hosted on a server in Texas and the ALERRT organization is headquartered in Texas. DataBreaches.net notified ALERRT.org via voicemail and email on March 24, and received an actual email acknowledgement and thanks that same date. DataBreaches.net did not publicly report on the incident, and did not indicate to ALERRT that this would be reported upon. Did ALERRT report the exposure to DHS? Wouldn’t they have reported to the FBI if they were going to report it at all? And wouldn’t the FBI have pursued it instead of DHS? How/why would ICE get involved at all? The only thing Flash had tweeted about his find was on March 26, and he didn’t even name the organization or include any screencaps: Some things i found over the weekend. Some health company leaking 300k+ phone calls , Some shooter response training site , mainly with law enforcement members with around 90k+ users, A university database with 28k users. Amazes me everyday the things that are publicly available. — Flash Gordon (@s7nsins) March 26, 2018 Something doesn’t make a lot of sense yet if the ALERRT incident is the explanation for the subpoena. And as Zack reports, one lawyer ZDNet consulted with found the whole situation a head-scratcher. Zack is a lot smarter than I am, and perhaps he is right in suggesting that there may be a link to the ALERRT incident, but there are so many leaks that Flash found and disclosed that it’s hard to be confident in any guess. But if this is about a researcher finding exposed data on servers and sharing his findings with U.S.-based journalists, then where is there any “export” that would justify the involvement of ICE? DataBreaches.net reached out to ALERRT.org and to ICE for a statement on Saturday, but has received no response from either as yet. Update July 3: After sending a second request, DataBreaches.net received a reply from Matthew Bourke of ICE’s Office of Public Affairs. Bourke wrote that “we are looking into this issue, but have no information to share at this time.” DataBreaches.net has not yet heard back from the individual at ALERRT who I had reached out to for follow-up.
Bill Cooke reports: With the help of self-professed “data and crypto addict” Flash Gordon, iAfrikan CEO Tefo Mohapi connected the leak to GoVault. GoVault is a platform operated by Dracore, and is billed as a “goldmine of information” which offers access to the contact details of South African consumers and homeowners. Read more on GearsofBiz. @s7nsins (aka “Flash Gordon”) had informed DataBreaches.net of this leak, and is not surprised to read how he helped others try to track down the source of the leak. He is one of a number of dedicated researchers who scour the net to see what can be viewed that shouldn’t be viewable.
Compiling data for Protenus, Inc.’s breach barometer should be relatively routine and straight-forward. In May, however, it wasn’t. Here’s a rundown on the factors that complicated our analyses: Investigating patient data put up for sale on the dark web. Determining whether the breaches were legitimate or fake turned out to be headache-inducing, as the following scenarios illustrate: A reliable source provided DataBreaches.net with data that appeared to be from Pain Consultants, PLLC in Washington State. According to the threat actor who provided the source with the data, there were 1200 records that included name, address, date of birth, telephone number, social security number, medical details, and health insurance information. This incident was included in our analyses even though the provider did not respond to inquiries sent by this site. A second listing, purportedly for the personal information of medical marijuana caregivers and patients, offered “thousands” of such credentials, but that vendor refused to provide this site with any samples that would permit us to attempt to verify their authenticity. As a result, we decided not to include these data in our analyses for the month, even though we could think of one recent breach they might have come from. A third listing, on yet a different dark web marketplace, offered a database with records that they claimed were from 70,000 Allscripts patients: DataBreaches.net was able to contact Allscripts, who investigated and subsequently informed this site: We are aware of this listing. We take the security of our data very seriously, and we’ve performed an investigation into this matter. Our conclusion is that this listing was posted by a ripper (an individual who commits fraud on underground forums), and that it is a fraudulent listing. Additionally, we consulted with law enforcement, who concurred with our conclusion. Thank you again for reaching out to us. As a result of their investigation and contact, the so-called “Allscript” data were deemed as “fake” and not included in our analyses. A fourth listing for a “MedicalDB Leaked Database | 2,000 records | 100% Original and Unmodified” was supposedly from a dump in October 2016. The vendor kindly provided DataBreaches.net with a sample of patient records. The patients all had Texas addresses, and dates of birth in 1937 and 1938. Their records included their name, address, telephone number, date of birth, Social Security number, and some other fields that were not clearly labeled. Although it seemed likely that these data were from a real patient database, it was unclear whether it might be a breach we had previously reported on/included, so it was not included in our analyses for the month. A fifth listing for 5,200 patients’ information was purportedly from “LifeMedical” in Minnesota. The incident was included in this month’s analyses, but because LifeMedical firmly denied that those are their patients’ data when DataBreaches.net contacted them, the incident is coded as “unknown entity.” But databases on the dark web were just one factor that took time to investigate. In addition: Three patient records databases were dumped by TheDarkOverlord. Two of the databases dumped by TheDarkOverlord in May – purportedly from Aesthetic Dentistry in NYC and OC Gastrocare – had been mentioned publicly in the past and were included in earlier Breach Barometer reports. The third data dump, from Tampa Bay Surgery Center, has been included in this month’s analyses even though they did not respond to an inquiry from this site. Of note: none of the three claimed breaches has appeared on HHS’s breach tool. Keeping up with leaking servers was a herculean task in May. Here are just some of the incidents/leaks DataBreaches.net investigated this month, although none are on HHS’s breach tool as of the time of this report: Bronx-Lebanon Hospital Center patient data leaked from a misconfigured backup server managed by iHealth Solutions. The leak was discovered by Kromtech Security. We really don’t have a solid estimate of how many patient records were in the 500 MB of data Kromtech initially downloaded from the leaking server, so have used the number offered by Kromtech. An untold number of files with medical information on workers compensation claimants was exposed due to a misconfiguration of a server that appeared to be owned by DocuCents. That leak was discovered by @s7nsins. Neither DocuCents nor its parent corporation responded to multiple notifications and inquiries sent by this site. The data were secured after DataBreaches.net contacted one of its clients, GEKLAW, and alerted them that their clients’ information was exposed. GEKLAW was only one of numerous firms that had client data left vulnerable or exposed. The incident has been reported to the California Attorney General’s Office by DataBreaches.net. An untold number of files with medical information of cancer patients was leaked by CureSeq. The leak was discovered by Kromtech Security, who was unable to get a response from the firm. On June 8, DataBreaches.net also sent notification to CureSeq with the subject line: URGENT: You are leaking patient/other data from your Rsync backup There was no response. DataBreaches.net contacted some of their clients, including the University of California San Francisco Dept. of Pathology and Stanford Medical Center Surgical Pathology. Contacts were attempted via email and telephone. None of the covered entities contacted responded to notifications. DataBreaches.net referred the CureSeq leak to the California Attorney General’s Office, and is considering filing a complaint about it with HHS. And if you needed even more messiness for the month…. For some incidents, we had no numbers. That’s not unusual, of course, but this month, there were a number of incidents that each may have had numbers in the hundreds of thousands or millions. Not having those numbers leaves us with what may be a truly significant underestimate of the number of breached records in May. In addition to the incident that we believe is linked to DocuCents, the True Health Diagnostics incident, the Molina Healthcare incident, and the OneLogin incident each could have exposed significant numbers of patient records. So how bad was May? Your guess is as good as mine at this point, but here’s the […]
I was excited back in 2010 when HHS started posting breaches on what some would call the “wall of shame.” I knew that we’d only learn about breaches involving HIPAA-covered entities, but at least we were finally starting to get some actual data. Now, more than 6 years later, it’s become clear to me that it’s probably best to just call time of death on the breach tool, despite its popularity with marketers who look for numbers to support their sales pitches. In this post, I review some of what we are not seeing on HHS’s breach tool, and why it’s really not a source of accurate or helpful information for those who want to understand breaches and incidents involving health or medical data. Have You Checked the Dark Web Recently? Last June, when TheDarkOverlord made headlines by advertising patient databases for sale at absurd prices, it was a bit of a wake-up call for me. I had never checked any dark web marketplaces for patient data that might be up for sale. Nowadays, I do, and I occasionally find evidence of breaches that have never appeared on HHS’s breach tool. But since I’ve already mentioned TheDarkOverlord, let’s start with him/them. Can you explain why none of three databases recently dumped had appeared on HHS’s breach tool, even though we knew about two of those claimed hacks last year? If you read this site or Protenus’s Breach Barometer, you knew about two of those three incidents last year when they were first disclosed by the hacker(s). But if you relied solely on HHS’s breach tool for your stats on hacking of patient data, you didn’t know about these incidents – and still don’t. In contrast, an incident involving Behavioral Health Center in Maine is on HHS’s breach tool, but probably only because I discovered it on the dark web and notified the covered entity, who, in turn, notified HHS. Here are some more dark web listings that still haven’t shown up – and may never show up – on the breach tool: A listing for pediatric patients’ information, which I’ve previously noted on this site. Although there have been one or two pediatrics offices reporting incidents, none have reported any that would quite correspond to what the vendor is claiming to possess. And then there’s this listing: Where did these data come from? Were these data from the Nevada incident reported by Justin Shafer – the one where the state said it had no indications of misuse of data and that private patient information was secure? The Nevada incident does not appear on HHS’s breach tool. Unfortunately, the dark web vendor would not provide me with a sample of the data, so I couldn’t confirm whether the data for sale were from Nevada, but there is no incident on HHS’s breach tool that appears to correspond to this listing. Then there was a dark web listing for 5,200 patients’ records from an incident in Minnesota that almost certainly should be on HHS’s breach tool – except that it’s not: The listing first appeared in a vetted forum with an asking price of $100.00. It was subsequently listed in a second forum with a $99.00 list price. The second listing identified the data as coming from a particular clinic in Minnesota: LifeMedical. DataBreaches.net was able to obtain all the data, but when I contacted LifeMedical in Minnesota and spoke to their outsourced tech firm, PriorityOne Technologies, they denied that the patient data was theirs. DataBreaches.net also contacted eClinicalWorks because there were references to them in the database. They were of no real help, however. Nor did the dark web vendor respond to a private message I sent them on the marketplace seeking further information. So we have data that can be partially verified by public sources such as Google searches or by calling the patients directly, but whose patient data were these? If no one has accepted responsibility/ownership of this database, no one has notified HHS and probably no one has notified or warned the 5,200 patients that their data was not only acquired by criminals, but was up for sale on the dark web in at least two marketplaces. And Oh, Those Third-Party Breaches Ok, what might happen if a service that handles documents with sensitive information relating to workers compensation cases has a misconfigured server (and no, I’m not talking about the Systema Software leak but a much more recent incident)? DataBreaches.net was so concerned by exposed reports that @s7nsins was finding and sharing with me that I called and sent messages to a law firm whose clients’ personal and medical information were among the numerous files that were exposed. To give you a sense of the scope of the problem, here’s just one file exposed on the server that has been redacted by DataBreaches.net. Note all the types of information that were included. Other files included financial information about settlements, W-9 information, radiological findings, and more. Now maybe some of these records could rightfully be considered public records if they’re evidence in litigation, but even courts generally require some redaction or sealing of sensitive information, don’t they? So how many hundreds – or thousands – or millions – of individuals may have had their personal and medical information exposed accidentally by this vendor and you wouldn’t have even known about it except for the fact a researcher contacted me and I just mentioned something here? How many curious researchers – or worse, criminals – may have downloaded all the data? Yes, DataBreaches.net will be following up on this one, but cannot tell you whether you will ever see it on HHS’s breach tool. No, I’m Not Done. Not By a Long Shot. When you think about massive exposed databases or servers like the one mentioned above, it should serve as a sobering reminder that we are only hearing about a fraction of compromised records if our only source of data is HHS’s breach tool. So what about all the misconfigured MongoDB installations that exposed patient information or health data? And what about the misconfigured rsync backup installations that exposed patient data? How many of the misconfigured MongoDB incidents or misconfigured rsync incidents have you seen reported on HHS’s public breach tool? Only a handful at the most, probably, because the data are often owned by entities that are not covered by or subject to HIPAA. In other cases, you may not hear about it because researchers contact me and […]