꿈 꾸는 사람

http://www.fitsec.com/blog/index.php/2012/02/19/new-piece-of-malicious-code-infecting-routers-and-iptvs/

http://www.symantec.com/security_response/earthlink_writeup.jsp?docid=2014-120115-3009-99

http://www.exploit-db.com/wp-content/themes/exploit/docs/26472.pdf

http://www.theregister.co.uk/2014/09/09/linux_modem_bot/

http://protectyournet.blogspot.kr/2013_08_01_archive.html

http://vierko.org/tech/lightaidra-0x2012/

Lightaidra는 2012년부터 시작됐나 보다. IRC 통신을 토대로 취약한 장비들을 스캔하고, 직접 IRC 명령을 받아 공격 수행도 한다. 그 대상 Platform이 다양 하기 때문에 (mips, mipse, arm,ppc, x86/x86-64, superh) 다양한 리눅스 기반 디바이스들이 타겟이 될 수 잇다. AP, Model, VOIP Device, IPTV, IP Camera, 스마트 폰 등이 그 대상이다. 

위 링크에서는 주로 Linux 장비 중 Telnet + 기본 패스워드 / 패스워드 없는 장비를 대상으로 한다고 한다. Telnet 이용을 하지만, D-Link, Netgear의 오래된 firmware를 대상으로는 /cgi-bin/firmwarecfg의 버그를 이용하여 장비의 계정을 탈취하기도 한다. (http://yae.prv.pl/adam-cou14/access-d-link-router.html)

현재까지 확인된 악성 코드에도 취약 firmwarecfg 이용하여 HTTP Request 관련 로직이 보이는 것으로 봐서는 아직까지도 이용되고 있는 듯 하며, 그러나 주 공격 루틴은 대상 호스트의 Telnet 취약 계정을 이용할 것으로 예상된다.

으흠..

Checksum은 network를 통해 패킷을 송/수신하는 중에 헤더나 데이터가 손상되지 않았다는 것을 보증하기 위해 사용된다. 

프로토콜에 상관없이 Checksum을 계산하는 알고리즘은 동일하지만 Checksum이 보증하는 필드가 각각 다르다. 

_____________________________________________________________________________

IP : IP Header 

ICMP : ICMP Header + Data

TCP : TCP Header + Data + TCP Psuedo 헤더

UDP : UDP Header + Data + UDP Psuedo 헤더

_____________________________________________________________________________

IP Checksum은 IP Header만을 보증하며 IP가 전달하는 데이터에 대해서는 보장하지 않는다. 

IPv6에서는 IP Header에서 Checksum이 수행되지 않으며 IPv4에서도 데이터의 보증은 TCP, UDP가 수행한다.

TCP/IP 프로토콜에서 Checksum 계산에 1의 보수 표현을 사용 (계산 처리의 효율성이 2의 보수보다 높다)

[출처 : forgetnotme.tistory.com/6]

UDP Checksum에서 간혹 Checksum 값이 0x0000으로 전송되는 경우가 있는데 이는 RFC768에서 아래와 같이 설명이 되고 있다.

즉, 전송을 시도하는 측에서 checksum을 계산하지 않은 체 보냈다는 의미이며 checksum 계산에 신경 쓰지 않는 상위 프로토콜들을 위해서 혹은 debugging의 효율을 위해 0으로 채워서 보낸다고 한다.

따라서, Checksum이 0x0000로 보내진다해서 모두 ChecksumError로 보기 힘들다고 판단된다.

[출처 : https://www.ietf.org/rfc/rfc768.txt]

[출처 : http://www.packetinside.com/2010/03/%ED%97%A4%EB%8D%94-%EC%B2%B4%ED%81%AC%EC%84%AC-%EC%98%A4%EB%A5%98-header-checksum-0x0000.html]

GNU Bash에서 환경 변수를 처리하는 과정에서 취약점이 확인되었으며 공격자는 Bash 환경 변수를 이용할 수 있는 대상 서버의 Application을 통해 쉘 명령어를 실행시킬 수 있다. (Bash는 기본적으로 원격의 사용자에게 쉘을 제공해주기 위해 다양한 프로그램들을 제공해주며 CGI Script (Apache, etc) 들을 제공해주거나 제한적 명령어를 사용할 수 있는 프로그램을 제공해준다.) 

취약점은 정확하게 환경 변수를 파싱하지 못해서 발생하는 것으로 환경 변수가 "() {" 문자열로 시작할 경우 Bash는 정의된 initialize_shell_variables()를 호출하게 된다. 해당 함수는 환경 변수가 "() {"로 시작함에 따라 함수로 정의하는 것으로 인식하며, 이후 함수로 정의(define)하기 위해 이후의 문자열을 parse_and_execute() 함수로 전달한다.

  [그림1. variables.c 중 initialize_shell_variables() 함수 코드]

parse_and_execute() 함수를 살펴보면 취약한 핵심 내용을 확인할 수 있다. 그것은 이 함수가 함수 정의 내용이 끝났음에도 불구하고 함수의 실행을 멈추지 않고, 이후에 있는 문자열의 실행을 하는 것이고, 이 중 명령어가 있을 경우 공격자의 의도된 명령에 따라 명령어가 실행된다.

아래 parse_and_execute() 함수의 일부를 살펴보면 while 반복 문을 통해 환경 변수에 전달된 문자열을 while() 함수를 통해 끝날 때까지 반복하며 수행하도록 되어 있다. 함수일 경우, 해당 함수가 끝나는 부분을 체크하여 반복 문을 멈춰야하지만 이에 대한 조건 (if) 이 존재하지 않아 이후 문자열을 그대로 수행하게 된다.

[그림2. evalstring.c 중 parse_and_execute() 함수 내용, 명령을 파싱하고 실행]

취약한 장비인지 확인하는 명령어는 아래와 같다.

[그림3. 취약 장비 확인]

또한 원격에서 아래와 같이 curl 명령어로 공격을 수행할 수 있다. (단, 사전에 공격 대상 서버의 취약한 cgi가 설치돼있어야 한다.)

이 외에 파이썬으로 작성된 소스, Malzilla와 같은 HTTP Header 조작 Tool 등으로 공격이 가능하다.

이에 대한 공격은 주로 HTTP Header에 포함되어 공격이 시도되나 URI 부분에도 포함되어 공격 수행이 되고 있다.