image
Beware! If you have downloaded PHP PEAR package manager from its official website in past 6 months, we are sorry to say that your server might have been compromised. Last week, the maintainers at PEAR took down the official website of the PEAR (pear-php.net) after they found that someone has replaced original PHP PEAR package manager (go-pear.phar) with a modified version in the core PEAR file system. Though the PEAR developers are still in the process of analyzing the malicious package, a security announcement published on January 19, 2019, confirmed that the allegedly hacked website had been serving the installation file contaminated with the malicious code to download for at least half a year. The PHP Extension and Application Repository (PEAR) is a community-driven framework and distribution system that offers anyone to search and download free libraries written in PHP programming language. These open-source libraries (better known as packages) allows developers to easily include additional functionalities into their projects and websites, including authentication, caching, encryption, web services, and many more. When you download PHP software for Unix/Linux/BSD systems, PEAR download manager (go-pear.phar) comes pre-installed, whereas Windows and Mac OS X users need to install the component when required manually. Since many web hosting companies, including shared hosting providers, also allow their users to install and run PEAR, this latest security breach could impact a large number of websites and their visitors. “If you have downloaded this go-pear.phar in the past six months, you should get a new copy of the same release version from GitHub (pear/pearweb_phars) and compare file hashes. If different, you may have the infected file,” the note on the official PEAR website reads. According to the PEAR maintainers, the team is currently performing a forensic investigation to determine what is the extent of the attack and how the attackers managed to compromise the server in the first place. A new clean version 1.10.10 of pearweb_phars is now available on Github, which “re-releases the correct ‘go-pear.phar' as v1.10.9, the file that was found tainted on the ‘http://pear.php.net' server, and now includes separate GPG signature files with each ‘phar.” The developers further notified that only the copy on the pear.php.net server was impacted, to their knowledge, and that the GitHub copy of go-pear.phar is not compromised. Since the PEAR officials have just put out a warning notification and not released any details about the security incident, it is still unclear that who is behind the attack. The developers tweeted that they will publish a “more detailed announcement” on the PEAR Blog once it's back online. All PHP/PEAR users who have downloaded the installation file go-pear.phar from the official website in the past six months should consider themselves compromised and quickly download and install the Github version. UPDATE — The PEAR team has published more details about the recent security incident, explaining the tainted “go-pear.phar” found on its server appeared to be planted after the last official file release on 20 December 2018. After analyzing the tainted version of the package manager, the team found that the malicious module “spawn a reverse shell via Perl to IP 104.131.154.154” from the infected servers, allowing attackers to take complete control over them, including the ability to install apps, run malicious code, and steal sensitive data. According to the DCSO, a German cybersecurity organization who also analyzed the tainted code, the server IP address 104.131.154.154 points to a web domain bestlinuxgames[.]com, which it believes was a compromised host used by the attackers. “This IP has been reported to its host in relation to the taint. No other breach was identified. The install-pear-nozlib.phar was ok. The go-pear.phar file at GitHub was ok, and could be used as a good md5sum comparison for any suspect copies,” PEAR team said in a series of tweets. “So, if you downloaded go-pear.phar since 12/20 in order to run it once to install the PEAR package on your system, you should be concerned, particularly if your system has ‘sh' and ‘perl' available.” “If you downloaded go-pear.phar before 12/20, we have no concrete evidence you received an infected file… but it would be prudent to check your system if you used go-pear.phar to perform a PEAR installation in the last several months.” “Also note that this does not affect the PEAR installer package itself… it affects the go-pear.phar executable that you would use to initially install the PEAR installer. Using the ‘pear' command to install various PEAR package is not affected.” Have something to say about this article? Comment below or share it with us on Facebook, Twitter or our LinkedIn Group.

Source

Beware! If you have downloaded PHP PEAR package manager from its official website in past 6 months, we are sorry to say that your server might have been compromised.

Last week, the maintainers at PEAR took down the official website of the PEAR (pear-php.net) after they found that someone has replaced original PHP PEAR package manager (go-pear.phar) with a modified version in the core PEAR file

Source

