rUUh roh: University of Utah and it’s insurance provider pay ransom

 

Until a thorough and robust method to stop ransomware, this phenomenon is going to continue to flourish. This popular method to attack is simple, and profitable to the attackers. Once this was successfully monetized, there was no turning back for the attackers. Another glaring example occurred this July with the University of Utah.

Attack

The University of Utah has been added to the list of ransomware victims (e.g. Michigan State University (MSU did not pay the ransom and the data was placed on the dark web), Columbia College of Chicago, Canada’s Royal Military College in Ontario, and the University of California at San Francisco (paid $1.14M)). The university’s Information Security Office (ISO) was notified on July 19^th of the attack. The focus of the attack was the College of Social and Behavioral Science (CSBS) servers. The central servers were not affected. The attackers have not been identified as of yet, which is not unusual. This group of attackers is likely the same which has been making the rounds, attacking other universities. The data indicates this, and the others may have been perpetrated by the NetWalker ransomware gang. As mentioned previously, this method of attack tends to be profitable. It is estimated the group has received more than $25M this year alone with these attacks.

Actions by the University

After the breach, the attackers encrypted the servers, which prompted the ransom demand. The university did act affirmatively and isolated the servers from the remainder of the network and the internet. They began an investigation and notified law enforcement. In addition, they are working with a third party specializing in these attacks to resolve the issue. No other systems were impacted by this. The affected students and staff were directed to change their university passwords on July 29^th.

Ransom

To regain their systems, the university and its insurance provider did pay $457,059.24 in Bitcoin. Thankfully the university had in place cybersecurity insurance to cover at least a portion of the ransom, as the university paid the remainder. While I generally don’t recommend this course of action, in this instance the attackers were able to secure sensitive data and allegedly they would have released this online for everyone to see and likewise secure if the ransom was not paid. This data included sensitive information for the employees and students. While this included only 0.02% of the data on the servers, this could still be a rather large amount of data that would have been placed online, without the ransom being paid. The issue is the university is depending on a group of attackers who breach systems and extort funds from the target. It is notable the fee was to remove the threat of the data being published. The university did restore the data from back-ups.

Lessons Learned

First and foremost, please train your staff to watch for this type of email or other communication. The method of attack is relatively simple. The attacker(s) send emails with malicious links or attachments. The humans, which are the primary attack surface, click the link or attachment, and the CISO begins to have issues quickly. Alternatively, based on the circumstances, the group could simply breach the targeted system, which may take more time and resources in comparison to the first option. The training and continued training is the first line of defense. Naturally, there is also the SIEM and other apps that also are required to attempt to severely limit the issue. With implementing these in earnest, not merely checking the box, the potential to correct the problem is on the right track. Until then, the attackers are going to use this method as much as possible, and collect as much as possible, to the detriment of the victims.

 

Resources

Cimpanu, C. (2020, August 21). University of Utah pays $475,000 to ransomware gang. Retrieved from https://www.zdnet.com/article/university-of-utah-pays-457000-to-ransomware-gang/

Dudley, G. (2020, August 21). University of Utah paid hackers $457k after ransomware attack. Retrieved from https://www.ksl.com/article/50008933/university-of-utah-paid-hackers-457k-after-ransomware-attack

Hamilton, E. (2020, August 21). The university of Utah just footed a $475,000 ransomware bill. Retrieved from https://news.knowledia.com/US/en/articles/the-university-of-utah-just-footed-a-457-000-ransomware-bill-fae31fb0a1a1ae1ac148c4e67e5dfba60b78f42f

Kass, D.H. (2020, August 26). University of Utah pays nearly $500k to ransomware gang to recover data. Retrieved from https://www.msspalert.com/cybersecurity-breaches-and-attacks/ransomware/university-of-utah-pays-nearly-500k-to-ransomware-gang-to-recover-data/

