Home Blog Page 195

Hackers Hide Phishing Links Inside .ics Calendar Invitations

Phishing Campaign on FINRA

Threat actors are finding innovative methods to phish people into clicking/downloading malicious links or entering sensitive information on fake forms. In a recent security discovery, the Cofense Phishing Defense Center (PDC) found that cybercriminals are using calendar invitations to launch phishing attacks.

Researchers at Cofense found a new phishing campaign to target enterprise email environments that deliver .ics calendar invitations, which contain phishing links in the email body with the subject “Fault Detection from Message Center,” from a sender named “Walker”.  The hackers used a compromised email account of a school district to bypass email filters.

The Phishing Page

The fake calendar invitation contains a malicious URL, hosted on Microsoft’s SharePoint site, and also displays another link that redirects the user to a phishing site. When a user clicks on the calendar invitation, it redirects them to a document hosted on the SharePoint site, which contains yet another malicious link. In case the victim clicks on the second link, they are redirected to a phishing website hosted by Google that looks like a legitimate Wells Fargo banking login page. The bogus page asks the users to enter their sensitive information like login details, account numbers, PIN, and email credentials. After entering all the sensitive information, the user will be redirected to the actual Wells Fargo login page to make the user believe that their account is secured.

“Cofense observed the use of several compromised accounts used to send this campaign. Using a compromised real account originating from Office 365 allows the email to bypass email filters that rely on DKIM/SPF. The story in this phish is a version of a classic lure “suspicious activity on the user’s bank account.” This attachment, however, does not jibe with the ruse considering it’s a calendar invite. A more fitting lure would have been something like “I attached a meeting invite; can you please attend,” the researchers said in a statement.

Google Calendar Scam

Threat intelligence and cybersecurity firm Kaspersky stated that scammers made phishing attacks, by abusing Google Calendar services, to trick users into giving away sensitive information like passwords, card details, and other financial data.  Several unsolicited pop-up calendar notifications were sent to Gmail users by cybercriminals as a sophisticated spam email attack. The calendar phishing emails exploit the automatic addition and notification of calendar invitations feature for people using Gmail on their mobiles.

 

Telehealth Privacy and Security

The Coronavirus pandemic has catalyzed a rapid increase of telehealth adoption. Leveraging telehealth platforms, patients are able to speak with doctors and nurses without having to risk exposure to themselves or others.

By Ian Terry, Information Security Consultant at Intraprise Health

The increase has been so drastic, the U.S. Department of Health and Human Services and its Office of Civil Rights (OCR) and the FBI have released special guidance related to the use of telehealth systems, particularly how they have come under attack by malicious actors and advanced persistent threats (APT).

For privacy and security practitioners in healthcare, the increased use of telehealth and government attention signals the need to learn more about telehealth systems, the security risks associated with their use and strategies for mitigating those risks.

Telehealth and Protected Health Information

Telehealth is the use of systems and services to provide health care diagnoses and to connect providers to patients remotely. Often, patients will use applications on their device to connect via videoconference with doctors.

Similar to a conventional provider environment like a hospital or urgent care office, patients must relay information like their birthdate, age and medical history as well as their current symptoms during a telehealth session. The doctor can then prescribe medicine or treatment based on this virtual visit. All of this information is considered protected health information (PHI), which means it must be protected according to HIPAA requirements.

Companies that use or develop telehealth software must ensure their telehealth solution is adequately vetted, configured and used in such a way that demonstrates HIPAA compliance and protects the privacy and security of patients’ PHI.

Security Risks – New “Friends” and Familiar Faces

Telehealth relies on many of the products and technologies with which we are already familiar in both professional and consumer settings. As such, they are prone to many of the same vulnerabilities and risks.

Attackers can intercept data transmitted between the patient and provider during telehealth sessions if encryption and authentication protocols are not properly utilized. Or they could hijack a legitimate user’s credentials and impersonate them during a session, adding an additional layer of complexity to identity theft. In this situation, the victim’s healthcare records could be inaccurately modified – potentially affecting their care for years to come until the illegitimate modifications are rectified.

These types of attacks occur in real time. But attackers can also exploit telehealth environments to obtain patient data-at-rest. In some instances, recordings, notes and patient data collected or created during sessions could be saved to servers or smart phones. If these devices are not adequately encrypted, they could be the targets of a successful data exfiltration attempt.

