В екосистемі npm виявлено шкідливий пакет lotusbail, який маскувався під легітимну бібліотеку для роботи з WhatsApp Web API. Протягом щонайменше півроку він залишався доступним у реєстрі та був завантажений більш ніж 56 000 разів, непомітно надаючи зловмисникам доступ до переписки, контактів та акаунтів WhatsApp користувачів.
Маскування під популярну бібліотеку WhatsApp Web API Baileys
Пакет lotusbail є форком відомого open source‑проєкту WhiskeySockets Baileys, який широко застосовується для інтеграції застосунків із WhatsApp Web. Сам факт, що це був «звичайний форк» популярної бібліотеки, створював враження надійності й знижував пильність як розробників, так і автоматизованих засобів перевірки.
Ключова особливість атаки полягає в тому, що пакет дійсно надавав очікувану функціональність: реалізовував клієнтську частину для роботи з WhatsApp Web API. Завдяки цьому він природно вбудовувався в існуючий код, не викликаючи явних збоїв чи підозрілої поведінки, що типово для атаки на ланцюжок постачання ПЗ (software supply chain attack).
Як працює шкідливий npm‑пакет lotusbail
Перехоплення аутентифікації та сесій WhatsApp
За результатами аналізу Koi Security, шкідливий код в lotusbail реалізовано як обгортку над легітимним WebSocket‑клієнтом, що взаємодіє з серверами WhatsApp. Увесь трафік між застосунком і WhatsApp спочатку проходив через цей додатковий шар, де й відбувалося непомітне перехоплення даних.
У момент аутентифікації в WhatsApp Web шкідливий компонент перехоплював токени доступу та ключі сесій. Аналогічно оброблялися всі вхідні та вихідні повідомлення, списки контактів, а також надіслані й отримані медіафайли та документи. У результаті застосунки, що підключали lotusbail, фактично перетворювалися на інструменти прихованого моніторингу акаунтів користувачів у WhatsApp.
Обфускація, шифрування та передавання викрадених даних
Зловмисники приділили значну увагу ускладненню аналізу коду й трафіку. За даними дослідників, у lotusbail застосовано кастомну реалізацію RSA разом із кількома шарами обфускації: маніпуляції з Unicode, стиснення за допомогою LZString та подальше шифрування алгоритмом AES. Такий підхід суттєво ускладнює реверс‑інжиніринг і сигнатурне виявлення шкідливої активності.
Лише після проходження всіх етапів шифрування та маскування структури, дані надсилалися на керувальні сервери (C2) зловмисників. При поверхневому аналізі мережевого трафіку це могло виглядати як звичайний зашифрований обмін даними, що ще більше знижувало шанси на вчасне виявлення інциденту.
Закріплення доступу через механізм «Зв’язані пристрої» WhatsApp
Окремо дослідники виділяють можливість прив’язати пристрій атакуючого до акаунта жертви через стандартний механізм multi‑device у WhatsApp («Зв’язані пристрої»). Це означає, що навіть після видалення шкідливого npm‑пакета з проєкту, зловмисники могли зберігати довгостроковий доступ до листування.
Поки користувач вручну не перевірить розділ «Зв’язані пристрої» у налаштуваннях WhatsApp і не від’єднає невідомі сесії, атакуючий має змогу читати нові повідомлення, надсилати їх від імені жертви та отримувати оновлені токени доступу. Більшість класичних захисних рішень не відстежують такі дії безпосередньо в інтерфейсі месенджера.
Чому шкідливий пакет так довго залишався непоміченим
За оцінкою Koi Security, у коді lotusbail реалізовано щонайменше 27 пасток з нескінченними циклами, покликаних ускладнити статичний і динамічний аналіз. Такі техніки anti‑debug та anti‑reverse часто змушують автоматизовані інструменти «здаватися» або давати неповні результати.
Вирішальним фактором також стала мімікрія під типовий форк популярного open source‑проєкту, при цьому основна функціональність працювала коректно. На практиці багато команд обмежуються побіжним переглядом вихідного коду залежностей і рідко моніторять поведінку таких бібліотек у runtime, особливо якщо вони сприймаються як «інфраструктурні» та «загальноприйняті».
Інцидент з lotusbail вписується в широку тенденцію зростання supply chain атак у реєстрах npm, PyPI та інших екосистемах. Подібні випадки вже неодноразово призводили до компрометації як кінцевих користувачів, так і корпоративної інфраструктури, підриваючи довіру до ланцюжка постачання програмного забезпечення.
Рекомендації для розробників та команд безпеки
Негайні дії для тих, хто використовував lotusbail
Якщо lotusbail колись використовувався у вашому проєкті, доцільно виконати такі кроки:
- Негайно видалити пакет із залежностей, build‑середовищ та контейнерів.
- Провести інвентаризацію всіх репозиторіїв і гілок, включно зі старими та тестовими середовищами, де бібліотека могла залишитися.
- Перевірити в WhatsApp розділ «Зв’язані пристрої» та вручну від’єднати всі невідомі або підозрілі підключення.
- За потреби перегенерувати ключі, токени доступу та креденшали, пов’язані з інтеграціями та ботами WhatsApp.
Посилення безпеки ланцюжка постачання npm
Щоб знизити ризик подібних інцидентів у майбутньому, варто впровадити низку практик безпеки ланцюжка постачання ПЗ:
- Проводити не лише код‑рев’ю, а й динамічний аналіз поведінки залежностей у sandbox‑середовищі з акцентом на мережеву активність і файлові операції.
- Моніторити підозрілі вихідні з’єднання, особливо в моменти аутентифікації користувачів і під час роботи з месенджерами чи іншими чутливими сервісами.
- Використовувати SCA‑інструменти (Software Composition Analysis), підписані артефакти та lock‑файли, щоб контролювати точні версії залежностей.
- Дотримуватися принципу мінімально необхідних привілеїв для сервісів, що взаємодіють із зовнішніми API, включно з WhatsApp Web API.
- Формалізувати процес додавання нових npm‑пакетів: обов’язковий ручний review, оцінка репутації автора й репозиторію, увага до підозрілих форків популярних бібліотек.
Історія з lotusbail демонструє, що навіть звичні й на перший погляд безпечні бібліотеки в екосистемі npm можуть стати каналом прихованої компрометації. Регулярний аудит залежностей, моніторинг поведінки застосунків у режимі виконання та зріла політика керування open source‑компонентами є критично важливими для будь‑якої команди розробки. Саме зараз варто переглянути свої npm‑залежності, посилити контроль за інтеграціями з месенджерами та інвестувати час у підвищення зрілості процесів безпеки ланцюжка постачання програмного забезпечення.
