Не все cookie одинаково полезны07.12.2015 20:48

В этой статье я хотел бы рассказать о том, как можно объединить небольшие недочеты в обработке cookie-значений в цепочку, и произвести за счет этого атаку на пользователей популярных веб-приложений.

История началась больше года назад, когда я испытывал программу DOMinator для поиска DOM-Based XSS на сайтах Bug Bounty программ. Одним из первых предупреждений, которое я получил, была уязвимость Cookie Injection в JavaScript сценарии Google Analytics.

При обращении к сайту с Google Analytics, сценарий обрабатывает значение HTTP заголовка Referer и извлекает из него host и путь к сценарию, для отслеживания откуда пришел пользователь. В дальнейшем эти данные попадают в cookie параметр __utmz.

Выглядит это следующим образом:
__utmz=123.123.11.2.utmcsr=[HOST]|utmccn=(referral)|utmcmd=referral|utmcct=[PATH]

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

http://blackfan.ru/x/injection;injection=injection?r=http://site.com/

Результат:
document.cookie=__utmz=blah...|utmcct=/x/injection;injection=injection; path=/; domain=.site.com

На данный момент это было сложно назвать уязвимостью, но тем не менее поведение сценария довольно интересное, к тому же он невероятно распространен.

Bug Bounty и Cookie

Небольшое отступление. Уязвимости, связанные с cookie, в рамках программ вознаграждения за уязвимости, примечательны тем, что у вас может получится два основных сценария:

Найдена возможность перезаписи и создания произвольных cookie параметров.
Ответ: Это всего лишь cookie, что это тебе даст?
Найдена XSS через cookie параметр.
Ответ: Ты ведь не можешь создать произвольный cookie параметр, значит, это не уязвимость!

И только если оба варианта оказались в рамках одной Bug Bounty программы, то вам, так уж и быть, заплатят.

Необходимость каждый раз доказывать угрозу от проблем, связанных с сookie, зачастую отталкивает людей от их поиска. Так как за потраченное на это время можно найти еще десяток уязвимостей, которые будут приняты без вопросов. В основном проверяются только самые базовые вещи, типа фиксации сессии и правильности установленных атрибутов secure, httpOnly…

Cookie

Взглянем на структуру сookie заголовков:

Set-Cookie: par=val; path=/; httpOnly; secure;
Cookie: par=val; par2="val2"; par3=val3;

Структура довольно сложная и с ней работают при каждом запросе браузер, JavaScript сценарии и веб-сервер. Каждый при этом обрабатывает по-своему, и одна и та же строка может дать разные результаты.

Анализируя обработку cookie необходимо задаться следующими вопросами:

Нужны ли пробелы после;
Какие символы можно использовать вместо ;
Какое значение будет результирующее в случае одинаковых ключей
Важен ли регистр у ключей
Сколько может быть атрибутов у параметра
Какое значение будет результирующее в случае одинаковых атрибутов
Как правильно кодировать спецсимволы

Особенности обработки Cookie

Первая и наиболее известная особенность — Safari позволяет объявлять несколько параметров через один заголовок Set-Cookie.

Set-Cookie: param1=value1; path=/, param2=value2; httpOnly;

Возвращаясь к проблеме Google Analytics, проверим данную особенность в установке cookie через JavaScript. Получаем первый вариант эксплуатации:

http://blackfan.ru/x/injection;,injection_cookie=injection;?r=http://site.com/

Результат
document.cookie=__utmz=blah...|utmcct=/r/injection;,injection_cookie=injection; path=/; domain=.site.com

Safari создаст два cookie параметра __utmz и injection_cookie.

То есть, для пользователя Safari на любом сайте с Google Analytics можно создать произвольный cookie параметр. Осталось только придумать зачем…

CSRF

Защиту от CSRF можно условно разделить на 3 типа:

Различные токены для каждого действия. Хранятся на сервере.
Один сессионный токен на все действия. Хранится на сервере в сессии пользователя.
Один сессионный токен на все действия. Хранится в cookie параметре.

Третий вариант основывается на том, что значение токена в cookie пользователя недоступно для злоумышленника. Для прохождения проверки достаточно просто послать одинаковое значение токена в cookie и post параметрах. То есть, простая перезапись значения через Google Analytics тут подойдет идеально.

Особенности обработки Cookie #2

Что если развернуть атаку на 180 градусов? Не обязательно, чтобы в браузере действительно был cookie параметр с CSRF токеном, значение которого мы знаем. Достаточно, чтобы так считал веб-сервер.

В этом поможет еще одна обнаруженная особенность обработки сookie.

RFC2109
Note: For backward compatibility, the separator in the Cookie header
is semi-colon (;) everywhere. A server should also accept comma (,)
as the separator between cookie-values for future compatibility.

