OTG-INFO-004 (웹 서버에 응용 프로그램 확인)


개요

웹 응용 프로그램 취약점 테스트에서 가장 중요한 단계는 웹 서버에 호스팅되어 있는 특정 응용 프로그램을 찾는 것입니다. 많은 응용 프로그램들이 원격 관리 권한을 획득하거나 데이터를 얻기 위해 알려진 취약점 및 공격 기법들이 있습니다. 추가적으로, 많은 응용 프로그램들이 내부적으로 사용한다는 인식 때문에 대부분 잘못된 설정을 하거나 최신으로 업데이트 하지 않아, 위협이 존재할 수 있습니다.

가상 웹 서버 확산으로 기존의 IP와 웹서버의 1:1 형식은 원래 의미를 잃었습니다.

동일한 IP 주소로 확인된 도메인 명이 여러 웹 사이트 또는 응용 프로그램을 가지는게 드문 일이 아닙니다. 이 시나리오는 호스팅 환경에 한정되지 않지만, 통상적으로 기업에 적용됩니다.

보안 전문가들에게는 때때로 침투 테스트 대상으로 IP 주소가 주어지기도 합니다. IP로 주어지는 침투 테스트 시나리오는 대상을 통해 접근할 수 있는 모든 웹 응용 프로그램을 테스트하기 위한 경우 입니다. 문제는 주어진 IP 주소가 포트 80에서 HTTP 서비스를 호스팅하는 것이지만, 만약 테스터가 IP 주소를 지정하여 접근하면, "No web server configured at this address" 또는 이와 유사한 메시지가 보고됩니다.

그러나, 시스템은 관련없는 DNS에 연결된 웹 응용 프로그램의 수를 숨길 수 있습니다.

분명히 분석의 범위는 테스터가 모든 응용 프로그램을 테스트하는 데 큰 영향을 받습니다.

때때로, 대상 특성이 더 풍부해집니다.

테스터는 IP 주소와 그에 상응하는 DNS를 제공받을 수 있습니다.

그럼에도 불구하고, 이 리스트는 부분적인 정보를 전달할 것입니다. 즉, DNS를 생략할 수 있고, 클라이언트는 그것을 인식하지 못할 수도 있습니다. (이것은 큰 조직에서 발생할 가능성이 더 큽니다.)