image
The U.S. Department of Homeland Security (DHS) has today issued an “emergency directive” to all federal agencies ordering IT staff to audit DNS records for their respective website domains, or other agency-managed domains, within next 10 business days. The emergency security alert came in the wake of a series of recent incidents involving DNS hijacking, which security researchers with “moderate confidence” believe originated from Iran. Domain Name System (DNS) is a key function of the Internet that works as an Internet's directory where your device looks up for the server IP addresses after you enter a human-readable web address (e.g., thehackernews.com). What is DNS Hijacking Attack? DNS hijacking involves changing DNS settings of a domain, redirecting victims to an entirely different attacker-controlled server with a fake version of the websites they are trying to visit, often with an objective to steal users' data. “The attacker alters DNS records, like Address (A), Mail Exchanger (MX), or Name Server (NS) records, replacing the legitimate address of a service with an address the attacker controls,” the DHS advisory reads. The threat actors have been able to do so by capturing credentials for admin accounts that can make changes to DNS records. Since the attackers obtain valid certificates for the hijacked domain names, having HTTPS enabled will not protect users. “Because the attacker can set DNS record values, they can also obtain valid encryption certificates for an organization's domain names. This allows the redirected traffic to be decrypted, exposing any user-submitted data,” the directive reads. Recent DNS Hijacking Attacks Against Government Websites Earlier this month, security researchers from Mandiant FireEye reported a series of DNS hijacking incidents against dozens of domains belonging to the government, internet infrastructure, and telecommunications entities across the Middle East and North Africa, Europe and North America. The DHS advisory also states that the “CISA is aware of multiple executive branch agency domains that were impacted by the tampering campaign and has notified the agencies that maintain them.” At the end of last year, researchers at Cisco Talos also published a report of a sophisticated malware attack that compromised domain registrar accounts for several Lebanon and the United Arab Emirates (UAE) government and public sector websites. DHS Orders Federal Agencies to Audit DNS Security for Their Domains The DHS orders federal agencies to: audit public DNS records and secondary DNS servers for unauthorized edits, update their passwords for all accounts on systems that can be used to tamper DNS records, enable multi-factor authentication to prevent any unauthorized change to their domains, and monitor certificate transparency logs. For those unaware, Certificate Transparency (CT) is a public service that allows individuals and companies to monitor how many digital certificates have been issued by any certificate authority secretly for their domains. The Cyber Hygiene service of the DHS's Cybersecurity and Infrastructure Security Agency (CISA) will also begin a regular delivery of newly added certificates to CT log for US federal agency domains. Once the CISA starts distributing these logs, government agencies are required to immediately begin monitoring their CT log data for issued certificates that they did not request. If any agency found any unauthorized certificate, it must be reported to the issuing certificate authority and the CISA. Agencies, except the Department of Defense, the Central Intelligence Agency (CIA) and the Office of the Director of National Intelligence, have 10 days to implement the directives.

Source

The U.S. Department of Homeland Security (DHS) has today issued an “emergency directive” to all federal agencies ordering IT staff to audit DNS records for their respective website domains, or other agency-managed domains, within next 10 business days.

The emergency security alert came in the wake of a series of recent incidents involving DNS hijacking, which security researchers with “

Source

