我试图了解模糊未知协议的复杂之处,以定位应用程序中的漏洞。我正在使用一个众所周知的易受攻击的应用程序,磁盘精明的企业10.4.18,其中有一个已知的SEH缓冲区溢出。
我目前有一个波弗兹脚本,我正在尝试使用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下面是我的模糊机器上的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正在做我想做的所有事情,减去重新启动。
我可以提供更多的信息,如果这还不够,我将感谢任何我可以得到的帮助。
谢谢!
发布于 2018-04-12 06:07:23
由于process_monitor.py已过时,因此该方法不存在;请从波弗兹下载最新副本,然后再试一次。
感谢您在问题中提供的详细调试信息。如果process_monitor.py打印了堆栈跟踪,包括这也会有所帮助。:)
我在代码库中搜索了“PED> remote”,并在第2行( boofuzz/pedrpc.py )(permalink)中找到了它:
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应该可以做到这一点。
如果进程监视器宣布了它的版本,这可能会被避免;我提交了问题。
https://stackoverflow.com/questions/49722029
复制相似问题