업데이트 2020년 1월 22일

이제 FireEye에서 제공하는 도구를 사용하여 아래 항목들을 스캔할 수 있습니다. 핵심은 익스플로잇이 실행된 이후의 작업을 확인할 수 있도록 2020년 1월 9일까지의 충분한 로그가 있어야 한다는 점입니다. .XML 페이로드 파일이 발견되면 아래 정보를 사용하여 조치를 결정해야 합니다. https://www.fireeye.com/blog/products-and-services/2020/01/fireeye-and-citrix-tool-scans-for-iocs-related-to-vulnerability.html

도구 다운로드

https://github.com/citrix/ioc-scanner-CVE-2019-19781 https://github.com/fireeye/ioc-scanner-CVE-2019-19781/

익스플로잇 탐지

현재 누군가가 무엇을 했는지 입증할 수 있는 쉬운 방법은 없습니다. 4가지 공개 익스플로잇은 각각 다른 아티팩트/시그니처를 남기므로 탐지에 도움이 되지만 100% 완벽하지는 않습니다. 기억해야 할 핵심은 10일까지 비공개였던 공개 익스플로잇들이며, 여전히 자신의 이익을 위해 공유하지 않는 다른 익스플로잇들이 존재할 수 있다는 점입니다. 대부분의 경우 익스플로잇은 수정 가능하여 드롭되는 파일 이름, 사용자 계정 이름, 프로세스 이름, 쿼리 경로 및 기타 여러 옵션을 변경할 수 있으므로 시스템이 익스플로잇되었을 가능성이 기하급수적으로 증가합니다. 또한 고급 공격자와 기본 공격자가 있으며, 하나는 흔적을 정리하고 탐지를 피하기 위해 매우 교묘한 방법을 사용할 것입니다.

Nessus를 실행 중이라면 아래 .YAR 파일을 사용하여 권한 있는 스캔을 통해 일반적인 탐지 방법을 찾을 수 있습니다. https://github.com/Neo23x0/signature-base/blob/master/yara/exploit_shitrix.yar

익스플로잇 감사

이 감사 프로세스에 관한 훌륭한 링크들입니다. https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/amp/ http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781/

면책 조항: 앞서 언급했듯이 이 방법이 모든 익스플로잇을 탐지하지는 않지만, 공격자가 공개 익스플로잇을 수정하지 않았거나 흔적을 정리하지 않은 경우 일부 이상 징후를 탐지하는 데 도움이 될 수 있습니다. 대부분의 공격자는 기본 익스플로잇을 사용하며, 아래는 남겨질 수 있는 문서화된 아티팩트 중 일부입니다. 이 명령 목록은 여러 출처에서 가져온 것이며, 다른 변종, 해결 방법 및 새로운 개발 상황이 나타남에 따라 매우 동적으로 변할 것입니다. 더 많은 감염이 발생하고 더 큰 샘플 세트로 추가 포렌식이 완료됨에 따라 이 내용은 지속적으로 변경될 것으로 예상해야 합니다.

먼저, 본인이 수행하지 않은 항목을 살펴보십시오. ADC에서 평소에 많은 작업을 하지 않는다면 이 로그들은 매우 조용해야 하며, 몇 주, 몇 달 또는 몇 년 전에 마지막으로 접속했던 항목이 있을 수 있습니다. 더 정밀한 쿼리는 바로 아래에 있습니다. 또한 이 블로그조차 고양이와 쥐 게임임을 이해해야 합니다. 우리가 본 것과 공격자를 찾는 방법을 공개함에 따라, 그들은 탐지를 피하기 위해 전술을 변경하여 이 정보를 역이용하고 있습니다.

익스플로잇 확인 빠른 체크리스트 v1

