Новости мира информационной безопасности. Расследование и реагирование на инциденты. Кибербезопасность.

Новости информационной безопасности




crackle - Crack Bluetooth Smart (BLE) Encryption

crackle cracks BLE Encryption (AKA Bluetooth Smart).

crackle exploits a flaw in the BLE pairing process that allows an attacker to guess or very quickly brute force the TK (Temporary Key). With the TK and other data collected from the pairing process, the STK (Short Term Key) and later the LTK (Long Term Key) can be collected.

With the STK and LTK, all communications between the master and the slave can be decrypted.

Before attempting to use crackle, review the FAQ to determine whether it is the appropriate tool to use in your situation.

Modes of Operation

crackle has two major modes of operation: Crack TK and Decrypt with LTK.

Crack TK

This is the default mode used when providing crackle with an input file using -i .

In Crack TK mode, crackle brute forces the TK used during a BLE pairing event. crackle exploits the fact that the TK in Just Works(tm) and 6-digit PIN is a value in the range [0,999999] padded to 128 bits.

crackle employs several methods to perform this brute force: a very fast method if all pairing packets are present in the input file, and a slow method if a minimum set of packets is present.

To use this mode, launch crackle with an input PCAP or PcapNG file containing one or more connections with a BLE pairing conversation. crackle will analyze all connections, determine whether it is possible to crack a given connection, and automatically choose the best strategy to crack each one.

If the TK successfully cracks, crackle will derive the remaining keys used to encrypt the rest of the connection and will decrypt any encrypted packets that follow. If the LTK is exchanged (typically the first thing done after encryption is established) crackle will output this value to stdout. The LTK can be used to decrypt any future communications between the two endpoints.

Provide crackle with an output file using -o to create a new PCAP file containing the decrypted data (in addition to the already unencrypted data).

Example usage:

$ crackle -i input.pcap -o decrypted.pcap

Decrypt with LTK
In Decrypt with LTK mode, crackle uses a user-supplied LTK to decrypt communications between a master and slave. This mode is identical to the decryption portion of Crack TK mode.
Example usage:
$ crackle -i encrypted.pcap -o decrypted.pcap -l 81b06facd90fe7a6e9bbd9cee59736a7

Running Crackle

Crack TK Mode
In Crack TK mode, crackle requires a PCAP file that contains a BLE pairing event. The best way to generate such a file is to use an Ubertooth to capture a pairing event between a master and a slave.
To check if your PCAP file contains all the necessary packets, run crackle with the -i option:

crackle -i <file.pcap>
crackle will analyze each connection in the input file and output the results of its analysis to stdout. If you have all the components of a pairing conversation, the output will look like this:
Analyzing connection 0:
  xx:xx:xx:xx:xx:xx (public) -> yy:yy:yy:yy:yy:yy (public)
  Found 13 encrypted packets

  Cracking with strategy 0, 20 bits of entropy

  !!!
  TK found: 412741
  !!!

  Decrypted 12 packets
  LTK found: 81b06facd90fe7a6e9bbd9cee59736a7

Specify an output file with -o to decrypt packets!
To decrypt all packets, add the -o option:
crackle -i <file.pcap> -o <output.pcap>
The output file will contain decrypted versions of all the encrypted packets from the original PCAP, as well as all the unencrypted packets. Note that CRCs are not recalculated, so the CRCs of decrypted packets will be incorrect.

Decrypt with LTK
In Decrypt with LTK mode, crackle requires a PCAP file that contains at a minimum LL_ENC_REQ and LL_ENC_RSP packets and the LTK used to encrypt the communications.
The format for LTK is a 128 bit hexadecimal number with no spaces or separators, most-significant octet to least-significant octet. Example:

-l 81b06facd90fe7a6e9bbd9cee59736a7
To check if your PCAP file contains all the necessary packets, run crackle with -i and -l:
crackle -i <file.pcap> -l <ltk>
If you have both of the required packets, the program should produce output similar to this:
Analyzing connection 0:
  xx:xx:xx:xx:xx:xx (public) -> yy:yy:yy:yy:yy:yy (public)
  Found 9 encrypted packets
  Decrypted 6 packets

Specify an output file with -o to decrypt packets!
To decrypt all packets, add the -o option:
crackle -i <file.pcap> -o <out.pcap> -l <ltk>
The output file will be produced similarly to the output file described above.

