Live data from Hacker News

So this guy is now S3. All of S3

chaos.social

291–300 of 522 posts

Re: So this guy is now S3. All of S3

#291

Earlier quoted context omitted.

I think crossdomain.xml died with Flash but I could be wrong, does anyone know?

None of the standardized web technologies use crossdomain.xml, but I think Acrobat Reader still uses it for... stuff. And acrobat still has a browser plugin, so I guess it's still a potential vector for abuse.

ah! Reader. That's a fun one. I once encountered an "Acrobat Reader-only" PDF that after filling out and selecting any applicable attachments on your filesystem you then... literally put in your credentials to the website in the PDF so that it could.. submit itself. I lost some braincells seeing that..

Re: So this guy is now S3. All of S3

#292
post #224
post #204

This is the second time one of my posts has caused issues for the chaos.social admins. I am so, so sorry. The hacker news DDOS is real. Previously: https://news.ycombinator.com/item?id=34691489

The interesting thing to consider is that someone who is popular to read may well be as much of a headache for the local sysop as someone who is a frequent target for attacks. How long until they have a 'bot that just 429s all of your posts on sight, do you think? (-:

Everything has happened before and will happen again: https://www.wired.com/2015/11/how-instagram-solved-its-justi...

Re: So this guy is now S3. All of S3

#293
post #240

Earlier quoted context omitted.

This post is on the front of HN. Many a larger website have succumbed to HN's warm embrace.

Isn't HN pretty small? This post has <400 upvotes over 3 hours. There can't be 1000x that amount of lurkers can there?

Indeed there are. Tens of us!

Maybe you underestimate how many people want to keep up on things but not interact?

Re: So this guy is now S3. All of S3

#294
post #3

For those not getting the context(like me), this seems to be about the Bluesky Social( https://bsky.app/ ), a twitter alternative.

Further context: Bluesky lets you use a domain name you own as a user handle. The official method is to set a TXT record, but apparently their "AT protocol" also lets you confirm a domain by serving `GET your.domainname.com/xrpc/com.atproto.identity.resolveHandle` and `xrpc` was available as an S3 bucket name :)

Yikes, why didn't they use a /.well-known/ address instead of inventing a new directory? This is entirely on Bluesky, not AWS.

Re: So this guy is now S3. All of S3

#295
post #163

Earlier quoted context omitted.

Both http and dns verification are stupid. Neither of them prove you own the domain. http verification proves you temporarily control IP space relative to a viewer. dns verification proves you temporarily control name resolution relative to a viewer. Both are trivially hacked, multiple ways. By the time someone finds out you did it ( if they closely monitor CT logs, which nobody does) you've already had hours, days,…

> I have been shouting about this for 10 years, none of the industry incumbents care. The internet is run by morons. Or maybe, just maybe, hear me out on this... maybe your proposal is not as smart as you think it is. For one thing: > Cert request signed by the private key of the domain owner, sent to the registrar to verify, the registrar signs it if its true What exactly does the registrar verify, and how?

The person who owns the domain creates a private key and uploads the public key to the registrar when they buy the domain. Literally a 68 byte string. Not exactly hard to store. The domain name itself may be longer.

The domain owner creates a CSR and signs it using their private key. Sends it to the registrar. The registrar uses the public key the user uploaded to validate the signature. This happens millions of times a day on shitty computers, this is completely old boring technology.

Now the registrar sends the Registrar-Signed-CSR back to the user. The user sends the RS-CSR to a CA. The CA uses the Registrar's public key to validate the Registrar's signature (exact same process as before). Now the CA can see the Registrar signed it, so it's legit.

Easy to automate. Boring old technology. Same flow millions of computers use every day, just with one extra party in the middle.

Re: So this guy is now S3. All of S3

#296

Earlier quoted context omitted.

None of the standardized web technologies use crossdomain.xml, but I think Acrobat Reader still uses it for... stuff. And acrobat still has a browser plugin, so I guess it's still a potential vector for abuse.

