# MS16-075 HOT Potato 本地提權(問題待研究) ###### tags: `potato提權` `window提權` 關於hot potato 的原理研究,老實說一個禮拜過去了,從原本很自信懂原理,到後面越研究越模糊,對於利用價值來講他已經過時了,我不該專研下去,雖然過程中學到很多有用知識點。 (這題我放棄) 我先講卡關的點網上大致上都只講解簡單的過程,很少有人把真正的攻擊路徑寫的很詳細。 這篇文章指出 https://github.com/xidaner/Freed0m/blob/master/%E7%AC%94%E8%AE%B0/%E5%AE%89%E5%85%A8/OS%E6%B8%97%E9%80%8F/%E5%86%85%E7%BD%91%E6%B8%97%E9%80%8F/%E5%86%85%E7%BD%91%E6%B8%97%E9%80%8F-NTLM%E4%B8%AD%E7%BB%A7%E5%92%8C%E5%8F%8D%E5%B0%84/%E5%86%85%E7%BD%91%E7%9F%A5%E8%AF%86NTLM%E4%B8%AD%E7%BB%A7%E5%92%8C%E5%8F%8D%E5%B0%841-4.md 他最重要的防禦信息: 主機 A 向主機 B(訪問 \\B) 進行 SMB 認證的時候,將 pszTargetName 設置為 cifs/B, 然後在 type 2 拿到主機 B 發送 Challenge 之後,在 lsass 裡面緩存 (Challenge,cifs/B)。 然後主機 B 在拿到主機 A 的 type 3 之後,會去查看 lsass 裡面有沒有緩存 (Challenge,cifs/b),如果存在緩存,那麼認證失敗。 這種情況底下,如果主機 B 和主機 A 是不同的主機的話,那 lsass 裡面就不會緩存 (Challenge,cifs/B)。如果是同一台主機的話,那 lsass 裡面肯定有緩存,這個時候就會認證失敗。 對比文章:(這篇文章滿滿的都是重點) https://shenaniganslabs.io/2019/11/12/Ghost-Potato.html 他裡面有提 http -> smb 的防禦(但好像沒屁用) 理論上,服務器的 LSASS 進程可以跟踪它向試圖通過服務器進程調用 ASC 對其進行身份驗證的客戶端發出的質詢。如果同一 LSASS 進程通過客戶端對 ISC 的調用(以生成相應的響應)收到質詢,該質詢先前已緩存在先前對 ASC 的調用中,那麼 LSASS 將有理由懷疑發生了某種 NTLM 反射。 但是有一個問題;如果發生本地身份驗證,即客戶端和服務器進程都在同一台主機上運行,因此共享 LSASS 實例,則此邏輯將失效。例如,LSASS假設 NTLM 反射已經發生是不正確的http://localhost/webdav/a.png,這僅僅是因為用戶試圖通過 WebDAV 進行身份驗證。在這種情況下,服務器進程(例如,webdavsvc.exe) 將調用 ASC 並傳入一個 NEGOTIATE 消息,獲得一個 CHALLENGE 消息,它期望返回給客戶端。客戶端隨後將調用 ISC,提供 CHALLENGE 消息以獲得響應,此時 LSASS 可以檢查其活動的挑戰緩存。緩存中的條目僅表示客戶端和服務器進程在同一台主機上運行,沒有惡意第三方參與的事實。 --- 後來又對比了 hot potato 攻擊時輸出的信息,我越來越矇開始搞不清楚中間人實際是怎運作的。 ``` Starting NBNS spoofer...WPAD = 127.0.0.1 Exhausting UDP source ports so DNS lookups will fail...Listening... Couldn't bind to a UDP port 500 Couldn't bind to a UDP port 3702 Couldn't bind to a UDP port 4500 Couldn't bind to a UDP port 5004 Couldn't bind to a UDP port 5005 Couldn't bind to a UDP port 5355 Couldn't bind to a UDP port 56026 Couldn't bind to a UDP port 56713 Couldn't bind to a UDP port 60995 Couldn't bind to a UDP port 63108 DNS lookup fails - UDP Exhaustion worked! UDP Ports exhausted... Clearing dns and nbns cache... Got 127.0.0.1 Spoofed target WPAD succesfully... Checking for windows defender updates... Got Request: GET http://127.0.0.1/wpad.dat! Spoofing wpad... Got Request: HEAD http://download.windowsupdate.comhttp//download.windowsupdate. com/v9/1/windowsupdate/redir/muv4wuredir.cab?2304230925! Redirecting to target..http://localhost:80/GETHASHES337444 Got Request: HEAD http://localhost/GETHASHES337444! Sending 401... Got request for hashes... Got Request: HEAD http://localhost/GETHASHES337444! Sending 401... Parsing initial NTLM auth... NTLM TlRMTVNTUAABAAAAB7IIogkACQAwAAAACAAIACgAAAAGAbEdAAAAD0xJQVIyLVBDV09SS0dST1V Q Setting up SMB relay... initSecContext - State 0 initSecContext - State 1 Adding TlRMTVNTUAACAAAAEAAQADgAAAAFwoqi+JzAl4hUdjiQXZkBAAAAAGAAYABIAAAABgGxHQAAA A9MAEkAQQBSADIALQBQAEMAAgAQAEwASQBBAFIAMgAtAFAAQwABABAATABJAEEAUgAyAC0AUABDAAQAE ABsAGkAYQByADIALQBQAEMAAwAQAGwAaQBhAHIAMgAtAFAAQwAHAAgAKtO8l8V12QEAAAAA to queue Got SMB challenge TlRMTVNTUAACAAAAEAAQADgAAAAFwoqi+JzAl4hUdjiQXZkBAAAAAGAAYABIAA AABgGxHQAAAA9MAEkAQQBSADIALQBQAEMAAgAQAEwASQBBAFIAMgAtAFAAQwABABAATABJAEEAUgAyAC 0AUABDAAQAEABsAGkAYQByADIALQBQAEMAAwAQAGwAaQBhAHIAMgAtAFAAQwAHAAgAKtO8l8V12QEAAA AA Got Request: HEAD http://localhost/GETHASHES337444! Sending 401... Parsing final auth... TlRMTVNTUAADAAAAAAAAAFgAAAAAAAAAWAAAAAAAAABYAAAAAAAAAFgAAAAAAAAAWAAAAAAAAABYAAAA BcKIogYBsR0AAAAPjEKYjnSHs9JOeCraq6Dh6A== Got TlRMTVNTUAADAAAAAAAAAFgAAAAAAAAAWAAAAAAAAABYAAAAAAAAAFgAAAAAAAAAWAAAAAAAAABY AAAABcKIogYBsR0AAAAPjEKYjnSHs9JOeCraq6Dh6A== Successfully started service ``` 我發覺攻擊的大制上流程,我懂,但是一些細節,我始終對比不出個樣子,總感覺跟快要拼上了,但又不因為小細節對不上整個思路陷入混亂。 我想只能從代碼中 一步一步理解了,但太花時間。 中間人的轉發流程細節太少了。 網上有圖,但跟輸出對不上。 另外一點 ms09-013 到底有沒有把http -> smb 封起來,網上也沒啥資料。 你需要了解的知識 1.NTLM 認證機制 2.LLMNR 和 NBNS 欺騙 3.WPAD劫持 4.NTLM relay (重放) 5.NTLM relection(反射) 本文重點 ### NTLM relay 網上介紹 NTLM relay 很多,這裡截取別人文章的精華 1、工作组环境(用处不大) 在工作组环境里面,工作组中的机器之间相互没有信任关系,每台机器的账号密码 Hash 只是保存在自己的 SAM 文件中,这个时候 Relay 到别的机器可能性就不大,除非两台机器的账号密码一样,不然毫无意义。 但是如果账号密码相同的话,为什么不直接用哈希传递呢? 2、域环境(主要在域环境下攻击) 我们知道在域环境下所有域用户的账号密码 Hash 都保存在域控的 ntds.dit 里面。若没有限制域用户登录到某台机子,那就可以将该域用户 Relay 到别人的机子,或者是拿到域控的请求,将域控 Relay 到普通的机子,比如域管运维所在的机器。 作者:小陈是个憨憨 链接:https://juejin.cn/post/7169428756824588319 来源:稀土掘金 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 --- ### NTLM reflection 小知識: 客户端可能没有服务端凭证,但客户端肯定拥有自身凭证,因此可以将其中继至客户端本身,即 NTLM Reflection,NTLM 反射。 在使用某些命令时,会先使用客户端自身的凭证来尝试验证。比如输入net.exe use \hostshare 并回车后会提示输入服务端账号密码,其实在提示输入账号密码之前客户端就已经用当前用户名及其 NTLM-Hash 进行挑战响应验证。显然这会因为客户端凭证无法用于服务端而失败,之后用户再输入正确的服务端账号密码,客户端再进行一遍挑战响应验证完成身份认证。 攻击者可以将客户端发送的 NTLM 挑战请求中继回客户端自身,完成 NTLM 反射攻击。(反射相关漏洞 MS08-068、CVE-2019-1384(Ghost Potato))。 以上部分內容來自:[Windows 域环境下的本地提权系列研究(二)(默安玄甲实验室)](https://mp.weixin.qq.com/s?__biz=MzkzNjI2MzgzOA==&mid=2247485149&idx=1&sn=464b670a114352353d94443e7b3d0a65&chksm=c2a02f2cf5d7a63a4ed230dd5af162114c8e91bba913576dd2ae21ca15545c48cce80e544423&scene=126&sessionid=1672380788&key=56998510be417bb8a98a1e59e69be5f620793ccace8056de27da11c0729814648a1d5dacac3bd38f27c65b0eb0124d2ee3d2cb400d2c791b9aa3ee9425df0b5cc7d35b1d1113688de7f366de6ab68482d413b07e48296299bf2919223273269ea917cbacd70f1526fb37bcdf20442b90f8781a95ce07d34dc3798ffa1036415b&ascene=15&uin=NTY2NTA4NjQ%3D&devicetype=Windows+Server+2016+x64&version=6308011a&lang=zh_CN&session_us=gh_fb6fe2418513&exportkey=n_ChQIAhIQ9a%2BVIYd3LdkHxjm%2BgPVNLhL4AQIE97dBBAEAAAAAAPbaIpoq2NAAAAAOpnltbLcz9gKNyK89dVj0FfE%2BIlXiWXY33OE3eSPmrjmc7HB0jDUOCQae4rlQZl3G%2BaE77mUBW1199vzdEieTwLBQPUKoZ9l%2Bd8C4gU2Vhvbo4rI2frRy1w8Q2VDQ%2F8gZroezoMO7rTB%2F%2FcWi26ZQ9i%2FSvXPQ00fdpVeExXP8IA790dgaVD0JUcV%2FdzNpOyFaV43dB%2FymlJwlZBh%2FmBHTH0RZbXdsVqZVX8%2F6QLoofP95IbP2BUO%2FwJ4FMxWVkBgBDyNKR1x7TrA5aaVH74GQKxs%2Fa2nvSuQ1Q8Yob) 備用:https://cn-sec.com/archives/1489316.html 工作组环境(用处不大)中間人能拿到客戶端的憑證,但是你中繼到服務端後,服務端的憑據跟客戶端的不同,所以也沒用處,除非雙方帳密剛好一樣。 於是衍生出了反射。 反射的原理就是,中間人拿到客戶端的憑證在丟回給客戶端 在此之前,我想問我自己一個問題 如果熟悉NTLM V1,V2加密原理 https://daiker.gitbook.io/windows-protocol/ntlm-pian/4 https://github.com/xidaner/Freed0m/blob/master/%E7%AC%94%E8%AE%B0/%E5%AE%89%E5%85%A8/OS%E6%B8%97%E9%80%8F/%E5%86%85%E7%BD%91%E6%B8%97%E9%80%8F/%E5%86%85%E7%BD%91%E6%B8%97%E9%80%8F-NTLM%E5%8D%8F%E8%AE%AE/%E5%86%85%E7%BD%91%E7%9F%A5%E8%AF%86NTLM%E5%8D%8F%E8%AE%AE1-3.md 1.A本地用戶 user1 密碼 123 hash(假設為666) 2.A首次用user1 傳給 攻擊者 3.攻擊者 偽造 user1 對應的 hash (777) 和生成一個隨機數(xxx) ,777加密隨機數(xxx)後生成 888,並把隨機數(xxx)傳給 A 4.A用666 加密(xxx) 生成(999) 傳給 攻擊者 5.攻擊者 把999 跟888 比對是否一樣 問題來了,攻擊者知道自己生成的xxx後,能不能直接解出user1的hash(666) 注意:我是要拿到A的密碼hash 並不是A的明文密碼 在實驗中是可以的,responder 工具可以幫你拿到。 注意:拿到的是 網路驗證 Net NTLM hash v1或v2 而不是 本地驗證的 NTLM 但既然16位的隨機數(類似key)是由攻擊者產生,那麼能不能拿 key 直接decode 拿到 NTLM 呢。 這點網上大部分只討論到拿到 Net NTLM hash v2並且說破解要很久,我在potato中 有看到 NTLM 但時間關係加上 這些加密的過程,可能不是我預想的那麼簡單(可能加一些向量),種種的不確定因素所以我就沒有特別研究。 反射正題 反射的好處: 攻擊者不需要知道A的hash,只需要把A發出的 NTLM 認證請求轉給A自己 1.A(client)本地用戶 user1 密碼 123 hash(假設為666) 2.A(client) 首次用user1 傳給 A(server) 3.A(server)找到 user1 對應的 hash (666) 和生成一個隨機數(xxx) ,666加密隨機數(xxx)後生成 999,並把隨機數(xxx)傳給 A(client) 4.A(client)用666 加密(xxx) 生成(999) 傳給 A(server) 5.A(server) 把999 跟999 比對是否一樣 所以你就知道反射非常方便。 NTLM 反射漏洞簡史 * 2001年 SirDystic 發布 SMBRelay * 2004年 微軟發布Windows XP SP2 * 2008年 Microsoft 在 MS08-68 中防禦 SMB/SMB 反射 * 2009年 Microsoft 在 MS09-13 中防禦 HTTP/SMB 反射 * 2014年 Forshaw 在 CVE-2017-3225 中發現本地 WebDAV/SMB 反射 Microsoft 發布 CVE-2017-3225 的 WONTFIX * 2015年 Forshaw 發現 DCOM DCE/RPC 本地 NTLM 反射特權提升 * 2016年 Foxglove Weaponise CVE-2017-3225 in Hot Potato 微軟在 MS16-075 中防禦 Hot Potato Foxglove 和 Forshaw 在 Rotten Potato 中濫用 SeImpersonatePrivilege 和本地 NTLM 反射 * 2018 Microsoft Mitigate Rotten Potato 在更高版本的 Windows 中(1809 起) 另外 potato 提權的歷史: https://jlajara.gitlab.io/Potatoes_Windows_Privesc hot potato 使用心得 下載: https://github.com/foxglovesec/Potato 我第一次使用時: 這兩個 payload 都不成功。 ``` //假設你已經拿到一般使用者 test123456 你把他加入到 amdinistrators 組 Potato.exe -ip 192.168.43.217 -cmd "C:\\Windows\\System32\\cmd.exe /c net localgroup administrators test123456 /add" -disable_exhaust false Potato.exe -ip 192.168.43.217 -cmd "C:\\Windows\\System32\\cmd.exe /k net localgroup administrators test123456 /add" -disable_exhaust true ``` 但隔天重開電腦後,又可以成功了。(不知道啥原因),可能是 windows update之類的? 成功後還有一些問題,你即使看了 test123456 屬於 administrators 組,不過在還沒重新啟動之前,他test123456是沒有任何作用的,你不能夠添加新的使用者。 但你可以關閉UAC。(關閉後也需要重新啟動)。 關於這點我也覺得很奇怪,一般使用者真的能隨隨便便關閉他嗎 ``` 關閉UAC cmd: reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f 開啟UAC cmd: reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 1 /f ``` 為啥關閉UAC 如果你不關的話,你重開機雖然是 administrator 組,但你需要申請UAC 給你權限(也就是右鍵 run as administrator),這在rdp 的方式下很簡單,但在拿到shell的情況下可就麻煩了,(我沒有特別研究 cmd 怎樣 run as administrator 通過UAC )。 我是有使用 runas test123456 之類的指令,但還是無法通過UAC 導致無法 add user,所以最好的方法就是關閉他。 以上實驗是在win 7 執行的 總結一下UAC 的問題: 1.普通user 可以關閉(這很好,但也很奇怪UAC 是可以被任何人關的嗎???) 2.即使你提權讓目前的使用者到administrators組,需要重開機才能具備跟UAC申請的資格,但不知道cmd 怎用UAC申請,所以乾脆關了,就沒那麼多煩惱。 最後我把我研究過的所有文章都放上來,也許未來可以理解: https://tryhackme.com/room/windows10privesc http://www.smatrix.org/forum/forum.php?mod=viewthread&tid=2442&extra= https://github.com/xidaner/Freed0m/blob/master/%E7%AC%94%E8%AE%B0/%E5%AE%89%E5%85%A8/OS%E6%B8%97%E9%80%8F/%E5%86%85%E7%BD%91%E6%B8%97%E9%80%8F/%E5%86%85%E7%BD%91%E6%B8%97%E9%80%8F-NTLM%E4%B8%AD%E7%BB%A7%E5%92%8C%E5%8F%8D%E5%B0%84/%E5%86%85%E7%BD%91%E7%9F%A5%E8%AF%86NTLM%E4%B8%AD%E7%BB%A7%E5%92%8C%E5%8F%8D%E5%B0%841-4.md https://blog.csdn.net/wo41ge/article/details/121278337 https://mp.weixin.qq.com/s?__biz=MzI0NzEwOTM0MA==&mid=2652495264&idx=1&sn=c42f9788c39d9e2100345f45acdc1397&chksm=f2587e13c52ff705a3c5896b6f7e985336ad069136a04dcff87b879067f75459a2900d58f610&mpshare=1&scene=23&srcid=1203AGd3ZwFCkqzRkXzqcEDf&sharer_sharetime=1638520540132&sharer_shareid=ff83fe2fe7db7fcd8a1fcbc183d841c4#rd http://www.smatrix.org/forum/forum.php?mod=viewthread&tid=2442&extra= http://moonflower.fun/index.php/2022/05/01/329/ https://zhuanlan.zhihu.com/p/486767130 https://foxglovesecurity.com/2016/01/16/hot-potato/ https://www.freebuf.com/articles/network/308340.html https://tttang.com/archive/1560/#%E5%9C%9F%E8%B1%86%E5%AE%B6%E6%97%8F%E5%88%86%E6%9E%90 http://www.smatrix.org/forum/forum.php?mod=viewthread&tid=2442&extra= https://decoder.cloud/2020/05/11/no-more-juicypotato-old-story-welcome-roguepotato/ https://github.com/xidaner/Freed0m/blob/master/%E7%AC%94%E8%AE%B0/%E5%AE%89%E5%85%A8/OS%E6%B8%97%E9%80%8F/%E5%86%85%E7%BD%91%E6%B8%97%E9%80%8F/%E5%86%85%E7%BD%91%E6%B8%97%E9%80%8F-NTLM%E4%B8%AD%E7%BB%A7%E5%92%8C%E5%8F%8D%E5%B0%84/%E5%86%85%E7%BD%91%E7%9F%A5%E8%AF%86NTLM%E4%B8%AD%E7%BB%A7%E5%92%8C%E5%8F%8D%E5%B0%841-4.md https://cn-sec.com/archives/1634495.html https://www.crisprx.top/archives/463 https://www.bilibili.com/video/BV1gv411V7fa/ https://www.bilibili.com/video/BV1rj411f7no/?spm_id_from=333.337.search-card.all.click https://cn-sec.com/archives/1489316.html https://www.secureauth.com/blog/we-love-relaying-credentials-a-technical-guide-to-relaying-credentials-everywhere/ https://hideandsec.sh/books/windows-sNL/page/in-the-potato-family-i-want-them-all https://chasers.fun/2020-02-29-ATT&CK_Privilege_Escalation/ https://websec.readthedocs.io/zh/latest/auth/ntlm.html https://segmentfault.com/q/1010000042947913 https://www.cnblogs.com/chnking/archive/2007/11/20/965553.html https://payloads.online/archivers/2018-11-30/1/ https://blog.51cto.com/u_15162069/2738224 https://github.com/jas502n/sangfor/blob/master/1earn/Security/RedTeam/OS%E5%AE%89%E5%85%A8/%E5%AE%9E%E9%AA%8C/NTLM%E4%B8%AD%E7%BB%A7.md https://blog.csdn.net/Waffle666/article/details/120251135 https://www.cnblogs.com/zhengna/p/15310612.html https://liwz11.com/blog/archives/412.html https://paper.seebug.org/2056/ https://shenaniganslabs.io/2019/11/12/Ghost-Potato.html https://zhuanlan.zhihu.com/p/64889695 https://blog.fox-it.com/2017/05/09/relaying-credentials-everywhere-with-ntlmrelayx/ https://www.anquanke.com/post/id/222746 https://www.freebuf.com/articles/network/256844.html https://blog.51cto.com/u_15060465/4537851 https://pentestlab.blog/2017/04/13/hot-potato/