Mostrando las entradas con la etiqueta seguridad de la informacion. Mostrar todas las entradas
Mostrando las entradas con la etiqueta seguridad de la informacion. Mostrar todas las entradas

jueves, 9 de agosto de 2012

Web VRA: Google skipfish

Skipfish is an active web application security reconnaissance tool from Google. It prepares an interactive sitemap for the targeted site by carrying out a recursive crawl and dictionary-based probes. The resulting map is then annotated with the output from a number of active (but hopefully non-disruptive) security checks. The final report generated by the tool is meant to serve as a foundation for professional web application security assessments.
Key features:
  • High speed: pure C code, highly optimized HTTP handling, minimal CPU footprint - easily achieving 2000 requests per second with responsive targets.
  • Ease of use: heuristics to support a variety of quirky web frameworks and mixed-technology sites, with automatic learning capabilities, on-the-fly wordlist creation, and form autocompletion.
  • Cutting-edge security logic: high quality, low false positive, differential security checks, capable of spotting a range of subtle flaws, including blind injection vectors.
The tool is believed to support Linux, FreeBSD, MacOS X, and Windows (Cygwin) environments.

Home Page:
http://code.google.com/p/skipfish/

Wiki Doc:
http://code.google.com/p/skipfish/wiki/SkipfishDoc

jueves, 19 de julio de 2012

Delegar permisos sobre Security logs

En los entornos corporativos y sobre todo para los ambientes Windows es muy comun encontrar que las áreas de Auditoría cuyos usuarios no son privilegiados deseen visualizar logs de Seguridad. En Windows Server 2003 esto es una tarea algo compleja y riesgosa para lo que nos tiene acostumbrados Microsoft y deberemos utilizar el lenguaje SDDL:

CUIDADO: Este procedimiento mal implementado puede impedir el acceso y requiere de reinicio del equipo.

Delegating access to the event logs

In Windows Server® 2003, Windows Vista, and Windows Server® 2008, it is possible to customize the permissions on each event log on a computer. This capability was not available in previous versions of Windows. Some organizations may want to grant read-only access to one or more of the System event logs to some members of the IT team, such as auditors. The access control list (ACL) is stored as a Security Descriptor Definition Language (SDDL) string, in a REG_SZ value called "CustomSD" for each event log in the registry. The following procedure shows how to delegate read-only access for an event log. You will need to repeat this procedure for each event log that you wish to delegate read-only access to by changing the registry key as needed.
CautionCaution
Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
To delegate access to an event log using the registry
  1. Open Registry Editor.
  2. Navigate to the following registry path:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog
    You will see that there are keys available for each event log. Select the event log for which you want to delegate read-only access.
  3. Add a new key with the name CustomSD to the event log you selected.
  4. Add a new String value to the CustomSD key. The name of this string is not required, but it represents the access control list for the event log in the Security Descriptor Definition Language (SDDL) syntax. In this procedure this value will be referred to as SDDLACL.
  5. Set the value of the SDDLACL to the following:
    O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG) (A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x5;;;SO)(A;;0x1;;;IU)(A;;0x1;;;SU) (A;;0x1;;;S-1-5-3)(A;;0x2;;;LS)(A;;0x2;;;NS)
Once you edit this value and restart the computer, the new setting will take effect. Be certain that you fully understand SDDL and the default permissions that are placed on each event log before you use this procedure. Also, be certain to test any changes thoroughly before you implement them in a production environment, because you could accidentally configure the ACLs on an event log in such a way that no one could access it.

Additional references

The following links provide additional information about event logging in Windows Server 2003 and Windows Vista:



Extraido de: http://technet.microsoft.com/en-us/library/cc722385(WS.10).aspx

Mas info: http://support.microsoft.com/default.aspx?scid=kb;en-us;323076

miércoles, 5 de octubre de 2011

Windows: Password required vulnerability

Hay ciertas cuentas que genera Windows en forma predeterminada que no requieren password y son una vulnerabilidad, ya que es posible utilizarlas sin ingresar su password.

Para conocer si una cuenta requiere password o no, debemos ejecutar el siguiente comando:

