Rabbit R1 zaliczył ostateczną wpadkę... (film, 5m)
Fireship w swoim najnowszym filmie ujawnia poważne błędy w kodzie Rabbit R1, które doprowadziły do poważnych zagrożeń dla użytkowników. Okazuje się, że deweloperzy tego urządzenia popełnili nieakceptowalny błąd, nazywając go wręcz katastrofalnym. Zły kod pozwala osobom trzecim na przeglądanie wszystkich wiadomości wysłanych ze wszystkich urządzeń oraz na ich modyfikację. Co gorsza, istnieje możliwość unieruchomienia każdego R1 w zasięgu tamtego złośliwego kodu. Twórcy Rabbit R1 muszą teraz stawić czoła konsekwencjom swoich działań. W dzisiejszej aktualizacji Fireship przybliża nam, jak nie popełnić podobnych błędów przy tworzeniu produktów technologicznych.
Fireship wspomina, że po raz pierwszy zetknął się z Rabbit R1 na CES w styczniu. Już wtedy nasz autor był zaskoczony jego całkowitą bezużytecznością oraz licznymi buzzwordami wyrzucanymi przez jego CEO. Mimo wczesnego sceptycyzmu, preordery na urządzenie rozeszły się błyskawicznie. Jednak po początkowym entuzjazmie produkt szybko zyskał reputację sprzętu wyśmiewanego przez ekspertów technologicznych. Jego pochodzenie z oszustw związanych z kryptowalutami i NFT tylko zaostrzyło krytykę. Ale nawet przed tym nikt nie mógł się spodziewać aż tak podstawowych błędów, które zostały wykonane przez zespół programistów.
Odkrycie błędów należy do grupy Rabbitude, która zajmuje się inżynierią odwrotną. Po zdobyciu dostępu do bazy kodu Rabbit 1, odkryli, że zawiera ono hard-kodowane klucze API do różnych zewnętrznych usług, w tym 11Labs, co stanowi najpoważniejsze zagrożenie. Klucz API 11Labs umożliwia komunikację z platformą przetwarzania tekstu na mowę. To oznacza, że każda interakcja z Rabbit 1 wymaga wysłania zapytania do platformy 11Labs, co stawia użytkowników w niebezpieczeństwie, jeśli te klucze trafią w niewłaściwe ręce. Warto podkreślić, że w tej sytuacji nie można obarczać winą samego 11Labs.
Fireship zwraca uwagę, że to, co należy zrozumieć, to że Rabbit mógł zignorować problem z Kluczem API 11Labs przez miesiąc. Estradujący programiści wyraźnie wykazali brak odpowiedzialności, myśląc, że sprawa sama się rozwiąże. Na szczęście, w momencie pisania tego artykułu, Rabbit zaktualizował swoje klucze API, co zapobiegło katastrofie, ale pozostaje zbyt wiele pytań o ich procedury zabezpieczeń. Kluczowe jest unikanie hard-codowania kluczy API, które powinny być traktowane tak jak hasła. W przeciwnym razie, nawet jeśli klucz zostanie wykradziony, można narazić się na poważne straty finansowe oraz wizerunkowe.
Zainteresowani produktem Rabbit R1 mają teraz kilka możliwości rozwiązania problemu. Fireship prowokująco sugeruje, aby potencjalni użytkownicy „zrzucili go w głęboki otwór”, co może być zarówno żartem, jak i śmiertelną powagą. Na zakończenie, warto zwrócić uwagę, że film zgromadził już 972 702 wyświetlenia oraz 40 007 polubień na czas pisania tego artykułu, co dowodzi, że kontrowersyjny temat budzi ogromne zainteresowanie wśród widzów. Błędy te są ważnym przypomnieniem o odpowiedzialności w tworzeniu produktów technologicznych.
Toggle timeline summary
-
Wprowadzenie do kontrowersji związanej z Rabbit R1.
-
Programiści popełnili katastrofalne błędy kodowania wpływające na wiadomości użytkowników.
-
Poważne luki pozwalają na nieautoryzowany dostęp do wiadomości i ich modyfikacje.
-
Omówienie tego, jak firma poradziła sobie z tymi problemami.
-
Przegląd początkowych wrażeń mówiącego o Rabbit R1.
-
Krytyka funkcjonalności Rabbit R1 i haseł reklamowych głównego dyrektora.
-
Ujawnienie, że Rabbit R1 to głównie aplikacja na Androida.
-
Opis głównego błędu kodowania związane z hardkodowanymi kluczami API.
-
Odkrycie Rabbitude dotyczące hardkodowanych kluczy API.
-
Wpływ niewłaściwego zarządzania kluczami API na funkcjonalność Rabbit R1.
-
Potencjalne eksploity wynikające z ujawnionych kluczy API.
-
Wyjaśnienie odpowiedzialności 11Labs w zakresie bezpieczeństwa API.
-
Spekulacje na temat sposobu, w jaki doszło do wycieku kluczy API.
-
Twierdzenia Rabbitude dotyczące zaniedbania ze strony Rabbit w sprawie ujawnionego API.
-
Porady dotyczące ostrożnego traktowania kluczy API.
-
Wyzwania związane z rotacją kluczy w aplikacjach produkcyjnych.
-
Dyskusja na temat szyfrowania i narzędzi bezpieczeństwa dla wrażliwych API.
-
Czarny humor dotyczący utylizacji Rabbit R1.
-
Zakończenie i pożegnanie z The Code Report.
Transcription
Another day, another controversy for the Rabbit R1. Apparently this time, its developers wrote some bad code. Like inexcusably, catastrophically bad code. Code that allows someone to view every message ever sent on all devices. Code that allows the attacker to alter the messages sent to the end user. And code that can brick every R1 in existence. It's outrageous, egregious, and preposterous. Mischievous, salacious, outrageous. But the most shocking part about this story is what the company did to fix it. In today's video, we'll find out how this is even possible, so you don't make the same mistake when shipping your own half-baked AI product. It is June 27th, 2024, and you're watching The Code Report. I first encountered the Rabbit R1 at CES in January, where I was blown away by its utter uselessness, along with the amount of cringe buzzwords used by its CEO. Despite setting off my bullsh** detectors, these devices sold out pre-orders within the first few minutes. But after the initial hype, the Rabbit R1 has been the lolcal of tech products of 2024. It was exposed as being nothing more than an Android app under the hood. It was revealed to have origins in crypto and NFT scams, and when it actually shipped, it was even more useless than people imagined. But never in my wildest imagination would I expect their developers to make a mistake like this, hard-coding API keys directly into the codebase. This mistake was discovered by a group called Rabbitude, which is dedicated to reverse engineering the R1. According to their statement, back on May 16th, they obtained access to the Rabbit codebase. And inside that codebase, they found hard-coded API keys for 11Labs, Azure, Yelp, and Google Maps. The most problematic one is 11Labs, which is an AI text-to-speech platform. When you talk to the Rabbit R1, it turns your speech into text. It then passes that text off to a large language model to generate a response. But before that response goes back to the end user, that text needs to be converted back into speech. And that's what 11Labs does. DEVELOPMENT OF THE ATOMIC BOMB That means the R1 needs to make an API call to 11Labs for every response ever sent by the R1. And that means if someone ever got the 11Labs API key, they'd be able to read every R1 response in history, they'd be able to change responses, and they could just delete the AI voices from 11Labs to brick every single R1 in existence in a matter of seconds. And that is quite the exploit. And just to be clear, it's not 11Labs' fault. But there's one thing we need some clarification on. In the statement, it says Rabbit 2 gained access to the Rabbit codebase, which I assume is referring to the back-end Rabbit codebase. The details are sparse, but I don't think they actually put an API key in their Android APK, which would be an even more absurd mistake, because you should never put secret API keys in client-side code. Even my 5-year-old knows that. It seems more likely that Rabbit has a leaker, like an employee dumping the code onto a USB and potentially breaking the law to share it. Leaking is a risky business. Julian Assange once leaked war crimes for which he was treated like a criminal. Even Hillary said, can't we just drone that guy? And he just regained his freedom a few days ago. Now the thing is, when those war crimes leaked, the war criminals didn't stop doing war crimes. And what's crazy is that Rabbit took a similar approach. According to Rabbitude, they've known about this exposed 11Labs API key for a month, and their solution was to just ignore it and hope the problem goes away. This information, I assume, is also coming from the leaker. Now, at this point, Rabbit has rotated its API keys, and this group is operating for the public good, thus nothing catastrophic has happened to user data, but there's a lot of good reasons not to hard-code API keys into your code. In fact, I have a new full Linux course coming up for Fireship Pro members that coincidentally talks about this issue. Might as well leave you a discount code if you want to get early access. An API key is like a password and should be treated with the same amount of respect. If a hacker gets a hold of one, they could retrieve and delete all your data, and cost you a bunch of money in the process. When an API key is hard-coded, one thing you might do is accidentally push it to a public Git repo. And right this very moment, there are scraperbots out there watching every Git repo for exposed API keys to exploit. Problem number two is that it makes key rotation more difficult. Generally, production apps should rotate API keys every 30 to 90 days, but a high-profile app like the R1, where it's known that people are actively trying to reverse-engineer it, could be even more paranoid and rotate their keys every week or so. And this process can be automated with zero downtime. There's really no excuse. Another reason you don't just hard-code is that for a key that's sensitive, it should also be encrypted. Tools like AWS Secrets Manager offer multiple layers of protection, so even if someone gets access to your server, they still shouldn't be able to get the API key. And even if someone does try to get access to it, those requests are logged, which would immediately identify the leaker, so Rabbit management could then put cyanide in their soy latte. Now, if you own the Rabbit R1, there is a recommended solution, and that is to douse it in gasoline, apply a flame to it, and chuck it in the cola super-deep borehole. This has been The Code Report. Thanks for watching, and I will see you in the next one.