Sep 25 2023

BIND DNS System Flaws Let Attackers Launch DoS Attacks

Category: DDoS,DNS Attacks — disc7 @ 9:28 am
BIND DNS System Flaws Let Attackers Launch DoS Attacks

In a recent disclosure, BIND 9, a widely-used DNS (Domain Name System) server software, has been found vulnerable to two critical security flaws, labeled CVE-2023-4236 and CVE-2023-3341. 

These vulnerabilities, if exploited, could have serious consequences, making it imperative for users to take swift action.

CVE-2023-4236: DNS-over-TLS Query Load Vulnerability

This vulnerability arises from a flaw in the networking code responsible for handling DNS-over-TLS queries in BIND 9. 

Under high DNS-over-TLS query load, an internal data structure is incorrectly reused, leading to an assertion failure. Consequently, a vulnerable named instance may terminate unexpectedly.

Thankfully, this flaw does not affect DNS-over-HTTPS code, as it employs a distinct TLS implementation. However, for those relying on DNS-over-TLS, the impact can be severe.

CVE-2023-3341: Control Channel Stack Exhaustion

The second critical vulnerability, CVE-2023-3341, relates to the control channel code within BIND 9. 

This flaw allows attackers to exploit a stack exhaustion issue by sending specially crafted messages over the control channel. 

This can lead to names unexpectedly terminating, causing potential disruption.

Notably, the attack is effective in environments with limited stack memory available to each process or thread, making it difficult to predict its impact.

For users of BIND 9, immediate action is necessary to address these vulnerabilities. ISC (Internet Systems Consortium), the organization behind BIND, has provided solutions to mitigate these risks.

For CVE-2023-4236:

– Upgrade to BIND 9.18.19 or BIND Supported Preview Edition 9.18.19-S1.

– Consider disabling DNS-over-TLS connections if not required.

For CVE-2023-3341:

– Upgrade to BIND 9.16.44, 9.18.19, or 9.19.17, depending on your current version.

– Ensure that control-channel connections are limited to trusted IP ranges when enabling remote access.

No active exploits have been reported for these vulnerabilities. However, proactive measures are crucial to safeguard your systems against potential threats.

ISC extends its gratitude to the individuals who responsibly reported these vulnerabilities. 

Robert Story from the USC/ISI DNS root server operations team brought CVE-2023-4236 to ISC’s attention, while Eric Sesterhenn from X41 D-Sec GmbH identified CVE-2023-3341.

The Hidden Potential of DNS In Security: Combating Malware, Data Exfiltration, and more – The Guide for Security Professionals

InfoSec tools | InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory

Tags: BIND DNS System Flaws, DNS In Security

Aug 20 2023

Microsoft DNS boo-boo breaks Hotmail for users around the globe

Category: DNS Attacks,Information Security — disc7 @ 11:05 pm

https://www.theregister.com/2023/08/21/microsoft_dns_booboo_breaks_hotmail

Someone at Microsoft has some explaining to do after a messed up DNS record caused emails sent from Hotmail accounts using Microsoft’s Outlook service to be rejected and directed to spam folders starting on Thursday.

Late on Thursday evening, Hotmail users began reporting that some emails were being returned with errors related to Sender Policy Framework (SPF), and thus recipient email services were unable “to confirm that [a] message came from a trusted location.” 

SPF, for those unfamiliar with it, is a method of outbound email authentication that helps avoid email spoofing, impersonation and phishing. If, for example, a service like Hotmail were to have one of its subdomains removed from the DNS TXT record that stores its SPF list, then recipient services may assume it’s junk. 

And that appears to be just what happened. 

Reddit users posting to the Sysadmin subreddit verified they were experiencing SPF issues with Hotmail. One user pulled up Hotmail’s SPF record and found that Redmond had made two changes: removing spf.protection.outlook.com from the record, and changing the SPF failure condition from soft to hard. That meant any suspicious messages from Hotmail should be rejected rather than just sent to spam. 

