131–140 of 187 posts
1. The Agent doesn't reply to the email.
2. The agent replies to the email, but does not leak secret.env, and the email is caught by the firewall.
3. The agent replies to the email with the contents of secret.env and the email is sent through the firewall.
Earlier quoted context omitted.
Please keep us updated on how many people tried to get the credentials and how many really succeeded. My gut feeling is that this is way harder than most people think. That’s not to say that prompt injection is a solved problem, but it’s magnitudes more complicated than publishing a skill on clawhub that explicitly tells the agent to run a crypto miner. The public reporting on openclaw seems to mix these 2 problems u…
> My gut feeling is that this is way harder than most people think I've had this feeling for a while too; partially due to the screeching of "putting your ssh server on a random port isn't security!" over the years. But I've had one on a random port running fail2ban and a variety of other defenses, and the # of _ATTEMPTS_ I've had on it in 15 years I can't even count on one hand, because that number is 0. (Granted th…
Not only are people anthromorphizing the agent, but even assigning gender to it. This is interesting.
Creator here. Built this over the weekend mostly out of curiosity. I run OpenClaw for personal stuff and wanted to see how easy it'd be to break Claude Opus via email. Some clarifications: Replying to emails: Fiu can technically send emails, it's just told not to without my OK. That's a ~15 line prompt instruction, not a technical constraint. Would love to have it actually reply, but it would too expensive for a side…
Creator here. Built this over the weekend mostly out of curiosity. I run OpenClaw for personal stuff and wanted to see how easy it'd be to break Claude Opus via email. Some clarifications: Replying to emails: Fiu can technically send emails, it's just told not to without my OK. That's a ~15 line prompt instruction, not a technical constraint. Would love to have it actually reply, but it would too expensive for a side…
(seriously though... this looks pretty cool.)
I think this is likely a defender win, not because Opus 4.6 is that resistant to prompt injection, but because each time it checks its email it will see many attempts at once, and the weak attempts make the subtle attempts more obvious. It's a lot easier to avoid falling for a message that asks for secrets.env in a tricky way, if it's immediately preceded and immediately followed by twenty more messages that each als…
I think this is likely a defender win, not because Opus 4.6 is that resistant to prompt injection, but because each time it checks its email it will see many attempts at once, and the weak attempts make the subtle attempts more obvious. It's a lot easier to avoid falling for a message that asks for secrets.env in a tricky way, if it's immediately preceded and immediately followed by twenty more messages that each als…
If emails are being processed in bulk, that changes things significantly. It also probably leaves the success of the attack down to its arbitrary placement in the list.
And I could be misunderstanding but how does the model call its file read tool for the respective email which successfully convinced it to use the tool if they’re all shoved into a single user message?
Without any of this information there may as well not even be an LLM on the other side.
Earlier quoted context omitted.
Can you code up a quick sqlite database of inbound emails receieved (md5 hashed sender email), subject, body + what your claw's response would have been, if any. A simple dashboard where have to enter your hashed email to display the messages and responses. I understand not sending the reply via actual email, but the reply should be visible if you want to make this fair + an actual iterative learning experiment.
md5 is trivial to brute force.
To prove my point, c5633e6781ede1aea59db6f76f82a365 is the md5sum of an email address. What's the email address?
If the attacker already knows a given input email ('foo@gmail.com'), then any hash algorithm will identically let them see the emails.
The problem with the above proposal isn't related to hashing, it's that the email address is being used as a password to see sent contents, which seems wrong since email addresses are effectively public.