Многие веб-серверы поддерживают перечисление сookie не только через точку с запятой, но и через запятую.

Cookie: par=val; par2="val2"; par3=val3;
Cookie: par=val, par2="val2", par3=val3,

Более того, в некоторых случаях пробел не обязателен.

Cookie: par=val;par2="val2";par3=val3;
Cookie: par=val,par2="val2",par3=val3,

В свою очередь, для большинства браузеров такие символы как пробел и запятая являются вполне нормальными. И если установить:

Set-Cookie: par=val, csrftoken=val2;
document.cookie="par=val, csrftoken=val2;";

Для браузера это будет одно значение, но для некоторых серверных реализаций — два сookie параметра. Однако, в случае эксплуатации данных особенностей для обхода CSRF защиты, необходимо помнить, что мы не перезаписываем старый токен, а добавляем еще один, то есть важен порядок обработки сookie.

Cookie: csrftoken=realvalue; par=val, csrftoken=fakevalue;

Итого получается уже две цепочки эксплуатации уязвимости:

Safari -> WebApp (GA & Double Submit Cookies)

Любой браузер -> WebApp (GA & Double Submit Cookies & Запятая, как разделитель cookie)

Эксплуатация

После подготовки неплохой базы, необходима проверка в реальных условиях. Практически сразу находится идеальный вариант mobile.twitter.com.

На нем реализована CSRF защита, основанная на cookie, сервер поддерживает перечисление cookie через запятую без пробела, но… На нем нет Google Analytics. Зато он есть на translate.twitter.com! Самое время проверить обработку атрибутов cookie значений, а если точнее, проверить возможность отбрасывания добавляемых в конце значений path и domain в случае, если инъекция происходит в значение cookie.

Оказалось, что Google Chrome в случае большого количества атрибутов cookie в какой-то момент просто прекращает их разбирать и не доходит до последних валидных значений.

То есть, в данном случае:

Set-Cookie: test=test; domain=.google.com; domain=.google.com; domain=.google.com; domain=.google.com; [...]; domain=blah.blah.blah.google.com;

Cookie будет установлена на .google.com, а не на blah.blah.blah.google.com.

Таким образом, добавляется еще одна цепочка эксплуатации:

Chrome -> WebApp 1 (Double Submit Cookies & Запятая, как разделитель cookie) & WebApp 2 (GA)

Формируем PoC:

  
    
      
        
        
        
      
      
    
    Tweet "PoC"

Описание:

Пользователь авторизован на twitter.com
Мобильная версия mobile.twitter.com подхватывает сессию основного сайта даже если пользователь не заходил на нее
Предполагаем, что пользователь не был на translate.twitter.com и у него не установлена cookie __utmz на нем
Передаем Referer с путем, в котором содержится инъекция в cookie, на сайт translate.twitter.com
Google Analytics создает сookie __utmz=blah...|,m5_csrf_tkn=x,
Из-за большого количества атрибутов Chrome перезаписывает domain на .twitter.com
Ждем окончание обработки запроса и посылаем еще один запрос на создание твита «PoC», используя токен «x»
В соответствии с порядком отправленных cookie, mobile.twitter.com берет наше значение токена «x» и убеждается, что значение в post запросе и в cookie одинаковые
У пользователя появляется твит PoC

Особенности обработки Cookie #3

Следующей целью стал instagram.com, а точнее все сайты на Django. CSRF защита в Django также основана на cookie. Для успешного прохождения проверки достаточно послать одинаковые значения в cookie csrftoken и post параметре csrfmiddlewaretoken, либо в HTTP заголовке X-CSRFToken. Однако, есть дополнительная проверка, которая в дальнейшем может помешать. В случае, если сайт работает по HTTPS, Django проверяет заголовок Referer и, в случае несовпадения, блокирует запрос, даже если в нем указан правильный токен. Post запросы без Referer также блокируются.

В ходе изучения обработки сookie в Django были обнаружены следующие особенности:

В качестве разделителя не обязательно использовать точку с запятой, достаточно любого пробельного символа между параметрами
Cookie: test=test test2=test2
Если в значении сookie есть символы [ \ ], то первая часть сookie отбрасывается
Cookie: test=test]test2=test2.
В результате создается только сookie test2.

Оказалось, что данная проблема даже не в Django, а в Python. Библиотека Cookie обрабатывает значения в соответствии с RFC2109. И действительно оказывается, что использование символов [ \ ] не предусмотрено, если значение не обрамлено двойными кавычками. Для браузеров же использование этих символов — вполне нормальное явление.

PoC для instagram практически идентичен предыдущему:

  
    
      
        
        
      
      
      
  </body>  
