Mon Mar 8 14:41:39 CET 2010

Known Host Cracker

Known Host Cracker (khc) is a small tool designed to recover hashed known_host files back to their plain-text equivalents. It can get used in penetration Tests or investigations.

Posted by Sebastian Rother | Permanent link | File under: openbsd, authentication, password

Thu Apr 9 18:30:07 CEST 2009

multiple Vendor - PF Null-pointer dereference

Author Sebastian "Rembrandt" Rother
Date 2009-04-30
Found 2009-04-09
Affected Software PF (OpenBSD Packet Filter)
Affected OS :
  • OpenBSD 4.2 up to 4.5 and HEAD branch up to 2009-04-11
  • NetBSD 5.x up to RC3 and HEAD branch up to 2009-04-13
  • MirOS #10 and earlier
  • MidnightBSD 0.3-current
Not affected OS :
  • FreeBSD
  • NetBSD 3.x, 4.x, 5.x (patched before release)
  • DragonflyBSD
  • Debian GNU/kFreeBSD
  • MidnightBSD prior 0.3

Older versions of OpenBSD PF and products based thereon might be affected as well.
The Bug was introduced between the OpenBSD 4.1 and 4.2 release.

Type : Denial of Service

OSVDB53608
Milw0rm8406,8581
CVE2009-0687
ISS X-Force49837
BID34482
Secunia34676
VUPEN IDADV-2009-1015

This advisory supercedes the original advisory which was just related to OpenBSD because we had to publish an announcement in response to OpenBSD's reaction.

Trying to fix it responsibly and get in contact with the vendor:

OpenBSD
Contacted 2009-04-09 16:35 UTC
Patch available 2009-04-11 23:43 UTC

We received no response nor a notification about an upcoming patch.
Also we had no chance to coordinate or inform other projects before OpenBSD issued the patch and a statement.

We like to mention that the issued patch is just a workaround and does not patch or remove the affected code.

NetBSD
Contacted and asked for confirmation 2009-04-15 06:00 UTC
Were informed about further investigations 2009-04-15 9:42 UTC
Received information about upcoming Patches 2009-04-15 11:57 UTC
Received confirmation for 5.x up to RC3 and HEAD 2009-04-15 12:17 UTC

We thank the NetBSD team that they patched the PF bug prior the 5.x release!

FreeBSD
Contacted and asked for confirmation 2009-04-15 06:56 UTC
Were informed about further investigations 2009-04-15 7:56 UTC
Were informed about not being vulnerable 2009-04-15 22:05 UTC
DragonFlyBSD
Contacted and asked for confirmation 2009-04-15 06:10 UTC
Were informed about not being vulnerable 2009-04-15 21:35 UTC
MirOS
Contacted and asked for confirmation 2009-04-15 06:36 UTC
Were informed about not being vulnerable 2009-04-15 17:57 UTC
MidnightBSD
Contacted and asked for confirmation 2009-04-15 20:17 UTC
Were informed about not being vulnerable 2009-04-15 22:37 UTC
Debian GNU/kFreeBSD
Contacted and asked for confirmation 2009-04-15 22:41 UTC
Were informed about not being vulnerable 2009-04-15 23:35 UTC


OpenBSDs PF firewall is prone to a remote Denial of Service due to a NULL- pointer dereference when handling special crafted IP datagrams. If the firewall handles such a packet the kernel panics. An example for such a packet would be a IPv4 packet with a ICMPv6 payload.

This affects multiple vendors because PF was incorporated into serveral OS.

The problem stems from the unification of the rule processing in pf_test_rule(). With this unification ICMPv6 logic was applied to IPv4 packets and vice versa. Because the handling logic asserts that the common code in pf_test has verified that the packet contains a full ICMP header and has pulled up the mbuf up to that point. This assertion fails when the wrong AF-version is used by pf_test and thus pf_test_rule tries to access not allocated memory. The affected function is in pf_change_a6 and the patch is just a workaround because it filters the packet in pf_test() except of fixing the affected source code.

