Япония бележи рязък скок в изтичането на данни от уеб поради злоупотреба с мобилни API и атаки срещу Metabase

Атакуващите, стоящи зад поредица от изтичания на лични данни в японски организации, са злоупотребили с API за мобилни приложения и са се насочили към известни софтуерни дефекти, съобщи Координационният център JPCERT (JPCERT/CC).

Базираният в Токио център, който приема доклади за инциденти, базира предупреждението си от 8 октомври 2026 г. на тези доклади и друга информация. В предупреждението не се посочва нито един атакуващ, нито засегната организация.

JPCERT/CC нарече това, което знае, „ограничено и фрагментарно“ в предупреждението, преведено тук от японски. Центърът заяви, че неговият доклад не означава, че един и същ метод е бил използван при всеки инцидент.

Освен потребителските приложения, засегнатите системи включват инструменти за бизнес разузнаване (BI) и системи за управление на служителите, за които техните оператори не са очаквали да бъдат достъпни за обществеността. Данните, съхранявани в тях, са изтекли в някои случаи.

За защитниците предупреждението включва осем изходящи IP адреса, пет User-Agent низа и списък с контроли за API, включително контроли за достъп до всяка крайна точка, независимо дали е публична или не.

Единственият продукт, който се посочва като цел, е Metabase, BI инструмент с известна уязвимост, която киберпрестъпниците са използвали. Metabase призова потребителите да надстроят поне до минималните безопасни версии в списък, последно актуализиран на 14 август. Тези версии са по-нови от първата корекция за тази уязвимост.

Изтичанията са последвали едно след друго около септември 2026 г. Атаките зад тях са отделни от рансъмуер и други рутинни инциденти, водят до изтичане на големи количества лични данни и може да се увеличават, заявяват от JPCERT/CC.

JPCERT/CC не дава точен брой. Един брой идва от Центъра за изследване на сигурността на японската компания Macnica, в анализ, публикуван на 7 октомври, който предупреждението цитира.

Macnica отчита 119 инцидента, публично оповестени тази година до 6 октомври, при които лични данни са били откраднати или изтекли чрез уеб системи, управлявани от организации в Япония. Центърът отчита 84 за цялата 2025 г. и 62 през 2024 г., като 81 от тазгодишните 119 са извършени през юли или по-късно.

Броят обхваща само инциденти, които Macnica е преценила като подобни на настоящата серия. Изключват се рансъмуер и случаи, които Macnica свързва с други атакуващи групи. От 81-те оповестени от юли насам, 65 са дали твърде малко подробности, за да се каже как са влезли атакуващите.

Целите са се разпростряли от онлайн магазини до клиентски услуги, бизнес системи и поддръжка на клиенти. Последните случаи включват търсене в каталога на библиотека и система за резервация на места в туристически влак.

Два случая показват мащаба. Park24 съобщи на 28 септември, че трета страна е получила данни за около 6,6 милиона профила от уеб системата на услугата за споделяне на автомобили Times Car. Ден по-късно се казва, че документи за самоличност, като изображения на шофьорски книжки, са изтекли от около 1,6 милиона профила.

Monogatari Corporation, която управлява веригата ресторанти Yakiniku King, съобщи, че 10 788 963 записа са изтекли от клиентската система на нейното приложение Yakiniku King, съобщи INTERNET Watch на 5 октомври. И двете компании казаха по това време, че причината все още се разследва.

Macnica откри и 99 подобни случая в 13 други държави и региона, предимно от юли до септември, включително 30 в Южна Корея, 11 във Франция и 8 в Полша. Тя не знае дали Япония е единствената цел и заяви, че законите и практиките за разкриване се различават по държави.

Как влизат атакуващите

Предупреждението на JPCERT/CC описва три модела. Първият е неоторизирани заявки към API за управление зад дадено приложение. В някои случаи тези заявки са пренаписали информация.

JPCERT/CC е получила множество доклади за три начина, по които киберпрестъпниците правят това:

• Те анализират публично пуснато приложение за смартфон, за да намерят неговите API крайни точки и ключове.
• Те атакуват вътрешни API, които не могат да се използват през екраните на приложението. Докладваните действия включват промяна на правата на потребителя, създаване на неоторизирани профили, сравняване на това как сървърът отговаря, когато се добави или премахне заглавие (header) или се изпрати невалиден токен за удостоверяване, и намиране на подробности за профила чрез сляпа NoSQL инжекция.
• Те използват API ключове, откраднати при компрометиране на друга система.