</html>
</code>
</pre><p>
<br />Для&nbsp;пробрасывания cookie <code>__utmz</code> используется <code>blog.instagram.com</code>, а&nbsp;для&nbsp;создания токена конструкция <code>/r/]csrftoken=x,;domain=.instagram.com;</code>.</p>

<h4>Особенности обработки Cookie #4</h4><p>
<br />После общения с&nbsp;Google, Twitter, Facebook, Django и&nbsp;Python я&nbsp;вновь решил попробовать обойти их&nbsp;исправления.</p>

<p>Произошли следующие изменения условий: <br /></p>

<ol><li>Google Analytics начал отбрасывать часть после точки с&nbsp;запятой и&nbsp;принудительно заменять пробел на&nbsp;%20</li>
<li>Python исправил некорректную обработку <code>[ \ ]</code></li>
</ol>

<p><br />Однако, все еще оставалась возможность перечисления cookie через&nbsp;пробельный символ в&nbsp;Django, чему сильно мешала замена используемая Google.</p>

<p>Проверка пробельных символов показала следующее: <br /></p>

<ol><li>Internet Explorer заменяет символы \x09 \x0b \x0c на&nbsp;_</li>
<li>Chrome не&nbsp;устанавливает cookie, если оно содержит символы \x09 \x0b \x0c</li>
<li>FireFox считает данные символы нормальными</li>
</ol>

<p><br />В&nbsp;результате чего получается следующий вариант эксплуатации для&nbsp;FireFox</p>

<p><code>https://instagram.com/?utm_source=1&utm_medium=2&utm_campaign=3&utm_term=4&utm_content=5%09csrftoken%3dx</code></p>

<h4>Особенности обработки Cookie #5</h4><p>
<br />Также я&nbsp;обнаружил еще один интересный вариант в&nbsp;некоторых серверных реализациях, но&nbsp;пока не&nbsp;нашел применения в&nbsp;реальных условиях. При&nbsp;использовании спецсимволов в&nbsp;cookie, значение обрамляют в&nbsp;двойные кавычки. Данное поведение можно использовать следующим образом: </p>

<p><code>Set-Cookie: test="test</code><br /><code>Set-Cookie: foo=bar</code><br /><code>Set-Cookie: test2="</code></p>

<p>Для&nbsp;браузеров двойные кавычки не&nbsp;являются каким-то&nbsp;особым символом и&nbsp;в&nbsp;результате получится такой заголовок: </p>

<p><code>Cookie: test="test; foo=bar; test2="</code></p>

<p>Но&nbsp;некоторые веб-серверы могут обработать данные значения, как&nbsp;один параметр test, в&nbsp;результате чего параметр <code>foo=bar</code> не&nbsp;будет создан. При&nbsp;совпадении невероятного количества условий, данная особенность также может быть использована.</p>

<h4>Результаты</h4><p>
<br />Варианты эксплуатации
<br /><code>Safari -> WebApp (GA & Double Submit Cookies)</code><br /><code>Любой браузер -> WebApp (GA & Double Submit Cookies & Запятая, как разделитель cookie)</code><br /><code>Chrome -> WebApp 1 (Double Submit Cookies & Запятая, как разделитель cookie) & WebApp 2 (GA)</code><br /><code>FireFox -> WebApp (GA & Double Submit Cookies & Пробельные символы, как разделитель cookie)</code>Фиксы
<br /></p>