image
Three unfixed Microsoft Windows vulnerabilities have been assigned unofficial, temporary micropatches – including a recently-disclosed high-severity remote code-execution flaw. The micropatches were released Tuesday by ACROS Security’s 0patch platform. 0patch, which is still in its beta stage, applies temporary micropatches for product vulnerabilities that have not yet been assigned a fix. One of the micropatches addresses a high-severity Windows flaw that enables arbitrary remote code-execution. The vulnerability was disclosed by Zero Day Initiative researcher John Page on Jan. 10 in a coordinated public release. However, Microsoft has not yet issued a patch for the flaw, which ranks 7.8 on the CVSS scale. “Microsoft has a customer commitment to investigate reported security issues, and proactively update impacted devices as soon as possible,” a Microsoft spokesperson told Threatpost. “Our standard policy is to provide solutions via our current Update Tuesday schedule.” Windows Flaw According to ZDI’s release, “this vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Microsoft Windows. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.” The flaw exists in the way that VCF and CONTACT files process data. VCF and CONTACT files are associated with the Windows Contacts application, which allows users to import contacts. Users can navigate their Contacts folder and select a VCF contacts file (also known as vCard) they would like to import. The way these Windows files craft and process data can allow them to display a dangerous hyperlink. The flaw allows an attacker to run executables that sit unseen in the attackers’ directory. An attacker is able to run an executable file when certain “.contact” of VCF files are processed. However, it’s not a quick or simple exploit to maneuver: The attacker would need to get the user to open a malicious VCF or CONTACT file and click on the displayed dangerous link, which would then launch the attacker’s executable. “An attacker can leverage this vulnerability to execute code in the context of the current user,” according to ZDI’s release. A micropatch has been released for fully updated 64-bit Windows 10 version 1803 and fully updated 64-bit Windows 7. In order to protect against the flaw, the micropatch blocks certain command that launches potential executables when a URL containing malicious executables are clicked on by potential victims: “We simply added some logic before this call to make sure that if the URL doesn’t start with “mailto:”, “http://” or “https://”, it gets prepended with “http://” to prevent any possible launching of local executables,” said Mitja Kolsek, with 0patch, in his detailing of the micropatch. According to ZDI, Microsoft advised researchers that its “engineering team had decided to pursue the fix as v.Next,” and, “Microsoft has decided that it will not be fixing this vulnerability and we are closing this case.” Other Micropatches The other two vulnerabilities addressed by 0patch were published by a researcher who goes by SandboxEscaper on Twitter, who has disclosed several zero-day vulnerabilities over the past few months. One of the flaws, which SandboxEscaper dubbed “angrypolarberbug,” allows a local unprivileged process to get any chosen file on the system overwritten. The flaw, which does not yet have a CVE, stems from the fact that a Windows Error Reporting Service can create a temporary XML file (C:ProgramDataMicrosoftWindowsWERTemp folder). This folder has inheritable permissions that include read, write and delete access for authenticated users (including a local attacker). That means that a bad actor could theoretically create a new XML file containing a low-privileged malicious process and would be able to execute that file under higher privileges, said 0patch. “The attacker has very little control over the content of this XML file, so the demonstration provided by SandboxEscaper was a local denial of service by corrupting a critical system file pci.sys, which prevents the system from booting,” Kolsek said. “One can imagine potentially finding some other file to overwrite that would lead to execution of attacker’s code under higher privileges such as SYSTEM or Administrator — but to our knowledge, such example has not been published.” The micropatch makes a small change by having the Windows Error Reporting Service creating the XML file specify permissions. The other micropatch addresses another flaw released by SandboxEscaper. The vulnerability allows an unprivileged process running on a Windows computer to obtain the content of arbitrary file – even if permissions on such file don’t allow it read access. The flaw exists in Windows Installer’s advertisement functionality, which can be triggered using the MsiAdvertiseProduct function. When a product is advertised, Windows Installer makes a temporary copy file for this product – but that temporary file gives bad actors potential permissions to read the content on it. However, “Due to file permissions on the temporary MSI file, which allow everyone read access, an attacker can thus trick the Windows Installer Service to copy the content of arbitrary file to the temporary MSI file, and then read that file to obtain said content,” according to Kolsek. The micropatch tweaks the development of these temporary files so that the permissions on the temporary MSI file are the same as on the file being copied, and “the attacker gains nothing from this process.”

Source

image
A custom malware used by the APT known as DarkHydrus uses a mix of novel techniques, including using Google Drive as an alternate command-and-control (C2) channel. According to Palo Alto’s Unit 42 intelligence division, the targeted attack involved spear-phishing emails written in Arabic sent to targeted organizations with macro-enabled Excel documents with .xlsm file extensions. Once executed, it fetches a custom payload dubbed RogueRobin; the malware has previously been seen in a PowerShell-based form, while this campaign uses a new form of the malware written in C+. “RogueRobin is a fully featured backdoor that can provide a variety of functionality to the threat actors,” said Bryan Lee, principal researcher at Palo Alto Networks, speaking to Threatpost. “It specifically allows the DarkHydrus operators to remotely execute PowerShell scripts, meaning they would be able to not only take advantage of any features within the scope of PowerShell, but also add functionality as desired by generating new scripts.” He added that it also has the ability to upload and download arbitrary files from the victim host which can further enhance the threat actors’ ability to add functionality to RogueRobin in addition to being able to exfiltrate data. Before carrying out any of its functionality, the payload checks to see if it is executing in a sandbox by using WMI queries and checks running processes. If the payload determines it is not running in a sandbox, it will attempt to install itself to the system to persistently execute. After providing system specific information, the payload will interact with the C2 server to obtain commands, which the payload refers to as jobs. The payload itself communicates with its C2 servers using a custom DNS tunneling protocol. “The DNS tunneling protocol can use multiple different DNS query types to interact with the C2 server,” researchers explained in a posting last week. “The payload has a function it calls early on that tests to see which DNS query types are able to successfully reach the C2 server. It iterates through a list of types and the first DNS type to receive a response from the C2 server will be used for all communications between the payload and the C2 server…the payload will look for different responses to…outbound queries depending on the type of DNS request that the payload uses to communicate with the C2.” Interestingly, the malware can establish an alternative C2 channel that uses the Google Drive API. This command is disabled by default, but when enabled via a command received from the DNS tunneling channel, it allows RogueRobin to receive a unique identifier and to get jobs by using Google Drive API requests. “In [this mode], RogueRobin uploads a file to the Google Drive account and continually checks the file’s modification time to see if the actor has made any changes to it,” said the researchers. “The actor will first modify the file to include a unique identifier that the trojan will use for future communications. The trojan will treat all subsequent changes to the file made by the actor as jobs and will treat them as commands.” While this isn’t a new tactic, it’s not common either, according to Lee. “Using legitimate services as C2s may be more effective for the adversary as it may be impossible for an organization to outright block the legitimate service, in addition to potentially being able to ‘hide in plain sight.’ since the activity would appear to be legitimate on the surface,” he told us.