Microsoft support forum advisors confirmed that the issue was known, which was further confirmed by a look at the Office service status page. Per Microsoft: “Some users may receive non-delivery reports when attempting to send emails from hotmail.com.” 

At time of writing, the status page indicated that “a recent change to email authentication” was the potential root cause of the outage. Microsoft said it made a configuration change to remediate impact, but shortly after said the problem may have been worse than it appeared at first glance. 

“We’ve identified that additional configuration entries are impacted, and we’re implementing further configuration changes to resolve the issue,” Microsoft said. Not long after that was posted, Microsoft indicated configuration changes were complete and the problem was fixed. 

Microsoft didn’t respond to our questions about the incident, only saying the issue had been resolved.

Tags: Microsoft DNS

Jan 24 2023

Serious Security: How dEliBeRaTe tYpOs might imProVe DNS security

Category: DNS Attacks — DISC @ 10:41 am
Serious Security: How dEliBeRaTe tYpOs might imProVe DNS security

Over the years, we’ve written and spoken on Naked Security many times about the thorny problem of DNS hijacking.

DNS, as you probably know, is short for domain name system, and you’ll often hear it described as the internet’s “telephone directory” or “gazetteer”.

If you’re not familiar with the word gazeteer, it refers to the index at the back of an atlas where you look up, say, Monrovia, Liberia in a convenient alphabetic list, and it says something like 184 - C4. This tells you to turn straight to page 184, and to follow the grid lines down from the letter C at the top of the map, and across from the number 4 on the left. Where the lines meet, you’ll find Monrovia.

For most users, most DNS lookups go out containing a server name, asking for a reply to come back that includes what’s known as its A-record or its AAAA-record.

(A-records are used for 32-bit IPv4 internet numbers, such as 203.0.113.42; AAAA-records are the equivalent answers for a 128-bit IPv6 addresses, such as 2001:db8:15a:d0c::42 – in this article, we’ll just use A-records and IPv4 numbers, but the same security issues apply to the lookup process in both cases.)

Here’s an example, where we’re looking up the imaginary domain name naksec.test via a DNS server that was specially created to track and teach you about DNS traffic.

We’ve used the old-school Linux tool dig, short for domain internet groper, to generate a simple DNS request (dig defaults to looking up A-records) for the server we want:

$ dig +noedns @127.42.42.254 naksec.test

;; QUESTION SECTION:
;naksec.test.			IN	A

;; ANSWER SECTION:
NAKSEC.TEST.		5	IN	A	203.0.113.42

;; Query time: 1 msec
;; SERVER: 127.42.42.254#53(127.42.42.254) (UDP)
;; WHEN: Mon Jan 23 14:38:42 GMT 2023
;; MSG SIZE  rcvd: 56

Here’s how our DNS server dealt with the request, showing a hex dump of the incoming request, and the successful reply that went back:

---> Request from 127.0.0.1:57708 to 127.42.42.254:53
---> 00000000  62 4e 01 20 00 01 00 00  00 00 00 00 06 6e 61 6b  |bN. .........nak|
     00000010  73 65 63 04 74 65 73 74  00 00 01 00 01           |sec.test.....   |

DNS lookup: A-record for naksec.test ==> A=203.0.113.42

<--- Reply from 127.42.42.254:53 to 127.0.0.1:57708
<--- 00000000  62 4e 84 b0 00 01 00 01  00 00 00 00 06 6e 61 6b  |bN...........nak|
     00000010  73 65 63 04 74 65 73 74  00 00 01 00 01 06 4e 41  |sec.test......NA|
     00000020  4b 53 45 43 04 54 45 53  54 00 00 01 00 01 00 00  |KSEC.TEST.......|
     00000030  00 05 00 04 cb 00 71 2a                           |......q*        |

Note that, for performance reasons, most DNS requests use UDP, the user datagram protocol, which works on a send-and-hope basis: you fire off a UDP packet at the server you want to talk to, and then wait to see if a reply comes back.