The introduction of telehealth solutions into providers’ service offerings can speed and improve the provision of healthcare to their patients but can also broaden their attack surface. Organizations should be prepared to expand their security program to compensate, accounting for risks to confidentiality, integrity and availability (CIA) of patient information before they suffer a costly and damaging data breach.

Tele-Help Me Out – What Can We Do?

Providers or business associates looking to use telehealth solutions or ensure existing solutions are secure, should consider the following:

Perform a Security Risk Assessment of the Telehealth Solution and Its Vendor

Commonly referred to as a third-party risk assessment, this type of assessment is performed by the organization to evaluate the security posture of a vendor as well as the controls implemented in their product or service.

For telehealth solutions, assessors should examine prospective telehealth solutions’ documentation and collaborate with vendors’ technical specialists to compare the solution’s technical security controls with organizational standards.

Further, organizations should solicit information related to the vendor’s own cybersecurity/information security program – especially if they are storing or transmitting any patient data (e.g. if they are a SaaS solution). This involves reviewing their policy and process documentation to ensure they have a HIPAA-compliant program in place.

Request or Perform an Application Penetration Test

Providers should request any application penetration testing results or findings associated with the telehealth product from the vendor. Because penetration testing simulates real-world attacker scenarios, they are one of the most effective ways for evaluating the security of a program.

Reviewing and discussing ‘pen’ test activities with prospective telehealth vendors provides insight specific to the application as well as a demonstration of a vendor’s respect for cybersecurity – if a vendor doesn’t perform in-depth penetration testing of their telehealth product, it may be worth looking elsewhere for a partnership where security is mutually valued.

Improve Your Telehealth Policies, Procedures, and Training Materials

Like any technology used by your workforce, data security is highly dependent on how it is used. It is important that your workforce is following processes and policies that are tailored to the unique risks associated with telehealth platforms.

Leveraging policy can ensure your company has the authority to enforce standards of behavior when using telehealth platforms. Process and procedure documentation arms your workforce with step-by-step instructions on how to perform their duties appropriately.

Additionally, education and training on the appropriate use of telehealth platforms — particularly training on HIPAA privacy and security best practices — should be given to workforce members who use it. For example, reminding doctors to destroy any handwritten notes and ensure that telehealth sessions take place away from bystanders to avoid an incidental disclosure scenario.

OCR Enforcement Discretion – This Means We Don’t Have to Worry, Right?

(OCR) announced that it would not impose penalties for noncompliance with regulatory requirements under HIPAA rules against care providers employing telehealth during the COVID-19 public health emergency.

For providers, this means they can temporarily get away with HIPAA noncompliance when implementing and using telehealth systems “in good faith” to serve patients, reduce potential exposure to COVID-19 and handle the abrupt increase in volume.

Additionally, this allows covered health care providers to use popular applications that allow for video chats such as Apple FaceTime and Zoom to provide telehealth services.

This relaxation of enforcement allows providers to quickly pivot towards telehealth integration. Providers should be aware, however, that this does not altogether absolve their responsibility to privacy and security when using telehealth systems – at least, not in the long term.

Though the Notification of Enforcement Discretion does not have an expiration date, OCR has stated they will issue a notice to the public when it is no longer exercising the enforcement discretion. When that day comes, transitioning will be easier for providers that did their due diligence ahead of time – assessing risk, establishing Business Associate Agreements (BAAs) and Data Exchange Agreements, and ensuring their policy and process documentation speaks accurately to their use of telehealth platforms.

Conclusion

Telehealth is a revolutionary technology that has enabled providers and patients to enjoy the benefits of remote health services – benefits that are demonstrating their value during a critical situation.

Providers should be aware of the risks posed by the use of telehealth systems, and developers of these systems should prepare themselves to be on the receiving end of security inquiries and risk assessments. Despite OCR’s enforcement discretion, providers adopting telehealth solutions should not leave security and privacy by the wayside.

About the Author

Ian TerryIan Terry, SSCP, HCISPP, is an information security consultant at Intraprise Health, a cybersecurity firm that works with healthcare organizations to secure their healthcare data.

 

 

Disclaimer

CISO MAG did not evaluate/test the products mentioned in this article, nor does it endorse any of the claims made by the writer. The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same. CISO MAG does not guarantee the satisfactory performance of the products mentioned in this article.