Source

image
Two of the most disruptive and widely-received spam email campaigns over the past few months — including an ongoing sextortion email scam and a bomb threat hoax that shut down dozens of schools, businesses and government buildings late last year — were made possible thanks to an authentication weakness at GoDaddy.com, the world's largest domain name registrar, KrebsOnSecurity has learned. Perhaps more worryingly, experts warn this same weakness that let spammers hijack domains tied to GoDaddy also affects a great many other major Internet service providers, and is actively being abused to launch phishing and malware attacks which leverage dormant Web site names currently owned and controlled by some of the world's most trusted corporate names and brands. In July 2018, email users around the world began complaining of receiving spam which began with a password the recipient used at some point in the past and threatened to release embarrassing videos of the recipient unless a bitcoin ransom was paid. On December 13, 2018, a similarly large spam campaign was blasted out, threatening that someone had planted bombs within the recipient’s building that would be detonated unless a hefty bitcoin ransom was paid by the end of the business day. Experts at Cisco Talos and other security firms quickly drew parallels between the two mass spam campaigns, pointing to a significant overlap in Russia-based Internet addresses used to send the junk emails. Yet one aspect of these seemingly related campaigns that has been largely overlooked is the degree to which each achieved an unusually high rate of delivery to recipients. Large-scale spam campaigns often are conducted using newly-registered or hacked email addresses, and/or throwaway domains. The trouble is, spam sent from these assets is trivial to block because anti-spam and security systems tend to discard or mark as spam any messages that appear to come from addresses which have no known history or reputation attached to them. However, in both the sextortion and bomb threat spam campaigns, the vast majority of the email was being sent through Web site names that had already existed for some time, and indeed even had a trusted reputation. Not only that, new research shows _many of these domains were registered long ago and are still owned by dozens of Fortune 500 and Fortune 1000 companies. _ That's according to Ron Guilmette, a dogged anti-spam researcher. Researching the history and reputation of thousands of Web site names used in each of the extortionist spam campaigns, Guilmette made a startling discovery: Virtually all of them had at one time received service from GoDaddy.com, a Scottsdale, Ariz. based domain name registrar and hosting provider. Guilmette told KrebsOnSecurity he initially considered the possibility that GoDaddy had been hacked, or that thousands of the registrar's customers perhaps had their GoDaddy usernames and passwords stolen. But as he began digging deeper, Guilmette came to the conclusion that the spammers were exploiting an obscure — albeit widespread — weakness among hosting companies, cloud providers and domain registrars that was first publicly detailed in 2016. EARLY WARNING SIGNS In August 2016, security researcher Matthew Bryant wrote about a weakness that could be used to hijack email service for 20,000 established domain names at a U.S. based hosting provider. A few months later, Bryant warned that the same technique could be leveraged to send spam from more than 120,000 trusted domains across multiple providers. And Guilmette says he now believes the attack method detailed by Bryant also explains what's going on in the more recent sextortion and bomb threat spams. Grasping the true breadth of Bryant's prescient discovery requires a brief and simplified primer on how Web sites work. Your Web browser knows how to find a Web site name like example.com thanks to the global Domain Name System (DNS), which serves as a kind of phone book for the Internet by translating human-friendly Web site names (example.com) into numeric Internet address that are easier for computers to manage. When someone wants to register a domain at a registrar like GoDaddy, the registrar will typically provide two sets of DNS records that the customer then needs to assign to his domain. Those records are crucial because they allow Web browsers to figure out the Internet address of the hosting provider that's serving that Web site domain. Like many other registrars, GoDaddy lets new customers use their managed DNS services for free for a period of time (in GoDaddy's case it's 30 days), after which time customers must pay for the service. The crux of Bryant's discovery was that the spammers in those 2016 campaigns learned that countless hosting firms and registrars would allow anyone to add a domain to their account without ever validating that the person requesting the change actually owned the domain. Here's what Bryant wrote about the threat back in 2016: “In addition to the hijacked domains often having past history and a long age, they also have WHOIS information which points to real people unrelated to the person carrying out the attack. Now if an attacker launches a malware campaign using these domains, it will be harder to pinpoint who/what is carrying out the attack since the domains would all appear to be just regular domains with no observable pattern other than the fact that they all use cloud DNS. It's an attacker's dream, troublesome attribution and an endless number of names to use for malicious campaigns.” SAY WHAT? For a more concrete example of what's going on here, we'll look at just one of the 4,000+ domains that Guilmette found were used in the Dec. 13, 2018 bomb threat hoax. Virtualfirefox.com is a domain registered via GoDaddy in 2013 and currently owned by The Mozilla Corporation, a wholly owned subsidiary of the Mozilla Foundation — the makers of the popular Firefox Web browser. The domain's registration has been renewed each year since its inception, but the domain itself has sat dormant for some time. When it was initially set up, it took advantage of two managed DNS servers assigned to it by GoDaddy — ns17.domaincontrol.com, and ns18.domaincontrol.com. GoDaddy is a massive hosting provider, and it has more than 100 such DNS servers to serve the needs of its clients. To hijack this domain, the attackers in the December 2018 spam campaign needed only to have created a free account at GoDaddy that was assigned the exact same DNS servers handed out to Virtualfirefox.com (ns17.domaincontrol.com and ns18.domaincontrol.com). After that, the attackers simply claim ownership over the domain, and tell GoDaddy to allow the sending of email with that domain from an Internet address they control. Mozilla spokesperson Ellen Canale said Mozilla took ownership of virtualfirefox.com in September 2017 after a trademark dispute, but that the DNS nameserver for the record was not reset until January of 2019. “This oversight created a state where the DNS pointed to a server controlled by a third party, leaving it vulnerable to misuse,” Canale said. “We’ve reviewed the configuration of both our registrar and nameservers and have found no indication of misuse. In addition to addressing the immediate problem, we have reviewed the entire catalog of properties we own to ensure they are properly configured.” According to both Guilmette and Bryant, this type of hijack is possible because GoDaddy — like many other managed DNS providers — does little to check whether someone with an existing account (free or otherwise) who is claiming ownership over a given domain actually controls that domain name. Contacted by KrebsOnSecurity, GoDaddy acknowledged the authentication weakness documented by Guilmette. “After investigating the matter, our team confirmed that a threat actor(s) abused our DNS setup process,” the company said in an emailed statement. “We’ve identified a fix and are taking corrective action immediately,” the statement continued. “While those responsible were able to create DNS entries on dormant domains, at no time did account ownership change nor was customer information exposed.” SPAMMY BEAR Guilmette has dubbed the criminals responsible as “Spammy Bear” because the majority of the hijacked domains used in the spam campaigns traced back to Internet addresses in Russia. In the case of Mozilla's Virtualfirefox.com domain, historic DNS records archived by Farsight Security show that indeed on Dec. 13, 2018 — the very same day that spammers began blasting out their bomb threat demands — the Internet address in the domain's DNS records at GoDaddy were changed to 194.58.58[.]70, a server in the Russian Federation owned by a hosting company there called Reg.ru. The record above, indexed by Farsight Security, shows the DNS entries for virtualfirefox.com were changed to allow sending of email from an ISP in Russia on Dec. 13, 2018, the same day spammers used this domain and thousands of others for a mass emailed bomb threat. In fact, Guilmette found that that at least 3,500 of the commandeered domains traced back to Reg.ru and to a handful of other hosting firms in Russia. The next largest collection of fraudulently altered Internet addresses were assigned to hosting providers in the United States (456), although some of those providers (e.g. Webzilla/WZ Communications) have strong ties to Russia. The full list of Internet providers is available here. Guilmette's sleuthing on the 4,000+ domains abused in both 2018 spam campaigns, combined with data from Farsight, suggest the spammers hijacked domains belonging to a staggering number of recognizable corporations who used GoDaddy for DNS, including but not limited to: Abbott Laboratories; Ancestry.com; Autodesk; Capital One; CVS Pharmacy; SSL provider Digicert; Dow Chemical; credit card processors Elavon and Electronic Merchant Systems; Fair Isaac Corp.; Facebook; Gap (Apparel) Inc; Fifth Third Bancorp; Hearst Communications; Hilton Interntional; ING Bank; the Massachusetts Institute of Technology (MIT); McDonalds Corp.; NBC Universal Media; NRG Energy; Oath, Inc (a.k.a Yahoo + AOL); Oracle; Tesla Motors; Time Warner; US Bank; US Steel Corp.; National Association; Viacom International; and Walgreens. In an interview with KrebsOnSecurity, Bryant said the hijacking technique can be a powerful tool in the hands of spammers and scammers, who can use domains associated with these companies not only to get their missives past junk and malware filters, but also to make phishing and malware lures far more believable and effective. “This is extremely advantageous to attackers because they don't have to pay any money to set it all up, and there's a strong reputation attached to the domain they're sending from,” Bryant said. “A lot of services will flag email from unknown domains as high risk, but the domains being hijacked by these guys have a good history and reputation behind them. This method also probably greatly complicates any sort of investigatory efforts after the spam campaign is over.” WHAT CAN BE DONE? Guilmette said managed DNS providers can add an extra layer of validation to DNS change requests, checking to see if a given domain already has DNS servers assigned to the domain before processing the request. Providers could nullify the threat by simply choosing a different pair of DNS servers to assign to the request. The same validation process would work similarly at other managed DNS providers. “As long as they're different, that ruins this attack for the spammers,” Guilmette said. “The spammers want the DNS servers to be the same ones that were already there when the domain was first set up, because without that they can't pull of this hack. All GoDaddy has to do is see if this particularly odd set of circumstances apply in each request.” Bryant said after he published his initial research in 2016, a number of managed DNS providers mentioned in his blog posts said they'd taken steps to blunt the threat, including Amazon Web Services (AWS), hosting provider Digital Ocean, and Google Cloud. But he suspects this is still a “fairly common” weakness among hosting providers and registrars, and many providers simply aren't convinced of the need to add this extra precaution. “A lot of the providers are of the opinion that it's down to a user mistake and not a vulnerability they should have to fix,” he said. “But it's clearly still a big problem.” Update, 10:38 p.m.: An earlier version of this story stated that Guilmette had identified more than 5,000 domains associated with the Spammy Bear campaigns. The true number is closer to 4,000. The discrepancy was my mistake and due to a formatting error in a spreadsheet. Also added text to clarify that not all of the domains were registered through Godaddy, but that all of them at one point at least received managed DNS service from the company.