1. 라이선스 확인: 일부 사용자가 장치를 재부팅한 후 라이선스가 만료된 사례를 들었습니다.
1. 지원 파일 얻기: 시스템 -> 진단 -> 지원 파일 받기로 이동하여 해당 파일을 저장합니다.
1. 아래 모든 명령은 NSCLI에서 실행되며, SSH로 박스에 접속하여 Shell을 사용하는 경우 Shell 접두사를 제거할 수 있습니다.
1. 박스의 날짜를 확인하여 로그 결과를 상호 참조하는 데 도움을 줍니다.
- a. shell date
1. 구성 변경 날짜 확인
- a. Shell ls -l /netscaler/ | grep netscaler
- b. Shell ls -l /nsconfig | grep netscaler
  - i. netscaler.conf의 날짜는 언제인가요?
  - ii. 정상적으로 보이나요? 다른 위치로의 파일 링크를 확인하세요.
1. 로컬 계정 비밀번호 파일 확인
- a. Shell ls -lh /etc/passwd
  - i. 파일이 수정된 시간을 확인하세요. 익스플로잇 이후이고 본인이 수정한 것이 아니라면 가능한 빨리 비밀번호를 변경해야 합니다.
  - ii. 익스플로잇이 탐지되면 nsroot 또는 로컬 계정의 비밀번호를 변경하는 것이 좋습니다. 많은 경우에
- b. Shell cat /etc/passwd
  - i. 계정에 무엇이 있는지 확인하세요.
  - ii. root, nsroot, daemon, operator, bin, nobody, sshd, nsmonitor는 기본 계정입니다.
1. 로그 확인
- a. shell ls -lh /var/logfile
  - i. 파일이 있나요? 크기가 매우 작나요?
  - ii. https://support.citrix.com/article/CTX121898