Data Breach Affects Millions of Dating App User Records

Dating Apps

Security researchers from cybersecurity firm Wizcase discovered misconfigured databases leaking millions of records belonging to five dating service providers in the U.S. and East Asia. Wizcase stated that the leaky databases were hosted on the Elasticsearch, MongoDB, and AWS bucket servers that are made available online without password protection.

Breaches Found

A 17MB database of the U.S.-based dating service CatholicSingles.com exposed 50,000 user records including names, contact details, email addresses, billing addresses, age, gender, occupation, and education details. Another U.S.-based dating site Yestiki exposed 43,000 records (352MB) that contained users’ names, contact details, addresses, GPS location data, user ratings, and activity logs.

The South Korean dating app SPYKX.com leaked over 37,000 users’ records (600MB) via an unprotected Elasticsearch server. The exposed data included emails, phone numbers, cleartext passwords, dates of birth, gender, education, and location data. Japan-based dating apps Charincharin.net and kyuun-kyuun.com owned by the same company exposed 102 million user profiles including users’ mobile device details, email addresses, and search preferences.

One more U.S.-based dating app Blurry leaked around 77,000 users’ private messages (3667MB), including social media and contact details.

In addition, WizCase’s security team discovered six more unsecured servers that contain information from different dating apps and sites. However, the researchers stated that the owners of the servers  are yet to be found. “This information could have been collected through a process known as web scraping, but this could only explain some of the data, as parts of it do not appear to be from internet-facing web pages,” the researchers said.

Security Incidents from Dating Apps

Dating apps have been a prime target of hackers. A research by Kaspersky Lab revealed that dating apps transmit unencrypted user data over insecure HTTP protocol risking user data exposure. According to the researchers, the reason for the vulnerability was  because the applications  used third-party ready-to-go advertising Software Development Kits (SDKs), popular among advertising networks. Attackers also used dating apps to infiltrate smartphones used by military personnel. Earlier, hackers honey-trapped the U.K.’s Royal Air Force (RAF) personnel by hijacking an RAF airwoman’s Tinder profile. They also reached out to another RAF serviceman to get details of the F-35 stealth fighter from him.

 

DXC’s Xchanging Subsidiary Falls Prey to Ransomware Attack

ransomware, ryuk ransomware, cox media

Xchanging, DXC Technology’s subsidiary and an Australian based IT services provider rendering services to insurance companies, reportedly experienced a ransomware attack. According to its website, Xchanging is primarily insurance managed services provider operating as a separate entity and thus, the ransomware attack did not affect any of DXCs mainframe systems and networks.

The main concern arises from the fact that DXC technology provides services across various industry verticals. It serves nearly 6,000 private and public sector customers across 70 countries and add to this, the DXC Partner Network including industry cloud experts like Amazon Web Services (AWS), Google Cloud, Microsoft, PwC, and many others. Thus, a security failure in their mainframe could potentially affect all these stakeholders associated with the company. However, Xchanging is confident that the incident solely remained isolated to their environment alone. In addition, DXC  did not indicate that data has been compromised or lost.

DXC itself has now taken all necessary steps to remediate the damages caused by the ransomware attack and hopes to resolve and restore all its affected services at the earliest. Additionally, it has also informed the required law enforcement agencies and cyber regulatory body about the incident, who are now working in tandem with them to speed up the investigation process.

Talking About Ransomware…

Have you heard about the Thanos ransomware? The rising popularity of this family of ransomware is associated with the fact that it is being advertised in the underground forums as Ransomware-as-a-service (RaaS) tool that exploits the RIPlace technique in the Windows file system This technique goes undetected in most antivirus, anti-ransomware, and Endpoint Detection and Response (EDR) solutions as it bypasses the security products by replacing all sensitive files on the victim’s machine.

It has been reportedly developed by a threat actor named as “Nosophoros”. However, a lot has changed since its initial emergence and now the latest feature of RIPlace technique has been integrated and used since February.

Read more about this ransomware family in the article “Snap Your Fingers Twice, Thanos Ransomware is Here!”

 

NSA Issues Guidelines on Securing Virtual Private Networks

NSA security advisory

