Ataque a la Fortaleza SAP

      6738

Autor: SET Staff

-[ 0x0A ]--------------------------------------------------------------------
-[ Ataque a la fortaleza SAP ]-----------------------------------------------
-[ by set-ezine ]----------------------------------------------------SET-36--


ATAQUE A LA FORTALEZA SAP 

Hay dias que parece que nada sucede, o al menos nada que valga la pena registrar
en nuestra memoria ni en el diario que escribimos en la vana esperanza de que
alguien lo lea cuando ya no naveguemos en este mundo. Sin embargo hay otros que
acumulan tal cantidad de novedades que no tenemos tiempo ni siquiera para
registrar en algun sitio lo que no podemos hacer ahora, pero debemos hacer en
un futuro proximo. Estos son los dias mas peligrosos. Escondidos dentro de la
avalancha de noticias inutiles, se esconden a menudo datos que nos pueden ser
de gran utilidad mas adelante en otras condiciones. Uno de esos dias, mientras
Viajero intentaba poner orden y fijar prioridades en una centena de mensajes
atrasados, su escondido diablillo le llamo la atencion sobre un inofensivo
mensaje que le informaba acerca de un "patch" no oficial sobre el conocido
"John The Ripper", un "patch" que pretendia adaptar dicho "crackeador" de
"hash" para atacar las cenizas de las "password" de SAP, el famoso "software"
de gestion integral empresarial.


ALGUNOS DATOS SOBRE SAP

SAP es un acronimo de "Systeme, Anwendungen und Produkte", que en aleman
significa "Sistemas, Aplicaciones y Productos". Como su nombre indica es
una empresa alemana que se dedica a producir "software" empresarial, lo que
no se puede deducir de su nombre es que bajo estas tres letras se esconde
una empresa que tiene en nomina decenas de miles de empleados, millones de
clientes, cientos de miles de instalaciones y una cifra de negocios de miles
de millones de euros. En resumen un monstruo que ha conseguido crear de facto
un cierto standard que se puede encontrar en muchas de las conocidas
multinacionales, tan monstruosas como el.

El origen de SAP esta en IBM, ya que fueron antiguos empleados descontentos de
esta potente empresa que decidieron jugarse su posicion y dejaron sus comodos
empleos en su empresa madre para fundar en 1972 en la ciudad de Mannheim,
Alemania, (los pioneros fueron, Claus Wellenreuther, Hans-Werner Hector, Klaus
Tschira, Dietmar Hopp y Hasso Plattner) una oscura empresa que se dedicaba a
vender "trajes a medida" en el mercado del software empresarial. Su gran vision
fue no olvidar y reutilizar el codigo cada vez que se hacia una aplicacion en
concreto para un cliente que solicitaba algo nuevo, de forma que cada programa
era coherente y compatible con los desarrollados anteriormente.
Muy probablemente sin darse realmente cuenta de lo que hacian, crearon una
telaraña de programas capaces de relacionar los datos de todos los aspectos
de una empresa.

Puede que ahora parezca evidente, pero en 1972 todos los procesos informaticos
trabajaban en batch sobre bases de datos independientes que no se hablaban entre
ellas. La salida de un programa se vertia sobre una base de datos que debia ser
leida por otro programa especialmente concebido para hacer una tarea diferente.
El resultado era que los datos se encontraban almacenados en kilometricas cintas
magneticas, a menudo de forma redundante y sin ninguna coherencia logica entre
ellos. SAP fue el primero, o el primero con exito comercial, que consiguio
unificar los datos de forma que, por ejemplo, un dato basico como el DNI, solo
se encontrara en una unica base de datos y si era necesario acceder a el solo
fuera necesario acceder a una tabla, que es como se refieren a esta organizacion
de la informacion en la jerga de SAP.

La evolucion de esta empresa se ve claramente en la organizacion de los modulos
que forman sus aplicaciones, si tenemos suficientes millones de euros y nos
ponemos en contacto con un comercial de SAP, este nos informara gentilmente que
su software se compone en realidad de 12 modulos llamados:

   - Gestion Financiera (FI),
   - Controlling (CO),
   - Tesoreria (TR),
   - Sistema de proyectos (PS),
   - Gestion de personal (HR),
   - Mantenimiento (PM),
   - Gestion de calidad (QM),
   - Planificacion de producto (PP),
   - Gestion de material (MM),
   - Comercial(SD),
   - Workflow (WF),
   - Soluciones sectoriales (IS) y
   - Activos Fijo(AF).

