Threat Level: green Handler on Duty: Bojan Zdrnja

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2006-05-12 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

RealVNC 4.1.1 authentication bypass vulnerability reported - Plan your upgrades

Published: 2006-05-12
Last Updated: 2006-05-12 21:05:27 UTC
by William Salusky (Version: 2)
0 comment(s)
The handlers have been discussing and investigating reports forwarded by many of our readers regarding the disclosure of an authentication bypass specifically affecting version 4.1.1 of the RealVNC product.  Because we have been unable confirm the vulnerability we had chosen to hold back on posting on this specifically to avoid spreading FUD (Which I personally seem to have an unfortunate penchant for doing).  Considering the fact that we are receiving the kind and welcome forwarding of this disclosure from so many avid readers and the inherent risk that this may pose due to the perceived considerable deployment base of VNC products it would be reasonable to think that many installations are exposed, unprotected and potentially vulnerable on the public internet.  We've chosen to post this here for awareness and to enable a larger audience to evaluate their own risk levels associated with this issue.

We have reached out to the disclosure point of contact at IntelliAdmin and are awaiting a response so that we can independantly confirm this vulnerabiltiy with them directly and remove the concern of this being primarily hearsay.  The IntelliAdmin website boasts a PoC to test whether your installation is vulnerable, but is conveniently unavailable due to the statement that the Slashdotting of the site was overloading the test.

The RealVNC website at http://www.realvnc.com does not yet acknowledge this vulnerability, and with version 4.1.1 being the current release, I personally offer up employing either network ACL's to prevent arbitrary access from the internet or configuring the application level ACL's to allow only specific endpoints to connect to your VNC services.

Beyond that, Keep in mind, this is reported to be a remote access authentication bypass and not to be confused with buffer overflow, associated with direct OS privileged access.  I would hope that the successful result of someone successfully abusing this flaw would result only in the remote viewing of the MS Gina login prompt.  An attacker would still have to brute force authentication credentials.  After all, your VNC instances are configured to automatically lock the screen after disconnect and allow only a single user to be connected, am I right?

The disclosure is covered in a blog available at the following URL:
http://www.intelliadmin.com/blog/2006/05/vnc-flaw-proof-of-concept.html

*Update* As of about 1:56pm -0400, It appears that RealVNC acknowledged the authentication bypass with their release of version 4.1.2, and Release Notes that simply states "FIXED: Security vulnerability.".
See: http://www.realvnc.com/products/free/4.1/release-notes.html

William Salusky
Handler on Duty!
Keywords:
0 comment(s)

Apple OSX Patches, 2006-003

Published: 2006-05-12
Last Updated: 2006-05-12 15:36:36 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
Yesterday, apple released a new set of security patches for OS X. Note that some of them fix arbitrary code execution problems in Safari and Mail.

All Apple wants you to know about the patches can be found here:
http://docs.info.apple.com/article.html?artnum=303737

Our testing hasn't shown any problems so far. Please report any issues you might have. The list of patches is long, and they can only be applied as a set, so we will skip a discussion of individual issues.




Keywords:
0 comment(s)

Incident Response and Malware investigations via SecCheck

Published: 2006-05-12
Last Updated: 2006-05-12 05:41:35 UTC
by William Salusky (Version: 1)
0 comment(s)
Before pausing from reading email for a few hours, I'd like to take a moment to redirect your attention to a little advertised and even more infrequently used Incident Response and investigative feature hosted here on the ISC SANS portal. That feature is SecCheck, developed by MyNetWatchman, and offered to the Storm Center to assist in investigating suspicious and potentially malicious activity on hosts running the Windows family of operating systems.

The Storm Center deployment of SecCheck is hosted at http://isc.sans.org/seccheck/ and does require the use of Internet Explorer.  IE is required for this execution as our deployment is implemented in the form of an ActiveX DLL that executes in the context of your browser to analyze and deliver IR run-time reporting for the currently running workstation session.  Execution of the tool will result in the report being displayed on your workstation as well as being posted back to the Storm Center host for our review, and enables the handlers to assist you more directly.

Among the run-time details that are reported include:
  • running process list  (why am I running something called caseyvideo.exe?)       
  • running service enumeration (hmmm, that service executing from c:\winnt\lssass.exe looks interesting)
  • network connection snapshot (identify both services and established connectivity mapped to processes)
  • autostart registry hive dumps (malware has to restart itself somehow, this will show you where)
  • Installed BHO listing (Often Spyware and Hijackers jump right out)
  • Module dump (You can identify library injection techniques here)
