Cyku

Yes, we're beating a dead horse. But that horse still runs in corporate networks - and quietly gives attackers the keys to the kingdom. We're publishing what’s long been exploitable. Time to talk about it. #DSM #Ivanti code-white.com/blog/ivanti-de…

嘿！你知道嗎？ 某些 HTML 標籤閉合的優先順序可能高於屬性的雙引號，例如「<xmp><img src="</xmp><svg onload=alert()>">」會在 chrome 上彈窗，看似神奇但當你將 xmp 改為 script 就可理解是 parser 不一致所導致，這特性曾被人應用在 Google Search 上的 XSS 漏洞 #紅隊豆知識 #RedTeamDoYouKnow

嘿！你知道嗎？ SSH 的 port forwarding 功能用於 tunneling 非常便利，OpenSSH 在 6.7 以後開始支援將流量轉發到 Unix socket，只要使用 "ssh -L 2376:/var/run/docker.sock" 就可以讓你在本機連到伺服器上的 docker，或許在 sandbox escape 時會有意想不到的用途。 #紅隊豆知識 #RedTeamDoYouKnow

嘿！你知道嗎？ Windows 為了檔案系統的相容性 (例如：FAT會用空白字元去填充沒有用到的檔名字串空間)，大部分時候在建立檔案時，會自動移除檔名末端的點(.)和空白字元，所以如果測試上傳漏洞遇到副檔名有黑名單的話，不妨試試看上傳 "webshell.aspx." 吧！ #紅隊豆知識 #RedTeamDoYouKnow

@Noth72013441 真的 現在紅隊越來越苦了

@cyku_tw 師傅，外網初始點最難 🤣

參與紅隊無數次打 Windows AD 的經驗總結下來， 我得到了四個字的滲透心法：花式登入。 不是隨時都有 ZeroLogon、CVE-2022–26923 這種無視限制可以直搗黃龍的漏洞，所以平時滲透的不二法門果然還是想盡辦法撈到密碼登入就對了！

I feel so energized. It's gonna be a great time at work with my new keyboard😺

My new keyboard 🥰

wargame.d3vc0r3.tw It's time to play 🤓

I've prepared 3 easy wargame challenges for HITCON CMT 2024 event, plus my coworker's challenge for a total of 7 challenges. I hope everyone enjoys them🥳

被 Wordware AI 嗆自己解不開自己做的 CTF 題目， 但事實上 .. .. 是真的， 今年老樣子為 HITCON 做了 Wargame，我還真的解不開， 有沒有會來 HITCON 2024 的朋友幫我解一下🥹

It's a short story about how do I perform a strange MSSQL Injection when the database doesn't even exist. I'm trying to write in English this time, and I had a hard time writing. I hope everyone can still like it. cyku.tw/no-database-ms…

It's been almost a year since my last blog post. I wanna update something but have no idea what to write about🤔

@fwarashi sounds great, I'll subsribe both!

ゲーム用のアカウントとチャンネル分離しようかな

@_r3st sad🐸

If an attacker exploits 0day to compromise service and leaves backdoor. After some time, victim fixes 0day but leaves backdoor behind. Then another attacker exploits new vuln to find backdoor and uses it to compromise enterprise, how do you describe second attack in ATT&CK?

@logonfail 感謝，這作為參考對我很有幫助！

@cyku_tw Multiple techniques are involved. Both groups have done initial access to get into the environment, and the latter group found and managed to leverage a leftover artifact (Persistence) to perform other attacks.

@logonfail If 2 attacks are by 2 different attack group, would you still choose technique under "Persistence"? or choose technique under "Initial Access"?

@cyku_tw IMHO the second attack is in fact, two attacks; first one will be under "Initial Access", and the one involving the backdoor could be one of the techniques under "Persistence".

@CRUD_Machine 沒錯！但如果表是指字典檔，一樣無法阻擋，如果是預先計算好的一個記滿雜湊的表跟它對應的原文密碼，那個加鹽的雜湊幾乎不可能會出現在表裡

@cyku_tw 有道理耶，這樣是不是可以理解成說：加鹽只是不讓對方查表，強迫對方一定要用暴力破解這樣🤔