Raymond, A. (2020, August 21). Cyber swindlers take university of Utah for nearly $500k in ransomware attack. Retrieved from https://www.deseret.com/utah/2020/8/21/21396174/cyber-swindlers-take-university-of-utah-for-nearly-500k-in-ransomware-attack

Pierce, S.D. (2020, August 21). University of Utah pays more than $450,000 in ransomware attack on its computers. Retrieved from https://www.sltrib.com/news/2020/08/21/university-utah-pays-more/

On the need for more cybersecurity professionals

 

 

There is a continuing problem we are experiencing in InfoSec, which is not something new. There is a shortage of personnel in the industry. If this is not a detrimental situation, there is also a training issue to further compound this.

               The first issue can be applied in economics view. The demand curve beginning approximately a decade ago has a robust upward curve. The curve has not been linear, or straight, but has increased its arc, meaning year after year the number of professionals in demand has increased at a higher rate than the year before. The increase in demand is due to several environmental factors. There are many more businesses online compared even to a couple of years ago. Each of these throughout the globe has its internet presence, applications, servers, AWS instances, etc., or multiples of these. Each of these creates another attack point. With the rapid expansion of the attack surface available, also brings with it the opportunity to attack and defeat a system. With all of this available, the attackers grew in number. While the concentration for each country is not uniform, the numbers are still growing within each. The attacks have been operationalized and have proven to be rather profitable, especially in the case of ransomware. The incidences have included success in attacks against city and county governments, massive corporations, and others of any size. Any business or municipality is a viable target to begin the attack processes a low bar; all it takes is a person in the organization clicking a link or an attachment.

               While the attacks continue to increase at an alarming rate, creating the business demand for persons with this skill set, the supply curve is increasing at a rather conservative rate. This crime has a slight incline. The difference between supply and demand continues to grow. This is a clear indication there’s a problem. People are not entering the field at a sustainable rate, and the people in the positions are burning out and leaving.

               This shortage has forced businesses to hire and bring people in who are not the most qualified. These persons may attend a boot camp for a few weeks and market themselves as subject matter experts (SMEs). While this is a good starting point, this is not the pinnacle for being qualified as a cybersecurity SME. This skills gap is also a problem for the industry. Management still has issues with fully understanding and appreciating cybersecurity and its role. Without some form of a roadmap for decreases the skills gap, the problems will continue and grow. This may be due to also HR not grasping the pertinence of cybersecurity. There have been dozens of highly publicized breaches detailing what happens to the business post-breach, especially in the health care field. This may also be an issue of not triaging what skills and training are important now versus which may be addressed later.

               However you wish to look at this, there is a significant problem that is not getting resolved in the near future. If the industry will not give this analysis the appropriate level of attention, the difference between the numbers in the industry in comparison to the numbers needs to grow at an ever-increasing rate.

 

DataViper Pwned

 

 

Cybersecurity is a hot commodity in the last few years. There seems to be new firms popping up everywhere, all claiming to use the newest tools, and a few even claim to have AI built-in! While these claims may be mostly generated by the marketing department and the AI is really ML with a nuance, there are a few legitimate firms. One of the newer firms is Data Viper, based in St. Louis, MO. This firm was founded by Vinny Troia, a cybersecurity subject matter expert. Data Viper notes it is an intelligence platform engineered to provide its clients with the largest collection of private information, hacking channels, and exposed databases online. While other firms do this, the nuance to differentiate Data Viper from the others s they provide their clients access to private and undisclosed data. As part of their business model, Data Viper collects exposed information on greater than 8k data breach incidents, including approximately 15B usernames, passwords, and other data. The firm has posed as a buyer or seller of stolen data on the dark web to expand their database.

Attack

The firm was successfully attacked, with the focus being the firm’s backend servers.