O sea todos los aspectos de una empresa pueden gestionarse de forma integrada
y homogenea.

Ello significa que SAP vela para que la cifra de ventas prevista para el año
proximo sea igual (mas, menos stocks) a la produccion prevista. Las materias
primas no pueden ser distintas a lo que arroje el calculo automatica de dicha
produccion, la tesoreria debe ajustarse a estas compras teniendo en cuenta lo
que dice el modulo de mantenimiento y el de gestion de proyectos, resumiendo,
que ningun jefecillo de los numerosos departamentos que puedan integrar una
gran sociedad mercantil pueden mentir impunemente sin que SAP saque a relucir
la diferencia en alguna parte y saque los colores al aprendiz de Pinocho.

Viajero habia conocido en el pasado situaciones ridiculas en las cuales la
produccion prevista para el proximo ciclo economico podia tener tres valores
distintos segun el auditorio, en que las "transparencias" eran facilmente
manipulables y no habia nadie que controlase la coherencia de los datos. Si
el oyente de turno estaba contento con los colores y datos de la presentacion,
porque complicarse la vida dando datos reales?; Mas de una empresa se ha
hundido debido a este tipo de descontrol interno. Con la nueva era "SAP",
esto ya no es posible.


ASPECTO GENERAL DE SAP PARA AL USUARIO

SAP tiene un aspecto para el usuario de a pie que podriamos calificar como de
deshonesto. Nos explicamos. Las pantallas generales parecen bastante agradables
y "user friendly" pero cuando se empieza a trabajar con el, el usuario se da
cuenta que todos los datos pueden cambiar en funcion de como los introducimos
o como hacemos las preguntas a pesar de los menus iniciales de bienvenida
aparentemente sencillos. Todo es consecuencia de como nacio este software, sin
orden ni concierto. Cada modulo, hoy plenamente integrado con el resto, estaba
formado por una serie de base de datos a las cuales se accedian a traves de
programas o "query" que se identificaban con dos letras, que representaban el
modulo y despues dos numeros que probablemente eran correlativos.
Aunque parezca mentira esto continua siendo la forma de acceder mas utilizada.
Cuando se "clickea" sobre un elemento del menu en realidad lo que se esta
haciendo es lanzar un programa auxiliar que nos presenta una pantalla donde
podemos introducir algunos parametros, despues se lanza el programa de toda
la vida con los parametros introducidos anteriormente. En la jerga de SAP esto
se denomina lanzar una "transaccion" y existen miles de ellas.

A lo largo de los mas de treinta años que han pasado desde la creacion de SAP,
los programas han ganado en complejidad sin cambiar de nombre, lo que ha
generado unas pantallas de introduccion de datos y parametros que ni tan solo
sus creadores son capaces de descifrar. Los programas originales, que debian
ser sencillos "querys", se han complicado de tal forma que los agujeros de
seguridad son famosos en todo el mundo. Las pantallas de introduccion de
parametros, tienen efectos que nadie se atreve a pronosticar y las revisiones
periodicas tiene una periodicidad bastante elevada.

No solo la complejidad tiene efectos sobre la seguridad sino tambien sobre la
forma en que los datos son tratados, ello hace que la prioridad numero uno de
SAP sea buscar los defectos que pueden generar problemas de coherencia de datos
antes que de seguridad. Hay dos razones para que se siga esta politica, una es
que si un dato contable es incorrecto una empresa se puede encontrar con que
los balances no sean adecuados y que la empresa que haga la auditoria se vea
obligada a hacer una salvedad, esto puede ser dramatico y tener consecuencias
enormes para una gran corporacion, pero puede ser igualmente importante para
una pequeña empresa si la facturacion no es adecuada aunque sea dentro de un
corto periodo de tiempo.

En ambos casos a SAP le pueden sacar los colores. Asi que su prioridad numero
uno es que no existan estos errores. Otra razon es que tradicionalmente todo
acceso se hace dentro de la empresa y estos accesos se consideran seguros.
Esto puede ser cierto o no. El caso es que SAP nunca ha cuidado la seguridad
y que el usuario medio se ve inmerso dentro de un galimatias de parametros que
dan soberbios dolores de cabeza al probo empleado, risa al vago que no tiene
ganas de trabajar y curiosidad malsana al que tenga un poco de cerebro dentro
del craneo.