This makes UDP much simpler and faster than its big cousin TCP, the transmission control protocol, which, as its name suggests, automatically takes care of lots of details that UDP doesn’t.

Notably, TCP deals with detecting data gets lost and asking foir it again; ensuring that any chunks of data arrive in the right order; and providing a single network connection that, once set up, can be used for sending and receiving at the same time.

UDP doesn’t have the concept of a “connection”, so that requests and replies essentially travel independently:

  • A DNS request arrives at the DNS server in a UDP packet of its own.
  • The DNS server keeps a record of which computer sent that particular packet.
  • The server sets about finding an answer to send back, or deciding that there isn’t one.
  • The server sends a reply to the original sender, using a second UDP packet.

From the level of the operating system or the network, those two UDP packets above are independent, standalone transmissions – they aren’t tied together as part of the same digital connection.

It’s up to the server to remember which client to send each reply to; and it’s up to the client to figure out which replies relate to which requests it originally sent out.

How can you be sure?

Learning CoreDNS: Configuring DNS for Cloud Native Environments

InfoSec books | InfoSec tools | InfoSec services

Tags: DNS flaw, DNS Security

Jul 11 2022

The impact of DNS attacks on global organizations

Category: DNS Attacks,Information Security — DISC @ 9:32 am
The impact of DNS attacks on global organizations

Often we see stories about cyber attacks that breached an organisations’ security parameters, and advice on how we can protect against future threats. However, what is often missed, is just how these threat actors managed to breach a system, and as such, the fact that the Domain Name System (DNS) probably played a very large role in the attacker’s entry point.

In this Help Net Security video, Chris Buijs, Chief Evangelist at EfficientIP, talks about the importance of making the DNS as part of an organisation’s security strategy.

Internet

DNSSEC Mastery

Tags: DNS attacks, DNSSEC

May 03 2022

A DNS flaw impacts a library used by millions of IoT devices

Category: DNS Attacks — DISC @ 8:29 am
A DNS flaw impacts a library used by millions of IoT devices

A vulnerability in the domain name system (DNS) component of the uClibc library impacts millions of IoT products.

Nozomi Networks warns of a vulnerability, tracked as CVE-2022-05-02, in the domain name system (DNS) component of the uClibc library which is used by a large number of IoT products. The flaw also affects DNS implementation of all versions of the uClibc-ng library, which is a fork specifically designed for OpenWRT, a common OS for routers used in various critical infrastructure sectors.

An attacker can exploit the vulnerability for DNS poisoning or DNS spoofing and redirect the victim to a malicious website instead of the legitimate one.

“The flaw is caused by the predictability of transaction IDs included in the DNS requests generated by the library, which may allow attackers to perform DNS poisoning attacks against the target device.” reads the advisory published by Nozomi Networks.

The uClibc library is used by major vendors, including Linksys, Netgear, and Axis, or Linux distributions such as Embedded Gentoo.

Security experts did not disclose the details of the flaw because the vendor has yet to address it.

The researchers from Nozomi discovered the issue by reviewing the trace of DNS requests performed by an IoT device in their test environment. They were able to determine the pattern of DNS requests performed from the output of Wireshark, the transaction ID is first incremental, then resets to the value 0x2, then is incremental again. The transaction ID of the requests was predictable, a circumstance that could allow an attacker to perform DNS poisoning under certain circumstances.

DNS

“A source code review revealed that the uClibc library implements DNS requests by calling the internal “__dns_lookup” function, located in the source file “/libc/inet/resolv.c”.” continues the advisory. “Given that the transaction ID is now predictable, to exploit the vulnerability an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server. Exploitability of the issue depends exactly on these factors. As the function does not apply any explicit source port randomization, it is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port.”

If the OS uses randomization of the source port, the only way to exploit the issue is to bruteforce the 16-bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate response.

“As anticipated, as of the publication of this blog, the vulnerability is still unpatched. As stated in a public conversation, the maintainer was unable to develop a fix for the vulnerability, hoping for help from the community. The vulnerability was disclosed to 200+ vendors invited to the VINCE case by CERT/CC since January 2022, and a 30-day notice was given to them before the public release.” concludes Nozomi.