This has been evidenced by the bad actors leaking the database online which was exfiltrated. The attacker not only leaked this but is also selling the database on the dark web. As part of this, the firm collected data from thousands of security incidents. There may also be information on companies who do not know they had been breached. Within the database being sold is hundreds of GB of data. This includes data from approximately 8,225 databases. These are comprised the information for billions of users from other company’s prior breaches. A portion of this data is from prior breaches, however, what makes this more pertinent is there is other data from companies who have not reported their incidents, indicating they may not know they had been breached.

It is not known how the attackers were able to gain access, or better yet able to stay on the Data Viper network for months to extract all of this data..un-noticed. The attacker is rather unapologetic as it relates to their activities. The attacker’s marketing campaign for this includes posting these for sale in multiple forums and selling up to 50 of the largest databases on the Empire dark web.

Troia did mention that this was not a case of credential stuffing, but one of the developers accidentally exposing the repository access credentials. Of the options, having an employee make this level of negligence speaks volumes.

Resources

Cimpanu, C. (2020, July 13). Hacker breaches security firm in act of revenge. Retrieved from https://www.zdnet.com/article/hacker-breaches-security-firm-in-act-of-revenge/            

Eyerys. (2020, July 15). Leaked databases gathered by cybersecurity company has been stolen by a hacker. Retrieved from https://www.eyerys.com/articles/timeline/leaked-databases-gathered-cybersecurity-company-has-been-stolen-hacker#event-a-href-articles-timeline-deepfake-one-most-serious-ai-crime-threats-researchers-saiddeepfake-one-of-the-most-serious-ai-crime-threats-researchers-said-a

Krebs, B. (2020, July 20). Breached data indexer ‘data viper’ hacked. Retrieved from https://krebsonsecurity.com/2020/07/breached-data-indexer-data-viper-hacked/

Sandle, T. (2020, August 9). Hacker extracts thousands of databases from cybersecurity firm. Retrieved from http://www.digitaljournal.com/tech-and-science/technology/hacker-extracts-thousands-of-databases-from-cybersecurity-firm/article/575794

Securitynewspaper.com. (2020, July 14). How a hacker revenged a cyber security company by hacking and leaking all its data. Retrieved from https://laptrinhx.com/how-a-hacker-revenged-a-cyber-security-company-by-hacking-and-leaking-all-its-data-3738611886/

              

Bootloader issues can be a problem

 

The computers and systems we use at work and at home have to be secure. We work on confidential, sensitive projects, and have PII on these every single day. This data being released into the wild or for sale on the dark web would be a truly bad thing for everyone involved. For business, there is also liability and fines which may be a concern. These can be rather significant with certain industries (e.g. healthcare). There is not a way around this. With the systems, the cybersecurity has to be in place from the beginning of the operation. There can’t be a lag. Any time this is not in place, the attack surface expands for the attacker to examine. As the system starts, the boot process kicks in and begins the operations. A recent attack focused on this part of the process. The new exploit is a bootkit, since it resides in the bootloaders. The new attack has been named “There’s a Hole in the Boot”.

               The problem at hand is with the bootloader process of the enterprise OS. In Linux systems, the vulnerability is in the Grand Unified Boot Loader (GRUB). Most programs use a program (i.e. shim) to extend the trust from the firmware to other programs securing early during the boot process. The particular issue is with the configuration parser in GRUB2 (grub.cfg) not properly exiting when there are errors present. This is exploitable when you increase the size of a token with the grub.cfg. This results in a heap-based buffer overflow. This acts to break the chain of trust. At this point, the attacker may download a non-signed (e.g. malicious) programs during this time in the boot process.

               In Microsoft systems, the successful attack allows arbitrary code to be executed and UEFI (Unified Extensible Firmware Interface) Secure Boot restrictions bypassed. In the Microsoft systems, the UEFI was engineered by the UEFI Consortium to protect the boot process from attacks. This ensures only the immutable and signed software is uploaded during the boot process and not malicious code, which in theory makes it “secure”. The attack allows the attacker to execute arbitrary code and bypass the UEFI Secure Boot restrictions.

               Secure boot has two steps, which are checking the allow (DB) and disallow (DBX) databases. These are just as they appear. The allow database (DB) holds the hashes and keys for the trusted loaders and EFI applications. These are allowed to be loaded onto the machine’s firmware. Naturally, the disallowed database (DBX) holds the revoked, compromised, and hashes/keys that are no longer trusted. The boot process fails when any signed code on the DBX is presented.

               The attack affects many different systems and versions. In particular, this is targeted to Enterprise Linux 7 and 8, Red Hat Atomic Host, Openshift Container Platform 4 (RHEL CoreOS), Windows 10, 8.1, Server 2012, Server 2019, Server 1903, Server 1909, and Server 2004.