LA ESTRUCTURA DE UNA IMPLEMENTACION SAP

Dada la complejidad de todo el sistema SAP, una implementacion clasica esta
formada normalmente por tres conjuntos de bases de datos y programas totalmente
separados. El primero es el sistema de desarrollo, el segundo es el de pruebas
y el ultimo es el de produccion. La forma de trabajar es desde el primero hacia
el ultimo, o sea, se hace toda la configuracion en la primera zona, todas las
pruebas en la segunda  y si todo va bien, la modificacion se copia en la maquina
de produccion. Nadie que no sea un suicida profesional hace ninguna modificacion
sobre la maquina de produccion ni siquiera los "patchs" de seguridad ya que los
efectos a veces son inesperados.

La configuracion normalmente es incluso mas compleja, ya que pueden haber
segmentos que comparten programas, las famosas  transacciones, pero no
comparten datos y otras que comparten ambas cosas. Si la explicacion no os
sirve de nada y solo os ha dado dolor de cabeza, lo cierto es que para los
administradores este galimatias les supone la fuente de su trabajo. Hay que
mantener el servicio a los usuarios, tener el sistema al dia aplicando los
"patch" que SAP saca regularmente y dejar un espacio de trabajo para que los
programadores puedan ganarse honestamente su salario. Todo ello sin que la
facturacion deje de salir y los "controllers" tengan sus informes regularmente.
Ante semejante tarea titanica no nos puede extrañar que la seguridad sea la
ultima de las prioridades.

Uno de los problemas principales de SAP supone el lugar donde se encuentran
almacenadas las "hash" y la forma en que se puede acceder a ellas. Por defecto
hay dos tablas donde se almacenan estos datos. La primera, llamada USR02,
contiene la "hash" actual y las ultimas cinco que se han utilizado. Si esto no
fuera bastante, en su hermana mayor USH02 estan todas las "hash" sean producto
de cambios hechos por el usuario como los realizados por el administrador.
Consecuencia de ello es que si conseguimos encontrar el sistema de atacar las
"hash" podemos no solo saber cuales son las palabras de paso si no tambien los
habitos de usuarios y administradores.



PISANDO TIERRA FIRME 

Todo ello paso por la mente de Viajero con la rapidez de un rayo mientras leia
el mensaje dirigido a la lista de distribucion de "John". Entre las muchas
cosas que habia hecho durante su carrera profesional se encontraba el pertenecer
a un grupo de "key users" que habian ayudado a configurar y validar una
instalacion de un ERP basado en SAP. Como podeis imaginar, todo "key user"
tiene un perfil limitado en la maquina de produccion pero este es mucho mas
amplio en la maquina de desarrollo, sobre todo debido a que la empresa habia
decidido hacer la implementacion contando solo con los recursos internos, sin
apelar a la ayuda de ningun consultor externo y esto habia sido fuente de
polemicas sin cuento, luchas fratricidas internas por nimiedades y discusiones
interminables entre jefes que no tenian la menor idea de lo que se estaba
hablando, sin embargo la consecuencia fue que se debieron hacer innumerables
maquetas con distintas configuraciones para intentar convencer a los inutiles
que pretendian tener las llaves del desarrollo.

El caso es que en algun momento Viajero tuvo acceso a esta maquina y aunque no
recordaba el perfil de usuario que le fue otorgado, si recordaba la direccion
de la maquina, el usuario y su password. En cuanto tuvo ocasion hizo un intento
de conexion, solo para recibir un mensaje diciendo que hacia tiempo que dicho
usuario habia sido dado de baja. Sin embargo no se rindio. Sabiendo que en SAP
nada se borra, sino solo se marca para borrar, supuso que sus accesos debian
dormir en algun sitio y que solo hacia falta despertarlo con alguna escusa.

