Add redpwnc.tf

[ginkoid]

• Description of Organization

• Reason for PSL Inclusion

• DNS verification via dig

• Run Syntax Checker (make test)

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration.

Description of Organization

Organization Website: https://redpwn.net

redpwn is a team which competes in security competitions known as CTFs. redpwn organizes an annual competition, redpwnCTF. I help organize the competition and am responsible for parts of its infrastructure.

Reason for PSL Inclusion

redpwnCTF uses the domain redpwnc.tf to host security challenges for competition participants. Subdomains of redpwnc.tf are used for intentionally insecure services that are designed to be compromised. To isolate participants from each other and provide cookie security, we would like to add redpwnc.tf to the PSL.

redpwnc.tf expires on 2023-03-24, which is 2 years from today.

DNS Verification via dig

dig +short TXT _psl.redpwnc.tf
"https://github.com/publicsuffix/list/pull/1241"

make test

Local tests have passed.

[ginkoid]

Hi @dnsguru,

Is there anything else I should do to help get this merged? Thanks!

[dnsguru]

Hi Philip

This does not match our typical large project profile for permanent or semi-permanent entries. Due to the file being consumed, used and integrated by a vast number of projects, libraries and systems, there is a focus on modest file size and the scale of project and audience are a consideration in the inclusion. This is the case with initial list submitters. We volunteers do try to process the requests quickly, but some require a few more cycles than others.

I've asked some of the colleague volunteers to approve on this request as I am a little tied up on "#dayjob".

Is there an estimate on how many hundred/thousand +more people this entry will be used by?

[ginkoid]

Last year, approximately 7 thousand people participated in the competition. We're expecting 10-12 thousand participants for this year's event. We will create approximately a dozen subdomains on redpwnc.tf for each participant, one for each cybersecurity challenge.

[sleevi]

Can you provide more details here? I’m trying to understand how this is different from a “dev” or “testing” setup; it seems like this is a limited use scenario, and it’s also unclear the necessity of separation here, since these are all known-insecure services.

[ginkoid]

Each annual competition serves production users from many competing teams. The teams are not testers or developers internal to redpwn.

Each service is an entirely seperate application with different vulnerabilities. Without the PSL entry, intentional vulnerabilities in one service can introduce unintentional vulnerabilities in other services due to a lack of cookie isolation. The PSL entry allows each service to be probed on its own without being affected by other services or other teams.

[sleevi]

I’m still not sure I understand what sort of side effects you’re imagining? If teams have their own server instances, why would they navigate to other team’s instances? And given it’s a CTF, why would this be a bad thing?

[sleevi]

And I understand it’s a competition, but it’s a competition with testing instances, which seems... more or less the same?

[ginkoid]

As an example of a side effect, consider two CTF challenges. One of them (challenge 1 at challenge-1-abc.redpwnc.tf) has an XSS vulnerability. The other (challenge 2 at challenge-2-xyz.redpwnc.tf) has an endpoint which is protected by an anti-CSRF token stored in a cookie.

A competitor has successfully exploited challenge 1 but has not exploited challenge 2. Without the PSL entry, the competitor can use the XSS in challenge 1 to set a CSRF token in a cookie on redpwnc.tf. This cookie is later sent to challenge-2-xyz.redpwnc.tf. This allows the competitor to fixate the CSRF token, bypassing the intentional solution to challenge 2.

This unintentional vulnerability in challenge 2 is a result of the lack of cookie isolation between the two challenges. It would not be possible for an attacker to accomplish this in an actual application outside of the CTF format, as differing applications would have unique eTLD+1 domains.

I'm not sure what testing instances means. Each challenge instance is set up like a real, production application.

[sleevi]

Right, but that “attack” doesn’t expose any risk to users - it just means you have to get creative with your challenges, or let teams supply their own base domain for the challenges (e.g. to a dynamic DNS instance already on the PSL). Given that the scenario you just described is an (intentional) vulnerability in the server code, I fail to see how client filtering is going to make any difference at all with respect to the actual challenges. This is because teams can always just use a tool like cURL or wget for their challenges.

Further, outside of your CTF participants, no one is going to be affected by this. That is, even if every person on the Internet joined a team at your site, there would still be both no harm to those users (no breaches, loss of data, etc) and no need for the billions of clients that ship the PSL to include your domain, as they would never even access it (e.g. chat apps, command-line tools, web servers - they’re never going to load those CTFs, right?)