Issue

               This is a rather significant issue. This was researched by the security vendor Eclypsium. As the responsible cybersecurity researchers, they did coordinate the disclosure of the issue. The firm notified Microsoft, Linux distributors (Red Hat, SuSE, Canonical/Ubuntu, and Debian), Citrix, VMware, computer original equipment manufacturers, and software developers. This may seem like a rather broad brush with notifying all of the organizations and groups. The risk with the issue is rather large though. Nearly every Windows and Linux system using secure boot is at risk. This also affects network appliances, proprietary gear specific to healthcare, financial and other industries, internet-of-things (IoT), operational technology (OT), and SCADA equipment in industrial environments. Once this is exploited, the attackers are able to bypass the secure boot process that is supposed to guard the system and disable other code integrity checks. Once this is done the attackers are able to load arbitrary executables and drivers. The attacker, once this is done, could nearly take over the complete system.

To hack or not to hack, that is the question

This appears to be a rather serious problem, with billions of devices at risk. This attack is not as easy as other attacks. To exploit this, you would need to have admin rights/root OR physical access to a system. If an unauthorized person has access and admin rights or physical access to a live system, you probably have larger systemic problems than this. This also has a limited level of relevance for most cloud computing uses, data centers, and personal devices. This has a limited application unless the system is already pwned

Mitigation

There are updates available for Ubuntu 20.04, 18.04, 16.04, and 14.04, and other systems. SuSE and Debian have released patches for this issue. Red Hat recommends updating their GRUB 2 packages. Red Hat clients using Secure Boot need to update the kernel, fwupdate, fwupd, shim, and dbxtool packages with the newly validated keys and certificates.

While these are great, this is not a quick fix. The mitigations will be a multi-step process and will take a long process and take significant time to complete the patches. In the interim, the admins need to monitor the contents of the bootloader partition (EFI system partition) for their OS, test the revocation list updates, deploy revocation updates, and engage with your third-party vendors to understand how they are addressing this issue  

Resources

Auscert. (2020, July 30). There’s a hole in the boot. Retrieved from https://www.auscert.org.au/blog/2020-07-30-theres-a-hole-in-the-boot

Blinde, L. (2020, July 31). NSA warns of GRUB2 BootHole vulnerability. Retrieved from https://intelligencecommunitynews.com/nsa-warns-of-grub2-boothole-vulnerability/

Brink. (2020, July 29). BootHole vulnerability in secure boot affecting Linux and windows. Retrieved from https://www.tenforums.com/windows-10-news/161603-boothole-vulnerability-secure-boot-affecting-linux-windows.html

Canonical. (2020, July 29). USN-4432-1: GRUB 2 vulnerabilities. Retrieved from https://ubuntu.com/security/notices/USN-4432-1

Cimpanu, C. (2020, July 29). ‘BootHole’ attack impacts windows and Linux systems using GRUB2 and secure boot. Retrieved from https://www.zdnet.com/article/boothole-attack-impacts-windows-and-linux-systems-using-grub2-and-secure-boot/

Debian. (2020). GRUB2 UEFI SecureBoot vulnerability-‘BootHole’. Retrieved from https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/

