en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

June 2021 Security Roundup

Summer is here! For a lot of people, that has meant hot temperatures, swimming, and a much better summer than last year. For us at SSL.com, it means that it’s time to look back at June and see what transpired in digital security. Read on for what we’ve found, and let the knowledge guide you towards safe online experiences moving forward.

RockYou2021: Billions of Passwords Leaked Online

Well, it happened. The world’s largest collection of passwords has leaked, and all 8.4 billion of them were posted on a forum used by hackers. As Anthony Spadafora reports for techradar pro, the passwords were “likely combined from previous data leaks and breaches.” In typical forum post fashion, the hacker claimed the leak was ten times that amount—82 billion—but 8,459,060,239 unique passwords is bad enough. The article explains an unexpected social media connection to the MySpace era that gave the leak its title:

The forum user who posted the collection of passwords has dubbed the compilation ‘RockYou2021′ which is likely a reference to the RockYou data breach that occurred in 2009. At the time, cybercriminals hacked their way into the servers of the company that made widgets for users’ MySpace pages and were able to obtain more than 32m passwords stored in plain text.

The leak is more than double the previous largest data breach: “The Compilation of Many Breaches.” As the article notes, that is partially attributable to the fact that RockYou2021 includes all of the passwords from the Compilation of Many Breaches. In addition, it’s worth remembering that the number of passwords exceeds the number of people online, which is only 4.7 billion.

[su_note class=”info”]SSL.com’s Takeaway: If you needed a reminder, here it is: Change passwords often and don’t reuse them (using a password manager can make this easier). Use two-factor authentication whenever possible. In addition, it’s always a good idea to consider mutual TLS with client certificates as an alternative or addition to password authentication.[/su_note]

[su_divider]

Meat Producer Pays $11 Million to Ransomware Attackers

Ransomware attacks have been making headlines lately, and it’s easy to see why. In yet another incident that disrupted international business, JBS Foods—the world’s largest meat supplier—revealed it had paid $11 million to fix an incident that threatened its international operations. A statement from the company, reported by Simon Sharwood of The Register, explains they made the decision to pay up “(i)n consultation with internal IT professionals and third-party cybersecurity experts … to mitigate any unforeseen issues related to the attack and ensure no data was exfiltrated.” The article continues:

“An investigation of the incident is ongoing. JBS wrote that it’s unable to offer “final determinations” about the incident and described the FBI’s opinion that the perpetrators being “one of the most specialized and sophisticated cybercriminal groups in the world”.

Indeed, the FBI has released a statement that attributes the attack to a group that has been linked to the Colonial Pipeline attack.

[su_note class=”info”]SSL.com’s Takeaway: Ransomware costs companies worldwide billions of dollars every year, and paying these criminals is increasingly discouraged. Please read Preventing Ransomware with Digital Certificates for much more about these kinds of attacks and what you can do to prevent them.[/su_note]

[su_divider]

New York State Internal Code Repository Exposed

Oh boy. Tech Crunch’s Zach Whittaker reports that an internal code bank used by the New York State IT office was thrown open for the world to see. That’s bad news, as the repository contained “secret keys and passwords associated with state government systems.” SpiderSilk, a Dubai cybersecurity company, discovered the GitLab server, which was “acessible from the internet and configured so that anyone from outside the organization could create a user account and log in unimpeded” according to SpiderSilk’s chief security officer Mossab Hussein via TechCrunch.

After affirming that the server was open and accepting new user accounts, TechCrunch contacted the governor’s office, and the server went offline after it had apparently been up since at least March. Eventually, a spokesperson attributed the security breach to a vendor and denied that there was any data at risk.

[su_note class=”info”]SSL.com’s Takeaway: All organizations must be vigilant against exposing login credentials and other sensitive information online. We’ve mentioned this before in connection with last year’s SolarWinds attack, where plaintext FTP credentials were leaked in a public GitHub repo.[/su_note]

[su_divider]

ALPACA: New Study of Cross-Protocol Attacks on HTTPS

This one is a little complicated, but it’s important, so please bear with us. Essentially, a new study looks at the potential havoc a man-in-the-middle attacker could create by confusing a browser that is trying to connect to an HTTPS website and “tricking” it into connecting to a server running a different protocol, such as an FTP or email server. The researchers have dubbed this sort of application layer content confusion attack “ALPACA.” As Ars Technica reports in a piece by Dan Goodin,

Because the browser is communicating in HTTPS and the email or FTP server is using SMTP, FTPS, or another protocol, the possibility exists that things might go horribly wrong—a decrypted authentication cookie could be sent to the attacker, for instance, or an attacker could execute malicious code on the visiting machine…In a research paper published on Wednesday, Brinkmann and seven other researchers investigated the feasibility of using what they call cross-protocol attacks to bypass TLS protections. The technique involves an MitM attacker redirecting cross-origin HTTP requests to servers that communicate over SMTP, IMAP, POP3, or FTP, or another communication protocol.

The MitM adversary can’t decrypt the TLS traffic, but there are still other things the adversary can do. Forcing the target’s browser to connect to an email or FTP server instead of the intended webserver, for instance, might cause the browser to write an authentication cookie to the FTP server. Or it could enable cross-site scripting attacks that cause the browser to download and execute malicious JavaScript hosted on the FTP or email server.

The article notes that, overall, such an attack “is very situational and targets individual users,” making the risk to the general public not that high at the moment. However, as more services are protected with TLS, it could become a more widespread pattern, so the time to mitigate the threat is now. The ALPACA Attack study authors recommend the use of the Application Layer Protocol Negotiation (ALPN) and Server Name Indication (SNI) TLS extensions to mitigate the threat.

[su_note class=”info”]SSL.com’s Takeaway: As the study authors note, “for the ALPACA attack to succeed, many preconditions need to be fulfilled,” so admins probably don’t need to treat this as a middle-of-the-night emergency. However, we recommend reading the study to understand how such an attack might be carried out and who might be vulnerable.[/su_note]

 

[su_note class=”info”]Compare Email, Client, And Document signing certificates from SSL.com, starting at just $20.00 per year.

[su_button url=”https://www.stg.ssl.com/s-mime-client-and-document-signing-certificates/” target=”blank”]COMPARE CERTIFICATES[/su_button]

[/su_note]

Subscribe to SSL.com’s Newsletter

Don’t miss new articles and updates from SSL.com