25개의 GPU 를 이용해 6시간안에 윈도우 패스워드를 깨트린다고 ?

패스워드 해쉬 크랙 관련하여 몇 개의 글을 포스팅 했었는데요, 작년12월에 나왔던 것을 이제야 하나 보게되었습니다. 재미있는 내용인데 그 내용인즉 25개의 GPU 를 이용해 윈도우 패스워드는 6시간 이내에 깨트릴 수 있다는 것입니다.

성능이 대단하죠? 초당 3500 억개를 연산할 수 있다고 합니다. MS 윈도우 제품중 NTLM 암호화 알고리즘을 사용하는 해쉬를 대상으로 한 것으로 패스워드 구성은 8 자 이내로 대문자/소문자, 숫자, 특수기호 등을 모두 포함한 것입니다. 이런 형태가 일반적으로 기업에서 사용하는 범주의 암호 형태이지요.

시스템은 5개의 4U 서버를 이용했고, 리눅스 기반으로 GPU 클러스트를 구성했습니다. 25개의 AMD Radeon GPU (HD7970, HD5970, HD6990, HD5870) 가 이용되었고 사용된 전략만도 7kW 라고 하네요.

한 컴퓨터에서 25개의 GPU 를 이용할 수 있는 없기 때문에 클러스트 구성을 한 것이고요 Virtual OpenCL 클러스트 플랫폼을 이용해 5개의 서버의 GPU 가 하나의 로컬 컴퓨터에 있는것 같이 구현한 것입니다. 패스워드 해쉬에 사용한 프로그램은 ocl-Hashcat Plus 로 GPU 를 지원하면서 무료로 이용할 수 있습니다.

이전에 테스트 하였던 컴퓨터는 Radeon HD6990 4개를 이용해 NTLM 해쉬에 대해 초당 880 억개를 했다고 하는데, 이전에 비하면 속도가 4배 가까이 증가한 것입니다. 일전에 링크드인 패스워드가 유출된 적이 있었습니다. 그 당시 그 패스워드 해쉬를 크랙하는데 650 만개의 패스워드중 90% 가 크랙되었다고 합니다. 그만큼 사용자들이 패스워드를 단순한 조합으로 사용하고 있다는 뜻이기도 합니다.

이전의 포스팅에서도 언급했듯이 패스워드를 사용시 어렵게 구성해야 합니다. 그러나, 현실은 쉽지 않죠 ^^
너무나 많은 사이트들에서 패스워드를 요구하다 보니 일일이 다 다르게 만들기도 힘들고 어렵게 하자니 외우기도 힘들어지고요. 그러다 보니 패스워드를 쉽게 만들어 사용하는 경우가 많은데, 이런 걸 보면 생각이 바뀌시지 않나요 ? :-)

[관련 포스팅]

2013년03월13일 15기가의 1,493,677,782 패스워드 단어 사전 공개 
2011년07월14일 분산 기반의 CPU/GPU 해쉬 크랙 프로젝트 'Durandal'
2010년09월15일 8자리 패스워드는 저리가~ 12자리 패스워드를 사용하자 
2010년11월23일 당신의 패스워드는 안전한가? 클라우드 기반 패스워드 크랙킹
2010년12월01일 자바스크립트기반의 분산 해쉬 크랙킹


[참고]
1. Password Cracking HPC, Passwords^12 보안 컨퍼런스
http://passwords12.at.ifi.uio.no/Jeremi_Gosney_Password_Cracking_HPC_Passwords12.pdf
2. ocl-Hashcat Plus
http://hashcat.net/oclhashcat-plus/
3. 관련 기사
http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/

VMware Workstation 설치 컴파일 오류(SPIN_LOCK_UNLOCKED)

VMware 7.1.4 리눅스 버전을 설치하면서 발생하는 에러에 대해 공유하고자 한다. VMware Workstation 최신 버전은 9 이다. 그러나, 정식적으로 사용 가능한 라이센스는 7 버전을 보유하고 있기에 7.1.4 를 설치하였다. (물론, 많은 경우는 무료로 사용 가능한 VirtualBox 를 사용하지만..)

설치하는 도중에 아래 그림과 같이 Error 메시지를 출력한다.

자세한 에러 메시지를 보면

"Unable to build kernel module.
See log file /tmp/vmware-root/setup-29550.log for details"

와 같았다. 로그파일을 살펴보면 특정 파일을 컴파일 하는 과정에서 발생하는 것이고, 이것을 수동으로 컴파일 해보면 다음과 같은 과정이다.