Sample Files
The test files included in the tests directory serve as interesting input for playing with crackle. Review the README files included in each test's subdirectory.
Grab some sample files for cracking with crackle. Refer to the README inside the tarball for more information:
https://lacklustre.net/bluetooth/crackle-sample.tgz

Frequently Asked Questions
We have compiled a list of Frequently Asked Questions .

See Also


Дата: 2017-02-25 15:13:27

Источник: http://www.kitploit.com/2017/02/crackle-crack-bluetooth-smart-ble.html



Powershell Stuff, Windows 10

Source: InterWebs
I recently had some Windows 10 systems come across my desk, and as part of my timeline creation process, I extracted the Windows Event Log files of interest, and ran them through my regular sequence of commands.  While I was analyzing the system timeline, I ran across some interesting entries, specifically "Microsoft-Windows-Powershell/4104" events; these events appeared to contain long strings of encoded text.  Many of the events were clustered together, up to 20 at a time, and as I scrolled through these events, I saw strings (not encoded) that made me think that I was looking at activity of interest to my exam.  Further, the events themselves were clustered 'near' other events of interest, to include indications that a Python script 'compiled' as a Windows executable had been run in order to steal credentials.  So, I sort of figured that this was something worth looking into, so during a team call, I posed the question of, "...has anyone seen this..." to the group, and got a response; one of my teammates pointed me toward Matt Dunwoody's block-parser.py script.  My own research had revealed that FireEye, CrowdStrike, and even Microsoft had talked about these events, and what they mean.

From the FireEye blog post (authored by Matt Dunwoody):

Script block logging records blocks of code as they are executed by the PowerShell engine, thereby capturing the full contents of code executed by an attacker, including scripts and commands. Due to the nature of script block logging, it also records de-obfuscated code as it is executed. For example, in addition to recording the original obfuscated code, script block logging records the decoded commands passed with PowerShell’s -EncodedCommand argument, as well as those obfuscated with XOR, Base64, ROT13, encryption, etc., in addition to the original obfuscated code. Script block logging will not record output from the executed code. Script block logging events are recorded in EID 4104. Script blocks exceeding the maximum length of an event log message are fragmented into multiple entries. A script is available to parse script block logs and reassemble fragmented blocks (see reference 5).

While not available in PowerShell 4.0, PowerShell 5.0 will automatically log code blocks if the block’s contents match on a list of suspicious commands or scripting techniques, even if script block logging is not enabled. These suspicious blocks are logged at the “warning” level in EID 4104, unless script block logging is explicitly disabled. This feature ensures that some forensic data is logged for known-suspicious activity, even if logging is not enabled, but it is not considered to be a security feature by Microsoft. Enabling script block logging will capture all activity, not just blocks considered suspicious by the PowerShell process. This allows investigators to identify the full scope of attacker activity. The blocks that are not considered suspicious will also be logged to EID 4104, but with “verbose” or “information” levels.

While the blog post does not specify what constitutes 'suspicious', this was a pretty good description of what I was seeing.  This Windows Powershell blog post contains information similar to Matt's post, but doesn't use the term "suspicious", instead stating that "PowerShell automatically logs script blocks when they have content often used by malicious scripts."  So, pretty interesting stuff.


After updating my Python installation with the appropriate dependencies (thinks to Jamie for pointing me to an install binary I needed, as well as some further assistance with the script), I ran the following command:
block-parser.py -a -f blocks.txt Microsoft-Windows-Powershell%4Operational.evtx

That's right...you run the script directly against a .evtx file; hence, the need to ensure that you have the right dependencies in place in your Python installation (most of which can be installed easily using 'pip').  The output file "blocks.txt" contains the decoded script blocks, which turned out to be very revealing.  Rather than looking at long strings of clear and encoded text, broken up across multiple events, I could now point to a single, unified file containing the script blocks that had been run at a particular time, really adding context and clarity to my timeline and helping me build a picture of the attacker activity, providing excellent program execution artifacts.  The decoded script blocks contained some 'normal', non-malicious stuff, but also contained code that performed credential theft, and in one case, privilege escalation code, both of which could be found online, verbatim.

