IPMI를 탐색하기 위해 소프트웨어를 몇 개 작성했습니다. 여기에 그 결과 중 일부를 정리했습니다. 평소처럼 탐지(detect), 데이터 수집(get data), 감사(audit)의 사이클을 밟아 보려고 했습니다. 이 각각은 그 자체로 꽤 흥미로운 문제였습니다. 적어도 제게는요.

IPMI 웹 사이트

http://fish2.com/ipmi에서 제공하는 논문과 자료들입니다.

html

비밀번호 크래킹

원격 BMC의 계정을 추측하고, 해당 해시를 추출한 다음, (HMAC 해시된) 비밀번호를 크랙하려고 시도하는 작은 Perl 프로그램입니다. 궁금하신 분들을 위해 이에 대해 간단히 작성해 두었습니다. 주석이 많이 달려 있어 어느 정도 유용할 수도 있습니다.

Cipher 가져오기

IPMI 사양에 따르면 인증 없이도 원격 시스템의 암호화 스위트(cipher)를 얻을 수 있다고 되어 있지만, 실제로 이를 수행하는 도구는 알지 못합니다. (모두 인증을 요구합니다. 물론 원한다면 원시 hex 바이트를 직접 입력할 수도 있겠지만요!) 그래서 이 작은 도구를 작성했습니다. 대부분 ipmitool의 출력 형식을 따르려고 했는데, 그 과정에서 해당 유틸리티의 버그를 하나 발견한 것으로 보입니다. (마지막 줄에서 때때로 시스템이 잘못 해석되는 것처럼 보이는 쓰레기 값을 출력합니다.) 하지만 누가 알겠습니까, 테스트할 만큼 충분한 시스템이 없네요. 어쨌든... ipmi-get-ciphers.py.

최소한 Cipher0 시스템을 찾아내는 데는 유용합니다. (참고 - 이것은 단지 지원되는 암호화 스위트를 알려줄 뿐이며, 실제로 활성화되어 있다는 뜻은 아닙니다.) 하지만 현장에는 흥미로운 것들이 많습니다.

인증 세부 정보 가져오기

여기 두 개의 프로그램이 있습니다. 하나는 간단한 Python 원격 프로버입니다. (솔직히 말하면 Perl이 이제 좀 싫어지기 시작했습니다.) 다른 하나는 FreeIPMI의 유틸리티를 사용하여 자격 증명이 필요한 구성 데이터를 가져옵니다.

단일 패킷을 BMC에 보내고 응답을 분석하는 작은 Python 프로그램입니다. (인라인 주석이 50% 이상이며, gzip 기준 2.5k입니다.) 패킷 하나로 무엇을 할 수 있냐고 물을 수도 있겠네요? 우선 IPMI에 대한 10가지 이상의 서로 다른 보안 테스트를 할 수 있습니다. 뭐, 처음부터 끝까지 어디까지나 패킷 하나일 뿐이지만요 :) 실행하려면 python, BMC, 그리고 UDP 포트 623으로의 열린 경로가 필요합니다. 사용법은 간단히 "ipmi-get-auth.py target"입니다.

ipmi-get-auth.py / 아주 간단한 설명

이걸 극한까지 밀어붙이자면... 뭐, 위 프로그램의 일종의 메가 버전으로, 모든 채널, 모든 권한(priv), 모든... 음, 대충 감이 오시죠. 단일 집착형(monomaniacal) 사용자를 위한 것입니다. (왜 이런 일을 하는지 알고 싶다면 주석이나 제가 쓴 글을 읽어보세요!)

mega_chan.py / 메가 메가 메가 ... 찬 찬 찬...

장치 ID(GUID) 가져오기

그리고 여기 시스템에 Get Device ID 패킷(IPMI v2 사양의 p250 참조)을 보내는 간단한 프로그램이 있습니다. 이론상으로는 인증 없이 동작해야 합니다. 제가 간단히 조사해 보니 약 90%의 시스템이 이에 응답했습니다. (전부 유효한 정보를 보내는 것은 아니었지만요!) 때로는 공급업체(vendor), 모델 번호 등의 정보를 얻을 수 있습니다. 하지만 더 흥미로운 것은 고유 ID를 실제로 얻을 수 있다는 점입니다. 전통적으로 네트워크를 통해 얻기가 어려운 것이었죠.

