[파라미터 조작] Fingerprinting Port 80 Attacks 2 > security

I. Introduction:

Port 80 is the standard port for websites, and it can have a lot of different security issues.
These holes can allow an attacker to gain either administrative access to the website, or even the web server itself.  This second paper was written to help the average administrator and developer to have a better understanding of the types of threats that exist, along with how to detect them.

80번 포트는 웹 사이트를 위한 표준이다. 그것은 다른 수많은 보안에 관한 이슈들을 가지고 있다. 이러한 보안 홀들은 공격자가 웹 사이트에 대한 관리자 접근이나 웹서버 자체를 획득하는 것을 허용한다. 이 두번째 문서에서는 보통의 관리자와 개발자에게 무언가 도움을 주고자 한다. 존재하는 위협의 타입에 대한 더많은 이해와 그것들을 어떻게 탐지하는지에 대해 언급하고자 한다.

II. More Common Fingerprints:

This section has examples of more common fingerprints used in exploitation of both web applications, and web servers.  This section is not supposed to show you every possible fingerprint, but instead show you more ways an attacker can possibly get into your system, along with how an attackers presence could be masked. These signatures should pick up most of the remaining methods not spoken about in the first paper. This section also describes what each signature is used for, along with examples of it being used in an attack.

이 부분은 웹 애플리케이션과 웹 서버들에 대해서 사용되어지는 보다 일반적인 공격징후들에 관한 예제들을 들어보고자 한다. 이부분은 당신에게 모든 가능한 징후들을 보여주는 것을 가정하지 않는다. 대신에 공격자가 당신의 시스템에 침투를 시도하는 더 많은 방법들을 보여줄 것이다. 공격자들의 존재가 어떻게 숨겨지는지에 관한 것도 포함되어 있다. 이러한 기호들은 첫번째 문서에서 설명하지 않는 것들 중에서 선택하였다. 이 부분은 각 기호가 무엇을 의미하는지에 대한 설명과 공격에서 그것이 사용되어지는 예제들을 포함하고 있다.

" * " Requests

The asterisk is often used by attackers as an argument to a system command.

Below is an example

* http://host/index.asp?something=........WINNTsystem32cmd.exe?DIR&e:WINNT*.txt

This request is asking for all text files within the directory of e:WINNT to be listed.
Requests like these can often be used to gather a list of log files, along with other important files. Not a lot of web applications use this character in a valid request so this makes an asterisk stand out in logs.

이 요청은 e:WINNT 디렉토리 상에 존재하는 모든 텍스트 파일들에 대한 리스트를 요청한다. 이와 같은 요청은 로그파일 리스트와 다른 중요한 파일들을 수집하기 위해서 사용한다. 많은 웹 애플리케이션은 유용한 요청으로 이러한 문자를 사용하지 않는다. 그래서 이것은 로그에 * 표시를 만든다.

* http://host/blah.pl?somethingelse=ls%20*.pl

This request is asking for a directory listing on a Unix system of all perl scripts that end in .pl.

이 요청은 유닉스 시스템상에서 .pl 로 끝나는 모든 펄 스크립트에 대한 디렉토리 리스트를 요청한다.

" ~ " Requests

The ~ character is sometimes used by attackers to determine who is a valid user on your system.

Below is an example

* http://host/~joe

This request is looking for a user named "joe" on the remote system. Often times users will have web space and if the attacker manages to visit a web page, or get a 403 error(Denied error) then a user exists.  Once an attacker has a valid username, they may try guessing passwords, or brute forcing
until they get a valid password. There are other ways of finding out who is a valid user but this is a port80 request so I figured I'd mention it. (This is a well known method) It can easily be misidentified as a valid request in IDS logs depending on if the system has user pages in this format.

이 요청은 리모트 시스템 상에서 joe라는 유저를 찾아보게 된다. 사용자들은 웹 스페이스를 가지고 있을 것이다. 만일 공격자가 웹 페이지를 방문하기 위해 조작을 하거나 403 error (Denied error)를 얻게 된다면 사용자는 존재하는 것이다. 이제 사용자는 유효한 사용자 이름을 가지게 되었다. 패스워드를 추측하거나 유효한 패스워드를 획득할 때까지 부르트 포스 공격을 감행할 것이다. 다른 유용한 사용자를 확인하는 다른 방법들이 있지만 이 문서는 80포트 요청에 관한 것이기 때문에 이것만 언급한다. (이것은 잘 알려진 방법이다.) 만일 시스템이 이 형식으로 사용자 페이지를 가지고 있는지에 따라서 IDS 로그상에서 유효한 요청으로서 쉽게 오인되어질 것이다.

" ' " Requests

If this particular character shows up in your logs then there is a possibility someone is trying a SQL injection attack against your software. Often times programs may be written poorly and may allow an attacker to insert SQL commands into the script. If it is possible to execute system commands then it may be possible for an attacker to gain administrative access to your system.
(Sometimes administrators run SQL as root on Unix, and if you run MS-SQL it already runs with administrative privileges)

만일 이 특별한 문자가 당신의 로그상에 있다면 어떤이가 당신의 소프트웨어에 SQL Injection 공격을 시도하고 있을 가능성이 있다. 부실하게 작성된 프로그램들은 공격자가 SQL 명령들을 스크립트 안에 삽입하는 것을 허용한다. 만일 시스템 명령을 실행하는 것들이 가능하다면 공격자가 당신 시스템에서 관리자 접속을 획득할 가능성이 있다. (때로는 관리자들은 유닉스 상에서 SQL 을 루트 계정으로 실행을 한다. 만일 당신이 MS-SQL을 실행했다면 관리자 권한으로 실행하기 바란다.)

Below is an example.

* http://host/cgi-bin/lame.asp?name=john`;EXEC master.dbo.xp_cmdshell'cmd.exe dir c:'--

This request is executing the cmd.exe shell on a windows NT machine. From here an attacker has free reign on the remote machine with access to add users, upload trojans, and steal the sam password file.