It turns out that "Microsoft-Windows-Powershell/4100" events are also very interesting, particularly when they follow an identified 4104 event, as these events can contain error messages indicating that the Powershell script didn't run properly.  This can be critical in determining such things as process execution (the script executed, but did it do so successfully?), as well as the window of compromise of a system.

Again, all of this work was done across what's now up to half a dozen Windows 10 Professional systems.  Many thanks to Kevin for the nudge in the right direction, and to Jamie for her help with the script.

Additional Reading
Matt's DerbyCon 2016 Presentation

Дата: 2017-02-25 14:12:00

Источник: http://windowsir.blogspot.com/2017/02/powershell-stuff-windows-10.html



Коллизии в SHA-1 портят репозитарии SVN

Недавняя демонстрация коллизий в SHA-1 внезапно потянула за собой ряд крайне практических (и неприятных) последствий.

Дело в том, что популярная система контроля версий Apache SVN использует именно хэши SHA-1 для контроля уникальности файлов. И, как выяснили на себе владельцы репозитария WebKit, заливка двух разных pdf с одинаковыми хэшами приводит к полной неработоспособности репозитария, после чего svn-сервер прекращает принимать коммиты. Пока не вполне понятно, как справиться с проблемой, кроме как откатиться на последний работоспособный бэкап, так что желающим срочно проверить баг лучше держать себя в руках.
обсуждение | Telegram | Facebook | Twitter

Дата: 2017-02-25 12:32:00

Источник: https://bugtraq.ru/rsn/archive/2017/02/07.html



Эксперты осуществили первую успешную атаку поиска коллизий хеш-функций SHA-1

В течение 90 дней Google планирует опубликовать PoC-код для атаки «SHAttered».

Разработанный в 1995 году Агентством национальной безопасности США популярный алгоритм криптографического хеширования SHA-1 окончательно признан небезопасным. Команда исследователей Google и Центра математики и информатики в Амстердаме сообщили об осуществлении первой в мире успешной атаки поиска коллизий хеш-функций SHA-1 .

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

Исследователи предупреждали о небезопасности SHA-1 еще более десяти лет назад, однако алгоритм по-прежнему пользуется большой популярностью. В октябре 2015 года исследователи Центра математики и информатики опубликовали доклад о практическом поиске коллизий хеш-функций SHA-1. Тогда эксперты оценили стоимость осуществления атаки с использованием вычислительной мощности облака Amazon’s EC2 в сумму от $75 тыс. до $120 тыс. Сам процесс занял бы несколько месяцев.

Команда Google совместно с экспертами Центра математики и информатики осуществили эту атаку и опубликовали новый отчет, подробно описывающий весь процесс. Атака, получившая название «SHAttered», обошлась исследователям в $110 тыс.

В качестве примера эксперты продемонстрировали два файла в формате PDF с одинаковым хешем SHA-1 , но с совершенно разным содержимым [PDF1, PDF2]. По словам исследователей, «SHAttered» дает результат в 100 тыс. раз быстрее, чем брутфорс. Как пояснили ученые, атака требует 9 223 372 036 854 775 808 вычислений SHA-1. С использованием одного процессора на это уйдет 6,5 тыс. лет, а с использованием видеокарты – 110 лет.

В течение 90 дней Google планирует опубликовать PoC-код для «SHAttered» .

Дата: 2017-02-25 09:06:36

Источник: http://www.securitylab.ru/news/485401.php



Security Week 08: SHA-1 точно всё, уязвимости в роутерах TP-Link, кроссплатформенный ботнет с кодом Mirai

Британские ученые доказали, что алгоритму криптографического хеширования SHA-1 точно настал конец. Как-то так вышло, что этой истории я кажется посвятил наибольшее количество упоминаний в дайджестах, возможно из-за того, что с криптографией не шутят: она либо работает, либо нет. Напомню, о чем идет речь: в конце 2015 года команда исследователей из университетов Голландии, Сингапура и Франции опубликовала доклад, в котором поделилась новыми идеями оптимизации алгоритма поиска коллизий при использовании SHA-1. По той оценке реальную атаку можно было провести примерно за 49 дней, потратив на облачные вычислительные мощности около 75000 долларов.

