Develop Destroyer

이 취약점으로 주말에 잘쉬고 있다가 갑자기 일을 하게 되었다.. 보편적으로 안쓰는 업체가 찾기 힘든 라이브러리에서 크리티컬한 취약점이 발견된 것이다. 이후에도 지속적으로 개발 커뮤니티에도 해당 이슈가 올라와서 나도 내가 아는바에 대한 내용을 기록으로 남겨본다

[개요]

자바 기반으로 만들어지고 전세계적으로, 대중적(?)으로 많이 사용되는 로깅을 위한 라이브러리로 log4j가 있다.

이번 이슈가 된 취약점은 log4j가 넘겨받은 변수를 그대로 로깅하는 것이 아니라 해당 변수를 분석해 실행할 수 있는 lookups 기능에서 발견되었다. lookups란 예를들어 log.error("에러 : " + result); 에서 result가 ${env:PASSWORD}로 설정되어 있다면 "에러 : ${env:PASSWORD}"를 그대로 로깅하는 것이 아니라 이에 해당하는 설정값을 찾아 "에러 : qwer1!"를 로깅하게 되는 기능이다. lookup에는 여러가지 기능들이 있는데, 이번 케이스는 JDNI 룩업을 이용한 공격이 가능하다는 취약점이다. 이른바 Log4Shell 취약으로 불린다.

[취약점 공격 대상]

log4j-core 버전 2.10.0 이상 ~ 2.15.0 미만

[대응방법]

1. log4j를 2.15.0 이상으로 업그레이드 한다. (Java8 이상에서만 기동된다)

2. log4j 2.10.0 이상 사용 시 다음의 방법 중 한 가지 이상의 방법을 사용한다. 개인적인 의견으로는 서비스의 운영환경마다 다르겠지만.. 운영하는 웹서비스가 많아 관리 포인트가 많고 복잡할 경우.. 이 방법은 관리측면에서는 별로 좋은 방법 같진 않다. 개발자가 프로젝트 소스코드 외부에서 관리해야하고(서버/인프라 단), 이 설정이 되어있는 이유에 대해 나중에 시간이 많이 지나서 누가 보더라도 알 수 있도록 히스토리를 잘 관리해야 한다는 점..

•  
• Java 실행 인자(Arguments) 에 시스템 속성을 추가한다. -Dlog4j2.formatMsgNoLookups=true
• Java 실행 계정의 환경 변수 혹은 시스템 변수로 LOG4J_FORMAT_MSG_NO_LOOKUPS=true를 설정한다.

3. log4j 2.7.0 이상 사용 시 log4j 설정(log4j.xml 등)에 PatternLayout 속성에 있는 %m 부분을 %m{nolookups} 으로 교체한다.

4. 만약 log4j 버전이 2.10.0보다 낮다면, 이번 이슈의 공격대상은 아니다.. 그렇지만 1버전 대의 경우는 지원이 중단되었으며, 이미 RCE 보안이슈가 존재하므로 가급적 업그레이드 방안을 모색하는 것이 좋다

[팁]

위 대응방법은 기본적인 조치 방법에 대해 설명한 것이고, 이와 더불어 조치 시 아래 오픈소스를 참고하면 빠르게 조치할 수 있다.

https://github.com/logpresso/CVE-2021-44228-Scanner

해당 소프트웨어를 서버로 옮겨서 웹서비스가 설치된 디렉토리를 중심으로 탐색하면 대상 log4j를 사용중인지 확인 할 수 있다. 사용방법은 해당 레포지토리 README에 상세히 나와있고 매우 간편하다.

그리고 우리 서비스 외에도 밴더 솔루션등에도 log4j 이슈가 있을 수 있으니 꼭 문의를 넣어서 확인해보자

이 가이드는 솔라나 지갑을 이미 보유한 상태에서 진행함

1. solona CLI를 설치한다. 아직까지는 연구단계임에따라 윈도우 환경 전용으로 설치하였는데 생각보다 잘 동작한다

