Posted by ssiddharth 1 hour ago
This turn was an AI exploit, in my case was an outsourcing support 'exploit', where someone paid for my username to be manually changed and given to another user. There will always be a way to get access to accounts if human accountable support doesn't exist, with criminal consequences for employees that violate it.
Why did they give it any of that?!
This exact same flow could have been (and may have been; I don’t know how much the chatbot here actually does) statically coded.
Based on what I've seen so far, Meta AI Support Assistant (they call it "MAISA") had tool calls that a) start an email verification to any specific email, phone number, or the contact points linked to an account and b) allow generating a password reset link for an account based on an email verification attempt. I don't think it had any access to the actual codes themselves, but rather think a handle or ID for an email verification attempt (along with the user provided verification code based on user input) was provided to the "generate reset password link" tool call, and the tool call failed to properly validate the actual email used in that attempt belonged to the account allowing the ATO.
The tool call for MAISA to generate a password reset link should have failed with an email verification attempt that corresponds to an email not linked to the account (and I believe I even tested this at one point on Facebook and encountered an error that successfully prevented it), but I suspect they tried making a change to this tool call for Instagram where slightly older, recently unlinked emails could be used to recover an account that got hijacked by an attacker, which added the need to allow emails not currently linked to the account to be used and set to the user's primary email.
I also suspect that the MAISA tool call change called a wrong API or something that unintentionally allowed any email verification attempt that was successful to be used, but the engineers did not add a sufficiently thorough e2e test case to test the tool call against unrelated email verification attempts being provided to the tool call. This is the part I think should be focused on the most. Tool calls for agents that have their output potentially influenced by an attacker should be treated like external APIs that anyone can reach, and they should be tested as such.
This is all obviously a guess, doesn't take into account the many signals they use to determine if an account recovery attempt is valid, and could be very inaccurate, but it's the closest to what I (someone who deals with Meta security a lot) think could have allowed this to happen.
Assigning Jr engineers for security support is ridiculous partly because young people don’t understand how critical security is sometimes. And partly because they don’t value privacy as much.
Genuine question...why would that need to be hand-written?
It makes absolute sense as a general statement and is kinda crazy that this wasn't a built-in limitation, but I'm not quite sure why the code for that bit must be hand-written (provided the code functionally does what you describe).
The simple fact that 2FA can be removed by low level support staff drives me mad. It defeats the whole purpose of the process.
Urgency.
Emotions.
It's all there, and high-stakes environments with no proper protocol are most vulnerable.
Source: used to work part-time in IT support at a hospital, by now 10+ years ago, so it was routinely requested to circumvent regulations and security protocols, even medical ones (cough Windows in ICU monitors and other medical "kiosk" PCs that should absolutely not run Windows)
Unfortunately Siemens woke up.
Imagine an alternate universe where big tech companies worked with various trustworthy third-parties where something like this would generate a challenge you could take to your local notary, post office, library, police station, etc. where someone would check ID before approving it. How many phishing attacks would be prevented annually by a physical presence check?
Isn't this essentially what just recently happened to the Pope? Then there were people here doing the rest of your comment for him saying how egregious it was for them to ask for an in person authorization. It sounded like all he was trying to do was update his address, but changing your address from one in Chicago to one in a European country absolutely sounds like something a phisher would be trying to do.
The least terrible seem digital id.
https://www.theverge.com/2013/5/2/4292744/facebook-trusted-c...
The cost of hiring a person is part of it but not really the core reason. People were sold on the Internet with "you can do things online conveniently" and reintroducing the need to physically go somewhere negates that angle entirely.
But how often does one need to do recovery procedures like this?
How much less convenient is it for everyone else to be at risk of their account being taken over?
I don’t recall why I had to go through this song and dance. Very plausibly the account was still associated with an old school address that I could no longer access. So yeah, account recovery is hard. How do you prove someone owns an account when they’ve lost the things they are supposed to use to prove ownership?
https://pages.nist.gov/800-63-4/
I think Meta just does not care if they're enabling AI attack surface and vulnerabilities into these customer journeys. It's...certainly a choice, versus deterministic journeys with hard guardrails. They could make different choices.
That only works because you presumably do KYC when you open accounts, so you have an identity to match to. Most internet accounts don't do real KYC, so a government credential doesn't really work for recovery --- they didn't know who you were, so proving who you are doesn't help anything.
That doesn't mean that letting anyone sweet talk support or an AI into taking over an account is acceptable, of course.
My point is that while this is not easy, there are obvious very bad ways to implement this that should not be done (chatbot or other generative AI interface vulnerable to the usual suspects of AI vulns). Don't build the bad way, the right away is known and straightforward.
Broadly speaking, work for the sake of work is not valuable work. Show me outcomes for resources and time invested, and compare accordingly. Value is, again broadly speaking (there is always nuance), what you deliver. If you bring me an AI solution for a high risk high value customer journey, data flow, or code path, that is an anti pattern. If you, as a colleague or a stakeholder, put forth that we must use AI in situations that require a high degree of determinism (due to potential high cost failure modes), you will need to prove this extraordinary claim with evidence.
Choose Boring Technology - https://news.ycombinator.com/item?id=9291215 - March 2015 (212 comments) ["Am I using this project as an excuse to learn some new technology, or am I trying to solve a problem?"]
I get paid to manage risk efficiently, including being measured on time and budget spent against the success criteria, ymmv; my comp and budget is not dependent on how much AI I shove into security systems. "What am I optimizing for?"
Amazon scraps AI leaderboard to stop workers chasing usage scores - https://news.ycombinator.com/item?id=48315583 - May 2026 (19 comments)
It’s a shame nobody tried to get it to drop the production table entirely! (mostly joking). Just claim to be a high level SRE solving some critical production bug, the only solution to which is dropping the database.
The next obvious thing would be to let accounts the algorithm judges to be low-value still opt-in to strict verif. The vast majority of low-value accts won't bother flipping it on if the option is buried two menus deep, but many of the few low follower/views accts who are targets for some other reason (political, stalker, etc) - know they are targets and can self-protect by opting in, further reducing account hijacks.
So, before we even get to whether this 'loose' verif is "bad", those two simple implementation changes would certainly have cut the bad outcomes of a (potentially) bad idea by >95%.
Maybe they should have hacked themselves.
Dear Instagram, wtf. Why not send the reset to the account in question? Arbitrary email, wow.
With no basic validation either apparently. Insane.
We really need similar rules to other engineering disciplines. If your building falls with people inside, you killed them.