La caza de Hackers. Ley y desorden en la frontera electrónica (8 page)

Read La caza de Hackers. Ley y desorden en la frontera electrónica Online

Authors: Bruce Sterling

Tags: #policiaco, #Histórico

BOOK: La caza de Hackers. Ley y desorden en la frontera electrónica
13.53Mb size Format: txt, pdf, ePub

Pero los sistemas totalmente electrónicos están introducidos en chips de silicio, alcanzan velocidades asombrosas, son baratos y muy duraderos. Su mantenimiento es más barato que incluso el de los mejores sistemas electromecánicos y ocupan la mitad de espacio. Y cada año los chips son aún más pequeños, más baratos y más rápidos. Y lo mejor de todo, los sistemas electrónicos automatizados trabajan durante todas las horas del día y no hay que pagarles sueldo ni seguro médico.

Utilizar chips tiene sin embargo bastantes inconvenientes importantes. Cuando se estropean, es un gran desafío averiguar qué demonios ha fallado. Un cable roto era generalmente un problema lo suficientemente grande como para verse. Un chip roto tiene invisibles fallos microscópicos. Y los fallos de
software
pueden ser tan sutiles, como para convertirse en cuestiones teológicas.

Si quieres que un sistema mecánico haga algo nuevo, tendrás que ir al punto adecuado, sacar algunas piezas y poner en su lugar piezas nuevas. Esto cuesta dinero. Sin embargo, si quieres que un chip haga algo nuevo, todo lo que has de hacer es cambiar el
software
, algo fácil, rápido y tirado de precio. Ni siquiera tienes que ver el chip para cambiar su programación. Aunque vieras el chip, daría igual. Un chip con el programa X no tiene un aspecto diferente al de uno con el programa Y.

Con los códigos apropiados, las secuencias de órdenes apropiadas y pudiendo acceder a líneas telefónicas especializadas, puedes modificar los sistemas electrónicos de centralitas de cualquier parte de América, desde cualquier lugar. Y eso lo pueden hacer algunas personas. Si saben cómo, pueden entrar en el
software
de algún microchip a través de las líneas especiales y organizar una estafa sin dejar ningún rastro físico. Si entraran a mano armada en la oficina de centralitas y encañonaran a Leticia, sería demasiado descarado. Si se colaran en un edificio de telecomunicaciones y fueran a por un sistema electromecánico cargados de herramientas, esto dejaría muchas pistas. Pero la gente puede hacer multitud de cosas sorprendentes a un sistema electrónico, simplemente tecleando y hoy en día hay teclados por todas partes. La extensión de esta vulnerabilidad es profunda, oscura, amplia, casi inconcebible y ésta es una realidad absoluta en cualquier ordenador conectado a una red.

Los expertos en seguridad han insistido durante los últimos veinte años, cada vez más apremiantemente, en que esta vulnerabilidad básica de los ordenadores representa un nivel de riesgo completamente nuevo, de un potencial desconocido pero obviamente terrible para la sociedad. Y tienen razón.

Una centralita electrónica hace prácticamente el mismo trabajo que hacía Leticia, con la diferencia de que lo hace en nanosegundos y en una escala mucho mayor. Comparada con los diez mil conectores de Miss Luthor, incluso una primitiva centralita electrónica 1ESS, de la
cosecha
de los años 60, tiene unas 128.000 líneas. Y el actual sistema de AT&T es la monstruosa quinta generación, la 5ESS. Una centralita electrónica, puede comprobar todas las líneas de su
panel
en una décima de segundo y hace esto continuamente, sin cansarse, hora tras hora. En lugar de ojos tiene
sondas
para comprobar la situación de cada línea local y troncal. En lugar de manos, tiene
distribuidores de señal
,
distribuidores centrales de pulsos
,
relés magnéticos
e
interruptores de lengüeta
, que completan e interrumpen las llamadas. En lugar de un cerebro, tiene un
procesador central
. En lugar de un manual de instrucciones, tiene un programa. En lugar de una libreta escrita a mano para anotar y llevar la contabilidad de las llamadas, tiene cintas magnéticas. Y no tiene que hablar con nadie. Todo lo que tiene que
decirle
un usuario lo recibe por la pulsación de teclas del teléfono.

Aunque una centralita no puede hablar, necesita una interfaz. Alguna manera de comunicarse con sus, ¡Eh...!, jefes. Esta interfaz es denominada
centro principal de control
. —Podría llamarse simplemente
interfaz
ya que en realidad no controla las llamadas telefónicas directamente—. Sin embargo, un término como
Centro Principal de Control
es la clase de retórica, que los ingenieros de mantenimiento de telecomunicaciones —y los
hackers
— consideran gratificante.

Usando el centro principal de control, un ingeniero de telefonía puede buscar errores en las líneas locales y troncales. Él —rara vez ella— puede comprobar varias pantallas de alarma, medir el tráfico en las líneas, examinar los registros de uso de un teléfono, el coste de esas llamadas y cambiar la programación.