Hizo uso de sus conocimientos y contactos de la epoca de "key user" y pidio que
su login fuera de nuevo activado, con una vaga excusa acerca de una recuperacion
de datos que ahi habia almacenados. A nadie le extraño, ya que como hemos dicho
y Viajero bien sabia, en el mundo SAP nada se borra y es muy frecuente la
demanda de acceso a viejos datos. El problema se complico simplemente ya que
nadie parecia tener la responsabilidad clara sobre los accesos de la maquina de
desarrollo cuando no hay en curso un proyecto importante y este era el caso.
Finalmente se consiguio que un oscuro funcionario de la sociedad, perdido en un
remoto pais, despertara al antiguo usuario y Viajero se encontro con que podia
de nuevo entrar en la vieja maquina.


PRIMEROS PASOS 

Siempre habia entrado en la maquina para hacer pruebas sobre posibles
configuraciones en modulos que nada tenian que ver con la seguridad y por
lo tanto no tenia ni idea de cuales eran las "transacciones" que le podian
dar acceso a la tabla USH02 para encontrar las  "hash" de los usuarios. Un
vago recuerdo le llevo a probar con GR55 que es una transaccion generica de
manipulacion de tablas, pero recibio un ambiguo mensaje informandole que
faltaba algun parametro de configuracion Se podian hacer muchas cosas, pero
casi siempre lo mejor es consultar en internet y alli descubrio que la
"transaccion" de sus suenos era SE16, aunque normalmente no debia ser
accesible a un usuario normal por muy "key" que fuera. Sin embargo hay que
recordar que Viajero habia entrado en un sistema de "test" y ahi las reglas
de seguridad eran mucho mas relajadas. Sin mucha sorpresa comprobo que su
perfil le permitia lanzar "SE16" y se encontro ante sus ojos la tabla entera
con todos los usuarios que habian utilizado el sistema (en SAP, nada se borra)
con sus sucesivas "hash".

Bien. Una cosa era "ver" los datos y otra conseguirlos en un formato que
despues fuera facilmente manipulable, afortunadamente SAP vino en ayuda de
Viajero, ya que por defecto tiene una aplicacion que permite convertir el
fichero en pantalla en otra en formato ASCII o bien "spreadsheet" compatible
con Excel. Fue asi como Viajero obtuvo un bonito archivo con mas de 500
"hash", todo para su uso particular. Ahora habia que convertir estos datos
en algo que "john" fuera capaz de digerir.

Algo que hay que tener muy en cuenta. Hasta este momento no se habia cometido
ningun tipo de delito. El perfil que le habian otorgado los administradores le
permitia, con toda legalidad, leer las tablas USR02 y USH02, hacer una copia
privada y se supone que analizar su contenido. Es un problema general en todos
los sistemas de desarrollo. Nadie se imagina que se pueda plantear un ataque
desde el interior del sistema y sin embargo es bastante elemental y sencillo
y por tanto, lo normal seria que el acceso a ciertos datos este un poco mas
controlado.

SAP ha desarrollado dos tipos de sistemas de cifrado, el mas viejo, "CODVN A"
tiene muchos defectos y practicamente ya no se utiliza. Desde hace mas de diez
años se utiliza el sistema de cifrado "CODVN B" que tampoco es ninguna
genialidad. De entrada no distingue entre mayusculas y minusculas. Ademas esta
el problema con los caracteres no ASCII, en la practica se pueden substituir
todos los caracteres no 7bit ASCII por el caracter "^" sin que la "hash" cambie.

Todo ello le vino a la mente a Viajero mientras releia el mensaje que dirigido
a la lista de "john" en "openwall" donde se informaba tambien que las "hash" se
formaba "salteando" con el "user". El "patch" habia previsto esto de forma que
el "user" se habia formado añadiendo al original espacios en blanco hasta un
valor de cuarenta caracteres que es la maxima permitida. En el mismo mensaje el
autor habia incluido un "script" en "perl" que extraia del fichero excel los
datos y creaba dos ficheros, uno por si encuentra "hash" tipo "CODVNA" y otro
para "CODVN B", que pueden ser usados directamente para el "john" modificado.
El siguiente paso es compilar y linkar el "john" con el "path" aplicado.


COMPILANDO Y EJECUTANDO JOHN-7.2-SAPLover 

