셸코드

Shellcode

해킹에서 셸 코드는 소프트웨어의 취약성악용할 때 페이로드로 사용되는 작은 코드 조각입니다.일반적으로 공격자가 손상된 머신을 제어할 수 있는 명령 셸을 시작하지만 유사한 작업을 수행하는 모든 코드 조각을 셸 코드라고 할 수 있기 때문에 셸 코드라고 합니다.payload의 기능은 단순히 셸을 산란하는 데 국한되지 않기 때문에 셸 코드라는 이름이 [1]불충분하다는 의견이 있습니다.그러나 이 용어를 대체하려는 시도는 널리 받아들여지지 않았다.셸 코드는 일반적으로 기계 코드로 작성됩니다.

셸 코드를 작성할 때는 일반적으로 소형으로 하고 실행 가능한 것으로 하는 것이 좋습니다.이를 통해 가능한 [2]한 다양한 상황에서 셸 코드를 사용할 수 있습니다.좋은 셸코드를 쓰는 것은 [3]과학만큼이나 예술일 수 있다.어셈블리 코드에서는, 같은 함수를 다양한 방법으로 실행할 수 있고, 이러한 목적을 위해서 사용할 수 있는 opcode의 길이에 어느 정도 차이가 있습니다.좋은 셸 코드 라이터는 이러한 작은 opcode를 사용하여 보다 콤팩트한 셸 [4]코드를 작성할 수 있습니다.일부는 [5]안정성을 유지하면서 가능한 한 작은 크기에 도달했습니다.

셸 코드의 종류

셸 코드는 로컬 또는 리모트하나로, 공격자가 셸 코드를 실행하는 머신(로컬)을 제어할 수 있는지, 아니면 네트워크를 통해 다른 머신(리모트)을 통해 제어할 수 있는지에 따라 달라집니다.

현지의

로컬 셸 코드는 머신에 대한 액세스가 제한되지만 버퍼 오버플로 등의 취약성을 악용할 수 있는 공격자가 해당 머신에서 더 높은 권한을 가진 프로세스에서 사용합니다.정상적으로 실행되면 셸 코드를 통해 공격자가 대상 프로세스와 동일한 높은 권한을 가진 머신에 액세스할 수 있습니다.

원격의

원격 셸 코드는 공격자가 로컬 네트워크, 인트라넷 또는 원격 네트워크의 다른 시스템에서 실행되는 취약한 프로세스를 대상으로 할 때 사용됩니다.정상적으로 실행되면 셸 코드를 통해 공격자가 네트워크를 통해 타깃머신에 액세스 할 수 있습니다.원격 셸 코드는 일반적으로 표준 TCP/IP 소켓 연결을 사용하여 공격자가 대상 시스템의 셸에 액세스할 수 있도록 합니다.이러한 셸 코드는 이 연결 설정 방법에 따라 분류할 수 있습니다. 셸 코드가 연결을 확립하는 경우 셸 코드가 공격자의 머신에 다시 연결되기 때문에 "리버스 셸" 또는 연결-백 셸 코드라고 합니다.한편 공격자가 연결을 설정하면 셸 코드가 공격 대상자의 시스템의 특정 포트에 바인딩되기 때문에 셸 코드를 바인드셸이라고 합니다.바인딩 부분을 건너뛰고 운영 체제에서 사용할 수 있는 랜덤 포트로 수신하는 bindshell random port라는 고유한 셸 코드가 있습니다. 때문에 bindshell 랜덤포트는 지금까지 사용 가능한x86_64의 가장 작고 안정적인 bindshell shell 코드가 되었습니다.세 번째 타입은 소켓 재사용 셸 코드입니다.이러한 유형의 셸 코드는 악용으로 인해 셸 코드가 실행되기 전에 닫히지 않은 취약한 프로세스에 대한 연결이 확립될 때 사용되는 경우가 있습니다.그러면 셸 코드는 이 연결을 다시 사용하여 공격자와 통신할 수 있습니다.셸 코드를 사용하는 소켓은 더 정교합니다. 왜냐하면 셸 코드는 재사용할 연결을 찾아야 하고 기계는 많은 연결을 [6]열 수 있기 때문입니다.

