¿El peor agujero de seguridad que has visto? [cerrado]

¿Cuál es el peor agujero de seguridad que has visto? Probablemente sea una buena idea mantener los detalles limitados para proteger al culpable.

Para lo que vale, aquí hay una pregunta sobre qué hacer si encuentra un agujero de seguridad, y otra con algunas respuestas útiles si una empresa no (parece) responder.

Desde los primeros días de las tiendas en línea:

Obtener un 90% de descuento ingresando .1 en el campo de cantidad del carrito de compras. El software calculó correctamente el costo total como .1 * costo, y el humano que empacó el pedido simplemente pasó por alto el extraño "." delante de la cantidad a empacar :)

El agujero de seguridad menos perdonable, y desafortunadamente uno muy común y fácil de encontrar, es el pirateo de Google . Caso en punto:

http://www.google.com/search?q=inurl%3Aselect+inurl%3A%2520+inurl%3Afrom+inurl%3Awhere

Es sorprendente cuántas páginas en Internet, en particular los sitios gubernamentales, pasan una consulta SQL a través de la cadena de consulta. Es la peor forma de inyección SQL, y no requiere ningún esfuerzo encontrar sitios vulnerables.

Con pequeños ajustes, he podido encontrar instalaciones desprotegidas de phpMyAdmin, instalaciones desprotegidas de MySQL, cadenas de consulta que contienen nombres de usuario y contraseñas, etc.

Ingeniería social:

<Cthon98> hey, if you type in your pw, it will show as stars
<Cthon98> ********* see!
<AzureDiamond> hunter2
<AzureDiamond> doesnt look like stars to me
<Cthon98> <AzureDiamond> *******
<Cthon98> thats what I see
<AzureDiamond> oh, really?
<Cthon98> Absolutely
<AzureDiamond> you can go hunter2 my hunter2-ing hunter2
<AzureDiamond> haha, does that look funny to you?
<Cthon98> lol, yes. See, when YOU type hunter2, it shows to us as *******
<AzureDiamond> thats neat, I didnt know IRC did that
<Cthon98> yep, no matter how many times you type hunter2, it will show to us as *******
<AzureDiamond> awesome!
<AzureDiamond> wait, how do you know my pw?
<Cthon98> er, I just copy pasted YOUR ******'s and it appears to YOU as hunter2 cause its your pw
<AzureDiamond> oh, ok.

De bash.org

La verdadera historia de mis primeros días en Microsoft.

No has conocido el miedo hasta el día en que te levantas y ves el titular en ZDNet.com esa mañana: "El peor agujero de seguridad de Internet Explorer que se haya descubierto en 'Blah' ", donde "Blah" es el código que escribiste seis meses antes .

Inmediatamente después de llegar al trabajo, verifiqué los registros de cambios y descubrí que alguien en otro equipo, alguien en quien confiamos para hacer cambios en el producto, había revisado mi código, había cambiado un montón de configuraciones clave de registro de seguridad sin ninguna buena razón, lo comprobé de nuevo y nunca recibí una revisión de código ni se lo conté a nadie. Hasta el día de hoy no tengo idea de qué demonios pensó que estaba haciendo; dejó la compañía poco después. (Por su propia voluntad.)

(ACTUALIZACIÓN: Algunas respuestas a los problemas planteados en los comentarios:

Primero, tenga en cuenta que elijo tomar la posición caritativa de que los cambios en la clave de seguridad no fueron intencionales y se basaron en el descuido o la falta de familiaridad, en lugar de la malicia. No tengo evidencia de una manera u otra, y creo que es sabio atribuir los errores a la falibilidad humana.

Segundo, nuestros sistemas de registro son mucho, mucho más fuertes ahora que hace doce años. Por ejemplo, ahora no es posible registrar el código sin que el sistema de registro envíe por correo electrónico la lista de cambios a las partes interesadas. En particular, los cambios realizados al final del ciclo de envío tienen muchos "procesos" a su alrededor, lo que garantiza que se realicen los cambios correctos para garantizar la estabilidad y seguridad del producto).

De todos modos, el error fue que un objeto que NO era seguro para ser utilizado desde Internet Explorer había sido liberado accidentalmente como marcado como "seguro para secuencias de comandos". El objeto era capaz de escribir archivos binarios (bibliotecas de tipo de automatización OLE, de hecho) en ubicaciones de disco arbitrarias. Esto significaba que un atacante podía crear una biblioteca de tipos que contuviera ciertas cadenas de código hostil, guardarla en una ruta que fuera una ubicación ejecutable conocida, darle la extensión de algo que haría que se ejecutara un script y esperar que de alguna manera el usuario correría accidentalmente el código. No conozco ningún ataque exitoso del "mundo real" que haya utilizado esta vulnerabilidad, pero fue posible crear un exploit de trabajo con él.

