Националният екип за реагиране при компютърни инциденти на Япония, JPCERT/CC, свърза неотдавнашния ръст на изтичания на уеб данни с две основни причини: злоупотреба с API на мобилни приложения и известни софтуерни уязвимости, включително експлоатиран бъг за SQL инжекция в Metabase. Историята е полезно напомняне, че изтичанията на уеб данни в Япония и слабостите в мобилните API обикновено са проблеми от страната на сървъра, в системи, които потребителите не могат да видят или контролират.

Какво откри JPCERT/CC зад изтичанията на данни в Япония

Според доклада JPCERT/CC свързва неотдавнашния скок на изтичания на данни в Япония със злоупотребата с API на мобилни приложения и с уязвимости, които вече са били публично известни. Един от посочените примери е уязвимост за SQL инжекция в Metabase, която атакуващите са експлоатирали.

Общата нишка е, че това не са екзотични атаки. Известните уязвимости и слабо защитените интерфейси са входните точки. Обобщението на изходния материал не свързва изтичанията с нещо, което отделните потребители са направили, и това е важно за това как читателите трябва да мислят за риска: личните данни са били изложени от услугите, които ги съхраняват.

Как SQL инжекцията и изложените мобилни API изтичат лични данни

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

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

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

И в двата случая слабостта е при организацията, която управлява услугата. Поправянето на известни уязвимости и затягането на контрола за достъп до API са решенията, и двете са работа на оператора, не на клиента.

Какво трябва да проверят японските потребители и услуги сега

За организациите акцентът на доклада върху известните уязвимости сочи към основен контролен списък:

  • Потвърдете, че всяко внедряване на Metabase е актуализирано до версия, която адресира експлоатирания бъг за SQL инжекция.
  • Прегледайте API на мобилните приложения, за да се уверите, че всяка заявка е удостоверена и че потребителите могат да извличат само собствените си записи.
  • Третирайте публично разкритите уязвимости като спешни, тъй като атакуващите вече ги използват.

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

Как да ограничите излагането си след изтичане

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

Това, което помага, е ограничаването на щетите, когато се случи изтичане:

  • Използвайте уникална парола за всеки акаунт. Ако една услуга бъде компрометирана, атакуващите не могат да използват същите идентификационни данни другаде. Мениджърът на пароли прави това практично.
  • Включете мониторинг за изтичане на данни. Много браузъри, мениджъри на пароли и независими услуги ще ви уведомят, когато имейлът ви се появи в известно изтичане.
  • Споделяйте по-малко данни с приложения. Полета, които никога не сте предоставили, не могат да бъдат изтекли. Пропуснете незадължителните подробности и използвайте отделен имейл адрес за услуги с по-ниско доверие.
  • Активирайте многофакторно удостоверяване, където се предлага, така че изтекла парола сама по себе си да не е достатъчна.
  • Бъдете внимателни с неочаквани съобщения. Изтеклите данни за контакт често подхранват целенасочен фишинг.

Какво означава това за вас

Констатациите на JPCERT/CC подчертават, че излагането ви зависи в голяма степен от това колко добре компаниите, на които се доверявате, поддържат системите си. Не можете да поправите техните сървъри, но можете да намалите това, което е заложено на карта. Приемете, че някои от данните ви в крайна сметка ще бъдат изложени някъде, и се уверете, че това излагане не отключва другите ви акаунти.

За скорошен пример как изглежда излагането в голям мащаб в Япония, вижте нашето отразяване на изтичането на данни в KDDI, което изложи 12,2 млн. имейла на клиенти в Япония. Само имейл адресите може да изглеждат маловажни, но те са точно видът данни, които захранват фишинг кампании.

Основни изводи

Изтичанията на уеб данни в Япония, свързани със злоупотреба с мобилни API и неактуализиран софтуер, са проблем от страната на услугата и VPN няма да ги реши. Използвайте уникални пароли, активирайте мониторинг за изтичане на данни, включете многофакторно удостоверяване и давайте на приложенията само данните, които наистина им трябват. Тези навици няма да спрат изтичане, но могат да попречат то да се превърне в много по-голям проблем за вас.