Live data from Hacker News

My minute-by-minute response to the LiteLLM malware attack

futuresearch.ai

191–194 of 194 posts

Re: My minute-by-minute response to the LiteLLM malware attack

#191

Earlier quoted context omitted.

LiteLLM isn't a good choice for a proxy in any case. It introduces a lot of lag amd latency and the features are often half baked. To me, it looks like a vibecoded application without a product owner. And the code itself isn't very organized either. I evaluated it for a project a few months ago and will never use it for anything production. Theres a few much better alternatives out there.

Could you name some of these better alternatives?

If your requirements are just to load balance between selhosted AI servers: nginx. If you want a more thorough system with configurability, logging, etc.: Bifrost from MaximAI

Re: My minute-by-minute response to the LiteLLM malware attack

#192
post #49

Earlier quoted context omitted.

The package in question was live for 46 minutes. It generally takes longer than that for security partners to scan and flag packages. PyPI doesn't block package uploads awaiting security scanning - that would be a bad idea for a number of reasons, most notably (in my opinion) that it would be making promises that PyPI couldn't keep and lull people into a false sense of security.

I realize this is controversial (and many Python folks would claim anti ethical). But I keep wondering if requiring a small payment for registering and updating packages would help. The money could go to maintaining pypix as well as automated AI analysis. Folks who really couldn't afford it could apply for sponsorship.

I suspect that for a nation-state type threat actor, this wouldn’t be much of a deterrent. Any type of reputation system like this would work to a point until motivated threat actors find a way to game it.

Re: My minute-by-minute response to the LiteLLM malware attack

#194
post #92

Earlier quoted context omitted.

As someone who works in security, it's really neat that you were able to discover this with the help of Claude. That being said the "I just opened Cursor again which triggered the malicious package" message is a bit eye opening. Ideally the instant you suspected malware that machine should have been quarantined and your security personnel contacted.

I get why you say this, but real life is messy and the "fog of war" makes situations far less obvious in the moment. The older I get the more I realize how much we need scrappy, can-do people who don't always follow the "rules". Knowing the "rules" and knowing that people follow the "rules" because "that's what your supposed to do" is itself an avenue for malicious actors to exploit.

Clear procedures are the entire point of incident response plans. You follow them because of the fact that your judgement can be compromised in the moment. They re-triggered the malware payload because they decided to just dive in and handle it on their own in the "fog of war". Which would have been avoided entirely if they'd been following the standard advice to quarantine the machine and contact security so that they can investigate properly, with the developer if necessary.

Your final sentence is completely irrelevant. Blind rule adherence can be an avenue for exploit in certain scenarios, but this wasn't a case of a developer being tricked into following a bad rule. They didn't follow a real and very well justified standard practice.

The takeaway is "wow, we got lucky, we should have security people to loop in for this next time" not your weird life philosophy about how rule followers are a problem.

Post reply on HN