The U.S. National Security Agency (NSA) issued a set of guidelines on securing IPsec (IP security) and Virtual Private Networks (VPNs) against potential cyberthreats. The NSA advisory also highlighted the importance of using strong cryptography techniques to protect sensitive information and communication when connecting to remote servers via third-party sources.

“Many organizations currently utilize IP Security and Virtual Private Networks to connect remote sites and enable telework capabilities. These connections use cryptography to protect sensitive information that traverses untrusted networks. To protect this traffic and ensure data confidentiality, it is critical that these VPNs use strong cryptography. This guidance identifies common VPN misconfigurations and vulnerabilities,” NSA said in the advisory.

Securing Virtual Private Networks

For a secure VPN, NSA recommended certain guidelines, including:

  • Reduce the VPN gateway attack surface
  • Verify that the cryptographic algorithms are Committee on National Security Systems Policy (CNSSP) 15-compliant
  • Avoid using default VPN settings
  • Remove unused or non-compliant cryptography suites
  • Apply vendor-provided updates for VPN gateways and clients

“VPNs are essential for enabling remote access and securely connecting remote sites, but without proper configuration, patch management, and hardening, VPNs are vulnerable to attack,” the advisory added.

Mitigating Attack Surface

The advisory stated that VPN gateways can be accessed directly from the internet and are exposed to network scanning, zero-day vulnerabilities, and brute force attacks. In order to defend against these vulnerabilities, NSA urged network administrators to execute traffic filtering rules, which include:

  • Restrict all traffic to the VPN gateway, limiting access to only UDP port 500, UDP port 4500, and ESP
  • When possible, limit accepted traffic to known VPN peer IP addresses. Remote access VPNs present the issue of the remote peer IP address being unknown and therefore it cannot be added to a static filtering rule
  • If traffic cannot be filtered to a specific IP address, NSA recommends an Intrusion Prevention System (IPS) in front of the VPN gateway to monitor for undesired IPsec traffic and inspect IPsec session negotiations

“VPNs are essential for enabling remote access and connecting remote sites securely. However, without the proper configuration, patch management, and hardening, VPNs are vulnerable to many different types of attacks. To ensure that the confidentiality and integrity of a VPN is protected, reduce the VPN gateway attack surface, always use CNSSP 15- compliant cryptography suites, avoid using vendor defaults, disable all other cryptography suites, and apply patches in a timely manner,” the NSA concluded.

 

 

Hacker Infiltrates 22,900 Unsecured MongoDB Databases to Demand Ransom

Zyxel Devices Vulnerable to Secret Backdoor

An unknown hacker took control of over 22,900 unsecured MongoDB databases that were left online without password protection, a number that accounts for roughly47% of all MongoDB databases available online, according to the Sophos report.

The hacker uploaded a ransom note demanding a 0.015 bitcoin (approximately $140) payment and also threatened to leak the data and then report to GDPR authorities.

“All your data is backed up. You must pay 0.015 BTC within 48 hours to recover it. After 48 hours, we will leak and expose all your data. If you refuse to pay, we will contact the General Data Protection Regulation authority and notify them that you store user data in an open form and is not safe. Under the rules of the law, you face a heavy fine or arrest and your base dump will be dropped from our server,” the hacker’s ransom note read.

Sophos learned that the hacker used an automated script to scan for misconfigured MongoDB databases online. The hacker accessed the same databases and dropped the same ransom note multiple times.

Focus on Unsecured Databases

Every minute is an opportunity for threat actors when they find an unsecure server left online. A recent security experiment by Comparitech led by cybersecurity researcher Bob Diachenko discovered that cybercriminals attacked a model of an unsecured database 18 times in a single day. In a security alert, Comparitech explained how unauthorized third parties find, gain access, and alter exposed data without any authentication process, leaving users’ privacy at risk. The company set up a honeypot to know how quickly the hackers would attack an Elasticsearch server with a dummy database and fake data in it.

Comparitech left the exposed data from May 11 until May 22, 2020. It found 175 attacks in just eight hours after the server was deployed, and the number of attacks in one day totaled to 22. All attackers were not looking to steal data. Some targeted unsecure servers to mine cryptocurrency, steal passwords, and destroy data, Comparitech stated.

 

The Zero Trust Primer: A Simple Overview of the NIST 800-207 Draft

Research Finds Increase in Botnet and Exploit Activity in Q2 2020

