tunneling through hotspot firewall

Posted by Daniel Gultsch on Apr 22

Hey guys,

this is my first posting on this mailling list. I kinda hope this is
the right place. However lets get to the point.

Suppose I’d have an unencrypted wireless lan with an dhcp server and a
router integreted in the access point. By default a firewall is
blocking all traffic coming…

URL: http://seclists.org/pen-test/2009/Apr/0131.html

Twitter Packet Challenge Solution, (Sat, Apr 18th)

Yesterday, I posted the packet below as my twitter feed to see how the packet skills are among my followers (my twitter feed is also replicated to Facebook).
Anyway. Here the solution. I came across this packet while playing with scapy6 being bored on a plane. I was doing some manual fuzzing among VMWare systems I had setup (of course, wifi/bluetooth was turned off ).
This packet is valid in the sense that I believe it to be RFC compliant, even though it doesn’t actually make sense. I never managed to send the packet as the VMware Linux system would give me a kernel panic whenever I tried. It is a pretty simple IPv6 packet, with IPv6 header and a Hop-by-Hop header. There is no payload and no higher level protocol header. The Hop-by-Hop header has one option: A Jumbo packet. Jumbo packets are used to send packets that are larger then 64k, but then again, there is nothing to prevent you from sending an empty packet with the option. So as a little joke, I thought it may be nice to see what various systems do if you tell them there is a huge empty packet coming. Of course, it never left… but well,
RFC2675 actually covers issues like that. In this case, the first host/router receiving the packet, if it understands jumbograms, should send a ICMPv6 parameter problem error with a code of 0 .
I am waiting for a plane right now and maybe I will get to it later. (Airtran Flights JAX-ATL-SFO… in case you want to re-book).

60 00 00 00 00 00 00 40 FE 80 00 00 00 00 00 00
02 0C 29 FF FE 0C 44 6D FE 80 00 00 00 00 00 00
02 23 12 FF FE 53 F5 4F 3B 00 C2 04 00 00 00 00

6: IP Version 6
0 0: Trafic Class 0
0 00 00: Flow label 0
00 00: Payload length 0 (this is normal for Jumbo packets.)
00: Next header 0 (Hop-By-Hop)
40: Hop Limit 64 (Default)

Next we got the two link local IP addresses:
FE80::020C:29FF:FE0C:446D
FE80::0223:12FF:FE53:F54f

So the IPv6 header is normal . Next the Hop-by-Hop header:

3B: There is nothing after this header (Next header: No more headers)
00: complete length of this header is 8 bytes
C2: We got a Jumbogram option here
04: total length of the option value, 4 bytes
00 00 00 00: The option value…

So this is a jumbo gram header setting the packet size to 0.

Extra credit question I added later was make of the systems involved…
The address uses the standard EUI64 encoding. The MAC addresses are
00:0C:29:0C:44:6D
00:23:12:53:F5:4F
(don’t forget to flip bit #7..)
accoridng ot the OUT database standards.ieee.org/regauth/oui/oui.txt,
the systems are:
00:0C:29 – VMWare
00:23:12 – Apple

Anyway. thought it was fun to tweet a packet. Maybe we will get an IP tunnel
over twitter going one of these days. It is just hard with an MTU of 170 Bytes.

]]> http://sechero.com/twitter-packet-challenge-solution-sat-apr-18th/feed/ 0 http://sechero.com/securing-rdp-is-it-possible-6/ http://sechero.com/securing-rdp-is-it-possible-6/#comments Tue, 14 Apr 2009 21:39:00 +0000 invalid string

RE: Securing RDP – Is it possible?

Posted by Craig S. Wright on Apr 15

Changing the default port adds obscurity and not security.

Next, SSL will help with TLS fully enabled – this is client side
certificates, but these are rarely used.

Otherwise, SSL is just a dark tunnel, it helps stop sniffing, but not the
attacks. In fact, it makes it more difficult to…

URL: http://seclists.org/pen-test/2009/Apr/0091.html

Watch your Internet routers!, (Mon, Mar 30th)

ISC reader Nick contacted us to share information about an Internet router at his workplace that got hacked this weekend. There’s several nuggets to learn from in this story, so here goes.
3/28/2009 8:34:02 Authen OK test

3/28/2009 8:34:04 test Default Group where cr

3/28/2009 8:34:05 test Default Group who cr

3/28/2009 8:34:13 test Default Group who cr

3/28/2009 8:34:19 test Default Group show version cr

3/28/2009 8:34:23 test Default Group who cr
A successful login of a user test is definitely not a welcome sight in the TACACS authentication log of an Internet router. And the commands that follow are a clear indication that something sinister is going on. We know since Cliff Stoll’s experience that somebody who needs to constantly look over his shoulder while connected (issuing the who command) isn’t up to any good.
At this time though, Nick’s firm didn’t know this yet … And the command log continues
3/28/2009 8:38:38 test Default Group show configuration cr

3/28/2009 8:38:59 test Default Group show interfaces cr

3/28/2009 8:39:48 test Default Group configure terminal cr

3/28/2009 8:39:50 test Default Group interface Tunnel 128 cr

3/28/2009 8:39:57 test Default Group show interfaces cr

3/28/2009 8:41:48 test Default Group configure terminal cr

3/28/2009 8:41:49 test Default Group access-list 20 permit 192.168.2.2 cr

3/28/2009 8:41:50 test Default Group ip nat pool new [removed] netmask 255.255.255.252 cr

3/28/2009 8:41:51 test Default Group ip nat inside source list 20 pool new overload cr

