141–150 of 291 posts
How did they manage to steal coins if they didn't get a valid cert? Did people logging into MyEtherWallet just ignore the invalid cert warnings and log in anyway?
Earlier quoted context omitted.
>HSTS wouldn't help users clicking through warning Actually it would have! Chrome and possible other browsers do not allow clicking throw certificate validation issues on sites with HSTS. For example, try to get to https://badssl.finn.io in Chrome.
Sorry how does that help if the attackers purchase a new "valid" SSL certificate since they control the DNS and thus email?
A website I own was affected by this. I got an alert from our monitoring saying the website was down for 1hr 2min 59sec. Luckily, they didn't redirect it to anything. I have other domains using Route53 (and hosted at AWS, just like this one).. that weren't affected AFAICT.
> I got an alert from our monitoring saying the website was down for 1hr 2min 59sec. That's a very accurate time. What system do you use to allow sampling at under 1 second intervals? My nagios boxes poll every minute, so an outage could be 2 seconds, or nearly 2 minutes, and nagios would report the downtime as 1 minute.
Getting a basic certificate issued is incredibly easy these days. If you own the DNS resolution, you can get a cert. Here a few ways I can think of to make this harder for an attacker: * Add a Strict-Transport-Security to all HTTPS requests. This means the attacker will need to get a valid cert (still easy if you can hijack BGP). * Pick a preferred SSL issuer and stick with them. Add a CAA DNS record only allowing th…
If I control the network, I can strip off any security that might be in DNS. I can change or remove CAA records, DNSSEC, etc. Those things currently fail open, which exception to DNS replication which will take "refresh" time to fail. I can then get new certs for the DNS I now control. HSTS just means use HTTPS. It doesn't validate the previous cert. That is HPKP which almost nobody uses unless they control the clien…
I thought HPKP is TOFU, not (necessarily?) preloaded? Meaning you don't need to control the client for the client to be able to take advantage of it?
It's sad that HPKP is being deprecated. It's one of the best ways to defend against an attacker with bgp hijack capabilities assuming you pin your own public key. Difficult to scale though and prone to disastrous misconfiguration.
Getting a basic certificate issued is incredibly easy these days. If you own the DNS resolution, you can get a cert. Here a few ways I can think of to make this harder for an attacker: * Add a Strict-Transport-Security to all HTTPS requests. This means the attacker will need to get a valid cert (still easy if you can hijack BGP). * Pick a preferred SSL issuer and stick with them. Add a CAA DNS record only allowing th…
Forgive my ignorance but I have a few questions: * Why would HSTS help in this case? While HSTS is active, does it prevent clicking through the warning (which was done here)? * How would a CAA record help against cert issuance in this case? Is it only helping against compromise of the authoritative during the remaining TTL of the record in recursives AND if the CAA record points to something that doesn't have on-dema…
Surely related (and warning!): During this period I received an email from: ship-confirm@amazon.com purporting to notify me of the despatch of a non-existent order; with an attached .zip. Nothing about the message, except the .zip and suggestion of an order's existence, was at all suspicious - all links point to amazon.com. I checked on amazon.com (without following a link) and on amazon.co.uk (where I would usually…
That's just regular spam. I bet if you checked you would see the email was not actually sent by Amazon, and did not have a DKIM signature.
can someone ELI5 how this works? like, how do they physically do this ?
It is extremely unlikely that they did what this article claimed. If they did, this is what would have happened (this ignores specific implementations which may make certain parts of this impossible which in turn would completely block this kind of attack): 1. Attackers would have noticed that either AWS does not register their prefixes or some of the prefixes were not registered or their registered policies did not…
https://stat.ripe.net/205.251.192.0%2F24#tabId=routing
As far as I know, most of ASNs only filter routes coming from their direct customers (if even that and even in that case they are likely to accept those prefixes from their own peers), so once route gets into the tier 1 ISPs routing tables, it's going to be propagated pretty much everywhere.
Earlier quoted context omitted.
wait, myetherwallet doesn't use HSTS? I thought they had a vulnerability analysis done a few months ago. I feel like this should have been something that was caught.
Wow, that's scary. I even told someone recently, jokingly of course, they forgot to add HSTS for their mvp app. But MEW doesn't have HSTS? I would never use it personally on a public Wifi, but many people will for sure and they have no idea they'd be MITM'd.
Even without HSTS a bad actor would have to either trick a user to install a root cert or trick a certificate authority to generate a cert for the domain. Both of these are possible and have happened in the past, but they're also are a requirement for the attack you mention that you seemed to have completely forgotten about.