Viajero se encontraba en la misma situacion que muchos paseantes aficionados
del ciberespacio. No tenia tiempo para mantener dos maquinas con sistemas
operativos distintos ni ganas de pasearse por el mundo con dos "laptops" debajo
del brazo y la consecuencia era que solo disponia en sus viajes de un portable
empresarial equipado con Windows XP, eso si, con una ultima actualizacion de
"cygwin". Una vez descomprimido el fichero "diff" en el directorio "src" de la
distribucion "john 7.2" a Viajero le basto con teclear:

 - "patch -p -Z < john-1[1].7.2-SAPLover-1.diff"

Sin embargo a la hora de compilar se encontro con el mismo problema que en otra
ocasion le ocurrio al compilar para aplicar un patch para MIPCH, y la solucion
fue la misma, cambiar ligeramente el "makefile" para que en el momento de hacer
el "linkado" las fuentes se presenten en el orden adecuado. A veces parece que
los desarrolladores se empecinen en convertir las cosas mas simples, en
complicadas operaciones . 

A Viajero le resulto de lo mas sencillo la utilizacion del nuevo "john"
modificado. Le basto con lanzarlo directamente poniendo como unico parametro
el fichero que contenia las "hash", nuestro inteligente "john" detecto
rapidamente el formato SAP, las "hash" detectadas y los diferentes "salts"
empleados, que no coincidian con las "hash" ya que habian diferentes passwords
para el mismo usuario debido a la memoria elefantica de SAP. De todas formas
"john" le comunico inmediatamente que estaba perdiendo tiempo y recursos ya
que SAP no distinguia entre minusculas y mayusculas y el ataque standard por
fuerza bruta "incremental" hace uso de ambos tipos de caracteres. A fin de
economizar recursos y obligar a "john" a saltarse las minusculas hay varias
soluciones pero una de las mas sencillas es crear un nuevo modo en el fichero
"john.conf" con el contenido de la "Figura 1" y lanzar "john" con el nuevo modo.

El resultado fue espectacular, apenas unas horas mas tarde, cien password
cayeron en la red. Como Viajero no tenia prisa lo dejo correr unos dieciocho
dias con el resultado que mas de 1500 password se encontraban almacenados en
"john.pot" al final del ataque. Ahora solo hacia falta probar si la cosecha
era de buena calidad y ver si se podia entrar en el sistema de desarrollo y
despues en el de produccion Tomo un usuario al azar y comprobo si podia entrar
en el SAP de desarrollo, el resultado fue cuando menos risible, no solo podia
entrar, sino que SAP le solicitaba que cambiara la password, eso suponia que
la sociedad habia dado a alguien acceso a la maquina de desarrollo, se supone
que para hacer pruebas y ejecutar cosas de calidad, y esa persona no se habia
dignado entrar ni una sola vez. !Desde luego la empresa habia hecho una buena
eleccion con esta persona!

Cuando Viajero consiguio reprimir las carcajadas, razono que debia buscar un
usuario un poco mas activo y una forma de hacerlo era encontrar un usuario que
se encontrara repetidamente en el fichero, signo que habia cambiado la password
repetidamente o sea un usuario que habia hecho pruebas y usaba asiduamente el
sistema. Un usuario asi tiene muchas ventajas, entre otras y no es la mas
pequeña, es que si se tienen diversas password de la misma persona se puede
deducir bastante facilmente cual es el mecanismo que utiliza para cambiar su
palabra de password.

De nuevo utilizando el sutil sistema del azar, busco un usuario con cuatro
password descifradas. Como era de esperar la entrada en el sistema de desarrollo
fue automatica, pero cuando quiso entrar en el sistema de produccion se le
pusieron las cosas un poco mas dificiles, en una palabra el sistema le rechazo.
Aqui el tener varias password le sirvio de bastante ayuda. Estas seguian un plan
bastante claro, digamos que la pauta era lond*M21, lond*M22, lond*M23,... no era
preciso ser un genio del hacker para darse cuenta que las proxima clave seria
lond*M24 o algo parecido. El primer intento fue infructuoso y tambien el
segundo. Viajero dejo pasar media hora para evitar que otro error le bloqueara
el usuario y al tercer intento ya estaba dentro.

Cuando se entra con la piel de otra persona siempre es bueno saber algo de esta.
Fue lo primero que hizo Viajero, mediante la transaccion SU01, investigo acerca
de la personalidad del usuario. Segun parecia era alguien de un departamento
informatico de un pais un tanto alejado. Es del todo normal que los accesos de
los usuarios se deleguen por zonas geograficas o paises Eso da ciertas ventaja
ya que asi los administradores locales pueden resolver conflictos en base a
informacion extra sistema, pero tiene el inconveniente que se multiplican los
administradores y que a nadie se le ocurre buscar un falso movimiento de un
usuario de un pais hecho por un administrador de otro.

