4 ms·

I've complained about this in the past (and was attacked for it). I'll do it again. If you create a subdomains under your trusted domain, and point those domai

I've complained about this in the past (and was attacked for it). I'll do it again. If you create a subdomains under your trusted domain, and point those domains to IP address controlled by scammers - you bear some responsibility for the resulting mess. The Epic claims are pure PR spin. Epic claimed "these rumors amounted to a paid commercial smear to harm Houseparty, announcing on their Twitter account, that a million-dollar bounty was being offered to “the first individual to provide proof of such a campaign.”" An individual offered clear proof that Epic was pointing houseparty domains to scammers who were using that to steal folks info, the exact situation users were complaining about. These are domains UNDER EPICS TOTAL CONTROL being pointed to scammers. They now claim they still found no evidence of a campaign against houseparty users by a hacker group - and this was all a "paid smear campaign". Who believes these PR people -seriously? If Amazon takes payments.amazon.com and point it to Scammer IP XXX, how does that NOT create a vulnerability?

JumpCrisscross 6y ago
> you bear some responsibility for the resulting mess But is it a compromise of the app? I'm failing to see the nexus between Houseparty, the app, and these subdomains. How does someone using the app end up on the subdomain?
- T3OU-736 6y ago
  Arguably, yes. At a minimum, poor security measures. "Certificate Pinning" and/or HSTS both help, and there are other measures.
- kstrauser 6y ago
  This is speculation, but I think reasonable: - Houseparty spins virtual servers up and down quickly to respond to changing demand. - They have a DNS TTL that's longer than the draining time for those VMs. Like, maybe they it takes them five minutes to kill a VM but DNS records are cached for an hour. - The attacker takes advantage of that window to spin up a bunch of tiny VMs and see if any of them are allocated one of the IPs that Houseparty recently abandoned. If so, then they fire up Nginx and serve poisoned PDFs to anyone who connects to it. - An end-user's app connects to "ephemeral-vm-837.houseparty.whatever" and gets the cached value that their ISP is still serving, because Epic configured their DNS to tell the ISPs to cache it for an hour, except now that IP is served by the attacker instead of by Epic. Mitigating this could be as blunt as setting DNS TTLs to 5 minutes, then putting "sleep 300" at the start of each server's shutdown script. When you decide to kill a server, first kill its DNS record so that nothing refers to it anymore, then start the waiting period before actually removing it from rotation.
  - eh78ssxv2f 6y ago
    > If so, then they fire up Nginx and serve poisoned PDFs to anyone who connects to it. Even if the attacker redirects the traffic, it still needs to serve the HTTPS/SSL certificates. How will the attacker do that?
    - kstrauser 6y ago
      Maybe it does? It could be serving plaintext HTTP ("why would we encrypt our logo.png file?"), or the client library could be configured to accept any valid SSL cert because they don't want to deploy good certs to every ephemeral host they spin up. There are a lot of ways this could go wrong.
      - eh78ssxv2f 6y ago
        Agreed. In my mind, if the server is using plain HTTP, and the attacker has control over parts of the network, then plain-old DNS is not the only attack model. The attacker does not need to hack DNS, they can just manipulate the content on the wire.
    - munchbunny 6y ago
      I believe LetsEncrypt will issue you a certificate for that subdomain if you can control the server responding at that subdomain. EDIT: Specifically: https://letsencrypt.org/docs/challenge-types/ https://letsencrypt.org/docs/challenge-types/ It won't give you a wildcard certificate, but you don't need one for the type of attack we're talking about.
      - sroussey 6y ago
        Well, hopefully they use certificate pinning. And if not, they should do certificate transparency like chromes does.
  - toast0 6y ago
    > Mitigating this could be as blunt as setting DNS TTLs to 5 minutes, then putting "sleep 300" at the start of each server's shutdown script. When you decide to kill a server, first kill its DNS record so that nothing refers to it anymore, then start the waiting period before actually removing it from rotation. If I had a dollar for everytime traffic stopped to an IP after the DNS ttl expired, I wouldn't have any dollars. After taking IPs out of DNS for www.popular site, I would continue to see traffic for weeks, and the TTL was set for somewhere like 5 minutes, an hour tops. Edit: also, when we moved our authoritative DNS, the old provider kept seeing queries for at least 6 weeks. If the only thing preventing you from sending private data or receiving trusted data is that it came from an IP you got from DNS, it's not secure.
- dumbfounder 6y ago
  Who cares if it is a compromise of the app or of their methodology for hosting content? I think it's still their responsibility to make sure their subdomains are not hijacked. What would happen if google.com let one of their IPs slip like that?
  - cududa 6y ago
    It’s bizarre to me people are making such a strong distinction between backend infrastructure and client app. Almost feels like some pre-defense mechanism?
