Dec 31, 2020

What is IoC?

IoC stands for Indicator of compromise.

Indicator of compromise (IoC) in computer forensics is an artifact observed on a network or in an operating system that, with high confidence, indicates a computer intrusion.

Links:

  • https://en.wikipedia.org/wiki/Indicator_of_compromise
  • https://azeria-labs.com/iocs-vs-ttps/

 

What is TTP?

TTP stands for Tactics, Techniques and Procedures.

Tactics, Techniques, and Procedures (TTPs) is an essential concept in terrorism and cybersecurity studies. The role of TTPs in terrorism analysis is to identify individual patterns of behavior of a particular terrorist activity, or a particular terrorist organization, and to examine and categorize more general tactics and weapons used by a particular terrorist activity, or a particular terrorist organization.

Links:

  • https://en.wikipedia.org/wiki/Terrorist_Tactics,_Techniques,_and_Procedures
  • https://azeria-labs.com/iocs-vs-ttps/

Internet Exposure of DNS-over-TLS

DNS-over-TLS (DoT) (TCP/853)

Encrypting DNS is great! Unless it's baddies doing the encrypting.


TLDR

  • WHAT IT IS: DNS over TLS is just what it says on the tin: the DNS protocol embedded in a TLS connection, ostensibly to make your DNS request more confidential.
  • HOW MANY: 3,237 discovered nodes. A hodgepodge mix of vendor/version information was discernible, but you’ll need to read the details to find out more.
  • VULNERABILITIES: Whatever is in the DNS that backs the service or in the code that presents TLS (more often than not, a plain, ol’ web server).
  • ADVICE: It’s complicated (read on to find out why!)
  • ALTERNATIVES: Plain, simple, uncomplicated, and woefully unconfidential UDP DNS; DNS over HTTPS (DoH); DNS over QUIC (DoQ); DNS over avian carriers (DoAC).
  • GETTING: Drunk with power. There are nearly two times as many as April 2019.
At face value, DNS over TLS (henceforth referred to as DoT) aims to be the confidentiality solution for a legacy cleartext protocol that has managed to resist numerous other confidentiality (and integrity) fixup attempts. It is one of a handful of modern efforts to help make DNS less susceptible to eavesdropping and person-in-the-middle attacks.

Discovery details

We chose to examine DoT because web browsers have become the new operating system of the internet, and DoT and cousins all allow browsers (or any app, really) to bypass your home, ISP, or organization’s choices of DNS resolution method and resolution provider. Since it’s presented over TLS, it can also be a great way for attackers to continue to use DNS as a command-and-control channel as well as an exfiltration channel.

We chose to examine DoT versus DoH because, well, it is far easier to enumerate DoT endpoints than it is DoH endpoints. It’s getting easier to enumerate DoH since there seems to be some agreement on the standard way to query it, so that will likely make it to a future report.

In case you have been left unawares, Google is a big player] in the DoT space, but it tends to concentrate DNS exposure to a tiny handful of IP addresses (i.e., that bar is not Google-proper). When we filter out CleanBrowsing (yep, they’re everywhere), we’re left with the major exposure in Google being … a couple dozen servers running an instance of Pi-hole (dnsmasq-pi-hole-2.80, to be precise). Cut/paste that finding for OV and DigitalOcean and yep, that same Pi-hole setup is tops in those two clouds as well.

You don’t need to get all fancy and run a Pi-hole setup to host your own DoT server. Just fire up an nginx instance, create a basic configuration, set up your own DNS behind it, and now, you too can stop your ISP from snooping your DNS queries.

Exposure information

Here is where we’d normally talk about versions and CVEs, etc., but the DoT situation is complicated by a few things. First, we have big players in this space using proprietary solutions, so version fingerprints such as  “CleanBrowsing v1.6a” are not very useful information. Second, should we focus on the version of the web server or of the back-end DNS server (or, both)? The latter might not be useful, since you can configure an nginx DoT setup to proxy to a third party, and that’s what will get picked up in the response. 

Attacker’s view

There are no DoT honeypots in project Heisenberg, but DoT is just a TLS wrapper over a traditional DNS binary-format query. When we looked for that in the TCP/853 full packet captures, we saw us (!) and a couple other researchers. Not very exciting, but with the goal of DoT being privacy, we really shouldn’t see random DoT requests.