For more information on SQL attacks visit www.cgisecurity.com/lib and check out a few papers we've collected from various sites on the subject. Also check out www.owasp.org for further examples of SQL Injection.

이 요청은 윈도우 NT 머신에서 cmd.exe 쉘을 실행한다. 이 경우에 공격자는 리모트 시스템 상에서 완전히 자유로운 통치가 되는 것이다. 사용자를 추가하고, 트로이안을 업로드하고 샘 패스워드 파일 훔칠 수도 있을 것이다.
SQL 공격에 관한 더 많은 정보를 얻기 위해서 www.cgisecurity.com/lib 를 방문한다. 주제에 관한 다양한 사이트에서 수집한 몇몇 문서들을 확인해 보라. SQL Injection에 관한 더 많은 예제들은 www.owasp.org 에서 확인해 보기 바란다.

" #, {} , ^ , and [] " Requests

These particular characters may show up in your logs if an attacker is echoing some source code into a file of a perl or c program. Once a file is created and compiled/interpreted the attacker could bind a shell to a port giving themselves easy access.

이 특별한 문자들은 공격자가 몇몇 소스코드들을 펄이나 C 프로그램으로 파일로 출력을 하였다면 당신의 로그에 보여질 수 있다. 한번 파일이 만들어지고 컴파일/인터프리트되어졌다면 공격자는 쉽게 접근할 수 있는 포트에 쉘을 바인드 할 수 있다.

