Heroku разкри, че откраднатите от миналия месец OAuth токени за интеграция на GitHub допълнително са довели до компрометиране на вътрешна клиентска база данни.
Притежаваната от Salesforce облачна платформа призна, че същият компрометиран токен е бил използван от нападателите за ексфилтриране на хеширани и солени пароли на клиенти от „база данни“.
Актуализацията на Heroku идва, след като BleepingComputer се свърза със Salesforce вчера.
Подобно на много потребители, ние неочаквано получихме имейл за нулиране на паролата от Heroku, въпреки че BleepingComputer няма интеграция на OAuth, която използва приложенията Heroku или GitHub. Това показва, че тези нулирани пароли са свързани с друг проблем.
Heroku обяснява принудително нулиране на парола
Тази седмица Heroku започна да извършва принудително нулиране на парола за подмножество от своите потребителски акаунти след инцидента със сигурността от миналия месец, без да обяснява напълно защо.
Във вторник вечерта някои потребители на Heroku получиха имейли, озаглавени „Съобщение за сигурността на Heroku – нулиране на пароли за потребителски акаунти 4 май 2022 г.“, уведомяващи потребителите, че паролите на техните акаунти са в ход. нулиране в отговор на инцидента със сигурността. Нулирането също ще направи невалидни всички токени за достъп до API и ще изисква от потребителите да генерират нови, обяснява имейлът.
Но споменатият първоначален инцидент със сигурността включва заплахи, които крадат OAuth токени, издадени на Heroku и Travis-CI, и злоупотребяват с тях за изтегляне на данни от частни хранилища на GitHub, принадлежащи на десетки организации, включително npm.
„На 12 април GitHub Security започна разследване, което разкри доказателства, че нападател е злоупотребил с откраднати потребителски токени на OAuth, издадени на двама интегратори на OAuth на трети страни, Heroku и Travis-CI, за да изтегли данни от десетки организации, включително npm“, съобщи GitHub. казах. предварително разкрита.
Тези токени преди са били използвани от приложенията Travis-CI и Heroku OAuth за интегриране с GitHub за внедряване на приложения.
Чрез кражба на тези OAuth токени, участниците в заплахата могат да получат достъп и да изтеглят данни от хранилища на GitHub, принадлежащи на онези, които са разрешили компрометирани Heroku или Travis CI OAuth приложения със своите акаунти. Имайте предвид, че самите инфраструктури, системи или частни хранилища на GitHub не са били засегнати от инцидента.
Но това все още не обяснява защо Heroku ще трябва да нулира някои пароли за потребителски акаунти досега.
Оказва се, че компрометираният токен на машинен акаунт в Heroku, получен от хакери, също позволява неоторизиран достъп до вътрешната база данни на клиентски акаунти на Heroku:
„Нашето разследване разкри също, че същият компрометиран токен е бил използван за достъп до база данни и ексфилтриране на хеширани и солени пароли от потребителски акаунти на клиенти“, обяснява Heroku в актуализиран съвет за сигурност.
„Поради тази причина Salesforce гарантира, че всички потребителски пароли на Heroku са нулирани и потенциално засегнатите идентификационни данни са опреснени. Ние сменихме вътрешните идентификационни данни на Heroku и внедрихме откривания. Продължаваме да разследваме източника на компромис с токена.“
Читател на YCombinator Hacker News твърди, че споменатата “база данни” може да бъде това, което се наричаше “core-db”.
Въпросното устройство е Крейг Керстийнс на платформата PostgreSQL CrunchyData, която преди това беше свързана с Heroku.
„Последният доклад говори за „база данни“, която вероятно е вътрешната база данни“, казва Керстиенс.
„Не искам да спекулирам твърде много, но изглежда [the attacker] имаше достъп до вътрешни системи. GitHub го откри и забеляза и го съобщи на Heroku. Не спорете, че трябва да има повече яснота, но най-добре е да проследите това със Salesforce.”
BleepingComputer се свърза с Kerstiens, който потвърди, че е написал тези коментари.
Клиентите наричат неясното разкриване „влакова катастрофа“
Първоначалното разкриване от Heroku на инцидента със сигурността казва, че неоторизираният достъп е бил свързан с хранилища на GitHub, собственост на акаунти, които са използвали компрометираните OAuth токени на Heroku.
„Компрометираните токени биха могли да осигурят на заплахата достъп до хранилищата на GitHub на клиентите, но не и до акаунтите в Heroku на клиентите“, каза по-рано компанията.
Но имейлите за нулиране на паролата основателно предизвикаха опасения сред клиентите, че разследването на Heroku може да е разкрило друга злонамерена заплаха, която не е била разкрита.
Някои читатели на YCombinator Hacker News нарекоха разкритието „пълна влакова катастрофа и казус за това как да не общувате с клиентите си“.
В стремежа си да бъде по-прозрачен с общността, Хероку хвърли малко светлина върху инцидента, който започна преди няколко часа.
„Оценяваме прозрачността и разбираме, че нашите клиенти търсят по-задълбочено разбиране на въздействието на този инцидент и нашия отговор към днешна дата“, каза Хероку.
Освен това облачната платформа каза, че след работа с GitHub, доставчици на разузнаване на заплахи, партньори в индустрията и правоприлагащи органи по време на разследването, тя е достигнала точка, в която може да се споделя повече информация, без да се компрометира текущото разследване:
GitHub идентифицира дейността на 12 април 2022 г. и уведоми Salesforce на 13 април 2022 г., когато започнахме нашето разследване. В резултат на това на 16 април 2022 г. отменихме всички OAuth токени за интеграция на GitHub, предотвратявайки на клиентите да внедряват приложения от GitHub през таблото за управление на Heroku или чрез автоматизация. Оставаме ангажирани да гарантираме, че интеграцията е сигурна, преди да активираме повторно тази функция.”
За разлика от тях, друг интегратор на трета страна, Travis-CI, разкри работния ден след първоначалното известие на GitHub, че инцидентът не е повлиял на клиентски данни.
Потребителите на Heroku се съветват да продължат да наблюдават страницата за известия за сигурност за актуализации, свързани с инцидента.
Актуализация, 5 май 2022 г. 9:30 ч. ET: Потвърдихме, че читателят, цитиран в статията, наистина е Керстиенс.