Zero Trust as a concept has but one fundamental assumption. Nothing should be implicitly trusted – not your identities, not your devices, not your network components. “Trust, but Verify”, gives way to “Do not trust. Verify every time.” The draft NIST 800-207 explains the basics of Zero Trust (ZT) and Zero Trust Architecture (ZTA). This article summarizes and simplifies the core concepts of NIST 800-207.

The concept is deceptively simple.

By Chaitanya Kunthe, Co-founder and Chief Operating Officer at Risk Quotient

The challenge, for CISOs, lies not in understanding the concept, but in finding the right path to implement it within their environments.

What is Zero Trust?

Zero Trust is different from the traditional ‘castle and moat’ architecture where you protect your perimeter and stop the bad guys from entering your sacred space. If you can control who comes in, you can trust everyone within your network. Bad guys out there. Good guys in here. You see the problem already?

The modern network does not have clear boundaries. You might have autoscaling container clusters that are hosted by cloud service providers and accessed by your DevOps team from their homes. Your HR team might be running their HRMS as a SaaS. Your security operations centre might be outsourced to a third party. The castle and moat approach fails when what-you-need-to-protect is outside your castle.

Zero Trust Architecture does not care where your assets are or where your users are. That is the beauty of it.

In the NIST 800-207, there are 2 goals of ZT and ZTA:

  • Prevent unauthorised access to data and services
  • Make access control and decisions of access control as granular as possible

The first goal is plain common sense. It is the second one that makes ZTA interesting.

To achieve it, you have to devise an architecture that shrinks ‘implicit trust zones.’ For example, if you have a server zone containing 100 servers, and an admin who has access to the entire server zone then the ‘implicit trust zone’ for the admin is 100 servers wide. Not very Zero Trust.

The trick lies in reducing this 100 servers’ zone to say 5 servers, for admin A, without increasing authorization delays.

Core Areas of Zero Trust

ZT 1

ZTA focuses on three core areas:

  • Enterprise identities and devices
  • Enterprise Resources
  • Trust Verification Systems (Policy Decision Points (PDP) & Policy Enforcement Points (PEP) and policy engine)

Enterprise identity and devices: This has two parts. First, the device authenticates the identity (user) and checks if the request is valid. This is already implemented in organizations today. Think of your average run-of-the-mill VPN connection – the user logs in to the device (authenticate the identity) and then the VPN application checks for a proper VPN certificate (valid request).

Trust Verification Systems: Here is where ZT really comes into its own. Your verification system should judge the level of confidence on the identity as well as the request and not just provide access when the base criteria are met.

The level of confidence is the trust that the verification system (Policy Engine /PDP / PEP) has in the system + identity making the request based on certain criteria. Some points that can be considered:

  • Does the device + identity normally connect at these times?
  • Does the identity connect from various devices? Which ones are trusted?
  • Is there anything out of pattern in the request?

Think of your VPN server that is accepting connections. Does it analyze the level of confidence in the request? If it were, it could provide different levels of access based on the level of confidence it has on the request. These are what Zero Trust calls ‘dynamic risk-based policies’ to access resources.

This ‘Trust Algorithm’ or ‘Policy Engine’ is the brain behind Zero Trust.

Resource: No surprises here. They can be any system, applications, devices, data, information etc. that have some value for the organization.

Tenets of Zero Trust Architecture

There are 7 basic tenets that every zero trust architecture must try to achieve:

zt 2

Consider these as the ‘goals’ of zero trust’:

  • All data sources and computing services are considered as ‘resources’
  • All communication is secured (internal or external)
  • All access is provided ‘per-session’
  • Access is provided based on a dynamic risk-based policy
  • All devices should be in the most secure state possible. They should be monitored for this
  • Dynamic authentication and authorization is strictly enforced before granting access
  • Collect as much information about the network and infrastructure as possible

Getting Started with Implementing Zero Trust Architecture

Here we move a little away from the basics and talk more from the implementation perspective.

CISOs should start thinking of their enterprise in terms of these tenets and create a plan that will take them from where they are to a zero trust architecture. There are many paths to zero trust. As long as you comply with these tenets, you can say that you are a zero trust company.

You need not comply to all of these tenets. Pick and choose what makes your network more secure.