I know this seems like a lot of pushback, but I’m also trying to reason through the harm of saying “no”. I want to make sure I’m understanding scope and risk, since as has been mentioned already, there’s also downside to saying “yes”.

[ginkoid]

Client filtering based on the PSL is important because the challenges are visited by a headless Chromium instance controlled by the competition organizers which is a substitute for a privileged human admin. After participants submit their URL, the headless Chromium sets a cookie on the known challenge domain (a subdomain of redpwnc.tf) before visiting the competitor-provided URL.

We could use a custom Chromium build with a custom PSL to handle this, but competitors wouldn't be able to fully test their solutions on their own computers. Distributing the custom Chromium to competitors wouldn't work, especially because the competition is targeted at students, who frequently have school policies which restrict running programs.

The competitor-supplied domain technique also wouldn't work as competitors could simply read the cookie containing the flag or admin token by updating their DNS records after the validation we perform on the domain.

While it's true that this PSL entry wouldn't be relevant to non-web browser clients, that's also true about many other sites on the PSL. If every person on the Internet joined the competition and we didn't have the PSL entry, some competitors would gain an unfair advantage using unintentional solutions due to the lack of cookie isolation.

[sleevi]

The competitor-supplied domain technique also wouldn't work as competitors could simply read the cookie containing the flag or admin token by updating their DNS records after the validation we perform on the domain.

But this is true for your own domains, regardless of the PSL, right?

I’m still trying to understand concretely the benefit here. It seems if you have the server verifying solutions, and you can patch the headless Chromium there, then you’ve already covered “cheating” competitors. At that point, it seems like the only benefits are

1. Preventing teams from interfering with each other.

• This seems both unlikely and yet also easily fixed. A user just needs to delete their cookies.

2. Prevent well-intentioned users from thinking they found a right solution by messing with document.domain or setting cookie scope, when the “expected” solution is something else.

• This seems easily addressed through documentation and your server verification of solutions. You don’t need to distribute custom builds, if you just rule certain things out of scope of the competition.

I know it probably feels like I’m being difficult, but it seems worth asking here.

[ginkoid]

But this is true for your own domains, regardless of the PSL, right?

DNS records on redpwnc.tf are controlled by the competition organizers. Competitors are not able to modify what IP address the subdomain references. The cookie from the headless Chromium is only set on the known subdomain, not on the URL that competitors submit.

This seems both unlikely and yet also easily fixed. A user just needs to delete their cookies.

The competition is targeted towards high school age students. For many competitors, this is their first introduction to cybersecurity. Therefore, we can't expect competitors to recognize that they need to clear their cookies, especially on school-managed computers where DevTools might be disabled. This has been a problem in prior competitions.

This seems easily addressed through documentation and your server verification of solutions. You don’t need to distribute custom builds, if you just rule certain things out of scope of the competition.

We actually want competitors to solve some challenges using cookie scope or document.domain. If redpwnc.tf is on the PSL, this could easily be accomplished by using subdomains similar to a.xyz.redpwnc.tf and b.xyz.redpwnc.tf. Universally ruling this type of attack as out of scope but then providing an exception for a specific challenge is both confusing to competitors and provides a very large hint for the specific challenge.

[sleevi]

I hear you, but you’re saying this is important enough to justify billions of devices and applications need to know about your CTF, now and likely for quite some time.

I totally appreciate that closing this as WontFix could lead to some inconvenience and some competitions not being as challenging as you want. But wouldn’t that be better than taking this route, affecting everyone else?

[ginkoid]

From what I can tell, entries are added to the PSL primarily due to the intended purpose of the domain owners, not a user count. For example, even though a web hosting startup might not have many users, the purpose for their entry on the PSL is well-understood. Therefore, as long as the domain is renewed, the web hosting startup will keep its entry on the PSL, regardless of how many users the company has at any time.

redpwnCTF is a yearly competition (this is the 3rd year) that I hope continues for many years. Although the event lasts only a week, we plan to keep this year’s challenges running until the next year’s competition. This effectively makes the event a year-round cybersecurity training platform, equivalent in usage to a small web hosting company.

[sleevi]

due to the intended purpose of the domain owners, not a user count.

Yes, and I’ve tried to capture from the start that the concern is very much with purpose. This feels very similar to cases where companies want their private use domains added, which are only internal to their network.

The “use” part is about trying to understand risk to actual users, since the purpose of inclusion - and why it’s used in billions of software installs - is to reduce that risk. It’s sounds very much like there is absolutely zero risk to users here.

[ginkoid]

Alright, that makes sense. Thanks for your time.