get-ipmi-guid.py / Get Device ID

SuperMicro 바이너리 비밀번호 파일에서 비밀번호 덤프하기

Supermicro는 BMC에서 비밀번호 파일이 유출되는 문제를 몇 차례 겪었습니다. 예를 들어 다음 글과 다른 글들을 참고하세요.

a-penetration-testers-guide-to-ipmi

이 스크립트를 사용하려면 다음과 같이 입력하기만 하면 됩니다:

dump_SM.py password_file

저는 잘 동작했습니다. 보증은 없습니다. 보장도 없습니다. 등등.

탐지

UDP 포트 623과 통신할 수 있다면 원격 시스템이 IPMI를 실행 중인지 알아내는 것은 꽤 간단합니다. 하지만 데이터 센터 내부가 아니라면 대부분의 사람들은 UDP를 차단합니다. 그리고 차단하지 않더라도... UDP 스캔은 상상할 수 있는 한 가장 느립니다. 그래서 현재 저는 두 가지 기본 방법을 사용하고 있습니다. 유서 깊은 Nmap과 ipmiping(FreeIPMI GNU 도구)을 활용하는 것입니다. 가장 쉬운 방법은 다음과 같습니다.

ipmiping을 사용하여 원격 시스템이 IPMI를 지원하는지 물어봅니다. 긍정적인 응답은 시스템이 IPMI를 지원한다는 가장 강력한 신호입니다. (하지만 확실한 것은 아무것도 없습니다!) 더 기술적으로 말하면, UDP 포트 623의 Get Channel Authentication Capabilities 요청 데이터그램을 통해 두 번의 IPMI Get Channel Authentication Capabilities 호출을 보냅니다. (UDP를 사용하므로 연결이 보장되지 않기 때문에 두 번 요청합니다.)
```
</p> <p>

Nmap이 대규모 네트워크 스캔에서 ipmiping보다 훨씬 효율적이기 때문에, 이 방법은 Nmap이 해당 호스트의 UDP 623이 열려 있다고 알려줄 때만 사용합니다.

</p> <p>

좋든 싫든 이 포트는 자주 차단됩니다. 그래서 대부분의 경우 다른 방법으로 IPMI 실행 여부를 간접적으로 알아내는 편이 더 낫습니다.
```

두 번째 방법은 조금 애매모호하고, 약간의 귀납(일명 추측)에 의존합니다. Nmap은 IPMI 및 공급업체 추가 기능과 연관된 것으로 알려진 포트들을 스캔합니다. UDP 623(기본 IPMI 포트)은 명백하지만, 단독으로는 즉시 답을 주지 못하는 다양한 포트(UDP와 TCP 모두)도 있습니다. 그러나 전체적으로 볼 때 IPMI의 존재를 강하게 시사할 수 있습니다. TFTP, SNMP, SSH/SMASH, VNC 등이 여기에 포함됩니다.

</p> <p>

포트는 그 지표 능력과 Nmap이 해당 포트를 open, filtered 또는 다른 상태로 감지했는지에 따라 가중치가 부여됩니다.

</p> <p>

Nmap은 연결된 서비스의 배너도 보여줄 수 있습니다. 저는 정규 표현식을 사용하여 대상을 찾습니다. 예를 들어 "iLO"와 "DRAC" 문자열은 시스템이 HP의 Integrated Lights Out 서비스(일명 iLO)를 실행 중일 가능성을 알려주는 좋은 지표입니다.

</p> <p>

<strong>참고:</strong> 현재 저는 브로드캐스트 ping 방법(현재 있는 서브넷을 매우 빠르게 훑는 방법)을 사용하지 않습니다. 그 효과성에 대한 데이터가 전혀 없기 때문입니다. 동작할 때는 매우 빠르지만, 임의 스캔이 주는 제어력과 신뢰성을 제공한다고 느끼지 못했습니다. 제 시스템 3대 중 2대(Dell과 HP)는 RMCP ping에 응답했습니다. idiscover(ipmiutil discover)의 브로드캐스트 ping에 응답한 시스템은 없었습니다. 그러나 모두 아래의 Python 감사 도구에는 응답했습니다.

</p> <p>

