security - que - seis sombreros para pensar resumen
Conocimiento del sombrero negro para los programadores de sombrero blanco (21)
¿Hasta qué punto crees que un programador honesto necesita conocer los métodos de los programadores maliciosos?
Necesitas saber más que ellos.
Siempre hay escepticismo de los no programadores cuando los desarrolladores honestos aprenden las técnicas de los hackers de sombrero negro. Obviamente, sin embargo, tenemos que aprender muchos de sus trucos para que podamos mantener nuestra propia seguridad a la altura.
¿Hasta qué punto crees que un programador honesto necesita conocer los métodos de los programadores maliciosos?
2 lados de la misma moneda. Aparte de la intención, ¿cuál es la pregunta? Mismas habilidades, diferente implementación.
Al final del día, nada de lo que los "sombreros negros" saben es conocimiento delictivo, sino cómo se aplica el conocimiento. Tener una comprensión profunda de cualquier tecnología es valioso como programador, es la forma en que sacamos lo mejor del sistema. Es posible sobrevivir estos días sin conocer las profundidades, ya que contamos con más y más marcos, bibliotecas y componentes que se han escrito utilizando tal conocimiento para ahorrarle tener que saber todo, pero aún así es bueno cavar de vez en cuando.
Básicamente, casi todos los ataques de seguridad utilizados por los piratas informáticos son errores en el código introducido por un estilo de programación pobre o disciplinas. Si escribe código para protegerlo contra datos incorrectos y operaciones de llamadas no válidas, bloqueará la mayoría de las vulnerabilidades de seguridad en su código.
Si está interesado en proteger su código de piratería / abuso / etc. pasarás demasiado tiempo con eso. Solo compre un paquete para proteger lo básico y siga adelante.
Creo que parte de "codificar a la defensiva" incluye conocer técnicas maliciosas, pero, al mismo tiempo, no necesariamente se necesitan conocer todas las técnicas para defenderse eficazmente de ellas. Por ejemplo, conocer los ataques de desbordamiento de búfer no es la razón para tratar de proteger sus búferes del desbordamiento. Los proteges contra el desbordamiento porque si lo hacen, podría causar estragos en tu programa, independientemente de si es un error o un ataque.
Si escribe código minuciosamente revisado y bien estructurado, los ataques maliciosos no podrán penetrar, porque una buena arquitectura debería bloquear automáticamente los efectos secundarios y el acceso no autorizado.
Sin embargo, ese último párrafo asume que tenemos un trabajo perfecto en el que nos dan increíbles cantidades de tiempo para que nuestro código sea el correcto . Dado que tal trabajo no existe, entonces conocer las técnicas maliciosas es un buen atajo, porque significa que aunque su código no es perfecto, puede crear ''no soluciones'' para esos exploits para asegurarse de que no se obtengan mediante. Pero esos no mejoran el código y no mejoran la aplicación.
En última instancia, conocer los exploits maliciosos es algo que es bueno tener en cuenta, pero el 95% de ellos se cubrirá simplemente asegurándose de cumplir con las mejores prácticas.
Cuando escucho la palabra blackhat, pienso en alguien que usa el conocimiento de las computadoras para irrumpir en los bancos y hacer otras cosas dañinas. Un whitehat sabe todo lo que el blackhat sabe, pero simplemente no hace nada malo con él.
Por lo tanto, no tiene cuidado o sabe qué es un "blackhat" para estar seguro ...
Saber cómo piensa un blackhat, cuando ya eres un whitehat equivalente no ayuda a ponerte en cuclillas. Es como saber, "John quiere irrumpir en mi casa y robar mi iPod". Si realmente te importaba tu iPod, deberías haberlo asegurado de todos modos.
Debes entender los métodos que usan los ''chicos malos'', por lo que es obligatorio comprenderlos.
Para el desarrollador promedio, creo que es suficiente asimilar el principio básico de lo que están haciendo para evitar la creación de vulnerabilidades en sus proyectos.
Para alguien que trabaja en un área de seguridad relevante (la banca viene a la mente, o datos de tarjetas de crédito de una tienda en línea), se requiere una comprensión más profunda. Esos desarrolladores tienen que "ocultarse" de cómo funciona un "tipo malo" y qué técnicas usa.
Definitivamente aprende el lado oscuro. Incluso si no aprende las técnicas reales, al menos haga el esfuerzo de aprender lo que es posible.
alt text http://ecx.images-amazon.com/images/I/51rqNSV141L._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg alt text http: //ecx.images-amazon .com / images / I / 519BX6GJZVL._BO2,204,203,200_PIsitb-sticker-arrow-click, TopRight, 35, -76_AA240_SH20_OU01_.jpg
Buenos recursos para aprender los trucos del oficio son Inversión: secretos de la ingeniería inversa y piratería: el arte de la explotación . Están escritos para ambos lados; podrían usarse para APRENDER a hackear, pero también para prevenir este tipo de ataques.
En gran medida. Tienes que pensar como un criminal, o no eres lo suficientemente paranoico.
Hasta el punto de que al aprender sus formas, comienza a pensar en su dirección. Y luego debe elegir a qué lado quiere "pertenecer".
No hay nada malicioso en la tecnología en sí ... el conocimiento es puro ... es la forma en que lo usas lo que determina cómo se debe mirar.
Tomaré la postura controvertida y diré que hay algunos conocimientos de sombrero negro de que no es necesario ser un buen hacker de sombrero blanco. Un médico no necesita saber cómo manipular genéticamente un virus para tratar efectivamente la enfermedad.
Trabajo como agente de seguridad, no desarrollador, y de acuerdo con mi experiencia, puedo decir simplemente que no se puede aprender cosas tan buenas como el sombrero negro o los sombreros blancos profesionales a menos que sea su segunda profesión. Simplemente consume mucho tiempo.
Lo más importante es ver a algunos malos o profesionales en acción y comprender cuáles son las posibilidades y el impacto del código inseguro.
Así que al aprender algunos trucos, pero muchos de ellos uno puede tener la sensación de "falsa sensación de seguridad" porque él o ella no puede hackear. Aunque un atacante mejor capacitado podría hackear lo mismo en cuestión de minutos.
Habiendo dicho eso, tan pronto como tengas esto en cuenta, creo que es bueno aprender algunos ataques, divertidos y bastante educativos para aprender a romper cosas.
Una de las técnicas que los White Hats necesitan aprender es cómo probar / mitigar / pensar en términos de ingeniería social, porque la mayor amenaza a la seguridad es la gente.
Los Sombreros Blancos son buenos para manipular los bits, pero las personas son las que los Sombreros Negros manipulan mucho más a menudo.
Una habilidad que a menudo se pierde es la ingeniería social.
Muchas personas simplemente no reconocen cuándo están siendo engañados. En una compañía anterior, un vicepresidente ejecutó una prueba al tener tres (mujeres) trabajadores temporales en una sala de conferencias para llamar a programadores y administradores de sistemas, y trabajar desde el script para intentar que alguien otorgue acceso o revele las contraseñas. Cada uno de los temporales tuvo acceso a algo en la primera hora de llamadas.
Apuesto a que si se ejecutara una prueba similar en cualquier compañía de tamaño mediano a grande, obtendrían los mismos resultados.
Una palabra de advertencia: Estado de Oregon vs. Randal Schwartz .
Habiendo sido una pequeña parte de la investigación de dos incidentes separados en nuestro sitio, diría que las posibilidades de aprender sobre un exploit antes de que se usen contra usted son infinitamente pequeñas. Quizás si dedicas tu carrera a ser un sombrero blanco estarás al tanto de todos los agujeros potenciales en la mayoría de las pilas populares de hardware / software. Pero para un programador ordinario, es más probable que estés en modo reacción.
Usted tiene la responsabilidad de saber cómo se puede piratear su propio software y la responsabilidad de mantenerse razonablemente actualizado con el software de terceros. Sería bueno contar con un plan de emergencia para enfrentar un ataque, especialmente si usted es un objetivo de alto perfil o de alto valor. Algunos lugares querrán cerrar un agujero de inmediato, pero nuestro sitio tiende a dejar ciertos huecos abiertos para ayudar a las autoridades a atrapar a los perpetradores. El equipo de seguridad de TI ocasionalmente anuncia internamente que realizará un escaneo de puertos para que las SA no se enloquezcan al respecto.
Vale la pena ser tan "inocentes como las palomas, y tan sabios como las serpientes", y aprender técnicas que hacen las personas con propósitos nefastos. Dicho esto, dicho conocimiento debe usarse con cuidado. "Con un gran poder viene una gran responsabilidad".
Voy a llegar tarde en esto, ya que acabo de enterarme en el podcast. Sin embargo, ofreceré mi opinión como alguien que ha trabajado en el equipo de seguridad de una compañía de software.
De hecho, tomamos la educación de los desarrolladores muy en serio, y daríamos tantos equipos de desarrolladores como sea posible, capacitación básica en desarrollo seguro. Pensar en la seguridad realmente requiere un cambio en el pensamiento del desarrollo normal, por lo que tratamos de hacer que los desarrolladores piensen en un estado mental de cómo romper cosas. Uno de los puntales que usamos era una de esas cajas fuertes para el hogar con el teclado digital. Dejamos que los desarrolladores lo examinen por dentro y por fuera para tratar de encontrar una manera de acceder a él. (La solución fue presionar el mango mientras se daba a la caja fuerte una parte superior afilada, lo que haría que el perno rebotara en su resorte en el solenoide.) Si bien no les daríamos técnicas específicas de sombrero negro, Hablemos sobre los errores de implementación que causan esas vulnerabilidades, especialmente cosas que quizás no hayan encontrado antes, como desbordamientos de enteros o compiladores que optimizan las llamadas a funciones (como memset para borrar las contraseñas). Publicamos un boletín mensual de seguridad interno, que invitaba a los desarrolladores a detectar errores relacionados con la seguridad en pequeñas muestras de código, lo que sin duda mostraba cuánto extrañarían.
También tratamos de seguir el ciclo de vida de desarrollo de seguridad de Microsoft, que implicaría que los desarrolladores hablen sobre la arquitectura de sus productos y descubran los activos y las posibles formas de atacar esos activos.
En cuanto al equipo de seguridad, que en su mayoría eran antiguos desarrolladores, entender las técnicas del sombrero negro fue muy importante para nosotros. Una de las cosas por las que fuimos responsables fue recibir alertas de seguridad de terceros, y saber cuán difícil sería para un sombrero negro explotar alguna debilidad era una parte importante de los procesos de triage e investigación. Y sí, en ocasiones eso me ha obligado a pasar por un depurador para calcular los desplazamientos de memoria de las rutinas vulnerables y aplicar parches a los ejecutables binarios.
El verdadero problema, sin embargo, es que mucho de esto estaba más allá de las capacidades de los desarrolladores. Cualquier compañía de un tamaño razonable va a tener muchos desarrolladores que sean lo suficientemente buenos para escribir código, pero simplemente no tienen la mentalidad de seguridad. Así que mi respuesta a su pregunta es la siguiente: esperar que todos los desarrolladores tengan conocimientos de black-hat sería una carga no deseada y perjudicial, pero alguien en su empresa debería tener ese conocimiento, ya sea un equipo de auditoría y respuesta de seguridad o solo desarrolladores sénior .
Voy a ser un poco herético e irme en una extremidad y decir:
- Realmente necesita hablar con la gente de sysadmin / network que aseguran sus máquinas. Estas personas manejan el concepto de los robos a diario, y siempre están atentos a los posibles exploits que se usarán en su contra. En su mayor parte, ignore el aspecto de "motivación" de cómo piensan los atacantes, ya que los días de "piratería informática para la notoriedad" han desaparecido. Enfoque en cambio en la metodología . Un administrador competente podrá demostrar esto fácilmente.
Cuando escribe un programa, está presentando lo que (con suerte) es una interfaz fluida y sin problemas para $ {whatever-else-accept-your-programs-I / O}. En este caso, puede ser un usuario final, o puede ser otro proceso en otra máquina, pero no importa. SIEMPRE asuma que el "cliente" de su aplicación es potencialmente hostil, sin importar si es una máquina o una persona.
No me creas? Intente escribir una pequeña aplicación que acepte órdenes de venta de los vendedores, y luego tenga una regla de la compañía que necesita aplicar a través de esa aplicación, pero los vendedores constantemente intentan moverse para que puedan ganar más dinero. Solo este pequeño ejercicio demostrará cómo un atacante motivado, en este caso, el usuario final previsto , buscará activamente formas de explotar fallas en la lógica o de jugar con el sistema por otros medios. ¡Y estos son usuarios finales de confianza!
Los juegos en línea multijugador están constantemente en guerra contra los tramposos porque el software del servidor típicamente confía en el cliente; y en todos los casos, el cliente puede ser pirateado, lo que hará que los jugadores jueguen con el sistema. Piense en esto: aquí tenemos personas que simplemente se están divirtiendo, y usarán medidas extremas para obtener ventaja en una actividad que no implica hacer dinero.
Imagínese la motivación de un pastor profesional de bots que gana su dinero para ganarse la vida de esta manera ... escribiendo malware para que puedan usar las máquinas de otras personas como generadores de ingresos, vendiendo sus botnets al mejor postor para inundaciones masivas de spam ... sí , this realmente happen
Independientemente de la motivación, el punto es que su programa puede, y en algún momento lo estará, ser atacado. No es suficiente proteger contra desbordamientos de búfer , destrucción de pila , ejecución de pila (el código como datos se carga en la pila, luego se realiza un retorno para descargar la pila, lo que lleva a la ejecución del código), ejecución de datos , sitio cruzado secuencias de comandos , escalada de privilegios , condiciones de carrera u otros ataques "programáticos", aunque ayuda. Además de tus defensas programáticas "estándar", también necesitarás pensar en términos de confianza, verificación, identidad y credenciales; en otras palabras, lidiar con lo que sea que proporcione tu entrada de programa y lo que sea que consuma la producción de tu programa. Por ejemplo, ¿cómo se puede defender contra el envenenamiento del DNS desde una perspectiva programática? Y a veces, no se pueden evitar las cosas en el código, por ejemplo, lograr que los usuarios finales no entreguen sus contraseñas a los compañeros de trabajo.
Incorpore esos conceptos en una metodología de seguridad, en lugar de una "tecnología". La seguridad es un proceso, no un producto . Cuando empiece a pensar qué está "del otro lado" de su programa y los métodos que puede emplear para mitigar esos problemas, será mucho más claro en cuanto a qué puede salir bien y qué puede ir terriblemente mal.
Yo personalmente no veo la diferencia técnica. Claro que los motivos son diferentes, pero el juego técnico es el mismo. Es como preguntar qué clase de guerra deben conocer los "buenos".
La respuesta es todo, incluso si no lo practican activamente.
nosotros, los sombreros blancos y los sombreros grises, debemos ser buenos para un millón de cosas, esos sombreros negros y patines solo tienen que tener éxito con una cosa
Diseña para el mal "Cuando el bien es tonto, el mal siempre triunfa".
En resumen, si no piensas como un criminal, eso no significa que los criminales no lo harán.