INTERNET STORM CENTER SPOTLIGHT
ISC provides a free analysis and warning service to thousands of Internet users and organizations, and is actively working with Internet Service Providers to fight back against the most malicious attackers. https://isc.sans.edu/about.html
Analyzing Synology Disks on Linux
Published: 2024-05-08
Last Updated: 2024-05-08 07:00:07 UTC
by Xavier Mertens (Version: 1)
Synology NAS solutions are popular devices. They are also used in many organizations. Their product range goes from small boxes with two disks (I’m not sure they still sell a single-disk enclosure today) up to monsters, rackable with plenty of disks. They offer multiple disk management options but rely on many open-source software (like most appliances). For example, there are no expensive hardware RAID controllers in the box. They use the good old “MD” (“multiple devices”) technology, managed with the well-known mdadm tool. Synology NAS run a Linux distribution called DSM. This operating system has plenty of third-party tools but lacks pure forensics tools.
In a recent investigation, I had to investigate a NAS that was involved in a ransomware attack. Many files (backups) were deleted. The attacker just deleted some shared folders. The device had two drives configured in RAID0 (not the best solution I know but they lack storage capacity). The idea was to mount the file system (or at least have the block device) on a Linux host and run forensic tools, for example, photorec.
In such a situation, the biggest challenge will be to connect all the drivers to the analysis host! Here, I had only two drives but imagine that you are facing a bigger model with 5+ disks. In my case, I used two USB-C/SATA adapters to connect the drives. Besides the software RAID, Synology volumes also rely on LVM2 (“Logical Volume Manager”). In most distributions, the packages mdadm and lvm2 are available (for example on SIFT Workstation). Otherwise, just install them ...
Read the full entry:
https://isc.sans.edu/diary/Analyzing+Synology+Disks+on+Linux/30904/
Detecting XFinity/Comcast DNS Spoofing
Published: 2024-05-06
Last Updated: 2024-05-08 00:15:59 UTC
by Johannes Ullrich (Version: 1)
ISPs have a history of intercepting DNS. Often, DNS interception is done as part of a "value add" feature to block access to known malicious websites. Sometimes, users are directed to advertisements if they attempt to access a site that doesn't exist. There are two common techniques how DNS spoofing/interception is done:
1. The ISP provides a recommended DNS server. This DNS server will filter requests to known malicious sites.
2. The ISP intercepts all DNS requests, not just requests directed at the ISPs DNS server.
The first method is what I would consider a "recommended" or "best practice" method. The customer can use the ISP's DNS server, but traffic is left untouched if a customer selects a different recursive resolver. The problem with this approach is that malware sometimes alters the user's DNS settings.
Comcast, as part of its "Business Class" offer, provides a tool called "Security Edge". It is typically included for free as part of the service. Security Edge is supposed to interface with the customer's modem but can only do so for specific configurations. Part of the service is provided by DNS interception. Even if "Security Edge" is disabled in the customer's dashboard, DNS interception may still be active.
One issue with any filtering based on blocklists is false positives. In some cases, what constitutes a "malicious" hostname may not even be well defined. I could not find a definition on Comcast's website. But Bleeping Computer (www.bleepingcomputer.com) recently ended up on Comcast's "naughty list". I know all to well that it is easy for a website that covers security topics to end up on these lists. The Internet Storm Center website has been on lists like this before. Usually, sloppy signature-based checks will flag a site as malicious. An article may discuss a specific attack and quote strings triggering these signatures.
Comcast offers recursive resolvers to it's customers: 75.75.75.75, 75.75.76.76, 2001:558:feed:1 and 2001:558:feed:2. There are advantages to using your ISP's DNS servers. They are often faster as they are physically closer to your network, and you profit from responses cached by other users. My internal resolver is configured as a forwarding resolver, spreading queries among different well performing resolvers like Quad9, Cloudflare and Google.
So what happened to bleepingcomputer.com? When I wasn't able to resolve bleepingcomputer.com, I checked my DNS logs, and this entry stuck out ...
Read the full entry:
https://isc.sans.edu/diary/Detecting+XFinityComcast+DNS+Spoofing/30898/
nslookup's Debug Options
Published: 2024-05-05
Last Updated: 2024-05-05 07:24:11 UTC
by Didier Stevens (Version: 1)
A friend was having unexpected results with DNS queries on a Windows machine. I told him to use nslookup's debug options.
When you execute a simple DNS query like "nslookup example.com. 8.8.8.8", you get an answer like this (notice that in my nslookup query, I terminated the FQDN with a dot: "example.com.", I do that to prevent Windows from adding suffixes)...
You see the result of a reverse DNS lookup (8.8.8.8 is dns.google) and you get 2 IP addresses for example.com in your answer: an IPv6 address and an IPv4 address.
If my friend would have been able to run packet capture on the machine, he would have seen 3 DNS queries and answers ...
A PTR query to do a reverse DNS lookup for 8.8.8.8, an A query to lookup IPv4 addresses for example.com, and an AAAA query to lookup IPv6 addresses for example.com.
One can use nslookup's debug options to obtain equivalent information, without doing a packet capture.
Debug option -d displays extra information for each DNS response packet ...
Read the full entry:
https://isc.sans.edu/diary/nslookups+Debug+Options/30894/
Scans Probing for LB-Link and Vinga WR-AC1200 routers CVE-2023-24796
Published: 2024-05-02
Last Updated: 2024-05-02 18:07:05 UTC
by Johannes Ullrich (Version: 1)
Before diving into the vulnerability, a bit about the affected devices. LB-Link, the make of the devices affected by this vulnerability, produces various wireless equipment that is sometimes sold under different brands and labels. This will make it difficult to identify affected devices. These devices are often low-cost "no name" solutions or, in some cases, may even be embedded, which makes it even more difficult to find firmware updates.
Before buying any IoT device, WiFi router, or similar piece of equipment, please make sure the vendor does:
1. Offer firmware updates for download from an easy-to-find location.
2. Provide an "end of life" policy stating how long a particular device will receive updates.
Alternatively, you may want to verify if the device can be "re-flashed" using an open source firmware.
But let us go back to this vulnerability. There are two URLs affected, one of which showed up in our "First Seen URLs" ...
Read the full entry:
https://isc.sans.edu/diary/Scans+Probing+for+LBLink+and+Vinga+WRAC1200+routers+CVE202324796/30890/