Коллизия — это когда два разных объекта имеют один хеш. Если алгоритм SHA-1 используется для идентификации объекта, то появляется возможность «подсунуть» иной объект так, что «по документам» он будет идентичен оригиналу. И речь идет даже не о взломе шифрованной переписки, хотя SHA-1 по-прежнему довольно активно используется в криптографии. «Объекты» могут быть документами, сертификатами для идентификации определенного сервера: подмена в данном случае открывает широкий простор для кибератак.

Но этот простор — теоретический: подтвердить уязвимость на практике стоит дорого. На этой неделе команда исследователей из Google и голландского CWI Institute сообщили, что они, таки да, смогли (новость, минисайт проекта).

Результатом практической атаки на SHA-1 стало создание двух разных документов в формате PDF, у которых полностью совпадает хеш (пруф —
1
,2). Создание документа потребовало огромного объема вычислений — более 9 квинтиллионов операций или 6500 лет процессорного времени (если этот сферический процессор будет трудиться в одиночку, конечно).

Алгоритм поиска коллизий исследователи не раскрывают. Интересно, что в Google решили относиться к этой проблеме, как к любой другой уязвимости: через 90 дней обещают выложить исходный код атаки. Воспользоваться кодом на практике, понятное дело, смогут только очень состоятельные джентльмены. Хотя уже сейчас известно, что примененный метод в 100 тысяч раз быстрее брутфорс-атаки, повторный подход к снаряду обойдется, по мнению диванных аналитиков, в полмиллиона долларов в ценах Амазона. Если потерпеть и использовать только непиковую процессорную мощность, доступную со скидкой, получится около 110 тысяч долларов — в целом похоже на предсказанные полтора года назад $75k.

Реальная атака с использованием коллизий известна в единственном экземпляре: Кибершпионская кампания Flame использовала данный прием для подписи вредоносного файла валидным (на тот момент) сертификатом Microsoft. Точнее, подпись была поддельная, но хеши у поддельной подписи и реальной совпадали. Но в том случае речь шла об алгоритме MD5, который «ломается» за секунды на любом оборудовании (но практическая атака все равно требует немало вычислительной мощности). С SHA-1 все несколько сложнее, но после практической реализации ничего интересного уже не произойдет. В ближайшем будущем обнаружат атаку, которая таки использует SHA-1 как один из многих способов взлома; это ненадолго привлечет внимание СМИ и сообщества. А еще лет через пять настанут трудовые будни админов, оставшихся один на один с устаревшей инфраструктурой, которую и выкинуть жалко, и использовать опасно, и заменить не на что.

Google на странице проекта не забывает напомнить, что браузер Chrome помечает соединения с использованием SHA-1 как небезопасные. Это, конечно, здорово, но проблемы если и возникнут, то скорее всего не в браузере.

Ждем ебилдов патчей для серьезных уязвимостей в роутерах TP-Link
Новость. Подробности в гитхабе исследователя.

Исследователь из Кот-д'Ивуара (!) Пьер Ким сообщил о множественных уязвимостях в роутерах TP-Link C2 и C20i (продаются в том числе и у нас), среди них — серьезная дыра в веб-интерфейсе, позволяющая выполнить на роутере произвольный код. Эксплуатируется уязвимость RCE достаточно просто: нужно залогиниться в веб-интерфейс, зайти на страницу диагностики и выполнить там любую команду, в том числе можно, например, запустить telnetd. Управлять роутером через telnet в дальнейшем можно вообще без авторизации.

Как обычно, в этой истории интереснее не уязвимости (они не так чтобы ужасные — все же требуется логин для веб-интерфейса, но это преодолимо), а процесс починки вендором. К чести TP-Link, патч для уязвимостей вот-вот должен выйти. Но изначально исследователю сообщили в техподдержке, что контакта для информации о дырах в софте у них просто нет. Весь процесс, от обнаружения до (надеемся) патча занял у исследователя полгода.

Исследователи «Лаборатории» обнаружили Windows-ботнет, атакующий IoT-устройства кодом Mirai
Новость. Исследование.

