abigailphoebe

Hi all, I recently went viral on Twitter due to my solution for detecting and removing a very common scam on Discord, in the process of deployment I found that a little over 8% of all images sent on Discord are scams (8.3%).

I wrote a blog post about it, would appreciate some feedback!

I'm also chronically unemployed at the moment, so if you read this and need someone to work on anti-abuse, or an overall skilled developer, please reach out!

i made a nice little write-up in addition to my paper on analyzing historical software metrics - would appreciate some feedback as this is my first 'technical' writeup. the 4 page paper is attached at the bottom of the article along with the github link to the actual test suite.

i personally host my own git instance for all my important projects, i'm just forced to use github for work.

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.

ehh, not really.

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

eh, i'm not convinced.

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.

that's actually a very good point, fair enough, i agree.

regretfully i'm not sure if such a big language change can be made; though it would be nice.

here's to hoping!

just read the pre-print paper.

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.

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.

you either misunderstand the rust ethos or are intentionally misrepresenting it.

safe refers to memory safety.

once again, if you write bad code, that’s your fault, not the languages. this is a feature of rust that was used incorrectly.

blaming the language is not the way to approach this. if an engineer writes bad code that’s the engineers fault, not the languages.

this was bad code that should have never hit production, it is not a rust language issue.

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.

would appreciate some insight!