해커원 버그바운티 절반의 실패 경험기

HackerOne (http://hackerone.com)은 온라인 버그바운티 플랫폼으로써 170여개의 기업이 참여하고 있다. 현재까지 45,000개 이상의 취약점이 HackerOne을 통해 보고 되었다고 하니, 해커들이 이 플랫폼을 얼마나 적극적으로 활용하고 있는지를 대략이나마 가늠할 수 있다. 해커원 버그 바운티 현황…버그가 많이도 나왔다   사실 시스템 해킹을 공부하는 입장에서 HackerOne 은 크게 매력적인 플랫폼은 아니다. 참여하고 있는 대부분의 기업들이 웹 어플리케이션(Web Application)을 바운티 범위 (Scope)로 잡고 있기 때문에 대부분의 보고된 취약점 역시 웹 취약점에 한정되어 있다. 그럼에도 불구하고 나는 매일같이 이 사이트를 들락날락 거리면서, 여러 해커들이 찾은 신선한 아이디어를 낼름낼름 공짜로 공부하는 즐거움을 느낄 수 있었다. 이번 블로그 포스팅은 나의 첫번째 해커원 버그바운티 도전/실패 경험 그리고 외국 보안 담당자와 우리나라 보안 담당자의 미묘한 차이에 대해 이야기 해보고자 한다.   무슨 취약점을 찾아 볼 것인가? 회사에서 모의해킹을 할 때에는 주어진 대상과 찾아야 하는 취약점이 명확한 경우가 많다. 그러나 해커원에 등록되어 있는 수 많은 기업들 중에서 어느 하나를 집어 취약점을 찾으려고 하니 뭔가 방법적인 면에서 비효율적이라는 생각이 들었다. (언제 무슨 취약점이 나올지도 모르는 상황에서 끝도없이 테스트만 해보는건 너무 무모하므로…) 따라서, 최근 해커원에서 보고된 취약점 카테고리를 하나 선정한 후에 다른 사이트에서 동일한 취약점이 있는지를 점검해보는 방식으로 진행하기로 했다.   아마존 S3버킷 Access Control Misconfiguration 취약점 SQL 인젝션이나 XSS 같은 경우는 개인적으로 식상하기도 하고 관심사에서 멀어진 취약점이라 처음부터 고려를 하지 않았다. 최근

Continue Reading

GEF – GDB Enhanced Features 소개

  리눅스 환경에서 순수(?) 버전의 gdb 사용은 상당한 인내를 필요로 한다. 가장 기본적인 디버거답게 여러가지 기능들을 갖추고 있지만, “보기 좋은 것까지 나한테 바라지 마라…”고 말하는 듯한 느낌이 들 때가 있다. 개인적으로 가장 gdb의 가장 불편한 점을 하나 꼽으라면 스택 정보를 볼 때, 매번 명령어를 입력해야 한다는 것이다. (물론 익숙해지면 그러려니 하고 쓰게 되지만… ㅠㅠ) 이런 단점을 해결하기 위한 사막의 오아시스 같은 툴이 등장했는데 바로 예전에 소개한 바 있는 PEDA 이다. 이전 자료 링크 :  Linux Exploit을 손쉽게 – peda 디버거 활용 [이 좋은 걸 만들어 준 Long(?) 씨에게 다시 한번 감사를] 그러나 PEDA는 Intel CPU 기반의 32/64비트 환경만 지원하기 때문에 ARM, SPARC 등의 시스템에서는 사용이 불가하다. 이번에 소개할 GEF – GDB Enhanced Features는 이러한 문제점을 단번에 해결해 줄 수 있다. ARM, PowerPC, SPARC 등의 시스템을 모조리 지원하는 GDB 확장 도구 GEF를 만나보자.   1. 설치 – Installation 설치 과정은 PEDA와 마찬가지로 매우 간단하다.  다음 3줄이면 설치 후 바로 사용이 가능하다. [crayon-59726824b97f7690447508/] 위 기본 사항만으로도 대부분의 기능을 사용할 수 있지만, ROP공격이나, 디스어셈블 기능을 강화하기 위해 다음 두가지 모듈을 추가로 설치할 것을 권장한다.   1) Capstone Disassembly 프레임워크로써, 다양한 아키텍쳐 환경을 지원한다. github (https://github.com/aquynh/capstone)를 통해 다운로드 받거나, pip 를 통해 바로 설치가 가능하다. [crayon-59726824b980a940484318/]   2) ROPGadget ROP 공격시 코드 내에서 ROP 조각들을

Continue Reading

Linux Exploit을 손쉽게 – peda 디버거 활용

  리눅스 환경에서 Exploit 공격 기법을 공부할 때 가장 처음 겪는 어려움은 아마도 GDB 사용이 아닐까 싶다. 윈도우와 같이 편리한 GUI 환경도 아닌데다가 여러개의 복잡한 옵션들, 그리고 Disassemble된 함수 내용이 많을 경우 더욱 더 사용하기가 꺼려지는게 사실이다. 사실 이러한 불편함도 수십번 쓰다보면 어느샌가 적응되어 있기는 하지만, 그럼에도 불구하고 리눅스 환경에서의 디버깅은 윈도우에 비하면 불편한 점이 많다. (물론 개인적인 생각이지만) 윈도우 환경에서 Exploit을 도와주는 여러 도구들 중 Immunity Debugger와 함께 사용 시 큰 힘을 발휘하는 Mona (https://github.com/corelan/mona) 가 있는데, 리눅스에서도 이와 비슷한 도구가 있어 소개 하고자 한다. 바로 블랙햇 2012에서 공개 된 PEDA 이다.   1. PEDA 개요 및 주요기능 소개 PEDA는 앞서 언급한 것처럼 리눅스 환경에서의 Exploit을 도와주는 도구이다. PEDA는 Python Exploit Development Assistance for GDB의 약자로써, GDB 기능을 확장하여 Exploit을 손쉽게 할 수 있게 도와주는 다양한 옵션과 유틸리티가 포함되어 있다. PEDA가 제공하는 주요 기능은 다음과 같다. Memory Operation – 메모리 구조 분석 Debugging Helpers – 디버깅을 손 쉽게 해주는 기능들 Exploit helpers – 익스플로잇에 필요한 패턴 및 쉘코드 제작 Utilities – 기타 유틸리티 그럼 본격적으로 PEDA 기본적인 사용법과 이를 이용한 Exploit을 실습해보도록 하자. ※ 블랙햇 발표자료는 ☞☞☞ [ 다운로드 링크 ]  ☜☜☜ 에서 받아볼 수 있다.   2. PEDA 다운로드 및 설치하기 PEDA는 파이썬 기반의 도구이므로, 당연히 파이썬이 먼저 설치되어 있어야

Continue Reading

[번역] SQL 인젝션 테스트를 위한 Burp 플러그인 활용(SQLiPy)

본 블로그 포스트는 아래 블로그 내용을 그대로 번역한 것입니다. 약간의 의역이 포함되어 있음을 미리 알려드립니다. [ 원문 글 주소 : https://www.codewatch.org/blog/?p=402 ]   나는 수년간 웹 어플리케이션에 대한 평가(점검)를 수행해왔다. 웹 보안 점검을 수행할 때 가장 많이 사용하는 두가지 도구를 꼽으라면 Burp Suite Pro와 SQLMap을 선택할 것이다. Burp Suite 는 웹 보안 점검을 수행하는데 있어 가장 기본적이면서도 훌륭한 도구라 할 수 있다. 만약 당신이 이미 웹 보안 점검을 수행한 경험이 있다면 이 도구에 대한 사용법을 이미 알고 있을것이라 생각한다. 또한, SQLMap 은 SQL 인젝션 공격을 시도할 때 Burp Suite를 기능적으로 보완해주는 역할을 한다. 과거 이 기능을 알았을 때 유연성과 확장성을 보고 크게 놀랐는데, 아직까지 이보다 더 좋은 플러그인은 보지 못한 것 같다 (아마도 내가 모르는 것일 수도 있지만) 예전에 내가 이 플러그인에 대해 알고있던 내용은 다음과 같다. 1. 플러그인으로 커맨드 라인 명령어 (당신이 실행하고자 하는 방향으로)를 생성한 후, 해당 구문을 복사하여 SQLMap을 직접 실행하거나2. 플러그인이 직접 SQLMap을 실행한 후, 결과를 콘솔 화면에 보여준다. 개발쪽에 발을 많이 담그지 않았기 때문에, 이 두가지를 하나로 통합해야겠다는 생각을 해본적은 없다.. 어느날 SQLMap 이 설치된 디렉토리에 sqlmapapi.py 파일이 있다는것을 알기 전까지는 말이다. 이전까지 이 파일이 있었다는 것을 몰랐지만, 알고 난 직후 이 스크립트가 무엇을 위한 것인지 자세히 들여다보기 시작했다. 이 api 파일은 RESTful 인터페이스를 가진 웹서버 역할을

Continue Reading

Brute Forcing (무작위 대입공격)은 정말 구닥다리가 되었나?

<Caution> : 본 포스팅은 연구 목적으로 작성되었으며, 허가 받지 않은 대상에 대한 공격 테스트를 절대 금합니다. 악의적인 목적으로 이용할 시 발생하는 모든 법적 책임은 자신에게 있습니다. 이는 해당 글을 열람할 때 동의하였다는 것을 의미합니다.    얼마전 iCloud 해킹으로 인해 헐리우드 스타들의 누드 사진이 노출되는 소동이 있었다. 사실 이것을 애플이 “해킹 당한것”으로 봐야할지 말아야할지는 의견이 분분한 것 같다 (개인적으로는 애플이 “해킹” 당했다는 의견에 동의하는 편이다.) 많은 이들이 Brute Forcing Attack을 이제는 구닥다리 공격법이라고 이야기하지만, 여러 측면으로 접근해보면, SQL 인젝션만큼의 파급력을 갖고 있다고 생각한다. 이번 포스팅에서는 모의해킹 경험을 바탕으로 다양한 BruteForcing 시나리오를 다룰 예정이다.   – Case 1 : 아무런 제약이 없는 조건에서의 공격법 [ 논란이 된 Find My iPhone 접속 화면 – 어떠한 보안 장치도 없었던 상황 ] BruteForcing 공격을 방어하기 위해 일반적으로 웹 서비스는 다음과 같은 보안장치를 한다. 1. ID / 비밀번호 입력 횟수 제한 (본인 경험상 가장 많은 방식이라 생각됨) 2. ID / 패스워드 중 어떤 항목이 틀렸는지 불명확한 용어를 표시 (Ex. “아이디 또는 패스워드가 정확하지 않습니다”) 3. 일정 횟수 이상 입력이 잘못된 경우 해당 계정 잠금(Lock) 어이없게도 이번 iCloud 계정이 털린 FindMyiPhone 웹 사이트의경우 위 세가지 보안조치 사항 중 단 하나도 제대로 설정되어 있지 않았다. 다시 말해 공격자에게는 매우 “땡큐”스러운 상황이었던 것이다. 첨에는 이 기사를 보고 ‘애플 내부에 스파이라도 있는건가?’는

Continue Reading

Site Footer

Sliding Sidebar

About Me

About Me

June Park