Національна команда реагування на комп'ютерні надзвичайні ситуації Японії, 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 їх не вирішить. Використовуйте унікальні паролі, увімкніть моніторинг витоків, активуйте багатофакторну автентифікацію та надавайте застосункам лише ті дані, які їм справді потрібні. Ці звички не зупинять витік, але вони можуть завадити йому стати значно більшою проблемою для вас.