>net user IUSR_testServer
User name                    IUSR_testServer
Full Name
Comment                      Built-in account for IIS
User's comment
Country code                 000 (System Default)
Account active               Yes
Account expires              Never
Password last set            03/06/2011 11:12:42 p.m.
Password expires             Never
Password changeable          03/06/2011 11:12:42 p.m.
Password required            No
User may change password     Yes
Workstations allowed         All
Logon script
User profile
Home directory
Last logon                   03/06/2011 11:12:42 p.m.
Logon hours allowed          All
Local Group Memberships      *Users
Global Group memberships     *None
The command completed successfully.

Una vez que detectamos estas cuentas debemos analizar si la aplicacion que la usa (En nuestro caso el IIS) puede reconfigurarse y setearle el password para que sea utilizado.

Una vez realizado este analisis es necesario forzar que requiera password con el siguiente comando:




net user /passwordreq:yes NombreUsusario


Una vez realizado esto, es recomendable reiniciar el servicio que utilice este usuario para comprobar que todo siga funcionando sin problemas.

Tambien será necesario controlar que el IIS tenga el password correcto ingresado en los sites que utilicen dicha cuenta. Si fuera otra aplicación verificar que la aplicación tenga el password correctamente ingresado.



lunes, 9 de mayo de 2011

Wireless sniffing: firesheep

firesheep no es una herramienta nueva, más bien tiene ya unos cuantos años de desarrollada, pero hay mucha gente que aún no la conoce, y me parece que es muy útil a la hora de concientizar sobre las precauciones que hay que tener en cuenta a la hora de utilizar wireless o redes en general. No es algo para volverse paranóico pero si para tener en mente mientras usamos internet.

firesheep permite "sniffear" (algo asi como escuchar) el tráfico que pasa por un adaptador inalámbrico de la pc. Al escuchar este tráfico automáticamente caputar las sesiones de las aplicaciones web y nos permite utilizarlas a nosotros que no somos los dueños de las mismas.

Lo que tiene de "bueno" firesheep es que de una manera sumamente simple nos permite ganar sesiones, sin demasiadas complicaciones.

viernes, 22 de abril de 2011

Los 20 mejores puestos en Seguridad de la información

SANS ha recopilado los 20 puestos más interesantes del mercado de la seguridad de la información. Para la mayoría de ellos propone una serie de cursos y certificaciones. Las certificaciones SANS son muy valoradas en la industria.

Acá les dejo el listado:
  • #1 Information Security Crime Investigator/Forensics Expert
  • #2 System, Network, and/or Web Penetration Tester
  • #3 Forensic Analyst
  • #4 Incident Responder
  • #5 Security Architect
  • #6 Malware Analyst
  • #7 Network Security Engineer
  • #8 Security Analyst
  • #9 Computer Crime Investigator
  • #10 CISO/ISO or Director of Security
  • #11 Application Penetration Tester
  • #12 Security Operations Center Analyst
  • #13 Prosecutor Specializing in Information Security Crime
  • #14 Technical Director and Deputy CISO
  • #15 Intrusion Analyst
  • #16 Vulnerability Researcher/ Exploit Developer
  • #17 Security Auditor
  • #18 Security-savvy Software Developer
  • #19 Security Maven in an Application Developer Organization
  • #20 Disaster Recovery/Business Continuity Analyst/Manager

Fuente: http://www.sans.org/20coolestcareers/

domingo, 3 de abril de 2011

Camaras de Seguridad Online

En este post comentaré algunas cuestiones de seguridad que he estado relevando en cámaras online. Es muy común ver sitios de cámaras que no están correctamente "hardenizados" y que son suceptibles de ataques o de accesos no autorizados.

Para evitar problemas de seguridad en cámaras online propias, debemos:


-Editar las página por defecto que tienen los sistemas de cámaras (sobre todo los títulos de las paginas) ya que mediante los buscadores es muy sencillo detectar cámaras con vulnerabilidades conocidas.
-Asegurarnos de que el acceso en caso de estar restringido tenga password fuertes y cambiarlos periódicamente.
-Revisar periódicamente los logs de acceso para ver desde que IPs se han conectado a nuestro sistema.
-En caso de ser posible, monitorear la disponibilidad del sistema en forma permanente.

Ahora bien uno podría preguntarse.... ¿que vulnerabilidades puede tener una cámara web?, ¿que cosas se pueden hacer si se aprovechan los bugs presentes?... por ejemplo:

