我试图了解模糊未知协议的复杂性,以找出应用程序中的漏洞。我使用了一个公开的易受攻击的应用程序Disk Savvy Enterprise 10.4.18,它有一个已知的SEH Buffer Overflow。
我目前有一个boofuzz脚本,我试图利用process_monitor.py
脚本,但无法重启崩溃的服务。我在目标计算机上运行process_monitor.py
,并从我的模糊测试机成功连接到它。我的问题是问题标题中的错误 - 当应用程序崩溃时,它会尝试'重启过程,但我收到错误
PED-RPC> remote method restart_target cannot be found
我的python脚本的相关位是:
session = sessions.Session(
crash_threshold="10000", # Arbitrary, high crash threshold
check_data_received_each_request=0, # Don't check data after every request (slow)
restart_sleep_time=0.1,
sleep_time=0.1,
)
# Define target
target = sessions.Target(
connection = SocketConnection(dst, dport, proto='tcp')
)
# Define procmon options
target.procmon = pedrpc.Client(dst, 26002)
target.procmon_options = {
"proc_name" : "disksvs.exe",
"stop_commands" : ['net stop "Disk Savvy Enterprise"'],
"start_commands" : ['net start "Disk Savvy Enterprise"']
}
我使用以下行在目标计算机上启动process_monitor.py
:
python process_monitor.py --port 26002 --crash_bin diskSaavy_Crashes.txt
这里产生的输出一旦开始,然后崩溃:
Couldn't import dot_parser, loading of dot files will not be possible.
[03:11.00] Process Monitor PED-RPC server initialized:
[03:11.00] crash file: C:\Python27\Lib\site-packages\boofuzz\diskSaavy_Crashes.txt
[03:11.00] # records: 3
[03:11.00] proc name: None
[03:11.00] log level: 1
[03:11.00] awaiting requests...
[03:23.29] updating target process name to 'disksvs.exe'
[03:23.30] updating stop commands to: ['net stop "Disk Savvy Enterprise"']
[03:23.30] updating start commands to: ['net start "Disk Savvy Enterprise"']
[03:23.30] debugger thread-1523215410 looking for process name: disksvs.exe
[03:23.42] debugger thread-1523215410 found match on pid 2908
[03:23.48] updating target process name to 'disksvs.exe'
[03:23.48] updating stop commands to: ['net stop "Disk Savvy Enterprise"']
[03:23.48] updating start commands to: ['net start "Disk Savvy Enterprise"']
[03:23.49] debugger thread-1523215410 caught access violation: 'libpal.dll:004a9
19f movsx ebp,[eax+ebx] from thread 2424 caused access violation'
[03:23.49] debugger thread-1523215410 exiting
PED-RPC> remote method restart_target cannot be found
这是我在fuzzing机器上boofuzz的输出,同样的崩溃:
[2018-04-08 15:23:49,996] Test Step: Failure summary
[2018-04-08 15:23:49,996] Info: procmon detected crash on test case #2: libpal.dll:004a919f movsx ebp,[eax+ebx] from thread 2424 caused access violation
[2018-04-08 15:23:49,996] Test Step: restarting target
[2018-04-08 15:23:49,996] Info: restarting target process
[2018-04-08 15:23:50,206] Error!!!! Restarting the target failed, exiting.
Traceback (most recent call last):
File "./boofuzz-diskSaavy.py", line 72, in <module>
main()
File "./boofuzz-diskSaavy.py", line 17, in main
fuzz(dst, dport)
File "./boofuzz-diskSaavy.py", line 69, in fuzz
session.fuzz()
File "/usr/local/lib/python2.7/dist-packages/boofuzz/sessions.py", line 414, in fuzz
self._fuzz_current_case(*fuzz_args)
File "/usr/local/lib/python2.7/dist-packages/boofuzz/sessions.py", line 893, in _fuzz_current_case
self._process_failures(target=target)
File "/usr/local/lib/python2.7/dist-packages/boofuzz/sessions.py", line 603, in _process_failures
self.restart_target(target)
File "/usr/local/lib/python2.7/dist-packages/boofuzz/sessions.py", line 680, in restart_target
raise sex.BoofuzzRestartFailedError()
boofuzz.sex.BoofuzzRestartFailedError
我尝试了start_commands
的不同版本,不发送proc_name
或stop_commands
,并且指定了process_monitor.py
,start_commands
,例如在服务名称周围包括net.exe
的完整路径和引号的不同转义等。到目前为止,我没有尝试过任何工作。
查看sessions.py
,pedrpc.py
和其他多个文件,我发现正在使用__getattr__
来处理方法调用,但从我所看到的情况来看,restart_target
存在于sessions.py
,所以我不确定为什么PEDRPC说明找不到restart_target ...我把头发拉了出来。 boofuzz正在做我想做的一切,减去重启。
如果这还不够,我可以提供更多信息,我很感激我能得到的任何帮助。
谢谢!
答案 0 :(得分:1)
TL; DR由于process_monitor.py
已过期,因此该方法不存在;从boofuzz下载最新的副本,然后重试。
感谢您提出问题中的详细调试信息。如果process_monitor.py打印了一个堆栈跟踪,包括那也有帮助。 :)
我在代码库中搜索了&#34; PED-RPC&gt;远程&#34;并在第2行(permalink)的boofuzz/pedrpc.py
中找到它:
sys.stderr.write('PED-RPC> remote method "{0}" of {1} cannot be found\n'.format(method_name, self))
注意略有差异,输出中不存在小of {1}
。这表明你的process_monitor.py来自旧版本的boofuzz。 git blame
显示此更改发生在e4723204d43bd758077f56df419af1c7c7424f14,最初包含在v0.0.8中。
下载最新的process_monitor.py
应该可以解决问题。
如果流程监视器宣布其版本,则可能已经避免了这种情况;我提交了an issue。