Germain, J.M. (2020, July 29). New security hole puts windows and Linux users at risk. Retrieved from https://www.technewsworld.com/story/86778.html

Goodin, D. (2020, July 29). New flaw neuters secure boot, but there’s no reason to panic. Here’s why. Retrieved from https://arstechnica.com/information-technology/2020/07/new-flaw-neuters-secure-boot-but-theres-no-reason-to-panic-heres-why/

Goetting, B. (2020, July 29). BootHole GRUB2 bootloader security exploit discovered, affects billions of windows and Linux devices. Retrieved from https://hothardware.com/news/eclypsium-boothole

Ilascu, I. (2020, July 29). BootHole GRUB bootloader bug lets hackers hide malware in Linux, windows. Retrieved from https://www.bleepingcomputer.com/news/security/boothole-grub-bootloader-bug-lets-hackers-hide-malware-in-linux-windows/

Kovacs, E. (2020, July 30). Companies respond to ‘BootHole’ vulnerability. Retrieved from https://www.securityweek.com/companies-respond-boothole-vulnerability

Kumar, M. (2020, July 29). Critical GRUB2 bootloader bug affects billions of Linux and windows systems. Retrieved from https://thehackernews.com/2020/07/grub2-bootloader-vulnerability.html

Meissner, M. (2020, July 27). SUSE addresses BootHole security exposure. Retrieved from https://www.suse.com/c/suse-addresses-grub2-secure-boot-issue/

Microsoft. (2020, July 29). ADV200011|Microsoft guidance for addressing security feature bypass in GRUB. Retrieved from https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011

Monathan, J. (2020, July 29). “Boothole” bootloader flaw breaks security on most Linux, windows devices. Retrieved from https://securityledger.com/2020/07/boothole-bootloader-flaw-breaks-security-on-most-linux-windows-devices/

Murphy, I. (2020, July 30). BootHole exposes billions of devices to attack. Retrieved from https://www.enterprisetimes.co.uk/2020/07/30/boothole-exploits-a-vulnerability-in-the-secure-boot-process-affecting-virtually-every-linux-distribution-windows-machine-and-other-operating-systems/

Red Hat Customer Portal. (2020, July 29). Boot hole vulnerability: GRUB 2 boot loader-CVE-2020-10713. Retrieved from https://access.redhat.com/security/vulnerabilities/grub2bootloader /78

Saarinen, J. (2020, July 30). Boothole GRUB2 bug breaks secure boot on Linux and windows. Retrieved from https://www.itnews.com.au/news/boothole-grub2-bug-breaks-secure-boot-on-linux-and-windows-551050

Seals, T. (2020, July 29). Billions of devices impacted by secure boot bypass. Retrieved from https://threatpost.com/billions-of-devices-impacted-secure-boot-bypass/157843/

Sheridan, K. (2020, July 29). ‘BootHole’ vulnerability exposes secure boot devices to attack. Retrieved from https://www.darkreading.com/vulnerabilities---threats/boothole-vulnerability-exposes-secure-boot-devices-to-attack/d/d-id/1338487

Solomon, H. (2020, July 30). IT admins being warned of vulnerability in secure boot process in Linux, windows. Retrieved from https://www.itworldcanada.com/article/it-admins-being-warned-of-vulnerability-in-secure-boot-process-in-linux-windows/433860

SUSE. (2020). Security vulnerability: “Boothole” grub2 UEFI secure boot lockdown bypass. Retrieved from https://www.suse.com/support/kb/doc/?id=000019673

Goshen Health learned the hard way: Phishing is alive and well

 

Healthcare is in a difficult position during these times. In between the pandemic, budgetary constraints, union negotiations, and other issues, their road is, to say the least, tough. Now add in cybersecurity issues, and the risks increase exponentially. All it takes is one person in the right department to click on the right link or icon, and BAM, a compromise is just around the corner. Goshen Health was unfortunate enough to learn this from their own experience. In this example from late last year, Goshen Health had the opportunity to personally test out their incident response (IR) plans.