방화벽을 사용하면 connect-back 셸 코드에 의해 확립된 발신 접속과 바인드셸에 의해 확립된 착신 접속을 검출할 수 있습니다.따라서 시스템이 취약하더라도 공격자가 셸 코드에 의해 작성된 셸에 접속하지 못하도록 함으로써 공격자에 대한 보호를 제공할 수 있습니다.이것이 소켓 재사용 셸 코드가 사용되는 이유 중 하나입니다.새로운 접속이 생성되지 않기 때문에 검출 및 차단이 어렵습니다.

다운로드 및 실행

다운로드 및 실행은 대상 시스템에서 특정 형식의 멀웨어를 다운로드하여 실행하는 원격 셸 코드입니다.이러한 유형의 셸 코드는 셸을 생성하는 것이 아니라 특정 실행 파일을 네트워크에서 다운로드하여 디스크에 저장하고 실행하도록 기계에 지시합니다.최근에는 Drive-by-download 공격에서 흔히 사용되고 있습니다.Drive-by-download 공격에서는 피해자가 악성 웹 페이지를 방문하여 이러한 다운로드를 실행하고 셸 코드를 실행하여 피해자의 컴퓨터에 소프트웨어를 설치하려고 시도합니다.이런 종류의 셸코드는 [7][8]라이브러리를 다운로드 및 로드합니다.이 기술의 장점은 코드가 작아질 수 있고, 대상 시스템에서 새로운 프로세스를 생성하기 위해 셸 코드가 필요하지 않으며, 셸 코드가 대상 프로세스를 정리하기 위해 코드가 필요하지 않다는 것입니다.이는 프로세스에 로드된 라이브러리에 의해 수행될 수 있기 때문입니다.

스테이지

공격자가 대상 프로세스에 주입할 수 있는 데이터의 양이 너무 제한적이어서 유용한 셸 코드를 직접 실행할 수 없는 경우 단계별로 실행할 수 있습니다.우선 작은 셸 코드(1단계)를 실행한다.다음으로 이 코드는 더 큰 셸 코드(2단계)를 프로세스의 메모리에 다운로드하여 실행합니다.

에그헌트

이것은 스테이지된 셸 코드의 또 다른 형태로 공격자가 프로세스에 더 큰 셸 코드를 삽입할 수 있지만 프로세스에서 어떤 결과가 나올지 판단할 수 없는 경우에 사용됩니다.예측 가능한 위치에서 프로세스에 작은 에그헌트 셸 코드를 주입하여 실행한다.그런 다음 이 코드는 프로세스의 주소 공간에서 더 큰 셸 코드(에그)를 검색하여 [9]실행합니다.

오믈렛

이러한 유형의 셸 코드는 에그헌트 셸 코드와 비슷하지만 여러 개의 작은 데이터 블록(계란)을 찾고 나중에 실행되는 하나의 큰 블록(오믈렛)으로 재결합합니다.이것은 [10]공격자가 프로세스에 다수의 작은 데이터 블록만 주입할 수 있는 경우에 사용됩니다.

셸 코드 실행 전략

부정 이용은 일반적으로 프로그램 카운터를 제어하기 위해 취약성을 이용하기 전 또는 동시에 대상 프로세스에 셸 코드를 주입합니다.프로그램 카운터는 셸 코드를 가리키도록 조정되며, 셸 코드가 실행된 후 작업을 수행합니다.셸 코드 삽입은 네트워크를 통해 취약한 프로세스로 전송되는 데이터에 셸 코드를 저장하거나 취약한 프로세스 또는 로컬 부정 이용의 경우 명령줄 또는 환경을 통해 읽히는 파일에 셸 코드를 제공하는 방식으로 이루어집니다.

셸 코드 부호화

대부분의 프로세스는 주입할 수 있는 데이터를 필터링 또는 제한하기 때문에 이러한 제한을 허용하기 위해 셸 코드를 작성해야 하는 경우가 많습니다.여기에는 코드 스몰, 늘프리 또는 영숫자로 하는 것도 포함됩니다.이러한 제한을 회피하기 위한 다음과 같은 다양한 솔루션이 발견되었습니다.

  • 셸 코드의 크기를 줄이기 위한 설계 및 구현 최적화.
  • 셸 코드에서 사용되는 바이트 범위의 제한을 피하기 위한 구현 수정.
  • 보통 프로세스에 삽입할 수 없는 바이트를 재생성하기 전에 자체 코드의 바이트 수를 수정하는 자체 수정 코드입니다.

침입검출은 네트워크상에서 송신되는 단순한 셸 코드의 시그니처를 검출할 수 있기 때문에, 검출을 피하기 위해서, 많은 경우, 부호화, 자기 복호화, 또는 다형성이 됩니다.

