Category Archives: vulnerabilities

Remote Banking Services – BS-Client ver 3.* SQL code injection vulnerability

SQL injection vulnerability exists in BS-Client ver. 3.* (server component) . Vulnerability arises if someone, who has enough permissions to edit or add new roles of users, is trying to remove role with specially created role’s name. It can be used, e.g., to perform user’s privileges escalation.

Сheat trading software (Clever bots vs. Speculators)

Интересная ситуация сложилась с Уралкалием.

Интересная ситуация с ОАО Уралкалий

Эдак неделю назад, после того, как руководство компании объявило о разрыве коммерческих отношений с белорусскими партнерами Беларуськалий и “Белорусская калийная компания“, акции компании просели на ~25% процентов. Чем не преминул воспользовать один мой знакомый для осуществления удачной покупки, так как серьезных альтернатив компании на рынке (СНГ) калийных удобрений нет. Но я не о стратегии торговли, а о ее механике. А она представляет собой следующее.

В настоящее время спред в ценах спроса и предложения на сентябрьские поставочные фьючерсы (UKU3) составляет порядка 150 руб. Торговля по данному деривативу идет крайне неактивно (вероятно потому, что акции не отскочили к настоящему моменту даже половины падения и все ждут своей прибыли). При этом, моим знакомым опытным путем было установлено, что висят на торгах этим фьючерсом, в основном, боты. И здесь начинается главное, а именно: возможность поспекулировать на логике их работы. Рассмотрим ситуацию:

Имеется:
цена спроса на фьючерс – 15 750
цена предложения на фьючерс – 15 910

Если выставить заявку на продажу контракта по цене, например, 15 890 один из ботов автоматически устанавливает заявку на 2 минимальных шага цены (в данном случае 2 руб.) ниже той, которая была установлена. Такое снижение повторяется ботом от 7 до 10 раз, а затем бот решает, что ему достаточно и выходит из игры. Но самое интересное начинается далее: цена спроса при этом также уменьшается – предположим, на 15 руб. меньше и составляет 15 740 руб. А вот теперь, если установить заявку (после того, как бот решил. что с него хватит и прекратил аукцион :)) хотя бы на рубль меньше цены, которую бот определил как свой лимит, и сразу ее снять, то цена спроса (вслед за снятой заявкой на продажу и отскочившей ценой предложения (не до последней цены, как следовало бы ожидать, а выше!)) как растянутая резинка отстреливает в обратном направлении не на 10 руб. (возвращаясь к 15 750), а на целых 30-40 единиц. Таким образом, снижая цену и заставляя бота выйти из игры, можно спекулировать ценой предложения и спроса (конечно, в пределах определенного интервала, которого, тем не менее, вполне достаточно для того, чтобы с этого что-то получить). Та же логика работает и в отношении повышения цены спроса. Так что, как показывает практика, лодку раскачивать таки надо :)
Вот таким вот образом сегодня можно было диктовать свои условия участникам торгов фьючерсами Уралкалия и зарабатывать на этой спекуляции.

Причины: крайне неактивная торговля и низкие объемы торгов позволяют определять стратегию поведения ботов, а, главное, пользоваться её изъянами.
Выводы:

  1. не пользуйтесь своими ботами в своих целях, пользуйтесь чужими ботами для своих целей ;-) Конечно, серьезные деньги так не делаются, но получить дополнительную надбавку при продаже/покупке вполне реально. А, как известно, деньги деньгами зарабатываются;
  2. сегодняшний рост контракта на рынке составил 3,71% (в лидерах роста сегодняшнего дня). Учитывая предыдущий рост, ценная бумага не отыграла даже половины падения, а ближайший уровень сопротивления ожидается ~ 18 450 руб. (при текущей цене 16 367) мой знакомый рекомендует покупать сразу после ближайшего локального отскока.

Котировки Уралкалия здесь.

P.S. Кстати, ещё один знакомый в ближайшее время найдет информацию по локальному переполнению буфера в самой популярной отечественной торговой системе QUIK, а я добавлю ее сюда.

Tagged , , ,

Reflected XSS at LockHeed Martin site

According to the annual tradition I publish a little bit information about LockHeed Martin site security :) It’s just an XSS as the result of several additional web security problems.

