Home » Posts tagged "session"

AWS 推出可以直接操作機器的 Shell Access

AWS 推出了 Shell Access,讓你可以直接操作 EC2 上的機器,而且又符合稽核上的要求:「New – AWS Systems Manager Session Manager for Shell Access to EC2 Instances」。

看起來機器上只要有 ssm-agent 就可以做這件事情了。在官方的圖可以看到用法:

另外 AWS 也在開發新的功能,一個是繞過 security group 的 SSH client:

SSH Client – You will be able to create SSH sessions atop Session Manager without opening up any inbound ports.


On-Premises Access – We plan to give you the ability to access your on-premises instances (which must be running the SSM Agent) via Session Manager.

這功能最主要還是稽核面的需求... 以前要作到這件事情會需要透過跳板之類的東西記錄使用者行為,現在 AWS 做出來後就省下這件事情。

各家 Session Replay 服務對個資的處理

Session Replay 指的是重播將使用者的行為錄下來重播,市面上有很多這樣的服務,像是 User Replay 或是 SessionCam

這篇文章就是在討論這些服務在處理個資時的方式,像是信用卡卡號的內容,或是密碼的內容,這些不應該被記錄下來的資料是怎麼被處理的:「No boundaries: Exfiltration of personal data by session-replay scripts」,主要的重點在這張圖:

後面有提到目前防禦的情況,看起來目前用 adblock 類的軟體可以擋掉一些服務,但不是全部的都在列表裡。而 DNT 則是裝飾品沒人鳥過:

Two commonly used ad-blocking lists EasyList and EasyPrivacy do not block FullStory, Smartlook, or UserReplay scripts. EasyPrivacy has filter rules that block Yandex, Hotjar, ClickTale and SessionCam.

At least one of the five companies we studied (UserReplay) allows publishers to disable data collection from users who have Do Not Track (DNT) set in their browsers. We scanned the configuration settings of the Alexa top 1 million publishers using UserReplay on their homepages, and found that none of them chose to honor the DNT signal.

Improving user experience is a critical task for publishers. However it shouldn’t come at the expense of user privacy.

用 SessionGopher 拉出機器上各種密碼與 Key

同事在 Slack 上提到 fireeye/SessionGopher 這個工具,可以從機器上拉出各種敏感資訊:

SessionGopher is a PowerShell tool that uses WMI to extract saved session information for remote access tools such as WinSCP, PuTTY, SuperPuTTY, FileZilla, and Microsoft Remote Desktop. It can be run remotely or locally.

方法是掃 registry 或是硬碟:

SessionGopher works by querying the HKEY_USERS hive for all users who have logged onto a domain-joined box at some point. It extracts PuTTY, WinSCP, SuperPuTTY, FileZilla, and RDP saved session information. It automatically extracts and decrypts WinSCP, FileZilla, and SuperPuTTY saved passwords. When run in Thorough mode, it also searches all drives for PuTTY private key files (.ppk) and extracts all relevant private key information, including the key itself, as well as for Remote Desktop (.rdp) and RSA (.sdtid) files.

是個... 好玩... 的... 東西...

記錄 Firefox/Chrome 在 TLS 的 Session Key 供 Wireshark 使用

以往要看 TLS traffic,需要用 mitmproxy 之類的軟體擋在中間,這需要在 client 端安裝對應的 CA root certificate。

而剛剛在「Decrypting TLS Browser Traffic With Wireshark – The Easy Way!」這篇文章裡面提到了如何讓 FirefoxChrome 記錄下 TLS 的 Session Key,然後倒給 Wireshark 使用。(文章裡有提到需要 dev 版本,不確定是因為新版支援的關係,還是這個功能限制在 dev 版才能用)

方法是在執行時設定 SSLKEYLOGFILE 這個環境變數,指定寫到某個檔案裡。不論是在 Windows & MacOSX & Linux 都一樣。

之後就可以把 Session Key 丟給 Wireshark 處理了,就像是這樣:(原文的範例)

CloudFlare 的 Keyless SSL 服務

CloudFlare 有兩篇公告出來:「Announcing Keyless SSL™: All the Benefits of CloudFlare Without Having to Turn Over Your Private SSL Keys」、「Keyless SSL: The Nitty Gritty Technical Details」。前面的一篇偏向公告文 (以及公關稿),而後面的一篇提到了實際運作的方式。

用兩張 Keyless SSL 的 flow 就可以知道差異了,一張是 RSA-based,一張是 DH-based:

把與 private key 相關的運算拆出來,由後方計算完成後再計算出 session key 與 client 溝通。如此一來,雖然速度比較慢,但 private key 管理在客戶自己手上...

新的 HTTPS 攻擊:BREACH Compression Attack

也是一個禮拜前的消息,在 Slashdot 上看到對 HTTPS 的新攻擊,目前沒有好解法,NSA 應該開心到爆炸:「BREACH Compression Attack Steals SSL Secrets」。

說明可以參考「Vulnerability Note VU#987798 BREACH vulnerability in compressed HTTPS」這篇。

假設你的 ISP 想要抓出你的 Facebook (HTTPS) session id 或是 CSRF token (只要是有能力在中間攔截封包並修改資料的團體都可以,這邊以 ISP 為例),作法是針對 HTTP 頁面值入 script,讓你的瀏覽器對 https://www.facebook.com/ 發出大量 request,藉由觀察這些 HTTPS 的長度就有機會取得 session id (或 CSRF token)...

CERT 的 security advisory 上是寫:

With a token of length 32 and a character space of size 16 (e.g. hex), the attacker needs an average of approximately 1,000 request if no recovery mechanisms are needed. In practice, we have been able to recover CSRF tokens with fewer than 4,000 requests. A browser like Google Chrome or Internet Explorer is able to issue this number of requests in under 30 seconds, including callbacks to the attacker command & control center.

四千次就搞定了... 太!歡!樂!了!

最近很紅的 Firesheep...

Firesheep,一個 Firefox extension,利用截聽封包的方式取得 session 資訊,進而使用該 session 做壞事。原理其實很簡單,只是這次被包成 Firefox extension 後讓一般人都很容易可以「確認」這不是什麼困難的事情... 而在 Wifi 環境下封包的截聽就更容易了。

除此之外,這次公開 Firesheep 時有說明「登入已經是 HTTPS 所以就很安全了」這個錯誤的觀念。因為在 HTTPS 模式下登入所拿到的 session (通常是 cookie) 在 HTTP 模式下預設還是會以明文傳輸,所以截聽 HTTP 封包取得 session 後就可以處理很多事情了。

目前 client 端的解法都是建議全程 HTTPS 加密並加裝套件確保不會有 HTTP request。在 Firefox 目前看到的套件中有兩個,一個是 Force-TLS,這個套件可以設定某些 site 一定要使用 HTTPS。安裝這個套件而不做設定不會有效果。另外一個套件是 EFF 出的 HTTPS Everywhere,預設就會設定一堆常見的站台加密,對於一般人來說比較方便。

回過頭來提到 HTTPS 協定。SSL 的 AES encryption/decryption 其實很快 (以目前 Web 的傳輸量來看),但啟始的 overhead 太大。再加上 HTTP 又是 stateless 協定,常常會需要重新連線。以目前 HTML5 WebSocket 支援加密的架構來看,以後有可能會用 WebSocket 加上 Javascript 解決效能的問題...