Live data from Hacker News

The newest Instagram “exploit” is the goofiest I've seen

0xsid.com

461–470 of 528 posts

Re: The newest Instagram “exploit” is the goofiest I've seen

#461

Earlier quoted context omitted.

It's a tough problem, because people forget passwords, change phones, lose access to 2FA devices, but still need to use their accounts.

It's worse than "forgetting." Having seen older folks just set up new accounts for a move, they make zero attempt to even try to keep them! Oh, the phone company needs a login/pass? Just type in anything, don't write it down. If something goes wrong, they're going to call in anyway, not use the website.

A lot of utility companies including Comcast used to not have a flow for “moving” and so you’d get a brand new account with a comcast email every time you moved to a new address. In a lot of cases the techs would just set it up for you as part of the install and give you the password. It’s only in the last 10 years they added anything like that. I have 3 or 4 different obsolete accounts with them where my actual email is the contact email from that time and some of their online systems will reset the wrong password and stuff like that.

Re: The newest Instagram “exploit” is the goofiest I've seen

#462
post #327

Earlier quoted context omitted.

The strangest/scariest and honestly in the end all that surprising one of these I had was with a major storage appliance provider that most in the space on HN would know by name. We needed to delete a storage volume to urgently free up space, and apparently this was locked in a way the storage vendor was required to act as a "second key" to ours to make the destructive action. We had never properly set this up, and I…

Ubiquiti or Synology?

Neither, large Enterprise storage name where the prices start in the six figures for the smallest boxes.

Re: The newest Instagram “exploit” is the goofiest I've seen

#463

Earlier quoted context omitted.

100% agree. Agents should have the same permissions as the user prompting them, nothing else. No rules will stop agents of accessing data or modifying content if the agent have permissions to do it. That does not make the agent "safe" from the perspective that it still can and eventually will cause havoc, delete critical data, etc. But it makes the system safe as it isolates that user access and it is not worse that…

> Agents should have the same permissions as the user prompting them, nothing else. In user support work, it won’t make them very useful. User support is the fallback when self-serve tools and public documentation, the one you have permission to read and use directly, are not allowing a solution. By definition useful user support allows operations that are beyond the user’s permissions

I love this thread. So:

Useful support agents = can do things user doesn’t have permission for = are a vulnerable attack vector.

Or they don’t have permission and are just glorified KB search.

Re: The newest Instagram “exploit” is the goofiest I've seen

#464

Earlier quoted context omitted.

> Agents should have the same permissions as the user prompting them, nothing else. In user support work, it won’t make them very useful. User support is the fallback when self-serve tools and public documentation, the one you have permission to read and use directly, are not allowing a solution. By definition useful user support allows operations that are beyond the user’s permissions

I love this thread. So: Useful support agents = can do things user doesn’t have permission for = are a vulnerable attack vector. Or they don’t have permission and are just glorified KB search.

Almost like AI support agents aren't viable

Re: The newest Instagram “exploit” is the goofiest I've seen

#465

Earlier quoted context omitted.

They are suggesting that you should assume the user has full access to the same tools as the agent, which is a helpful way to approach it. You mentioned the prompt side of things, and I think you should use a similar mindset there—just assume the user can read the entire prompt exactly as it’s sent.

You should also assume the user can read any data you send back from a tool call or data you add to a user response. If any part of the input or output is controllable by an attacker, you should be assuming some prompt injection is possible that allows them to access all data and tool calls the agent had and has access to.

Yes, that's part of the "entire prompt"

Re: The newest Instagram “exploit” is the goofiest I've seen

#466

Earlier quoted context omitted.

There are a lot of other ways they could do it. You could provide a delay feature… if you request this sort of reset, it takes 3 days, and emails are sent to the primary address every day with the count down. If your email isn’t lost, you would see these warnings. You could let an account holder designate emergency contacts (other accounts) that are allowed to request a reset if you lose your primary email (again wit…

This is actually what microsoft does for microsoft accounts If you recover a microsoft account / submit a ticket to recover it and provide correct information, the active email gets an email letting them know about the request You can deny it, or if you ignore it for 30 days the request goes through Seems to be the best system IMO

> You can deny it, or if you ignore it for 30 days the request goes through

That's a good measure, but it would fail for the attack scenario in TFA: the attacker claims their account was hacked, so presumably (if the support AI "believes" them) the notification email is compromised. If the account was hacked, you cannot let the one receiving the notification cancel your recovery attempt, which they will of course try to do. Of course in this exploit it's all a lie, but what if your account truly was hacked and your were genuinely trying to recover it?

Re: The newest Instagram “exploit” is the goofiest I've seen

#467

When thinking about the security of AI agents, one should ignore the agent entirely. Consider only the tools that the agent has access to. Assume that, if the attacker can interact with this agent, they have full and unfettered access to these tools. If those tools are secure, the agent is secure. This framing doesn't consider context poisoning attacks, on which much has been written already and which merit their own…

Isolation doesn't solve the main issue, at the end of the day you have to trust the model being able to handle dangerous things, there's no clever way around this basic fact.

Re: The newest Instagram “exploit” is the goofiest I've seen

#468
post #378

Earlier quoted context omitted.

You can view the recent activity on your Microsoft account @ account(dot)live(dot)com/Activity Would show any logins or security info updates etc

Those login attempts which trigger 2fa app does not generate a log entry if unsuccessful. Only attempts with username/password does. For some strange reason. So there is no way to flag them as malicious and if you accidentally accept, then it’s already too late. Pretty annoying setup.

I have the same issue. It’s absolutely stressful. Id also love some way to mark them as malicious.

Re: The newest Instagram “exploit” is the goofiest I've seen

#469
Imagine dragging in a random person from the street and making them work on account recovery without training them first. That seems to be what happened here, the process was simply left to model's judgement, and the model only sees a text stream, even less than a random person from the street who is at least going to be vaguely aware of their position. It could be a roleplay for what the model cares.

The agent should have had proper instructions to check the identity of a complete stranger. Yes it's still possible to jailbreak the model, and it's probably still easier than deceiving a trained human employee in a social engineering attack. But it doesn't mean there shouldn't be a proper process of identity verification on account recovery at Meta.

Re: The newest Instagram “exploit” is the goofiest I've seen

#470

When thinking about the security of AI agents, one should ignore the agent entirely. Consider only the tools that the agent has access to. Assume that, if the attacker can interact with this agent, they have full and unfettered access to these tools. If those tools are secure, the agent is secure. This framing doesn't consider context poisoning attacks, on which much has been written already and which merit their own…

100% agree. Agents should have the same permissions as the user prompting them, nothing else. No rules will stop agents of accessing data or modifying content if the agent have permissions to do it. That does not make the agent "safe" from the perspective that it still can and eventually will cause havoc, delete critical data, etc. But it makes the system safe as it isolates that user access and it is not worse that…

[dead]
Post reply on HN