Otro caso de SSH y fuerza bruta

Y seguimos con ataques de fuerza bruta al SSH. En este caso nos lo cuentan en El extraño caso del SSH y el ataque de fuerza bruta donde se cuenta otra batallita de intentos de acceso por SSH, uso de un equipo para lo que no se debe y el tiempo perdido tratando de encontrar el problema.

Fuzzing en Google

Ya hemos hablado de Fuzzing varias veces por aquí. Por eso me gustó ver lo que hacen en Google al respecto. Lo cuentan brevemente en Fuzzing at scale.
No todo el mundo tiene esos recursos, claro.

Otras veces que hemos hablado del tema:
Fuzzing en teléfonos móviles
Fuzzing, ciclos vacíos y fallos
JBroFuzz para hacer fuzzing
Fuzzing y cubrimiento de código.

Fuzzing en teléfonos móviles

Ya habíamos hablado antes de fuzzing, por ejemplo en Fuzzing, ciclos vacíos y fallos.

En [PDF] Fuzzing the Phone in your Phone podemos leer un artículo sobre el tema aplicado a teléfonos móviles (iPhone, Android y Windows Mobile): se generan SMS ‘confusos’ (fuzzed SMS messages) y se consigue lo esperable, que fallen cosas como por ejemplo, desconectar el teléfono de la red.

También hablamos en su día de ataques con SMSs a teléfonos concretos (y no en experimentos controlados, sino en el ‘mundo real’) en Nuevos ataques con SMSs.

Las pruebas y los programas

En Testing is not a substitute for thinking (binary search part 3) una entrada interesante: con las metodologías ligeras tan de moda en estos tiempos, a veces pensamos que basta con las pruebas (‘tests’) para estar seguros de que todo va bien. No diremos que las pruebas no son útiles ni necesarias, pero en algunos casos (casi siempre) hace falta algo más y el autor da estas razones:

  1. Las pruebas sólo pueden mostrar la presencia de fallos, no su ausencia
  2. Las pruebas pueden tener errores, igual que el código que se quiere probar
  3. Las pruebas aumentan la confianza, no la comprensión

Yo añadiría una cuarta (¿relacionada con la segunda y la primera?) y es que es bastante posible que a la hora de preparar las pruebas nos dejemos algo porque es difícil que seamos capaces de prever todos los casos de uso.

Ya lo comentábamos en Una base axiomática para el desarrollo de programas la teoría y la práctica han de ir de la mano (y muy cerquita de la experiencia).

Y, en la medida de lo posible, utilizar más herramientas: Fuzzing y cubrimiento de código.

Fuzzing, ciclos vacíos y fallos

En Microsoft runs fuzzing botnet, finds 1,800 Office bugs nos cuentan como Microsoft utliza los ordenadores que no están haciendo nada (‘idle cycles’) para hacer ‘Fuzzing’ y encontrar fallos en Office.

“We found and fixed about 1,800 bugs in Office 2010’s code,” said Gallagher, who last week co-hosted a presentation on Microsoft’s fuzzing efforts at the CanSecWest security conference in Vancouver, British Columbia. “While a large number, it’s important to note that that doesn’t mean we found 1,800 security issues. We also want to fix things that are not security concerns.”

Muy interesante la idea de utilizar la potencia de cálculo disponible para
probar estas cosas.

Visto en Microsoft Fuzzing Botnet Finds 1,800 Office Bugs.

Ya hablamos de Fuzzing el otro día en JBroFuzz para hacer fuzzing (y allí hay más enlaces). Creo que también de la idea de que las empresas empleen sus ciclos vacíos para cálculos que lo necesiten y también en la idea de la computación distribuida en general, por ejemplo en Una darknet en el navegador.

Dos tendencias que parece que están ganando terreno.

Fuzzing y cubrimiento de código

Ya habíamos hablado del Cubrimiento de código (‘code coverage’): cuando nuestro código no ejecuta todas las ramas posibles es que algo no es correcto (sobre todo en las fases de pruebas).
También habíamos hablado de ‘fuzzing’ (enviar basura a las interfaces de entrada para comprobar como se comporta nuestro programa) en Hay que probar.

En Using code coverage to improve fuzzing results nos proponen mezclar ambas para mejorar las pruebas que se hacen del código de un proyecto.

Hay que probar

En Secure Software Needs Careful Testing–And Lots Of It hay una ‘defensa’ del ‘fuzzing’ (probar las aplicaciones mandando ‘basura’ a las divesas interfaces de entrada para detectar posibles problemas y fallos).

Ya habíamos hablado en vidas anteriores del ‘fuzzing’ (¿alguna traducción por ahí?): Fuzz testing, MacOS, fuzzing y malos resultados y Fuzzing y JavaScript.