Configuring the client is actually fairly straight forward and only requires the setting used to configure the Firewall VPN and a rudimentary understanding of IPSEC. The guidance within this article is simply mapping the VPN settings directly to the client configuration.

0) Open the NetScreen-Remote Security Policy Editor through the Start menu or by right clicking the task bar icon and selecting Security Policy Editor…

Remote Party Identity and Addressing

1) Create a new connection.  In this example I chose to call the connection ‘Home’.  Ensure that the “Remote Party Identity and Addressing” section matches the VPN Server “Phase 2 Proposals” Proxy-ID section.

Client Identity

2) Next, select “My Identity” and set the pre-shared key used when configuring the VPN Server.  You should also configure the “ID Type” under the ‘My Identity” section.  For the Dial-Up VPN the ID Type should be set to “Email Address” and should correspond to a user configured on the VPN Server within the “Remote VPN Group” (though this may be called something else).  The “Secure Interface Configuration” and “Internet Interface” sections can be left alone.

Security Policy

3) Next, select “Security Policy” and set the Phase 1 Negotiation Mode to “Aggressive Mode”.  (NOTE: “Main Mode” may also be selected for identity protection provided the server supports it.  The Juniper KB article shows Aggressive mode being selected.) It is important to note that the NetScreen VPN uses the Diffie-Hellman Group 2 Key Group.  Group 2 will also have to be selected within the Phase 1 proposal tab as well.  NetScreen also supports Replay Protection and Perfect Forward Secrecy (PFS) however these need to be enabled on the server side as well.

Authentication (Phase 1) and Key Exchange (Phase 2)

4) For the next two tabs “Authentication (Phase 1)” and “Key Exchange (Phase 2)” be sure to configure the proposals that line up with the VPN Server Phase1 and Phase 2 settings. Specifically align the Encryption Algorithms and the Hash Algorithms.

That should be about it.  The biggest mistake most people seem to make is matching the Proxy-ID IP Address and Subnet to the “Remote Party Identity” ID

The code works fresh from the box however, pay attention to Python’s preference for tabs:

class SMB2(SocketServer.BaseRequestHandler):
 def handle(self):
   print "Who:", self.client_address
   print "THANKS SDL"
   input = self.request.recv(1024)
   self.request.send(packet)
   self.request.close()

launch = SocketServer.TCPServer(('', 445),SMB2)
launch.serve_forever()

There really is nothing special that is required to make this work.  Executing the Python script will open a socket listening on TCP/445.  When the target attempts to access SMB services on the attacker, the target will hang.

I was not able to produce a BSOD and in some test cases the target was recovered once the SMB session was terminated.  NOTE: any SMB session connection will do, however as Laurent pointed out the ‘dir’ method is the easiest.

Just for grins, I captured the errant packet as it flew across the wire.  This is the encoded back from Laurent’s source in PCAP format decoded in Wireshark.

Why do we care?  How many organizations or even home users block egress SMB ?  Not many I’m certain.