<ol><li>В&nbsp;Google Analytics добавили принудительную замену пробела на&nbsp;%20 в&nbsp;значении cookie (сомнительное улучшение)<br /></li>
<li>В&nbsp;Google Analytics исправили возможность изменить атрибуты cookie путем отбрасывания всего, что&nbsp;идет после символа »;»<br /></li>
<li>Google Chrome НЕ&nbsp;будет исправлять перезапись с&nbsp;помощью большого количества атрибутов, так как&nbsp;возможности устанавливать произвольные атрибуты не&nbsp;должно быть у&nbsp;клиента изначально<br /></li>
<li>Python исправил проблему с&nbsp;символами <code>[ \ ]</code> (https://hg.python.org/cpython/rev/270f61ec1157)<br /></li>
<li>Twitter изменили тип CSRF защиты на&nbsp;сайте <code>mobile.twitter.com</code><br /></li>
</ol>

<p><br />При&nbsp;общении с&nbsp;Google я&nbsp;столкнулся с&nbsp;тотальным непониманием сути уязвимости. От&nbsp;меня требовали примера на&nbsp;сайтах Google, которого у&nbsp;меня не&nbsp;было, и&nbsp;их&nbsp;совершенно не&nbsp;интересовало, что&nbsp;Google Analytics может нести угрозу на&nbsp;других сайтах. И&nbsp;лишь спустя десяток писем мой отчет попал к&nbsp;Krzysztof«у&nbsp;(судя по&nbsp;всему это был @kkotowicz), который разобрался что&nbsp;к&nbsp;чему и&nbsp;донес информацию до&nbsp;соответствующих разработчиков.</p>
    
            <p class="copyrights"><span class="source">&copy;&nbsp;<a target="_blank" rel="nofollow" href="http://habrahabr.ru/post/272187/">Habrahabr.ru</a></span></p>
                    </div>
                                                    
            <br>
            <!--<div align="left">
                <script type="text/topadvert">
                load_event: page_load
                feed_id: 12105
                pattern_id: 8187
                tech_model:
                </script><script type="text/javascript" charset="utf-8" defer="defer" async="async" src="//loader.topadvert.ru/load.js"></script>
            </div>
            <br>-->

            <div style="padding-left: 20px;">
                <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-2514821055276660"
                        crossorigin="anonymous"></script>
                <!-- PCNews 336x280 -->
                <ins class="adsbygoogle"
                     style="display:block"
                     data-ad-client="ca-pub-2514821055276660"
                     data-ad-slot="1200562049"
                     data-ad-format="auto"></ins>
                <script>
                    (adsbygoogle = window.adsbygoogle || []).push({});
                </script>
            </div>
            <!-- comments -->
                            <noindex>
                    <div style="margin: 25px;" id="disqus_thread"></div>
                    <script type="text/javascript">
                        var disqus_shortname = 'pcnewsru';
                        var disqus_identifier = '666684';
                        var disqus_title = 'Не все cookie одинаково полезны';
                        var disqus_url = 'http://pcnews.ru/blogs/ne_vse_cookie_odinakovo_polezny-666684.html';

                        (function() {
                            var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
                            dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
                            (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
                        })();
                    </script>
                    <!--<noscript>Please enable JavaScript to view the <a rel="nofollow" href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>-->
                    <!--<a href="http://disqus.com" rel="nofollow" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a>-->
                </noindex>
            
        </div>

        <br class="clearer"/>
    </div>
    <br class="clearer"/>

    

        <div id="footer-2nd"></div>

        <div id="footer">
            <br/><br/>
            <ul class="horz-menu">
                <li class="about"><a href="/info/about.html" title="О проекте">О
                        проекте</a></li>
                <li class="additional-menu"><a href="/archive.html" title="Архив материалов">Архив</a>
                </li>
                <li class="additional-menu"><a href="/info/reklama.html"
                                               title="Реклама" class="menu-item"><strong>Реклама</strong></a>
                    <a href="/info/partners.html" title="Партнёры"
                       class="menu-item">Партнёры</a>
                    <a href="/info/legal.html" title="Правовая информация"
                       class="menu-item">Правовая информация</a>
                    <a href="/info/contacts.html" title="Контакты"
                       class="menu-item">Контакты</a>
                    <a href="/feedback.html" title="Обратная связь" class="menu-item">Обратная
                        связь</a></li>
                <li class="email"><a href="mailto:pcnews@pcnews.ru" title="Пишите нам на pcnews@pcnews.ru"><img
                                src="/media/i/email.gif" alt="e-mail"/></a></li>
                <li style="visibility: hidden">
                    <noindex>
                        <!-- Rating@Mail.ru counter -->
                        <script type="text/javascript">
                            var _tmr = window._tmr || (window._tmr = []);
                            _tmr.push({id: "93125", type: "pageView", start: (new Date()).getTime()});
                            (function (d, w, id) {
                                if (d.getElementById(id)) return;
                                var ts = d.createElement("script");
                                ts.type = "text/javascript";
                                ts.async = true;
                                ts.id = id;
                                ts.src = (d.location.protocol == "https:" ? "https:" : "http:") + "//top-fwz1.mail.ru/js/code.js";
                                var f = function () {
                                    var s = d.getElementsByTagName("script")[0];
                                    s.parentNode.insertBefore(ts, s);
                                };
                                if (w.opera == "[object Opera]") {
                                    d.addEventListener("DOMContentLoaded", f, false);
                                } else {
                                    f();
                                }
                            })(document, window, "topmailru-code");
                        </script>
                        <noscript>
                            <div style="position:absolute;left:-10000px;">
                                <img src="//top-fwz1.mail.ru/counter?id=93125;js=na" style="border:0;" height="1"
                                     width="1" alt="Рейтинг@Mail.ru"/>
                            </div>
                        </noscript>
                        <!-- //Rating@Mail.ru counter -->

                    </noindex>
                </li>
            </ul>
        </div>

        <!--[if lte IE 7]>
        <iframe id="popup-iframe" frameborder="0" scrolling="no">