Enviamos un parche bastante rápido para eso, déjame decirte.

Causé y posteriormente arreglé muchos más agujeros de seguridad en JScript, pero ninguno de ellos llegó a estar cerca de la publicidad que uno hizo.

Espero que puedas ver lo que está mal aquí. (Terriblemente mal, de hecho):

String emailBody = "";

for (int i = 0; i < subscribers.Count; i++)
{
    emailBody += "Hello " + subscribers[i].FirstName + ",";
    emailBody += "this is a reminder with your account information: \n\n:";
    emailBody += "Your username: " + subscribers[i].Username + "\n";
    emailBody += "Your password: " + subscribers[i].Password + "\n";
    emailBody += "Have a great day!";

    emailDispatcher.Send(subscribers[i].EmailAddress, emailBody);
}

El último destinatario fue el más feliz;)

Los viejos terminales tontos de IBM System 36 tenían una combinación de teclado que iniciaba la grabación de una macro. Entonces, cuando un terminal no estaba conectado, puede comenzar la grabación de una macro y dejarla en esa posición. La próxima vez que alguien inicie sesión, las pulsaciones de teclas se grabarán en la macro y la grabación finalizará automáticamente cuando se hayan registrado las teclas máximas permitidas. Simplemente regrese más tarde y reproduzca la macro para iniciar sesión automáticamente.

El peor agujero de seguridad que he visto fue realmente codificado por los suyos y causó que el Google Bot elimine toda mi base de datos.

Cuando estaba aprendiendo ASP clásico, codifiqué mi propia aplicación básica de blog. El directorio con todos los scripts de administración estaba protegido por NTLM en IIS. Un día me mudé a un nuevo servidor y olvidé volver a proteger el directorio en IIS (¡Vaya!).

La página de inicio del blog tenía un enlace a la pantalla principal de administración, y la pantalla principal de administración tenía un BORRAR ENLACE para cada registro (sin confirmación).

Un día encontré todos los registros de la base de datos eliminados (cientos de entradas personales). Pensé que algún lector había entrado en el sitio y borró maliciosamente todos los registros.

Llegué a averiguarlo a través de los registros: el Google Bot había rastreado el sitio, siguió el enlace de administración y procedió a seguir todos los BORRAR ENLACES, eliminando así todos los registros de la base de datos. Sentí que merecía el premio Dumbass of the Year al ser inadvertidamente comprometido por el Google Bot.

Afortunadamente tenía copias de seguridad.

El peor agujero que he visto fue un error en una aplicación web en la que si ingresas un nombre de usuario y una contraseña vacíos, iniciarás sesión como administrador :)

Una vez notado esto en la URL de un sitio web.

http://www.somewebsite.com/mypage.asp?param1=x&param2=y&admin=0

Cambiar el último parámetro a admin = 1 me dio privilegios de administrador. Si vas a confiar ciegamente en la entrada del usuario, ¡al menos no telegrafíes que lo estás haciendo!

Vi este en The Daily WTF .

<script language="javascript">
<!--//
/*This Script allows people to enter by using a form that asks for a
UserID and Password*/
function pasuser(form) {
    if (form.id.value=="buyers") { 
        if (form.pass.value=="gov1996") {              
            location="http://officers.federalsuppliers.com/agents.html" 
        } else {
            alert("Invalid Password")
        }
    } else {  
        alert("Invalid UserID")
    }
}
//-->
</script>

Nada puede vencer a mi en mi humilde opinión.

En una universidad no menos, que permanecerá sin nombre, todas sus consultas de acción se pasaron a través de la URL en lugar del formulario publicado.

La cosa funcionó de maravilla hasta que apareció Google Bot y revisó todas sus URL y borró su base de datos.

Sorprendido, nadie ha mencionado la ingeniería social, pero me gustó este artículo .

Resumen: los usuarios malintencionados pueden comprar unas pocas docenas de unidades flash, cargarlas con un virus o troyano de ejecución automática, y luego espolvorear dichas unidades flash en el estacionamiento de una empresa a altas horas de la noche. Al día siguiente, todos se presentan a trabajar, tropiezan con el hardware irresistible brillante y con forma de caramelo y se dicen a sí mismos "oh wow, unidad flash gratuita, ¡me pregunto qué hay en ella!" - 20 minutos después, toda la red de la compañía está conectada.

"Pedo mellon a minno" , "Habla amigo y entra", a las puertas de Moria.