Source

Two of the most disruptive and widely-received spam email campaigns over the past few months — including an ongoing sextortion email scam and a bomb threat hoax that shut down dozens of schools, businesses and government buildings late last year — were made possible thanks to an authentication weakness at GoDaddy.com, the world’s largest domain name registrar, KrebsOnSecurity has learned.

Perhaps more worryingly, experts warn this same weakness that let spammers hijack domains registered through GoDaddy also affects a great many other major Internet service providers, and is actively being abused to launch phishing and malware attacks which leverage dormant Web site names currently owned and controlled by some of the world’s most trusted corporate names and brands.

In July 2018, email users around the world began complaining of receiving spam which began with a password the recipient used at some point in the past and threatened to release embarrassing videos of the recipient unless a bitcoin ransom was paid. On December 13, 2018, a similarly large spam campaign was blasted out, threatening that someone had planted bombs within the recipient’s building that would be detonated unless a hefty bitcoin ransom was paid by the end of the business day.

Experts at Cisco Talos and other security firms quickly drew parallels between the two mass spam campaigns, pointing to a significant overlap in Russia-based Internet addresses used to send the junk emails. Yet one aspect of these seemingly related campaigns that has been largely overlooked is the degree to which each achieved an unusually high rate of delivery to recipients.

Large-scale spam campaigns often are conducted using newly-registered or hacked email addresses, and/or throwaway domains. The trouble is, spam sent from these assets is trivial to block because anti-spam and security systems tend to discard or mark as spam any messages that appear to come from addresses which have no known history or reputation attached to them.

