Security problems in ISDN equipment authentication

[davids () WEBMASTER COM (David Schwartz)]

        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