Here are a few logical steps to get you started:

  • Identify all the resources in your organization – data sources as well as computing resources used. Check if they have basic authentication and request validity checks. You can use your existing asset databases, configuration databases etc. for this.
  • List all the ‘identities’ in your organization. How many and what type of identities do you manage? This might not be easily available as most organizations do not track identities as effectively as they track assets. However, you are in luck if you have an IDAM solution implemented across the organization.
  • Now, the tricky part – identify the places where the identities need to interact with the resources. It is almost like creating a data flow diagram. At each interaction point, identify levels of confidence. For example, a known user and device connecting from an unknown IP would have a lesser level of confidence as compared to a known user and device connecting from a known IP. This can get very daunting. A piecemeal approach is best suited here.
  • Identify the level of access to provide at various levels of trust.
  • Identify if your current access control tools can deliver what you expect. If not, calculate the risk associated with not being able to identify the level of confidence. If the risk is unacceptable, look for a solution that meets your requirement

Implementing zero trust is a very strategic exercise. You cannot have a tool that you can plug, and it magically implements zero trust in your organization. If you want to implement zero trust, prepare to roll up your sleeves and painstakingly proceed step by step.

You might now have more questions, like:

  1. What are the risks of implementing Zero Trust?
  2. What inputs should the trust algorithm consider?
  3. What are the different deployment scenarios in which Zero Trust can be implemented?

The NIST 800-207 draft is a detailed document that answers these questions. It contains many sections that a would-be practitioner of Zero Trust would be interested in. If this has piqued your interest, download the standard from the NIST website and go through it.

About the author:

Chaitanya KuntheChaitanya Kunthe is a seasoned cybersecurity mentor who believes in simplifying things. He is the Co-founder and Chief Operating Officer at Risk Quotient, where he mentors the team to provide innovative and practical cybersecurity advice.

 

Disclaimer

CISO MAG did not evaluate/test the products mentioned in this article, nor does it endorse any of the claims made by the writer. The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same. CISO MAG does not guarantee the satisfactory performance of the products mentioned in this article.

Was it Stuxnet 2.0? Cyberattack on Iran’s Natanz Nuclear Facility

Israel and Iran, Iran cyberattack, cyber war

A fire broke out at Iran’s Natanz nuclear facility on July 2, 2020. The Atomic Energy Organization of Iran (AEOI) spokesman Behruz Kamalvandi, said that the incident took place at one of the industrial sheds under construction at the Natanz uranium enrichment plant. And although the fire caused significant damage, no casualties were reported. However, now reports suggest that this was a sabotage attempt by state actors initiated through a cyberattack on Iran’s nuclear facility.

Attempt at Stuxnet 2.0?

The Shahid Ahmadi Roshan Natanz Nuclear Complex is a known nuclear facility in Iran. The UN nuclear watchdog – International Atomic Energy Agency (IAEA) – is keeping a close eye on the proceedings at this facility for the past few years. Why? Because this site has an underground facility that can produce enriched uranium which acts as fuel for reactors but also works as a basic component for creating nuclear weapons.

Although no official statement was given from Iran, a post in the Al-Jareeda daily cited an unnamed senior source as saying that an Israeli cyberattack is behind this entire episode, which was initiated with an intent of sabotage and push the progress of the nuclear enrichment program back by two months. This is very similar to a 2010 cyberattack against the same adversary, which then came to be known as the first known cyber weapon, the Stuxnet.

The First known Cyber Weapon

Stuxnet was a computer worm designed specifically by the U.S. and Israel to target the industrial control systems (ICS) made by Siemens. It was a self-replicating malware that used Windows vulnerabilities to penetrate the SCADA. Once in, it targeted the systems controlling the centrifuges in the Iranian nuclear plant. Although no affirmation of the exact impact was publicly given by Iran, unofficial statements claimed that almost 1,000 centrifuges were damaged in this cyberattack, which delayed the completion of the Iranian nuclear plant.

Although there are many possibilities behind this incident, but nothing can be affirmed unless Iran confirms these theories, which Behrouz Kamalvandi says, “will be declared in due course for security reasons.”

Massive Data Breach Exposes PII of 99,000 V Shred Customers and Trainers

V Shred Data Breach

Security research firm vpnMentor reported that fitness brand V Shred suffered a data breach that exposed the personally identifiable information (PII) of 99,000 of its customers and trainers. The exposed information included V Shred users’ names, home addresses, social security numbers, email addresses, dates of birth, social media accounts details, age, usernames, passwords, sensitive photos of V Shred customers, gender, and citizenship status.

