An Internet Storm Center forums user is reporting an increase in Protocol 47 traffic over the last two weeks. Researchers have detected this via backscatter IBR. Typically, this type of traffic is used for Generic Route Encapsulation (GRE). Many forms of VPN traffic are tunneled through GRE. An astute ISC commenter reports that the payloads don’t carry the correct headers to properly carry out the GRE->IP->GRE->IP attack.
Possible Target: Taiwanese Chungwa Telco
By analyzing the backscatter traffic, the ISC community has determined that the majority of the targets are in Taiwan. The IP addresses are associated with a telco company called Chungwa. However, no information exists about an ongoing DDoS there. Finally, an update shows there are upticks via protocol 132 and 255 as well. These are Stream Control Transmission Protocol and Reserved/Unknown, respectively.
Signal has begun using a practice called domain fronting to counter the Egyptian government’s censorship of their service. Instead of using Open Whisper servers and domains to send content, they are using the Google App Engine. This effectively hides traffic under an encrypted and trusted domain, masking it among the noise of Google traffic. What looks similar to Google searches, calendar requests, and document collaboration could now hold encrypted messages.
Domain fronting works… too well.
@Google there’s a problem in using your search page and gmail through ur chrome app on both iPhone and laptop. In Egypt! What’s wrong?
For hackers using spearphishing as their method of attack, there are small bites and then there are whales. Whales are large value targets such as bankers, corporate executives, and of course high-ranking political officials such as John Podesta. This process of “whaling” is what allows hackers or groups of hackers such as APT28 and APT29 to gain access to DNC emails and infrastructure.
On December 26, 2016, the FBI and DHS published a joint technical report called GRIZZLY STEPPE – Russian Malicious Cyber Activity. Many publications are referencing this document as proof of Russian involvement in recent high-profile data breaches, such as the DNC Hack the document focuses on.
However, the stated intent of the document is to share insights gained from studying and countering these attacks, so that other companies, organizations and agencies can properly prepare for them and mitigate any damage that happened as a result.
Main Actors: Advanced Persistent Threat 28 and 29
The document identifies two actors: one called Advanced Persistent Threat (APT) 28, and one called APT29. After gathering and analyzing data related to the susceptibility of their targets, both actors use spearphishing attacks to gain remote access to systems, using various methods to deceive and evade detection.
The document is accompanied by a list of IP addresses, YARA signatures, and file hashes (in CSV and XML format) associated with RIS actors, and suggests a full audit of such indicators of compromise (IOCs). It then lists the “usual suspects” when it comes to Web-based InfoSec: SQL injections, XSS attacks, and server misconfiguration.
I wont copy the full list here, you can see the PDF yourself. To its credit, it does contain over 3 dozen best practices when it comes to security, all of them valid and worthwhile
Enhancing Cybersecurity Posture Post-DNC Hack
The most interesting part of the document is near the end, titled “How to Enhance your Organization’s Cyber Security posture. I will enumerate them here, because each one is notable. For better or worse, almost every single one of these posturings involve sharing (or receiving) information with (or from) a government agency.
Cyber Security Advisors (CSAs) are DHS personnel assigned to each of the 10 FEMA regions, tasked with cybersecurity preparedness, mitigation, and incident response.
Cyber Resilience Review (CRR) is a no-cost vulnerability assessment available for critical infrastructure sectors such as state or local governments.
Enhanced Cybersecurity Services (ECS) is a group that will actually share classified and sensitive threat models with with relevant professionals. Thus, critical infrastructure can be maintained and protected against novel attacks.
The Cybersecurity Information Sharing and Collaboration Program (CISCP) is a program of voluntary information sharing between operators of critical infrastrcture and the Federal Govt.
Automated Indicator Sharing(AIS) is much like CISCP, but it is an automated system that is triggered by threat indicators. The locally-hosted system will participate in two-way data sharing with the DHS, uploading information and downloading new threat models.
The Cybersecurity Framework is a NIST-created tool that provides standards, guidelines, and practices for an IT infrastructure.
Garbage men have reported that people often throw away interesting and valuable items. This raises two questions. First, how do we define “trash” on the Internet, and what interesting and valuable things can be found there? Karyn Benson, who spent the last 4 years working on her Ph. D in “internet trash,” otherwise known as Internet Background Radiation (IBR) answers these questions for us.
Note, this talk was so good and so relevant to cybersecurity that I decided to include it in the cybersecurity section of thie site as well.
Internet Background Radiation, or Internet Trash is simply unsolicited packets sent to your own IP addresses. This includes:
Scanning packets. Crawlers and probes send lots of unsolicited packets. Bro.org has a working definition of what a scanner is.
Backscatter. An attacker sends a sends a packet forged as one of your IP addresses, and the victim responds to you.
Misconfigurations. A host erroneously believes that the wrong machine is hosting a service.
Bugs. Bugs such as byte order bugs that simply send packets to the wrong destination.
Spoofed Traffic. Attackers mask their IP addresses to appear as if they’re coming from a different source.
Unknown. Just plain weird traffic like TCP non-standard ports or encrypted UDP packets.
How do we collect Internet Background Radiation
Researchers collect using “honeypots,” simply mock servers. You can configure your honeypot to respond like a normal host. You can also configure them not to respond at all and just collect one-way traffic. There are a number of specific ways to route incoming traffic internally that I won’t go into detail on here.
What Karyn and her team used was called a “Network Telescope,” which allowed all traffic in with no response, and stored all incoming packets for analysis. They collected a massive dataset from all over the world going back to 2008
Interesting and valuable items found in Internet Background Radiation
Revisiting the earlier list:
Scannertraffic correlates heavily to vulnerability announcements
The early data show worm releases such as Conficker on TCP port 455. In fact, the historical data show heuristically a probable test run of Conficker from a province in China, months before the worm was discovered. Later traffic moved to TCP port 23 (telnet), which may correlate to Internet-of-Things devices.
Backscatter data show that name servers are vulnerable to DDoS
An open resolver is a DNS server that resolves any DNS request, not just that of its own internal network. Spood traffic to Open Resolvers can be used to attack an authorative NS (like, say, Dyn) with no response cost to the user. Amazingly, this talk was given in August, well before the Oct 21 Dyn attack.
Misconfigurations, such as those caused by a BitTorrent Index Poisoning attack, can cause IBR.
False hosts inside of a BitTorrent Distributed Hash Table can give incorrect locations for torrets, causing the internet background radiation on Benson’s network telescope. 95% of the malicious hosts were in China.
Byte order bugs and careful packet inspection can reveal information.
Using these techniques and coordination with UCSD, they were able to determine that many packets came from Qihoo, a popular Chinese security software package. Qihoo versions containing said bug sent traffic to incorrect hosts. Benson’s team notified them of the bug.
By carefully inspecting the bytes of unknown packets, you can determine the source of traffic. Often times the source is a Botnet like Sality.
In addition to witnessing security related events, you can use techniques such as outage detection, DHCP lease duration analysis, and path change detection to further secure your systems.
It turns out running a single line of code can cost you tens of thousands of dollars. Meet the AWS Shield Advanced CreateSubscription call, which comes with a price tag of $36,000.
$36,000? You Can’t Be Serious. What is “AWS Shield Advanced?”
AWS Shield Advanced is the Rolls-Royce version of AWS Shield, which is simply a managed DDoS protection service. And yes, I am serious: It comes with a price tag of $3,000 a month (plus usage fees), and a minimum 12 month commitment. Luckily, AWS is fairly amenable to refunds if you make a mistake, so this is likely not a one-way street.
Is this really relevant to cybersecurity?
If it’s easy for a coder to cost their company $36,000 by making a simple mistake, then this becomes a security concern. Simply put: If an organization cannot provide operating capital to support a mistake like this, it will almost bring down resources or entire infrastructures. This is very relevant to cash-poor organizations like non-profits or startups.
Finally, I admit that I have a blind spot when it comes to non-aws AWS cloud providers. So, I’m curious to know: Do Google, Microsoft, IBM, Rackspace have similarly shocking API call costs? What’s the most expensive mistake you can make?
“For potentially affected accounts, the stolen user account information may have included names, email addresses, telephone numbers, dates of birth, hashed passwords (using MD5) and, in some cases, encrypted or unencrypted security questions and answers.”
Bob Lord, CISOI)https://yahoo.tumblr.com/post/154479236569/important-security-information-for-yahoo-users
Given that we now live in an era of “fake news,” it’s worth taking Lord’s claim of MD5 hashing into a bit of deeper consideration, especially when several other sources, from somewhat reputableII)http://www.theregister.co.uk/2016/12/15/yahoos_password_hash/, to not at allIII)https://www.onlinehashcrack.com/how-to-crack-gmail-yahoo-hotmail-account-the-truth.php, are claiming otherwise.
However, let’s just assume that if somebody says something that they at least believe it, the claim that this data was hashed using MD5 is severely egregious.
If you’re wondering: MD5IV)https://en.wikipedia.org/wiki/MD5 is an encryption function used to scramble or “hash,” and then store passwords in a database. MD5 has long been hacked, cracked, and broken six ways to Sunday.
One common and highly effective way of hacking this is using something called a Rainbow Table – this is simply a long list of MD5 hashes and the words they correspond to. In short, child’s play for even a novice hacker. To prove this point, all I had to do was google “MD5 Rainbow Table”V)https://www.google.com/search?q=MD5+rainbow+table&oq=md5+rainbow+table&aqs=chrome.0.69i59.2257j0j7&sourceid=chrome&ie=UTF-8 to find one.
In using this function and not a stronger one, Yahoo! is at best highly irresponsible and at worst criminally unethical, and 1B people just paid the price.
DynII)http://dyn.com/ is a well known and well-respected provider of managed DNS services. Organizations like Twitter, Amazon, and Shopify rely on it to make sure internet traffic is routed properly to their sites. The Mirai botnetIII)https://www.incapsula.com/blog/malware-analysis-mirai-ddos-botnet.html is an autonomous system that relentlessly tries to gain access to public systems. Mirai then executes custom code, taking control, and then carries on infecting even more systems.
On Oct 21, Mirai’s custom code was set to flood Dyn’s managed DNS infrastructure with packets on port 53. In a sense, this is like the thermal exhaust port in the Death Start – you take down Dyn, and organizations like Twitter, Amazon, Shopify, all suffer. This is what the hackers set out to do. Ultimately, whether or not they succeeded depends on where you were in the US and what sites you were trying to get to.
Let’s make this issue a little smaller so we can wrap our heads around it. First, imagine your organization has two locations, inside of which there is some Valuable Stuff. To protect your Valuable Stuff you install 4 wi-fi cameras at each location so you can see in every direction. Those cameras each have their own IP address on the network. Then, each camera sends video in the form of packets to a central server. This allows you to watch the feeds and keep an eye on who is approaching your Valuable Stuff.
Now, imagine that at any moment any one of those cameras can turn rogue and start spamming your server with meaningless packets. The intent is to max out your server’s bandwidth, RAM, or CPU (whichever fails first) and bring it to it’s knees. It’s a nightmare on the level of Invasion of the Body Snatchers – you have no idea who, or when. Hence, you can’t trust your trusted IP addresses.
So, what do you do with this? Let’s assume you’ve already taken the following actions:
Block any incoming internet traffic to the cameras and the servers via a firewall. It’s not hard for Mirai to get inside of your intranet – an email attachment can do it.
Maintain a default deny policy with server-side IP whitelists of where requests can come from. This highlights what’s so insidious about this botnet: it will turn trusted devices against you.
Here are some things you can do your end to further secure yourself against DDoS attacks:
Rate limit all client IPs. Each camera in our example will use some average amount of bandwidth under normal circumstances. You can use that average to set a bandwidth threshold you’re comfortable with. Dyn reported spikes of 40 or 50 times baseline during the attack
Use whatever influence you have to push for sane regulations on IoT devices. It’s hard to understate how crucial IoT security is now, and will remain into the coming decades.