Steps to reproduce:
If you have an affected OS in your network which does NAT or redirecting traffic you should be able to test your IPv4 device with this simple hping command:

hping -0 -H 58 $a_host

Patches are provided for:
OpenBSD 4.3 - 4.5 (not for 4.2), HEAD after 2009-04-11
NetBSD 4.x (patched for consistency) - 5.0RC3, HEAD after 2009-04-13
MirBSD 10
MidnightBSD 0.3-current

Workaround:
The OpenBSD developers provide hints for a workaround at their errata website too.


We like to thank the security teams of the following projects for their friendly cooperation:

DragonflyBSD
NetBSD
FreeBSD
MidnightBSD
MirBSD

Special thanks goes to Andreas Bogk who assisted in the assembly analysis and Adrian Portelli of the NetBSD project for his time and permanent suggestions.

Posted by Sebastian Rother | Permanent link | File under: openbsd, denial_of_service

Fri Aug 8 18:24:29 CEST 2008

OpenBSD Remote triggable DoS related to NFS

Author:Sebastian "Rembrandt" Rother
Date:2008-08-08
Affected Software:OpenBSD Kernel
Affected OS:OpenBSD prior 4.4
Type:Remote triggable Denial of Service

OpenBSD, when configured as NFS Client, is prone to a remote triggable
denial of service condition wich can lead to local data corruptions.
If a remote attacker can disrupt the communication between the NFS Server and
a OpenBSD NFS client a DoS can get trigered if a mounted NFS-share should get
unmounted. The shell used to execute the umount command will become unavaiable.

A kernel panic can get triggered if the remote user for example shutdowns the
client and the communication to the NFS Server is still interupted.

Steps to reproduce:

At first interupt the connection to the NFS Server by for example unplugging the networkcable.

$ umount /mnt/nfs

If you like to provoke a kernel panic just shutdown.

The risk of this attack should be very low and Thordur Bjornsson, OpenBSD developer, provided patches for OpenBSD 4.4 and later.

Posted by Sebastian Rother | Permanent link | File under: openbsd, denial_of_service

Wed Feb 27 17:47:42 CET 2008

Netgear SSL312 VPN Router DoS

Author Sebastian "Rembrandt" Rother
Date 2008-02-27
Affected Software propietary CGI
Affected OS Netgear embedded Linux for the SSL312 router. Propably other devices are affected as well
Type Denial of Service

OSVDB51847
Milw0rm8008
CVE2009-0680
ISS X-Force48605
BID33657
Secunia33896
VUPEN IDADV-2009-0407

Trying to fix it responsible and get in contact with the vendor:

-- ZDI --
Case Opened 2008-12-28 07:57 GMT-6
Case Closed 2009-01-15 17:01 GMT-6

"After some deliberation we have unfortunately decided that we won't be accepting bugs affecting NetGear products."
-- END --

Contacting Netgear and mitre.org: 2009-02-01 12:25 GTM+1
No reaction, release: 2009-02-06 23:59 GTM+1
Netgear VPN router SSL312 is prone to a remote DoS condition which can get triggered if somebody has access to the webinterface of the VPN router. The problem is related to a propietary CGI binary and makes is impossible for users to patch the router. Further in detail analyses will show several other issues like outdated third party software (e.g. the webserver) and further problems in the cgi-binary itself which won't get disclosed here.

If you download the source code the affected binary can be found at:
./NG_SSL312-GPL/uClinux/uC-src/real/EasyAccess/EasyAccess/www/cgi-bin/single_cgi

Steps to reproduce:

Visit the Netgear SSL312 VPN router webinterface.
You will see a login field and a password field.
Just enter any random data and proceed.

The URL will include a path like:
https://xxx.xxx.xxx.xxx/cgi-bin/welcome/VPN_only?err=VXNlciBMb2dpbiBGYWlsZWQ=

