Re: SMC Barricade 7008ABR port forwarding

["WiM" <vulndev () vision rma ac be>]

The connection to port 25 on 192.168.1.7 gets established, data is exchanged
and the connection is properly terminated. All this, while 192.168.1.7
"sees" the address XX.XXX.XXX.XXX.

This shows you that the replies from 192.168.1.7 get back beyond the SMC
Barricade to the outside client that is trying to establish a connection to
port 25 on the Barricade.

This would mean that the Barricade is actually applying NAT from the outside
to the inside (instead of the other way around).

Could you try to disactivate NAT on the Barricade and check whether this
changes its behavior with respect to the port forwarding problem. In that
case, it's probably an bug in that part of SMC's firmware.

WiM

----- Original Message -----
From: "nate" <vulndev () aphroland org>
To: <vuln-dev () securityfocus com>
Sent: Wednesday, November 27, 2002 7:25 AM
Subject: SMC Barricade 7008ABR port forwarding


> I tried doing some googling but didn't come up with much.
>
> One of my friends contacted me, his ISP(road runner) emailed
> him saying he was running an open relay on his box. I checked
> and sure enough it was allowing relays.
>
> Looking closer the problem seems to be on the router/modem itself
> not the box. the router is not properly re-writing the packets
> it port forwards for port 25(at least not all the time).
>
> Inbound connections to port 25 reveal the source IP of the external
> interface on the router, NOT the source ip of the acutal machine
> connecting. However, connecting to port 22 reveals the source IP
> of the actual machine connecting.
>
> again, rebooting the router fixed the problem, so that inbound SMTP
> requests were showing the proper source address that was connecting
> (me). The server is very low traffic, so I was the only one connected
> to the machine at the time of my tests according to netstat.
>
> The router's management interface seems extremely simple, and looking
> at the configuration it seems OK. I mean for port forwarding it
> just asks for
>
> Internal IP
> Internal port
> external port
>
> tcpdump log from my machine(which goes out of my NAT) to his machine
> port 25(what I did was echo "quit" | /usr/bin/nc remote_host 25)
>
> tcpdump run: tcpdump -n dst port 25
> his IP changed to the XX's for privacy(and the fact he's an open
> relay ATM)
>
> 23:04:02.908336 10.10.10.59.1364 > XX.XXX.XXX.XXX.25: S
> 1770303467:1770303467(0) win 32120 <mss 1460,sackOK,timestamp 1368186
> 0,nop,wscale 0> (DF)
> 23:04:03.068472 10.10.10.59.1364 > XX.XXX.XXX.XXX.25: . ack 2567611199 win
> 32120 <nop,nop,timestamp 1368202 139100879> (DF)
> 23:04:03.072261 10.10.10.59.1364 > XX.XXX.XXX.XXX.25: P 0:5(5) ack 1 win
> 32120 <nop,nop,timestamp 1368203 139100879> (DF)
> 23:04:08.303975 10.10.10.59.1364 > XX.XXX.XXX.XXX.25: . ack 150 win 32120
> <nop,nop,timestamp 1368726 139101402> (DF)
> 23:04:08.305124 10.10.10.59.1364 > XX.XXX.XXX.XXX.25: . ack 151 win 32120
> <nop,nop,timestamp 1368726 139101402> (DF)
> 23:04:08.310901 10.10.10.59.1364 > XX.XXX.XXX.XXX.25: F 5:5(0) ack 151 win
> 32120 <nop,nop,timestamp 1368727 139101402> (DF)
>
>
> tcpdump on his side:
> 00:08:52.148586 XX.XXX.XXX.XXX.65038 > 192.168.1.7.25: S
> 1770303467:1770303467(0) win 32120 <mss 1460,sackOK,timestamp 1368186
> 0,nop,wscale 0> (DF)
> 00:08:52.301089 XX.XXX.XXX.XXX.65038 > 192.168.1.7.25: . ack 2567611199
win
> 32120 <nop,nop,timestamp 1368202 139100879> (DF)
> 00:08:52.305154 XX.XXX.XXX.XXX.65038 > 192.168.1.7.25: P 0:5(5) ack 1 win
> 32120 <nop,nop,timestamp 1368203 139100879> (DF)
> 00:08:57.537516 XX.XXX.XXX.XXX.65038 > 192.168.1.7.25: . ack 150 win 32120
> <nop,nop,timestamp 1368726 139101402> (DF)
> 00:08:57.538479 XX.XXX.XXX.XXX.65038 > 192.168.1.7.25: . ack 151 win 32120
> <nop,nop,timestamp 1368726 139101402> (DF)
> 00:08:57.545016 XX.XXX.XXX.XXX.65038 > 192.168.1.7.25: F 5:5(0) ack 151
win
> 32120 <nop,nop,timestamp 1368727 139101402> (DF)
>
>
> now, connecting to port 22 instead of 25:
>
> from my side(same tcpdump options except I'm using port 22)
>
> 23:08:59.994817 10.10.10.59.1368 > XX.XXX.XXX.XXX.22: S
> 2086127748:2086127748(0) win 32120 <mss 1460,sackOK,timestamp 1397895
> 0,nop,wscale 0> (DF)
> 23:09:00.157249 10.10.10.59.1368 > XX.XXX.XXX.XXX.22: . ack 2893297488 win
> 32120 <nop,nop,timestamp 1397911 139130589> (DF)
> 23:09:00.160288 10.10.10.59.1368 > XX.XXX.XXX.XXX.22: P 0:1(1) ack 1 win
> 32120 <nop,nop,timestamp 1397912 139130589> (DF)
> 23:09:00.313106 10.10.10.59.1368 > XX.XXX.XXX.XXX.22: . ack 24 win 32120
> <nop,nop,timestamp 1397927 139130604> (DF)
> 23:09:00.325790 10.10.10.59.1368 > XX.XXX.XXX.XXX.22: . ack 44 win 32120
> <nop,nop,timestamp 1397928 139130605> (DF)
> 23:09:00.330457 10.10.10.59.1368 > XX.XXX.XXX.XXX.22: F 1:1(0) ack 44 win
> 32120 <nop,nop,timestamp 1397929 139130605> (DF)
>
> from his side:
>
> 00:13:47.530571 216.39.174.24.64972 > 192.168.1.7.22: . ack 3871033271 win
> 32120 <nop,nop,timestamp 1397725 139130401> (DF) [tos 0x10]
> 00:13:49.247800 216.39.174.24.65044 > 192.168.1.7.22: S
> 2086127748:2086127748(0) win 32120 <mss 1460,sackOK,timestamp 1397895
> 0,nop,wscale 0> (DF)
> 00:13:49.399097 216.39.174.24.65044 > 192.168.1.7.22: . ack 2893297488 win
> 32120 <nop,nop,timestamp 1397911 139130589> (DF)
> 00:13:49.402313 216.39.174.24.65044 > 192.168.1.7.22: P 0:1(1) ack 1 win
> 32120 <nop,nop,timestamp 1397912 139130589> (DF)
> 00:13:49.554598 216.39.174.24.65044 > 192.168.1.7.22: . ack 24 win 32120
> <nop,nop,timestamp 1397927 139130604> (DF)
> 00:13:49.566539 216.39.174.24.65044 > 192.168.1.7.22: . ack 44 win 32120
> <nop,nop,timestamp 1397928 139130605> (DF)
> 00:13:49.572871 216.39.174.24.65044 > 192.168.1.7.22: F 1:1(0) ack 44 win
> 32120 <nop,nop,timestamp 1397929 139130605> (DF)
>
> (216.39.174.24 is my ip)
>
> again, all occurances of XX.XXX.XXX.XXX originally was his real ip
> (some IP inside of road runner).
>
> restarting the router seems to fix the problem for an undetrmined amount
> of time(sofar less then 30 minutes in each case). I have never worked
> with any SMC router equipment but this behavior is VERY strange to me.
> Just the fact that it changes the way the packets come in out of nowhere
is
> enough for alarm.
>
> I haven't tried to contact SMC yet, was hoping for any insight others
> may have on the issue. And if anyone else may be using this product
> and perhaps can reproduce it. He is running the latest firmware available
> on the website - 1.41.008.
>
> very strange!! any ideas?
>
> thanks
>
> nate