• meoward
  • Posts
  • 🐈 I only have 1 question for Confluence

🐈 I only have 1 question for Confluence

Who is disabledsystemuser?

Read time: 5 minutesChuckles: 12

Hi again, it's meoward – your inbox's weekly dose of security. Sometimes I delete the 's' in 'https' just to see life a bit more clearly.

On the stack this week:

  • πŸͺ² Confluence Vulnerability: a hardcoded password in an Atlassian Marketplace app with over 8k installs.

  • πŸ”Ž Google Search Ads: sometimes when you Google Search 'facebook' the top result brings you to a bad place (erm, well, a different bad place).

  • πŸ”’ DNS over HTTP/3: one step closer to DNS encrypted everywhere, and it's on Android.

  • 🧠 Learn Kubernetes security: there's an interactive playground where you (and your DevOps teams) can learn and practice securing K8's.

Chop, chop. Look lively now.

Hardcoded password in Confluence app

Questions for Confluence is an Atlassian Marketplace app for the popular enterprise wiki software Confluence. The app is basically a poor man's StackOverflow for your Confluence, adding the ability to post questions and answers.

It also adds a new user to your Confluence server, disabledsystemuser, with the hardcoded password of disabled1system1user6708. And despite the username, it's absolutely enabled by default.

So how did the researcher get the password? Brute force? Rainbow tables? Nah, it's right there sitting in plaintext in the default.properties file of the app's JAR file.


Why should I care?

Based on the poor reviews and lack of features, I'd say this app isn't installed on a lot of Confluence servers today. Unfortunately, uninstalling this app doesn't remove disabledsystemuser, so if this app was installed at any point this default account is probably still active. Certainly worth a quick check.

But what I found even more jarring (*ahem* JARring) is this app has gone through Atlassian's Cloud Fortified apps program, which includes a security self-assessment, ongoing vulnerability scanning, and a recent penetration test or code review.

Fortified in vitamin D – Default credentials

Looks real nice, but an automated code scan should have found these default creds. Which leads me to my next question...

How many other Atlassian apps are out there with hardcoded passwords?

Malvertising campaign hijacks popular Google searches

I can't spell. Wait, didn't you just decide to write a newsletter? Well sure, you see one overlooked modern wonder is that we have spell check everywhere. Documents, texts, emails, and in your browser.

But you know where there is no spell check? The address bar in your web browser. It's one of the reasons typosquatting – evil doers that register domains like facebokk.com – is super effective. So when I want to go to Facebook I type β€˜facebook’ instead of β€˜facebook.com’ in the address bar and blindly click that first Google result. It’s probably the only computer habit my grandma and I share.

The difference between my grandma's experience and mine? Her first result after searching β€˜facebook’ is usually an ad. And while that ad usually takes her to Facebook...

Threat actors have been successfully purchasing ad space for popular keywords like youtube, facebook, amazon, and walmart.

That electric scooter from 1916 is real btw

Why didn't Google catch this?

One word – cloaking. Once you click the ad, you're redirected to a site that determines if you're a person. Since ad policy violations are usually checked by automated scripts, the site checks things like:

  • is the traffic is coming from a residential IP address?

  • is the user-agent a web browser?

If the site determines the visitor is a machine, it redirects it to the legitimate facebook.com. Nothing to see here.

But if the site smells a meatbag, it redirects you to a series of malicious sites, usually ending in a browlock – a vicious chokehold that prevents you from using your browser and usually ends in extortion.

These threat actors are certainly well funded. Getting ads for keywords like these to the top of Google results isn't cheap.

Android gets DNS over HTTP/3

The Domain Name System (DNS) is the phonebook of the Internet. If that analogy feels old, it's because DNS has been around for awhile. And while most Internet protocols have migrated to using TLS, DNS still remains largely unencrypted.

But in the last few years, there's been some progress...

Two Contenders enter the ring

In one corner we have DoT, DNS-over-TLS:

  • He's got a sense of identity – his own port (853) so you know when he's talking

  • He's a little needy – requires developers to add support to the OS or add a new service

And in the other corner, DoH, DNS-over-HTTPS:

  • He keeps a low profile – his traffic is just like all your other web traffic

  • He's a modern man – web browsers can add support directly, no services needed

There's a hot debate over who should have access to this data (Big Tech vs ISPs) and whether user's should be given control over which DNS provider to use.

But the real reason we haven't seen widespread adoption? They're too slow.

Until Now.

Google announced DNS-over-HTTP/3 (DoH3) for Android 11+. HTTP/3 uses QUIC, a transport that efficiently multiplexes multiple streams over UDP using a single TLS session with session resumption. Wow.

In manager-speak: DoH3 beats DoT, and may even be more efficient than old-man-DNS on unreliable networks (T-Mobile). K.O.

To use DoH3 on your Android 11+ device, you'll have to choose either Google DNS or Cloudflare DNS.

Kubernetes is hard, let's go play in the sandbox

You know how Kubernetes works, right? Everybody is using it. I hear it makes you cool. Me? I wouldn't be caught dead deploying plain EC2 instances.

But you know what's not cool? Insecure configurations. Keys in the codebase. Overly permissive privileges.

But like G.I. Joe says, "knowing is half the battle." And America's Hero Madhu Akula has been working on a project called Kubernetes Goat – an interactive Kubernetes security learning playground. It has scenarios that highlight common misconfigurations, real-world vulnerabilities, and security issues in Kubernetes.

The scenarios are a lot of fun. Here's a few of my favorites:

  • ⎈ DIND (docker-in-docker) exploitation

  • ⎈ Kubernetes namespaces bypass

  • ⎈ Gaining environment information


  • 🎧 [podcast] How Google's detect & respond teams scale: automation, metrics, toil

  • 🀷 [blog] Dependency Confusion: build process attacks

  • πŸ‘€ [cheatsheet] Windows persistence: never leave, ok?

  • πŸ’° [thought] Technically Savvy Buyers are tough to convince (two words: prove it)

How did you like today's email?

Login or Subscribe to participate in polls.