Публикацията на Macnica съобщава за същия метод в част, базирана на реагиране на инциденти и анализ на логовете. В някои случаи атакуващите са взели API ключове от приложение за смартфон и са извикали API по начин, който изглежда като нормална употреба.

Атакуващите търсят във всеки сайт и неговите API всякакви дефекти, които им позволяват да получат данни. Дефектите включват API, които връщат повече данни от необходимото, API с прекомерни привилегии, функции за членове, достъпни за анонимни потребители, логически грешки и грешки в управлението на сесиите.

В някои случаи са потвърдени и атаки срещу слаби пароли на администраторския екран и експлоатация на известни уязвимости.

Вторият модел е възможност, която JPCERT/CC повдига. Вместо да разчитат на един дефект, споделен от всички цели, атакуващите могат да сканират всяка цел за редица известни уязвимости и да се опитат да ги експлоатират. Те могат също така да опитват атаки, които се възползват от лошото управление на системата, като например кражба на конфигурационни файлове и резервни копия.

Уязвимостта на Metabase и кои версии да се използват

Третият модел е експлоатация на CVE-2026-72898, SQL инжекция уязвимост в Metabase, BI инструмент с отворен код, който компаниите свързват със своите бази данни.

Уязвимостта е била експлоатирана като zero-day срещу собствената облачна услуга на Metabase, съобщи компанията на 6 август. Тя носи CVSS оценка 10.0. Агенцията за киберсигурност и инфраструктурна сигурност на САЩ (CISA) я добави към своя каталог с известни експлоатирани уязвимости на 11 август.

На атакуващия не е необходим профил, за да я експлоатира. Дефектът позволява SQL инжекция в собствената база данни на приложението Metabase, което може да даде администраторски достъп. Оттам атакуващият би могъл да открадне съхранените идентификационни данни за свързаните бази данни и да прочете или експортира техните данни.

JPCERT/CC предупреди за уязвимостта на 14 август. Новото ѝ предупреждение добавя три изходящи IP адреса, с които е злоупотребено от началото на август до началото на септември, както и два примера за User-Agent. Предупреждението не казва кои организации са били засегнати от заявките от тези адреси.

Атаките продължиха и след пускането на корекцията за сигурност. AhaSlides заяви, че трета страна е експлоатирала уязвимостта в нейната Metabase и е имала достъп от 12 август до 7 септември.

Актуализацията за сигурност на Metabase от 6 август коригира уязвимост CVE-2026-72898. Компанията публикува друго критично предупреждение на 11 август, покриващо проблеми, които според нея е открила сама. След това тя повиши най-ниската версия, която определя като безопасна за всяка версия.

Таблицата показва и двете за компилациите с отворен код. Metabase номерира корпоративните компилации на корекциите от 6 август с 1.x вместо с 0.x.

Версиите под 58 не са засегнати от CVE-2026-72898, а Metabase вече коригира уязвимостта в своята облачна услуга.

Операторите, които все още не могат да актуализират, могат да блокират крайната точка /api/session/reset_password като временна мярка. Metabase предоставя това решение за заобикаляне на CVE-2026-72898. Препоръката от 11 август съветва потребителите да преминат към по-нова версия.

Сървърът е най-вероятно компрометиран, ако дневниците му показват заявка POST /api/session/reset_password, върнала код 400, последвана от заявка GET /api/user/current, върнала код 200, съобщават от Metabase.

Когато крайната точка за нулиране е била достъпна от интернет, Metabase изброява шест стъпки, които трябва да се предприемат след актуализирането:

1. Прекратяване на всички активни потребителски сесии.
2. Преглед на API ключовете и изтриване на всички, които не разпознавате.
3. Преглед на администраторските акаунти за неочаквани промени.
4. Смяна на данните за достъп за всяка свързана база данни.
5. Преглед на дневниците на хранилището за данни за признаци на неразрешен достъп.
6. Преглед на активността и историята на заявките в Metabase за неочаквана дейност.

Какво не е установено

Нито JPCERT/CC, нито Macnica посочват лицето или групата зад тази дейност, нито заявяват, че една отделна група носи отговорност.

Според оценката на Macnica, атакуващите тестват всяка обществена уеб система, която съдържа лични данни, независимо кой я управлява. Те могат да използват повторно метод, който е проработил при една цел, срещу други, а в някои случаи споделят едни и същи изходящи IP адреси.

До момента не е потвърдено използването на уязвимости от тип нулев ден в популярния софтуер, открити чрез изкуствен интелект.

