Facebook phishing using Belgium (.be) domains
This is not new or exciting, but as we have received several reports during the weekend (thanks to all that wrote in - Kevin, Mike, Rick), you all should know what is going on. It seems a new Facebook phishing/spam campaign is doing the rounds. It uses Belgium domains (.be) to impersonate the Facebook login page and steal the user credentials.
UPDATE 4: The malicious domains do not only impersonate Facebook but contain malicious "hidden" (1x1pixel) iframes, hosted on the same host, such as: "/tds/r.php?sid=2&pid=5511". Do not browse to them unless you know what you are doing!
UPDATE 5: (May 25, 22:00h CET) It seems there is a new variation moving around, using tinyurl links (thanks Charlie). For example, you get a Facebook message pointing to "tinyurl dot com /o5kblj/" that takes you to a link at "simplemart dot be". Remember you can enable/disable the tinyurl preview feature through "http://tinyurl.com/preview.php". You just need to enable cookies on your browser.
Some of the malicious domains being used are redfriend dot be, redbuddy dot be, picoband dot be... (at this point, none of them can be resolved).
UPDATE 1: Other domains: areps dot at, greenbuddy dot be (Thanks Derek)
UPDATE 2: You can check the owner of Belgium domains through www.dns.be (the whois search is on the top-right corner).
Just to provide a couple of examples, the greenbuddy dot be and redfriend dot be domains were registered on May 22, and the last update was May 24, by:
Name | Andrey Sokolovsky |
Language | English |
Address | ... |
... |
The redbuddy dot be was registered on May 21, last updated May 24 (both from people on the ".at" domain):
Name | Petr Anisimov |
Language | English |
Address | ... |
... |
UPDATE 3: As expected, more domains are coming (and some of them are still active right now - May 25, 0:00am CET) - thanks Kevin and Greg:
- redfriend dot be, redbuddy dot be, picoband dot be, areps dot at, greenbuddy dot be
- picoband dot be, vispace dot be, whiteflash dot be, bestspace dot be
- There are other "more than suspicious" .be domains associated to the same IP address
The ones active do resolve to IP address 211.95.78.98. From APNIC:
inetnum: 211.90.0.0 - 211.97.255.255 netname: UNICOM descr: China United Telecommunications Corporation descr: No.133,Taiyun Building,Xidan North Street descr: Xicheng District,Beijing,China country: CN admin-c: JY1446-AP tech-c: JY1446-AP mnt-by: MAINT-CNNIC-AP mnt-lower: MAINT-CNNIC-AP mnt-routes: MAINT-CNNIC-AP status: ALLOCATED PORTABLE changed: ipas@cnnic.cn 20070731 changed: hm-changed@apnic.net 20070802 source: APNIC
It's recommended to filter access to all them (and the others coming)!
--
Raul Siles
www.raulsiles.com
IIS admins, help finding WebDAV remotely using nmap
If you are concerned about the recent unpatched IIS 6.0 WebDav Remote Auth Bypass vulnerability (CVE-2009-1535), you will be interested on detecting if you are running WebDAV and if you are vulnerable. You can do that locally or remotelly. I can identify scenarios were both methods are useful to audit internal or external web servers.
For local testing, please follow Adrien's diary from a couple of days ago.
For remote testing you can use our good friend nmap, and a new NSE script (http-iis-webdav-vuln) by Ron Bowes and Andrew Orr. I've been using it on a recent penetration test, but it can be equally used in your vulnerability assessments and pre-incident handling tasks following two easy steps:
- Download/Update & compile nmap from the SVN repository:
$ svn co --username guest --password "" svn://svn.insecure.org/nmap/ $ cd nmap $ ./configure $ make $ sudo make install
- Run the script just against your IIS web servers (specify the web server port accordingly, "-p" option):
$ nmap -n -PN -p80 --script=http-iis-webdav-vuln <target_web_server.domain.com>
- The script doesn't work directly against HTTPS web servers. Therefore, you need to make use of the nmap's service detection capabilities ("-sV") to make it work:
$ nmap -n -PN -sV -p443 --script=http-iis-webdav-vuln <target_web_server.domain.com>
This NSE script launches a kind of dictionary attack, searching for potential web server folders. If you want to avoid it, because you just want to test an existing specific folder or subfolder, use the "--script-args=webdavfolder=<PATH>" option to specify it (all in one line):
$ nmap -n -PN -p80 --script=http-iis-webdav-vuln --script-args=webdavfolder="protected/webdav/folder/" <target_web_server.domain.com>
This is a listing of the most common output you can get:
- WebDAV is disabled on a HTTP server:
80/tcp open http |_ http-iis-webdav-vuln: WebDAV is DISABLED. Server is not currently vulnerable.
- WebDAV is disabled on a HTTPS server:
443/tcp open ssl/http Microsoft IIS webserver 6.0 |_ http-iis-webdav-vuln: WebDAV is DISABLED. Server is not currently vulnerable. Service Info: OS: Windows
- WebDAV is enabled on a HTTP server, but no folder was found:
80/tcp open http |_ http-iis-webdav-vuln: WebDAV is ENABLED. No protected folder found; check not run. If you know a protected folder, add --script-args=webdavfolder=<path>
- WebDAV is enabled on a HTTP server, but the specified folder is not vulnerable:
80/tcp open http |_ http-iis-webdav-vuln: WebDAV is ENABLED. Could not determine vulnerability of folder: /protected/webdav/folder
- WebDAV is enabled on a HTTP server, and vulnerable folders were found:
80/tcp open http |_ http-iis-webdav-vuln: WebDAV is ENABLED. Vulnerable folders discovered: /secret, /webdav
Please, audit ALL your web servers before anybody else does! ... and don't forget to look at your web server logs to check if someone is already testing it!
--
Raul Siles
www.raulsiles.com
Analyzing malicious PDF documents
As we announced in a recent ISC diary, Adobe is changing its patching model and strategy, but it seems still JavaScript will be enabled by default in Adobe Acrobat and Reader. As a consequence, I foreshadow more PDF vulnerabilities, exploits and attacks in the near future (let's hope I'm wrong).
On the one hand, I've been actively using PDF exploits in recent penetration tests, emulating the real-world attacks we have seen in the wild and described in several ISC diaries during the last 2-3 years (you can get most of them using the following search in Google: "pdf site:isc.sans.org"). Both, the open-source Metasploit Framework, and commercial pen-testing tools, like Core Impact, include these capabilties.
On the other hand, we need to be able to disect these malicious files when we are the target . The Hakin9 magazine has made available this week (for free) a great introductory article on the internal formatting of PDF files and how to analyze malicious PDF documents, those exploiting a vulnerability in the embedded JavaScript interpreter (very common), by Didier Stevens (a well known PDF expert we've mentioned regarding previous PDF vulnerabilities):
"Anatomy of Malicious PDF Documents". Didier Stevens. Hakin9 magazine.
In order to get a copy of the article, in PDF format (What a coincidence! Is it malicious or not? ), you just need to provide an e-mail address. Do not forget to download the RTF document with the code listing (link on the right hand side).
This article is a must read and great starting point for incident handlers interested on increasing their skills to analyze malicious PDF documents. If you want to start practicing today, before being a target, generate a malicious PDF document in Metasploit and analyze it. For more advanced inspection, I encourage you to use some specific PDF analysis tools.
--
Raul Siles
www.raulsiles.com
Comments