SecCheck reporting does present much information that may take a little getting used to, but we're here to help!  Give it a try, especially if you are experiencing unusual and inexplicable computer activity.

There are additional developments available at http://www.mynetwatchman.com including standalone SecCheck binaries that offer additional features.

William Salusky
Handler on Duty!
 
Keywords:
0 comment(s)

Different strokes for different folks, spyware and browsers

Published: 2006-05-12
Last Updated: 2006-05-12 00:23:57 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)

One of our readers, Chris, sent us a URL to an interesting site. The site in question tries to install some spyware on the users' machine. This in itself is not interesting, but some "more advanced" features that we've seen deployed on this site are.

The site creators first setup a wildcard DNS entry for their domain, so anything prefixed to their domain name will go to their web server. They needed to do this so they can try to poison Google rates and enhance their page rankings when users are searching for potential keywords. In Chris' case, he was looking for information about one higher education institution (the attack is not limited to higher education institutions; we've seen a lot of other "poison" attempts from this group).

Now they have the basis for their attacks and we come to the interesting part. As a security researcher, you should always be careful when accessing unknown URLs (if you want to try it with a browser, probably the best way is to use one in a virtual machine). So, we decided to use wget to download the initial index.html web page, to see what's inside. Surprisingly, wget didn't manage to download anything:

$ wget http://[REMOVED].ascii. zstopers.com
--10:56:29--  http://[REMOVED].ascii. zstopers.com/
           => `index.html'
Resolving [REMOVED].ascii. zstopers.com... 66.246.246.215
Connecting to [REMOVED].ascii. zstopers.com|66.246.246.215|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
10:56:30 ERROR 403: Forbidden.

Hmm, forbidden. Ok, that goes with what Chris told us in his e-mail that the site seems to be down now. Being curious as we are (otherwise you won't be reading this diary) we decided to try the same site with Internet Explorer (in a virtual machine, of course).

What we got: (I've removed the domain prefix, which showed higher education institution, but the spyware domain is still visible there):



Notice the ActiveX control up there? That's what they want you to install. The popup will be shown until the user decides to install the ActiveX control. Keep in mind that other Internet Explorer versions will actually show a window asking the user to install the ActiveX component.

So, why didn't our wget work? Let's try with Mozilla:



Interesting! They detect what kind of browser is running, probably by parsing the User Agent field.
So, let's try to download the web page (just the index.html) file with wget, but this time faking the User Agent field, so the remote site will think that we are actually using Internet Explorer. If you're wondering what the User Agent field should look like, the easiest way is to check web server logs on one of the servers you have access to. Below we used Internet Explorer's User Agent field.

$ wget -U "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" http://[REMOVED].ascii. zstopers.com/

--11:04:52--  http://[REMOVED]. zstopers.com/
           => `index.html'
Resolving [REMOVED].ascii. zstopers.com... 66.246.246.215
Connecting to [REMOVED].ascii. zstopers.com|66.246.246.215|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]

    [                                                                                                                        ] 18,416        42.02K/s

11:04:53 (41.87 KB/s) - `index.html' saved [18416]

Aha! So they do use the User Agent field to detect what browser you are running and then send you to different web pages depending on it.
Further investigation of the index.html web page showed that it calls a JavaScript which then tries to install the WinAntiSpyware2006FreeInstall.cab, a well known spyware application, which some anti-virus vendors even detect as Trojans.

Those guys are definitely getting better and are actively adding new features to their malware. Remember the -U option for wget, it is very handy in cases like this.

Keywords:
0 comment(s)

Quicktime upgrade time

Published: 2006-05-12
Last Updated: 2006-05-12 00:18:50 UTC
by Swa Frantzen (Version: 1)
0 comment(s)
Apple released a Quicktime upgrade to version 7.1 that fixes a number of vulnerabilities in the Quicktime viewer.

Normally I'd like suggest to read the release notes for details, but they are typically thin in explaining what's been fixed and/or otherwise changed.

Basically viewing crafted images:
and movies:
can lead to arbitrary code execution.

The fixed version is available for both OS X and Windows. The best about it all is that at least we don't get the implicit insults we should only visit trusted websites.

Without more information the only option is not to use quicktime or upgrade.

--
Swa Frantzen - Section 66
Keywords:
0 comment(s)
Diary Archives