According to vpnMentor’s report, an unsecured AWS S3 bucket exposed V Shred’s database, which contained 1.3 million files, containing 606GB data. The exposed database contained three types of .CSV files: the CSV file #1 has 96,000+ entries of lead generation list; CSV file #2 has V Shred client email list, with 3,522 entries; and CSV file #3 has a list of 52 trainers working for V Shred, including their email addresses. The unsecured database is now secured after vpnMentor reported the issue to V Shred.

“The data was stored on a misconfigured Amazon Web Services (AWS) S3 bucket, which was completely open to public access. The URL of the bucket contained V Shred, and many of the files contained the company’s logo and other identifiers,” the report said.

How to Secure an AWS S3 Bucket

vpnMentor also recommended certain instructions to AWS users to secure S3 buckets, these include:

  • Make the bucket private and add authentication protocols
  • Follow AWS access and authentication best practices
  • Add more layers of protection to their S3 bucket to further restrict who can access it from every point of entry

“It is important to note that open, publicly viewable S3 buckets are not a flaw of AWS. They are usually the result of an error by the owner of the bucket,” the report added.

Data Breaches on Fitness Firms

In a similar data breach, security researchers discovered an open database, which belongs to fitness tech company Kinomap, exposing 42 million records (40GB data) of its users for at least a month. The database includes PII of users from across 80 countries, including North America, Australia, Japan, the U.K., Belgium, Finland, and Hungary. The exposed PII included full names, home country, email addresses, usernames, Kinomap account details, gender, timestamps for exercises and the date they joined Kinomap. vpnMentor stated that it notified the French firm on March 28, 2020, immediately after the discovery. The database was fixed on April 12, 2020, after the French data protection regulator had been informed.

 

U.S. Schools Suffer Over 1,300 Data Breaches Since 2005

U.S. Schools Suffer Over 1,300 Data Breaches Since 2005

A research from technology website Comparitech revealed that K–12 school districts and colleges across the U.S. have suffered over 1,300 data breaches since 2005. More than 24.5 million records have been compromised in the data breaches.

According to the research, hacking is the topmost cause of data breaches in schools and colleges, with 45.9% of hacking incidents reported. Accidental data disclosure is second with 21% incidents in schools and 27.3% in colleges, followed by data theft or loss of data storage devices (11.1% in schools, and 14.7% in colleges).

Other findings from the research include:

  • California is a hot spot for both college and K-12 data breaches with 12.2% of the 985 college data breaches and 10.6% of the 21.5 million records affected.
  • New York reported most of the data breaches, with 63 breaches affecting almost half a million records.
  • Arizona is one of the worst-hit states by number of records affected, with 2.83 million people affected.
  • Wyoming is the only state to have no known reported education breaches.
  • 2008 had the most education data breaches, but 2013 and 2017 were the biggest years by the number of records affected.
  • The majority of records compromised in college data breaches with 3.07 million and 2.9 million records affected in 2013 and 2017 respectively.
  • The biggest years for K–12 schools were 2018 and 2019 with 991,340 and 804,734 records affected, respectively.

“There does not appear to be any kind of trend in the breach numbers for K-12 schools or colleges, nor does there seem to be a pattern with college records affected. However, over the past few years, there has been a significant increase in the number of school records affected,” the report said.

Ransomware Attacks on K-12 Schools

Earlier, a similar report revealed that around 86 universities, colleges, and school districts were impacted, which in turn disrupted operations of nearly 1,224 individual schools due to ransomware attacks. The report also shared a list of  top three incidents of public schools being affected by ransomware attacks.

K-12 Cybersecurity Act

In order to address the rising cyberthreats on K-12 schools, two U.S. Senators, Gary Peters (Michigan) and Rick Scott (Florida), both members of the Senate’s National Security and Government Affairs Committee, have tabled a bill called “K-12 Cybersecurity Act” in December 2019. The Act directs the DHS Cybersecurity and Infrastructure Security Agency (CISA) to first study the specific cybersecurity risks associated with K-12 educational institutions. Once the study is done, CISA will then be responsible to develop cybersecurity recommendations and set up online tools to help schools with their cybersecurity requirements.

 

1...194195196...409Page 195 of 409