Attackers are more likely to stand up their own DoT servers or reconfigure other DoT servers to use their DNS back-ends and then use those as covert channels once they gain a foothold after a successful phishing attack. This is a big reason we enumerate/catalog DoT, and we’re starting to see more DoT in residential ISP space and traditional hosting provider IP space. It looks like more folks are experimenting with DoT with each monthly study.

Our advice

IT and IT security teams should block TCP/853, lock down DoT and DoH browser settings as much as possible so there is no way to bypass organizational IT policies, and monitor for all attempts to use DoT or DoH services internally (or externally). In other words, unless you’re the ones setting them up, disallowing rogue, internal DoT is the safest course.

Cloud providers should consider offering managed DoT solutions and provide patched, secure disk images for folks who want to stand up their own. (This is one of the few cases where organizational advice and cloud advice are quite nearly opposite.)

Government cybersecurity agencies should monitor for malicious use of DoT and provide timely updates to the public. These centers should also be a source of unbiased, expert information on DoT, DoH, DoQ (et al).

Links:

  • https://www.rapid7.com/blog/post/2021/01/15/nicer-protocol-deep-dive-internet-exposure-of-dns-over-tls/

Dec 30, 2020

Internet Exposure of memcached

 memcached (UDP/11211)

It's an easy-to-use DDoS Howitzer AND a NoSQL database!


TLDR

  • WHAT IT IS: An in-memory key-value store, used usually in caching website assets for geographically distributed websites.
  • HOW MANY: 68,337 discovered nodes. 68,337 (100%) have version fingerprints
  • VULNERABILITIES: 13 CVEs since 2011, but it has a wicked amplification DDoS issue we cover in the Exposure Information section.
  • ADVICE: Use it! Just don’t expose it to the internet.ALTERNATIVES: Redis and etcd are two similar, alternative in-memory key-value stores with characteristics similar to memcached.

Memcached is an in-memory key-value store for small chunks of arbitrary data (i.e., strings, binary objects) from results of database calls, API calls, or web page rendering. Its simple design has made it wildly popular, as it promotes quick deployment and ease of development.

Discovery details

Project Sonar found 68,337 exposed memcached hosts, and we did a double-take when we saw that South Africa is in third place, since we don’t often find it in any other top 10 lists of exposure. Most (97%) of these SA nodes are in two autonomous systems: Icidc Network (87%) and Internet Keeper Global (10%), and a majority of hosts in each autonomous system appear to have similar exposure counts in both nginx and SSH.

As noted in our section on Redis, Amazon has a cloud “cache” service offering that can also be configured to use memcached directly or emulate the exquisitely diminutive memcached protocol, and Alibaba has a managed memcached service offering, so it is no surprise finding some in those environments, but it is somewhat disconcerting that these instances are exposed to the internet. What’s more surprising is that OVH goes out of its way to help you secure memcached and, yet, ~1,500 folks apparently did not get that rather crucial memo.

Exposure information

Why all the fuss about memcached? Well, way back in 2018, an “Insufficient Control of Network Message Volume” vulnerability in the UDP portion of memcached was used to launch the largest distributed denial-of-service amplification attack ever, and disrupted many major internet services. Cloudflare summed up the flaw quite well in its blog at that time:


"There are absolutely zero checks, and the data WILL be delivered to the client, with blazing speed! Furthermore, the request can be tiny and the response huge (up to 1MB)."

Attacker’s view

While we do not have a memcached honeypot, we can see connection attempts on UDP 11211 and peek at the packet captures to see if memcached commands (most often, the stats one we use, though we occasionally see what look like misconfigured clients that are connecting to what they think are their memcached servers). The daily memcached command connections we see are mostly from Shadowserver, which is (correctly) self-described as a “nonprofit security organization working altruistically behind the scenes to make the internet more secure for everyone,” despite their scary name. They also scan the internet every day to try to get a handle on exposure and help organizations (for free) get a picture of their attack surface. We heart Shadowserver.

During the first third of 2020, we saw spikes of near 80,000 data-less UDP connections on 11211 across a handful of days, but none of this appears truly malicious in nature.

Our advice

IT and IT security teams should never expose memcached to the internet, and should ensure via playbooks and automation that development, test, and production memcached environments are rigidly controlled.

Cloud providers should continue to offer secure service alternatives to self-hosted memcached, ensure their provider-maintained machine images are kept patched with a default configuration of memcached only available on non-internet-exposed interfaces, and—frankly—not allow memcached to be exposed to the internet on host in their sphere of network control.

Government cybersecurity agencies should provide regular reminders about the dangers of memcached, offer guidance on how to run memcached safely, monitor for malicious use of memcached, and strongly encourage ISPs and cloud providers to block connections to memcached’s default port.