Microsoft Bob
(Crédito: Dan's 20th Century Abandonware )

Si ingresa su contraseña incorrectamente por tercera vez, se le preguntará si la ha olvidado.

http://img132.yfrog.com/img132/8397/msbob10asignin15.gif

Pero en lugar de tener seguridad, como continuar solicitando la contraseña correcta hasta que se ingrese o bloquearlo después de varios intentos incorrectos, ¡puede ingresar cualquier contraseña nueva y reemplazará la original! Cualquiera puede hacer esto con cualquier cuenta de Microsoft Bob "protegida" con contraseña.

No se requiere autenticación previa. esto significa que el Usuario1 podría cambiar su propia contraseña simplemente escribiendo su contraseña tres veces y luego ingresando una nueva contraseña la cuarta vez, sin tener que usar "cambiar contraseña".

También significa que Usuario1 podría cambiar las contraseñas de Usuario2, Usuario3 ... exactamente de la misma manera. Cualquier usuario puede cambiar la contraseña de cualquier otro usuario simplemente escribiéndola tres veces y luego ingresando una nueva contraseña cuando se le solicite, y luego podrá acceder a la cuenta.

http://img132.yfrog.com/img132/9851/msbob10asignin16.gif

Tenía la antigua dirección de Joe X y necesitaba saber su nueva dirección actual en la misma ciudad, pero no tenía forma de contactarlo. Supuse que estaba recibiendo el habitual montón diario de catálogos de pedidos por correo, así que llamé arbitrariamente al número 800 de See's Candies (en oposición a Victoria's Secret, o Swiss Colony, o cualquier otro gran correo):

Yo: "Hola, soy Joe X. Creo que me tienes en tu lista de correo dos veces, tanto en mi dirección anterior como en mi nueva dirección. ¿Me muestra tu computadora en [dirección anterior] o en [dirección falsa] ? "

Operador: "No, te mostramos en [nueva dirección]".

Dar 1 = 1 en un cuadro de texto enumera todos los usuarios del sistema.

Al ser un consultor de seguridad de aplicaciones para ganarse la vida, hay muchos problemas comunes que le permiten obtener administrador en un sitio web a través de algo. Pero la parte realmente genial es cuando puedes comprar medias por valor de un millón de dólares.

Era un amigo mío que trabajaba en este concierto, pero lo primero era que los precios de los artículos en una tienda de libros en línea ahora muy popular (y todo lo demás) se almacenaban en el propio HTML como un campo oculto. En los primeros días, este error mordió muchas tiendas en línea, apenas comenzaban a descubrir la web. Muy poca conciencia de seguridad, quiero decir, ¿quién va a descargar el HTML, editar el campo oculto y volver a enviar el pedido?

Naturalmente, cambiamos el precio a 0 y pedimos 1 millón de pares de calcetines. También puede cambiar el precio a negativo, pero al hacer esto, parte del desbordamiento del búfer del software de facturación de fondo finalizó la transacción.

Si pudiera elegir otro, serían problemas de canonicalización de ruta en aplicaciones web. Es maravilloso poder hacer foo.com?file=../../../../etc/passwd

Confirmar la contraseña raíz de la base de datos al control de origen por accidente. Fue bastante malo, porque era el control de fuente en Sourceforge.

No hace falta decir que la contraseña se cambió muy rápidamente.

No cambiar las contraseñas de administrador cuando los empleados clave de TI dejan la empresa

Aunque este no es el peor agujero de seguridad que he visto. Pero esto es al menos lo peor que he descubierto:

Una tienda en línea bastante exitosa para audiolibros utilizó una cookie para almacenar la información de identificación del usuario actual después de una autenticación exitosa. Pero podría cambiar fácilmente la ID de usuario en la cookie y acceder a otras cuentas y comprarlas.

Justo al comienzo de la era .com, estaba trabajando para un gran minorista en el extranjero. Observamos con gran interés cómo nuestros competidores lanzaron una tienda en línea meses antes que nosotros. Por supuesto, fuimos a probarlo ... y rápidamente nos dimos cuenta de que nuestros carritos de compras se estaban mezclando. Después de jugar un poco con la cadena de consulta, nos dimos cuenta de que podíamos secuestrar las sesiones de los demás. Con un buen momento, puede cambiar la dirección de entrega pero dejar solo el método de pago ... todo eso después de haber llenado el carrito con sus artículos favoritos.

Cuando me uní por primera vez a la compañía en la que trabajo actualmente, mi jefe estaba revisando el sitio web de comercio electrónico existente de un posible nuevo cliente. Esto fue en los primeros días de IIS y comercio electrónico, y la seguridad fue, digamos, menos estricta.

