락쉴드 Locked Shields #8 Day 2

락쉴드 Locked Shields #8 Day 2

 

** 소개
2일 날 레드 팀은 전날의 활동을 표현하기 시작했다. 불행하게도, 진행미팅 세션은 심각한 성능 문제를 가졌고, 블루 팀은 거의 그것을 이해할 수 없었다. VPN은 7시 20분에 열렸다.

 

** 웹 공격
다음 변조 캠페인은 2일 날에 실행되었다 
1. 변조의 네 번째 라운드 8시 35분에 지속되었고 - 9시 55분 대상이 되었다. 하지만 모든 BT3는 해킹되었다. 보고서에 따르면, BT5는 50분 후에 이전 팀보다 손상 되었다. 다시 이 시점까지 자신의 웹 애플리케이션 방화벽은 미세 조정이 충분하지 않았고 코드 수정은 그들에게 지연, 공격을 차단하는데 도움이 되지 않았다고 나타냈다.

2. 변조의 다섯 번째이자 마지막 라운드는 11:00쯤에 시작되었고, 고객 포털, WWW 사이트, 웹 메일 서버 및 BT7의 웹 상점, BT2, BT9, BT1, BT6, BT4, BT8 및 BT3은 다시 떨어졌다. 보고서에 따르면, 고객 데이터베이스는 BT9와 BT1에 도난 당했다. 공격자는 BT9에 대한 특별한 감정을 가짐에 따라 우리의 정보 소스 서명을 남겨 이러한 공격은 동등하게 균형을 따라야 했었다, 사실, 레드 팀 리더로 조정 여부를 의심 할 이유가 있다.

** 네트워크 공격
두 번째 라운드는 2일 날 09:10분에 네트워크 장치 구성를 훔치는 것으로 시작되었다. 40분에서 BT1, BT2 및 BT9는 라우터 다시 소유했다. 또한, 이 시간의 목표는 BT4와 BT6에 대하여 수행 하였다. 기술적인 관점에서, 공격은 오히려 사소했다. 라우터는 변경되지 않은 초기 비밀번호 (BT9) 또는 초기 읽기 - 쓰기 커뮤니티 이름과 SNMP 사용에 따른 SSH를 통해 액세스 했다. 그것은 10:30 이후 레드 팀이 더 이상 접근할 수 없도록 하지 않은 이상 BT4는 장치를 고정하는 것으로 알려졌다.

** 클라이언트 측 공격
클라이언트 측 팀은 내부 영역에서 Windows 호스트를 대상으로 계속했다. 그들의 주요 목표는 SCADA 구성 요소의 VNC 암호를 도용하고, 특정 순간에 SCADA에 액세스 할 워크스테이션을 사용하는 능력을 가지고하기 위해 지속적인 접속을 유지하는 것 이었다.

2일 날 아침, 레드 팀은 BT1, BT2, BT4와 BT9 컴퓨터에 대한 액세스 권한을 얻을 수 있었다. 블루 팀은 MSF 또는 SET와 같은 표준 도구 실패로 만든 다양한 안티 멀웨어 솔루션을 구축했다. 그것은 인코딩 페이로드와 블루 팀을 격파하는 것이 가능했지만, BT2와 BT4 몇 초 공격자를 발견하고 세션을 죽였다. 레드 팀은 여전히 BT1와 BT9에서 시스템 수준의 권한을 갖고 있는 키로거로 시작했다. BT3의 워크스테이션은, BT7 및 BT8 착취 시도에 사용할 수 없었다.

** SCADA 블로우 업
모든 블루 팀은 공동 실험실 SCADA 설치로 시뮬레이션은 블루 팀의 공유 데이터 센터의 에어컨을 제어하는 프로세스를 보호했다. 방화벽의 기본 설정의 규칙은 각각 블루 팀 내부 영역에서 하나의 워크스테이션에서 VNC를 통해 구성 요소 (HMI, 제어 PC 및 개발 PC)에 대한 액세스를 허용했다. 사실, 모든 블루 팀은 레드 팀으로부터 워크스테이션을 유지하고 공유 VNC 암호를 보호 할 수 있었다. 화이트 팀은 정기적으로 로그인 SCADA 관리자로 역할을 지키고 있었다.

둘째 날 By 10:00Z - 레드 팀은 BT1 네트워크의 워크스테이션에 키로거를 설치하고 SCADA 암호를 훔치는 관리했다.
11:30 Z - 데이빗 핫셀 호프 공격(HMI의 배경 이미지가 바뀌었습니다) 실시하였다. 그리고 10분 후, BT4의 워크스테이션에서 시스템이 고장이 났다.

레드 연구팀은 BT6 및 BT9의 윈도우 XP 컴퓨터를 통해 액세스를 유지하고 있었다. 따라서, 아홉 팀 모두 네 개의 아웃 SCADA를 보호하는데 실패했다.

