Hírolvasó

An issue was discovered in the Linux kernel before 5.2.6. On NUMA systems, the Linux fair scheduler has a use-after-free in show_numa_stats() because NUMA fault statistics are inappropriately freed, aka CID-16d51a590a8c.

An issue was discovered in __split_huge_pmd in mm/huge_memory.c in the Linux kernel before 5.7.5. The copy-on-write implementation can grant unintended write access because of a race condition in a THP mapcount check, aka CID-c444eb564fb1.

An issue was discovered in mm/mmap.c in the Linux kernel before 5.7.11. There is a race condition between certain expand functions (expand_downwards and expand_upwards) and page-table free operations from an munmap call, aka CID-246c320a8cfe.

An issue was discovered in kmem_cache_alloc_bulk in mm/slub.c in the Linux kernel before 5.5.11. The slowpath lacks the required TID increment, aka CID-fd4d9c7d0c71.

An issue was discovered in romfs_dev_read in fs/romfs/storage.c in the Linux kernel before 5.8.4. Uninitialized memory leaks to userspace, aka CID-bcf85fcedfdd.

An issue was discovered in do_madvise in mm/madvise.c in the Linux kernel before 5.6.8. There is a race condition between coredump operations and the IORING_OP_MADVISE implementation, aka CID-bc0c4d1e176e.

An issue was discovered in fs/io_uring.c in the Linux kernel before 5.6. It unsafely handles the root directory during path lookups, and thus a process inside a mount namespace can escape to unintended filesystem locations, aka CID-ff002b30181d.

An issue was discovered in the Linux kernel before 5.7.3, related to mm/gup.c and mm/huge_memory.c. The get_user_pages (aka gup) implementation, when used for a copy-on-write page, does not properly consider the semantics of read operations and therefore can grant unintended write access, aka CID-17839856fd58.

In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is received entirely but not consumed by the application, then a subsequent request on the same connection will see that body prepended to its body. The attacker will not see any data but may inject data into the body of the subsequent request.

Recently I have been testing a new tool created by the people at Salesforce.  The tool is called JARM and what it does is query TLS instances (HTTPS servers and services) to create a fingerprint of their TLS configuration.  Much like analyzing the nuances of network traffic can be used to fingerprint the operating system and version of a server, JARM fingerprints TLS instances  to create a fingerprint which can be used to compare one TLS service to another.

The JARM repository on github provides two executable files.  The first jarm.py can be used to create a fingerprint for any TLS enabled service. The second jarm.sh is used to automate a JARM scan across a range of IPs.  For example the fingerprint for isc.sans.edu can be generated as follows:

$ python3 jarm.py isc.sans.edu Domain: isc.sans.edu Resolved IP: 45.60.103.34 JARM: 29d29d00029d29d00041d41d0000005d86ccb1a0567e012264097a0315d7a7

JARM can be used for a number of purposes.  As the Salesforce blog post says:

“JARM fingerprints can be used to:

• Quickly verify that all servers in a group have the same TLS configuration.
• Group disparate servers on the internet by configuration, identifying that a server may belong to Google vs. Salesforce vs. Apple, for example.
• Identify default applications or infrastructure.
• Identify malware command and control infrastructure and other malicious servers on the Internet.”

Shodan has integrated JARM and has generated JARM fingerprints for all TLS instances they have discovered and integrated them into a Shodan facet.  You can query Shodan’s JARM results from the Shodan web tool, or from any Linux with Python installed you can use the Shodan command line, or use the Shodan API, to query fingerprints

So how can this be used to detect malware deployments?  Well it turns out that the when malware deploys a TLS enabled service the fingerprints tend to stay the same across multiple deployments.  The JARM developers have given us the fingerprints for a number of common malware families.

Using this information you could create a script to run across your address space and compare the computed fingerprints to the known malware fingerprints or you could just use Shodan to do this comparison.  In this example below I am using the Shodan command line to query the JARM results for AS209 and comparing the result to the fingerprint for Cobalt Strike (a red team tool often dropped by emotet and other malware onto compromised servers).

$ shodan search asn:as209 ssl.jarm:07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1 184.99.37.107 443 HTTP/1.1 403 Forbidden\r\nContent-Length: 310\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 71.37.172.120 443 71-37-172-120.lsv2.qwest.net HTTP/1.1 403 Forbidden\r\nContent-Length: 316\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 71.37.172.123 443 71-37-172-123.lsv2.qwest.net HTTP/1.1 403 Forbidden\r\nContent-Length: 316\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 97.122.203.173 443 97-122-203-173.hlrn.qwest.net HTTP/1.1 403 Forbidden\r\nContent-Length: 303\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 174.16.120.233 443 174-16-120-233.hlrn.qwest.net HTTP/1.1 403 Forbidden\r\nContent-Length: 309\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 65.144.105.2 443 mail.strataproducts.com HTTP/1.1 403 Forbidden\r\nContent-Length: 314\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 65.144.105.6 443 HTTP/1.1 200 OK\r\nCache-Control: private\r\nContent-Type: text/html; charset=utf-8\r\nServer: Microsoft-IIS/7.5\r\nSet-Cookie: ASP.NET_SessionId=vpxjjrrzezdnobjeacvfff45; path=/; HttpOnly\r\nX-AspNet-Version: 2.0.50727\r\nX-Powered-By: ASP.NET\r\nDate: Sun, 22 Nov 2020 02:31:11 GMT\r\nContent-Length: 47074\r\n\r\n 65.144.7.67 443 HTTP/1.1 403 Forbidden\r\nContent-Length: 352\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n 71.222.37.196 443 71-222-37-196.lsv2.qwest.net HTTP/1.1 403 Forbidden\r\nContent-Length: 316\r\nContent-Type: text/html\r\nConnection: Close\r\n\r\n

I have to believe there have to be some false positives in the results, but it gives you a  place to start.

For more information on JARM, please check out the Salesforce JARM blog post 

For downloading, JARM can be found on github.
 

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

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

Fix for multiple CVEs

fix CVE-2020-27780: authentication bypass when the user doesn't exist

Update to upstream 17.9.0 for bug and security fixes

Fix for multiple CVEs

Security fix for CVE-2020-8277.

blosc2.c in Blosc C-Blosc2 through 2.0.0.beta.5 has a heap-based buffer overflow when there is a lack of space to write compressed data.

npm package systeminformation before version 4.30.5 is vulnerable to Prototype Pollution leading to Command Injection. The issue was fixed with a rewrite of shell sanitations to avoid prototyper pollution problems. The issue is fixed in version 4.30.5. If you cannot upgrade, be sure to check or sanitize service parameter strings that are passed to si.inetChecksite().

In Crafter CMS Crafter Studio 3.0.1 an unauthenticated attacker is able to inject malicious JavaScript code resulting in a stored/blind XSS in the admin panel.

In Crafter CMS Crafter Studio 3.0.1 an unauthenticated attacker is able to create a site with specially crafted XML that allows the retrieval of OS files out-of-band.

Crafter CMS Crafter Studio 3.0.1 has a directory traversal vulnerability which allows unauthenticated attackers to view files from the operating system.