Not a week goes without a new Facebook blunder. Remember the most recent revelation of Facebook being caught asking users new to the social network platform for their email account passwords to verify their identity? At the time, it was suspected that Facebook might be using access to users’ email accounts to unauthorizedly and secretly gather a copy of their saved contacts. Now it turns out that the collection of email contacts was true, Facebook finally admits. In a statement released on Wednesday, Facebook said the social media company “unintentionally” uploaded email contacts from up to 1.5 million new users on its servers, without their consent or knowledge, since May 2016. In other words, nearly 1.5 million users had shared passwords for their email accounts with Facebook as part of its dubious verification process. A Facebook spokesperson shared information with Business Insider that the company was using harvested data to “build Facebook’s web of social connections and recommend friends to add.” The social media giant said the company had stopped this email verification process a month ago and has assured its users that it has not shared those contacts with anyone and that it has already started deleting them. “Last month we stopped offering email password verification as an option for people verifying their account when signing up for Facebook for the first time,” Facebook says. “We estimate that up to 1.5 million people’s email contacts may have been uploaded. These contacts were not shared with anyone and we’re deleting them. We’ve fixed the underlying issue and are notifying people whose contacts were imported. People can also review and manage the contacts they share with Facebook in their settings.” This recently reported incident is the latest in a long list of privacy-related issues and controversies the tech giant is dealing with. Just last month, Facebook was caught storing passwords of hundreds of millions of users in plaintext within its internal servers, which were accessible to some of its employees. In October last year, Facebook also announced its worst-ever security breach that allowed hackers to successfully steal secret access tokens and access personal information from 29 million Facebook accounts. The recent revelation once again underlines the failure of Facebook to protect its users’ information while generating billions of dollars in revenue from the same information.
By David Balaban What data do Facebook, Google, and mobile apps collect, do mobile carriers listen to your calls? Read this post and find answers to these and other privacy questions as well as get tips on how to protect your personal data. It has become known that information about 257,000 Facebook users have been freely available. Although […] This is a post from HackRead.com Read the original post: Never Forget That You Are Being Watched
Cisco has rushed out patches for a critical vulnerability in its ASR 9000 routers that could give remote, unauthenticated attackers access to the devices – as well as the power to launch denial-of-service (DoS) attacks against them. The flaw is specifically in Cisco Aggregation Services Routers (ASR) 9000 Series, Cisco’s popular carrier Ethernet router intended for service applications. The vulnerability could allow an unauthenticated, remote attacker to access internal applications on the sysadmin virtual machine for the router, according to a Wednesday advisory. “An attacker could exploit this vulnerability by connecting to one of the listening internal applications,” the advisory stated. “A successful exploit could result in unstable conditions, including both a denial of service and remote unauthenticated access to the device.” The vulnerability (CVE-2019-1710) has a CVSS score of 9.8, making it critical in severity. Specifically, Cisco ASR 9000 routers have an issue where the internal sysadmin applications are incorrectly isolated in the secondary management interface. ASR 9000 routers that are running Cisco IOS XR 64-bit software and that have the secondary management interface are impacted. That means an attacker could exploit this vulnerability by connecting to one of the listening internal applications. A successful exploit could result in unstable conditions, including both DoS and remote unauthenticated access to the device. Cisco said that the vulnerability was discovered during internal security testing, and that it is not aware of any exploits. Cisco ASR 9000 Routers Cisco has urged users to upgrade to the Cisco IOS XR 64-bit software as soon as possible: “This vulnerability has been fixed in Cisco IOS XR 64-bit Software Release 6.5.3 and 7.0.1, which will edit the calvados_boostrap.cfg file and reload the device,” it said. Cisco on Wednesday also revealed that exploit code for a previously-disclosed critical remote code execution vulnerability was now available. The critical flaw (CVE-2017-3881) was previously disclosed in March 2017 and exists in the Cisco Cluster Management Protocol used in Cisco IOS and IOS XE software. “A vulnerability in the Cisco Cluster Management Protocol (CMP) processing code in Cisco IOS and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause a reload of an affected device or remotely execute code with elevated privileges,” according to Cisco. Cisco has released patches for the flaw – but the exploit code was made available by a security researcher on April 10, according to Cisco. “The Cisco Product Security Incident Response Team (PSIRT) is aware of exploitation of the vulnerability that is described in this advisory,” according to Cisco. Earlier in April, Cisco re-patched flaws for two high-severity bugs affecting its RV320 and RV325 routers after a botched first attempt at fixing them. The company also reported two new medium-severity router bugs impacting the same router models – and with no reported fixes or workarounds. Don’t miss our free Threatpost webinar, “Data Security in the Cloud,” on April 24 at 2 p.m. ET. A panel of experts will join Threatpost senior editor Tara Seals to discuss how to lock down data when the traditional network perimeter is no longer in place. They will discuss how the adoption of cloud services presents new security challenges, including ideas and best practices for locking down this new architecture; whether managed or in-house security is the way to go; and ancillary dimensions, like SD-WAN and IaaS.
A cybersecurity professional today demonstrated a long-known unpatched weakness in Microsoft’s Azure cloud service by exploiting it to take control over Windows Live Tiles, one of the key features Microsoft built into Windows 8 operating system. Introduced in Windows 8, the Live tiles feature was designed to display content and notifications on the Start screen, allowing users to continuously pull up-to-date information from their favorite apps and websites. To make it easier for websites to offer their content as Live Tiles, Microsoft had a feature available on a subdomain of a separate domain, i.e., “notifications.buildmypinnedsite.com,” that allowed website admins to automatically convert their RSS feeds into a special XML format and use it as a meta tag on their websites. The service, which Microsoft had already shut down, was hosted on its own Azure Cloud platform with the subdomain bound/set to an Azure account operated by the company. However, now it turns out that even after disabling the RSS-to-XML converter service, the company forgot to delete nameserver entries, leaving the unclaimed subdomain still pointing to the Azure servers. Hanno Böck, who discovered this issue, seized this opportunity to exploit the weakness and reclaimed the same subdomain using a newly created account on Azure. Apparently, the indirect control over Microsoft’s subdomain made it possible for him to push arbitrary content or notifications on Windows Live Tiles of various app or websites that are still using meta tags generated by the disabled service. “With an ordinary Azure account, we were able to register that subdomain and add the corresponding hostname. Thus we were able to control which content is served on that host,” Böck said. “Web pages that contain these meta tags should remove them or if they want to keep the functionality, create the appropriate XML files themselves.” This technique is usually known as “subdomain takeover,” an important attack vector that can usually be found in the way most online services allow their users to run web apps or blogs with a custom domain name. For example, when you create an app on Azure and wants to make it available on the Internet with a custom domain name, the platform asks users to point their domain’s nameserver to Azure and then claim it within their account’s dashboard. Since Microsoft Azure does not have a mechanism to verify if the account claiming a domain really owns it, any Azure user can claim any unclaimed domain (or left unattended) that have nameservers pointing to the cloud service. “We have informed about this problem but have not received it yet,” Böck said. “Once we cancel the subdomain a bad actor could register it and abuse it for malicious attacks.” Google’s Blogger service also had a similar issue, which the company patched a few years ago by making it mandatory for every blog owner to set a separate, unique TXT record for their custom domains in order to verify the claim. Though it seems Microsoft has now secured its subdomain by removing the nameservers, The Hacker News reached out to Microsoft to learn if the company has any plans to fix the “subdomain takeover” issue in its Azure cloud service platform that could eventually affect other domain users as well. We will update this report when we hear back.
I’m not a huge fan of stories about stories, or those that explore the ins and outs of reporting a breach. But occasionally I feel obligated to publish such accounts when companies respond to a breach report in such a way that it’s crystal clear they wouldn’t know what to do with a data breach if it bit them in the nose, let alone festered unmolested in some dark corner of their operations. And yet, here I am again writing the second story this week about a possibly serious security breach at an Indian company that provides IT support and outsourcing for a ridiculous number of major U.S. corporations (spoiler alert: the second half of this story actually contains quite a bit of news about the breach investigation). On Monday, KrebsOnSecurity broke the news that multiple sources were reporting a cybersecurity breach at Wipro, the third-largest IT services provider in India and a major trusted vendor of IT outsourcing for U.S. companies. The story cited reports from multiple anonymous sources who said Wipro’s trusted networks and systems were being used to launch cyberattacks against the company’s customers. Wipro asked for several days to investigate the request and formulate a public comment. Three days after I reached out, the quote I ultimately got from them didn’t acknowledge any of the concerns raised by my sources. Nor did the statement even acknowledge a security incident. Six hours after my story ran saying Wipro was in the throes of responding to a breach, the company was quoted in an Indian daily newspaper acknowledging a phishing incident. The company’s statement claimed its sophisticated systems detected the breach internally and identified the affected employees, and that it had hired an outside digital forensics firm to investigate further. Less than 24 hours after my story ran, Wipro executives were asked on a quarterly investor conference call to respond to my reporting. Wipro Chief Operating Officer Bhanu Ballapuram told investors that many of the details in my story were in error, and implied that the breach was limited to a few employees who got phished. The matter was characterized as handled, and other journalists on the call moved on to different topics. At this point, I added a question to the queue on the earnings conference call and was afforded the opportunity to ask Wipro’s executives what portion(s) of my story was inaccurate. A Wipro executive then proceeded to read bits of a written statement about their response to the incident, and the company’s chief operating officer agreed to have a one-on-one call with KrebsOnSecurity to address the stated grievances about my story. Security reporter Graham Cluley was kind enough to record that bit of the call and post it on Twitter. In the follow-up call with Wipro, Ballapuram took issue with my characterization that the breach had lasted “months,” saying it had only been a matter of weeks since employees at the company had been successfully phished by the attackers. I then asked when the company believed the phishing attacks began, and Ballapuram said he could not confirm the approximate start date of the attacks beyond “weeks.” Ballapuram also claimed that his corporation was hit by a “zero-day” attack. Actual zero-day vulnerabilities involve somewhat infrequent and quite dangerous weaknesses in software and/or hardware that not even the maker of the product in question understands before the vulnerability is discovered and exploited by attackers for private gain. Because zero-day flaws usually refer to software that is widely in use, it’s generally considered good form if one experiences such an attack to share any available details with the rest of the world about how the attack appears to work — in much the same way you might hope a sick patient suffering from some unknown, highly infectious disease might nonetheless choose to help doctors diagnose how the infection could have been caught and spread. Wipro has so far ignored specific questions about the supposed zero-day, other than to say “based on our interim investigation, we have shared the relevant information of the zero-day with our AV [antivirus] provider and they have released the necessary signatures for us.” My guess is that what Wipro means by “zero-day” is a malicious email attachment that went undetected by all commercial antivirus tools before it infected Wipro employee systems with malware. Ballapuram added that Wipro has gathered and disseminated to affected clients a set of “indicators of compromise,” telltale clues about tactics, tools and procedures used by the bad guys that might signify an attempted or successful intrusion. Hours after that call with Ballapuram, I heard from a major U.S. company that is partnering with Wipro (at least for now). The source said his employer opted to sever all online access to Wipro employees within days of discovering that these Wipro accounts were being used to target his company’s operations. The source said the indicators of compromise that Wipro shared with its customers came from a Wipro customer who was targeted by the attackers, but that Wipro was sending those indicators to customers as if they were something Wipro’s security team had put together on its own. So let’s recap Wipro’s public response so far: -Ignore reporter’s questions for days and then pick nits in his story during a public investor conference call. -Question the stated timing of breach, but refuse to provide an alternative timeline. -Downplay the severity of the incident and characterize it as handled, even when they’ve only just hired an outside forensics firm. -Say the intruders deployed a “zero-day attack,” and then refuse to discuss details of said zero-day. -Claim the IoCs you’re sharing with affected clients were discovered by you when they weren’t. WHAT DID THE ATTACKERS DO? The criminals responsible for breaching Wipro appear to be after anything they can turn into cash fairly quickly. A source I spoke with at a large retailer and Wipro customer said the crooks who broke into Wipro used their access to perpetrate gift card fraud at the retailer’s stores. I suppose that’s something of a silver lining for Wipro at least, if not also its customers: An intruder that was more focused on extracting intellectual property or other more strategic assets from Wipro’s customers probably could have gone undetected for a much longer period. A source close to the investigation who asked not to be identified because he was not authorized to speak to the news media said the company hired by Wipro to investigate the breach dated the first phishing attacks back to March 11, when a single employee was phished. The source said a subsequent phishing campaign between March 16 and 19 netted 22 additional Wipro employees, and that the vendor investigating the incident has so far discovered more than 100 Wipro endpoints that were seeded with ScreenConnect, a legitimate remote access tool sold by Connectwise.com. Investigators believe the intruders were using the ScreenConnect software on the hacked Wipro systems to connect remotely to Wipro client systems, which were then used to leverage further access into Wipro customer networks. Additionally, investigators found at least one of the compromised endpoints was attacked with Mimikatz, an open source tool that can dump passwords stored in the temporary memory cache of a Microsoft Windows device. The source also said the vendor is still discovering newly-hacked systems, suggesting that Wipro’s systems are still compromised, and that additional hacked endpoints may still be undiscovered within Wipro. Wipro has not yet responded to follow-up requests for comment. I’m sure there are smart, well-meaning and capable people who care about security and happen to work at Wipro, but I’m not convinced any of those individuals are employed in leadership roles at the company. Perhaps Wipro’s actions in the wake of this incident merely reflect the reality that India currently has no laws requiring data owners or processors to notify individuals in the event of a breach. Overall, I’m willing to chalk this entire episode up to a complete lack of training in how to deal with the news media, but if I were a customer of Wipro I’d be more than a little concerned about the tone-deaf nature of the company’s response thus far. As one follower on Twitter remarked, “openness and transparency speaks of integrity and a willingness to learn from mistakes. Doing the exact opposite smacks of something else entirely.” In the interests of openness, here are some indicators of compromise that Wipro customers are distributing about this incident (I had to get these from one of Wipro’s partners as the company declined to share the IoCs directly with KrebsOnSecurity).
A bug in a 30-year-old standard used for the exchange and storage of medical images has been uncovered; it allows an adversary to embed fully-functioning executable code into the image files captured by medical devices such as CT and MRI machines. This results in hybrid files that allow malware binaries to hide behind intact, standards-compliant images that preserve the original patient data – as such, they can be used and shared by clinicians without arousing suspicion. “By exploiting this design flaw attackers can take advantage of the abundance and centralization of DICOM imagery within healthcare organizations to increase stealth and more easily distribute their malware, setting the stage for potential evasion techniques and multi-stage attacks,” said Markel Picado Ortiz at Cylera Labs, who found the bug, in an analysis this week. Further, according to Ortiz, by mixing in with protected health information malware can effectively exploit the data’s clinical and regulatory implications to evade detection. Because of stringent privacy regulations in HIPAA regulations, medical device manufacturers and healthcare organizations often configure anti-malware software to ignore medical imagery and files containing protected health information. The Bug Ortiz said that the vulnerability, which he has a proof-of-concept exploit for, exists in DICOM, which is a global and ubiquitous imaging standard within the healthcare industry, originally drafted by National Electrical Manufacturers Association (NEMA). It defines a file format for the representation and storage of medical imagery and a communication protocol for the transmission of imagery over a network. The DICOM standard is used by the systems that produce imagery, specialized workstations for analyzing scan results, and even phones and tablets used to view diagnostic information. Digging deeper, the DICOM file format standard has a header with a 128-byte section at the beginning of the file, called the Preamble, that can be used to facilitate access to the images and metadata within the DICOM image. A third party can use the Preamble to enable compatibility with DICOM-unaware applications that expect common image formats; i.e., by design, the standard allows a third party to control the sequence of bytes within the Preamble, crafting it to trick image viewers into believing a DICOM file is actually another image format that would be compatible with them. This however can have unintended consequences: “While the DICOM standard intends for the field to be used to enable compatibility with non-DICOM image viewers, such as JPG and TIFF images, the standard does not impose any structural requirements on the data inserted into the Preamble,” explained Ortiz. “Any arbitrary sequence of 128 or fewer bytes can be inserted without jeopardizing the image file’s conformance with the DICOM standard.” Thus, this “feature” can be abused by attackers to fully embed a functioning executable into a DICOM image, while preserving the ability of the file to both be executed by the operating system, as any other executable would, as well as act as a standards-compliant DICOM image file. Exploitation In the PoCs, Ortiz shows that to execute commands on remote hosts, an attacker would need to have valid Active Directory credentials or permissions. “In many networks, however, it is common to have shared credentials for devices, a weakness that has been exploited in cases such as the Kwampirs campaigns by the Orangeworm Group that targeted healthcare organizations,” he noted. A local attacker with access to the healthcare network could also locate and tamper with an image, then execute it on the network to start the attack process. In both cases, it’s possible to create an attack that uses worm-like self-propagation to spread through the network, as he demonstrates in the PoC. Consequences The implications of this new attack vector are myriad, Ortiz points out, including consequences on the evasion, propagation and persistence fronts. “This enables new and existing malware to evolve into more potent variants, optimized for successful compromise of healthcare organizations, by using the infected patient data to hide, protect and spread itself – three of the primary functions that determine the effectiveness of a malware campaign,” Ortiz noted. When it comes to evasion, the file will not exhibit any artifact “.exe” files; the altered DICOM images will retain their “.dcm” file extensions. And, when an analyst inspects the file, it will open the original DICOM image and display the clinical information as it would pre-infection. The flaw also enables evasion of A/V software in addition to human analysts and system administrators because of the aforementioned HIPAA-aware configurations of most of these solutions being used in healthcare settings. In terms of propagation, the approach allows malware to be used as part of a multi-stage attack by making use of the transfer of DICOM imagery. “Imaging results are not only shared within a single organization but between organizations with overlap in patients treated,” Ortiz explained. “Patients will sometimes seek specialists who are experts in particular domains that are not handled by their local healthcare organization. Infected records could be transferred to the new organization as part of a consultation, thereby spreading infected DICOM files not only between departments within an organization, but across organizational boundaries and into completely unrelated healthcare organizations. The malware effectively “follows” the patient from organization to organization.” Also, central repositories of DICOM files provide a single infection point that could proliferate the malware-infected image to a large number of clinical devices as patient information is pulled during the course of patient diagnosis and treatment. And finally, when it comes to persistence in the face of remediation attempts, the malware is essentially fused to legitimate imaging files. As such, incident response teams and A/V software cannot delete the malware file as it contains protected patient health information. They also cannot deny access to the retrieval and viewing of the file in order to contain the malware without the risk that they will impede clinical operations. Conversely, response teams that are unaware the file contains patient information could potentially destroy patient information in the mitigation process. “Response teams and A/V software that are aware the file contains patient information are left in a difficult situation where they must balance cybersecurity, clinical and regulatory risk as they respond to malware that is effectively using patient data as a shield,” Ortiz said. He added, “[These] files are not only exploiting a vulnerability in a file format, but an unfixable vulnerability in healthcare data regulation as well. If this flaw was instead in a file format for images that were not protected by HIPAA, it would not be as technically effective. This is the first vulnerability whose technical potency is derived from a regulatory environment in addition to a software design flaw.” Mitigations Fixing the issue is not an easy one. In the long-term, a modification to the DICOM file format specification is ideal, but that’s sure to be an extensive effort. “DICOM has become ubiquitous within healthcare,” Ortiz said. “The number of systems supporting DICOM is innumerably large. There is no single vendor that can provide a patch and no single action that can be taken to fix the root cause of the issue across all systems using DICOM. Any change to the specification must be carefully considered to preserve interoperability between systems that may be designed to different versions of the specification before software vendors even begin to upgrade their own implementations.” Thus, in the short term, healthcare organizations should fortify existing systems with network segregation, changing default credentials, and by implementing mechanisms to detect abuse. They also should proactively create processes for “appropriately responding to and mitigating attacks exploiting this flaw,” according to Ortiz – that means having a way to analyze the Preamble and wipe it clean, if necessary. Don’t miss our free Threatpost webinar, “Data Security in the Cloud,” on April 24 at 2 p.m. ET. A panel of experts will join Threatpost senior editor Tara Seals to discuss how to lock down data when the traditional network perimeter is no longer in place. They will discuss how the adoption of cloud services presents new security challenges, including ideas and best practices for locking down this new architecture; whether managed or in-house security is the way to go; and ancillary dimensions, like SD-WAN and IaaS.
On the heels of reports that Facebook leveraged its users’ data in its relationships with other companies, researchers say that the tech space needs to re-assess the value of data as it relates to user privacy measures. However, they also said that users need to take steps themselves to safeguard their data. A Tuesday NBC News report, detailing 4,000 newly-leaked Facebook emails, webchats, spreadsheets and meeting summaries from 2011 to 2015, found that Facebook has been using its user data as leverage in various relationships with other companies. That included rewarding some firms with extended user data access after they spent money advertising on its platform; as well as withholding user data from other companies that posed a competitive threat to the social media firm. Researchers, for their part, said they aren’t surprised by this latest Facebook faux pas – but stressed that top tech firms need to re-evaluate the meaning of responsibly collecting and sharing data, and that user consent needs to be highlighted and prioritized in the future. “Facebook is a company built on consuming customer data, and it’s no surprise that they’ve looked for ways to monetize that most valuable asset,” said Tim Erlin, vice president of product management and strategy at Tripwire, via email. He added that this begs the questions: “Should we be outraged that they’re selling our data, that they’re giving it to preferred partners unfairly, or that they’re talking about privacy publicly while behaving in opposition to that narrative?” NBC News’ report reveals just how valuable user data is for companies looking to strike deals or solidify relationships. In one example, the report showed that Facebook extended Amazon’s access to user data after the company spent money on advertising and partnered with it for the launch of the Fire phone. Another document showed Facebook officials pondering cutting data access from a messaging app that had become a rival. But researchers said they aren’t shocked by the findings given Facebook’s track record when it comes to sharing data access to other companies since its Cambridge Analytica scandal in March 2018 first brought data sharing to the forefront. “The only surprise here is that anyone is surprised by this,” Paul Bischoff, privacy advocate with Comparitech.com, told Threatpost. “Facebook’s primary source of income is advertising, and online advertising relies heavily on user data. Facebook profits from its user’s personal data, who in return get to use the social network for free. The issue is not whether Facebook shared or sold user data, but whether it got proper consent to do so from users.” Stephen Cox, vice president and chief security architect at SecureAuth, told Threatpost that the explosion of data has spiraled out of control; and at this point, organizations need to begin limiting the number of people that have access to it. “When data is collected, it must be used responsibly,” he said. “Developers, marketing employees and executives want to collect as much data as possible because it can used to improve user experience, but once collected data is often analyzed, shared, sold or used at a company’s discretion.” That type of responsibility when it comes to collecting and sharing data has seemed to evade Facebook: as recently as December, the social media giant acknowledged that it had struck broad data-sharing partnerships with more than 150 companies, including Apple, Amazon and Netflix, exempting them from its normal data privacy terms and conditions. Also in December, internal documents showed the social media giant promoting – and trying to keep secret – the collection of call logs and texts for Android app users; and the Italian Competition Authority (ICA) found that Facebook violated several articles of the statute by misleading consumers about how their data would be used (The company was hit with two fines in response). This most recent report may just be more of the same type of data-sharing behavior by Facebook, but researchers said that, moving forward, users also have responsibility for taking note of what kind of data is being collected by the social-media company when Facebook and apps on the platform ask for permissions to collect data. “There’s a special kind of cognitive dissonance that occurs with Facebook users, where we implicitly understand that we’re providing value to Facebook through our personal data, but simultaneously fail to grasp the privacy implications of doing so,” said Erlin. “It’s unclear what it will take for users to change their perception of Facebook in this regard.” In the very least, data privacy is at the forefront of the conversation within the government: When Facebook CEO Mark Zuckerberg appeared before Congress in April 2018, for instance, politicians stressed the need for regulation to secure end users’ data privacy on social-media platforms. Currently, a Federal Trade Commission consent decree from 2011 requires the social network to receive explicit permission from users in regards to sharing their data with third parties. The FTC in March announced it is launching an investigation into Facebook’s data-privacy practices after the Cambridge Analytica scandal. Facebook could rack up fines totaling $40,000 per violation if found guilty. But in the meantime, Facebook and other data-chugging platforms continue to post a privacy and security risk to their users until the conversation about responsibly maintaining data is had, said Cox: “The more people who have access to data that is available, the more likely that bad actors will obtain it through a data breach, or that it will be used improperly,” he said. “Less data collected will reduce the threat surface – and reduce abuse.” Don’t miss our free Threatpost webinar, “Data Security in the Cloud,” on April 24 at 2 p.m. ET. A panel of experts will join Threatpost senior editor Tara Seals to discuss how to lock down data when the traditional network perimeter is no longer in place. They will discuss how the adoption of cloud services presents new security challenges, including ideas and best practices for locking down this new architecture; whether managed or in-house security is the way to go; and ancillary dimensions, like SD-WAN and IaaS.
A newly-discovered state-sponsored campaign is targeting national security organizations across the Middle East and North Africa (MENA) – and elsewhere – with domain name system (DNS) hijacking attacks, used to scoop up credentials. The campaign, dubbed “Sea Turtle” by the Cisco Talos researchers who discovered it, began as early as January 2017 and has continued through the first quarter of 2019. At least 40 different organizations across 13 various countries have been compromised so far by the campaign; in addition to the MENA victims, secondary targets, including telecom firms, ISPs and DNS registrars are being targeted in the U.S. and Sweden. Researchers in a Wednesday analysis said that the attackers behind the campaign have the capabilities and sophistication to grow: “While this incident is limited to targeting primarily national security organizations in the Middle East and North Africa, and we do not want to overstate the consequences of this specific campaign, we are concerned that the success of this operation will lead to actors more broadly attacking the global DNS system,” they said. The Campaign The campaigns have been utilizing DNS hijacking attacks, a type of attack where an individual redirects traffic meant to go to a legitimate website to a malicious server — meaning that they could easily harvest website credentials and other sensitive data that users are sharing with web forms and the like. Since 2017, more than 40 firms have been compromised by the Sea Turtle attacks – including national security organizations, ministries of foreign affairs and prominent energy organizations; and telecom firms, internet service providers (ISPs) and DNS registrars. That includes companies like consulting firm Cafax and DNS registry NetNod, which have both released public statements on the attacks. In addition to these types of targets, researchers said the campaign represents the first known case of a domain name registry organization that was compromised for cyber-espionage operations. A domain name registry manages different parts of the domain registry, such as country code top-level domains and generic top-level domains. Compromising a domain name registry allows attackers to access the DNS logs, and highlights the sophistication of the attackers, researchers said. The campaign has been “highly successful,” researchers said, in part because the attacker employed DNS hijacking and redirection attacks to access targeted networks, as traditional security products aren’t designed to monitor DNS requests, said researchers: “The threat actors were able to achieve this level of success because the DNS domain space system added security into the equation as an afterthought,” researchers said. The Attacks The attackers gained initial access either through spear-phishing emails or through exploiting known flaws. The phishing emails were aimed at registrants and used to gain their credentials. From there, the bad actors could access an organization’s DNS records with the registrant’s credentials. or by exploiting known vulnerabilities – including a PHP code injection flaw in phpMyAdmin (CVE-2009-1151), a remote code exploit for Cisco integrated service router 2811 (CVE-2017-6736) and the infamous “Drupalgeddon” remote code execution Drupal glitch (CVE-2018-7600). A list of impacted CVEs used by the attacker is below – but researchers say that they believe the list is incomplete and “the actor in question can leverage known vulnerabilities as they encounter a new threat surface.” Once they gained access to a network, an attacker would access the DNS registry and modify the name system records for targeted firms, pointing users to a malicious DNS server that provided actor-controlled responses to all DNS queries – allowing them to trick users to give them their credentials. “The amount of time that the targeted DNS record was hijacked can range from a couple of minutes to a couple of days,” researchers said. “This type of activity could give an attacker the ability to redirect any victim who queried for that particular domain around the world.” The threat actors also used an array of techniques to evade detection, researchers said. For instance, once users put their credentials into impersonated services, they would then be passed to the legitimate service, and couldn’t tell that anything was wrong. Attackers also used an interesting technique called certificate impersonation, where attackers stole a certificate authority-signed X.509 certificate from another provider for the same domain, imitating the one already used by the targeted organization – making the web browser seem more legitimate. Other Campaigns Researchers said that they assess with high confidence that the hijacking attacks are being launched by an advanced, state-sponsored actor looking to access sensitive networks and systems – but stayed mum on who exactly that actor was. “This is the first time Cisco Talos is documenting operations conducted by this threat actor,” Craig Williams, director of Talos Outreach at Cisco, told Threatpost. “While we assess with high confidence that this activity was carried out by an advanced, state-sponsored actor, we defer to law enforcement officials on establishing attribution.” DNS-based attacks are an increasing worry for governments and enterprises alike. DNS Hijack Attack Vector In January, the Department of Homeland Security is ordering all federal agencies to urgently audit DNS security for their domains in the next 10 business days. Also in January, a wave of DNS hijacking attacks targeting victims in North America, Europe, Middle East and North Africa were linked to Iran. The attacks, which were related to a campaign dubbed “DNSpionage” by Cisco Talos researchers, had a high degree of success harvesting targets’ credentials, according to the firm. However, Talos researchers said they assess with high confidence that the DNSpionage operations are “distinctly different and independent” from the Sea Turtle campaign. “The report assesses with high confidence that Sea Turtle operations are distinctly different and independent from DNSpionage operations,” Williams told Threatpost. “DNSpionage and Sea Turtle have a strong correlation in that they both use the DNS hijacking/re-direction methodologies to perform their attacks. However, both campaigns’ level of maturity and capability are distinctly different. Sea Turtle has a much more mature level of playbook by attacking their ancillary targets before shifting their focus to a specific set of Middle Eastern and African victims. Due to the closely related nature of the attacks, overlapping TTPs [tactics, techniques and procedures] are common, but our visibility makes it very clear these are two different groups.” To protect against these DNS hijacking attacks, Williams said that companies can implement a registry lock service, multi-factor authentication (to access DNS records), and of course staying up to date on patches, especially on internet-facing machines. However, “once these credentials are stolen, it is virtually impossible to completely shut down a campaign until the credentials are regained, changed and locked,” he told Threatpost. Don’t miss our free Threatpost webinar, “Data Security in the Cloud,” on April 24 at 2 p.m. ET. A panel of experts will join Threatpost senior editor Tara Seals to discuss how to lock down data when the traditional network perimeter is no longer in place. They will discuss how the adoption of cloud services presents new security challenges, including ideas and best practices for locking down this new architecture; whether managed or in-house security is the way to go; and ancillary dimensions, like SD-WAN and IaaS.
Our Standard Office Hours
Monday – Friday: 8:00AM – 5:00PM EDT
Saturday – Sunday: Closed
Where to Find Us
Data Privacy Notice
- – All product names, logos, and brands are property of their respective owners.
- – The use of these names, logos, and brands is for identification purposes only and does not imply endorsement.
- – Content syndication and aggregation of public information is solely for the purpose of identifying information security trends, all syndicated content contains source links to the content creator website. All content is owned by it’s respective content creators.
- – If you are an owner of some content and want it to be removed, please email email@example.com