XSS exists when you send POST request with an empty body request due to improper Java exception handling (javax.jcr.AccessDeniedException) and incorrect handling of HTTP request methods (HTTP Verb Tampering). For exploitation of the vulnerability you must to spoof the Referer header.

lockheed

Info:

HTTP verb tampering

XSS in Referer header

RomPager 4.07 cross-site scripting vulnerability

During testing IPs that were sources of attacks on php-cgi vulnerability discovered by eindbazen (CVE-2012-1823) accidentally found XSS in Referer header in RomPager/4.07 embedded web server.

GET http://IP.IP.IP.IP/s0urc3_that_not_exists HTTP/1.1

..

Referer: http://dtls.com/”><script>alert(document.cookie)</script&gt;

Tagged , ,

HTTP Headers Pollution (server output pollution)

After reading http://www.acunetix.com/blog/whitepaper-http-parameter-pollution/ I’ve tried to check that one for HTTP headers. So, with Apache/2.2.15 (CentOS) and PHP 5.3.6 I’ve received next result:
Image
So, we can watch the difference between http parameter pollution and http headers pollution for Apache/PHP. In case of HPP with combo PHP/Apache appears only last occurrence of user input in request, and in HHP there is another situation, in which we ca see input concatenation with comma sign. This fact can be very usefull for filters bypassing in some cases.

UPDATE: It can be used for application flow manipulation (not only). For example in cases, in which length of each headers (as element of headers array) checks separately for each header, but subsequently final header used in a way presented on the image above. I didn’t look source codes of Apache closely, but possibly it may be usefull for bypassing latest patch for CVE2012-0053 vulnerability, in which length of value of cookie header (each? final?) must to be less than 80 chars.

P.S. Probably, the reason is depended of the web-server version, but may be this is the same thing exists in older versions.

Tagged , , ,

Краткое описание DTLS протокола

В настоящее время очень трудно найти хотя бы общую информацию о протоколе DTLS (а ему уже 5 лет) – даже гугл при вводе dtls предлагает искать tls.

Общие сведения (много RFC):

Протокол DTLS описан в RFC 4347.

Для DTLS отсутствует чётко зафиксированное значение порта сервера – в реализации OpenSSL, начиная с версии 0.9.8b используется порт 4433. Также, DTLS поддерживается и в других, отличных от OpenSSL реализациях протокола SSL/TLS – например, в CyaSSL.

DTLS – сетевой протокол, предназначенный для безопасной передачи данных с использованием UDP протокола. Возник в связи с необходимостью обеспечения становящихся всё более популярными медиа-протоколов, протоколов IP-телефонии и т.п.
Протокол построен (как следует из названия) по аналогии с протоколом TLS (1.1). Для решения проблем потери пакетов использует механизм ретрансляции пакетов с использованием таймера.
Для решения проблемы ограничения длины UDP пакетов активно используется фрагментация данных. В реализации протокола предусмотрена (опциональная) возможность обнаружения повторной отсылки пакетов (replay) – фильтрация пакетов происходит путём анализа временных фреймов для поступающих пакетов. Также отбрасываются пакеты, идентичные уже поступавшим. Общей защитой от replay-атак является применение номера последовательности (sequence number) и проверки кода “идентичности” сообщения (MAC – message authentication code).

Формат DTLS записи:

struct {
ContentType type;
ProtocolVersion version;
uint16 epoch;                                    // отсутствует в TLS
uint48 sequence_number;                          // отсутствует в TLS
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;

DTLS protocol traffic example

Описание каждого поля можно найти в разделе 4.1 RFC4347.

Установление соединения происходит с использованием рукопожатия (handshake) по алгоритму, аналогичному используемому в TLS. Однако, существуют и отличия:

1) Для противодействия атакам класса отказ в обслуживании используется механизм обмена сообщениями о состоянии сеанса (stateless cookie);
2) Внесены изменения в механизм реализации рукопожатия для предоставления возможности обработки ситуации потери сообщений, изменения порядка рукопожатия и фрагментации сообщений.
3) Как было сказано ранее – также используется механизм таймеров повторной отсылки сообщений для обработки ситуации потери пакетов.