** 인프라 속보
두 번째 연습 날은 심각한 테스트의 실습 환경을 넣었다. VM을 호스팅하는 블레이드의 개수가 오버로드 된 두 가지 주요 증세가 있었다. 대부분의 시스템에 액세스하거나 사용할 수 없었다. 네트워크 트래픽 캡처 인프라는 높은 트래픽 피크를 처리하도록 설계되지 않았다.

1. 첫 번째 중단은 9시 50분쯤에 중단되었고, 10:00쯤에 선수들이 점심 먹기를 조언했다. 11:00쯤에 모든 블루 팀이 시스템에 다시 접근 확인되어 계속했다.

2. 나중에 다른 짧은 기간에 레드 팀의 활동에 의해 부하 문제 발생이 있었다.
구문 소동 단계에서 '모든 공격 허용'에 대한 불확실성 : 레드와 화이트 팀 사이의 오해가 있었다. 레드 팀은 여전히 ​​교전 규칙을 따라야 할 것으로 예상했다. 특히, 그들은 ddos를 시작할 것으로 예상되지 않았다 그러나 이것은 정확히 무슨 일이 일어났다.  레드 팀은 가짜 경로를 주입하여 세그먼트 내부 목적에 라우팅 루프를 만들었다. 그린 팀이 가상 네트워크 인터페이스의 트래픽 제한을 정의하지 않았으므로, 서로 다시 과부하 가 되었다.

** 다양한 공격
다른 레드 팀 활동, DMZ에서 메일 서버 및 고객 포털 파괴가 직접 득점 하였다. 메일 서버는 BT1, BT2 및 BT7에서 BT1, BT2, BT4, BT8 및 BT9, 그리고 포털에서 점령과 엉망이 되었다.

레드 연구팀은 고객의 인터넷 서비스를 중단하는 경로 주사를 실시했다. 이 모든 운동의 인프라에 영향을 미치는 라우팅 루프와 높은 트래픽 피크였다.

레드 팀은 악성 코드에 감염된 무단 계약자의 노트북을 흉내 낸  리눅스 워크스테이션을 준비하고 내부 영역에 연결했다. 악성 코드는 DNS 터널을 통해 워크스테이션에 연결을 했다. 이 방법은 성공하지 못했다. 예를 들어, BT7는 컴퓨터에 IP 주소를 임대하지 않았다. 트래픽의 비정상적인 양을 발견하고 터널을 죽였다.

** 사업 투입
다음과 같이 추가 작업이 2 일 날 블루 팀에게 주어졌다.
1.고객은 새로운 웹 사이트를 (반복) 호스팅하는 블루 팀에게 연락했다.
2.데이터 보호 기관 손상되었을 수 있는 민감한 개인 데이터가 있다며 정보를 요청했다.
3. 블루 팀은 전화로 인터뷰를 했다. 변조 및 데이터 도난에 대한 상황이 있었기 때문에 많은 압력을 추가하지 않았고 단계적으로 확대했다고 공개했다. SCADA 공격은 좋은이야기를 만들었지만, 미디어 참여가 너무 늦게 발생했을 수 있었다.

 

** 결론

1.커스텀 웹 프로그램이 취약해서 8개의 블루팀이 성공적인 해킹을 피할 수 없었다. 
2.인프라 문제로 몇 번이나 게임을 방해했다.
3.SCADA 시나리오는 너무 기술적이서 모든 블루팀이 힘들었다.
4.표준 맬웨어 방지 도구와 좋은 모니터 도구는 클라이언트 측 공격을 성공적으로 막았다. 어떤 블루 팀도 방지, 탐지 및 공격을 완화하는 유일한 방법이나 기술을 살펴볼 수 없었다. 

 

 * 패치 시스템

 * 시스템 하드닝

 * 접근 제어를 강화해라. 불필요한 사용자 계정을 제거해라, 파일 접근 권한을 변경해라
 * 심한한 서비스를 제거하라. 취약한 서비스는 다른 벤터 제품으로 대체하라.
 * 네트워크 웹 어플리케이션의 취약점을 스캔하라.
 * 백도어와 루트킷을 찾아서 제거해라.
 * 안티바이러스 소프트웨어가 설치된 워크 스테이션을 보호해라.

 * 그리고 모니터링 툴을 사용하여 악의적인 행위를 탐지해라.
 * 보안 이벤트와 로그를 수집 및 분석해라.
 * IDS/IPS 시스템을 설치: Snort.  
 * 빠른 핵을 가진 악의적인 입력을 필터해라.
 * 취약점 소스코드를 수정해라
 * DoS 공격을 막기위해 어플리케이션 앞단에 reverse 프록시를 배치
 * 웹 페이지를 변경할 때 경고를 트리거 해라. (홈페이지 무결성 체크)
 * 서로 정보를 공유해라: 공격과 의심스러운 ip를 탐지하는 방법, 취약점 수정방안, 백도어 탐지 방법