TOP
AutoresTOTAL
LecturasSET 36
123690 visitas
- Contenidos - SET Staff
- Editorial - SET Staff
- TOR - Una Verdad a Medias - blackngel
- Bazar de SET - Varios Autores
- 1er Reto Torneo Shell Warzone (BoF) (bazar) - blackngel
- Biblioteca del Hacker 3.0 (bazar) - blackngel
- HTTP Fingerprinting - gcode
- 2do Reto Torneo Shell Warzone (HoF) - blackngel
- 3er Reto Torneo Shell Warzone (BoF) - blackngel
- Criptografia Practica 02 - blackngel
- Historia de un CrackMe - blackngel
- Proyectos, peticiones, avisos - SET Staff
- Ataque a la Fortaleza SAP - SET Staff
- Cracking WiFi al Completo - blackngel
- Curso de electronica 07 - elotro
- Rendimiento del PC - Arien
- Heisenbugs & Company - blackngel
- Llaves PGP - SET Staff
Ataque a la Fortaleza SAP
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*