Managing Mission – Critical Domains and DNS: Demystifying nameservers, DNS, and domain names

DNSSEC Mastery

Tags: DNS flaw, IoT devices

Mar 17 2022

B1txor20 Linux botnet use DNS Tunnel and Log4J exploit

Category: DNS Attacks,Linux Security,Log4j — DISC @ 8:50 am
B1txor20 Linux botnet use DNS Tunnel and Log4J exploit

Researchers uncovered a new Linux botnet, tracked as B1txor20, that exploits the Log4J vulnerability and DNS tunnel.

Researchers from Qihoo 360’s Netlab have discovered a new backdoor used to infect Linux systems and include them in a botnet tracked as B1txor20.

The malware was first spotted on February 9, 2022, when 360Netlab’s honeypot system captured an unknown ELF file that was spreading by exploiting the Log4J vulnerability.

The name B1txor20 is based on the file name “b1t” used for the propagation and the XOR encryption algorithm, and the RC4 algorithm key length of 20 bytes.

The B1txor20 Linux backdoor uses DNS Tunnel technology for C2 communications, below is the list of the main features implemented by the threat:

  • SHELL
  • Proxy
  • Execute arbitrary commands
  • Install Rootkit
  • Upload sensitive information
B1txor20

The researchers also noticed the presence of many developed features that have yet to be used, and some of them are affected by bugs. Experts believe the B1txor20 botnet is under development.

“In short, B1txor20 is a Backdoor for the Linux platform, which uses DNS Tunnel technology to build C2 communication channels. In addition to the traditional backdoor functions, B1txor20 also has functions such as opening Socket5 proxy and remotely downloading and installing Rootkit.” reads the analysis published by the experts.

Once the system has been compromised, the threat connects the C2 using the DNS tunnel and retrieves and executes commands sent by the server. The researchers noticed that the bot supports a total of 14 commands that allows it to execute arbitrary commands, upload system information, manipulate files, starting and stopping proxy services, and creating reverse shells.

“Generally speaking, the scenario of malware using DNS Tunnel is as follows: Bot sends the stolen sensitive information, command execution results, and any other information that needs to be delivered, after hiding it using specific encoding techniques, to C2 as a DNS request; After receiving the request, C2 sends the payload to the Bot side as a response to the DNS request. In this way, Bot and C2 achieve communication with the help of DNS protocol.” continues the analysis.

The post includes additional technical details along with Indicators of Compromise (IoCs) for this threat.

Indicators of Compromise Associated with BlackByte Ransomware: Joint Cybersecurity Advisory

Tags: B1txor20 Linux botnet, Indicators of Compromise, IoC

Apr 09 2021

How do I select an attack detection solution for my business?

Category: Attack Matrix,Cyber Attack,DNS Attacks,MitM Attack — DISC @ 8:33 am
How do I select an attack detection solution for my business?

When selecting an attack detection solution, no single product will provide the adequate detection needed that is required to detect and defend against the current advanced threat landscape. The holistic aspect of defending against threat actors requires technology, expertise, and intelligence.

The technology should be a platform of integrated technologies providing detection at each point of entry that a threat actor may use such as email, endpoint, network, and public cloud. These should not be disparate technologies that don’t work together to holistically defend the organization.

We must use technologies that can scale against threat actors that have a very large number of resources. The technology should also be driven by intelligence cultivated from the frontlines where incident responders have an unmatched advantage. It is also important to remember that post-exploitation, threat actors masquerade as your own employee’s making it difficult to know legitimate from non-legitimate activity occurring on the network or your endpoints.

This is where intelligence and expertise is extremely valuable to determine when a threat actor is operating within the organization. Being able to identify the threat actors “calling card” and potential next moves, is paramount. While many solutions will claim they defend against advanced threats, it is important to understand the experience that a vendor has and how that is included into their product offering.