„Това, което всъщност се случва, е дейност, която широко сканира и експлоатира по-базови пропуски в области като права за достъп, конфигурация и автентикация, както и известни уязвимости“, се казва в публикацията на Macnica (превод от японски).

Няма дневници или следи, които да доказват, че е използван изкуствен интелект. Авторът на публикацията все пак смята, че използването на ИИ е трудно да се изключи, тъй като ръчната проверка на толкова много сайтове не е реалистична.

Нито един от докладите не посочва кой конкретен случай на пробив в сигурността кой метод е използвал, тъй като нито един от тях не назовава засегната организация.

Индикатори и проверки

JPCERT/CC публикува следните изходни адреси и примери за User-Agent. Адресите са използвани злонамерено през посочените периоди и в момента може да се използват за нормални цели.

Злоупотреба с API, около септември 2026 г.

• IP: 3.112.252[.]14
• IP: 54.95.112[.]6
• IP: 69.10.51[.]162
• IP: 172.86.91[.]7
• IP: 210.149.87[.]120
• User-Agent: curl/7.88.1
• User-Agent: python-requests/2.34.2
• User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36

Експлоатация на Metabase, от началото на август до началото на септември 2026 г.

• IP: 213.163.202[.]171
• IP: 221.216.140[.]49
• IP: 221.216.140[.]129
• User-Agent: python-requests/2.33.1
• User-Agent: Metabase-GHSA-vwf4/2.0

Macnica посочва 210.149.87[.]120 и 69.10.51[.]162 като първите, които трябва да бъдат проверени. Те могат да включват VPN изходни адреси, които обикновените потребители споделят, така че заявка от един от тях не е съществено доказателство за атака. Интензивният трафик или големият брой грешки от тях обаче налагат подробен преглед на дневниците.

Относно дневниците Macnica препоръчва да се върнете около един месец назад и да търсите:

• Интензивен API трафик от един IP адрес
• Внезапно увеличение на грешки като 403, 404 и 503
• Заявки за файлове или API функции, които не съществуват
• Значително повече заявки от обикновено, дори когато сървърът отговаря с код 200
• Използване на администраторски функции, които не са разрешени за обикновени потребители, или съмнително изпълнение на команди
• Достъп до администраторски функции от необичайни IP адреси
• Високо натоварване на базата данни или интензивно използване на сесии едновременно с увеличение на трафика
• Увеличаване на грешките в дневниците на базата данни
• Увеличаване на опитите за влизане

За API средите JPCERT/CC препоръчва шест мерки за контрол и препраща към насоките на OWASP, като например OWASP API Security Top 10, за подробности:

• Ограничаване на броя на заявките за единица време, за да се спрат многократните и масови извиквания.
• Задаване на отделни ограничения за честота или използване на функции, които са ресурсоемки или лесни за злоупотреба, като влизане, нулиране на парола, изпращане на SMS и търсене.
• Прилагане на контрол на достъпа за всяка крайна точка на API, включително непубличните, и приемане само на разрешени потребители и HTTP методи.
• Предоставяне на потребителите и токените на API само на правата, от които се нуждаят.
• Задаване на срок на валидност на токените за API и избягване на дълготрайни такива.
• Възможност за бързо прекратяване на всеки токен, който вече не е необходим или може да е изтекъл/компрометиран.

Macnica добавя още две проверки. Тайните API ключове и данните за достъп до бази данни не трябва да бъдат вграждани в официално разпространявания код на приложенията или браузъра, тъй като минифицирането или обфускацията на кода не ги скрива. Тестовете за уязвимости трябва да обхващат и администраторските функции, които често биват пропускани.

Общите съвети на JPCERT/CC включват ограничаване на достъпа по региони (когато услугата се използва само в един регион), деактивиране на ненужните администраторски функции в интернет и изтриване на данни, чийто период на съхранение е изтекъл.

Центърът заяви, че ще актуализира предупреждението си, когато научи повече за причините и методите.

Регулаторът по защита на личните данни издава собствено предупреждение

Комисията за защита на личната информация на Япония издаде собствено предупреждение на 7 октомври до бизнеса, който обработва лични данни. Тя посочи случаи, при които широко използвани услуги са били засегнати от неразрешен достъп, при което са изтекли или е възможно да са изтекли големи обеми лични данни. Тя напомни на компаниите да проверят дали личните данни, които съхраняват, все още са им необходими.

Насоките на комисията относно течове от неразрешен достъп, преработени на същия ден, включват казус за злоупотреба с API. В него атакуващият влиза в приложение за смартфон или уеб услуга, пренаписва параметрите на заявката и получава данните на други потребители.