퍼센트 부호화

브라우저를 대상으로 하는 부정 이용은 일반적으로 퍼센트 인코딩, 이스케이프 시퀀스 인코딩을 사용하여 JavaScript 문자열 내의 셸 코드를 인코딩합니다.\uXXX" 또는 엔티티 [11]부호화.또, IDS 에 의한 검출을 막기 위해서, 부호화된 셸 코드 문자열을 한층 더 난독화하는 악용도 있습니다.

예를 들어 IA-32 아키텍처에서는 다음과 같은 두 가지 방법이 있습니다.NOP(no-operation) 명령어는 처음에 부호화되지 않은 상태로 표시됩니다.

90 NOP 90 NOP
인코딩된 이중 NOP:
백분율로 측정되었다 unescape("%u9090")
유니코드 리터럴 "\u9090"
HTML/XML 엔티티 "邐"또는"邐"

이 지침은 NOP 슬라이드에 사용됩니다.

Null-free 셸 코드

대부분의 셸 코드는 늘 끝 문자열을 통해 타깃프로세스에 삽입되도록 설계되어 있기 때문에 늘 바이트를 사용하지 않고 작성됩니다.늘 종단 문자열이 복사되면 셸 코드의 첫 번째 늘 바이트까지 복사되지만 후속 바이트는 처리되지 않습니다.이와 같이 늘을 포함한 셸 코드가 삽입되면 셸 코드의 일부만 삽입되어 정상적으로 실행할 수 없게 됩니다.

늘 바이트를 포함한 셸 코드로부터 늘 프리 셸 코드를 작성하려면 0이 포함된 머신명령어를 같은 효과가 있지만 늘이 없는 명령어로 대체할 수 있습니다.예를 들어 IA-32 아키텍처에서는 다음 명령을 대체할 수 있습니다.

B8 010000 MOV EAX, 1 // 레지스터 EAX를 0x00001로 설정합니다.

이 명령어는 1리터럴의 일부로서0 을 포함하고 있습니다(으로 전개됩니다).다음 순서를 나타냅니다.

33C0 XOR EAX,EAX // 레지스터 EAX를 0x0000000 40 INC EAX로 설정 // EAX를 0x00000001로 증가

같은 효과가 있지만 인코딩에 걸리는 바이트 수가 적고 늘이 없습니다.

영숫자 및 인쇄 가능한 셸 코드