root@:/tmp/vmware-root# /usr/bin/make -C /tmp/vmware-root/modules/vmmon-only auto-build SUPPORT_SMP=1 HEADER_DIR=/lib/modules/3.0.0-22-generic/build/include CC=/usr/bin/gcc GREP=/usr/bin/make IS_GCC_3=no VMCCVER=4.6.1
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-root/modules/vmmon-only'
make -C /lib/modules/3.0.0-22-generic/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
 MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-headers-3.0.0-22-generic'
  CC [M]  /tmp/vmware-root/modules/vmmon-only/linux/driver.o
/tmp/vmware-root/modules/vmmon-only/linux/driver.c:783:59: error: ‘SPIN_LOCK_UNLOCKED’ undeclared here (not in a function)
make[2]: *** [/tmp/vmware-root/modules/vmmon-only/linux/driver.o] Error 1
make[1]: *** [_module_/tmp/vmware-root/modules/vmmon-only] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.0.0-22-generic'
make: *** [vmmon.ko] Error 2
make: Leaving directory `/tmp/vmware-root/modules/vmmon-only'

SPIN_LOCK_UNLOCKED 가 선언되지 않았다고 계속 나타나는 문제였다. 관련 내용을 구글링 해보고 다음 패치파일을 찾을 수 있었다.

패치파일 다운로드 받기 : http://weltall.heliohost.org/wordpress/wp-content/uploads/2011/08/fullvmwarelinux310patch.tar.gz

패치를 실행해 보았다. 그러나 다음과 같은 메시지만 계속 출력된다.

# ./patch-modules_2.6.39.sh
Sorry, this script is only for VMWare WorkStation 7.1.5 or VMWare Player 3.1.5. Exiting

분명 패치파일에는 7.1.4 버전도 분명 명시되어 있었다. 스크립트 파일을 살펴보니

[ "$vmver" == "workstation$vmreqver2" ] && product="VMWare WorkStation"
[ "$vmver" == "player$plreqver2" ] && product="VMWare Player"

와 같이 vmreqver2 를 참고하는 변수가 있지만 실제 스크립트에는 없다. 아래와 같이 스크립트가 변경이 필요하다.

vmreqver=7.1.4
plreqver=3.1.4
vmreqver=7.1.5
plreqver=3.1.5

를 다음과 같이 변경하였다.

vmreqver=7.1.4
plreqver=3.1.4
vmreqver2=7.1.5
plreqver2=3.1.5

그리고 다시 패치 스크립트를 실행하면 깔끔하게 실행이 된다.

# ./patch-modules_2.6.39.sh
patching file vmblock-only/linux/dentry.c
patching file vmblock-only/linux/filesystem.c
patching file vmci-only/linux/driver.c
patching file vmmon-only/linux/driver.c
patching file vmmon-only/linux/hostif.c
patching file vmmon-only/linux/iommu.c
patching file vmnet-only/compat_netdevice.c
.
.
.
Built vsock module
Starting VMware services:
   VMware USB Arbitrator                                               done
   Virtual machine monitor                                             done
   Virtual machine communication interface                             done
   VM communication interface socket family                            done
   Blocking file system                                                done
   Virtual ethernet                                                    done
   Shared Memory Available                                             done


All done, you can now run VMWare WorkStation.
Modules sources backup can be found in the '/usr/lib/vmware/modules/source-workstation7.1.4-2012-10-09-15:04:41-backup' directory


자, 이제 패치가 완료되었으니 VMware 를 다시 재 설치 진행해 주면 에러 발생없이 깨끗하게 설치가 진행된다. 참고로 VMware 7.1.6.744570 버전도 해당 패치를 반영하여 사용이 가능하다. 패치 적용시 후반에 약간의 오류가 있긴 하지만 VMware 를 실행하면 커널 컴파일 하는 GUI 화면에서 제대로 진행이 계속된다.

참고로, VMWare 를 설치한 파일은 "VMware-Workstation-Full-7.1.4-385536.x86_64.bundle" 이며, 커널은 3.0.0-22 이었다. (64비트)

혹시, 같은 에러를 경험할 사용자를 위해 해결책을 공유한다.

VMWare 에서 지정한 스냅샵이 동작하지 않는 경우

VMWare 가상 머신 중 하나가 동작이 이뤄지지 않았다. 에러메시지는 아래와 같았다:

Detected an invalid snapshot configuration

File <unspecified filename>was not found

아무 문제없이 잘 동작하던 가상 머신에 왜 이런일이 나타난 것일까? 콘솔로 로그인 하여 검토하던 중 vmx 파일에서 문제를 발견하였다.

vmx 파일 내용중 가상머신 파일인 vmdk 를 지정한 부분이 있다.

scsi0:0.fileName = "VirtualMachine-000001.vmdk"

실제 존재하는 vmdk 는 000002 였으나, 어찌된 영문인지 000001로 되어 있었다.  000002로 변경하고 가상머신을 동작시키니 정상적으로 동작한다.

무슨 이유에서인지, fileName 에 지정한 vmdk 가 존재하지 않는 것으로 변경이 되어 있었던 것이다.
혹시 위와 같은 메시지를 보게되면 살펴보기 바란다.

VMWare ESX 볼륨 디스크를 변경하는 경우, 이미지 재 설정하기

VMWare ESX 를 사용하는 도중, 마운트된 볼륨 한개의 하드디스크를 교체할 이유가 있었다. 단순한 생각으로는, 새로 들어가는 디스크에 똑같이 그대로 복사해 주면 일단 동작할 수 있지 않을까 생각했다. 새로 다시 이미지를 생성하는 일은 힘들기 때문에 어찌되었든, 기존 이미지를 그대로 유지해야만 했다.

이미지를 카피만 한 후, vSphere 클라이언트에서 확인해 보면 기 존재했던 가상머신 리스트들이
Unknown (inaccessible) 하고 흐릿하게 되어 있었다. 즉, 실행을 시킬 수 없다. 일단,
콘솔로 로긴하여 볼륨을 확인했다.

아래것은 기존에 존재하던 볼륨의 출력화면인데, Storage4 가 교체된 디스크이다.
drwxr-xr-t 1 root root 4060 Dec  2 11:49 4cf5def9-58109560-9ac8-0022196ba845
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage1 -> 4bdad755-e0b14358-4a7f-00[삭제]843
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage2 -> 4bdfd27b-72617197-994f-00[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage3 -> 4bdeccc2-cb8a6f83-4f2a-00[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 13:59 Storage4 -> 4cf5def9-58109560-9ac8-00[삭제]845

아래와 같이 확인해 보면 새로 구성한 볼륨의 UUID 값이 변경되었다.

# ls -l /vmfs/volumes/
total 4096
drwxr-xr-t 1 root root 5460 Dec  2 19:09 4bdad755-e0b14358-4a7f-00[삭제]843
drwxr-xr-t 1 root root 2940 Dec  6 14:15 4bdeccc2-cb8a6f83-4f2a-00[삭제]845
drwxr-xr-t 1 root root 5740 Dec  2 12:14 4bdfd27b-72617197-994f-00[삭제]845
drwxr-xr-t 1 root root 1120 Dec  6 15:41 4cfc855d-9bad2bdf-bb1b-00[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage1 -> 4bdad755-e0b14358-4a7f-0[삭제]843
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage2 -> 4bdfd27b-72617197-994f-0[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage3 -> 4bdeccc2-cb8a6f83-4f2a-0[삭제]845
lrwxr-xr-x 1 root root   35 Dec  6 16:11 Storage4 -> 4cfc855d-9bad2bdf-bb1b-0[삭제]845

Storage4 번에 있던 이미지들이 제대로 엑세스 할 수 없는 환경임을 추정해 볼 수 있다.
아래 경로의 xml 파일을 확인해 보면, 각 가상머신에 대한 경로가 기록되어 있다.

/etc/vmware/hostd/vmInventory.xml

해당되는 디스크에 속해있던 디스크 UUID 값으로 변경해주고,

  <ConfigEntry id="0084">
    <objID>2864</objID>
    <vmxCfgPath>/vmfs/volumes/4cfc855d-9bad2bdf-bb1b-00[삭제]845/Image110/Image110.vmx</vmxCfgPath>
  </ConfigEntry>

다시 재 반영해 주기 위해 mgmt-vmware 를 통해 재시작을 시켜주었다.

# ./mgmt-vmware restart
Stopping VMware ESX Management services:
   VMware ESX Host Agent Watchdog                          [  OK  ]
   VMware ESX Host Agent                                   [  OK  ]
Starting VMware ESX Management services:
   VMware ESX Host Agent (background)                      [  OK  ]
   Availability report startup (background)                [  OK  ]

이후 vSphere Client 프로그램을 통해 보면 기존에는 접근할 수 없었던 이미지가 이제 접근이 된다. 파워온을 하면 한가지 confirm 을 요청하는 것을 물어보고

OK 를 해주면 이제 정상적으로 동작이 된다. 디스크를 교체하게 되면서, 빠르게 기존 이미지를 그대로 복구할 수 있는 방법을 찾다보니 그냥 이렇게 간단히 문제가 해결될 수 있다.

비슷한 경우를 겪는 분들이라면 참고하길 바란다.

리눅스 시스템에서 내 CPU가 가상화를 지원하는지 알고 싶다면?

내가 사용하는 리눅스 시스템이 가상화를 지원하는 CPU 를 사용하고 있는지 알고 싶다면, /proc/cpuinfo 를 통해 쉽게 확인할 수 있다.

아래와 같은 명령어로 /proc/cpuinfo 에서 vmx 또는 svm 이 있는지 확인하면 된다.

# egrep '(vmx|svm)' /proc/cpuinfo
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr dca sse4_1 sse4_2 popcnt lahf_lm ida
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr dca sse4_1 sse4_2 popcnt lahf_lm ida

필자가 사용하는 경우는 vmx 를 확인할 수 있는데, 인텔기반의 경우 vmx 라 나오고, AMD 는 svm 이다. 그리고, BIOS 에서 살펴보면 CPU 설정에서 가상화 지원 Enable, Disable 설정을 할 수 있는데, 가상화 서비스를 이용하고자 한다면 BIOS 에서 CPU 가상화지원을 Enable 하도록 설정하여야 하는데. 내가 겪어본 경우는 기본이 Disable 되어 있다.

--color 옵션을 주게되면 매칭되는 부분이 색깔이 바뀌어 나오므로 쉽게 알 수 있다. egrep 의 -c 옵션은 카운트를 나타내므로, 16개의 CPU 가 잡힌 것으로 나온다.
# egrep '(vmx|svm)' --color=auto -c /proc/cpuinfo
16

다음은 집에서 사용하는 나의 오래된 컴퓨터를 확인해 본것인데, 역시나 없다. 물론 없는건 이미 알고 있었지만 ;-)


flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx fxsr_opt rdtscp 3dnowext 3dnow up pni cr8_legacy

ESXi 4.x 패스워드 길이 조절하기

VMWare ESX 3 버전대에서 패스워드 길이를 짧게 사용하고 있었다면 4.1 에서는 난관에 부딪히게 될 것이다. 보안이 좀더 강화되어, 패스워드를 좀더 복잡하게 사용하여야 하기 때문이다.

짧은 패스워드를 입력하게 되면 아래와 같은 메시지를 보게된다.

Weak password: not enough different characters or classes for this length.

Try again.

패스워드를 안전하게 사용하는 것이 바람직 하지만, 굳이 그렇지 않게 사용되는 시스템도 있다. ESX3 버전대와 마찬가지로 간단하게 패스워드를 이용할 수는 없을까? 물론, 방법은 있다. 다음의 경로를 찾아 파일을 열어보자

/etc/pam.d/system-auth

아래와 같은 내용을 볼 수 있는데, min=8,8,8,7,6 과 같은 부분이 보일것이다. 그렇다 딱 이부분만 봐도 추측이 되지 않는가? 유닉스 시스템을 많이 접해본 사용자라면 이것이 무엇인지는 알 것이다.

#%PAM-1.0

auth       required     /lib/security/$ISA/pam_access.so

auth       required     /lib/security/$ISA/pam_per_user.so  /etc/security/login.map

account    required     /lib/security/$ISA/pam_per_user.so  /etc/security/login.map

session    required     /lib/security/$ISA/pam_per_user.so  /etc/security/login.map

password   requisite    /lib/security/$ISA/pam_passwdqc.so retry=3 min=8,8,8,7,6

password   sufficient   /lib/security/$ISA/pam_unix.so use_authtok nullok shadow

password   required     /lib/security/$ISA/pam_deny.so

패스워드의 최소 길이등을 지정한 것을 변경 해 주면 되는 것이다.  일단 이 파일을 수정전에 아래와 같이 +t 옵션을 추가해 주어야 한다.

# chmod +t /etc/pam.d/system-auth

# ls -l /etc/pam.d/system-auth

-r--r--r-T    1 root     root                623 Dec  2 02:25 system-auth

그리고 파일을 수정하는데, 다음과 같이 변경해 주면 된다.


password   requisite    /lib/security/$ISA/pam_passwdqc.so retry=3 min=0,0,0,0,0

이후 패스워드를 변경해 보면, 이전과 같는 달리 좀더 짧은 패스워드를 사용할 수도 있다.

/etc/pam.d # passwd

Changing password for root

You can now choose the new password or passphrase.

A good password should be a mix of upper and lower case letters,

digits, and other characters.  You can use a 0 character long

password.

A passphrase should be of at least 3 words, 0 to 40 characters

long, and contain enough different characters.

Alternatively, if noone else can see your terminal now, you can

pick this as your password: "pengr-vaphe_ohggba".

Enter new password:

Re-type new password:

passwd: password updated successfully

ESX 의 파일명은 system-auth-generic 로 약간 다르다. 좀다 자세한 것은 아래 참고를 살펴보기 바란다.

[참고]
1. ESX and ESXi 4.x password requirements and restrictions

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012033

ESXi 4.1 에서 SSH 기능 사용하기

얼마전 VMWare ESXi3 에서 SSH 접근하여 사용할 수 있는 방법에 소개했다. ESX 4 버전대에서는 이런 방식이 조금 달라졌다. ESXi 4 버전을 설치했다면, vSphere Client 를 통해 접속후
Configuration -> Security Profile -> Properties 를 보면 아래와 같은 화면을 볼 수 있다.

Remote Tech Support 를 클릭하여 시작해 주면 상태가 Running 으로 변경된다. 이외 콘솔화면에서는 Troubleshooting Mode 를 클릭하면 다음과 같은 화면을 볼 수 있고 마찬가지로 Remote Tech Support 를 Enable 해 주면 된다. (아래 화면은 현재 Enable 되어 있는 상태이다)

SSH 로 접근은 필요에 따라 유용하게 사용될 수 있을 것이다.

[참고]
1. Using Tech Support Mode in ESXi 4.1
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1017910

2. VMWare ESX3i 에서 SSH 로 접근하여 사용하기!
http://www.packetinside.com/2011/01/vmware-esx3i-ssh.html

VMWare ESX3i 에서 SSH 로 접근하여 사용하기!

VMWare ESXi 는 무료로 사용가능한 가상화 솔루션이다. VMWare Workstation 과 달리 안정적으로 대량의 가상 머신을 운영하기에는 적절한 방법이다. 리눅스 커널을 기반으로 만들어진 것이며, 최근버전은 ESXi 4.1 버전이다. 3i 버전도 필요에 따라 유용하며, 이에 ESXi 3 버전에 대한 루트 접근 방법을 소개한다.

이미 ESXi 를 사용하는 사용자라면 루트권한을 획득하기 위한 방법을 많이 알고 있을 것이다.
가상화를 이용한 프로젝트도 진행하고 있으며, 개인적으로 관심도 많기 때문에 앞으로 패킷인사이드에서는 가상화에 대한 부분도 다뤄볼까 한다.

ESXi 는 원격에서 클라이언트 프로그램을 통해 접속을 하게 되며, 직접적으로 쉘로 접근하는 방법은 제공하지 않는다. 하지만, 접근할 수 있는 방법이 있으므로 이를 이용하면 여러분들이 원하는 형태로 제법 운영 가능하다.

루트로 접근하기 위해서는 다음과 같은 방법을 사용한다.

1. 구동된 화면 ESXi 콘솔 에서 (회색과 노란색 화면) ALT + F1 을 누른다.
2. 여기서 unsupported 라고 입력한다. 이때 타이핑 하는 것은 나타나지 않는다.
3. 올바르게 입력하면 다음과 같은 접속 화면을 볼 수 있다.

4. SSH 를 enable 하기 위해 /etc/inetd.conf 를 수정해야 한다.

vi /etc/inetd.conf

5. ssh 를 서치해 보면 ssh 가 # 으로 주석처리 되어 있다. 이 주석을 제거해 주면 된다.

#ssh   stream   tcp   nowait   root   /sbin/dropbearmulti   dropbear

6. 저장하고 빠져 나간다음 서비스를 재 시작해 준다. SSH 가 enable 되었으므로, 원격지에서

VMWare ESXi 가 설치된 IP 로 접속을 시도하면 된다. ( ssh root@esxi ip )

/sbin/services.sh restart

* 업데이트 버전에 따라서 달라질 수 있는데, 만약 접속이 제대로 이루어 지지 않는다면

ps | grep inetd 

로 inetd 프로세스를 찾아 kill -HUP 로 inetd 를 재 구동해준다.

7. ALT + F2 를 누르면 다시 원래의 GUI 화면으로 이동한다.

자! 이제 쉘로 접근하여 원하는 형태대로 동작시켜보면 된다. 커맨드로 제어할 수 있는 명령어 등이 있으므로, 필요에 따라 적절하게 사용하면 된다.