Cómo piratear software Cómo piratear software James A. Whittaker Resumen Este artículo analiza una serie de métodos para descubrir fallas en el diseño y desarrollo de software (los llamados "ataques"). Estos ataques son pruebas exploratorias manuales que se diseñan y ejecutan dinámicamente con poca sobrecarga adicional. Estos ataques se crean estudiando cientos de defectos de software reales y abstrayendo sus causas y fenómenos. Después de dos semestres de análisis detallado, los estudiantes de pruebas de software de Florida Tech identificaron docenas de estrategias de ataque destinadas a encontrar fallas. Estas tácticas resultaron tan útiles que se descubrieron cientos de defectos más en un período de tiempo muy corto, con poco o ningún conocimiento del producto, como resultado directo de estas tácticas. Este artículo presenta un subconjunto de estas estrategias de ataque y explica cómo pueden descubrir fallas reales en los productos lanzados. ¿Qué caracteriza a un buen evaluador? ¿Qué don los hace tan sensibles a las vulnerabilidades? ¿Se puede enseñar esta habilidad? Estas preguntas son el tema de este artículo. Creo que los buenos testers nacen, no se hacen. De hecho, a lo largo de los años, muchos evaluadores parecen haber acumulado un arsenal estándar de estrategias de ataque. De hecho, a lo largo de los años, muchos evaluadores parecen haber acumulado una biblioteca de estrategias de ataque estándar, que reorganizan cada vez que encuentran un problema de prueba difícil para poder encontrar siempre fallas. Aunque estas estrategias de ataque rara vez se documentan, desempeñan un papel importante en las pruebas manuales y la herencia de pruebas. Al estudiar probadores reales y errores reales, comenzamos a documentar esta riqueza. En este artículo exploramos algunos de los resultados de este proyecto. El próximo desafío es automatizar estos ataques y encontrar estrategias específicas para usarlos de manera efectiva. Los ataques se pueden dividir en tres categorías amplias: ? Ataques de entrada/salida ? Cada categoría tiene tipos de ataques específicos que pueden provocar fallos de software muy interesantes. En los siguientes capítulos, utilizaré errores específicos como ejemplos para presentar los tipos de ataques en cada categoría. Todos los errores involucrados provienen de productos de Microsoft. No creo que esto deba verse como un comportamiento anti-Microsoft. El hecho de que Microsoft sea un actor dominante en la industria del software lo convierte en un objetivo natural. Sin embargo, no debemos dar por sentado que los productos de Microsoft tengan más defectos que los de otros proveedores de software. Las tácticas de ataque descritas en este artículo han tenido éxito contra una variedad de productos de software de empresas que se ejecutan en prácticamente cualquier plataforma que se pueda imaginar. Mi experiencia muestra que los desarrolladores crean vulnerabilidades con frecuencia sin importar para qué dominio estén desarrollando aplicaciones, qué sistema operativo estén usando y si publican el código fuente o no. Si son desarrolladores web, el problema es menor, porque los propios programas de red. son propensos a sufrir accidentes. Ataques de entrada/salida Los ataques de entrada/salida son lo que los evaluadores llaman pruebas de "caja negra" porque no se requieren datos internos ni información computacional para respaldar la ejecución de la prueba. De hecho, este es el tipo de prueba más común porque leer el código fuente es tedioso y consume mucho tiempo, y a menudo no sirve de nada a menos que sepas exactamente qué tipo de vulnerabilidad estás buscando (hablaremos de eso en la siguiente sección). dos partes) Qué lagunas jurídicas deberíamos intentar encontrar). Ataque de entrada/salida Ataque de entrada única Forzar la aparición de todos los mensajes de error Forzar la especificación de valores predeterminados Pruebe todos los conjuntos de caracteres disponibles Forzar el cambio del tamaño del área de salida Provocar que el área de visualización se desborde Provocar problemas de actualización de la pantalla Ataque de combinación de entradas Forzar la aparición de resultados no válidos La búsqueda no se puede estropear Combinación de entradas Ataques de secuencia de entradas Forzar la aparición de resultados no válidos Repetir la misma secuencia de entradas muchas veces Ataques de entrada única Estos ataques se dirigen a usuarios que utilizan una única entrada (o una combinación de entradas). Este tipo de ataque estudia el comportamiento del uso de una única entrada (entrada variable). Intentamos encontrar situaciones en las que una sola entrada provocaría que la aplicación fallara mientras la mayoría de los datos funcionaban normalmente. Además de considerar los valores límite, existen muchas otras formas de seleccionar casos de uso de entrada, especialmente si desea encontrar vulnerabilidades que los desarrolladores realmente reconozcan y no simplemente ignoren los requisitos indefinidos. Primero, un consejo que parece simple pero que no es fácil de implementar: asegúrese de que todos los mensajes de error aparezcan una vez. Los errores generalmente no hacen que el programa aborte o finalice correctamente; muchos mensajes de error simplemente obligan al programa a dejar de mostrar el mensaje de error y luego continuar con la siguiente entrada o hasta que expire un temporizador. Sin embargo, también hay mensajes de error que provienen de excepciones lanzadas por el programa y excepciones causadas por la ejecución del controlador de excepciones.
A menudo surgen problemas cuando un controlador de excepciones (o un hilo central de manejo de errores) cambia repentinamente un puntero sin el correspondiente cambio en el estado de los datos. Tan pronto como se ejecuta el controlador de excepciones, surgen varios problemas de datos: el archivo no se cierra, la memoria no se libera y los datos no se inicializan. Cuando el control regresa al hilo principal, es difícil saber cuándo se llamó al controlador de errores y qué problemas restantes esperan al desarrollador desprevenido: la apertura del archivo falló porque el archivo no se cerró o antes de que se inicializaran los datos. . Si podemos asegurarnos de que el sistema sigue funcionando correctamente después de recibir todos los mensajes de error, podemos ahorrarles muchos problemas a nuestros usuarios (sin mencionar a nuestros ingenieros de mantenimiento). La Figura 1 muestra un error interesante que mis alumnos descubrieron en Microsoft Word 2000, donde por alguna razón el mensaje de error apareció dos veces seguidas. El error se descubrió durante un único ataque al hilo de manejo de errores. Asegúrese de que el software especifique los valores predeterminados. Los desarrolladores a menudo no recuerdan especificar valores predeterminados cuando la entrada del usuario se sale del rango o los parámetros se establecen en valores irrazonables. A veces, forzar un valor predeterminado significa no hacer nada, pero como esto no es lo esperado, es difícil incluso para los mejores desarrolladores hacerlo. Por ejemplo, en Word 2000, el siguiente cuadro de diálogo tiene una casilla de verificación que desaparece cuando abre el cuadro de diálogo nuevamente sin realizar ningún cambio. Compare los cuadros de diálogo en las imágenes de la izquierda y la derecha. ¿Falta algún control? A veces, especificar un valor predeterminado requiere cambiar la configuración actual de un valor antes de establecerlo en un valor no razonable. Esta conversión continua garantiza que se establezca el valor predeterminado antes de convertirlo a otro valor utilizable. Intente ingresar todos los juegos de caracteres disponibles para la variable. Algunos problemas de entrada son simples, especialmente cuando se utilizan caracteres como $, %, #, comillas, etc. Estos caracteres tienen significados especiales en muchos lenguajes de programación y, a menudo, requieren un manejo especial cuando se leen como entrada. Si el desarrollador no tiene esto en cuenta, estas entradas pueden provocar que el programa falle. Cambiar el volumen de entrada provoca cambios en el área de salida. Centrarse en el resultado en sí es un método productivo pero rara vez utilizado para encontrar errores. La idea es asumir que una salida o comportamiento se comporta como una vulnerabilidad y luego buscar la entrada que lo causa. Un ejemplo simple del ataque anterior es activar un recálculo del tamaño de la región de salida cambiando el valor de entrada y la longitud de la cadena de entrada. Un buen ejemplo conceptual es configurar la hora del reloj a las 9:59 y luego esperar a que la hora del reloj cambie a las 10:00. Inicialmente, el área de visualización tiene 4 caracteres y luego 5 caracteres. En su lugar, configuramos la hora en 12:59 (5 caracteres) y esperamos a que cambie a 1:00 (4 caracteres). Los desarrolladores a menudo simplemente manejan la inicialización como en blanco sin pensar en cómo actualizar el área de visualización para mostrar diferentes longitudes de datos si ya hay datos en esa área. Por ejemplo, hay un error interesante en la función "Arte de personajes" de PowerPoint. Supongamos que ingresamos una cadena larga, como se muestra en la imagen a continuación. Puede ver que no se muestra la cadena completa porque es demasiado larga. Pero ese no es el punto. Se activarán dos eventos después de hacer clic en el botón confirmar. Primero, el programa calcula el tamaño del área de salida requerida y la llena con el texto ingresado. Ahora, editamos la cadena y la cambiamos a un solo carácter. Puede ver que aunque ahora solo hay un carácter y el tamaño de fuente no ha cambiado, el tamaño del área de visualización no ha cambiado. Mira más abajo. Si editamos la cadena nuevamente en una cadena de varias líneas, el resultado será más interesante. Creo que esta parte se ha explicado con relativa claridad y pasaremos a la siguiente. Asegúrese de verificar los límites del área de visualización. Esta es otra idea de ataque basada en resultados, muy similar a la anterior. Sin embargo, el ataque anterior se centró en provocar errores dentro del área de visualización, mientras que esta vez nos centramos en el exterior del área de visualización. Además, el área de visualización ya no volverá a calcular los límites de visualización, sino que solo tendrá en cuenta el desbordamiento de los límites. Tomando PowerPoint como ejemplo, podemos dibujar un cuadro de texto e ingresar una cadena con un superíndice. Aumente el tamaño de fuente de la cadena para que la parte superior del superíndice quede truncada. Este y otros temas relacionados se explicarán más adelante. Causando problemas de actualización de pantalla. Este es un gran problema para los usuarios de la GUI de Windows.