D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Автор: miserylord
Эксклюзивно для форума: xss.is
Добро пожаловать в мир поиска и эксплуатации багов, на связи miserylord!
Итак, во время сканирования сайтов любым сканером вы, скорее всего, довольно часто обнаружите те или иные ошибки конфигурации SSL/TLS. Они действительно довольно распространены. В то же время этот тип уязвимостей, возможно, является одним из наименее освещённых среди всех уязвимостей веба. Это в целом понятно, ведь тема криптографии, пожалуй, одна из самых сложных. Реально вникнуть в математику криптографических протоколов — задача совсем нетривиальная. К тому же большинство Common Vulnerabilities and Exposures датированы временами чуть ли не Древней Греции.
Начнем с небольшого теоретического введения:
SSL (Secure Sockets Layer) и TLS (Transport Layer Security) — это протоколы, которые обеспечивают безопасное соединение между устройством, клиентом и сервером. Они, в том числе, защищают данные от перехвата или подмены. Если не углубляться в историю, TLS — это всего лишь более современная и безопасная версия SSL. На данный момент актуальная версия — TLS 1.3, а термины TLS и SSL в целом часто используются взаимозаменяемо.
Протокол HTTPS (HyperText Transfer Protocol Secure) — это комбинация HTTP и SSL/TLS. Он обеспечивает, во-первых, шифрование данных, защищая их от перехвата со стороны провайдера (ISP), а во-вторых, гарантирует, что общение происходит именно с тем сервером, на который вы изначально хотели попасть.
За выдачу сертификатов отвечают специальные организации — Центры сертификации (Certificate Authorities, CA). Они выдают сертификаты для сайтов, гарантируя, что связь происходит с подлинным сервером. Это осуществляется в рамках стандарта цифровых сертификатов X.509. Сертификат, по сути, — это аналог документа.
Для получения сертификата проходит примерно следующий процесс: всё работает в рамках архитектуры открытых и закрытых ключей. Открытые ключи доступны всем желающим, но они гарантируют, что сообщение подписано владельцем соответствующего закрытого ключа. Владелец сайта генерирует пару ключей — закрытый и открытый — и отправляет запрос в центр сертификации (CSR), предоставляя открытый ключ и информацию о сайте. Центр сертификации проверяет данные и выдает сертификат, связывающий открытый ключ с именем сайта. Сертификат затем устанавливается на сервер. Браузеры используют его для проверки подлинности сайта.
Изначально этот процесс задумывался как способ заработка для CA, но сейчас существуют и бесплатные центры, например, Let’s Encrypt, которые считаются некоммерческими организациями. Я не до конца уверен, зачем они это делают, но факт остается фактом.
Когда пользователь заходит на сайт, браузер запускает процесс валидации сертификата: он проверяет, кем подписан сертификат и доверяет ли этому центру сертификации. Также проверяется срок действия сертификата — он не должен быть просрочен.
Сертификат можно подписать самостоятельно, но в таком случае браузер будет ругаться и показывать предупреждение безопасности. Однако если добавить этот сертификат в менеджер сертификатов конкретного браузера, предупреждений не будет.
Мне кажется, это видео прекрасно раскрывает тему: How does HTTPS work? What's a CA? What's a self-signed Certificate? - YouTube. Также, отличное видео: .
Теперь давайте перейдем к практике. Я ознакомился с несколькими утилитами и пришел к выводу, что для поиска уязвимостей лучше всего подходит testssl. Эта утилита, помимо прочего, может сканировать сайты на наличие уязвимостей. Собрав несколько десятков URL (а именно 84) из одного каталога сайтов, я приступил к сканированию. testssl дает очень обширный лог аналитики, но чтобы сосредоточиться на уязвимостях, будет достаточно флага --vulnerable.
Результаты сканирования оказались следующими: самой распространённой уязвимостью стала CVE-2011-3389, известная как BEAST. Она встретилась на 30 сайтах. На втором месте — LUCKY13 (CVE-2013-0169) с 22 сайтами. Однако в логах указано "experimental" и "potentially", что может свидетельствовать о ложных срабатываниях. На третьем месте — BREACH (CVE-2013-3587), обнаруженная на 12 сайтах. В логах также указано, что эта уязвимость "потенциально не ОК" и может быть проигнорирована для сайтов со статическим контентом или при отсутствии секретных данных.
Четвёртое место заняла SWEET32 (CVE-2016-2183, CVE-2016-6329), обнаруженная на 7 сайтах. Далее дважды была выявлена LOGJAM (CVE-2015-4000), а один раз — RC4 (CVE-2013-2566, CVE-2015-2808).
Кроме этого, четыре раза встретилась уязвимость Secure Client-Initiated Renegotiation, которая может потенциально позволить провести DoS-атаку. Также один раз была обнаружена уязвимость под названием ROBOT с пометкой "слабая уязвимость". В логах отмечается, что атака займёт слишком много времени либо сервер не поддерживает ни один набор шифров с использованием транспортных ключей RSA.
Окей, давайте подробно рассмотрим каждую CVE и её возможности.
Уязвимость, которая встречалась чаще всего — CVE-2011-3389, под названием BEAST (Browser Exploit Against SSL/TLS), на мой взгляд, не слишком полезна. Итак, что она позволяет сделать?
BEAST позволяет перехватывать зашифрованный трафик и расшифровывать его, используя метод атаки на блочные шифры (CBC — Cipher Block Chaining). Проще говоря, она позволяет перехватывать куки и токены на сайтах, где сканер определил её наличие.
Для того чтобы BEAST сработала, атакующему нужно быть в позиции Man in the middle, то есть перехватывать трафик между клиентом и сервером. Это можно сделать разными способами, например, с помощью незащищенной сети Wi-Fi или вредоносного расширения браузера. Однако стоит отметить, что этот способ перехвата данных довольно сложный и громоздкий. Например, те же вредоносные расширения могут предоставить доступ к этим данным гораздо проще и понятнее.
Но это ещё не всё. CVE-2011-3389 требует использования версии протокола TLS 1.0, потому что в актуальной версии TLS 1.3 полностью исключён режим CBC. BEAST также комбинируется с атакой понижения версии протокола, которая происходит во время хендшейка, когда клиент и сервер договариваются о версии протокола, которую будут использовать.
У этой уязвимости нет готового эксплоита, однако есть PoC (Proof of Concept), доступный на GitHub: GitHub - mpgn/BEAST-PoC.
Моё мнение о BEAST: это очень громоздкий способ перехвата трафика, и если цель — перехватить куки, то вредоносное расширение будет намного проще и эффективнее.
По поводу атаки на понижение версии протокола. Код для реализации такой атаки будет максимально простым. Всё, что нужно сделать, — сообщить серверу, что мы, как клиент, поддерживаем только ограниченную версию протокола. Если сервер поддерживает эту версию, общение будет установлено именно через неё. Пример на Go выглядит следующим образом:
C-подобный: Скопировать в буфер обмена
Информации про LUCKY13 (CVE-2013-0169) оказалось ещё меньше. LUCKY13 является разновидностью атаки по времени, при которой возможно извлечь информацию о содержимом зашифрованного сообщения, просто наблюдая за временем, которое сервер тратит на обработку различных запросов. Хотя, как сказать, "просто"... Я не обнаружил ни готовых эксплоитов, ни PoC.
Честно говоря, я искал что-то другое. Атаки, которые могут быть реализованы в позиции Man in the middle, действительно интересны, но для этого необходимо сначала перехватить трафик. Поэтому я не увидел реальной возможности эксплуатировать LUCKY13 в её текущем виде.
Идем дальше, BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) — это уязвимость, которая позволяет проводить атаки на HTTPS-соединения с целью извлечения информации из зашифрованного трафика. Это могут быть секретные токены, CSRF-токены или другие чувствительные данные.
BREACH — разновидность атаки на основе побочного канала. Она использует анализ зашифрованных данных, основываясь на их сжимаемости. Уязвимость CVE-2013-3587 эксплуатирует сжатие HTTP-данных, выполняя атаку для расшифровки зашифрованного трафика. Основная идея атаки заключается в том, что данные HTTP-сообщений сжимаются до шифрования. Это позволяет извлекать часть содержимого путём анализа изменений в размере зашифрованных данных.
Три необходимых условия для атаки BREACH:
Атака BREACH также требует нахождения в позиции Man in the middle, но её эксплуатация значительно проще и понятнее по сравнению с другими атаками.
Готовый эксплоит доступен на GitHub: GitHub - miguelob/BREACH: Example of a BREACH attack on a test website to extract secret tokens.
Напомню, что с CVE-2013-3587 у меня было 12 сайтов. При проверке с помощью эксплоита на большинстве из них скрипт выдавал ошибки. Однако на трёх из них скрипт сработал.
Судя по этому видео: , даже крупные ресурсы могут быть подвержены этой атаке. Я бы рассматривал её с точки зрения программы Bug Bounty.
SWEET32 (CVE-2016-2183, CVE-2016-6329) в чем-то похожа на LUCKY13 и BEAST, хотя механизм ее действия отличается и основан на коллизиях блочных шифров. Интересно, что, находясь в позиции man-in-the-middle, SWEET32 позволяет частично расшифровывать VPN-трафик, если VPN-туннель использует 3DES или Blowfish. В плане практической реализации это, пожалуй, самая трудоемкая атака: согласно PoC, на получение токена ушло 18,6 часа времени и 705 ГБ трафика (то есть для эксплуатации атаки такой объем трафика должен пройти через перехваченную сессию). Подробнее: https://sweet32.info/
Также стоит упомянуть RC4 (CVE-2013-2566, CVE-2015-2808). RC4 (Rivest Cipher 4) — это потоковый шифр, который долгое время считался стандартом для шифрования в нескольких протоколах, включая SSL/TLS. Уязвимости CVE-2013-2566 и CVE-2015-2808 связаны с недостатками самого алгоритма RC4, которые позволяют проводить атаки, направленные на раскрытие зашифрованных данных. Как и в случае с SWEET32, такие атаки требуют огромного количества трафика, что делает их актуальными только в случае комбинированных атак. Однако важно отметить, что RC4 является устаревшим стандартом.
Ну и, наконец, LOGJAM (CVE-2015-4000). Ранее я демонстрировал процесс понижения версии протокола — это схожая уязвимость, но относится она не к версии протокола, а к алгоритму Диффи-Хеллмана, используемому для установки шифрованных соединений. Для успешной эксплуатации также требуется позиция man-in-the-middle.
Изначально меня заинтересовала такая уязвимость, как Heartbleed. Heartbleed эксплуатировала метод heartbeat (сердцебиение), который представляет собой что-то вроде пинга в рамках сессии. Клиент мог увеличить объем получаемых данных в ответе и вместо 1 КБ получить 64 КБ. В рамках этих 64 КБ могли возвращаться дополнительные данные, которые не предназначались для клиента. Я хотел обнаружить что-то похожее, но понял, что Heartbleed скорее исключение из ряда подобных уязвимостей. Это довольно старая уязвимость, но некоторые хосты, все еще уязвимые, можно найти через Shodan. Помимо дорки vuln:cve-2014-0160, можно использовать запрос OpenSSL 1.0.1 port:443, который в результате выдает 303 хоста.
Для эксплуатации удобнее всего использовать Metasploit. Запускаем msfconsole, ищем auxiliary/scanner/ssl/openssl_heartbleed, устанавливаем RHOSTS на IP-адрес и включаем verbose в true. В случае успешной эксплуатации мы получим перехваченные данные, хотя это происходит не всегда. Также существуют отдельные эксплойты, но те, которые я находил, отказывались работать.
По результатам тестирования я пришел к выводу, что большинство обнаруженных уязвимостей не представляет большого интереса. Именно поэтому этот вектор остается в самом конце списка. Тем не менее, он может быть полезен в более сложных атаках, и полностью игнорировать его не стоит.
Трям! Пока!
Эксклюзивно для форума: xss.is
Добро пожаловать в мир поиска и эксплуатации багов, на связи miserylord!
Итак, во время сканирования сайтов любым сканером вы, скорее всего, довольно часто обнаружите те или иные ошибки конфигурации SSL/TLS. Они действительно довольно распространены. В то же время этот тип уязвимостей, возможно, является одним из наименее освещённых среди всех уязвимостей веба. Это в целом понятно, ведь тема криптографии, пожалуй, одна из самых сложных. Реально вникнуть в математику криптографических протоколов — задача совсем нетривиальная. К тому же большинство Common Vulnerabilities and Exposures датированы временами чуть ли не Древней Греции.
Начнем с небольшого теоретического введения:
SSL (Secure Sockets Layer) и TLS (Transport Layer Security) — это протоколы, которые обеспечивают безопасное соединение между устройством, клиентом и сервером. Они, в том числе, защищают данные от перехвата или подмены. Если не углубляться в историю, TLS — это всего лишь более современная и безопасная версия SSL. На данный момент актуальная версия — TLS 1.3, а термины TLS и SSL в целом часто используются взаимозаменяемо.
Протокол HTTPS (HyperText Transfer Protocol Secure) — это комбинация HTTP и SSL/TLS. Он обеспечивает, во-первых, шифрование данных, защищая их от перехвата со стороны провайдера (ISP), а во-вторых, гарантирует, что общение происходит именно с тем сервером, на который вы изначально хотели попасть.
За выдачу сертификатов отвечают специальные организации — Центры сертификации (Certificate Authorities, CA). Они выдают сертификаты для сайтов, гарантируя, что связь происходит с подлинным сервером. Это осуществляется в рамках стандарта цифровых сертификатов X.509. Сертификат, по сути, — это аналог документа.
Для получения сертификата проходит примерно следующий процесс: всё работает в рамках архитектуры открытых и закрытых ключей. Открытые ключи доступны всем желающим, но они гарантируют, что сообщение подписано владельцем соответствующего закрытого ключа. Владелец сайта генерирует пару ключей — закрытый и открытый — и отправляет запрос в центр сертификации (CSR), предоставляя открытый ключ и информацию о сайте. Центр сертификации проверяет данные и выдает сертификат, связывающий открытый ключ с именем сайта. Сертификат затем устанавливается на сервер. Браузеры используют его для проверки подлинности сайта.
Изначально этот процесс задумывался как способ заработка для CA, но сейчас существуют и бесплатные центры, например, Let’s Encrypt, которые считаются некоммерческими организациями. Я не до конца уверен, зачем они это делают, но факт остается фактом.
Когда пользователь заходит на сайт, браузер запускает процесс валидации сертификата: он проверяет, кем подписан сертификат и доверяет ли этому центру сертификации. Также проверяется срок действия сертификата — он не должен быть просрочен.
Сертификат можно подписать самостоятельно, но в таком случае браузер будет ругаться и показывать предупреждение безопасности. Однако если добавить этот сертификат в менеджер сертификатов конкретного браузера, предупреждений не будет.
Мне кажется, это видео прекрасно раскрывает тему: How does HTTPS work? What's a CA? What's a self-signed Certificate? - YouTube. Также, отличное видео: .
Теперь давайте перейдем к практике. Я ознакомился с несколькими утилитами и пришел к выводу, что для поиска уязвимостей лучше всего подходит testssl. Эта утилита, помимо прочего, может сканировать сайты на наличие уязвимостей. Собрав несколько десятков URL (а именно 84) из одного каталога сайтов, я приступил к сканированию. testssl дает очень обширный лог аналитики, но чтобы сосредоточиться на уязвимостях, будет достаточно флага --vulnerable.
Результаты сканирования оказались следующими: самой распространённой уязвимостью стала CVE-2011-3389, известная как BEAST. Она встретилась на 30 сайтах. На втором месте — LUCKY13 (CVE-2013-0169) с 22 сайтами. Однако в логах указано "experimental" и "potentially", что может свидетельствовать о ложных срабатываниях. На третьем месте — BREACH (CVE-2013-3587), обнаруженная на 12 сайтах. В логах также указано, что эта уязвимость "потенциально не ОК" и может быть проигнорирована для сайтов со статическим контентом или при отсутствии секретных данных.
Четвёртое место заняла SWEET32 (CVE-2016-2183, CVE-2016-6329), обнаруженная на 7 сайтах. Далее дважды была выявлена LOGJAM (CVE-2015-4000), а один раз — RC4 (CVE-2013-2566, CVE-2015-2808).
Кроме этого, четыре раза встретилась уязвимость Secure Client-Initiated Renegotiation, которая может потенциально позволить провести DoS-атаку. Также один раз была обнаружена уязвимость под названием ROBOT с пометкой "слабая уязвимость". В логах отмечается, что атака займёт слишком много времени либо сервер не поддерживает ни один набор шифров с использованием транспортных ключей RSA.
Окей, давайте подробно рассмотрим каждую CVE и её возможности.
Уязвимость, которая встречалась чаще всего — CVE-2011-3389, под названием BEAST (Browser Exploit Against SSL/TLS), на мой взгляд, не слишком полезна. Итак, что она позволяет сделать?
BEAST позволяет перехватывать зашифрованный трафик и расшифровывать его, используя метод атаки на блочные шифры (CBC — Cipher Block Chaining). Проще говоря, она позволяет перехватывать куки и токены на сайтах, где сканер определил её наличие.
Для того чтобы BEAST сработала, атакующему нужно быть в позиции Man in the middle, то есть перехватывать трафик между клиентом и сервером. Это можно сделать разными способами, например, с помощью незащищенной сети Wi-Fi или вредоносного расширения браузера. Однако стоит отметить, что этот способ перехвата данных довольно сложный и громоздкий. Например, те же вредоносные расширения могут предоставить доступ к этим данным гораздо проще и понятнее.
Но это ещё не всё. CVE-2011-3389 требует использования версии протокола TLS 1.0, потому что в актуальной версии TLS 1.3 полностью исключён режим CBC. BEAST также комбинируется с атакой понижения версии протокола, которая происходит во время хендшейка, когда клиент и сервер договариваются о версии протокола, которую будут использовать.
У этой уязвимости нет готового эксплоита, однако есть PoC (Proof of Concept), доступный на GitHub: GitHub - mpgn/BEAST-PoC.
Моё мнение о BEAST: это очень громоздкий способ перехвата трафика, и если цель — перехватить куки, то вредоносное расширение будет намного проще и эффективнее.
По поводу атаки на понижение версии протокола. Код для реализации такой атаки будет максимально простым. Всё, что нужно сделать, — сообщить серверу, что мы, как клиент, поддерживаем только ограниченную версию протокола. Если сервер поддерживает эту версию, общение будет установлено именно через неё. Пример на Go выглядит следующим образом:
C-подобный: Скопировать в буфер обмена
Код:
package main
import (
"crypto/tls"
"fmt"
"log"
"net"
)
func checkTLS12Support(host string, port string) {
config := &tls.Config{
MinVersion: tls.VersionTLS12, // Минимальная версия TLS - 1.2
MaxVersion: tls.VersionTLS12, // Максимальная версия TLS - 1.2
ServerName: host,
InsecureSkipVerify: false,
}
conn, err := net.Dial("tcp", host+":"+port)
if err != nil {
log.Fatalf("Ошибка подключения: %v", err)
}
defer conn.Close()
tlsConn := tls.Client(conn, config)
err = tlsConn.Handshake()
if err != nil {
log.Fatalf("Ошибка рукопожатия TLS: %v", err)
}
connectionState := tlsConn.ConnectionState()
if connectionState.Version == tls.VersionTLS12 {
fmt.Println("Сервер поддерживает TLS 1.2.")
} else {
fmt.Printf("Сервер не поддерживает TLS 1.2. Используемая версия: %x\n", connectionState.Version)
}
}
func main() {
checkTLS12Support("site.com", "443")
}Информации про LUCKY13 (CVE-2013-0169) оказалось ещё меньше. LUCKY13 является разновидностью атаки по времени, при которой возможно извлечь информацию о содержимом зашифрованного сообщения, просто наблюдая за временем, которое сервер тратит на обработку различных запросов. Хотя, как сказать, "просто"... Я не обнаружил ни готовых эксплоитов, ни PoC.
Честно говоря, я искал что-то другое. Атаки, которые могут быть реализованы в позиции Man in the middle, действительно интересны, но для этого необходимо сначала перехватить трафик. Поэтому я не увидел реальной возможности эксплуатировать LUCKY13 в её текущем виде.
Идем дальше, BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) — это уязвимость, которая позволяет проводить атаки на HTTPS-соединения с целью извлечения информации из зашифрованного трафика. Это могут быть секретные токены, CSRF-токены или другие чувствительные данные.
BREACH — разновидность атаки на основе побочного канала. Она использует анализ зашифрованных данных, основываясь на их сжимаемости. Уязвимость CVE-2013-3587 эксплуатирует сжатие HTTP-данных, выполняя атаку для расшифровки зашифрованного трафика. Основная идея атаки заключается в том, что данные HTTP-сообщений сжимаются до шифрования. Это позволяет извлекать часть содержимого путём анализа изменений в размере зашифрованных данных.
Три необходимых условия для атаки BREACH:
- Использование HTTP-сжатия. Это как раз то, что отмечает сканер.
- Отображение вводимых пользователем данных в HTTP-ответе.
- Наличие в теле HTTP-ответа секрета. Например, CSRF-токена.
Атака BREACH также требует нахождения в позиции Man in the middle, но её эксплуатация значительно проще и понятнее по сравнению с другими атаками.
Готовый эксплоит доступен на GitHub: GitHub - miguelob/BREACH: Example of a BREACH attack on a test website to extract secret tokens.
Напомню, что с CVE-2013-3587 у меня было 12 сайтов. При проверке с помощью эксплоита на большинстве из них скрипт выдавал ошибки. Однако на трёх из них скрипт сработал.
Судя по этому видео: , даже крупные ресурсы могут быть подвержены этой атаке. Я бы рассматривал её с точки зрения программы Bug Bounty.
SWEET32 (CVE-2016-2183, CVE-2016-6329) в чем-то похожа на LUCKY13 и BEAST, хотя механизм ее действия отличается и основан на коллизиях блочных шифров. Интересно, что, находясь в позиции man-in-the-middle, SWEET32 позволяет частично расшифровывать VPN-трафик, если VPN-туннель использует 3DES или Blowfish. В плане практической реализации это, пожалуй, самая трудоемкая атака: согласно PoC, на получение токена ушло 18,6 часа времени и 705 ГБ трафика (то есть для эксплуатации атаки такой объем трафика должен пройти через перехваченную сессию). Подробнее: https://sweet32.info/
Также стоит упомянуть RC4 (CVE-2013-2566, CVE-2015-2808). RC4 (Rivest Cipher 4) — это потоковый шифр, который долгое время считался стандартом для шифрования в нескольких протоколах, включая SSL/TLS. Уязвимости CVE-2013-2566 и CVE-2015-2808 связаны с недостатками самого алгоритма RC4, которые позволяют проводить атаки, направленные на раскрытие зашифрованных данных. Как и в случае с SWEET32, такие атаки требуют огромного количества трафика, что делает их актуальными только в случае комбинированных атак. Однако важно отметить, что RC4 является устаревшим стандартом.
Ну и, наконец, LOGJAM (CVE-2015-4000). Ранее я демонстрировал процесс понижения версии протокола — это схожая уязвимость, но относится она не к версии протокола, а к алгоритму Диффи-Хеллмана, используемому для установки шифрованных соединений. Для успешной эксплуатации также требуется позиция man-in-the-middle.
Изначально меня заинтересовала такая уязвимость, как Heartbleed. Heartbleed эксплуатировала метод heartbeat (сердцебиение), который представляет собой что-то вроде пинга в рамках сессии. Клиент мог увеличить объем получаемых данных в ответе и вместо 1 КБ получить 64 КБ. В рамках этих 64 КБ могли возвращаться дополнительные данные, которые не предназначались для клиента. Я хотел обнаружить что-то похожее, но понял, что Heartbleed скорее исключение из ряда подобных уязвимостей. Это довольно старая уязвимость, но некоторые хосты, все еще уязвимые, можно найти через Shodan. Помимо дорки vuln:cve-2014-0160, можно использовать запрос OpenSSL 1.0.1 port:443, который в результате выдает 303 хоста.
Для эксплуатации удобнее всего использовать Metasploit. Запускаем msfconsole, ищем auxiliary/scanner/ssl/openssl_heartbleed, устанавливаем RHOSTS на IP-адрес и включаем verbose в true. В случае успешной эксплуатации мы получим перехваченные данные, хотя это происходит не всегда. Также существуют отдельные эксплойты, но те, которые я находил, отказывались работать.
По результатам тестирования я пришел к выводу, что большинство обнаруженных уязвимостей не представляет большого интереса. Именно поэтому этот вектор остается в самом конце списка. Тем не менее, он может быть полезен в более сложных атаках, и полностью игнорировать его не стоит.
Трям! Пока!