Break another CTF by taking over its machine | Hacker News Reader

Break another CTF by taking over its machine

github.com

37 pointsseadog00715 comments

Open articleView on HN

> When I was play noxCTF 2018, I saw a challenge named PSRF, then I thought that might be SSRF, PostScript, or both.

Wow, talk about having no context! You need to do at least three Google searches just to parse the first sentence.

EDIT: Realized my comment was not constructive. For context, might be helpful to make some of the acronyms into links!

Sorry about that, what is your suggestion?

Before your reply, I will add some explain for these terms

An introductory paragraph, as umvi suggested, would be very helpful.

Also, please don't use sockpuppet accounts to upvote HN submissions. That's not allowed here, and we ban accounts that do it.

Write an introduction paragraph that gives context for non security researchers/penetration testers/etc.

I just added a brief intro. I don't think everyone should understand the technique detail, but if that want, they will

SSRF should be well known to anyone familiar with web app vulnerabilities, and PostScript is a programming language that's been around since 1982. Not exactly arcane terms. And noxCTF can reasonably be assumed to be a security CTF competition, even if you aren't familiar with the specific CTF.

Well, I think if all developer know about these vulnerabilities, then there are no more bug bounty that we can play. Then it might be helpful to put some intro of these terms.

But still, I except people who click the link should already understand these terms.

I cannot overstate how much I despise these “helpful” cloud agents. They are useful for experimentation to update user accounts (SSH keys, etc. — GCP uses for its web shell as well), but they are a nightmare for production use. They are a very straightforward path from cloud account compromise to instance takeover.

Azure pulls the same trick. AWS seems fine.

I'm a bit confused by this:

> The challenge has kubernetes logo on the bottom of the page like the screenshot below, and the IP is 35.241.245.36.

> I immediately realized that is a GCP machine, so I tested the backend server by sending HTTP request to my server to see if it is also on GCP, and it is.

What about the IP address or k8s logo made you realize it was a GCP machine?

A whois on the 35.241.245.36 returns a ownership by Google with the following comment:

Comment: * The IP addresses under this Org-ID are in use by Google Cloud customers *

He then uses the SSRF to issue a request to his own server after which he likely realizes that the IP address belonging to the backend service also runs on GCP.

After working with AWS a ton, I commonly spot their IP addresses while reviewing random data sets. 50., 52., etc... This person has probably just worked with GCE a bit.

I think both make me think this is a GCP machine. like if you see a A record point to 104.xx.xx.xx, then you might think this is a Cloudflare protected record.

Could this have been harder to do if the insecure server inspected the HTTP content-type and response body in the response? Something like this (psuedo-code):

  if response.content_type =~ /image-/i && !plain_text?(response.body)
    pass
  else
    fail!()
  end

I could be, but I really don't know the designed solution.

Reply on news.ycombinator.com