De todas formas siempre es deseable comprobar la informacion a traves de,
como minimo, dos fuentes independientes. Para ello utilizo algo bastante
comun en las grandes corporaciones. Cuando ya no es posible conocerse
fisicamente, todas las grandes empresas utilizan los datos del servidor de
correo para ofrecer informacion general acerca de la persona poseedora de la
cuenta de correo. Estos datos son fuente preciosa para cualquier "hacker" y
son de libre utilizacion de cualquiera que tenga acceso a la red desde el
interior y sea propietario de una cuenta valida. Pero claro! Es que dentro
de las corporaciones no hay "hackers"!

Como fuere, el caso es que Viajero comprobo que el usuario al cual estaba
suplantando correspondia con un oscuro administrador encargado de las altas,
bajas y modificaciones de un pais situado en otro continente. Realmente parecia
la presa adecuada para hacer diversas modificaciones sin despertar muchas
sospechas. Animado con estas premisas, cambio el titulo de otro usuario que
trabajaba en un tercer pais. Probablemente años mas tarde alguien se sorprendera
de que Xuan no sea un hombre, sino una mujer y alguno quede intrigado por el
hecho de que el cambio fuera realizado por un probo empleado de un lejano pais.
Todo el mundo lo achacara a un error banal.


PRECAUCIONES 

Nadie en su sano juicio intentaria cambiarse su perfil para atribuirse derechos
que no le correspondia y Viajero era bastante cuerdo. Tan solo se imagino lo
que podia hacerse, como por ejemplo buscar un usuario con muy poco trafico,
cambiarle el perfil, extraer informacion confidencial, guardarla en un servidor
lejano convenientemente cifrada y despues volver al pobre usuario a la condicion
de empleado de a pie. Todo ello a ser posible desde una maquina que se conecte
mediante internet fuera de la red de la corporacion ya que SAP este caso, no
reconoce la maquina desde donde se realiza la conexion, sino solo la IP de
entrada, que es siempre la misma. Toda otra accion es suicida ya que lo mas
probable es que se encuentren implementados varios sistemas de proteccion y una
accion poco juiciosa puede terminar con tu vida profesional abruptamente.


COMENTARIOS FINALES 

La mayor parte de los administradores de sistemas SAP, son cuidadosos y protegen
sus sistemas. Nadie encuentra sistemas en los cuales se han dejado los usuarios
por defecto (SAP*, DDIC, SAPCPIC, Early Watch, Sys, System, SAPr3) con sus
"password de origen (06071992, 19920706, admin, support, Change_On_Install,
Manager, SAPr3). Los clientes que se crean en las instalaciones standard, 000,
001 y 066, tampoco se encuentran activos en un sistema de explotacion, el
problema reside en la debilidad intrinseca de los accesos a los sistemas de
desarrollo. A traves de ellos no solo los programadores pueden cambiar
impunemente cualquier ABAP de acceso, sino los humildes "key users" pueden
acceder tambien a la "hash" de las password y a traves de ellas conseguir una
escalada de privilegios.

Y aqui hay que hacer una reflexion acerca de los "key users". Normalmente no
son informaticos ni son conscientes de los problemas de seguridad. Solo estan
interesados en resolver problemas practicos que se presentan durante el trabajo
que desarrollan. Quieren cambiar los datos de una factura cuyos datos son
defectuoso, o de un pedido mal realizado. Nada les importa que le puede pasar
a la integridad del sistema. Personas basicas con necesidades basicas y como
tales son tratados y nadie piensa que entre ellos se pueda colar alguien que
pretenda conocer el conjunto del sistema. En el caso de que esto ocurra, todos
los datos de la corporacion se pueden encontrar en peligro y con ellos su propia
viabilidad.

Esta es una historia bastante real que da una idea de la debilidad sobre la
que se construyen muchos sistemas de produccion informaticos empresariales.

2008 SET, Saqueadores Ediciones Tecnicas. Informacion libre para gente libre
www.set-ezine.org
web@set-ezine.org

*EOF*