Data

Healthcare facilities hold so much data, which is valuable for numerous reasons. This is especially the case for the attackers. This is sold on the dark web without an issue. In this case, 9,160 patients had their protected health information (PHI) stolen from Goshen Health. The data could have included many different points for each person. In this instance, the data exfiltrated included the names, dates of birth, location, driver’s license number, social security number, healthcare insurance details, names of doctors providing care, and certain clinical information. This really would be beneficial for the attackers or the person/organization purchasing this. All of this fantastic data could be used for credit card fraud, fraud over the phone, utility fraud, bank fraud, government, and medical identity fraud. The truly enterprising attacker could use this data for years to come.

Post-Compromise

After the InfoSec department and administrators had understood the compromise had happened, the facility notified the 9,160 patients potentially affected with communication on September 30, 2019. Since this was a phishing attack, Goshen Health secured the compromised email accounts. Without this action in place, the breach would have kept open, and the attackers would continue to leverage this as much as possible. After the notification, the incident investigation began immediately. At first, Goshen Health believed they would not need to issue patient notifications. This sounds counter-intuitive given there was a breach of a medical facility. The team, however, believed there was no PHI involved. This was a rather significant oversight. As of August 1^st, the compromised email accounts actually had the patient PHI included. This has been noted in several successful attacks in recent memory. Instead of leaving the PHI on the servers or in the cloud, the data is emailed about. If the PHI was not in the compromised emails, the organization would not have had to notify the government and staff. To reduce the potential for this to occur again, the facility has improved the security protection and added more forensic resources and technology, just in case they were to be targeted again. For the investigation, they did contract with third-party forensic personnel to research the breach in November 2018. The subject matter experts (SMEs) did not find evidence of PHI being involved initially. It took them a year to identify the compromised email accounts, which held the PHI. The organization filed the breach report with HHS Office for Civil Rights on September 30, 2019. For those affected with their social security numbers, the facility is offering free credit monitoring and identity theft protection for one year. The organization had its employees attend email security and phishing awareness training. The facility is recommending the patients monitor their accounts for any irregularities.

Attack Method

Phishing strikes again. The phishing attack was in August 2018, from the 2^nd to the 13^th. For all of the patients affected and the additional expenses to the facility, this was due to a simple phishing email. This is another example of how far-reaching a simple click can affect a large hospital, along with the expenses involved with the investigation, and directly with the patients. The access was from an unknown, unauthorized party.

In parting…

There seems to be a rather significant time lag with the organization in more than one area. It took approximately a year to discover the emails had PHI in them. This seems like this task would not have taken this long to accomplish. There are logs and other resources available to review this. This portion is especially curious.

 

 

Resources

Blankenship, F. (2019, October 4). Goshen health data breach potentially exposes 9,160 patients’ sensitive records. Retrieved from https://4classaction.com/2019/10/04/goshen-health-data-breach-potentially-exposes-9160-patients-sensitive-records/

Dissent. (2019, October 2). IN:Goshen health notifies patients potentially impacted by 2018 data security breach. Retrieved from https://www.databreaches.net/in-goshen-health-notifies-patients-potentially-impacted-by-2018-data-security-breach/

Garrity, M. (2019, October 3). Indiana hospital alerts 9,100 patients of breach. Retrieved from https://www.beckershospitalreview.com/cybersecurity/indiana-hospital-alerts-9-100-patients-of-data-breach.html

HIPAA Editor. (2019, October 8). 9,160 goshen health patients affected by phishing-related email breach. Retrieved from https://www.hipaaanswers.com/9160-goshen-health-patients-affected-by-phishing-related-email-breach

HIPAA Journal. (2019, October 3). Goshen health notifies 9,160 patients of historic PHI breach. Retrieved from https://www.hipaajournal.com/goshen-health-notifies-9160-patients-of-historic-phi-breach/