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.

Advertisements
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 , ,

Acunetix Web Vulnerability Scanner 8 beta-testing

Acunetix developers provide possibility to take a part in Acunetix WVS 8 beta-testing program.

For taking a part in program you must send a mail to beta@acunetix.com and after that confirm that you are into web security.

Thanks to Acunetix’s developers team for provided possibility – guys, you make a real usefull and good quality software!

Links:

http://t.co/IsAVa1UH

http://twitter.com/c3retc3

Tagged , , , ,

PHD CTF 2012 prequals results

PHDays CTF prequals had finished yesterday.

Results are expected – first place won rdot.org team (gratz guys!). Teams from NL, SP, FR also at TOP 5.

The CTF was very hot for participants and I hope that we could see all winners on PHD 2012.

Also:

http://sgordey.blogspot.com/2011/12/phd-ctf-quals_11.html

http://phdays.ru/ctf_quals_rating.asp

http://devteev.blogspot.com/2011/12/phdays-ctf-quals-2011-competitions.html

Tagged , ,

Zerodays

О конференции zeronights:

– далеко;

– не было столпотворения;

– достаточно мест, чтобы присесть;

– доклады разной направленности;

  • сильные доклады по телекомам;
  • слабые доклады по банкам.

– доклады неудачно разбросаны по времени;

– еда/вода;

– большой, приличный зал;

– доступность community;

rdot.org молодцы (как всегда);

– говорят, задание от doznpp было неплохим;

– desTiny уделал крякмисы, как всегда;

– несколько симпатичных девушек из dsec;

– не осталось ничего, что мыслительно ассоциировалось бы с zeronights кроме синего цвета;

– 0-days;

– слабая подача организационных моментов;

– рекламы почти не было.

 

P. S. Где взять доклад с мероприятия по responce splitting’у?

UPDATE: off video http://www.youtube.com/watch?v=bW6ke62HB6E

not off video :) http://www.youtube.com/watch?v=_Qlxx-xKknY&feature=related