Web Hacking 101 중국어 버전 13, 하위 도메인 납치

5317 단어

13. 자역 납치


저자: Peter Yaworski
비룡
프로토콜: CC BY-NC-SA 4.0

묘사


하위 구역 제어는 정말 듣기에 그렇다. 이것은 일종의 장면으로 악의적인 사용자가 합법적인 사이트를 대표하여 하위 구역을 신청할 수 있다.한 마디로 하면 이 유형의 빈틈은 사이트가 하위 도메인에 DNS 기록을 만드는 것과 관련이 있다. 예를 들어 Heroku (호스트 업체) 이고 이 하위 도메인을 신청한 적이 없다.
  • example.com에 히로쿠에 등록했다.
  • example.com는 DNS 기록subdomain.example.com을 만들고 unicorn457.heroku.com을 가리킨다.
  • example.com는 신청하지 않았다unicorn457.heroku.com.
  • 악성 사용자가 신청unicorn457.heroku.com하고 복사example.com했다.
  • 모든 subdomain.example.com의 데이터가 악성 사이트를 통과하는데 유사해 보인다example.com.

  • 따라서 이 논리에 따르면 DNS 항목은 신청하지 않은 외부 서비스, 예를 들어 Heroku, Github, Amazon S3를 가리켜야 한다.그것들을 발견하는 좋은 방법은 KnockPy를 사용하는 것이다. 도구 1절에서 하위 영역의 흔한 목록을 교체해서 존재하는지 확인하는 것이다.

    예제


    1. Ubiquiti 하위 도메인 납치
    난이도:낮음
    URL: http://assets.goubiquiti.com
    보고서 링크: https://hackerone.com/reports/109699보고일자: 2016.1.10
    보너스: 500달러
    설명:
    하위 납치 설명에서 말한 바와 같이 http://assets.goubiquiti.com 아마존 S3 파일을 가리키는 DNS 기록이 있지만 실제 아마존 S3 용기는 존재하지 않는다.HackerOne 캡처:
    따라서 악성 사용자는 신청uwn-images.s3-website-us-west-1.amazonaws.com을 하고 이곳에 사이트를 배치할 수 있다.만약 이것이 Ubiquiti와 더욱 유사하다고 가정한다면, 이곳의 빈틈은 사용자가 개인 정보를 제출하고 계정을 제어하도록 유도하는 것이다.
    중요한 결론
    DNS 레코드는 새롭고 독특한 취약점 활용 기회를 제공합니다.KnockPy를 사용하여 하위 영역이 존재하는지 확인한 후에 유효한 자원을 가리키는지 확인하고 AWS, Github, Zendesk 및 기타 삼자 서비스에 특히 주의한다.이 서비스들은 사용자 정의 URL을 등록할 수 있도록 합니다.

    2. Scan.me의 Zendesk 지향


    난이도:낮음
    URL: support.scan.me
    보고서 링크: https://hackerone.com/reports/114134보고일자: 2016.2.2
    보너스:$1000
    설명:
    Ubiquiti의 예와 같이 여기 Scan.me는 DNS 기록을 가지고 있으며 support.scan.mescan.zendesk.com를 가리킨다.이런 상황에서 해커harry_mg는 신청scan.zendesk.com할 수 있고support.scan.me는 그것을 가리킨다.
    그렇습니다. 상금은 1000달러입니다.
    중요한 결론
    주의하다이 구멍은 2016년 2월에 발견된 것과 전혀 복잡하지 않다.성공적인 구멍 발굴은 날카로운 관찰이 필요하다.

    3. 페이스북 공식 방문 Token


    난이도:높음
    URL: facebook.com
    보고서 링크: http://philippeharewood.com/swiping-facebook-official-access-tokens보고 날짜: 2016.2.29
    보너스: 미공개
    설명:
    나는 이것이 자역 납치의 기술 정의에 부합되는지 모르겠지만, 필립이 최소한의 상호작용으로 임의의 페이스북 계정을 납치할 수 있도록 하는 중대한 발견이라고 생각한다.
    이 빈틈을 이해하기 위해서, 우리는 OAuth를 보아야 한다. 그들의 사이트에 따라 웹 이동과 데스크톱 응용의 안전성을 간단하고 표준적인 방식으로 검증할 수 있는 오픈 프로토콜이다.다시 말하면, OAuth는 사용자가 어떤 응용 프로그램을 대표할 수 있도록 권한을 부여할 수 있으며, 응용 프로그램에 비밀번호를 공유할 필요가 없다.사이트를 방문한 적이 있다면 Google, 페이스북, 트위터, 그리고 다른 계정으로 로그인할 수 있도록 해 줍니다. OAuth를 사용합니다.
    이제 이곳의 잠재적 이용에 주의를 기울였다고 가정해 보세요.OAuth가 사용자에게 권한을 부여할 수 있다면 오류 실현의 영향은 매우 크다.이 과정을 이해한 후에Philippe는 협의가 어떻게 실현되었는지 설명하는 괜찮은 그림을 제공했다.
    Philippe Harewood - Facebook OAuth 프로세스
    어쨌든 우리는 여기서 볼 수 있다.
  • 사용자는 일부 앱을 통해 페이스북 API를 일부 목적으로 사용하도록 요청했다.
  • 이 앱은 사용자를 페이스북 API로 다시 지정해 권한을 부여한다.
  • 페이스북 API는 사용자에게 코드를 제공하고 이를 앱으로 리디렉션했다.
  • APP는 코드를 받고 페이스북 API를 호출하여 Token을 획득한다.
  • 페이스북은 Token을 APP에 되돌려줍니다. 이것은 호출을 위한 권한을 부여하는 데 사용됩니다.

  • 이 절차에서 사용자는 계정을 방문하는 앱에 페이스북 사용자 이름과 비밀번호를 제공할 필요가 없다는 것을 알게 될 것이다.이것도 개관이다. 절차에서 교환할 수 있는 추가 정보를 포함하여 여기에도 많은 다른 일이 나타날 수 있다.
    페이스북이 #5에서 애플리케이션에 Token에 대한 액세스를 제공하는 중대한 취약점이 있다.
    Philippe의 발견을 돌이켜 보면, 이 Token들을 어떻게 시도하고 포획해서 페이스북이 그 앱이 아닌 그에게 그것을 보내도록 유도하는지 상세하게 설명한다.그러나 반대로 통제할 수 있는, 빈틈이 있는 페이스북 앱을 찾기로 했다.
    결과적으로 모든 페이스북 사용자들은 계정에 권한을 부여받은 앱을 사용하지만, 많은 사용자들은 현시적으로 사용하지 않는다.그의 Write Up에 따르면 하나의 예는'Content Tab of a Page on wwww'로 페이스북 팬 페이지에 API 호출을 로드했다.APP 목록 강좌는 https://www.facebook.com/search/me/apps-used에서 확인할 수 있습니다.
    브라우저 목록에 나타난 후에 Philippe는 앱을 찾았는데 그 설정이 잘못된 것이고 Token을 포획하기 위해 요청을 사용할 수 있다. 요청은 다음과 같다.
    https://facebook.com/v2.5/dialog/oauth?response_type=token&display=popup&client_id=APP_ID&redirect_uri=REDIRECT_URI
    

    여기에서 사용된 APP_ID 응용 프로그램은 완전한 권한을 가지고 오류를 설정한 것입니다. 단계 #1과 #2가 이미 완성되었음을 의미하며, 사용자는 팝업 창을 보지 않고 응용 프로그램에 권한을 부여할 수 있습니다. 왜냐하면 그들은 실제로 이미 완성되었기 때문입니다.또한 페이스북이 가지고 있지 않기 때문에REDIRECT_URIPhilippe는 실제로 그것을 가지고 있을 수 있다. 정확히 말하면 자역과 같다.따라서 사용자가 링크를 클릭하면 다음 위치로 리디렉션됩니다.
    http://REDIRECT_URI/access_token_appended_here
    Philippe는 Token에 접근한 모든 것을 기록하고 페이스북 계정을 납치하는 데 사용할 수 있다.더욱이 NB의 블로그에 따르면 만약에 공식 페이스북이 Token을 방문하면 레스의 다른 페이스북 앱인 Token, 예를 들어 인스타그램을 가지게 된다.그가 해야 할 일은 페이스북 GraphQL(페이스북에서 데이터를 얻는 데 사용되는 API)을 호출하는 것이다. 응답에는 요청에 사용된 앱access_token이 포함된다.
    중요한 결론
    나는 네가 왜 이 예가 이 책의 이 장과 절에 포함되었는지 알고 싶을 것 같다.나에게 있어서 가장 중요한 결론은.침투 과정에서 일부 유류 자원을 어떻게 활용하는지를 고려해야 한다.이 장의 이전 예에서 DNS는 더 이상 사용하지 않는 서비스를 가리킨다.여기에는 더 이상 사용하지 않는 앱을 미리 심사 비준해 놓은 것이 있다.침투할 때, 이러한 응용 프로그램의 변화를 찾아야 한다. 응용 프로그램은 당신에게 공개된 자원을 남길 수 있다.
    그 밖에 만약에 이 예를 좋아한다면 Philippe의 블로그(자원 1장과'Hacking Pro Tips Interview'를 볼 수 있다. 이것은 그가 앉아서 나와 함께 완성한 것이다. 그는 좋은 조언을 많이 해 주었다)를 볼 수 있다.

    총결산


    한 사이트가 쓸모없는 DNS 기록을 만들고 삼자 서비스 공급자를 가리키면 하위 구역 납치는 정말 완성하기 어렵지 않다.KnockPy, Google Hack (site:*.hackerone.com, Recon-ng, 기타 등 다양한 방법으로 그것들을 발견할 수 있습니다.이 물건들의 용법은 모두 이 책의 도구 한 장에 포함되어 있다.
    또한 앞서 페이스북이 Token에 방문한 예와 같이 이러한 유형의 빈틈을 고려할 때 당신의 영역을 확대하고 목표에 유행이 지난 유류 자원이 있는지 고려한다.예를 들어 redirect_uri와 사전 승인된 페이스북 앱이다.

    좋은 웹페이지 즐겨찾기