Para abreviar una larga historia, alteró una URL (solo por curiosidad), y se dio cuenta de que la exploración del directorio no estaba desactivada, por lo que podría cortar el nombre de la página al final de la URL y ver todos los archivos en el Servidor web.

Terminamos navegando por una carpeta que contenía una base de datos de Access, que descargamos. Era toda la base de datos de clientes / pedidos de comercio electrónico, repleta de varios miles de números de tarjetas de crédito sin cifrar.

Personas que publican sus contraseñas en sitios web públicos ...

Cuando tenía 13 años, mi escuela abrió una red social para los estudiantes. Desafortunadamente para ellos, encontré un error de seguridad en el que podía cambiar el URI a otro ID de usuario como "? UserID = 123" e iniciar sesión para ese usuario. Obviamente se lo dije a mis amigos, y al final la red social de las escuelas se llenó de porno.

Sin embargo, no lo recomendaría.

Creo que el campo de nombre de usuario / contraseña en blanco para acceso de superusuario es, con mucho, el peor. Pero uno que me he visto fue

if (password.equals(requestpassword) || username.equals(requestusername))
{
    login = true;
}

Lástima que un operador haga una gran diferencia.

El mío sería para un banco del que era cliente. No pude iniciar sesión, así que llamé al servicio al cliente. Me pidieron mi nombre de usuario y nada más; no hicieron preguntas de seguridad ni intentaron verificar mi identidad. Luego, en lugar de enviar un restablecimiento de contraseña a la dirección de correo electrónico que tenían en el archivo, me preguntaron a qué dirección de correo electrónico enviarlo. Les di una dirección diferente a la que tenía en el archivo y pude restablecer mi contraseña.

Esencialmente, todo lo que un hacker necesitaría es mi nombre de usuario, y luego podría acceder a mi cuenta. Esto fue para un banco importante del que al menos el 90% de las personas en los Estados Unidos habrían oído hablar. Esto sucedió hace unos dos años. No sé si fue un representante de servicio al cliente mal capacitado o si ese fue el procedimiento estándar.

Compartiré uno que creé. Mas o menos.

Hace años y años y años, la compañía para la que estaba trabajando quería indexar en su sitio web ASP. Así que fui y configuré Index Server, excluí algunos directorios de administración y todo estuvo bien.

Sin embargo, desconocido para mí, alguien le había dado a un vendedor un acceso ftp al servidor web para que pudiera trabajar desde casa, estos eran los días de acceso telefónico y era la forma más fácil para que intercambiara archivos ... y comenzó a cargar cosas, incluidos documentos que detallan el marcado en nuestros servicios ... que indexó el servidor y comenzó a servir cuando la gente buscaba "Costos".

Recuerde niños, listas blancas, no listas negras.

Uno de los más simples, pero realmente rentables es:

Los sistemas de pago que usan motores como PayPal pueden ser defectuosos porque la respuesta de PayPal después de que el pago fue exitoso no se verifica como debería ser.

Por ejemplo:

Puedo ir a un sitio web de compra de CD y agregar algo de contenido al carrito, luego, durante las etapas de pago, generalmente hay un formulario en la página que se ha rellenado con campos para PayPal, y un botón de envío para "Pagar".

Usando un editor DOM puedo ir al formulario "en vivo" y cambiar el valor de £899.00a £0.01y luego hacer clic en enviar ...

Cuando estoy del lado de PayPal, puedo ver que la cantidad es de 1 centavo, así que pago eso y PayPal redirige algunos parámetros al sitio de compra inicial, que solo valida parámetros como payment_status=1, etc., etc. y no validar la cantidad pagada.

Esto puede ser costoso si no cuentan con un registro suficiente o si los productos se envían automáticamente.

El peor tipo de sitios son los sitios que ofrecen aplicaciones, software, música, etc.

¿Qué tal un administrador de documentos en línea, que permite configurar todos los permisos de seguridad que pueda recordar ...

Eso es hasta que llegaste a la página de descarga ... download.aspx? DocumentId = 12345

Sí, el ID de documento era el ID de la base de datos (incremento automático) y usted podía recorrer cada número y cualquiera podía obtener todos los documentos de la compañía.

Cuando se le alertó sobre este problema, la respuesta del gerente del proyecto fue: Ok, gracias. Pero nadie ha notado esto antes, así que vamos a mantenerlo como está.

Una entrega de pizza noruega tenía un agujero de seguridad donde podía pedir cantidades negativas de pizzas en su nuevo y brillante portal de Internet y obtenerlas gratis.