'SecRule'에 해당되는 글 2건

  1. 2014.09.25 Bash Vulnerability Code Injection Attack
  2. 2010.01.11 modsecurity php 업로드 제한설정
2014.09.25 14:42

Bash Vulnerability Code Injection Attack


bash_ld_preload.c

#include <sys/types.h>
#include <stdlib.h>
#include <string.h>

static void __attribute__ ((constructor)) strip_env(void);
extern char **environ;

static void strip_env()
{
	char *p,*c;
	int i = 0;
	for (p = environ[i]; p!=NULL;i++ ) {
		c = strstr(p,"=() {");
		if (c != NULL) {
			*(c+2) = '\0';
		}
		p = environ[i];
	} 

}


  • Compile it:
gcc bash_ld_preload.c -fPIC -shared -Wl,-soname,bash_ld_preload.so.1 -o bash_ld_preload.so
  • Copy bash_ld_preload.so to /lib:
cp bash_ld_preload.so /lib/

If you wish to apply this workaround across the entire system:

  • Add the following to /etc/ld.so.preload on a line by itself:
/lib/bash_ld_preload.so
  • Restart all relevant services or reboot the system.

Note that this is potentially very dangerous. It is recommend that you just apply this workaround to specific services that may be exploitable on your system. This can be achieved by adding bash_ld_preload.so to the LD_PRELOAD environment variable in the script that will initialize the service. For example, for httpd on Red Hat Enterprise Linux 6:

  • Add the following two lines at the top of /etc/init.d/httpd, after the #! line:
LD_PRELOAD=/lib/bash_ld_preload.so
export LD_PRELOAD
  • Then restart httpd:
service httpd restart


Workaround: Using mod_security:

The following mod_security rules can be used to reject HTTP requests containing data that may be interpreted by Bash as function definition if set in its environment. They can be used to block attacks against web services, such as attacks against CGI applications outlined above.

Request Header values:

SecRule REQUEST_HEADERS "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

SERVER_PROTOCOL values:

SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST names:

SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST values:

SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

File names for uploads:

SecRule  FILES_NAMES "^\(\) {"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'"

These may result in false positives but it's unlikely, and they can log them and keep an eye on it. You may also want to avoid logging as this could result in a significant amount of log files.

Workaround: Using IPTables:

A note on using IPTables string matching:

iptables using -m string --hex-string '|28 29 20 7B|'

Is not a good option because the attacker can easily send one or two characters per packet and avoid this signature easily. However, it may provide an overview of automated attempts at exploiting this vulnerability.


$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

 vulnerable

 this is a test


$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

 bash: warning: x: ignoring function definition attempt

 bash: error importing function definition for `x'

 this is a test




출처 : access.redhat.com




Trackback 0 Comment 0
2010.01.11 19:25

modsecurity php 업로드 제한설정

작성자 : 홍석범

확장자로 필터링할 수 있는 방법도 있겠지만 실제로 공격자 입장에서는 이를 우회할 수 있는 방법이 매우 많이 있습니다. 실제로 double extension이나 .txt 또는 .gif 등의 확장자를 사용하지만 실제 php코드인 경우가 매우 많이 있습니다.

따라서 단순 확장자 필터링 방법보다는 이 방법이 어떨까 합니다.

SecRule FILES_TMPNAMES "@inspectFile /usr/local/sbin/chk_upload.sh"
"log,auditlog,deny,status:403,phase:2"

와 같이 지정한 후 해당 쉘스크립트(chk_upload.sh)에서는 파일의 콘텐츠에
"<%" 나  "<?"  또는 특정 문자열과 같은 스크립트 문자열이 들어가면 차단하도록 하는 것이 더 좋을 듯 합니다.

또한 후탐지이기는 하지만,

SecUploadDir /path/to/tmp
SecUploadKeepFiles On

를 하여 업로드되는 파일들에 대해 특정 디렉토리에 모이도록 한 후 정기적으로(이를테면 매 1시간마다) file 등의 명령어로 실행하여 아래와 같이 script로 보이면 삭제하거나 알람하도록 하는 것도 좋을 듯 합니다.

$ file image.gif
image.gif: PHP script text


출처 : http://www.linux.co.kr

Trackback 0 Comment 0