Ну как обнаружили. Ботнет, организованный кем-то, говорящим на китайском, существует уже довольно давно, но относительно недавно он начал использовать печально известный код атаки Mirai на уязвимые Linux-устройства. При этом сам ботнет построен из зараженных Windows-систем. В исследовании экспертов «Лаборатории» приводятся живописные примеры сбора вредоносной кампании, что называется, с миру по нитке. Атакующие слепили ботнет из того, что было: используются методы атаки на серверы MS SQL, вредоносный код подписывается украденными у ряда китайских компаний сертификатами, на пораженные системы внедряются кейлоггеры, все это построено чуть ли не на батниках.

В общем это такой антипод опасных, но красивых, черт возьми, атак, который доказывает, что техника взлома чужих систем не обязана быть совершенной, чтобы быть эффективной. И так сойдет. Стать жертвой угрозы из говна и палок такого типа наверное вдвойне обидно. Mirai подключили к общему делу, видимо, по тем же принципам: прицепили где-то сбоку телнет-клиент и скрипты для массовой (или по спискам IP с командного сервера) бомбежки Linux-систем с прорехами в безопасности. Вишенка на тортике: вредоносный код прячется в хранящиеся на командном сервере картинки.

Древности


«Adolf-475»

Резидентный опасный вирус, стандартно записывается в COM- и OVL-файлы при их загрузке в память. Свою резидентную копию помещает в таблицу векторов прерываний по адресу 0000:0020. Содержит текст: «Adolf Hitler». С вероятностью 1/8 блокирует удаление файлов. Перехватывает int 21h.

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 58.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Дата: 2017-02-24 17:39:39

Источник: https://habrahabr.ru/post/322536/



Проблема в Java и Python позволяет обойти сетевой экран

FTP-инъекции при использовании Java и Python, возможные из-за уязвимости этих сред к XEE-атакам (XML External Entity), могут поставить под удар защищенные экраном системы.

Подробности этих багов были преданы гласности несколько дней назад, а ИБ-службы Python и Oracle были о них уведомлены в январе и ноябре, соответственно. Ни тот, ни другой вендор уязвимость еще не пропатчили, хотя команда Python подтвердила наличие бага, а Oracle заявила, что работает над решением проблемы. Очередной выпуск патчей от Oracle запланирован на 18 апреля.

Немецкий исследователь Александр Клинк (Alexander Klink) обнаружил в коде Java-обработчика FTP URL уязвимость, позволяющую внедрять команды в поток данных клиента. Этот баг можно использовать в комбинации с существующей возможностью XXE (использования внешних сущностей для записи спецсимволов в XML-документах) или SSRF (подмены запросов на стороне сервера) для несанкционированной отправки писем из Java-приложения по протоколу SMTP.

Исследователь Тимоти Морган (Timothy Morgan) дополнил находку Клинка: он обнаружил, что XXE можно использовать, чтобы заставить файрвол разрешить удаленное TCP-соединение с уязвимой системой. «В том случае, когда база данных развернута на сервере приложений, один XXE-баг может обеспечить вам идентификаторы для доступа к этой базе данных, а затем и прямой доступ к этой службе, что приведет к полной компрометации приложения», – пояснил Морган для Threatpost.

«Если база данных размещена на другой хост-системе, подобная атака невозможна, однако на серверах приложений зачастую работают другие жизненно важные объекты, к примеру, кэши Redis, кэши memcached, очереди RabbitMQ, административные интерфейсы Tomcat и т.п., – рассказывает Морган. – При определенных условиях раскрытие этих сервисов при наличии XXE составит серьезную угрозу целостности прикладной программы».

Клинк, в свою очередь, пишет в блоге, что обнаружил, как заставить клиент Java открыть FTP-соединение и воспользоваться отсутствием адекватной проверки входных данных, в частности, полей имени пользователя и пароля в URL. Спецификации FTP допускают использование любых ASCII-символов в имени пользователя, кроме CR и LF. Как оказалось, обработчик FTP URL в Java проверку наличия CR и LF не производит, поэтому Клинку удалось остановить выполнение команды USER (или PASS) и внедрить новую команду в FTP-сессию. Поскольку протоколы FTP и SMTP схожи, исследователь смог посылать произвольные команды на почтовый сервер.

«Таким образом, если послать команду USER на почтовый сервер вместо FTP-сервера, он вернет ошибку (поскольку USER как команда недопустима в SMTP), однако продолжим нашу сессию, – пишет Клинк. – В комбинации с багом, упомянутым выше, это позволяет посылать произвольные SMTP-команды с целью отправки писем».