However, in both the sextortion and bomb threat spam campaigns, the vast majority of the email was being sent through Web site names that had already existed for some time, and indeed even had a trusted reputation. Not only that, new research shows many of these domains were registered long ago and are still owned by dozens of Fortune 500 and Fortune 1000 companies. 

That’s according to Ron Guilmette, a dogged anti-spam researcher who has made a living suing spammers and helping law enforcement officials apprehend online scammers. Researching the history and reputation of more than 5,000 Web site names used in each of the extortionist spam campaigns, Guilmette made a startling discovery: Virtually all of them had at one time been registered via GoDaddy.com, a Scottsdale, Ariz. based domain name registrar and hosting provider.

Guilmette told KrebsOnSecurity he initially considered the possibility that GoDaddy had been hacked, or that thousands of the registrar’s customers perhaps had their GoDaddy usernames and passwords stolen.

But as he began digging deeper, Guilmette came to the conclusion that the spammers were exploiting an obscure — albeit widespread — weakness among hosting companies, cloud providers and domain registrars that was first publicly detailed in 2016.

EARLY WARNING SIGNS

In August 2016, security researcher Matthew Bryant wrote about spammers hijacking some 20,000 established domain names to blast out junk email. A few months later, Bryant documented the same technique being used to take over more than 120,000 trusted domains for spam campaigns. And Guilmette says he now believes the attack method detailed by Bryant also explains what’s going on in the more recent sextortion and bomb threat spams.