How do I select an attack detection solution for my business?

Tags: attack detection solution

Jan 20 2021

List of DNSpooq vulnerability advisories, patches, and updates

Category: DNS Attacks,Information Security — DISC @ 11:37 am
DNSpooq

Yesterday, seven Dnsmasq vulnerabilities were disclosed, collectively known as DNSPooq, that attackers can use to launch DNS Cache Poisoning, denial of service, and possibly remote code execution attacks, on affected devices.

Dnsmasq is a widely used open-source Domain Name System (DNS) forwarding application commonly installed on routers, operating systems, access points, and other networking equipment. 

Vendors have started to release information on how customers can protect themselves from DNSPooq. To make it easier to find this information, BleepingComputer will be listing security advisories as they are released. 

The related CVEs from JSOF’s DNSpooq advisory are listed below, along with their descriptions.

NameCVSSDescription
CVE-2020-256818.1Dnsmasq versions before 2.83are susceptible to a heap-based buffer overflow in sort_rrset() when DNSSEC is used. This can allow a remote attacker to write arbitrary data into target device’s memory that can lead to memory corruption and other unexpected behaviors on the target device.
CVE-2020-256828.1Dnsmasq versions before 2.83 are susceptible to buffer overflow in extract_name() function due to missing length check, when DNSSEC is enabled. This can allow a remote attacker to cause memory corruption on the target device.
CVE-2020-256835.9Dnsmasq versions before 2.83 are susceptible to a heap-based buffer overflow when DNSSEC is enabled. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in get_rdata() and cause a crash in dnsmasq, resulting in a Denial of Service.
CVE-2020-256875.9Dnsmasq versions before 2.83are vulnerable to a heap-based buffer overflow with large memcpy in sort_rrset() when DNSSEC is enabled. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in sort_rrset() and cause a crash in dnsmasq, resulting in a Denial of Service.
CVE-2020-256844A lack of proper address/port check implemented in dnsmasq versions
CVE-2020-256854A lack of query resource name (RRNAME) checks implemented in dnsmasq’s versions before 2.83 reply_query function allows remote attackers to spoof DNS traffic that can lead to DNS cache poisoning.
CVE-2020-256864Multiple DNS query requests for the same resource name (RRNAME) by dnsmasq versions before 2.83 allows for remote attackers to spoof DNS traffic, using a birthday attack (RFC 5452), that can lead to DNS cache poisoning.

BleepingComputer suggests checking this page throughout the coming days to see if new information is available for devices you may be using.

Source: List of DNSpooq vulnerability advisories, patches, and updates

Aug 06 2020

Hackers abuse lookalike domains and favicons for credit card theft

Category: DNS Attacks,Hacking — DISC @ 10:58 pm

Hackers are abusing a new technique: combining homoglyph domains with favicons to conduct credit card skimming attacks.

Source: Hackers abuse lookalike domains and favicons for credit card theft



Credit Card Scammers on the Dark Web
httpv://www.youtube.com/watch?v=jT-jmq8KBw0



Preventing Credit Card Fraud: A Complete Guide for Everyone from Merchants to Consumers




PCI Compliance

Download a Security Risk Assessment Steps paper!

Subscribe to DISC InfoSec blog by Email

Take an awareness quiz to test your basic cybersecurity knowledge

DISC InfoSec 🔒 securing the business 🔒 via latest InfoSec titles




Tags: abuse lookalike domains, credit card theft

Feb 20 2019

A Deep Dive on the Recent Widespread DNS Hijacking Attacks

Category: DNS Attacks — DISC @ 5:24 pm

The U.S. government — along with a number of leading security companies — recently warned about a series of highly complex and widespread attacks that allowed suspected Iranian hackers to siphon huge volumes of email passwords and other sensitive data from multiple governments and private companies. But to date, the specifics of exactly how that attack went down and who was hit have remained shrouded in secrecy.

  • Source: A Deep Dive on the Recent Widespread DNS Hijacking Attacks