Морган, со своей стороны, обнаружил возможность более опасного сценария, при котором FTP-инъекция позволяет обмануть файрвол жертвы и заставить его разрешить TCP-соединение с хост-системой из интернета на каком-либо из портов с 1024 по 65535. По словам исследователя, аналогичная уязвимость присутствует также в Python-библиотеках urllib2 и urllib.

«Оценить риски в данном случае сложно, так как существует много разных способов использования этого бага, – комментирует Морган. – Ни один из них не имеет широкий охват, однако совокупное число жертв может оказаться большим. Важно, чтобы те, кто находится в группе риска, хорошо понимали степень угрозы для их сетей и приложений. Эти атаки делают ставку на совместное действие разных технических трюков с использованием XXE/SSRF. Каждый из этих приемов сам по себе не влечет серьезные последствия, однако в совокупности они способны наделать много бед».

В своей блог-записи Морган рассматривает ряд сценариев атаки, позволяющей обойти настройки сетевого экрана и добраться до размещенных за ним систем. Его PoC-эксплойт тоже использует отсутствие проверки синтаксиса (фильтрации CR и LF) и позволяет отправить на сервер вредоносную команду – к примеру, заставив Java-клиент выполнить парсинг файла JNLP, содержащего вредоносный FTP URL. По словам Моргана, такая атак возможна, если пользователя десктопа с плагином Java удастся заманить на вредоносный сайт, причем этот плагин у жертвы не обязательно должен быть включен.

«Атака Java Web Start, скорее всего, вероятна для большого числа пользователей настольных компьютеров, – полагает собеседник Threatpost. – Согласно этому сценарию, пользователя нужно заманить на веб-страницу, принудительно загружающую файл .jnlp (некоторые браузеры могут скупо предупредить о начале атаки Java Web Start, однако это зависит от типа браузера, а я не все их протестировал). При запуске Java Web Start сразу начинается обмен, открывающий TCP-порты на десктопе пользователя (без дополнительного предупреждения защиты). Имеются ли на TCP-портах 1024-65535 вашего десктопа какие-либо службы, злонамеренный доступ к которым нежелателен? Риск в данном случае может быть различным в зависимости от используемой ОС и уровня патчинга».

В блоге Морган рассматривает и другие атаки, использующие XXE, SSRF, а также атаки MitM; все они позволяют внедрить код в поток данных.

Залатать данную брешь, по мнению эксперта, не так уж трудно. «Судя по тому, что я вычитал в спецификациях FTP, невозможно создать имя файла или директории, включающее буквенные символы новой строки (хотя в файловых системах UNIX их использование разрешено), – заключает Морган. – Поэтому есть смысл их попросту отвергать. То есть после того, как Python или Java расшифруют FTP URL, им следует выполнить простую проверку, чтобы удостовериться в отсутствии неподдерживаемых символов (\r\n\0 и проч.), и выдавать исключение, если они найдены».

Дата: 2017-02-24 16:38:27

Источник: https://threatpost.ru/java-python-ftp-injection-attacks-bypass-firewalls/20707/



Onion Peeler: Batch Tor Lookup Program

Logs, Logs, Logs. I see, IPs. When reviewing log files for suspect activity it can be helpful to look up information related to IP addresses. There is a great utility for this by Nirsoft called IPNetinfo. You can import a whole list of IP addresses and it will give you "the owner of the IP address, the country/state name, IP addresses range, contact information (address, phone, fax, and email), and more."

When I am reviewing log files, an IP address associated with a foreign country may peak my interest. Another check I like to do is look for activity associated with Tor nodes. In a corporate environment, a user accessing a system from a Tor exit node may be a red flag.

When I am checking an IP address to see if it is associated with a Tor exit node I will use a website like ExoneraTor. It lets me put in an IP address and a date, and lets me know if the IP address is associate with a Tor relay. While this is a great tool, if I have a list of IP addresses to check, it's not very efficient. To that end, I wrote a little program to help automate the process of checking a list of IP addresses against Tor Relays and Bridges, Onion Peeler.

Onion Peeler is written in Python and uses OnionPy. OnionPy is a wrapper for the OnionOO Tor Api. Using OnionPy, Onion Peeler caches a local copy of the Tor exit nodes and performs a check for a list of supplied IP addresses. What's nice is that if you have a list of sensitive IPs, the information is not shared and is kept locally:


