i'm at an ai summit for my work, we're doing a hackerthon on abusing ai agents we develop.
i attempted to fork the dummy repository and was met with "You are unable to fork this repository at this time"; after this my co-worker went to view my profile and found that it 404s to anyone who is not logged in as my user.
went to submit a ticket to support.github.com & it redirected me to a specific reinstatement request support flow; wonderful.
i yearn for the day my company moves away from github and uses literally anything else, likely will be soon after this.
this is just... enumeration of phone numbers?
how is this a 'security vulnerability'? an issue maybe, but it's not a vulnerability as that implies faulty code; this is a documented feature.
I agree with this, but not the rest. It is not a security vulnerability, and I am not sure it being a privacy-sensitive endpoint either. Like someone pointed out, if you check one of your contacts and they have WhatsApp, you can tell, and you can message them from there. This is a feature.
I agree that there should be rate limiting of some sort.
For example, while everybody can physically go to your house and look at it from the street, somebody setting a webcam up and pointing it at the same house from the same vantage point would be a very different story and is illegal in many jurisdictions as a result.
Sure, they probably should implement it to be able to make it private, but then again, I do not trust Meta and I do not think you should trust it either, so if you get sent to jail for using it, you should probably be wary of it either way.
There are many alternatives to WhatsApp, you may want to try them. Briar, Ricochet Refresh, Session, Matrix (Element), Jabber (with OMEMO and whatnot), among many others.
Why isn't it a privacy and security problem if it is just done for a single phone number?
What is this was not WhatsApp, but it was a website or service dedicated to something unethical or illegal or just extremely embarrassing? Something that could ruin a marriage or career if it was known someone was a registered user? Would it be OK if someone could punch in phone numbers to find out who is registered on these sites?
What if someone automated and correlated this information to produce a profile for a phone number of all the shady/embarrassing services that phone number is associated with?
they claim to have achieved a rate of 7,000/s, which is roughly 25M/h
i do agree that is an absurd amount, especially when paired with the lack of rate limiting as discussed in their paper.
> "[...] Moreover, we did not experience any prohibitive rate-limiting. With our query rate of 7,000 phone numbers per second (and session), we could confirm 3.5 B phone numbers registered on WhatsApp [...]"
prior to my initial comment, i was under the impression they had encountered ratelimiting and bypassed it, it appears this initial assumption was incorrect.
i agree that it is ridiculous, though i faulter on calling it a vulnerability as in my eyes that term is specifically for unintended side affects / exploitation.
assuming a reasonable ratelimit, say 100 lookups per day (maybe some exceptions if the lookup results in an account that already has you in contacts, idk) - this would significantly reduce the amount of scraping that can be done.
contact lookup is a required function of whatsapp, the issue this paper highlights is that there is no protection against mass scraping
> The language says "safe" on the tin. It advertises safety.
Rust advertises memory safety (and other closely related things, like no UB, data race safety, etc.). I don't think it's made any promises about hard guarantees of other kinds of safety.
Rust has grown beyond its original design as a "memory safe" language. People are using this as an HTTP/RPC server programming language now. WASM serverless jobs, etc. Rust has found itself deployed in a lot of unexpected places.
These folks are not choosing Rust for the memory safety guarantees. They're choosing Rust for being a fast language with a nice type system that produces "safe" code.
Rust is widely known for producing relatively defect-free code on account of its strong type system and ergonomics. Safety beyond memory safety.
Unwrap(), expect(), and their kin are a direct affront to this.
There are only two uses cases for these: (1) developer laziness, (2) the engineer spent time proving the method couldn't fail, but unfortunately they're not using language design features that allow this to be represented in the AST with static guarantees.
In both of these cases, the engineer should instead choose to (1) pass the Result<T,E> or Option<T> to the caller and let the caller decide what to do, (2) do the same, but change the type to be more appropriate to the caller, (3) handle it locally so the caller doesn't have to deal with it, (4) silently turn it into a success. That's it. That's idiomatic Rust.
I'm now panicked (hah) that some dependency of mine will unwrap something and panic at runtime. That's entirely invisible to users. It's extremely dangerous.
Today a billion people saw the result of this laziness. It won't be the last time. And hopefully it never happens in safety-critical applications like aircraft. But the language has no say in this because it isn't taking a stand against this unreasonably sharp edge yet. Hopefully it will. It's a (relatively) easy fix.
kudos to getting this blog post out so fast, it’s well written and is appreciated.
i’m a little confused on how this was initially confused for an attack though?
is there no internal visibility into where 5xx’s are being thrown? i’m surprised there isn’t some kind of "this request terminated at the <bot checking logic>" error mapping that could have initially pointed you guys towards that over an attack.
also a bit taken aback that .unwrap()’s are ever allowed within such an important context.
1. Cloudflare is in the business of being a lightning rod for large and targeted DoS attacks. A lot of cases are attacks.
2. Attacks that make it through the usual defences make servers run at rates beyond their breaking point, causing all kinds of novel and unexpected errors.
Additionally, attackers try to hit endpoints/features that amplify severity of their attack by being computationally expensive, holding a lock, or trigger an error path that restarts a service — like this one.
this was in the middle of a scheduled maintenance, with all requests failing at a singular point - that being a .unwrap().
there should be internal visibility into the fact a large number of requests are failing all at the same LOC - and attention should be focused there instantly imo.
or at the very least, it shouldn't take 4 hours for anyone to even consider it wasn't an attack.
in situations such as this, where your entire infra is fucked, you should have multiple crisis teams working in parallel, under different assumptions.
if even one additional team was created that worked under the assumption it was an infra issue rather than an attack, this situation could have been resolved many hours earlier.
for a product as vital to the internet as cloudflare, it is unacceptable to not have this kind of crisis management.