Grasping the true breadth of Bryant’s prescient discovery requires a brief and simplified primer on how Web sites work. Your Web browser knows how to find a Web site name like example.com thanks to the global Domain Name System (DNS), which serves as a kind of phone book for the Internet by translating human-friendly Web site names (example.com) into numeric Internet address that are easier for computers to manage.

When someone wants to register a domain at a registrar like GoDaddy, the registrar will typically provide two sets of DNS records that the customer then needs to assign to his domain. Those records are crucial because they allow Web browsers to figure out the Internet address of the hosting provider that’s serving that Web site domain. Like many other registrars, GoDaddy lets new customers use their managed DNS services for free for a period of time (in GoDaddy’s case it’s 30 days), after which time customers must pay for the service.

The crux of Bryant’s discovery was that the spammers in those 2016 campaigns learned that countless hosting firms and registrars would allow anyone to add a domain to their account without ever validating that the person requesting the change actually owned the domain. Here’s what Bryant wrote about the threat back in 2016:

“In addition to the hijacked domains often having past history and a long age, they also have WHOIS information which points to real people unrelated to the person carrying out the attack. Now if an attacker launches a malware campaign using these domains, it will be harder to pinpoint who/what is carrying out the attack since the domains would all appear to be just regular domains with no observable pattern other than the fact that they all use cloud DNS. It’s an attacker’s dream, troublesome attribution and an endless number of names to use for malicious campaigns.”

SAY WHAT?

For a more concrete example of what’s going on here, we’ll look at just one of the 5,000+ domains that Guilmette found were used in the Dec. 13, 2018 bomb threat hoax. Virtualfirefox.com is a domain registered via GoDaddy in 2013 and currently owned by The Mozilla Corporation, a wholly owned subsidiary of the Mozilla Foundation — the makers of the popular Firefox Web browser.

The domain’s registration has been renewed each year since its inception, but the domain itself has sat dormant for some time. When it was initially set up, it took advantage of two managed DNS servers assigned to it by GoDaddy — ns17.domaincontrol.com, and ns18.domaincontrol.com.

GoDaddy is a massive hosting provider, and it has more than 100 such DNS servers to serve the needs of its clients. To hijack this domain, the attackers in the December 2018 spam campaign needed only to have created a free account at GoDaddy that was assigned the exact same DNS servers handed out to Virtualfirefox.com (ns17.domaincontrol.com and ns18.domaincontrol.com). After that, the attackers simply claim ownership over the domain, and tell GoDaddy to route all traffic for that domain to an Internet address they control.

Mozilla spokesperson Ellen Canale said Mozilla took ownership of virtualfirefox.com in September 2017 after a trademark dispute, but that the DNS nameserver for the record was not reset until January of 2019.

“This oversight created a state where the DNS pointed to a server controlled by a third party, leaving it vulnerable to misuse,” Canale said. “We’ve reviewed the configuration of both our registrar and nameservers and have found no indication of misuse. In addition to addressing the immediate problem, we have reviewed the entire catalog of properties we own to ensure they are properly configured.”

According to both Guilmette and Bryant, this type of hijack is possible because GoDaddy — like many other managed DNS providers — does little to check whether someone with an existing account (free or otherwise) who is claiming ownership over a given domain actually controls that domain name.

“During this entire time, and continuing to the present moment, the same bad actor(s) who were responsible for the massive wave of bomb threat bitcoin extortion spams that were emailed to five countries on December 13th, 2018 have been in a position to add, delete, or modify any DNS record associated with any domain name that uses the GoDaddy DNS service,” Guilmette said.