Y por supuesto, cualquier otra persona que acceda al centro principal de control remotamente, también puede hacer estas cosas, si él —rara vez élla— es capaz de imaginarse cómo hacerlo, o, mejor aún, ha conseguido averiguarlo robándole los datos necesarios a alguien que sabía cómo hacerlo.

En 1989 y 1990, una RBOC, BellSouth, que se sentía en dificultades, gastó al parecer 1.200.000 dólares en seguridad. Algunos consideran que gastó en realidad dos millones teniendo en cuenta gastos asociados. Dos millones de dólares son muy poco comparado con el gran ahorro que suponen los sistemas electrónicos de telefonía.

Lamentablemente, los ordenadores son estúpidos. A diferencia de los seres humanos, los ordenadores poseen la profunda estupidez de lo inanimado.

En los años 60, durante las primeras oleadas de informatización, se hablaba con facilidad sobre la estupidez de los ordenadores —se decía que
sólo podían ejecutar su programación
y se les pedía que hicieran
sólo lo que se les decía que hicieran
—. Se ha empezado a hablar menos de la estupidez de los ordenadores desde que empezaron a conseguir la categoría de gran maestro en torneos de ajedrez y a manifestar otras características de una aparente inteligencia.

Sea como sea, los ordenadores son
aún
profundamente frágiles y estúpidas; simplemente su fragilidad y su estupidez es mucho más sutil. Los ordenadores de los años 90, tienen componentes mucho más fiables que los de los primeros sistemas, pero también se les hace ejecutar tareas mucho más complejas bajo condiciones mucho más difíciles.

En un nivel matemático básico, cada línea de un
software
ofrece alguna posibilidad de fallo. El
software
no permanece estático cuando se ejecuta; está
corriendo
, interactuando consigo mismo y con sus entradas y salidas. Es como una masa que adopta millones de posibles formas y condiciones, tantas formas que nunca pueden probarse todas del todo, ni siquiera en el tiempo de vida del universo. Y a veces la masa se rompe.

Eso que llamamos
software
, no se parece a ninguna de aquellas cosas en las que la sociedad humana está acostumbrada a pensar. El
software
se parece a una máquina, a matemáticas, a un lenguaje, a pensamiento, arte, información... pero el
software
no es en realidad ninguna de estas cosas. Esa cualidad multiforme del
software
es una de las cosas que lo hace fascinante. También lo hace muy poderoso, muy sutil, muy impredecible y muy arriesgado.

Algunos programas son malos y están llenos de errores. Otros son
robustos
, incluso
a prueba de balas
. El mejor
software
es aquél que ha sido probado por miles de usuarios bajo miles de condiciones diferentes durante años. Entonces es denominado
estable
. Esto
no
quiere decir que el
software
sea ahora perfecto y que esté libre de errores. Generalmente quiere decir que hay muchos errores, pero han sido identificados correctamente y se han hallado sus causas.

No hay ninguna manera de asegurar que un programa esté libre de errores. Aunque el
software
es de naturaleza matemática, no puede ser
demostrado
como un teorema matemático; el
software
se parece más al lenguaje, con ambigüedades inherentes, con definiciones diferentes, con suposiciones diferentes y diferentes niveles de significado que pueden entrar en conflicto.

Los seres humanos pueden arreglárselas más o menos con los lenguajes humanos, porque podemos captar su esencia.

Los ordenadores, a pesar de años de esfuerzos en la
inteligencia artificial
, han demostrado que se les da terriblemente mal
captar la esencia
. El más insignificante bit erróneo puede tumbar al ordenador más potente. Una de las cosas más complicadas trabajando con un programa de ordenador es intentar mejorarlo —para intentar hacerlo más seguro—. Los
parches
de
software
son un
software
nuevo, no probado e
inestable
, por definición más peligroso.

El sistema telefónico moderno ha acabado dependiendo total e irreversiblemente del
software
. Y la
caída del sistema
del 15 de enero de 1990, fue causado por una
mejora
del
software
. O mejor dicho, un
intento
de mejorarlo.

Lo que ocurrió, el problema en esencia, tenía esta forma:

Se escribió una parte de
software
de telecomunicaciones en C, —un lenguaje estándar en el campo de las telecomunicaciones.
En este programa en C hay una larga sentencia
do-while.
Este
do-while
tenía una sentencia
switch.
Este
switch
tenía un
if.
Este
if
tenía un
break.
Se suponía que el
break
hacía que el flujo del programa, sólo saliera del
if.
En realidad, salía del
switch.

Este fue el problema, la verdadera razón por la que la gente que descolgó el teléfono el 15 de enero de 1990, no pudo llamar a nadie. O al menos ésta fue la sutil y abstracta raíz ciberespacial del problema. Ésta fue la manera, en la que el problema de programación se manifestó en el mundo real:

El Sistema 7 de las centralitas 4ESS de AT&T, el «
Software
Genérico 44E14 de Oficina Principal de Centralitas», ha sido probado muchas veces y estaba considerado como muy estable. A finales de 1989, ochenta de los sistemas de centralitas de AT&T de todo el país, habían sido programados con el nuevo
software
. Por precaución, se había seguido utilizando en otras treinta y cuatro centralitas el Sistema 6, más lento y con menos capacidades, porque AT&T sospechaba que podría haber problemas con la nueva red de Sistema 7, de sofisticación sin precedentes.

Las centralitas con Sistema 7, estaban programadas para pasar a una red de respaldo en caso de problemas. A mediados de diciembre de 1989, sin embargo, se distribuyó un nuevo parche de
software
de gran velocidad y seguridad, a cada una de las centralitas 4ESS, que les permitiría trabajar aún más rápido y hacer que la red de Sistema 7 fuera aún más segura.

Desafortunadamente, cada una de estas centralitas 4ESS tenía ahora un pequeño pero mortal fallo.

Para mantener la red, los enlaces conectores de línea de las centralitas, deben comprobar las condiciones del resto de enlaces —si están listos y funcionando, si están parados momentáneamente, si tienen sobrecarga y necesitan ayuda... El nuevo
software
ayudaba a controlar esta función, monitorizando el
status
de otros enlaces.

A un enlace de una 4ESS que tenga dificultades, sólo le lleva entre cuatro y seis segundos deshacerse de todas sus llamadas, dejar todo temporalmente y reinicializar su
software
. Reinicializar, generalmente liberará al enlace de cualquier problema de
software
que se haya desarrollado durante la ejecución del sistema. Los errores que aparezcan serán simplemente barridos por este proceso. Es una idea inteligente. Este proceso de reinicialización automática, se conoce como
rutina normal de recuperación de fallo
. Dado que el software de AT&T es excepcionalmente estable, sus sistemas rara vez tienen que ejecutar una
recuperación de fallo
; pero AT&T siempre ha alardeado de su fiabilidad en el
mundo real
y esta táctica es una rutina similar a llevar cinturón y tirantes a la vez.

Los enlaces de las 4ESS usaban su nuevo
software
, para monitorizar los enlaces de alrededor al recuperarse de fallos. A medida que otros enlaces volvían a conectarse tras recuperarse, enviaban señales OK al enlace. El enlace, hacía una anotación sobre esto en su
mapa de status
, confirmando que el enlace vecino estaba de vuelta y listo para funcionar, que podía recibir algunas llamadas y ponerse a trabajar.

Desafortunadamente, mientras el enlace estaba atareado anotando en el mapa de
status
, el pequeño
fallo
en el nuevo
software
entraba en juego. El error hacía que el enlace 4ESS interactuara, sutil pero drásticamente, con las llamadas telefónicas que recibía hechas por personas. Si —y sólo si— dos llamadas coincidían en el mismo enlace en menos de una centésima de segundo, una pequeña parte del programa y los datos era estropeada por el error.

Pero el enlace estaba programado para monitorizarse a sí mismo constantemente en busca de cualquier dato dañado. Cuando el enlace percibía que sus datos habían sido dañados de alguna manera, entonces se desconectaba para hacer reparaciones de urgencia en su
software
. Enviaba una señal a los enlaces de alrededor para que no le mandaran trabajo. Entraba en el modo de recuperación de fallos durante unos cinco segundos. Y después, el enlace volvería a funcionar y enviaría su señal OK,
listo para trabajar
.

Sin embargo, la señal OK,
listo para trabajar
era lo que
precisamente
antes había hecho que el enlace se desconectara. Y
todos
los enlaces del Sistema 7 tenían el mismo
fallo
en su
software
de
mapa de status
. Tan pronto como se detuvieran para anotar que sus enlaces vecinos estaban funcionando, entonces también estarían expuestos a la pequeña posibilidad, de que les llegaran dos llamadas en menos de una centésima de segundo.

A eso de las 14:25 horas en la Costa Este, un lunes 15 de enero, uno de los enlaces del sistema de centralitas de llamadas interurbanas de Nueva York tuvo un pequeño
fallo
normal. Entró en la rutina de recuperación de fallos, emitió la señal
me desconecto
, y después emitió la señal
he vuelto
,
estoy en funcionamiento
. Y este alegre mensaje, se extendió por la red hasta llegar a muchos de sus enlaces 4ESS vecinos.

Other books

The Memory Book by Howard Engel
Teetoncey and Ben O'Neal by Theodore Taylor
In The Wake by Per Petterson
Speak Now by Margaret Dumas
Moscardino by Enrico Pea
Please Me: Parisian Punishment by Jennifer Willows
Shadow Catcher by James R. Hannibal