-Modificar el firmware de la cámara y hacer que ejecute algún otro software.
-Tomar control del domo y hacer que apunte a un lugar donde no es útil. Esto es principalmente grave en cámaras de Seguridad. Algún delincuente podría aprovechar esta situación.
-Desactivar la grabación del video.
-Apagar el video por completo.
-Crear nuevos usuarios, alterar o restringir el acceso.
-Generar una imagen falsa en la cámara. (tal como se ve en las películas)

Si bien existen varias vulnerabilidades conocidas, no voy a reproducirlas para no facilitarle las cosas a nadie pero en caso de que este tema les sea de interés podrán encontrar muchos sitios con vulnerabilidades y con la ayuda de los buscadores podrán encontrar muchos sitios donde "testear" esas vulnerabilidades, claro esta que solo podrán "testearlas" con la aprobación del dueño del sistema...


sábado, 2 de abril de 2011

Internet: Navegacion Segura para toda la familia

En este post, quiero comentar un sistema que he estado testeando por un tiempo y que me ha dado muy buenos resultados para navegar en forma segura y veloz por Internet.

Este sistema es altamente recomendable para familias con chicos y adolescentes que acceden a Internet desde el hogar. También puede ser utilizado en empresas, colegios, universidades, bares o cualquier otro punto de acceso a Internet ya sea publico o privado.

La solución se llama OpenDNS y permite restringir el acceso a paginas inseguras o de contenido sexual. Posee una versión gratuita para usuarios finales y una versión paga con mayores prestaciones. OpenDNS permite definir una página de error que se mostrará cuando un sitio sea bloqueado e informará porque fue bloqueado.

También cuenta con la funcionalidad de loguear todo el historial de navegación que se hace desde cualquier equipo de la casa sin importar con que navegador o equipo se haga.

Para los entendidos en tecnología paso a explicar su funcionamiento intrínseco. OpenDNS nos brinda dos DNS (primario y secundario) para que los utilicemos en nuestra configuración IP. Esto permitirá que OpenDNS analice las URLs que queremos acceder y en base a esto determine si son sitios seguros o no.
Si son sitios confiables nos devolverá la dirección IP como cualquier DNS; pero en caso de no serlo nos direccionará a otra página informando que la página en cuestión no es segura o tiene algún tipo de contenido no permitido.

Para poner manos a la obra y comenzar a utilizarlo tenemos varias opciones:

1-Registrarnos en https://www.opendns.com/ (no es obligatorio, pero nos permitirá tener el historial de navegación y realizar ciertas configuraciones)

2a- Configurar manualmente nuestros DNS a utilizar 208.67.222.222 y 208.67.220.220.

2b- Instalar un programita provisto por OpenDNS que nos configura los DNS en forma automática (recomendado para los inexpertos).

3-No hay paso 3!! Solo comenzar a navegar en forma segura


Ahora bien en caso de que contemos con un router que nos provea acceso a Internet es recomendable que configuremos aqui los DNS para que no tengamos que hacerlo en cada equipo. También es mas seguro así ya que es mas difícil para los "usuarios" modificarlo desde allí. OpenDNS posee en su sitio instructivos para configurar esto en los dispositivos mas comunes.

Con respecto a la seguridad que ofrece podemos enumerar la protección de las siguientes amenazas comunes de Internet:

-Phishing (que tiene por fin confundir y robar información)
-Malware (incluye virus, troyanos, adware, etc.)
-Contenido para adultos
-Y otras opciones customizables como sitios de alcohol, subastas, etc.
-Ademas nos permite definir nuestras propias listas blancas y negras.

Por otro lado OpenDNS ofrece mejora en la velocidad de la navegación ya que posee un cache optimizado de consultas DNS, por lo que puede realizar en forma veloz la resolución de nombres de Internet.

Por ultimo en caso de que seamos algo "paranoicos" y no querramos que el "gran hermano" nos este vigilando podemos simplemente utilizar los dns sin registrarnos.

Como conclusión final, considero que al ser una herramienta muy estable y gratuita no hay escusas para que las instituciones y lugares publicos de acceso a Internet comiencen a brindar una experiencia mas segura en internet sobre todo para los chicos y adolescentes.