Contacted by KrebsOnSecurity, GoDaddy acknowledged the authentication weakness documented by Guilmette.

“After investigating the matter, our team confirmed that a threat actor(s) abused our DNS setup process,” the company said in an emailed statement.

“We’ve identified a fix and are taking corrective action immediately,” the statement continued. “While those responsible were able to create DNS entries on dormant domains, at no time did account ownership change nor was customer information exposed.”

SPAMMY BEAR

Guilmette has dubbed the criminals responsible as “Spammy Bear” because the majority of the hijacked domains used in the spam campaigns traced back to Internet addresses in Russia.

In the case of Mozilla’s Virtualfirefox.com domain, historic DNS records archived by Farsight Security show that indeed on Dec. 13, 2018 — the very same day that spammers began blasting out their bomb threat demands — the Internet address in the domain’s DNS records at GoDaddy were changed to 194.58.58[.]70, a server in the Russian Federation owned by a hosting company there called Reg.ru.

The record above, indexed by Farsight Security, shows that the Internet address for virtualfirefox.com was changed to an ISP in Russia on Dec. 13, 2018, the same day spammers used this domain and more than 5,000 others for a mass emailed bomb threat.

In fact, Guilmette found that that at least 3,500 of the commandeered domains traced back to Reg.ru and to a handful of other hosting firms in Russia. The next largest collection of fraudulently altered Internet addresses were assigned to hosting providers in the United States (456), although some of those providers (e.g. Webzilla/WZ Communications) have strong ties to Russia. The full list of Internet addresses is available here.

Guilmette’s sleuthing on the 5,000+ domains abused in both 2018 spam campaigns, combined with data from Farsight, suggest the spammers hijacked domains belonging to a staggering number of recognizable corporations who registered domains at GoDaddy, including but not limited to:

Abbott Laboratories; Ancestry.com; AutodeskCapital One; CVS Pharmacy; SSL provider Digicert; Dow Chemical; credit card processors Elavon and Electronic Merchant Systems; Fair Isaac Corp.; Facebook; Gap (Apparel) Inc; Fifth Third Bancorp; Hearst CommunicationsHilton InterntionalING Bank; the Massachusetts Institute of Technology (MIT); McDonalds Corp.NBC Universal MediaNRG Energy; Oath, Inc (a.k.a Yahoo + AOL); OracleTesla Motors; Time WarnerUS Bank; US Steel Corp.; National Association; Viacom International; and Walgreens.

In an interview with KrebsOnSecurity, Bryant said the domain hijacking technique can be a powerful tool in the hands of spammers and scammers, who can use domains associated with these companies not only to get their missives past junk and malware filters, but also to make phishing and malware lures far more believable and effective.

“This is extremely advantageous to attackers because they don’t have to pay any money to set it all up, and there’s a strong reputation attached to the domain they’re sending from,” Bryant said. “A lot of services will flag email from unknown domains as high risk, but the domains being hijacked by these guys have a good history and reputation behind them. This method also probably greatly complicates any sort of investigatory efforts after the spam campaign is over.”

WHAT CAN BE DONE?

Guilmette said managed DNS providers can add an extra layer of validation to DNS change requests, checking to see if a given domain already has internal DNS servers assigned to the domain before processing the request. Providers could nullify the threat by simply choosing a different pair of DNS servers to assign to the request. The same validation process would work similarly at other managed DNS providers.

“As long as they’re different, that ruins this attack for the spammers,” Guilmette said. “The spammers want the DNS servers to be the same ones that were already there when the domain was first set up, because without that they can’t pull of this hack. All GoDaddy has to do is see if this particularly odd set of circumstances apply in each request.”

Bryant said after he published his initial research in 2016, a number of managed DNS providers mentioned in his blog posts said they’d taken steps to blunt the threat, including Amazon Web Services (AWS), hosting provider Digital Ocean, and Google Cloud. But he suspects this is still a “fairly common” weakness and hosting providers and registrars, and many providers simply aren’t convinced of the need to add this extra precaution.

“A lot of the providers are of the opinion that it’s down to a user mistake and not a vulnerability they should have to fix,” he said. “But it’s clearly still a big problem.”

Source

Researchers show how rogue web applications can be used to attack vulnerable browser extensions in a hack that gives adversaries access to private user data.

Source

The French Data Protection Authority (DPA) found a lack of transparency when it comes to how Google harvests and uses personal data for ad-targeting purposes.

Source