If you modify the URL as below and resend your http request the device will
crash and needs a hard reboot.

https://xxx.xxx.xxx.xxx/cgi-bin/welcome/VPN_only?../../../../../

Example network affected by this: StudiVZ

Simple google dork:
intitle:SSL-VPN intext:password inurl:/cgi-bin/welcome

Workaround:
Preventing others to gain access to the webinterface of the router prevents the attack.

Posted by Sebastian Rother | Permanent link | File under: denial_of_service, authentication

Sun Jun 3 19:47:09 CEST 2007

GNU screen Local Authentication Bypass

Author Sebastian "Rembrandt" Rother
Date 2007-06-03
Affected Software GNU screen <= 4.0.3
Affected OS OpenBSD up to 4.4 (and propably others)
Type Local Authentication Bypass

OSVDB39587
Milw0rm4028
CVE2007-3048
ISS X-Force34693

screen, on some operating systems, is vulnerable to a local terminal screen
lock authentication bypass that may allow physically proximate attackers to
gain access to the system.

This issue has been confirmed on OpenBSD with screen 4.0.3 on x86/amd64.
The underlying vulnerability may be related to 3rd party authentication such
as PAM. This issue was tested on OpenSuSE with screen 4.0.2 and was not
vulnerable.

Steps to reproduce:

$ screen -S test
[Screened session starts]
$ id
uid=1001(test) gid=1001(test) groups=1001(test)
$
[type ctrl-a x]
Key: test
Again: test
Screen used by test .
Password:
[type ctrl-c]
$ screen -r
[Regained access to screen, without password]

The screen lock mechanism is designed to lock a terminal, not the entire shell
session. If an attacker has shell access to the target account, it is understood
they can bypass protection. However, on the system tested, the screen lock
mechanism was bypassed using 'ctrl-c'.

The vulnerability is not in OpenBSD. screen developers indicate this is known
behavior, but do not appear to fully understand the scenario with which
this can be abused. Replies to my initial disclosure suggest this may be
related to PAM authentication, or another 3rd party package. Testing was
not performed to fully identify the vulnerable code.

Tobias Ulmer has committed a patch to the screen code that prevents
this exploit from happening.

Patch:
http://archives.neohapsis.com/archives/openbsd/2008-06/1408.html

Posted by Sebastian Rother | Permanent link | File under: openbsd, authentication

Wed Apr 25 22:49:30 CEST 2007

OpenSSH S/Key Remote Information Disclosure Vulnerability

Author: Sebastian "Rembrandt" Rother
Date: known since somewhere in 2005
Affected Software: OpenSSH 4.6 <=, Proppably everything wich is based on OpenSSH
Type: Remote
Type: Enumeration of system accaunts
CVE: 2007-2243


OpenSSH is vulnerable to an information leak which allows remote attackers
to gain informations about system accounts, in case S/KEY is used on the system.

If "ChallengeResponseAuthentication" is set to "Yes", which is the default
setting, SH allows the user to login by using S/KEY in the form of
'ssh userid:skey at hostname'.

The normal behavior for SSH looks like this:


alucard $ ssh user at somewhere
Permission denied (publickey,keyboard-interactive).


Passwordauthentication is disabled as you can see.
Now you can test about ChallangeResponseAuthentication.
If it`s enabled it will let you determine the existence of system accounts.


alucard $ ssh user:skey at somewhere
otp-md5 99 some04578
S/Key Password:

alucard $


If a account does not exist OpenSSH reacts like exspected.


alucard $ ssh testuser:skey at somewhere
Permission denied (publickey,keyboard-interactive).


As you can see clearly OpenSSH discloses the existence of system accounts.
A possible solution for this problem would be to print a fake S/Key-Request
even for non existing users as well as it`s done with the Passwordauthentication.

Posted by Sebastian Rother | Permanent link | File under: openbsd, openssh, authentication