평가 범위에 영향을 미치는 다른 문제는 명확하지 않은 URL에 게시된 응용 프로그램에 의해 표현됩니다. (예제> http://www.example.com/some-strange-URL),

이것은 설정 실수와 같은 에러나 알려지지 않은 관리자 인터페이스와 같이 의도적으로 발생될 수 있습니다.

이러한 문제를 해결하기 위해서는, 웹 응용 프로그램의 검색을 수행 할 필요가 있습니다.


테스트 목적

웹 서버에 존재하는 응용 프로그램 확인


테스트 방법


Black Box Testing

웹 응용 프로그램 발견은 주어진 인프라에서 웹 응용 프로그램을 식별하기 위한 과정입니다. 후자는 일반적으로 IP 주소의 집합으로 지정되지만, DNS 명 또는 이들 조합으로 구성될 수 있습니다.

이 정보는 고전적인 스타일의 침투 테스트 또는 응용 프로그램 중심의 평가 일지라도 평가 수행 전에 전달됩니다.

두 가지 경우 모두 침투 테스트 규칙에 따로 명시하지 않는 한, 평가는 범위에서 가장 포괄적이 되도록 노력해야 합니다. 즉, 주어진 대상을 통해 액세스 할 수 있는 모든 응용 프로그램을 식별해야 합니다.

다음 예제들은 이 목표를 달성하는 데 사용할 수 있는 몇 가지 기술을 검토합니다.


1. 다른 기본 URL

웹 응용 프로그램에서 명백한 입력 지점은 www.example.com 입니다. 즉, http://www.example.com/ 에서 시작하는 웹 응용 프로그램의 단축 표기번을 생각해볼 수 있습니다.

위와 같은 경우가 일반적인 상황이지만, "/"에서 응용 프로그램을 시작하지 않아도 됩니다.

예를 들어, 다음과 같은 세 가지 웹 응용 프로그램에 동일한 기호 이름을 연결할 수 있습니다.

이 경우 URL http://www.example.com/은 의미있는 페이지로 연결되지 않으며, 세 가지 응용 프로그램은 테스터가 정확하게 연결하는 방법을 알지 못하는 한 "숨김"상태가 됩니다. 즉, 테스터는 url1, url2 또는 url3로 알고 있습니다.

소유자가 표준 방식으로 액세스하기를 원하지 않는 한 일반적으로 이러한 방식으로 웹 응용 프로그램을 게시할 필요는 없으며, 정확한 위치를 사용자에게 알릴 준비가 되어 있습니다.

이것은 응용 프로그램이 보안되어 있다는걸 의미하진 않으며, 프로그램의 존재 및 위치가 분명하게 공개되지 않았음을 의미합니다.


2. 비표준 포트

웹 응용 프로그램은 일반적으로 포트 80(http) 및 443(https)에 있지만, 이러한 포트 번호에 대해서는 별다른 변화가 없습니다.

사실 상, 웹 응용 프로그램은 임의의 TCP 포트와 연괼될 수 있으며, 다음과 같이 포트 번호를 지정하여 참조할 수 있습니다.

http://www.example.com:20000/

3. Virtual hosts

DNS는 단일 IP 주소가 하나 이상의 심볼릭 네임과 연결되도록 허용합니다. 예를 들어, IP 주소 192.168.1.100은 DNS 네임 www.example.com, helpdesk.example.com, webmail.example.com으로 할당할 수 있습니다. 모든 이름이 동일한 DNS 도메인에 속할 필요는 없습니다.

이 1-to-N 관계는 소위 virtual host를 사용하여 다른 컨텐츠를 제공하기 위해 반영될 수 있습니다. 참조하고 있는 virtual host를 지정하는 정보는 HTTP 1.1 Host: header에 내장되어 있습니다.

helpdesk.example.com과 webmail.example.com을 알지 못한다면, 분명한 www.example.com 외에 다른 웹 응용 프로그램의 존재를 의심하지 않아도 됩니다.



문제를 해결하기 위한 접근 방식 1 - non-standard URLs

비표준 웹 응용 프로그램의 존재를 완전히 확인할 수 있는 방법은 없습니다.

비표준이기 때문에 명명 규칙을 관리하는 고정 된 기준은 없지만, 테스터가 몇 가지 추가적인 통찰력을 얻기 위해 사용할 수 있는 여러 기술이 있습니다.

첫째, 웹 서버가 잘못 구성되어 있고 디렉토리 검색이 가능하다면 이러한 응용 프로그램을 발견 할 수 있습니다.

취약점 스캐너가 이러한 측면에서 도움이 될 수 있습니다.

둘째, 이러한 응용 프로그램은 다른 웹 페이지에서 참조할 수 있으며 웹 검색 엔진에서 수집 및 색인을 생성 할 가능성이 있습니다.

테스터가 www.example.com에서 이러한 "숨겨진" 응용 프로그램의 존재를 의심하면, "site : www.example.com"에 대한 쿼리 결과를 검사 할 수 있습니다.

반환된 URL 중에는 이러한 명백하지 않은 응용 프로그램을 가리키는 URL이 있을 수 있습니다.

또 다른 옵션은 게시되지 않은 응용 프로그램의 후보가 될 수 있는 URL을 조사하는 것입니다.

예를 들어, 웹 메일 프론트 엔드는 https://www.example.com/webmail, https://webmail.example.com/ 또는 https://mail.example.com/과 같은 URL에서 액세스 할 수 있습니다.

숨겨진 URL에 게시 될 수 있지만 아직 참조되지 않은 관리 인터페이스의 경우에도 마찬가지 입니다.

따라서 약간의 사전 스타일 검색 (또는 "지능적 추측")을 수행하면 몇 가지 결과를 얻을 수 있습니다. 취약점 스캐너가 이러한 측면에서 도움이 될 수 있습니다.


문제를 해결하기 위한 접근 방식 2 - non-standard ports

비표준 포트는 웹 응용 프로그램의 존재 여부를 쉽게 확인할 수 있습니다.

nmap과 같은 포트 스캐너로 -s 옵션을 사용하여 서비스 인식을 수행 할 수 있으며, 임의의 포트에서 http[s] 서비스를 식별합니다.

필요한 것은 전체 64k TCP 포트 주소 공간을 전체적으로 검사하는 것입니다.

예를 들어, 다음 명령은 TCP 연결 검사와 함께 IP 192.168.1.100에 있는 모든 열린 포트를 검색하고 어떤 서비스가 이들에 바인딩되어 있는지 확인하려고 시도합니다.

nmap –PN –sT –sV –p0-65535 192.168.1.100

Interesting ports on 192.168.1.100:
(The 65527 ports scanned but not shown below are in state: closed)
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 3.5p1 (protocol 1.99)
80/tcp    open  http        Apache httpd 2.0.40 ((Red Hat Linux))
443/tcp   open  ssl         OpenSSL
901/tcp       open  http        Samba SWAT administration server
1241/tcp  open  ssl         Nessus security scanner
3690/tcp  open  unknown
8000/tcp  open  http-alt?
8080/tcp  open  http        Apache Tomcat/Coyote JSP engine 1.1

이 예제로 부터 아래와 같은 내용을 확인할 수 있습니다.

  • Apache http 서버는 80 포트에서 실행되고 있음.
  • It looks like there is an 443 포트에서 https 서버가 있는 것으로 보임
  • 901 포트에 Samba SWAT 웹 인터페이스가 있음.
  • 1241 포트에 서비스는 https가 아니지만 SSL-wrapped Nessus daemon이 실행 중.
  • 포트 3690에는 지정되지 않은 서비스가 있습니다.
  • 포트 8000의 또 다른 알려지지 않은 서비스; 이 포트에서 http 서버를 찾는 것이 일반적이지 않기 때문에 아마도 http 일 수 있습니다.
$ telnet 192.168.10.100 8000
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 200 OK
pragma: no-cache
Content-Type: text/html
Server: MX4J-HTTPD/1.0
expires: now
Cache-Control: no-cache

<html>
...

이는 실제로 HTTP 서버임을 확인합니다.

  • Apache Tomcat은 포트 8080에서 실행 중입니다.

문제를 해결하기 위한 접근 방식 3 - virtual hosts

주어진 IP 주소 x.y.z.t에 할당된 DNS명을 식별하기 위해 사용할 수 있는 수많은 기술이 있습니다..

DNS zone-transfers

이 기술은 최근 DNS 서버가 zone-transfer 기능을 사용하지 않는다는 사실을 감안할 때 사용이 제한적입니다.

그러나, 시도해 볼 가치가 있습니다.

우선, 테스터는 x.y.z.y를 제공하는 네임 서버를 결정해야 합니다. 만약 심볼릭 네임이 x.y.z.t로 알려져있다면, DNS 서버 레코드를 요청하여 nslookup, host 또는 dig와 같은 도구를 사용하여 네임 서버를 결정할 수 있습니다.

만약 심볼릭 네임이 x.y.z.t로 알려져있지 않지만 대상 정의에 심볼릭 네임이 일부 포함되어 있다면, 테스터는 동일한 프로세스를 적용하고 네임 서버에 해당 이름을 쿼리하려고 시도할 수 있습니다.

예를 들어, 만약 대상 IP 주소가 x.y.z.t로 구성되어 있고 mail.example.com이라면, 네임서버는 example.com으로 결정됩니다. 다음 예제는 host 명령을 사용하여 www.owasp.org에 네임 서버를 식별하는 방법을 보여줍니다.

$ host -t ns www.owasp.org
www.owasp.org is an alias for owasp.org.
owasp.org name server ns1.secure.net.
owasp.org name server ns2.secure.net.

zone-transfer는 이제 example.com 도메인의 네임 서버에 요청할 수 있습니다. 테스터가 운이 좋으면, 이 도메인의 DNS 항목 목록을 다시 가져옵니다.

여기에는 명백한 www.example.com과 명확하지 않은 helpdesk.example.com 및 webmail.example.com이 포함됩니다.

zone-transfer로 반환된 모든 이름을 확인하고 평가 대상과 연관된 모든 이름을 고려하십시오. 그것의 네임 서버 중 하나로부터 owasp.org에 zone-transfer 요청을 시도합니다.

$ host -l www.owasp.org ns1.secure.net
Using domain server:
Name: ns1.secure.net
Address: 192.220.124.10#53
Aliases:

Host www.owasp.org not found: 5(REFUSED)
; Transfer failed.

DNS inverse queries

이 과정은 위와 유사하지만, inverse DNS 레코드에 의존합니다. zone-transfer를 요청하는 대신, 레코드 유형을 PTR로 설정하여 지정된 IP 주소에 대해 쿼리를 실행하십시오.

테스터가 운이 좋으면, DNS 항목을 다시 가져올 수 있습니다. 이 기술은 IP 심볼릭 네임 맵의 존재에 의존하며, 이는 보장되지 않습니다.

Web-based DNS searches

해당 종류의 검색은 DNS zone-transfer와 비슷하지만 DNS 기반의 이름 기반 검색을 가능하게 하는 웹 기반 서비스에 의존합니다.

Netcraft Search DNS 서비스: http://searchdns.netcraft.com/?host

Reverse-IP services

Reverse-IP 서비스는 DNS inverse querie와 유사하지만, 테스터가 이름 서버 대신 웹 기반 응용 프로그램을 쿼리한다는 차이점이 있습니다. 해당 서비스는 여러 가지가 있습니다.

그들은 부분적인 결과를 반환하는 경향이 있으므로, 보다 포괄적 인 분석을 얻으려면 여러 서비스를 사용하는 것이 좋습니다.

Googling

테스터는 써치 엔진을 통해 정보 수집을 하여, 공격 대상과 관련된 추가 도메인 명의 정보를 얻거나, 비 명백한 URL을 통해 액세스 할 수 있습니다.

구글링 기술은 Spiders, Robots, Crawlers 테스트를 위해 설명되었습니다.


Gray Box Testing

Not applicable.


도구


참고 문헌

  • RFC 2616: Hypertext Transfer Protocol – HTTP 1.1