It will output a list of matches:




Since it's in Python, the program is cross-platform compatible. I've tested it on Windows, Linux and Mac. It just requires OnionPy, which can be installed using "pip install OnionPy". I also have a compiled Windows Executable if you don't have Python installed. It requires an Internet connection as the initial query grabs the latest Tor nodes from OnionOO. I am thinking about adding in a way to store an offline copy in the next version as well as add in additional details about the Tor nodes (first seen, last seen etc.)

It took about a minute to check 8,000 IP addresses. Of course, a bigger list will take longer, so be patient.

Code and program are available on my github.

Дата: 2017-02-24 15:20:50

Источник: http://az4n6.blogspot.com/2017/02/onion-peeler-batch-tor-lookup-program.html



Уязвимость Cloudflare подставила пользователей множества сайтов

Популярный CDN-провайдер Cloudflare, услугами которого пользовались многие сайты в целях снижения нагрузки и противодействия DDoS-атакам, почти полгода внедрял случайные фрагменты оперативной памяти своих серверов в содержимое веб-страниц, отдаваемых пользователям. При определенном усердии в течение этого времени можно было накапливать отдаваемую информацию в поисках критичной информации - в первую очередь сессионных ключей, паролей, номеров кредиток и прочих данных, передаваемых как по http, так и по https (последнее особенно неприятно).

Уязвимость уже закрыта, но список потенциальных пострадавших насчитывает более 4 миллионов сайтов, включая authy.com, uber.com, medium.com, thepiratebay.org, pastebin.com. Собственно говоря, часть данных до сих пор может просто лежать в кэшах поисковиков. В сообщении Clodflare говорится, что уже обнаружено...»»
обсуждение | Telegram | Facebook | Twitter

Дата: 2017-02-24 15:17:00

Источник: https://bugtraq.ru/rsn/archive/2017/02/06.html



CloudFlare рассказала о крупной утечке данных с сайтов-клиентов

Представители компании-разработчика сервисов распределённого хранения контента Cloudflare рассказали об обнаруженной уязвимости, которая могла стать причиной утечки личных данных пользователей сайтов её клиентов.

Скомпрометированные данные могут включать пароли, куки-файлы, аутентификационные токены в незашифрованном виде. Об этом представители компании сообщили в своём блоге.

Как отмечает Techcrunch, системой от Cloudflare пользуются более пяти миллионов сайтов. Злоумышленник, заметивший брешь, мог собирать личные данные посетителей сайтов, которые обычно должны храниться в зашифрованном виде. Кроме того, часть информации успела попасть в кэш поисковых систем, поэтому представители Cloudflare обратились к Googleinfo-icon, Bing, Yahooinfo-icon и другим компаниям, чтобы вручную устранить последствия вероятной утечки, пишет vc.ru.

Баг содержался в старом коде компании, но проблема утечки памяти проявилась 22 сентября 2016 года, когда CloudFlareinfo-icon внедрила новый HTML-парсер, после чего системы компании стали интегрировать случайные фрагменты оперативной памяти своего сервера в содержимое веб-страниц, которые отправляются клиентам. 

Спустя пять месяцев специалист по безопасности Google Project Zero обнаружил баг и сообщил представителям Cloudflare. Наиболее серьёзная утечка могла произойти между 13 февраля и 18 февраля, когда примерно один из каждых 3,3 млн HTTP-запросов к сайтам-клиентам Cloudflare подвергал данные вскрытию.

Злоумышленники могли иметь доступ к данным в реальном времени или через кэш поисковых систем. В своём заявлении представители Cloudflare отметили, что даже на пике информация утекала только из 0,00003% всех запросов. В комментариях на Hacker News технический директор компании Джон Грэхем-Камминг отметил, что команда обнаружила утечку данных как минимум с 3438 уникальных доменов клиентов компании. Один из пользователей Github опубликовал список доменов, которые могли попасть под уязвимость, утверждая, что их общее число превышает 4 миллиона — включая 2ip.ru, 4pda.ru, avito.ru, rghost.ru, forbes.ru и rosbalt.ru.