I won't show a complete example of this because in order to do so I'd have to paste a bindshell program.
This paper wasn't written to give people easy to follow example on how to use trojans. For this reason I have decided not to include an example. [ and ]  may also be used as a command argument in Unix for commands like ls -al [a-f]*. This would list all the files starting with characters between a and f. # may show up if an attacker is uploading a perl script backdoor
(Ex: #!/usr/bin/perl at the top of the file).

나는 이것을 실행하기 위한 완벽한 예제를 보여주지 않을 것이다. 그래서 나는 바인드쉘 프로그램을 이곳에 보여주지 않는다. 이 문서는 사람들이 트로이안을 어떻게 하면 쉽게 따라 할 수 있는가에 대한 것이 아니다. 이러한 이유로 예제를 포함하지 않기로 결정했다. [ 과 ] 는 또한 유닉스 명령상에서 ls -al[a-f]* 처럼 사용할 수 있다. 이것은 문자 a와 f 사이로 시작하는 모든 파일들을 리스트할 것이다. #은 만일 공격자가 펄 스크립트 백도어를 업로딩 한다면 보여진다.
(예: #!/usr/bin/perl  파일 맨 위쪽에)

Below is an example using #

* http://host/dont.pl?ask=/bin/echo%20"#!/usr/bin/perl%20stuff-that-binds-a-backdoor"%20>/tmp/back.pl;/usr/bin/perl%20/tmp/back.pl%20-p1099

" ( and ) " Requests

This value is often used in cross site scripting attacks. Cross Site Scripting
has gotten a lot of attention lately, and a lot of large sites still suffer
from this type of attack.

Below is an example.

이 값들은 cross site scripting 공격에 사용한다. Cross Site Scripting은 최근에 많은 주의를 요하고 있다. 많은 대형 사이트들이 이 공격에 여전히 노출되고 있다.

* http://host/index.php?stupid=<img%20src="javascript:alert(document.domain)>

This example above will be sent to the index.php. From here an output page
will be displayed with the following javascript. Next your browser will execute this javascript and display a popup window. Cross site scripting is considered a low to medium threat. It does have the ability to allow an attacker to steal cookies from you. An obvious way to prevent this would be to make sure the output doesn't contain < or > in them. This way the javascript will not be executed.

이 예제는 index.php에 보내질 것이다. 여기서 출력페이지는 따라오는 자바스크립트를 출력할 것이다. 다음 당신의 브라우저는 이 자바스크립트를 실행할 것이고 팝업 윈도우를 보여줄 것이다. Cross site scripting은 중간 취급자들과 관련이 있다. 공격자가 당신으로부터 쿠키를 훔치는 것을 허용할 가능성을 가지고 있다. 이것을 맞는 분명한 방법은 그것들 안에 < 나 > 을 포함하지 않는다는 것을 확인하는 것이다. 이 방법만이 자바 스크립트가 실행되어지지 않을 것이다. 

" & " Request

Sometimes the & is used as a blank space similar to "%20" as mentioned in my
previous paper. This value (when used in an attack) is often used with cmd.exe backdoored hosts. Often times an attacker or worm will copy cmd.exe to a file inside the webroot. Once this file is copied an attacker has full control over your windows machine. He will use the & character to help pass arguments to the script. If this character comes up in your logs don't freak. This character is widely used with web applications and it can be easily misidentified. If it manages to pop up in your logs you may want to double check them but there is no reason to panic.

많은 예전 문서들에서 언급되어진 것과 같이 &는 %20과 비슷하게 빈스페이스로 사용한다. 공격에 사용되어진 이값은 백도어가 있는 호스트에서 cmd.exe와 함께 사용한다. 공격자나 웜은 cmd.exe를 웹루트에 있는 파일에 복사한다. 한번 이파일이 복사되어지면 공격자는 당신의 윈도우 머신에 관한 전박적인 사항에 대한 제어권을 가지게 된다. 공격자는 스크립트상에 인자를 전달하기 위해서 &를 사용할 것이다. 만일 이 문자가 당신의 로그상에 나타난다면 이상한 것이 아니다. 이 문자는 웹 애플리케이션에 전박적으로 사용된다. 그것은 쉽게 오인되어질 수 있다. 만일 당신 로그상에 나타나는 것을 관리하고자 한다면 당신은 그것을 재차 조사해 보기를 원할 수 있다. 하지만 흥분할 이유가 없다.

Below is an example.

* http://site/scripts/root.exe?/c&dir&c:

This particular example is showing a request to a backdoor called root.exe. This backdoor is installed by sadmind/IIS worm, Code Red, and Nimda after a host is compromised. The & character is often used in windows backdoors that involve cmd.exe copies.

이 특별한 예제는 호출되어진 백도어 root.exe에 관한 것을 보여준다. 이 백도어는 호스트가 장악되어진 후에 sadmind/IIS, 코드레드, 님다에 의해서 인스톨 되어진다. & 문자는 cmd.exe 복사와 관련이 있는 윈도우 백도어들에 사용한다.

Additional Worm Information 웜에 대한 추가적인 정보
http://www.cert.org/incident_notes/IN-2001-09.html

 

III. More Advanced Fingerprints

This section focuses more on the files an attacker or worm may request, along with a few other signatures that stand out. This isn't a complete list of requests or files an attacker may request, but it will give you a good idea of what is being attempted against your system.

이 부분은 공격들이 요청하는 파일에 초점을 맞추고자 한다. 그리고 나타나는 몇 개의 다른 기호들도 포함한다. 이것은 공격자가 요청하는 파일들이나 요청들에 대한 완벽한 리스트가 아니다. 하지만 당신의 시스템에 시도되어지고 있는 것이 무엇인지에 대한 좋은 근거를 보여 줄 것이다.

 

Lots of "/" Requests

If you check your logs and see A LOT of "/" characters then there is a good chance an attacker is attempting to exploit a well known apache bug. This bug which effects every version of apache before 1.3.20 and allows directory listings. If you see this in your logs someone is attempting to exploit you. (This fills up logs FAST)

만일 당신이 로그에서 수많은 / 문자들을 보게 된다면 공격자가 잘 알려진 아파치 버그를 익스플로잇하기 위해서 시도하고 있다는 것을 알 수 있는 좋은 기회이다. 1.3.20 이전의 아파치 버전이 영향을 받는 이 버그는 디렉토리 리스팅을 허용한다. 만일 당신의 로그에서 이것을 보게되면 당신을 익스플로잇 하기 위한 시도이다. (이것은 로그를 빠르게 채운다.)

Below is an example.

*http://host////////////////////////////////////////////////////////////////////////////////////////

The way this exploit works is the attacker runs a script that keeps adding a slash one at a time.
Eventually on an affected system the attacker will be able to gather file listings, among other things.

이 익스플로잇이 작업하는 방법은 공격자가 슬래쉬를 한번씩 추가하는 스크립트를 실행하는 것이다. 영향을 받는 시스템 상에서 실제로 공격자는 파일 리스트를 수집할 수 있다.

* Common files and directories an attacker will request.
* 공격자가 요청하는 일반 파일과 디렉토리.

"autoexec.bat"

This file is started by certain versions of windows every time at boot up.
Often times after an attacker has done what he wants with a box, he/she will install tools to remove logs and any reference to an intrusion taking place. An attacker may modify this file and insert commands into this file. Next time the machine is rebooted logs/traces can be wiped and the attacker is home free. People running a web server on windows 95 and 98 will be affected by this problem. You should only be running a public web server on NT/2000 with NTFS for security purposes if you plan on using a windows product.

이 파일은 윈도우즈의 특정버전에서 매번 부팅될 때마다 시작되어진다. 공격자가 원하는 것을 하나의 박스에서 공격한 후에 로그와 침입에 관한 어떤 흔적을 옮기기위해 툴을 인스톨 할 것이다. 공격자는 이 파일을 수정하고 이 파일에 명령을 삽입할 것이다. 다음 번에 머신이 재부팅되어지면 로그와 흔적은 깨끗이 지워지고 공격자는 집에서 영화 한편을 보고 있을 것이다. 윈도우즈 95와 98에서 웹 서버를 운영하고 있는 사람은 이 문제에 영향을 받을 것이다. 만일 윈도우즈 시스템을 사용해서 웹 서버를 운영할 계획이라면 보안 목적을 위한 NTFS상에서 NT/2000 시스템으로 웹 서버를 운영해야 한다.

"root.exe"

This is the backdoor left by Sadmin/IIS, Code Red, and Nimda worms. This backdoor is a copy of cmd.exe renamed to root.exe and put inside the webroot. If an attacker or worm has access to this file, you can bet your in trouble. Common directories this file resides in are "/scripts/" and "/MSADC/".

이것은 Sadmin/IIS, Code Red, Nimda 웜에 의해서 남겨진 백도어이다. 이 백도어는 cmd.exe 의 복사본을 root.exe로 리네임 시킨 후 웹루트 내부에 남겨 놓는다. 만일 공격자가 웜이 이 파일에 접근을 하게 되면 문제를 일으킬 수 있게 된다. 이 파일이 일반적으로 존재하는 디렉토리는 /scripts/ 그리고 /MSADC/ 이다.

"nobody.cgi 1.0 A free Perl script from VerySimple"

This is a cgi program, which was originally written to help provide admins with a shell backdoor. It also has a hefty warning by the programmer explaining the dangers of improperly using this program. This is now a popular backdoor used by attackers to execute commands with the permission of the webserver. You really would be surprised how often I see this popping up. Hanging in chat rooms I've seen 3 different occasions where people (unaware of each other) have used this script.
Oh and no I won't give you the link to this product.

이것은 CGI 프로그램이다. 이것은 원래 관리자에게 쉘 백도어를 제공하는 목적으로 만들어졌다. 부적절하게 이 프로그램을 사용하면 대단한 위험에 직면할 수 있는 경고를 가지고 있다(?) 이 프로그램은 공격자에 의해 웹서버의 권한으로 명령을 명령을 실행할 수 있는 인기있는 백도어이다. 내가 얼마나 자주 이것이 나타나는 것을 보았는지를 알게되면 놀랄 것이다. 채팅 룸에 있을 때 이 스크립트를 사용하는 3가지의 다른 경우를 보았다. 이 제품에 대한 링크는 제공하지 않을 것이다.

"[drive-letter]:WINNTsystem32LogFiles"

This is the directory that contains the IIS server logs. An attacker may
attempt to view your logs via a web application hole. If you see a reference
to system32/LogFiles there is a good chance your system is already taken over.

IIS 서버 로그들을 담고 있는 디렉토리이다. 공격자는 웹애플리케이션의 보안홀을 통해 당신의 로그를 보기 위한 시도를 할 수도 있다. 만일 당신이 system32/LogFiles에 대한 참조를 보게 된다면 당신의 시스템은 이미 탈취되어진 것이다.

"[drive-letter]:WINNTsystem32repair"

This is the directory that contains the backup password file on NT systems.
The file will either be named "sam._"(NT4) or "sam"(Win2k). If an attacker manages to get a hold of this file then you're in for some real trouble.

NT 시스템 상에서 백업 패스워드 파일을 포함하고 있는 디렉토리이다. 이 파일은 "sam._"(NT4) 또는 "sam"(Win2k) 로 명명 되어져 있다. 만일 공격자가 이 파일을 취득하기 위해서 조치를 취하게 된다면 당신은 실제 몇가지 문제에 당면하게 될 것이다. 

Novell File systems
"[server-name]:SYSTEM:PUBLIC"

This is an example Novell file system. It may be possible an advanced attacker with deep knowledge of Novell may try to view files remotely. Getting information such as the intranet server name may not be too easy on the other hand.

이것은 노벨 파일 시스템 상에서의 예이다. 노벨에 대한 고도의 지식을 가지고 있는 능력있는 해커는 리모트에서 파일을 보기 위해 시도할 가능성이 있다. 인트라넷 서버 이름같은 정보를 얻는 것은 그렇게 쉽지 않다.

IV.  Cross Site Scripting Examples

Cross site scripting attacks are often used by an attacker to make the user
think that certain information is actually coming from another site. These attacks are often used in scams, or when an attacker is trying to fool people into thinking certain things about companies in order to lower the price of the stocks, product prices, etc..  One problem with this attack type is that the attacker must have the user click on a link he provides in order to view this information. Sometimes an attacker will use other existing holes to make this process more believable. These attacks are very common and a lot of major sites are affected by this attack type in some way or another.

Below are a few examples of requests an attacker will use when trying to fool
a user.

Cross site scripting 공격은 사용자로 하여금 다른 사이트에 있는 특정 정보를 보도록 할 때 공격자에 의해서 사용된다. 이 공격은 주로 신용사기에 사용되어지거나 공격자가 회사의 특정 물건에 대해서 주식이나 제품등의 가격을 보다 낮게할 목적으로 시도되어진다. 이 공격 형태의 한가지 문제점은 공격자가 보여주기 위해서 제공하는 링크를 사용자가 클릭해야만 한다는 것이다. 공격자는 이것이 보다 믿음직스럽게 보이기 위해서 이미 존재하는 보안홀을 사용할 것이다. 이 공격은 매우 일반적인 것이다. 많은 메이저 사이트들은 이 공격의 형태에 영향을 받는다. 아래 예제는 공격자가 사용자를 바보로 만들때 사용하는 몇가지 요청에 대한 예제이다.

Example 1: The IMG tag

* http://host/search/search.cgi?query=<img%20src="http://host2/fake-article.jpg>

Depending on the website setup and if the search engine doesn't filter requests for html tags, this generates html with the image from host2 and feeds it to the user when they click on this link. Depending on the original web page layout it may be possible to fool a user into thinking this is a valid article.  One problem is the url above is very obvious and anyone with half a brain would notice something was wrong. This request could be encoded on the other hand so that when a user clicks on this link they do not get
suspicious. I posted an example in relation to perl.com a few months ago and even managed to fool a staff member at O'Reilly with this. (Only for like an hour though :)

웹사이트의 셋업상태와 검색 엔진이 html 태그들을 위한 요청을 필터링하지 않는지에 따라서 host2 에 있는 이미지를 갖고 있는 html을 생산한다. 그리고 이 링크를 클릭한 사용자에게 그것을 제공한다. 원본 웹페이지에 따라서 사용자가 이것을 유효한 문서라고 생각하게 하는 것이 가능할 수가 있다. 한가지 문제점은 위에 있는 URL이 매우 분명하다는 것이다. 그냥 그런 사람도 뭔가가 잘못되었다는 것을 알아차릴 것이다. 이 요청이 다른 방법으로 코딩된다면 사용자가 링크를 클릭할 때 전혀 의심을 하지 않을 것이다. 몇달 전 나는 perl.com에 관련된 예제를 보였다. 이것으로 O'Reilly에 있는 스탭을 속이는데 성공했다. (단지 한시간동안)

 

Example 2:

* http://host/something.php?q=<img%20src="javascript:something-wicked-this-way-comes>

If a user clicks on this link a JavaScript popup box displaying the sites domain name will appear. While this example isn't harmful, an attacker could create a falsified form or, perhaps create something that grabs information from the user. The request above is easily questionable to a standard user but with hex, unicode, or %u windows encoding a user could be fooled into thinking this is a valid site link.

만일 사용자가 이 링크를 클릭하게 된다면 사이트 도메인 네임이 나타나는 자바스크립트 팝업 박스가 표시될 것이다. 이 예제는 해롭지는 않지만 공격자는 거짓형태를 만들거나 사용자가 획득하는 정보에 무언가를 추가할 수 있을 것이다. 위에 요청은 표준 사용자들에게 쉽게 의심을 받을 것이다. 하지만 헥사코드, 유니코드 또는 %u 윈도우즈 코딩을 사용하는 사용자는 이것이 유효한 사이트 링크라고 생각하게 만들 수 있다.

Example 3:

* http://host/<script>Insert stuff here</script>

This particular request is very common example. About once a month I'll
see a new script that is affected by this. If you see something like this
in your logs, there is a good chance someone is testing your scripts out.

이 특별한 요청은 매우 일반적인 예이다. 약 한달에 한번 나는 이와 같은 형태의 새로운 스크립트를 본다. 만일 당신이 로그에서 이와 같은 것을 보게 된다면 누군가가 당신의 스크립트를 테스트하고 있다는 증거이다.

 

V. Modified Headers:

I recently wrote a paper on web statistical software and the types of exploitation that can happen via http header modification. I will use a few excerpts of this paper below to show you the types of fingerprints that exist for it.

나는 최근에 웹 통계 소프트웨어와 http 헤더 변조를 통해 발생할 수 있는 익스플로잇 형태에 관한 문서를 작성했다. 나는 이 문서에서 몇개를 발췌해서 사용할 것이다. 아래 문서는 그 문서에 존재하는 몇 가지 징후의 형태를 보여줄 것이다.

This paper can be found here

* Http://www.cgisecurity.com/papers/header-based-exploitation.txt

 

Below is a review of some things to look for in your logs.
아래에서 당신의 로그에서 조사한 몇가지 것을 평가해보자.

x.x.x.x - - [10/Dec/2001:09:03:39 -0500] "GET / HTTP/1.1" 200 10453 "http://www.cgisecurity.com" "Mozilla/4.0
(compatible; MSIE 5.5; Windows NT 5.0; T312461)"

We are going to look at  the 11th and 12th field in this log.
우리는 이 로그에서 11번째와 12번째에 있는 것을 알아볼 것이다.

11th "http://www.cgisecurity.com"   Referrer Field
12th "Mozilla/4.0"                  User Agent Field

These fields are filled in by your browser automatically. If I had a link on
www.hosta.com that pointed to my site and clicked on it, then my browser would save this information and forward it to my website. This information is known as the referrer field. The referrer field is filled in by your browser automatically, which means this information is provided by the client, and
not the server. This means this information is "user input". Since this information is user input this means we can change it to whatever we want.

The threat in this is that certain types of software gather the values from your logs and display them out. (Example Web Stats Software) Some software doesn't do stripping of metacharacters very well and because of this code insertion is possible.

이 필드들은 당신의 브라우저에 의해서 자동으로 채워진다. 만일 내가 내 사이트를 지시하는 www.hosta.com 링크를 가지고 있고 그것을 클릭했다면 내 브라우저는 이 정보를 저장하고 그것을 나의 웹 사이트로 포워드 할 것이다. 이 정보는 레퍼러 필드로 알려져 있다. 레퍼러 필드는 당신의 브라우저에 의해 자동적으로 채워진다. 즉 이정보는 서버가 아니라 클라이언트에 의해서 제공되어진다는 것이다. 이 정보는 사용자의 입력이라는 것을 의미한다. 비록 이 정보가 사용자 입력이기 때문에 우리는 원한다면 언제라도 이것을 변경할 수가 있다.

이것이 취급하는 것은 로그로부터 값을 수집하는 소프트웨어이다. (예를 들면 웹 통계 소프트웨어) 어떤 소프트웨어는 메타문자를 구별해 내지 못하기 때문에 이 코드의 삽입은 가능하다.

Example 1:

su-2.05# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0
Referer: <!--#virtual include="somefile.log"-->   (Yes Referrer is spelt wrong)
User-Agent: <!--#exec cmd="/bin/id"-->

"In this example the attacker is inserting SSI tags into the "Referrer" and User-Agent fields. Depending on whether the software outputs this information as text or in image form, this could lead to possible file includes, or command execution. (Of course these examples could be interchangeable) If the logs are shown as text and displayed in a shtml file, and the referrer, or user agent fields are shown (Most of the time they are), then these two
requests will be included in the file. Now next time a visitor views these logs, the SSI tags will be executed by the web server, and should display the results of the "id" command, and the contents of "somefile.log".(Once again depending on server configuration)"

이 예제에서 공격자는 "Referrer" 와 User-Agent 필드에 SSI 태그를 삽입하고 있다. 소프트웨어가 텍스트나 이미지 폼으로 출력하느냐에 따라서 파일 삽입이나 명령 실행을 가능하게 할 것이다. (물론 이 예제는 변경 가능하다) 만일 텍스트로 보여지고 shtml 파일 안에 디스플레이 되고 Referrer 또는 user agent 필드가 보여진다면 (대부분의 경우 그렇게 한다) 이 두 요청은 파일 안에 포함되어 질 것이다. 그리고 id 명령의 결과와 somefile.log 내용을 표시할 것이다.(한번더 서버 설정에 따라서)

- * Http://www.cgisecurity.com/papers/header-based-exploitation.txt

If for any reason you find a request like this in your logs, then it may
be possible someone is trying to exploit you.

Below is another example from my previous paper.

어떤 이유에서건 당신이 이와 같은 요청을 당신의 로그에서 발견한다면 누군가가 당신을 익스플로잇 하고 있을 가능성이 크다.

Example 2:

su-2.05# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0
Referer: <javascript-that-is-evil-so-there's-no-need-for-examples>
User-Agent: </html>

"If a user visits this stats page and the referrer is outputted then it may
be possible to steal users cookies. " It is suggested that you check this field in your apache logs regularly, if you feel that you run software which may be at risk.

만일 사용자가 이 통계 페이지를 방문하고 Referer가 출력되어진다면 사용자 쿠키들을 훔칠 가능성이 있다. 만일 위험성이 있는 소프트웨어를 운영하고 있다면 당신은 아파치 로그에서 규칙적으로 이 필드를 검사해 보기 바란다.

There is a good tool that can modify http headers called "Websleuth" that
is worth checking out.

체크해볼 만한 충분한 가치가 있는 Websleuth 라고 불리우는 http 헤더를 수정할 수 있는 훌륭한 툴이 있다.

VI. More Encoding:

This chapter covers common encoding methods an attacker or worm may use
to help avoid detection. Hex, Unicode, and windows %u encoding is covered.
This isn't a "how to" section, rather something that may help explain what
you may run into in your logs.

이번 장은 공격자나 웜이 발견되어지는 것을 회피하기위해 사용하는 일반적인 코딩 방법들에 대해서 다루고 있다. 헥사코드, 유니코드 그리고 윈도우즈 %u코드를 다룬다. 또한 여기는 어떻게 할 것인가가 아닌 당신의 로그안에 있는 것에 대한 것을 이해 하는데 도움을 주는 사항들이 포함될 것이다.

A. Hex Encoding:

Example: %xx

Below are the hex values of some of the characters mentioned in the last paper.
If you see these characters in any log file there is a good chance an attacker
is trying to mask his requests, or even trying to get around an IDS product.

Encoded characters mentioned in last paper/this paper.

아래에 있는 헥사값들은 이전 문서에서 언급하고 있는 몇몇 문자에 관한 것이다. 만일 당신이 로그파일에서 이들 문자들을 보게 된다면 공격자가 그의 요청을 숨기기를 시도하거나 IDS 제품을 회피하기를 시도하고 있는 것이다.

%2e  = .  (Example: .. requests)
%3e  = >  (Example: Html/Javascript/SSI insertion. Mentioned in last paper)
%3c  = <  (Example: Html/Javascript/SSI insertion. Mentioned in last paper)
%2a  = *  (Examples Listed in chapter 2 of this paper)
%2b  =   (Example: cmd.exe backdoor request. Also used as space)
%60  = `  (Examples Command execution. Mentioned in last paper)
%21  = !  (Example: SSI insertion. Mentioned in last paper)
%7c  = |  (Example: Command execution. Mentioned in last paper)
%3b  = ;  (Example: Command execution. Mentioned in last paper)
%7e  = ~  (Examples Listed in chapter2 of this paper)
%3f  = ?  (Example: Php/Mentioned in last paper)
%5c  =   (Example: Possible Encoded Windows Directory Transversal Attempt)
%2f  = /  (Example: Possible Encoded Unix Directory Transversal Attempt)
%7b  = {  (Example: Possible trojan/backdoor upload attempt, possible command argument)
%7d  = }  (Example: Possible trojan/backdoor upload attempt, possible command argument)
%28  = (  (Example: Possible Cross Site Scripting attempt)
%29  = )  (Example: Possible Cross Site Scripting attempt)
%5b  = [  (Example: Possible trojan/backdoor upload attempt, possible command argument)
%5d  = ]  (Example: Possible trojan/backdoor upload attempt, possible command argument)
%5e  = ^  (Example: Possible trojan/backdoor upload attempt, possible command argument)

For a complete list of characters in Unix type "man ascii" and a list will be provided.
Below is what An example of directory transversal would look like while trying to fetch the server's password file.

유닉스 상에서 문자들의 완벽한 리스트는 "man ascii" 명령을 실행함으로써 얻을 수 있다. 아래 예제는 디릭토리를 변경해서 서버의 패스워드 파일을 조작하기 위한 시도이다.

Example 1 :

* http://host/script.ext?template=%2e%2e%2f%2e%2e%2f%2e%2e%2f%65%74%63%2f%70%61%73%73%77%64

This request is made up of:

1. %2e%2e%2f%2e%2e%2f%2e%2e%2f = ../../../

2. %65%74%63 = etc

3. %2f = /

4. %70%61%73%73%77%64 = passwd

Combinations of this will probably be used to help further fool your IDS product.
Tools like rain.forrest.puppies "Whisker" use these techniques to avoid detection.

이것의 조합은 IDS제품을 회피하기 위해 아마도 사용되어 질 것이다. rain.forrest.puppies의 "Whisker" 같은 툴은 발견되어지는 것을 회피하기 위해서 이 테크닉을 사용한다.

B. Unicode Encoding:

Example: %xx%xx

This type of encoding by now, has been heard about by most people who deal with security.
The famous IIS exploit that used this encoding method is an example of what a Unicode request looks like.

보안을 취급하는 대부분의 사람들은 이와같은 형태의 코딩에 대해서 들어보았을 것이다. 이러한 코딩형태를 사용하는 유명한 IIS 익스플로잇은 유니코드 요청이 보여주는 예이다.

* http://127.0.0.1/scripts/..%c0%af../winnt/system32/cmd.exe?&/c&dir&c:

I'm not going to get into this encoding method much before plenty of documentation already exists. For additional information about unicode Read "RFC 2279" and the link below.

이미 수많은 문서들이 존재하기 때문에 이 코딩 방법을 다루지는 않겠다. 유니코드에 관한 추가적인 정보는 "RFC 2279"를 읽어보시면 될 것이다.

http://www.ietf.org/rfc/rfc2279.txt

C. "%u" Encoded Requests:

Example: %uxxxx

This is a type of encoding used by the Microsoft IIS web server. Through the use of this Microsoft specific encoding method, an attacker can possibly evade IDS products. Below is an example of what a worm or attacker may send to a vulnerable system with and without %u encoding.

MS IIS 웹서버는 이러한 형태의 인코딩을 사용한다. MS의 이러한 특징적인 코딩방법을 통해서 공격자는 IDS 제품을 회피할 가능성이 있다. 다음은 웜이나 공격자가 %u 코딩방법을 사용하거나 사용하지 않고 취약 시스템에 보내는 것에 대한 예제이다.

* http://host/lame.asp?asp=a.txt

This request is attempting to read the file "a.txt" using lame.asp.
이 요청은 lame.asp를 사용해서 a.txt 파일 읽기를 시도하고 있다.

* http://host/lame.asp?asp=%u0061.txt

This request does the same thing using "%u" Microsoft encoding. While this may still draw attention when you view the logs manually, an IDS product may miss this request, and allow the attacker to continue his fun unnoticed. This type of encoding can also be used in conjunction with normal ASCII characters, and
because of this alone, some IDS products will not detect such a request.

이 요청은 %u를 사용한 MS 코딩방법으로 위와 같다. 역시 같은 시도를 하고 있다. IDS제품이 이와 같은 요청을 놓칠 가능성이 역시 존재한다. 그런 일이 발생한다면 공격자에게 그의 작업을 계속하도록 할 것이다. 이러한 코딩 형태는 일반 ASCII 문자들을 결합하는데 사용되어질 수 있다. 어떤 IDS 제품은 이러한 요청을 발견하지 못한다.

Visit the link below for further information on this encoding method.
이 인코딩 방법에 대한 더 많은 정보를 획득하기 위해서 다음 링크를 방문해 보기 바란다.
http://www.eeye.com/html/Research/Advisories/AD20010705.html

 

VII. Web server Codes and Logging:

Often times when an attacker is trying to exploit your web application it will
cause your software to produce error messages both seen, and unseen by the attacker.
This section will cover the types of error messages that will show up in your logs, and what they may mean. This section covers basic logging and is meant more for newbie's. Skip ahead if you already have a good grasp on logging to the next chapter.

공격자가 당신의 웹 애플리케이션을 익스플로잇 시도할 때 당신의 소프트웨어는 공격자에게 보여지거나 보여지지 않는 에러 메시지를 생산한다. 이 부분은 당신의 로그상에 나타나는 에러 메시지의 형태들에 대해서 다룰 것이다. 이 부분은 기본적인 로그인 과정을 다루고 초보자들에게 더 의미가 있는 것들을 다룰 것이다. 만일 당신이 로그인 과정에 대한 충분한 이해가 되어있다면 다음 장으로

403 Denied Errors

This particular error happens when you have a file that is not marked world readable. Sometimes the webmaster can make a mistake and accidentally forget to chmod a file readable. A lot of the time when a file is marked not world readable (Example a password file), and someone requests it through your website this is an alarm to either move the file, and examine your logs further.

이 특별한 에러는 당신이 모두가 읽을 수는 없는 파일을 가지고 있을 때 나타난다. 웹마스터는 chmod 명령으로 파일을 읽기 가능하게 변경하는 것을 잊어 버리는 실수를 할 수가 있다. 많은 경우 파일은 모두가 읽지는 못하게 표시되어져 있을 때 (예를 들어 패스워드 파일) 어떤이가 당신의 웹사이트에 있는 그 파일을 요청한다. 이것은 파일을 옮기기 위한 시도일 수도 있다. 당신의 로그를 좀더 자세히 조사해 보라.

[Wed Feb 20 10:23:33 2002] [error] [client 192.168.1.1] (13)Permission denied: file permissions deny server access:
/some/path/htdocs/secret/apache-unreleased-overflow.c

(Message as it would appear in your error_log)

                                                                                                 |-- 403 Code
192.168.1.1 - - [20/Feb/2002:10:23:33 -0500] "GET /secret/apache-unreleased-overflow.c HTTP/1.0" 403 206

(Message as it would appear in your access_log)

404 Not Found errors

When running a large website or even a medium sized one, people may start linking to material on your website directly from another site. As time goes by sometimes things get moved around a bit and these old references to files are no longer valid. You may see such a reference in your access_log or easier to see error_log file. Sometimes these requests for invalid, or obsolete
files can let you know if you've renamed a file to the incorrect name, or that someone is poking around. IDS systems would not pick up the majority of 404 error because they aren't considered an immediate threat.  Picking up on 404 codes would be a nightmare because 404 codes are a normal issue websites deal with and are 99.99 percent of the time not attacks/probes at all.  Instead
IDS software tends to match signatures of filenames, some of which I will mention below.

대형이나 중형의 웹사이트를 운영할 때 사람들은 다른 사이트로부터 곧장 당신 웹사이트에 있는 어떤 것으로 링킹을 시도하기도 한다. 시간이 지나도 이동되지 않을 때 파일에 대한 이 오래된 참조는 더이상 유효하지 않는 것이다. 이러한 경우 당신은  access_log 상에서 이러한 참조를 볼 수 있거나 보다 쉽게 error_log 파일에서 볼 수 있을 것이다. 유효하지 않거나 불명확한 파일에 대한 요청은 당신이 파일명을 변경했거나 잘못된 이름을 지정했다는 것을 알 수 있게 할 것이다. IDS 시스템들은 404 에러의 대부분을 추출하지 않는다. 왜냐하면 즉각적인 조치를 필요하는 것으로 간주하지 않기 때문이다. 404 코드에서 추출한 것은 쓸데 없는 일이다. 404 코드는웹 사이트가 취급하고 있는 일상적인 일이기 때문이다. 99.99% 의 시간동안 웹사이들은 공격이나 조사되어질 필요가 전혀 없다. 대신에 IDS 소프트웨어가 파일이름들의 기호 일치시키고 아래에 언급하는 것들을 하는 경향이 있다.

This below log entry is from a person scanning my site looking for the popular formail cgi script.
Formail is known to have multiple security issues, and just recently it has been found to be widely used by spammers to send people unwanted email.

아래에 있는 로그는 유명한 formail cgi 스크립트를 찾기 위해서 내 사이트를 스캐닝하고 있는 것이다. formail 이 다양한 보안 이슈들을 가지고 있다는 것은 잘 알려져 있다. 최근에서 사람들은 원치 않는 메일을 보내는 스팸어의 의해서 사용되어지는 것이 발견되어지기도 했다.

[Web Feb 20 10:30:42 2002] [error] [client 192.168.2.2] script not found or unable to stat: /usr/local/apache/cgi-bin/formail.pl

(Message as it would appear in your error_log.)

                                                                                |-- 404 Code
192.168.2.2 - - [20/Feb/2002:10:30:42 -0500] "GET /cgi-bin/formail.pl HTTP/1.0" 404 3683 "-" "Mozilla/4.78 [en] (Win98; U)""Mozilla/4.78 [en] (Win98; U)"
(Message as it would appear in your access_log)

This can be an alert that someone is scanning your machine, or subnet for holes. Obviously just because a 404 is triggered in your logs this doesn't mean your under attack. Carefully study your logs for common files that may be mislinked, and also check for anything out of the ordinary.

이것은 당신의 머신이나 서브넷이 스캔당하고 있다는 경고이다. 분명히 404는 당신의 로그상에 나타나기 때문에 이것이 공격을 받고 있다는 것을 의미하지는 않는다. 잘못링크된 일상적인 파일들을 위해 당신 로그를 조사해 보고 일장적이지 않는 것들은 조사해 보기 바란다.

Below is another example this time requesting a backdoor left by the Nimda, and well known
아래 예제는 Nimda, Code Red 웜이 남겨놓은 백도어를 요청하는 예제이다.

Code red worm.

[Tue Dec 18 05:11:04 2001] [error] [client 192.168.3.3] File does not exist: /usr/local/apache/htdocs/MSADC/root.exe
(Message as it would appear in your error_log)

                                                                                   |--- 404 code

192.168.3.3 - - [18/Dec/2001:05:11:04 &0000] "GET /MSADC/root.exe?/c&dir HTTP/1.0" 404 3147
(Message as it would appear in your access_log)

Often times people scan for these files hoping to get an easily backdoored machine. From here they would have complete control of your IIS machine.

500 Server Error

Sometimes when an attacker is testing out software for command execution, or remote file read abilities they will insert characters (Like mentioned above) to help achieve this goal. Sometimes scripts will not handle this additional data insertion well and instead terminate abnormally. This will show up in your logs as a server error (500 code). Not all 500 codes mean an attacker is scanning you. Often times users who upload scripts, which are not configured correctly for this particular system , can give this error.

공격자가 명령실행이나 리모트 파일 읽기 능력을 위한 소프트웨어를 테스트할 때 그들은 문서에 이러한 목표에 도움을 주기 위해서 문자를 삽입한다. 때때로 스크립트는 이런 추가적인 데이터 삽입을 처리하지 못할 것이고 대신에 비정상적으로 종료하게 된다. 이때 로그상에 서버 에러 (500 코드) 같은 것이 보인다. 500 에러가 전적으로 공격자가 당신을 스캔하고 있다는 것을 의미하지는 않는다. 특정 시스템을 잘못된 설정으로 유도하는 스크립트를 업로드하는 사용자는 이 에러를 줄 수 있다.

Below is an example

                                                                                |--- 500 Code
192.168.4.4 - - [18/Dec/2001:05:11:04 &0000] "GET /cgi-bin/port80.cgi HTTP/1.0" 500 529 "-" "Mozilla/4.78 [en] (Win98; U)"

(access_log)

[Thu Dec 13 15:30:23 2001] [error] [client 192.168.4.4] Premature end of script headers:
/usr/local/apache/cgi-bin/port80.cgi

(error_log)

Depending on what exactly the attacker is attempting to do, will determine exactly what the reason will be in your error_log.

공격자가 시도하고 있는 것이 무엇인지에 따라서 error_log 내에 일어나는 이유가 무엇인지가 결정될 것이다.

Htaccess error codes

Not all error messages are attacks against your system. Often times it could
be as simple as a user using the wrong username, or password. Sometimes on the
otherhand attackers will run a program like "WWWhack" to brute force your password to gain entry to protected area's. Below is an example

모든 에러메시지가 당신의 시스템을 공격하고 있다는 것을 표시하지는 않는다. 사용자가 잘못된 사용자이름이나 패스워드를 사용하기 때문일 수도 있는 것이다. 공격자는 보호된 지역에 접근하기 위해서 당신의 패스워드를 크랙하기 위해서 WWWhack 같은 프로그램을 실행할 것이다.

192.168.5.5 - miked [30/Jan/2002:13:37:26 -0500] "GET /secret HTTP/1.0" 401 397 "-" "Mozilla/4.78 [en]C-CCK-MCD snapN45b1  (Win98; U)"

(Message as it would appear in your access_log)

[Wed Jan 30 13:37:26 2002] [error] [client 192.168.5.5] user miked: authentication failure for "/secret": password mismatch

(Message as it would appear in your error_log)

This shows a failed login attempt by 192.158.5.5 trying the username of miked.  If for any reason you see a lot of failed requested from the same ip address, then there is a good chance someone is trying to brute force your password protection.  Between 1-40 may be just a user who forgot his password. Another hint that someone is attempting is breaking is if 1 ip address is trying to attempt to login with non existent accounts, or trying to use
multiple usernames.

유저네임이 miked 인 사용자(192.168.5.5)에 의한 로그인이 실패했다는 것이다. 만일 당신이 동일 IP로부터의 수많은 로그인 실패를 본다면 누군가가가 패스워드 브루트 포스 공격을 감행하고 있다는 신호이다. 자신의 패스워를 잃어버린 사람은 1~4회를 시도한다. 만일 1 IP 주소가 존재하지 않는 계정에 대한 접속을 시도하거나 여러 사용자 이름으로 접속을 시도한다면 누군가가 패스워드 크래팅을 하고 있다는 신호가 될 것이다.

A complete list of error codes can be found at the link below.
완벽한 에러코드에 관한 리스트는 아래 링크에서.
http://www.w3.org/Protocols/HTTP/HTRESP.html

Extended logging options with apache

Apache has a module that is used for logging called "mod_log_config". This module allows an administrator the ability to choose which format his data is logged in. It also allows the administrator to choose which headers are logged. Sometimes new types of attacks get published that use extended HTTP headers. (Examples: Content-Encoding, Host, Etag, Content-MD5, Warning, WWW-Authenticate, etc...) By default apache does not log these fields. The "LogFormat" Directive gives the administrator the ability to choose what is logged and what isn't. This can be particularly useful