JARM Відбиток

Відбиток JARM – це пасивний метод зняття відбитків TLS на стороні клієнта, який використовується для ідентифікації конкретного стека TLS сервера або проксі-сервера шляхом аналізу його відповіді на серію спеціально створених зондів TLS ClientHello. Розроблений Salesforce, JARM надає унікальний відбиток для реалізації TLS сервера, дозволяючи операторам ідентифікувати конкретне програмне забезпечення сервера, виявляти проксі-сервери та відстежувати інфраструктуру.

Розуміння відбитків JARM

Зняття відбитків JARM (Just Another Rather Marvelous) працює шляхом надсилання 10 різних пакетів TLS ClientHello цільовому серверу. Кожен ClientHello розроблений зі специфічними, впорядкованими варіаціями в його параметрах, таких як підтримувані версії TLS, набори шифрів, розширення та еліптичні криві. Відповіді сервера на ці зонди, які включають обрану ним версію TLS, набір шифрів, розширення та інші параметри рукостискання, потім конкатенуються та хешуються для отримання 62-символьного відбитка.

Цей процес використовує тонкі відмінності в тому, як різні стеки TLS (наприклад, OpenSSL, Microsoft SChannel, Go's crypto/tls, BoringSSL, LibreSSL) узгоджують рукостискання TLS. Навіть незначні відмінності в конфігурації або рівнях патчів можуть призвести до різних відбитків JARM.

Деталі зондів JARM

10 зондів ClientHello відрізняються за кількома параметрами:
* Версії TLS: Зонди націлені на конкретні версії TLS (наприклад, TLS 1.0, 1.1, 1.2, 1.3).
* Набори шифрів: Кожен зонд включає окремий список і порядок наборів шифрів.
* Розширення: Використовуються різні набори та порядок розширень TLS (наприклад, SNI, ALPN, renegotiation_info, supported_groups).
* Еліптичні криві: Включені варіації підтримуваних еліптичних кривих.

Відповідь ServerHello сервера на кожен із цих 10 зондів фіксується. Ключові поля, витягнуті з цих відповідей, включають:
* Узгоджена версія TLS
* Обраний набір шифрів
* Список наявних розширень
* Форма відповіді розширення SNI (якщо є)

Ці витягнуті поля потім конкатенуються в один рядок. Цей рядок потім хешується за допомогою MD5, і підмножина цього хешу, разом із хешем SHA-256 повного рядка відповіді, формує остаточний 62-символьний відбиток JARM. Відбиток структурований таким чином, щоб кодувати інформацію про відповіді на кожен із 10 зондів.

Чому JARM корисний для проксі-сервісів

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

Ідентифікація сервера та програмного забезпечення

JARM може точно ідентифікувати базову бібліотеку TLS та конфігурацію сервера або проксі-сервера. Це дозволяє:
* Класифікація програмного забезпечення: Розрізнення між поширеними веб-серверами, такими як Nginx, Apache HTTP Server, Microsoft IIS, Caddy, або серверами додатків, такими як Tomcat, Jetty.
* Виявлення версій: Часто різні версії або рівні патчів одного й того ж програмного забезпечення даватимуть різні відбитки JARM через зміни в їхній реалізації стека TLS.
* Виявлення неправильної конфігурації: Несподівані відбитки можуть вказувати на нестандартні конфігурації або потенційні проблеми безпеки.

Виявлення та характеристика проксі-серверів

Для проксі-сервісу ідентифікація проміжних проксі-серверів є критично важливою для розуміння мережевих шляхів та стану безпеки.
* Зворотні проксі-сервери та CDN: Коли клієнт підключається до сервера за зворотним проксі-сервером, балансувальником навантаження або мережею доставки контенту (CDN), відбиток JARM відображатиме стек TLS проксі-сервера/вузла CDN, а не вихідного сервера. Це дозволяє ідентифікувати такі сервіси, як Cloudflare, Akamai, AWS CloudFront або Nginx/HAProxy, що діють як зворотний проксі-сервер.
* Прямі проксі-сервери: Прямий проксі-сервер може представляти свій власний стек TLS при виконанні перехоплення TLS (MITM). Якщо з'єднання клієнта перехоплюється, відбиток JARM, отриманий клієнтом, належатиме прямому проксі-серверу, а не призначеному пункту призначення. Прямі проксі-сервери, що не перехоплюють, зазвичай пропускають ClientHello, зберігаючи JARM вихідного сервера.
* WAF (Веб-фаєрволи додатків): Багато WAF працюють як зворотні проксі-сервери та представлятимуть свій власний відбиток JARM.

Безпека та аналітика загроз

JARM є цінним інструментом в операціях безпеки:
* Ідентифікація C2 шкідливого програмного забезпечення: Зловмисники часто повторно використовують певні стеки TLS для своєї інфраструктури Command and Control (C2). JARM може знімати відбитки цих серверів C2, дозволяючи їх ідентифікувати та відстежувати за різними IP-адресами або доменами.
* Мапування інфраструктури: Дослідники безпеки використовують JARM для мапування інфраструктури зловмисників, ідентифікації спільних компонентів та зв'язування, здавалося б, розрізнених кампаній.
* Виявлення фішингу: Виявлення несподіваних відбитків JARM для легітимних доменів може вказувати на спробу фішингу, коли зловмисник використовує іншу інфраструктуру.

Видимість мережі

JARM забезпечує глибше розуміння екосистеми TLS, з якою взаємодіє проксі-сервер:
* Встановлення базового рівня: Створення базового рівня очікуваних відбитків JARM для відомих сервісів та партнерів допомагає виявляти аномалії.
* Виявлення сервісів: Ідентифікація базової технології сервісів без необхідності взаємодії на рівні додатків.

Генерація відбитка JARM

Генерація відбитка JARM включає надсилання спеціальних зондів та обробку відповідей. Для цього доступні інструменти та бібліотеки.

Приклад: Використання бібліотеки Python jarm

Бібліотека Python jarm надає простий спосіб генерації відбитків.

import jarm

def get_jarm_fingerprint(host, port=443):
    """
    Генерує відбиток JARM для заданого хоста та порту.
    """
    try:
        fingerprint = jarm.string_fingerprint(host, port, timeout=5)
        return fingerprint
    except Exception as e:
        return f"Помилка генерації JARM для {host}:{port}: {e}"

if __name__ == "__main__":
    target_host_1 = "www.example.com"
    target_host_2 = "cloudflare.com" # Часто обслуговується власним стеком TLS Cloudflare
    target_host_3 = "nginx.org"

    print(f"JARM для {target_host_1}: {get_jarm_fingerprint(target_host_1)}")
    print(f"JARM для {target_host_2}: {get_jarm_fingerprint(target_host_2)}")
    print(f"JARM для {target_host_3}: {get_jarm_fingerprint(target_host_3)}")

Цей скрипт підключиться до вказаного хоста та порту, надішле зонди JARM та виведе отриманий 62-символьний відбиток.

Інтерпретація відбитків JARM

Сам відбиток JARM є непрозорим рядком. Його цінність походить від порівняння та асоціації з відомими сервісами або зловмисниками.
* Пошук у базі даних: Публічні та приватні бази даних (наприклад, JARM.info, Shodan, Censys) збирають та асоціюють відбитки JARM з відомим програмним забезпеченням, сервісами та організаціями.
* Розпізнавання шаблонів: Специфічні відбитки JARM часто корелюють з певними бібліотеками TLS або програмним забезпеченням сервера. Наприклад:
* 27d40d40d27d40d00045d40d00041d01dd2d4000000000494a000000000000 є поширеним відбитком для Nginx.
* 07d14d14d07d14d00041d14d0000000d1d2d00000000000000000000000000 часто спостерігається з Apache HTTP Server (OpenSSL).
* 07d07d07d07d07d00041d07d0000000d1d2d00000000000000000000000000 може вказувати на Cloudflare.
* Виявлення аномалій: Будь-яке відхилення від очікуваного відбитка для відомого сервісу вимагає розслідування.

JARM та поведінка проксі-сервера

Взаємодія між JARM та проксі-сервісами є центральною для його корисності.

Прямі проксі-сервери

• Прямі проксі-сервери, що не перехоплюють: Ці проксі-сервери просто пересилають ClientHello клієнта до сервера призначення. У цьому сценарії відбиток JARM, спостережений клієнтом (якби клієнт генерував JARM для сервера), був би відбитком вихідного сервера. Однак, якби сам проксі-сервіс діяв як клієнт і генерував JARM для призначення, він все одно отримав би JARM вихідного сервера.
• Прямі проксі-сервери, що перехоплюють (інспекція TLS): Коли прямий проксі-сервер виконує інспекцію TLS (наприклад, для сканування безпеки або примусового виконання політики), він діє як Man-in-the-Middle (MITM). Він завершує TLS-з'єднання клієнта та встановлює нове з вихідним сервером. Відбиток JARM, спостережений клієнтом, був би відбитком стека TLS прямого проксі-сервера. І навпаки, відбиток JARM, спостережений вихідним сервером, був би відбитком стека TLS прямого проксі-сервера. Ця поведінка є ключовим індикатором для виявлення інспекції TLS.

Зворотні проксі-сервери, балансувальники навантаження та CDN

Ці сервіси розташовані перед одним або кількома вихідними серверами та обробляють вхідні з'єднання клієнтів.
* Відбиток JARM, отриманий клієнтом, що підключається до сервісу, який обслуговується зворотним проксі-сервером, балансувальником навантаження або CDN, завжди відображатиме стек TLS цього посередника.
* Відбиток JARM вихідного сервера прихований від зовнішнього спостереження. Це основний механізм для ідентифікації цих типів сервісів. Наприклад, підключення до google.com дасть відбиток JARM для граничної інфраструктури Google, а не для конкретного бекенд-сервера, що обробляє запит.

Обмеження та міркування

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

JARM проти JA3

І JARM, і JA3 є методами зняття відбитків TLS, але вони служать різним цілям.

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