Almost 8,000 business owners who applied for a loan from the Small Business Administration may have had their personal information exposed to other applicants, the SBA admitted on Tuesday.
The breach relates to a long-standing SBA program called Economic Injury Disaster Loans (EIDL). It has traditionally been used to aid owners whose businesses are disrupted by hurricanes, tornadoes, or other disasters. It was recently expanded by Congress in the $2.2 trillion CARES Act. In addition to loans, the law authorized grants of up to $10,000 that don’t need to be paid back.
The EIDL program is separate from the larger Paycheck Protection Program that was also part of the CARES Act. The SBA says that PPP applicants were not affected by the breach.
A Trump administration official described the problem to CNBC:
The official said that in order to access other business owners’ information, small business applicants must have been in the loan application portal. If the user attempted to hit the page back button, he or she may have seen information that belonged to another business owner, not their own.
The SBA says it discovered the flaw on March 25 and notified affected users. One victim posted a copy last Friday of a paper letter she received about the breach. The letter stated that personally identifiable information—including Social Security numbers, addresses, dates of birth, and financial data—may have been exposed. The letter said that, as of last week, there was no sign yet of the data being misused.
The SBA says that it immediately disabled the portion of its website that was exposing applicant data, fixed the problem, and re-launched the website. Affected businesses have been offered a year of free credit monitoring.
The SBA has struggled to deal with demand for EIDL loans. Before the coronavirus crisis, small businesses were supposed to be eligible for up to $2 million in disaster loans.
But with millions of firms seeking assistance, the SBA was forced to limit the loans to as little as $10,000. Despite the limits, the SBA website currently states that it is not accepting new applications due to a lack of funds.
As of April 19, SBA had approved almost 27,000 EIDL loans valued at $5.6 billion. Another 755,000 businesses received EIDL grants worth a total of $3.3 billion. The Trump administration official told CNBC that 4 million business owners had applied for assistance worth $383 billion—far more than the $17 billion allocated for the program.
The PPP has also seen overwhelming demand, with funding running out in a matter of days. A legislative compromise announced on Tuesday could replenish both programs, with the PPP getting another $320 billion and the EIDL getting $60 billion.
Finastra, a company that provides a range of technology solutions to banks worldwide, said today it was shutting down key systems in response to a security breach discovered this morning. The company’s public statement and notice to customers does not mention the cause of the outage, but their response so far is straight out of the playbook for dealing with ransomware attacks.
London-based Finastra has offices in 42 countries and reported more than $2 billion in revenues last year. The company employs more than 10,000 people and has over 9,000 customers across 130 countries — including nearly all of the top 50 banks globally.
Earlier today, sources at two different U.S. financial institutions forwarded a notice they received from Finastra saying the outage was expected to disrupt certain services, particularly for clients in North America.
“We wish to inform our valued customers that we are investigating a potential security breach. At 3:00 a.m. EST on March 20, 2020, we were alerted to anomalous activity on our network which risked the integrity of our data-centers,” reads the notice. “As such, and to protect our customers, we have taken quick and strict remedial action to contain and isolate the incident, while we investigate further.”
Update, 5:21 p.m. ET: Finastra has acknowledged that it is battling ransomware.
“At this time, we strongly believe that the incident was the result of a ransomware attack and do not have any evidence that customer or employee data was accessed or exfiltrated, nor do we believe our clients’ networks were impacted,” the company said in a revised statement.
The statement continues:
“Our approach has been to temporarily disconnect from the internet the affected servers, both in the USA and elsewhere, while we work closely with our cybersecurity experts to inspect and ensure the integrity of each server in turn. Using this ‘isolation, investigation and containment’ approach will allow us to bring the servers back online as quickly as possible, with minimum disruption to service, however we are anticipating some disruption to certain services, particularly in North America, whilst we undertake this task. Our priority is ensuring the integrity of the servers before we bring them back online and protecting our customers and their data at this time.”
Finastra also acknowledged an incident via a notice on its Web site that offers somewhat less information and refers to the incident merely as the detection of anomalous activity.
“The Finastra risk and security services team has detected anomalous activity on our systems,” wrote Tom Kilroy, Finastra’s chief operating officer. “In order to safeguard our customers and employees, we have made the decision to take a number of our servers offline while we investigate. This, of course, has an impact on some of our customers and we are in touch directly with those who may be affected.”
Once considered by many to be isolated extortion attacks, ransomware infestations have become de facto data breaches for victim companies. That’s because some of the more active ransomware gangs have taken to downloading reams of data from targets before launching the ransomware inside their systems. Some or all of this data is then published on victim-shaming sites set up by the ransomware gangs as a way to strongarm victim companies into paying up.
One reader on Twitter told KrebsOnSecurity they’d heard Finastra had sent thousands of employees home today as a result of the security breach. Finastra told this author the company closed select offices in Canada and Paddington, London today where employees were unable to access the servers which they took offline.
“The majority of the Company’s employees are already working from home,” a statement shared by Finastra reads. “This is determined by Finastra’s response to COVID-19 and not related in any way to this incident.”
Interestingly, several ransomware gangs have apparently stated that they are observing a kind of moratorium on attacking hospitals and other healthcare centers while the COVID-19/Coronavirus epidemic rages on. Bleeping Computer’s Lawrence Abrams said he recently reached out to the operators of the Maze, DoppelPaymer, Ryuk, Sodinokibi/REvil, PwndLocker, and Ako Ransomware infections to ask if they would continue targeting health and medical organizations during the outbreak.
Abrams said several of those gangs told him they would indeed stop attacking healthcare providers for the time being. One gang even used its victim-shaming Web site to post a “press release” on Mar. 18 stated that “due to situation with incoming global economy crisis and virus pandemic” it would be offering discounts to victims of their ransomware.
“We also stop all activity versus all kinds of medical organizations until the stabilization of the situation with virus,” reads the release from the Maze ransomware gang.
This story will be updated as more details become available.
As a leading vulnerability reporting platform, HackerOne has paid hackers more than $23 million on behalf of more than 100 customers, including Twitter, Slack, and the US Pentagon. The company’s position also gives it access to unimaginable amounts of sensitive data. Now, the company has paid a $20,000 bounty out of its own pocket after accidentally giving an outside hacker the ability to read and modify some customer bug reports.
The outsider—a HackerOne community member who had a proven track record of finding and privately reporting vulnerabilities through the platform—had been communicating late last month with one of the company’s security analysts. In one message, the HackerOne analyst sent the community member parts of a cURL command that mistakenly included a valid session cookie that gave anyone with possession of it the ability to read and partially modify data the analyst had access to.
“HackerOneStaff Access,” the community member haxta4ok00 wrote in broken English on November 24. “i can read all reports @security and more program.” In a follow-up message, haxta4ok00 wrote: “i found what is you can edit private program (for test) I have not changed anything and not used , all for the sake of hacking.” On the same day, the hacker followed up again, writing: “If you need Proof, I can write a message [redacted].”
HackerOne revoked the session cookie at 7:11am Pacific time, exactly two hours and three minutes after haxta4ok00 reported the breach. The company’s incident response team then set out to investigate what happened and how much damage had been done.
HackerOne isn’t saying precisely how much data was exposed. An incident report the company published on Tuesday said that all affected customers have already been privately notified. Tuesday’s report also said that the data was limited to reports the security analyst had access to, but the disclosure doesn’t provide even a rough estimate of how many customers or how much data were affected. The report and an accompanying transcript of HackerOne’s communications with haxta4ok00, however, suggest that the exposure was non-trivial.
“Something came up that we hadn’t asked you yet,” HackerOne cofounder Jobert Abma wrote to the hacker a day after the incident. “We didn’t find it necessary for you to have opened all the reports and pages in order to validate you had access to the account. Would you mind explaining why you did so to us?”
The community member said he did it to “show the impact” and that he didn’t intend any harm and reported the access immediately. “I was not sure that after the token substitution I would own all the rights,” he wrote. In a later message, haxta4ok00 went on to write:
- Three years ago I mentioned such an attack, but it was theoretical and I was not listened to( here [report] #163381 I wrote in theory find this in the future). If this will help the I am systemic moderator on one of forums on security. And we protected ourselves from such attacks by binding the session to the IP address at the entrance. We also made basic authorization for access to private sections. Perhaps this will help you.
- I understand, that saw data which should not was see, but this was only hack interest in white purposes, I wanted to watch and show you to prejudice consequence of this can lead ( I’ve always been taught to write the full impact that can be) . It was a happy white hacking for me.
- Please do not scold █████ he’s one of the best staff that help to hackerone
And sorry if I that the poorly translated, hope you me will understand. Thanks @jobert again.
Abma replied that “this became a bigger incident due to the amount of data that you accessed, not because it happened in the first place.”
Also telling is another message Abma sent. It read:
Due to the nature of the data that could’ve been accessed, systems other than hackerone.com may be accessible. Scope includes any customer assets because of the vulnerability information that could have been accessed.
The transcript and report also suggest that the breach gave the outsider other potentially more serious abilities, including paying bounties, modifying program details, adding users, and suspending customer submissions. Haxta4ok00 assured HackerOne the hacker limited the access to “read only.” In an email, HackerOne Director of Security Reed Loden said network logs also showed no changes were attempted.
The hacker also assured HackerOne that all screenshots, exports, proxy logs, browser history, and other data captured during the unauthorized access has been deleted, although the hacker admitted there was no way to prove this.
Loden denied as “incorrect” the claim made at the outset of the report, that haxta4ok00 could “read all reports @security and more program.” Loden wrote:
The hacker could access for a short time a limited subset of vulnerability reports for customer programs permitted by the session cookie. The majority of the affected reports only had their title and limited metadata viewable. Once a report is submitted, the original description cannot be altered, and we confirmed via logs that no changes to reports were attempted. This was also confirmed by the hacker.
He declined to say in megabytes or gigabytes how much data was accessed by haxta4ok00 or how many customers were affected other than to say the breach “impacted less than 5% of programs.”
Loden also said that the attack haxta4ok00 reported three years ago was a “purely theoretical scenario focused on older browsers that were not, and are still not, supported by the HackerOne Platform.” Loden said that the sharing of session cookies with community members was not previously reported.
The report went on to detail the steps HackerOne has taken to prevent similar breaches in the future. As haxta4ok00 suggested, one step was to bind authentication cookies to the IP address of the user it was issued to. The move prevents the cookies from being reused by outsiders.
Tuesday’s report said: “The change was rolled out for HackerOne employees (including all HackerOne Security Analysts) on November 25, 2019.” A message Abma sent haxta4ok00 on November 26, however, stated: “We’re postponing the rollout to all users due to people having legitimate use cases for using multiple IP addresses (e.g. ISPs with DHCP).”
Other short-term measures include blocking access from specific countries and moving from notifications over Slack to paging an on-call security person when critical reports are submitted. The company has also implemented controls that automatically detect and redact session cookies and other sensitive data submitted in comments. Other preventative measures HackerOne plans to put into place include adding new logging of information around data access, binding sessions to specific devices, improving employee education, and overhauling the security analyst permission model.
There’s no indication that any of the data exposed in the breach was modified, stored, or passed on to parties besides haxta4ok00. Still, the event shows the risks companies take when trusting an outside party with some of their most sensitive business secrets. Katie Moussouris, HackerOne’s chief policy officer from 2014 to 2016, told me that she left the company as it began a pilot program that she had spearheaded for the Department of Defense. Dubbed Hack the Pentagon, it wasn’t just the first federal bug bounty program. It was also HackerOne’s first foray into vulnerability triage on behalf of a customer.
Now the CEO and founder of Luta security, a vulnerability consultancy that worked with HackerOne on the Hack the Pentagon program, Moussouris said of HackerOne:
They had never attempted triage for any customers before the Pentagon. I warned them that triage labor that we could trust would be incredibly hard to find. And that the platform as designed would need much stricter granular controls on the back end, to restrict access per program, especially if contractors would be used to do triage.
I advise my customers not to outsource triage for vulnerability disclosure or bug bounty programs that are targeted towards sensitive systems, since contractors are often the ones doing triage on these managed bug bounty platforms. [Customers] should also fix these bugs as quickly as possible, since an insider threat from the bug bounty platforms, or an outside attacker that gains access, would potentially see a treasure trove of unpatched vulnerabilities stored in these systems.
I feel like all the things I’ve been warning about on the risks of current bug bounty platform implementations over the past couple of years are in this report.
For HackerOne’s part, Loden said that the resolution and detailed disclosure of the unauthorized access—a practice he said is standard for every security event affecting the company—is proof of HackerOne’s commitment to protecting its customers’ secrets.
“Security incidents will always exist, and the way a company responds can be more telling than the vulnerability itself,” he wrote. “We aim to show the community and our customers through our actions the steps we are actively taking to enhance our security.”
months after DiBella’s Old Fashioned Submarines was notified by the FBI and
credit card companies of a data breach the sandwich shop chain has issued a
notice informing its customers of the incident.
reported its stores in Connecticut, Indiana, Michigan, Ohio, New York and
Pennsylvania may have had the information on as many as 305,000 payment cards
compromised. DiBella’s said it was informed by the FBI and its credit card
firms on August 27, 2018 of the data breach and that Fin7 were the likely
actors behind the attack gaining access to the company’s payment card data and
of the locations were victimized between March 22, 2018 and December 28, 2018
with its Cranberry, Penn. store possibly being hit as early as September 2017.
The customer data involved included individual names, payment card numbers,
expiration dates, and CVV numbers, DiBella’s
has not yet returned an SC Media inquiry into why the company waited until now
to disclose the issue.
does not know which individuals were impacted and said it has not received any
customer complaints about their payment cards being misused. But it is warning
anyone who visited the locations in questions to
aka the Carbanak gang, were caught by law enforcement starting in January and
June of 2018. In August 2018 the U.S. Department of Justice made public arrests
of the three Ukrainian men who allegedly were key players in the cyber gang. However,
the arrests did not stop other members of the gang from continuing their activities.
notice said the malware found on the company’s system ties the attack to Fin7.
The post Fin7 behind DiBella’s data breach affecting 305,000 cards appeared first on SC Media.
The Catch Hospitality Group is notifying customers of its New York City restaurants of a POS malware incident that may have compromised their payment cards.
Catch NYC (including Catch Roof) and Catch Steak had payment card skimming malware injected into the POS systems in use at the restaurant bars that searched for track data which could include cardholder’s names, card number, expiration date and internal verification code. The mobile POS devices the wait staff uses at the tables were not affected as these use point-to-point encryption to communicate with the corporate payment network, Catch reported.
The issue at
Catch NYC (including Catch Roof) lasted from March 19, 2019 through October 17,
2019 and at Catch Steak from September 17, 2019 through October 17, 2019.
security firm has removed the malware, which was not named, and enacted additional
Catch did not reveal when the malware was discovered.
The post Catch NYC, Catch Steak hit with payment card skimming malware appeared first on SC Media.