Date: Wed, 10 Feb 1999 15:08:50 -0800 From: David Schwartz To: BUGTRAQ@netspace.org Subject: Security problems in ISDN equipment authentication A security flaw is probably still present in Ascend's multilink PPP implementation over ISDN. Due to its fundamental nature, it's probably in other ISDN hardware as well. Ascend determines whether to bond a new incoming PPP connection with a previous connection based upon the 'endpoint identifier'. As I recall, they claimed that they had to do this because they had to decide whether to bond or not _before_ they received any other authentication information. Most ISDN routers use their Ethernet hardware address as their endpoint identifier. I'm not sure what modems and T/As use. However, since the endpoint identifier is specified by the other end, it is fundamentally insecure to rely upon it for a security decision, such as whether to bond to an existing PPP connection. The way we discovered this was during WebRamp beta testing, when the firmware had an interesting bug. It seems that every WebRamp sent the same endpoint identifier! Sure enough, if two WebRamps ever connected to the same Max or TNT, they'd get bonded to each other and both would fail to send any (futher) data reliably. Ascend insisted that the bug was in the WebRamp (it was sending an invalied endpoint ID). We responded that while there was a bug in the WebRamp, it was exploiting a security flaw in the Ascend. Anyone can, in principle, specify any endpoint identifier that they wish. Ascend simply got WebRamp to fix the flaw, and to my knowledge, this weakness still exists. Anyone who knows your endpoint identifier can bond to your PPP link. Anyone who you have ever connected to with your ISDN equipment knows your endpoint identifier, and you cannot easily change it. To an extent, the problem is fundamental. If you aren't using PAP or CHAP, but instead use a text 'sign on' form of authentication, but are bonding multiple connections, what means does the other end have to determine whether to bond to an existing connection when it receives a new one? But we had this problem even with PAP or CHAP enabled -- I'm not entirely sure why. DS ------------------------------------------------------------------------------------ Date: Fri, 12 Feb 1999 09:14:12 -0800 From: David Schwartz To: BUGTRAQ@netspace.org Subject: PPP/ISDN multilink security issue - summary My thanks to the many people who responded to my post about security issues when terminal servers make the decision about whether to bond two physical connections into a single network connection (multilink PPP). Ascend has stated (unofficially) that their implementation was at one point insecure, and relied upon the TEI or EDO (endpoint identifier) to make the decision. This is in violation of standards. They state that their implementation has been secure for about three years and will not bond two connections together unless the authenticate with the same username. If multilink PPP is properly implemented, it should make two connections _eligible_ to be linked together if and only if their TEIs match. However, it must be prepared to not link them if they later identify (by PAP or CHAP) for different accounts. The RFCs state, according to Jeff Mcadams : The Endpoint Discriminator Option represents identification of the system transmitting the packet. This option advises a system that the peer on this link could be the same as the peer on another existing link. If the option distinguishes this peer from all others, a new bundle MUST be established from the link being negotiated. If this option matches the class and address of some other peer of an existing link, the new link MUST be joined to the bundle containing the link to the matching peer or MUST establish a new bundle, depending on the decision tree shown in (1) through (4) below. To securely join an existing bundle, a PPP authentication protocol must be used to obtain authenticated information from the peer to prevent a hostile peer from joining an existing bundle by presenting a falsified discriminator option. The problem is, it seems that in some cases the router needs to do certain things one way if it's going to bundle the two connections together and another way if it's not going to, and it may need this information _before_ the new connection has authenticated: Dennis Kavanaugh states: Sadly, the real problem, IMHO, is in the Multilink PPP spec; if a vendor wants to conform to the spec, they must allow this to happen. I spent quite a bit of time with numerous vendors trying to explain the inherent vulnerabilities in the existing spec, but they didn't seem to understand or be bothered by the potential problems. The spec covers any type of MLPPP connection, be it dial-up ISDN (i.e., T/A), multiple async, or Brouter. Both ends must understand what can be done, and take steps to ensure they are providing as much security as they feel they need for the given situation. It's just another case where poor configuration can result in poor security. In reality, the resulting session when a hijacked session bonds with a legitimate session is unusable. Sort of 'security by unusability', if you don't count the DoS. The unusuability occurs because compression is usually in use, and the compression breaks when you only have part of a bundle. It seems that it is possible to do things right, but there are probably numerous implementations that incorrectly bond two connections with the same identifier even if they authenticate for different accounts. I still wouldn't want anyone else to know the Ethernet hardware address of my ISDN router. David Schwartz