영숫자 셸 코드는 0-9, A-Z, a-z [12][13]등의 영숫자 ASCII 또는 Unicode 문자로 구성되거나 실행 시 자체 조립되는 셸 코드입니다.이러한 유형의 인코딩은 해커가 텍스트로 보이는 내부에 작동 중인 기계 코드를 숨기기 위해 만들었습니다.이것은, 코드의 검출을 회피해, 문자열로부터 영숫자가 아닌 문자를 스크럽 하는 필터를 코드가 통과할 수 있도록 하는 경우에 도움이 됩니다(일부 이러한 필터는 영숫자가 아닌 셸 코드의 부정 이용에 대한 응답이었습니다).유사한 유형의 인코딩은 인쇄 가능한 코드라고 불리며 인쇄 가능한 모든 문자(0-9, A-Z, a-z, !@#%^&*() 등)를 사용합니다.마찬가지로 제한된 변형으로는 ECHO 명령에 의해 받아들여지지 않는 문자를 포함하지 않음ECHOable 코드가 있습니다.영어로 [14]된 일반 텍스트와 같은 셸 코드를 작성할 수 있는 것으로 나타났습니다.영숫자 코드 또는 인쇄 가능한 코드를 작성하려면 코드가 실행되는 시스템의 명령 집합 아키텍처를 잘 이해해야 합니다.복수의 [15]머신에서 실행 가능한 영숫자 코드를 쓸 수 있는 것이 증명되어 멀티 아키텍처 실행 가능 코드가 되어 있습니다.

경우에 따라서는 타깃프로세스가 삽입된 셸 코드에서 인쇄 가능 문자 또는 영숫자가 아닌 바이트를 필터링합니다.이러한 상황에서는 셸 코드를 기술하는 데 사용할 수 있는 명령의 범위가 매우 제한됩니다.이 문제에 대한 해결책은 Rix가 Prack[12] 57에서 발표한 것으로, 어떤 코드도 영숫자 코드로 변환할 수 있다는 것을 증명했습니다.자주 사용되는 기술은 자체 수정 코드를 만드는 것입니다. 이 기술을 사용하면 코드가 자신의 바이트를 수정하여 통상 허용 범위를 벗어나는 바이트를 포함할 수 있기 때문에 사용할 수 있는 명령의 범위가 넓어지기 때문입니다.이 트릭을 사용하면 처음에는 허용된 범위의 바이트만 사용하는 자체 수정 디코더를 만들 수 있습니다.셸 코드의 메인코드는 부호화되어 허용 범위 내의 바이트만 사용합니다.출력 셸 코드가 실행되면 디코더는 자신의 코드를 수정하여 정상적으로 기능하기 위해 필요한 명령을 사용할 수 있습니다.그리고 나서 원래의 셸 코드를 계속 디코딩합니다.셸 코드를 디코딩한 후 디코더는 정상적으로 실행될 수 있도록 제어를 셸 코드로 전송합니다.영어로 [14]된 일반 텍스트처럼 보이는 임의의 복잡한 셸 코드를 생성할 수 있는 것으로 나타났습니다.

Unicode 프루프 셸 코드

최신 프로그램에서는 유니코드 문자열을 사용하여 텍스트를 국제화할 수 있습니다.이러한 프로그램은 수신 ASCII 문자열을 처리하기 전에 유니코드로 변환하는 경우가 많습니다.UTF-16으로 인코딩된 Unicode 문자열은 각 문자를 인코딩하기 위해 2바이트를 사용합니다(특수 문자의 경우 4바이트).ASCII(일반적으로 Latin-1) 문자열이 UTF-16으로 변환되면 원래 문자열의 각 바이트 뒤에 0 바이트가 삽입됩니다.옵스커우는 프락 61에서[13] 이 변환 후에 성공적으로 실행될 수 있는 셸 코드를 작성할 수 있음을 증명했습니다.임의의 셸 코드를 영숫자 UTF-16-proof 셸 코드로 자동적으로 부호화할 수 있는 프로그램은, 원래의 셸 코드를 디코딩 하는 작은 자기 수정 디코더와 같은 원리에 근거하고 있습니다.

플랫폼

대부분의 셸 코드는 공격받는 취약성에 의해 공격자가 프로세스에 액세스할 수 있는 수준이 낮기 때문에 머신 코드로 작성됩니다.따라서 셸코드는 프로세서, 운영체제서비스 팩의 특정 조합인 플랫폼(Platform)을 대상으로 작성되는 경우가 많습니다.일부 악용의 경우 타깃프로세스에 의해 셸코드에 가해지는 제약으로 인해 매우 구체적인 셸코드를 작성해야 합니다.그러나 하나의 셸 코드가 여러 악용, 서비스 팩, 운영 체제 및 프로세서에 [16][17][18]대해 작동하는 것이 불가능한 것은 아닙니다.이러한 범용성은 일반적으로 다양한 플랫폼을 대상으로 하는 여러 버전의 셸 코드를 작성하고 코드가 실행되고 있는 플랫폼의 올바른 버전으로 분기하는 헤더를 작성함으로써 실현됩니다.실행 시 코드는 플랫폼에 따라 다르게 동작하며 실행 중인 플랫폼의 셸 코드 오른쪽 부분을 실행합니다.

셸코드 분석

셸 코드를 직접 실행할 수 없습니다.셸 코드가 무엇을 시도하는지 분석하려면 셸 코드를 다른 프로세스에 로드해야 합니다.하나의 일반적인 분석 기술은 셸 코드를 바이트 버퍼로 유지하는 작은 C 프로그램을 작성한 후 함수 포인터 또는 인라인 어셈블러를 사용하여 실행을 전송하는 것입니다.또 다른 기술은 shellcode_2_exe와 같은 온라인 도구를 사용하여 셸 코드를 표준 디버거에서 분석할 수 있는 미리 만들어진 실행 파일 허스크에 삽입하는 것입니다.2005년에 Malcode Analyst Pack의 일부로 처음 출시된 iDefense sclog 프로젝트와 같은 특수한 셸 코드 분석 도구도 있습니다.Sclog는 외부 셸 코드 파일을 로드하여 API 로깅 프레임워크 내에서 실행하도록 설계되었습니다.크로스 플랫폼 libemu 패키지의 일부인 sctest 애플리케이션과 같은 에뮬레이션 기반 셸 코드 분석 도구도 존재합니다.libemu 라이브러리를 중심으로 구축된 다른 에뮬레이션 기반 셸 코드 분석 도구는 기본 디버깅셸과 통합 보고서 기능을 포함하는 scdbg입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Foster, James C.; Price, Mike (2005-04-12). Sockets, Shellcode, Porting, & Coding: Reverse Engineering Exploits and Tool Coding for Security Professionals. Elsevier Science & Technology Books. ISBN 1-59749-005-9.
  2. ^ Anley, Chris; Koziol, Jack (2007). The shellcoder's handbook: discovering and exploiting security holes (2 ed.). Indianapolis, Indiana, UA: Wiley. ISBN 978-0-470-19882-7. OCLC 173682537.
  3. ^ Gupta, Sunil (2019), "Buffer Overflow Attack", Ethical Hacking – Orchestrating Attacks, Berkeley, California, USA: Apress, doi:10.1007/978-1-4842-4340-4_12, ISBN 978-1-4842-4340-4, S2CID 235938447
  4. ^ Foster, James C. (2005). Buffer overflow attacks: detect, exploit, prevent. Rockland, MA, USA: Syngress. ISBN 1-59749-022-9. OCLC 57566682.
  5. ^ "Tiny Execve sh - Assembly Language - Linux/x86". GitHub. Retrieved 2021-02-01.
  6. ^ BHA (2013-06-06). "Shellcode/Socket-reuse". Retrieved 2013-06-07.
  7. ^ SkyLined (2010-01-11). "Download and LoadLibrary shellcode released". Archived from the original on 2010-01-23. Retrieved 2010-01-19.
  8. ^ "Download and LoadLibrary shellcode for x86 Windows". 2010-01-11. Retrieved 2010-01-19.
  9. ^ Skape (2004-03-09). "Safely Searching Process Virtual Address Space" (PDF). nologin. Retrieved 2009-03-19.
  10. ^ SkyLined (2009-03-16). "w32 SEH omelet shellcode". Skypher.com. Archived from the original on 2009-03-23. Retrieved 2009-03-19.
  11. ^ "JavaScript large number of unescape patterns detected". Archived from the original on 2015-03-20.
  12. ^ a b rix (2001-08-11). "Writing ia32 alphanumeric shellcodes". Phrack. Phrack Inc. 0x0b (57). #0x0f of 0x12. Archived from the original on 2022-03-08. Retrieved 2022-05-26.
  13. ^ a b obscou (2003-08-13). "Building IA32 'Unicode-Proof' Shellcodes". Phrack. Phrack Inc. 11 (61). #0x0b of 0x0f. Archived from the original on 2022-05-26. Retrieved 2008-02-29.
  14. ^ a b Mason, Joshua; Small, Sam; Monrose, Fabian; MacManus, Greg (November 2009). English Shellcode (PDF). Proceedings of the 16th ACM conference on Computer and Communications Security. New York, NY, USA. pp. 524–533. Archived (PDF) from the original on 2022-05-26. Retrieved 2010-01-10. (10페이지)
  15. ^ "Multi-architecture (x86) and 64-bit alphanumeric shellcode explained". Blackhat Academy. Archived from the original on 2012-06-21.
  16. ^ eugene (2001-08-11). "Architecture Spanning Shellcode". Phrack. Phrack Inc. #0x0e of 0x12. Archived from the original on 2021-11-09. Retrieved 2008-02-29.
  17. ^ nemo (2005-11-13). "OSX - Multi arch shellcode". Full disclosure. Archived from the original on 2022-05-26. Retrieved 2022-05-26.
  18. ^ 차인표는 상 길;박세리, 브라이언, Brumley, David;립턴, 리차드 제이(2010-10-08)[2010-10-04].플랫폼 독립 프로그램(PDF).컴퓨터 통신 보안(CCS'10)에 17ACM컨퍼런스 논문집.일리노이 주, 시카고 미국:카네기 Mellon대학교, 펜실베니아 주 피츠버그, 미국/조지아 공과 대학, 조지아, 아틀란타, 미국.를 대신하여 서명함. 547–558. doi:10.1145/1866307.1866369.아이 에스비엔 978-1-4503-0244-9.그 2022-05-26에 원래에서Archived(PDF).2022-05-26 Retrieved.[1](12페이지)(참고 항목:[2]).

외부 링크