3/28/2009 8:41:52 test Default Group ip nat inside source static tcp 192.168.2.2 113 [removed] 113 extendable

3/28/2009 8:41:52 test Default Group interface Serial 1/0 cr

3/28/2009 8:41:53 test Default Group ip nat outside cr

3/28/2009 8:41:53 test Default Group interface Tunnel 128 cr

3/28/2009 8:41:53 test Default Group ip nat inside cr

3/28/2009 8:41:54 test Default Group ip address 192.168.2.1 255.255.255.0 cr

3/28/2009 8:41:54 test Default Group ip tcp adjust-mss 1400 cr

3/28/2009 8:41:55 test Default Group tunnel source Serial 1/0 cr

3/28/2009 8:41:55 test Default Group tunnel destination [removed] cr
Whoa! The bad guy is not wasting any time. Barely five minutes after connecting, and he has configured a network tunnel back to his home base.
3/28/2009 8:47:23 test Default Group configure terminal cr

3/28/2009 8:47:26 test Default Group line console 0 cr

3/28/2009 8:47:32 test Default Group password *****

3/28/2009 8:47:45 test Default Group who cr

3/28/2009 8:47:55 test Default Group configure terminal cr

3/28/2009 8:48:01 test Default Group line vty 0 1052 cr

3/28/2009 8:48:06 test Default Group password *****

3/28/2009 8:49:12 test Default Group no transport input cr

3/28/2009 8:49:26 test Default Group transport input ssh cr
As a next step, the bad guy changes the locally configured passwords. This doesn’t make much of a difference, since these accounts only are used when the central TACACS database is not reachable. While the hacker shows quite some familiarity with setting up an IP tunnel on a Cisco router, he doesn’t seem to fully grasp the significance of the TACACS entries in the configuration: since TACACS includes accounting logs, all his commands get recorded.
At 08:52, the bad guy logs off, and Nick’s firm is still completely unaware that their perimeter router has just been subverted. But not for long: At 09:00, their RANCID script kicks in, pulls the current configuration off the router, compares it with the last known good configuration, and immediately e-mails the changes to the network admin. Luckily, the admin understands the significance of what he sees right away, and alerts the incident response team. A while later, the test user is removed, the config is cleaned up again, and the bad guy is locked out.
Nick’s own lessons learned that he shared with us are:
– Disable outside management of Internet routers unless 100% required

– Log!! Log!! Log!!

– Review logs, review logs, review logs.

– Dont use easy usersnames/passwords.

– Talk to people, this includes ISP’s. Get the word out of wrong doing.

– Dont hack back…(we didnt, but people sometimes feel the need to retaliate). This is against the law.

– Keep router firmware upgraded.
To which we at SANS ISC would like to add our own
– What saved the day here is the use of RANCID, which acted like a trip wire. Something the bad guy clearly didn’t expect

– Having a privileged user named test with a guessable password is of course unwise. But mistakes happen all the time – that’s why we security folks all strive to build our defenses in a way that one single mistake isn’t enough to sink the ship. Defense in depth works!
Thanks to Nick for sharing the logs and information about the attack!

URL: http://isc.sans.org/diary.php?storyid=6100&rss

CVE-2009-0635 (ios)

Memory leak in the Cisco Tunneling Control Protocol (cTCP) encapsulation feature in Cisco IOS 12.4, when an Easy VPN (aka EZVPN) server is enabled, allows remote attackers to cause a denial of service (memory consumption and device crash) via a sequence of TCP packets.

URL: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-0635

CVE-2009-0629 (ios, ios_s, ios_t, ios_xr)

The (1) Airline Product Set (aka ALPS), (2) Serial Tunnel Code (aka STUN), (3) Block Serial Tunnel Code (aka BSTUN), (4) Native Client Interface Architecture (NCIA) support, (5) Data-link switching (aka DLSw), (6) Remote Source-Route Bridging (RSRB), (7) Point to Point Tunneling Protocol (PPTP), (8) X.25 for Record Boundary Preservation (RBP), (9) X.25 over TCP (XOT), and (10) X.25 Routing features in Cisco IOS 12.2 and 12.4 allows remote attackers to cause a denial of service (device reload)…

URL: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-0629

Cisco IOS cTCP Denial of Service Vulnerability

A series of TCP packets may cause a denial of service (DoS) condition on Cisco IOS devices that are configured as Easy VPN servers with the Cisco Tunneling Control Protocol (cTCP) encapsulation feature. Cisco has released free software updates that address this vulnerability. No workarounds are available; however, the IPSec NAT traversal (NAT-T) feature can be used as an alternative.

URL: http://www.cisco.com/en/US/products/products_security_advisory09186a0080a90459.shtml

[tool] Webtunnel 0.0.5

Posted by Janos Szatmary on Mar 17

I’d like to announce the release of Webtunnel 0.0.5, available at sourceforge.net/projects/webtunnel
.

WHAT’S NEW

2009/03/17

     Added support for proxy auto-configuration
     Fixed a bug that would cause a keep-alive timeout to…

URL: http://seclists.org/pen-test/2009/Mar/0099.html

Cisco IOS Virtual Private Dial-up Network Denial of Service Vulnerability

Two vulnerabilities exist in the virtual private dial-up network (VPDN) solution when Point-to-Point Tunneling Protocol (PPTP) is used in certain Cisco IOS releases prior to 12.3. PPTP is only one of the supported tunneling protocols used to tunnel PPP frames within the VPDN solution.

URL: http://www.cisco.com/en/US/products/products_security_advisory09186a0080969862.shtml