Наиболее распространёнными атаками на протокол датаграмм являются:
1) отсылка множественных сообщений, содержащих запросы на инициализацию процесса рукопожатия (нагрузка возникает за счёт ресурсоёмкости криптографических операций на последних стадиях рукопожатия – согласование алгоритмов шифрования, обмен ключами и т.п.). К этой категории относятся, например, популярные уязвимости в OpenSSL, связанные с возможностью инициализации клиентом переустановления соединения и повторного согласования вышеуказанных операций (Session Renegotiation Attack на протокол SSL/TLS, например, CVE-2009-3555, CVE-2011-1473);
2) рассылка множественных запросов с подмененным (указывается адрес атакуемого сервера) адресом источника сообщения на установление соединения. В ответ серверы, на которые были отосланы запросы, будут отвечать на атакуемый сервер ресурсоёмкими (как для самого сервера, так и для атакемого сервера) сообщениями Server Hello/Certificate Message. Данная атака представляется как сложнее реализуемая в силу малой популярности DTLS протокола.

Для противодействия DoS атакам в DTLS используется вышеуказанный (и хорошо описанный в RFC4347) механизм stateless cookie, также используемый, например, в протоколе IKE.
Так, при отсылке клиентом ClientHello запроса сервер может (но не обязан!) ответить HelloVerifyRequest сообщением. Последнее сообщение может содержать поле stateless cookie, в случае наличия которого клиент будет обязан переслать ClientHello запрос с добавленным полем cookie.

DTLS Handshake with cookiesДанный алгоритм обмена cookies обеспечивает защиту от атак с использованем запросов с подменой адреса источника (описанный выше тип 2 DoS-атаки). Структуру записей в запросах ClientHello и HelloVerifyRequest можно найти в RFC.

Для обхода данного механизма предотвращения атак злоумышленник может осуществить сбор cookies с различных адресов и, затем использовать их в процессе проведения атаки.
Для предотвращения подобных экспромтов на сервере должно быть задано небольшое время истечения действия cookies. Это сделает процесс обмена более ресурсоёмким как для сервера, так и для клиента, но и более безопасным.

Хотелось бы, конечно, описать еще множество интересных вещей, таких как описание механизмов формирования cookies, MAC-сообщений, фрагментации сообщений, запросов на изменение используемых алгоритмов шифрования, структуры различных сообщений, но, полагаю, в случае острой нехватки строго технического описания и наличия свободного времени более полезным мог бы быть уже не один раз упомянутый RFC 4347.

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

Доп. информация:

Поддержка DTLS реализована в Cisco AnyConnect VPN/WebVPN Cisco ASA. Support for DTLS first arrived in ASA release 8.0(2) some three years ago; however for the IOS this has just recently been added in IOS® 15.1(2)T ([4]). Актуальные поддерживаемые версии можно найти на cisco.com.

 

Настройка DTLS сервера в Cisco ASA:

asa2(config-webvpn)# enable outisde
INFO: WebVPN and DTLS are enabled on ‘outisde’.

asa2(config-webvpn)# dtls port ?

webvpn mode commands/options:
  <1-65535>  The DTLS server’s listening port. UDP port 443 is the default.

asa2(config-group-webvpn)# svc dtls ?

config-group-webvpn mode commands/options:
  enable  Enable DTLS for SVC
  none    Disable DTLS for SVC

Настройка DTLS для группы (интерфейс inside):

hostname(config)# enable inside

hostname(config)# group-police sales attributes

hostname(config)# webvpn

hostname(config-group-webvpn)# svc dtls enable

 

Примеры уязвимостей в DTLS:

OpenSSL DTLS DoS (SA35128)

OpenSSL plain-text disclosure possibility (CVE-2011-4108)

OpenSSL DTLS DoS atack (CVE-2012-0050)


Ссылки:

1) RFC 4347

2) The Design and Implementation of Datagram TLS (очень детальное описание)

3) Уязвимости SSL/TLS: CVE-2009-3555 (1), CVE-2009-3555 (2), CVE-2011-1473

4) DTLS ‘n’ Cisco WebVPN

Tagged , , , , , , , , , ,

JBoss 3.2.8.GA information disclosure vulnerability (NonManagedConnectionFactory.java)

One more example of bad logging function realisation in JBoss (value of variable pwd is placed in logfiles as a plaintext when SQLException appears):

088 public Connection getConnection()
089 {
......
099 catch (SQLException e)
100 {
101 reportAndRethrowError("Failed to get connection for url=" + url + ", user=" + usr + ", password=" + pwd, e);

where
pwd = config.getJdbcPassword();

Source: NonManagedConnectionFactory.java

Tagged , ,