ah! Reader. That's a fun one. I once encountered an "Acrobat Reader-only" PDF that after filling out and selecting any applicable attachments on your filesystem you then... literally put in your credentials to the website in the PDF so that it could.. submit itself. I lost some braincells seeing that..

Oh man, then you really don’t want to know about a product I once created.

Reader could have an optional Flash plugin, and better yet, you could configure the PDF interactive plugin to dynamically download the swf file to run.

I built an entire Flex based rich UI that was dynamically loaded by the 1kb PDF you’d receive in email, the Flex app retrieved and posted data via HTTP APIs.

Because reasons.

That product was live for years. I think we shut it down as recently as 2 years ago.

To be 100% clear, wasn’t my idea.

But it was my mistake to joke about the absurd possibility to build such a thing in front of some biz folks.

Re: So this guy is now S3. All of S3

#297
post #140

Earlier quoted context omitted.

Both http and dns verification are stupid. Neither of them prove you own the domain. http verification proves you temporarily control IP space relative to a viewer. dns verification proves you temporarily control name resolution relative to a viewer. Both are trivially hacked, multiple ways. By the time someone finds out you did it ( if they closely monitor CT logs, which nobody does) you've already had hours, days,…

> ...dns verification proves you temporarily control name resolution relative to a viewer. > Both are trivially hacked, multiple ways. I'm genuinely curious how it is trivial to "control [authoritative] name resolution relative to a viewer".

Find out what the CA uses for its DNS resolver. Attack it with cache poisoning, or BGP spoofing, or compromise the account controlling the target domain's nameserver records, or trick some other system into making a record you want.

The BGP attack requires knowledge of internet routing and the DNS attack requires knowledge of DNS server exploits, but either of them can be executed with very minimal network access that any consumer can get. Target the nameserver account admin with a phishing attack, account reset attack, lateral password bruteforce, etc.

You'd be surprised how incredibly stupid the admins of some of the largest computer networks are. It's really not hard to get access to some accounts. It should require more than just a username and password to hijack a domain, but usually it doesn't.

In any case, if all you want is a valid cert, you can do it a number of ways that nobody will notice. Again, this only has to work once, on any one of 130+ different organizations. Not all of them have stellar security.

And I'm not even talking about social engineering either the CA, Nameserver, or Registrar's support people, which I consider cheating because it's so much easier.

Re: So this guy is now S3. All of S3

#298

Earlier quoted context omitted.

And given that bucket names are a giant shared namespace, there's absolutely an incentive toward lots of prefixing to help ensure you get the ones you want.

A while back I made one with a name like "postgresbackups" and was floored to realise later it was a global name.

To this day I don't know why it's a global name. For R2 we looked at this, saw the massive annoyance picking bucket names, and made it scoped to your account. CNAME records are orthogonal and can be set up to point to your bucket with a few button clicks.

Re: So this guy is now S3. All of S3

#299

Earlier quoted context omitted.

ah! Reader. That's a fun one. I once encountered an "Acrobat Reader-only" PDF that after filling out and selecting any applicable attachments on your filesystem you then... literally put in your credentials to the website in the PDF so that it could.. submit itself. I lost some braincells seeing that..

Oh man, then you really don’t want to know about a product I once created. Reader could have an optional Flash plugin, and better yet, you could configure the PDF interactive plugin to dynamically download the swf file to run. I built an entire Flex based rich UI that was dynamically loaded by the 1kb PDF you’d receive in email, the Flex app retrieved and posted data via HTTP APIs. Because reasons. That product was l…

oh looooooooooooord. O_O

Re: So this guy is now S3. All of S3

#300
post #289

Earlier quoted context omitted.

yah that's fine, but the replication to other domains does no good for the typical user on the web who only has a link to the original URL, clicks it, sees an error page, and then clicks away

I understand. In my view it will be important to have a fediverse URL protocol so that these links are not aimed at the original domain, and instead open at your home server, or in a mobile app connected to the home server.

Lol this is great.
Post reply on HN