| ▲ | robomc 6 days ago |
| From the CEO's response: > On January 24, 2025, security researchers from Kudelski Security disclosed a vulnerability to us through our Vulnerability Disclosure Program (VDP). The researchers identified that Rubocop, one of our tools, was running outside our secure sandbox environment—a configuration that deviated from our standard security protocols. Honestly, that last part sounds like a lie. Why would one task run in a drastically different architectural situation, and it happen to be the one exploited? |
|
| ▲ | KingOfCoders 5 days ago | parent | next [-] |
| Yes, all the tools are fine and secure and sandoxed, just this one tool that was kind of randomly chosen by the security researcher because it is a tool that can execute Ruby code inside the environment - one could argue an especially dangerous tool to run - was not safe. |
|
| ▲ | jdlshore 6 days ago | parent | prev | next [-] |
| Not sure why it seems like a lie. Oversights like this happen all the time. |
| |
| ▲ | cube00 5 days ago | parent | next [-] | | It seems like a lie because they tried to hide this incident by deflecting to a PR fluff post first [1] They only published a proper [2] disclosure post later once their hand was forced after the researcher's post hit the HN front page. [1]: https://news.ycombinator.com/item?id=44954242 [2]: I use that term loosely as it seems to be AI written slop. | |
| ▲ | wheelerwj 6 days ago | parent | prev [-] | | 100%. Sounds like a very common oversight at many companies. |
|
|
| ▲ | 6 days ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | sophacles 6 days ago | parent | prev | next [-] |
| > Why would one task run in a drastically different architectural situation Someone made a mistake. These things happen. > and it happen to be the one exploited? Why would the vulnerable service be the service that is exploited? It seems to me that's a far more likely scenario than the non-vulnerable service being exploited... no? |
| |
| ▲ | bigiain 6 days ago | parent [-] | | > > Why would one task run in a drastically different architectural situation > Someone made a mistake. These things happen. Some company didn't have appropriate processes in place. For ISO27001 certification you at least need to pay lip service to having documents and policies about how you deploy secure platforms. (As annoying as ISO certification is, it does at least try to ensure you have thought about andedocumented stuff like this.) | | |
| ▲ | sophacles 5 days ago | parent [-] | | Ah yes processes.... things done by humans. When stuff is done by humans, mistakes happen - no matter what the process is. Go do a search for the phrase "wondering how this could happen" and find millions of news articles about mistakes happening despite processes being in place! |
|
|
|
| ▲ | Romario77 6 days ago | parent | prev [-] |
| because researchers from Kudelski Security most likely tried different static analysis tools and they didn't work the way Rubocop did. They don't write the details of how they got to this particular tool - you could also see from the article they tried a different approach first. |
| |
| ▲ | robomc 6 days ago | parent | next [-] | | > because researchers from Kudelski Security most likely tried different static analysis tools and they didn't work the way Rubocop did. Yes but that's kind of the point - they say this issue that takes you directly from code execution to owning these high value credentials was only present on rubocop runnners but isn't it a bit coincidental that the package with (perhaps, since they chose it) the easiest route to code injection also happens to be the one where they "oops forgot" to improve the credentials management? It just seems very convenient. | |
| ▲ | KingOfCoders 5 days ago | parent | prev [-] | | I've read it differently, they chose Rubocop not because it worked, but because it allows to execute Ruby code. |
|