1. 악성 파일 확인
- a. 이 파일들 중 8-9자가 아니거나 임의의 파일 이름을 가진 것이 있다면, 이는 기본 익스플로잇을 변경한 고급 공격자의 징후입니다. 이 경우 그에 따라 대응을 조정해야 합니다. Pwnpzi1337.xml은 Project India 익스플로잇의 파일 이름입니다.
- b. shell ls /netscaler/portal/templates/*.xml
  - i. 여기에 XML 파일이 없어야 합니다.
  - ii. 감염된 경우 파일 날짜를 확인하세요.
  - iii. shell ls -lh /netscaler/portal/templates/
- c. shell ls /var/tmp/netscaler/portal/templates
  - i. 이 디렉토리는 존재하지 않아야 합니다.
  - ii. 감염된 경우 파일 날짜를 확인하세요.
  - iii. shell ls -lh /var/tmp/netscaler/portal/templates
- d. shell ls /var/vpn/bookmark/*.xml
  - i. 일반적으로 존재하지 않지만, 거기에도 XML 파일이 있으면 안 됩니다.
  - ii. 감염된 경우 파일 날짜를 확인하세요.
  - iii. shell ls -lh /var/vpn/bookmark/
- e. shell ls /tmp/.init
  - i. 이 디렉토리는 존재하지 않아야 합니다.
1. 크론 작업 (지속성 방법)
- a. shell cat /etc/crontab
- b. shell crontab -l -u nobody
1. 암호화폐 채굴 확인
- a. shell top -n 10
  - i. NSPPE-xx (패킷 엔진)는 100% 또는 거의 100%여야 하며, 다른 프로세스가 있다면 채굴이 발생했을 수 있습니다.
1. PCAP
- a. Shell find / -name "*.cap"
- b. 유실된 캡처 파일을 찾는 데 도움을 줍니다.
- c. 이는 네트워크 스니핑을 수행한 고급 공격자의 징후입니다.
1. Shell 로그
- a. shell cat /var/log/bash.log | grep nobody
  - i. nobody 사용자의 접근을 찾습니다.
- b. shell gzcat /var/log/bash.*.gz | grep nobody
  - i. 압축된 로그에서 nobody 사용자의 접근을 찾습니다.
1. Apache 로그 확인
- a. shell "cat /var/log/httperror.log | grep -B2 -A5 Traceback"
- b. shell "gzcat /var/log/httperror.log.*.gz | grep -B2 -A5 Traceback"
- c. shell grep -iE 'POST.*.pl HTTP/1.1" 200 ' /var/log/httpaccess.log -A 1
- d. shell grep -iE 'POST.*.pl HTTP/1.1" 200 143' /var/log/httpaccess.log -A 1
- e. shell grep -iE 'GET.*.xml HTTP/1.1" 200' /var/log/httpaccess.log -B 1
- f. shell grep -i '.pl HTTP/1.1" 200 143' /var/log/httpaccess.log | grep POST
  - i. 이 모든 명령은 .pl 및 .xml 파일이 시스템 안팎으로 이동할 때 특정 항목을 찾습니다.
- g. shell cat /var/log/httperror.log
  - i. 전체 파일의 원시 내용을 확인하여 눈에 띄는 다른 항목을 찾습니다.
1. 지속성 스크립트
- a. shell ps -aux | grep python
- b. shell ps -aux | grep perl
- c. shell ps -auxd | grep nobody
  - i. 이들은 리버스 셸 및 기타 작업을 실행하기 위해 스크립트를 사용하는 알려진 지속성 방법입니다. 프로세스 목록에는 grep 명령만 표시되어야 합니다.
  - ii. 이 게시물은 또 다른 지속성 방법의 발견 내용을 다룹니다. 이 익스플로잇은 Nobody 사용자가 실행한 악성 프로세스를 사용했습니다. https://soolidsnake.github.io/2020/01/17/citrix_malware.html
1. 비밀번호/계정 확인
- a. shell ls -l /etc/passwd
  - i. 최근에 추가된 항목이 있는지 파일 날짜도 확인하세요.
- b. shell cat /etc/passwd
  - i. 의심스러운 항목, 로컬 계정이 있나요?
1. TCP 연결 확인
- a. Shell netstat -natu
- b. VLAN에서 로컬이 아닌 IP 주소를 찾으세요. 다른 박스가 손상되었을 수 있으므로 내부 IP도 확인해야 합니다.
1. 인증 프로필 확인
- a. TLS 또는 SSL로 설정되어 있었는데 지금은 PlainText로 변경되었나요?
  - i. 일부 감사 및 온라인에서 변경된 사례를 보았습니다.
  - ii. 이는 고급 공격자의 징후이기도 합니다.
- b. 이는 다행히 ns.conf 구성이 변경되었는지 여부와 관련이 있습니다.
- c. 이전에 PlainText였다면, 익스플로잇 징후가 있든 없든 가능한 빨리 TLS 및 SSL로 설정해야 합니다.
1. 인증서 확인
- a. 이들은 SSL 인증서로, 특히 박스가 익스플로잇된 경우 재발급을 고려해야 합니다.
- b. 익스플로잇 징후가 있으면 SSL 인증서를 재발급하는 것이 좋습니다. 대규모 배포의 경우 인증서가 바인딩된 다른 위치가 많고 SSL 인증서 변경으로 인한 잠재적 중단/장애가 있을 수 있어 더 어려울 수 있습니다.
- c. 일부 고객은 익스플로잇 실행 외에는 아무것도 하지 않았음을 입증할 수 있는 좋은 로그가 있어 재발급하지 않았습니다. 대부분의 고객은 며칠 분량의 로그만 보유하고 있을 수 있습니다.
1. 구성 파일에서 잠재적 1계층 대상 확인
- a. ns.conf를 확인하면 장치가 익스플로잇된 경우 가장 먼저 액세스된 1계층 대상 목록을 얻을 수 있습니다.

익스플로잇된 경우

위협 환경에 따라 수행해야 할 작업은 항상 다릅니다. 익스플로잇 실행 증거를 발견한 고객에게 전달한 몇 가지 생각입니다.

귀하의 비즈니스는 어떤 규정 준수 기관의 적용을 받나요? 금융/은행, SOX, PCI, HIPPA, 주/지방 및 정부 법률.

해당 프레임워크 중 하나에 속한다면, 해당 규정 준수 기관의 절차를 따라야 합니다. 또한 인시던트 대응 및 공개에 관한 조항이 있는 인증 및 전문 단체의 윤리적 고려 사항도 있습니다.

다음은 잘 알려진 두 인시던트 대응 프로세스 가이드 링크입니다. https://security.berkeley.edu/incident-response-planning-guideline https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

지금까지 알려진 바에 따르면, 1월 10일경 첫 번째 공개 익스플로잇이 공개되었으며, 9일에도 감염 보고가 있었습니다. 대부분의 경우, 2020년 이전에 시스템을 패치했다면 위험은 훨씬 낮습니다.

CVE-2019-19781 예상 위험 위협 증가

12월 17일 ~ 12월 31일: 익스플로잇 위험 최저 1월 1일 ~ 8일: 익스플로잇 위험 낮음 1월 9일 ~ 13일: 익스플로잇 위험 높음 1월 14일 ~ 현재: 익스플로잇 위험 최고

이 정보는 다음 단계를 위한 프로세스에 포함되어야 합니다.

익스플로잇 흔적을 발견했습니다. 이제 무엇을 해야 하나요? 여전히 상황에 따라 다릅니다. 대부분의 Citrix ADC 배포에서는 우수한 SNMP 및 SYSLOG 로깅이 구성되지 않으며, 아티팩트가 발견되었을 때 검색, 필터링 또는 경고할 좋은 방법이 없을 수 있습니다. 완벽한 로깅이 있고 공격자가 아무것도 하지 않았다고 확신한다면, 그냥 넘어갈 수 있습니다. 그리고 무언가를 발견했고 원격 접속을 자신 있게 제거할 수 있었다면, 역시 넘어갈 수 있습니다.

하지만 대부분은 일부 흔적을 발견하고, 무엇이 수행되었고 어디로 갔는지 연결할 수 없을 수 있으며, 탐지 후 장치를 재설정하는 것이 더 쉬울 수 있습니다.

다음 조언은 향후 2주 내에 변경될 수 있습니다.

샘플 인시던트 대응 경로

모든 상황에 맞는 완벽한 정답은 없습니다. 아래는 1월 19일 현재의 제 생각이며, 이 취약점과 관련된 방어 또는 공격 측면에서 더 많은 정보를 얻고 다음 단계가 공개됨에 따라 변경될 수 있습니다. 정답은 없으며, IT 보안은 "상황에 따라 다르다"는 법칙이 지배하는 분야입니다. 3개 디렉터리에만 이러한 파일 외에 다른 것이 발견된다면, 박스가 손상된 것으로 간주하고 더 신중한 경로를 선택하는 것이 좋습니다. 일부에서는 특히 로깅이 없어 공격자가 무엇을 했는지 확인할 수 없을 때 더 신중한 경로를 권장합니다. 팀과 협력하여 상황에 가장 적합한 조치를 결정해야 합니다. 이는 팀 스포츠이기 때문입니다. 항상 더 나은 해결 방법이 있을 수 있지만, 장치 내부 및 주변(1계층 대상)의 증거를 바탕으로 위험을 줄이고 거기서부터 시작하는 것이 괜찮을 수 있습니다.

완화: 상황에 관계없이 여기서 시작해야 합니다. 새 펌웨어 또는 응답기 정책을 사용합니다.
감사 중 탐지된 익스플로잇
- 인시던트 대응 프로세스를 시작합니다.
우수한 장치 로깅이 있는 경우
- 고급 공격 또는 지속성 징후
  - 새로 구축 후 마이그레이션
- 고급 공격 또는 지속성 징후 없음
  - 문제 해결 후 계속 운영
장치 로깅이 없는 경우
- 고급 공격 또는 지속성 징후
  - 새로 구축 후 마이그레이션
  - 공장 초기화
- 고급 공격 또는 지속성 징후 없음
  - 새로 구축 후 마이그레이션
  - 공장 초기화
우수한 1계층 대상 로깅이 있는 경우
- 고급 공격 또는 지속성 징후
  - 새로 구축 후 마이그레이션
  - 공장 초기화
- 고급 공격 또는 지속성 징후 없음
  - 문제 해결 후 계속 운영
1계층 대상 로깅이 없는 경우
- 고급 공격 또는 지속성 징후
  - 새로 구축 후 마이그레이션
  - 공장 초기화
- 고급 공격 또는 지속성 징후 없음
  - 새로 구축 후 마이그레이션
  - 공장 초기화

CVE-2019-19871-AuditGuide

인기