【每天推薦一篇文章】存密碼的正確姿勢 前兩天貼了編碼、加密、雜湊的文章，今天接著貼它的續集： 聽說不能用明文存密碼，那到底該怎麼存？ - Starbugs Weekly 星巴哥技術專欄 medium.com/starbugs/how-t… 這篇列了幾個方案，從編碼到雜湊，搭配圖文解釋，非常適合貼給同事然後叫他們密碼不要亂存。 真的，只要你同事一說「那我們就用 bas...」就直接把這篇甩在他臉上。 按慣例，這邊也迅速節錄一下、收進筆記庫。 --- 方案一：Base64 編碼 先回顧上一篇的這句： > 所謂的編碼並不會修改資料、也沒有任何加密的效果，單純就是換個方式來表達資料而已 沒有加密效果！沒有加密效果！沒有加密效果！而且 base64 的 `==` 真的太好認了= = > 經過 Base64 後的結果很常都是 = 或 == 結尾，所以如果有一天資料庫真的洩漏出去了，駭客也會在第一時間就發現可以用 Base64 解開，然後在很短的時間內得到原本的密碼 那如果不要用 base64，用一些比較冷門的編碼呢？ > 也不行，雖然這些編碼演算法比較少人在用，但頂多騙騙不懂電腦的路人甲乙。真正的駭客很可能會使用各種方法嘗試要 decode 密碼，所以不管用哪一種編碼都是不安全的，結論就是不要使用編碼來儲存密碼！ --- 方案二：AES256 加密 那用加密呢？加密就會牽涉到保管 key 的問題： > 因爲使用者要登入時，後端必須確認使用者輸入的密碼加密後跟資料庫內的 password 是否符合，所以還是必須把 key 放在 server 上。既然是放在 server 上，那駭客就還是有機會拿到 > 因為公司內的員工可能會知道 key，所以就可以從資料庫得到使用者的密碼。如果你知道 Facebook 的工程師只要想要就能得到所有人的密碼，應該也不太放心吧，尤其很多人都在多個網站使用同樣的密碼 > 結論就是因為無法保證 key 的安全，所以不建議用加密的方式保存密碼 --- 方案三：SHA1 雜湊 雜湊已經不可逆了，通常是拿到密碼之後再雜湊一次進行比對： > 當使用者 Luka 要登入時，就把他輸入的密碼拿去經過 SHA1 雜湊，如果算出來的雜湊值跟資料庫內那一大串一樣，那就代表 Luka 有極高機率輸入了正確的密碼，所以就放行讓他登入 但因為現在的電腦已經很猛了，所以針對一些長度很短的、常出現的密碼，其實就可以直接拿來比對 SAH1，結果就還是會被猜出來 > 剛剛的 love1234 之所以可以被破解其實是因為他太簡單了，只要把長度為 8 的字串雜湊值都算過一遍就好。而且小寫字母加上數字也才 36 個字元，算一算 36⁸ 大約才 2.8 兆種組合，很快就可以建一個表出來 > 如果你的密碼又臭又長又亂、包含了大小寫甚至還有一些怪怪的字元，像是 -y]@7k[BSB@3m]r$.>"R，那以現在電腦的計算速度就還無法破解，因為長度 20 以內由數字、大小寫還有特殊字元組成的字串太多了，算到天荒地老都不見得能算出來 （只到這步的話，感覺平常只要密碼夠長就沒啥問題？） --- 方案四：加鹽 & SHA1 > 哦？聽起來只要密碼夠長、夠亂就沒問題了，那我能不能自己產生隨機字串，把使用者的密碼加長呢？ > 答案是可以，這就是所謂的 加鹽（Salt）。如果今天有一個新的使用者要註冊，這時我們的後端系統就隨機生成一個長度十的字串稱作 Salt，計算 Hash 時就把使用者輸入的密碼跟 Salt 合在一起算 我現在碰到的密碼處理幾乎都是這種，安心實在。 --- 方案五：Bcrypt 完全沒看過的東西！馬上節錄文章內的介紹： > 雖然 Bcrypt 的名字裡面有個 crypt，但他並不是加密法，而是跟 SHA1 一樣是雜湊演算法，唯一的差別是他計算很慢 > 計算慢有什麼好處呢？前面有提到 SHA1 的雜湊值之所以可以被查表查出來，就是因為現今的電腦計算太快了，就連建個表反查也不需要太多時間 > 而 Bcrypt 則是可以透過設定疊代次數讓他變慢，以疊代五次的 Bcrypt 來說，他的計算速度大概比 SHA1 慢 1000 倍。也就是說，假如你原本用 SHA1 計算三天就能反查出所有使用者的密碼，現在卻要花大概八年的時間才可以 竟然就只是，算很慢？但想想還是很有道理，畢竟現在的玩法就是炸裂駭客的時間成本讓他去找別人，這樣看起來其實挺有用的？ --- 最後標一下總結的這一小句。我發現有很多朋友曾經跟我有一樣的迷思：安全是不是就是完全無法被攻破？但其實不是這樣的。 > 在資安領域沒有所謂絕對的安全，你只能不斷提高攻擊者的成本，當那個成本高到攻擊者無法負荷時（像是破解一個密碼要租超級電腦連續計算十年），那就可以說是足夠安全了XD 那麼，今天的轉貼就到這邊。我們下次（不敢說明天了）見～

🎄SQLi was first reported 25 years ago, by a researcher once known as Rain Forest Puppy, in Phrack Magazine on this day in 1998. 🎁 Happy birthday SQLi! 🎁 🐛Despite being around for 25 years, it's still essential knowledge for pentesters.