Links:

  • https://www.rapid7.com/blog/post/2020/12/07/nicer-protocol-deep-dive-internet-exposure-of-memcached/

Dec 29, 2020

Internet Exposure of etcd

etcd (TCP/2379)

Gleaming the Kube(rnetes)

TLDR

  • WHAT IT IS: Another distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines.
  • HOW MANY: 2,560 discovered nodes. 2,560 (100%) have version fingerprints
  • VULNERABILITIES: Two low-to-moderate CVEs since 2018.
  • ADVICE: Use it! Just don’t expose it to the internet.
  • ALTERNATIVES: Redis and memcached are two similar, alternative in-memory key-value stores with characteristics similar to etcd.

The etcd key-value service is part of the Kubernetes ecosystem and is designed to hold system/service configuration and state information. The Kubernetes API Server uses etcd's watch API to monitor the cluster and roll out critical configuration changes or simply restore any divergences of the state of the cluster back to what was declared by the deployer. It exposes a JSON API over the HTTP protocol.

We’re including etcd for completeness (since we’ve mentioned in the previous blogs on Redis and memcached), but the sample size is way too small to dig into, since we have no data on which ones are honeypots and which ones are real.

Just like the other two key-value databases, etcd should never be exposed to the internet. Unlike the previous two services, etcd tends to be purpose-driven for Kubernetes orchestration environments, which is another great reason not to expose it to the internet directly.

Links:

  • https://www.rapid7.com/blog/post/2020/12/10/nicer-protocol-deep-dive-internet-exposure-of-etcd/

Dec 19, 2020

Incident Mgmt Vs Vulnerability Mgmt

Everyone agrees that Incident Management is different than Vulnerability Management. But yet still people mix them up when things happen.

Recently, SolarWinds supply chain attack has becomes the hottest topic in the month of December 2020 for Cybersecurity world. With the SUNBURST or SuperNova backdoors found, it is obviously becomes an incident (rather than a vulnerability) if your company is using the affected products. With the investigation is still ongoing, more affected products might be included in the list.

But, why people try to manage the SolarWinds case with vulnerability management? Is it because everyone is more familiar with vulnerability remediation process.

Yes, both incident management and vulnerability management has the remediation process. However it is performed by different teams. The remediation process for an incident is performed by Cybersecurity team, while the remediation process for a vulnerability is performed by IT team.

I guess people just thought that the all remediation process are the same.

Why people mix them up so easy?

I think it is due to sophisticated Cybersecurity team structure. And there is monthly remediation reminder that continuously reminding us on the remediation process. People just like to engage with what they are familiar with.

If your company is using a vulnerability management process to handle the SolarWinds attack or incident, then you should start think about simplifying your Cybersecurity teams. 

Dec 5, 2020

Retirement of Enhanced Security Admin Environment ESAE

Today, I just found that Microsoft has stopped their ESAE strategic architecture. Microsoft has recommended new strategy to complements any existing ESAE implementation. 

The Enhanced Security Admin Environment (ESAE) architecture (often referred to as red forest, admin forest, or hardened forest) is an approach to provide a secure environment for Windows Server Active Directory (AD) administrators.

In early 2018, where I first learned about ESAE. After a deep dive evaluation, my conclusion is, it is too costly to implement such a solution, in term of operating cost, for most of the company (even it is a secure strategy). This is simply because the strategies have never consider the essential security concept. #EssentialSecurity 

And after 3 years, Microsoft has admitted that the ESAE architectural pattern is only valid or applicable in a limited set of scenarios. Any organization who implement ESAE architecture, must accept the increased technical complexity and operational costs of the solution. 

The ESAE retirement post can be found at https://docs.microsoft.com/en-us/security/compass/esae-retirement


Dec 1, 2020

GUI bug in KennaSecurity

There is a minor bug found at the Kenna's user interface that I encounter today.

To simulate the bug, from the Dashboard, look for any Kenna meter that has zero asset count (or you can create one), click on it to explore the asset/vuln list. And you will found that most of the filters are missing at the Explore page, such as:

  • (Asset Filters) Active/inactive
  • (Asset Filters) Tag
  • (Asset Filters) Sort by (everything)
  • (Vulnerability Filters) Status
  • (Vulnerability Filters) Classification
  • (Vulnerability Filters) Connector names .....
  • (Vulnerability Filters) custom fields.....

 😞😞