Это не выглядит масштабной утечкой, отмечает Techcrunch, однако среди клиентов Cloudflare есть дейтинговые сайты и менеджеры паролей, которые хранят по-настоящему чувствительную информацию.

Баг появился в HTML-парсере, который Cloudflare использовал, чтобы ускорить быстродействие сайта — он подготавливает сайт для работы с платформой AMP от Google и превращает HTTP-ссылки в HTTPS. 

Системы самой Cloudflare также подверглись ошибке — «один из утёкших фрагментов информации был приватным ключом, который используется для связи между машинами Cloudflare», — написал Грэхем-Камминг. Ключ позволял компьютерам компании безопасно общаться друг с другом и был внедрён в 2013 году на фоне опасений о государственной слежке.

Грэхем-Камминг подчёркивает, что Cloudflare не обнаружила подтверждений тому, что хакеры успели обнаружить или использовать баг, отметив, что сотрудники заметили бы подозрительную активность в своей сети.

Команды Cloudflare в Сан-Франциско и Лондоне смогли избавиться от самой серьёзной проблемы за семь часов. Полное восстановление и избавление от бага заняло шесть дней, включая работу с поисковыми системами, которая позволила извлечь часть утекшей информации. 

Сотрудник Google Тавис Орманди, первым заметивший баг, рассказал, что наткнулся на неожиданную информацию в ходе работы над своим проектом и сперва подумал, что обнаружил баг в собственном коде. После ряда тестов он понял, что утечка происходит из систем Cloudflare — Орманди наблюдал чужие ключи шифрования, куки, пароли и HTTPS-запросы, личные сообщения с крупных сайтов знакомств, кадры из веб-чатов, данные бронирования гостиниц и кредитных карт.

Позже специалист удалил полученные образцы, но опубликовал отредактированные скриншоты с частью информации, которая просочилась с сайтов 1Password, Uber, Fitbit и OkCupid. Он также отметил, что, несмотря на заявления Cloudflare, сотрудники компании недооценивают опасность для клиентов, поскольку утёкшая информация могла осесть не только в кэше поисковых систем, но и в других местах.

Дата: 2017-02-24 14:25:05

Источник: https://www.anti-malware.ru/news/2017-02-24/22359



SPARTA - Network Infrastructure Penetration Testing Tool


SPARTA is a python GUI application which simplifies network infrastructure penetration testing by aiding the penetration tester in the scanning and enumeration phase. It allows the tester to save time by having point-and-click access to his toolkit and by displaying all tool output in a convenient way. If little time is spent setting up commands and tools, more time can be spent focusing on analysing results. Despite the automation capabilities, the commands and tools used are fully customisable as each tester has his own methods, habits and preferences.

Requirements
It is recommended that Kali Linux is used as it already has most tools installed, however SPARTA would most likely also work in Debian based systems.
Kali (preferred):
apt-get install python-elixir
Ubuntu 12.04+ (untested)
apt-get install python-elixir python-qt4 xsltproc
Other than these, the following tools are required for SPARTA to have its minimum functionality:
In Kali Linux these can be installed with:
apt-get install nmap hydra cutycapt
In Kali, to ensure that you have all the tools used by SPARTA's default configuration use:
apt-get install ldap-utils rwho rsh-client x11-apps finger

Installation
cd /usr/share/
git clone https://github.com/secforce/sparta.git

Place the "sparta" file in /usr/bin/ and make it executable.
Type 'sparta' in any terminal to launch the application.

Source code
The source code is structured in folders as such:

Demos

Known issues
SPARTA uses a third-party tool called Cutycapt to take screenshots. One of the problems with the version that is currently in Kali's repositories is that it fails to take screenshots of HTTPS pages when self-signed certificates are in use. A way around this is to compile the Cutycapt executable yourself and edit SPARTA's configuration file to specify the path to the compiled executable.
It can be compiled in Kali by following these instructions:
% sudo apt-get install subversion libqt4-webkit libqt4-dev g++
% svn co svn://svn.code.sf.net/p/cutycapt/code/ cutycapt
% cd cutycapt/CutyCapt
% qmake
% make
% ./CutyCapt --url=http://www.example.org --out=example.png

Дата: 2017-02-24 14:08:10

Источник: http://www.kitploit.com/2017/02/sparta-network-infrastructure.html