Google знадобився два місяці, щоб усунути вразливість DevSite, яка дозволяла виконувати код без авторизації

Повторно використаний секретний ключ призвів до дистанційного виконання коду

Google усунула вразливість дистанційного виконання коду (RCE) без авторизації в DevSite, платформі, на якій працюють developers.google.com та кілька інших сайтів документації. Вразливість, якій Google присвоїла S0, найвищий рівень шкали серйозності, виявив інженер програмного забезпечення Otark GmbH Simon Köck.

Первинною причиною став повторно використаний секретний ключ OAuth-клієнта. DevSite зберігав у кукі сесії Flask серіалізований об'єкт OAuth2WebServerFlow бібліотеки oauth2client від Google, який компанія залишила для сумісності з google-auth, і цим розкрила ключ. Той самий ключ Google використовувала й для підпису сесій DevSite, що Köck підтвердив офлайн-множенням підпису кукі.

Підроблені сесії приймалися на семи доменах

Köck підтвердив, що підроблені сесії приймалися на всіх семи постраждалих доменах, які спиралися на два різні ключі підпису. Виконання коду він продемонстрував на трьох з них: developers.google.com, docs.partner.android.com та web.dev. RCE без авторизації він перевірив за допомогою payload з Python sleep і виміряв затримки відповідей, однак свідомо утримався від запуску команд і доступу до файлів, даних чи внутрішніх сервісів.

«Я б назвав це особливо серйозним RCE, тому що його міг досягнути будь-хто без облікового запису та залучення жертви», — каже Köck у розмові з The New Stack.

Google виплатила винагороду в розмірі 90 000 доларів: 75 000 доларів — базова виплата за RCE рівня S0, який компанія вважає звичайним рівнем для додатків, помножена на 1,2 за особливу якість облікового запису.

Ланцюг завершила десеріалізація Pickle

Для десеріалізації даних сесії OAuth callback використовувала pickle в Python. Köck замінив об'єкт flow на шкідливий pickle payload, підписав підроблене кукі та виконав його в callback. Для ланцюга мали скластися три помилки: ключ, розкритий у кукі, подвійне використання того самого ключа для підпису та небезпечна десеріалізація даних сесії. Виправлення будь-якої з них розірвало б ланцюг.

Два місяці на виправлення, питання без відповідей залишаються

Köck повідомив про вразливість 6 серпня, а Google отримала її наступного дня. Винагороду затверджено 27 серпня, а виправлення впроваджено лише 7 жовтня. Google не пояснила двомісячний термін, чи застосовувалися тимчасові пом'якшувальні заходи, чи було відкликано один із двох розкритих секретних ключів OAuth-клієнтів і чи анульовано наявні сесії. Köck каже, що ніколи не отримував форензичного висновку і не знайшов доказів експлуатації до виправлення. На запит коментаря щодо цього оновлення Google не відповіла.

Arvin Shivram, дослідник із Сінгапуру, який діє під ім'ям @brutecat і за власним обліком повідомив понад 130 вразливостей Google, зазначає, що внутрішні додатки App Engine часто мають доступ до Stubby, внутрішньої системи міжсервісної комунікації Google. Köck визнає, що цей доступ «може бути значною частиною впливу», однак не перевіряв, до чого міг дістатися цей конкретний процес DevSite. Він також не перевіряв можливість запису у вміст документації, де змінені команди встановлення або посилання на завантаження могли б викликати атаку ланцюга поставок. За його обліком, продемонстрований вплив — це виконання коду на трьох хостах і підроблені сесії на семи, а повний ареал впливу, включаючи шляхи до внутрішніх сервісів Google, залишається недоведеним.

Джерела: Thenewstack