물론 불행하게도 통신과 네트워크의 유령이 등장합니다. nmap은 포트가 열려 있거나 닫혀 있는 이유에 대해 여러 가지 서로 다른 상태(open, closed, filtered 등)를 알려줍니다. 또 다른 테이블에는 열린 포트가 "(Nmap이 말하듯이) open|filtered" 히트보다 더 많은 점수를 받도록 하는 가중치 세트가 있습니다. nmap을 해석하고 가중치를 적용하는 것은 다소 답답한 일이지만, 어쩔 수 없죠(c'est la vie).


</p> <p>

모든 가중치를 취하고 모든 점수를 합산하면 IPMI 확신 수준이 나옵니다. 임시 테스트에서 15점 이상이면 시스템이 IPMI를 실행 중이라는 강력한 지표라는 것을 발견했습니다.

</p> <p>

현재 저는 여러 임계값(no, possibly, probably, yes)을 사용합니다. 테스트에서 - 제 시스템 외에 다른 서버에 대한 알려진 접근 권한 없이 - 꽤 합리적으로 동작하는 것 같습니다. 즉, 제가 의심스럽다고 생각하는 것들과 위의 기본 사고 모델이 실제로 특정 서버들을 최상위로 끌어올리고 임의의 호스트들은 그대로 두는 것입니다. 다만 오탐(false positive)에는 실질적인 문제가 있습니다. 많은 방화벽이 nmap에게 어떤 포트든 무언가가 있다는 인상을 주는 것 같습니다. (드문 포트를 한두 개 추가하는 것을 고려해 봤습니다. 예를 들어 포트 1이나 31313 같은 것을 듣고 있다면 실제로 그 포트를 *진짜로* 듣고 있을 가능성은 낮으니까요!)

</p> <p>

하지만 이것이 이 주제에 대한 최종 결론은 아닙니다. IPMI 배너에 대한 괜찮은 데이터를 얻는 것은 상당히 간단해야 하며, 제 추측으로는 대량의 시스템을 빠르게 스캔하는 가장 좋은 방법이 될 것입니다.

위 내용을 구현한 Perl 프로그램 네 개가 있습니다. 하나는 스캔하고, 하나는 해석하며, 나머지 두 개는 가중치 계산에 사용됩니다. 이는 프로덕션 스캐너라기보다 연구 도구 또는 개념 증명(proof of concept)이지만, 그럭저럭 합리적인 출력을 만들어 냅니다.

필수: Nmap 버전 6.

사용법은 아주 간단합니다. 다소 특이하긴 하지만요. root로 실행해야 합니다. 많은 출력을 보려면 Verbose(-v)를 사용하세요.

# standard run:
   ./ipmi_scan.pl -A -v -O yes  192.168.0.0/24
# fast
   ./ipmi_scan.pl -tcp -v 192.168.0.0/24
# kitchen sink
   ./ipmi_scan.pl -A -v -O high 192.168.0.0/24

스캔은 대상 이름에 대응하는 결과 파일 한 쌍을 생성합니다. (슬래시는 밑줄로 변환됩니다.) 그냥 그 파일들에 후처리기(post-processor)를 실행하면 됩니다. 숫자 역순 정렬을 거치면 더 흥미로운 순서로 정렬됩니다. 10 초과는 의심스러운 것으로, 20 초과는 IPMI 실행이 거의 확실한 것으로 볼 수 있습니다.

이 경우 출력을 최소한으로 줄이기 위해 terse 플래그(-t)를 사용했습니다.

./post_ipmi_scan.pl -t 192.168.0.0_24|sort -rn
96.3 192.168.0.69
16.25 192.168.0.46
10.8 192.168.0.23
7.33 192.168.0.202
5.4 192.168.0.189
5.4 192.168.0.179
1.7 192.168.0.9
1.23 192.168.0.1
1.1 192.168.0.8
0.9 192.168.0.251
0.63 192.168.0.55
0.43 silent/192.168.0.250
0.2 pi.fish2.com/192.168.0.14
0.2 fierce.fish2.com/192.168.0.6
0.2 192.168.0.88
0.01 192.168.0.16

위 결과에서 상위 3개 시스템은 실제로 IPMI를 실행 중입니다. 하지만 Nmap에 UDP 포트 623이 열려 있다고 알려준 것은 HP뿐이었습니다. 제 Dell과 Supermicro는 더 모호한 "open|filtered" 응답을 반환했는데, 이는 흔히 오탐(false alarm)이 되곤 합니다. 으으. 어쩔 수 없이 감수하고 스캐너와 병렬로 IPMI ping을 수행하는 편이 나을 수도 있습니다. (또는 Nmap에서 제대로 처리하도록 NSE를 작성하거나요.)

감사

FreeIPMI 도구를 사용하여 (a) 서버의 기본 IPMI/BMC 구성을 가져오고 (b) 결과에 대해 살짝 보안 점검을 수행하는 작은 Python 프로그램 두 개가 있습니다.

왜냐하면 제가... 뭐, 사실 특별한 이유는 없습니다. 하나는 python3로, 다른 하나는 python2로 작성했습니다. 아마 여러분의 준비 상태를 시험해 보는 것일 겁니다. 프로그램에는 주석이 상당히 많이 달려 있습니다. 특히 ipmifreely.py를 보면 무슨 일이 일어나는지 자세히 알 수 있습니다. simplejson과 ConfigParser가 필요하며, 그 외 몇 가지가 더 필요할 수도 있습니다.

반드시 FreeIPMI가 설치되어 있어야 합니다. 이 글을 쓰는 시점 기준으로는 Mac과 Windows에서 서버의 멋진 JSON 파일을 가져올 기회가 없습니다. 그리고 정말, 정말 최신 버전이어야 합니다. 경고했다는 말은 하지 말아 주세요. 하지만 삶은 계속됩니다.

데이터 수집은 유효한 자격 증명이 필요한 Python 프로그램(I-check.py)을 통해 수행됩니다. 이 프로그램은 결과를 JSON으로 변환하며, 이 JSON은 감사 도구(ipmifreely.py)로 검사할 수 있습니다. "IPMI-policy.ini"에는 샘플 정책이 들어 있는데, 테스트용 값을 넣어 두었습니다.

I-check.py - IPMI 구성 데이터를 가져옵니다

ipmifreely.py - 위 프로그램의 출력을 파싱하여 몇 가지 결과를 출력합니다

사용 예:

# this grabs the configuration stuff; here I'm using it on an HP iLO 3 server
# the output is redirected to a file
$ ./ipmifreely.py -v -u admin -p admin 192.168.0.46 > hp.json
# This takes the JSON file and looks for issues
$ ./I-check.py drac.json
./I-check.py hp.json 
Host:    192.168.0.46
[bmc-config]   Serial_Channel Non_Volatile_Enable_Pef_Alerting = No
[bmc-config]   Serial_Channel Volatile_Enable_Pef_Alerting  = No
[bmc-config]   Serial_Channel Volatile_Enable_Per_Message_Auth = No
[bmc-config]   Serial_Channel Non_Volatile_Enable_Per_Message_Auth   = No
[bmc-config]   Lan_Conf_Security_Keys  K_G   = 0x0000000000000000000000000000000000000000
[bmc-config]   SOL_Conf Force_SOL_Payload_Authentication = No
[bmc-config]   SOL_Conf Force_SOL_Payload_Encryption  = No
[bmc-config]   Lan_Conf_Auth  Callback_Enable_Auth_Type_None   = Yes
[bmc-config]   Lan_Conf_Auth  Operator_Enable_Auth_Type_None   = Yes
[bmc-config]   Lan_Conf_Auth  OEM_Enable_Auth_Type_None  = Yes
[bmc-config]   Lan_Conf_Auth  Admin_Enable_Auth_Type_None   = Yes
[bmc-config]   Lan_Conf_Auth  User_Enable_Auth_Type_None = Yes
[bmc-config]   Rmcpplus_Conf_Privilege Maximum_Privilege_Cipher_Suite_Id_1 = OEM_Proprietary
[bmc-config]   Rmcpplus_Conf_Privilege Maximum_Privilege_Cipher_Suite_Id_0 = OEM_Proprietary
[bmc-config]   Rmcpplus_Conf_Privilege Maximum_Privilege_Cipher_Suite_Id_2 = OEM_Proprietary
[pef-config]   Community_String  Community_String  = public
[pef-config]   PEF_Conf Enable_PEF_Event_Messages  = No

보안 관점에서 무엇을 점검해야 할지, 제가 좋은 방법이라고 생각하는 것들에 대해 더 자세히 알고 싶다면 IPMI 보안 모범 사례를 확인해 보세요.

인기

ipmi