2. 다음 명령어에 따라 내 지갑에 연결된 토큰 account 정보를 확인해볼수 있다.

C:\WINDOWS\system32>spl-token accounts
Token                                         Balance
---------------------------------------------------------------
83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ  90
85iewBw7g5xzTBPsmEhRT6UyVHjZKkH2QzxR6Hpxp4AM  10  (Aux-1*)
HuJCd48ycmqS5ADDnprxzbPoTAH2FQwYY92SdFC4tZgs  10  (Aux-1*)

참고로 위 과정 중 특정위치에 있는 계정정보파일을 읽을 수 없다면 에러가 뜰것이다. solona config 명령어를 통해 계정정보가 어디에 저장돼는지 확인 할 수 있으며 계정정보가 없다면 자신의 지갑 개인키를 배열(엄밀히 따지자면 json)의 형태로 저장해주면 된다. (ex. [13, 103, 34, 534 ...] 이런 형태로 저장된다. 이 값은 sollet.io에서 접속한 뒤 자신의 지갑에서 export를 하면 해당 파일을 얻을 수 있다.. 직접 이렇게 변환하는 방법도 알고싶은데 어디에서인지 아직 알 수 없음;

3. 토큰을 새로 생성한다.

intput

spl-token create-token

output

Creating token 83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ

Signature: 4ELSGXv7Eh6sFnzcM7XvVLmZUZrWbCsF7DoKYpj14qmMzohh9b79AqTXnUYTaLKUuFQLASBHrPMKhEbrM7h8cjMr

4. 이제 생성한 토큰을 집어넣을 token account를 만들어준다. 왜이렇게하는건지는 아직 이해하지 못하겠으나... 본 지갑에서 서브형태로(?) 종속된 account를 만들어서 거기에 방금 3에서 생성한 토큰을 넣어줄것이다.

intput

spl-token create-account 83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ

output

Creating account 3mMDq1JaT3jRWyJkK7tZuy9E9jJFCey83Kj2WK6Lk1Ei

Signature: 42Sa5eK9dMEQyvD9GMHuKxXf55WLZ7tfjabUKDhNoZRAxj9MsnN7omriWMEHXLea3aYpjZ862qocRLVikvkHkyfy

5. 새로만든 account를 확인해보자

solana balance 3mMDq1JaT3jRWyJkK7tZuy9E9jJFCey83Kj2WK6Lk1Ei

6. 토큰을 다음과 같은 형태로 민트한다

spl-token mint tokenAddress mintAmount recipientAddress

예시는 아래와 같다

spl-token mint 83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ(토큰) 100(발행량) 3mMDq1JaT3jRWyJkK7tZuy9E9jJFCey83Kj2WK6Lk1Ei(토큰account)

7. 이제 다음과 같이 발행된 토큰을 확인해 볼 수 있다.

spl-token accounts

Token Balance

------------------------------------------------------------

83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ 1000000

8. 발행한 토큰을 다른 지갑으로 전송해본다

spl-token transfer --fund-recipient tokenAddress transferAmount recipientAddres

아래는 예시

input

spl-token transfer 83htTo1jczLTMRBLDjmc94bx7Gz3M3FrpJW2QtVzUZRJ 30 vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg

output

Transfer 50 tokens Sender: 7UX2i7SucgLMQcfZ75s3VXmZZY4YRUyJN9X1RgfMoDUi Recipient: vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg Recipient associated token account: F59618aQB8r6asXeMcB9jWuY6NEx1VduT9yFo1GTi1ks Signature: 5a3qbvoJQnTAxGPHCugibZTbSu7xuTgkxvF4EJupRjRXGgZZrnWFmKzfEzcqKF2ogCaF4QKVbAtuFx7xGwrDUcGd

실수로 merge를 하였을 경우 다음과 같이.. reset을 해버리자

git reset --merge ORIG_HEAD

위 명령어를 사용하면 원격지와의 head와 로컬의 head가 상이하여 push시도시 에러가 발생한다.

git push -f origin master

-f (force)를 사용하여 강제로 push해야한다.