- thoraway1010 6y ago
  You target people using the app. If you had control of verify.paypal.com you'd target people using paypal apps. Even though it's not a compromise of the app argueably it's a concept of the app platform. Users's don't make these distinctions. They install the app, they get a message on the app to go to the apps domain to verify their info (email / 2 factor authentication). They are NOT then checking that the subdomain was released and got a new IP recently (or didn't get an IP). These PR people love to split these hairs. Our app is secure - but we leaked 100% of your data out of our back-end servers when they were hacked for 3 months - is another one that's common.
bradly 6y ago
I believe GitHub had a related vulnerability years ago before GitHub Pages had their own domain.

JumpCrisscross 6y ago

> you bear some responsibility for the resulting mess But is it a compromise of the app? I'm failing to see the nexus between Houseparty, the app, and these subdomains. How does someone using the app end up on the subdomain?

T3OU-736 6y ago
Arguably, yes. At a minimum, poor security measures. "Certificate Pinning" and/or HSTS both help, and there are other measures.
kstrauser 6y ago
This is speculation, but I think reasonable: - Houseparty spins virtual servers up and down quickly to respond to changing demand. - They have a DNS TTL that's longer than the draining time for those VMs. Like, maybe they it takes them five minutes to kill a VM but DNS records are cached for an hour. - The attacker takes advantage of that window to spin up a bunch of tiny VMs and see if any of them are allocated one of the IPs that Houseparty recently abandoned. If so, then they fire up Nginx and serve poisoned PDFs to anyone who connects to it. - An end-user's app connects to "ephemeral-vm-837.houseparty.whatever" and gets the cached value that their ISP is still serving, because Epic configured their DNS to tell the ISPs to cache it for an hour, except now that IP is served by the attacker instead of by Epic. Mitigating this could be as blunt as setting DNS TTLs to 5 minutes, then putting "sleep 300" at the start of each server's shutdown script. When you decide to kill a server, first kill its DNS record so that nothing refers to it anymore, then start the waiting period before actually removing it from rotation.
- eh78ssxv2f 6y ago
  > If so, then they fire up Nginx and serve poisoned PDFs to anyone who connects to it. Even if the attacker redirects the traffic, it still needs to serve the HTTPS/SSL certificates. How will the attacker do that?
  - kstrauser 6y ago
    Maybe it does? It could be serving plaintext HTTP ("why would we encrypt our logo.png file?"), or the client library could be configured to accept any valid SSL cert because they don't want to deploy good certs to every ephemeral host they spin up. There are a lot of ways this could go wrong.
    - eh78ssxv2f 6y ago
      Agreed. In my mind, if the server is using plain HTTP, and the attacker has control over parts of the network, then plain-old DNS is not the only attack model. The attacker does not need to hack DNS, they can just manipulate the content on the wire.
  - munchbunny 6y ago
    I believe LetsEncrypt will issue you a certificate for that subdomain if you can control the server responding at that subdomain. EDIT: Specifically: https://letsencrypt.org/docs/challenge-types/ https://letsencrypt.org/docs/challenge-types/ It won't give you a wildcard certificate, but you don't need one for the type of attack we're talking about.
    - sroussey 6y ago
      Well, hopefully they use certificate pinning. And if not, they should do certificate transparency like chromes does.
- toast0 6y ago
  > Mitigating this could be as blunt as setting DNS TTLs to 5 minutes, then putting "sleep 300" at the start of each server's shutdown script. When you decide to kill a server, first kill its DNS record so that nothing refers to it anymore, then start the waiting period before actually removing it from rotation. If I had a dollar for everytime traffic stopped to an IP after the DNS ttl expired, I wouldn't have any dollars. After taking IPs out of DNS for www.popular site, I would continue to see traffic for weeks, and the TTL was set for somewhere like 5 minutes, an hour tops. Edit: also, when we moved our authoritative DNS, the old provider kept seeing queries for at least 6 weeks. If the only thing preventing you from sending private data or receiving trusted data is that it came from an IP you got from DNS, it's not secure.
dumbfounder 6y ago
Who cares if it is a compromise of the app or of their methodology for hosting content? I think it's still their responsibility to make sure their subdomains are not hijacked. What would happen if google.com let one of their IPs slip like that?
- cududa 6y ago
  It’s bizarre to me people are making such a strong distinction between backend infrastructure and client app. Almost feels like some pre-defense mechanism?
thoraway1010 6y ago
You target people using the app. If you had control of verify.paypal.com you'd target people using paypal apps. Even though it's not a compromise of the app argueably it's a concept of the app platform. Users's don't make these distinctions. They install the app, they get a message on the app to go to the apps domain to verify their info (email / 2 factor authentication). They are NOT then checking that the subdomain was released and got a new IP recently (or didn't get an IP). These PR people love to split these hairs. Our app is secure - but we leaked 100% of your data out of our back-end servers when they were hacked for 3 months - is another one that's common.

bradly 6y ago

I believe GitHub had a related vulnerability years ago before GitHub Pages had their own domain.