0-Day - Ataque de día cero

o-day java-exploit

Un 0-Day no es más que la ejecución de código malicioso en una aplicación o un sistema, completamente actualizado, aprovechando alguna falla o vulnerabilidad que esta posea, y como el fabricante no tiene conocimiento de aquello no puede proceder a publicar un parche de seguridad que solucione este gran problema, es por ello que un 0-Day constituye un una forma de ataque tan peligrosa porque no existe método para detenerlo.


Un Peligro Latente
Cuando una persona descubre un fallo de seguridad, la cual obviamente no esta publicada, esta debería notificar a la empresa o a quien corresponda para que solucione el error, a esto llamamos Ethical Hacking, actuar de manera profesional y no mal intencionada. Posterior a eso dicha empresa deberá corregir el código y distribuir un parche de seguridad. Esta seria la manera correcta de actuar ante tal circunstancia. Sin embargo no todo es color de rosas, y gente con mucho talento y oscuras intenciones suelen descubrir 0-Day en aplicaciones o sistemas que utilizaran para su propio beneficio, ya sea para explotar el código para robar información o venderlo en el mercado negro por mucho mucho dinero. Y como el 0-Day no esta en conocimiento no existe defensa alguna, tanto para el usuario como para el experto en seguridad, les comento la siguiente anécdota:


En 2013, Alejandro Hernandez, dando una charla en la Campus Party de Colombia, relataba que tras hacer una auditoria a un importante banco y no encontrar mayores problemas en la seguridad de sus sistemas, una semana después de aquello "defacean" el portal de dicho banco. Con el tiempo logro dar que un Team de Hacker Brasileros habían empleado un xploit para un fallo que no había sido publicado.

Angry Birds utilizados para robar Bitcoins

angrybirds-y-bitcoins-800px


Investigadores de ESET nos alertan de un tipo de malware para Mac que roba Bitcoins (moneda electrónica) a través de aplicaciones modificadas para propagar el código malicioso. En concreto se trata del troyano OSX/CoinThief que infecta ordenadores que usan Mac OS X, instalando complementos maliciosos en el navegador para robar las credenciales de sitios dedicados al intercambio de bitcoins.

Los expertos han desvelado que CoinThief se está propagando mediante redes de intercambio de archivos P2P, escondido dentro de versiones crackeadas de aplicaciones muy famosas para Mac OS X, tales como:




  • El editor de texto para Mac: BBEdit

  • El editor de gráficos: Pixelmator

  • El popular juego Angry Birds

  • El catálogo multimedia Delicious Library


Los delincuentes que están detrás de CoinThief quieren sacar partido de la locura que se está viviendo con los bitcoines y la fluctuación en su cotización, irrumpiendo en los monederos digitales de los usuarios“, afirma el investigador de seguridad Graham Cluley, que ha escrito sobre esta amenaza en el blog de ESET “We Live Security“. “Tal y como ha demostrado el equipo de investigación de ESET, los usuarios de Mac que han descargado e instalado aplicaciones piratas desde sitios torrent, no sólo están privando a los desarrolladores de sus legítimos ingresos, sino que están arriesgando sus ordenadores y su economía“, explica.


Según las estadísticas de detección ofrecidas por ESET LiveGrid, esta amenaza está afectando fundamentalmente a usuarios de Mac en Estados Unidos. CoinThief fue detectado a primeros de mes por los investigadores de SecureMac, que descubrieron que se había distribuido a través de sitios famosos de descargas, como Download.com y MacUpdate.com, escondidos en versiones troyanizadas de Bitcoin Ticker TTM (To The Moon), BitVanity, StealthBit y Litecoin Ticker.


Consejos


Desde aquí, más allá de que seas usuario de Bitcoin o no, aconsejamos a los usuarios de Mac que protejan sus equipos con un antivirus actualizado y que resistan la tentación de descargar software pirateado. Lo recomendable es dirigirse a una fuente legítima como el sitio web de cada desarrollador o el App Store para Mac.


Si desafortunadamente eres uno de los usuarios infectados por el OSX/CoinThief, aquí tienes algunas instrucciones de limpieza que te pueden resultar útiles.


 Adaptación del post de Graham Cluley para We Live Security. Post tomado de: http://blogs.protegerse.com/laboratorio/2014/02/27/los-angry-birds-usados-para-propagar-malware-para-mac/

Top 10 de Técnicas para Hacking Web 2013


Año tras año la empresa WhiteHat Security lanza un concurso para encontrar las mejores técnicas de hackeo web, dando a los participantes la oportunidad de publicar sus métodos en, blogs, papers, revistas, listas de correo e incluso presentarse en conferencias a exponer sus técnicas.


La fase de competencia para elegir las mejores técnicas esta dividida en dos fases: la primera es una votación abierta a la comunidad, la cual entrega un sistema de puntuación o ranking a los participantes. De ahí los seleccionados pasan a ser evaluados de la misma manera, solo que ahora por un jurado de expertos en la materia.


Aquí el listado de los top 10

  1. Mario Heiderich – Mutation XSS

  2. Angelo Prado, Neal Harris, Yoel Gluck – BREACH

  3. Pixel Perfect Timing Attacks with HTML5

  4. Lucky 13 Attack

  5. Weaknesses in RC4

  6. Timur Yunusov and Alexey Osipov – XML Out of Band Data Retrieval

  7. Million Browser Botnet Video Briefing
    Slideshare

  8. Large Scale Detection of DOM based XSS

  9. Tor Hidden-Service Passive De-Cloaking

  10. HTML5 Hard Disk Filler™ API


Aquí la lista de los seleccionados del 2013:

  1. Tor Hidden-Service Passive De-Cloaking

  2. Top 3 Proxy Issues That No One Ever Told You

  3. Gravatar Email Enumeration in JavaScript

  4. Pixel Perfect Timing Attacks with HTML5

  5. Million Browser Botnet Video Briefing
    Slideshare

  6. Auto-Complete Hack by Hiding Filled in Input Fields with CSS

  7. Site Plagiarizes Blog Posts, Then Files DMCA Takedown on Originals

  8. The Case of the Unconventional CSRF Attack in Firefox

  9. Ruby on Rails Session Termination Design Flaw

  10. HTML5 Hard Disk Filler™ API

  11. Aaron Patterson – Serialized YAML Remote Code Execution

  12. Fireeye – Arbitrary reading and writing of the JVM process

  13. Timothy Morgan – What You Didn’t Know About XML External Entity Attacks

  14. Angelo Prado, Neal Harris, Yoel Gluck – BREACH

  15. James Bennett – Django DOS

  16. Phil Purviance – Don’t Use Linksys Routers

  17. Mario Heiderich – Mutation XSS

  18. Timur Yunusov and Alexey Osipov – XML Out of Band Data Retrieval

  19. Carlos Munoz – Bypassing Internet Explorer’s Anti-XSS Filter

  20. Zach Cutlip – Remote Code Execution in Netgear routers

  21. Cody Collier – Exposing Verizon Wireless SMS History

  22. Compromising an unreachable Solr Serve

  23. Finding Weak Rails Security Tokens

  24. Ashar Javad Attack against Facebook’s password reset process.

  25. Father/Daughter Team Finds Valuable Facebook Bug

  26. Hacker scans the internet

  27. Eradicating DNS Rebinding with the Extended Same-Origin Policy

  28. Large Scale Detection of DOM based XSS

  29. Struts 2 OGNL Double Evaluation RCE

  30. Lucky 13 Attack

  31. Weaknesses in RC4


Y aquí los 15 seleccionados:

  1. Million Browser Botnet Video Briefing
    Slideshare

  2. Timur Yunusov and Alexey Osipov – XML Out of Band Data Retrieval

  3. Hacker scans the internet

  4. HTML5 Hard Disk Filler™ API

  5. Eradicating DNS Rebinding with the Extended Same-Origin Policy

  6. Aaron Patterson – Serialized YAML Remote Code Execution

  7. Mario Heiderich – Mutation XSS

  8. Timothy Morgan – What You Didn’t Know About XML External Entity Attacks

  9. Tor Hidden-Service Passive De-Cloaking

  10. Auto-Complete Hack by Hiding Filled in Input Fields with CSS

  11. Pixel Perfect Timing Attacks with HTML5

  12. Large Scale Detection of DOM based XSS

  13. Angelo Prado, Neal Harris, Yoel Gluck – BREACH

  14. Weaknesses in RC4

  15. Lucky 13 Attack


Resultados de años anteriores:2006 (65), 2007 (83), 2008 (70), 2009 (82), 2010 (69), 2011 (51) y 2012 (56).

Fuente: http://blog.whitehatsec.com/top-10-web-hacking-techniques-2013/

 

Los Puertos Logicos

trinity-nmapscreen-hd-crop-1200x728

Los puertos lógicos son básicamente el direccionamiento de la capa 4 del modelo OSI, estos puertos lo podemos dividir en dos:

  • TCP

  • UDP


ya que ambos son protocolos de transporte.

Un poco de como funcionan
Los puertos son el  medio que tiene el Sistema Operativo para poder entregar un paquete IP a una aplicación especifica, por ejemplo un cliente al enviar una petición ya sea HTTP (puerto 80) o FTP (puerto 20-21), envía paquetes que son transportadas hasta la capa de "transporte" para ser dividida en segmentos y así el servidor podrá saber la IP de origen, la IP de destino y el puerto del servicio requerido.


puertos1

Tipos de puertos:


Los puertos en general tienen un rango que van de 0 hasta 65,534 (UDP como TCP), y son dividos en tres categorías:




  • Well-known port: 0-1013

  • Registered ports: 1024-49,151

  • Dynamic and private ports: 49,152-65,534


Well-known port: Aquí se encuentra el rango de puerto usado por las aplicaciones más comunes como el FTP (20-21), HTTP (80), SSH (22), TELNET (23), etc.


Para un listado completo ver la entrada de Wikipedia


Registered ports: Los puertos de registro son asignados por IANA o ICANN, los cuales hacen referencia a una determinada aplicación o protocolo. Un ejemplo clásico es el uso de webmin que utiliza el puerto 10000 para su conexión


Para mayor estudio ver la entrada de Wikipedia


Dynamic and private ports: Son los puertos que están disponibles para cualquier aplicación a utilizar en la comunicación.


Puertos y Seguridad


Dentro de la seguridad informática, el conocimiento de puertos es algo elemental, cabe destacar el conocimiento del uso de puertos en el manejo de firewall para abrir o negar servicios y el filtrado de paquetes a través de dichos puertos.


También encontramos el uso de aplicaciones Port Scaner, el cual descubre que puertos, ya sea TCP o UDP, tiene abierta una maquina y así poder averiguar que servicios están corriendo en un servidor en cualquier momento y con la eventualidad de ser explotador (obviamente haciendo ethical hacking)

Repositorio de Sitios Vulnerables

Haciendo un poco de "Black SEO" dí con el sitio Secureless.org, portal que posee un listado de sitios web que presentan alguna vulnerabilidad en su sistema. El proyecto esta bastante interesante, ademas de indicar las fallas de los sitio posee una gráfica con las vulnerabilidad mas comunes, de todas maneras hay que ver el sitio para estudiar un poco.

Link: Secureless – http://www.secureless.org

Generando contraseñas aleatorias

Sin título-1Random.org es un sitio destinado a generar contraseñas de manera aleatoria para así poder ser utilizadas de manera segura por en las cuentas que el usuario necesite.

Generalmente el usuario promedio al momento de crear sus contraseñas utiliza información personal como por ejemplo:

  • Fechas de nacimientos
  • Nombres de familiares
  • Números de teléfono
  • Dirección
  • Etc

Otro factor importante es que los internautas además utilizan claves fáciles de adivinar (artículo 10 contraseñas más utilizadas) . Estos dos hechos puntuales constituyen una falta grave en la seguridad de la información, puesto que un atacante destinando algo de tiempo puede averiguar estos datos.

Es por ello que random.org ofrece un servicio gratuito para generar claves de forma totalmente aleatorias.

random

Las peores contraseñas del 2013

[caption id="attachment_1167" align="aligncenter" width="660"]1390321923_0 y lo más probable que tambien del 2014...[/caption]

Something You Know, Have, or Are

Sin título-2

Methods for authenticating people differ significantly from those for authenticating machines and programs, and this is because of the major differences in the capabilities of people versus computers. Computers are great at doing large calculations quickly and correctly, and they have large memories into which they can store and later retrieve Gigabytes of information. Humans don't. So we need to use different methods to authenticate people. In particular, the cryptographic protocols we've already discussed are not well suited if the principal being authenticated is a person (with all the associated limitations).


All approaches for human authentication rely on at least one of the following:




  • Something you know (eg. a password). This is the most common kind of authentication used for humans. We use passwords every day to access our systems. Unfortunately, something that you know can become something you just forgot. And if you write it down, then other people might find it.

  • Something you have (eg. a smart card). This form of human authentication removes the problem of forgetting something you know, but some object now must be with you any time you want to be authenticated. And such an object might be stolen and then becomes something the attacker has.

  • Something you are (eg. a fingerprint). Base authentication on something intrinsic to the principal being authenticated. It's much harder to lose a fingerprint than a wallet. Unfortunately, biometric sensors are fairly expensive and (at present) not very accurate.


Something You Know


The idea here is that you know a secret --- often called a password --- that nobody else does. Thus, knowledge of a secret distinguishes you from all other individuals. And the authentication system simply needs to check to see if the person claiming to be you knows the secret.


Unfortunately, use of secrets is not a panacea. If the secret is entered at some sort of keyboard, an eavesdropper ("shoulder surfing") might see the secret being typed. For authenticating machines, we used challenge/response protocols to avoid sending a secret (key) over the wire where it could be intercepted by a wiretapper. But we can't force humans to engage in a challenge/response protocol on their own, because people cannot be expected to do cryptographic calculations.


Furthermore, people will tend to choose passwords that are easy to remember, which usually means that the password is easy to guess. Or they choose passwords that are difficult to guess but are also difficult to remember (so the passwords must be written down and then are easy for an attacker to find).


Even if a password is not trivial to guess, it might succumb to an offline search of the password space. An offline search needs some way to check a guess without using the system itself, and some methods used today for storing passwords do provide such a way. (See below.)


Finally, changing a password requires human intervention. Thus, compromised passwords could remain valid for longer than is desirable. And there must be some mechanism for resetting the password (because passwords will get forgotten and compromised). This mechanism could itself be vulnerable to social-engineering attacks, which rely on convincing a human with the authority to change or access information that it is necessary to do so.


With all these concerns about passwords, you might wonder what is required for a password to be considered a good one. There are three dimensions, and they interact so that strengthening one can be used to offset a weakness in another.




  • Length. This is the easiest dimension for people to strengthen. Longer passwords are better. A good way to get a long password that is seemingly random yet easy to remember is to think of a passphrase (like the first words of a song) and then generate the password from the first letters of the passphrase.

  • Character set. The more characters that can be used in a password, the greater the number of possible combinations of characters, so the larger the password space. To search a larger password space require doing more work by an attacker.

  • Randomness. Choose a password from a language (English, say) and an attacker can leverage regularities in this language to reduce the work needed in searching the password space (because certain passwords are now "impossible"). For instance, given the phonotactic and orthographic constraints of English, an attacker searching for an English word need not try passwords containing sequences like krz (although this would be a perfectly reasonable to try if the password was known to be in Polish). Mathematically, it turns out that English has about 1.3 bits of information per character. Thus it takes 49 characters to get 64 bits of "secret", which comes out to about 10 words (at 5 characters on average per word).


When passwords are used for authenticating a user, the system must have a way to check whether the password entered is valid. Simply storing a file with the list of usernames and associated passwords, however, is a bad idea because if the confidentiality of this file were ever compromised all would be lost. (Similarly, backup copies of this file would have to be afforded the same level of protection, since people rarely ever change their passwords.) Better not to store actual passwords on-line. So instead we might compute a cryptographic hash of the password, and store that. Now, the user enters a password; the system computes a hash of that password; and the system then compares that hash with what has been stored in the password file.


Even when password hashes instead of actual passwords are what is being stored, the integrity of this file of hashes must still be protected. Otherwise an attacker could insert a different hash (for a password the attacker knows) and log into the system using that new password.


The problem with having a password file that is not confidential --- even if cryptographic hashes are what is being stored --- is the possibility of offline dictionary attacks. Here, the attacker computes the hash of every word in some dictionary and then compares each hash with the stored password hashes. If any match, the attacker has learned a password. An alternative to confidentiality for defending against offline dictionary attacks is use of salt. Salt is a random number that is associated with a user and is added to that user's password when the hash is computed. With high probability, a given pair of users will not have the same salt value. And the system stores both h(password + salt) and the salt for each account.


Salt does not make it more difficult for an attacker to guess the password for a given account, since the salt for each account is stored in the clear. What salt does, however, is make it harder for the attacker to perpetrate an offline dictionary attack against all users. When salt is used, all the words in the dictionary would have to be rehashed for every user. What formerly could be seen as a "wholesale" attack has been transformed into a "retail" one.


Salt is used in most UNIX implementations. The salt in early versions of UNIX was 12 bits, and it was formed from the system time and the process identifier when an account is created. Unfortunately, 12 bits is hopelessly small, nowadays. Even an old PC can perform 13,000 crypt/sec, which means such a PC so can hash a 20k word dictionary with every possible value of a 12 bit salt in 1 hour.



Secret Salt


Another defense against offline dictionary attacks is to use secret salt (invented by Manber and independently by Abadi and Needham). In this scheme, we select a small set of possible "secret salt" values from a large space. The password file then stores for each user: userid, h(password, public salt, secret salt), public salt. Note that the value of the secret salt used in computing the hash is not saved anyplace. When secret salt is being employed, a user login involves having the system guess the value of secret salt that was used in computing the stored, hashed password; the guess involves checking through the possible secret salt values. The effect is to make computing a hashed password very expensive for attackers.



Examples of Password Systems


We now outline several widely-used password systems.




  • Unix. Unix stores a hashed salted password and salt. For the hash, it iterates DES 25 times with an input of "0" and with the password as the key; it then adds the 12-bit salt. As discussed above, this is not strong enough for today's machines. Some versions of Unix employ a shadow password file, so that it is harder for an attacker to retrieve the hashed passwords. There are then two files: /etc/shadow and /etc/master.password.

  • FreeBSD. FreeBSD stores a hashed password (where the hash is based on MD5). There is no limit to the length of the password, and 48 bits of salt are used.

  • OpenBSD. OpenBSD does a hash based on blowfish encryption, and then stores the hashed password along with 128 bits of salt. The system guarantees that no two accounts will have the same salt value.

  • Windows NT/2000/XP. NT stores 2 password hashes: one called the LanMan hash and another called the NT hash. The LanMan hash is used for backwards compatibility with Windows 95/98, and it is a very weak scheme. The following diagram shows how it works.

    To see the weakness, consider how much work an attacker would have to do to break this scheme. The numbers and uppercase letters together make up 36 characters. Each half of a 14-character password then has 367 possible values, which comes out as 78,364,164,096. The actual work factor then is 2 x 367 (whereas the theoretical work factor for 14 characters is 3614 = 367 x 367).Note that if upper and lower case were both allowed, then there would be (2 x 26) + 10 = 62 possible characters and thus 627 = 3,512,614,606,208 possible values, which is 100 times greater than the LanMan value.

    The NT hash is somewhat better. In the NT operating system, there was still a 14 character limit, although this limit was removed in Windows 2000 and XP. The password is then passed through 48 iterations of MD4 to get a 128 bit hash. This hash is stored in the system, but no salt is used at all.


Defense Against Password Theft: A Trusted Path


Given schemes that make passwords hard to guess, an attacker might be tempted to try theft. The attack is: install some some sort of program to produce a window that resembles a login prompt or otherwise invites the user to reveal a password. Users will then type their passwords into this program, where the password is saved for later use by the attacker.


How can you defend against such attacks? What we would like is some way for a user to determine the pedigree of any window purporting to be a login prompt. If each point in the pedigree is trusted, then the login prompt window must be trusted and it is safe to enter a password. This idea is called a trusted path.


To implement a trusted path, the keyboard driver recognizes a certain key sequence (Ctl-Alt-Del in Windows) and always then transfers control to some trusted software that displays a (password prompt) window and reads the contents. Users are educated to type passwords only into windows that appear after typing that special key sequence.


Notice, however, that this scheme requires that a trusted keyboard driver is executing. So, that means the system must be running an operating system that is trusted to prevent keyboard driver substitutions. One might expect that rebooting the machine would be a way to ensure that a trusted operating system is executing (presuming you trust whatever operating system is installed), but what if the OS image on the disk had been altered by an attacker? So, one must be certain that the operating system software stored on the disk has not been modified, too. But even that's not enough. What about the boot loader, which might have been altered to read a boot block from a non-standard location on the disk? And so it goes. Even if you start each session by booting from your own fresh OS CD, a ROM or even the hardware might have been hacked by an attacker. Physical security of the hardware then must also have been maintained. In the end, though, to the extent that you can trust all layers from the hardware to the keyboard driver, the resulting trusted path provides a way to defend against attacks implemented by programs that attempt to steal passwords by spoofing.



Something You Have


Instead of basing authentication on something a principal knows and can forget, maybe we should base it on something the principal has. Various token/card technologies support authentication along these lines. For all, 2-factor authentication becomes important --- an authentication process that involves 2 independent means of authenticating the principal. So, we might require that a principal not only possess a device but also know some secret password (often known as a PIN, or personal identification number). Without 2-factor authentication, stealing the device would allow an attacker to impersonate the owner of the device; with 2-factor authentication, the attacker would still have another authentication burden to overcome.


Here are examples of technologies for authentication based on something a principal might possess:




  • A magnetic strip card. (eg. Cornell ID, credit card) One serious problem with these cards is that they are fairly easy to duplicate. It only costs about $50 to buy a writer, and it's easy to get your hands on cards to copy them. To get around these problems, banks implement 2-factor authentication by requiring knowledge of a 4 to 7 character PIN whenever the card is used.Short PINs are problematic. First, they admit guessing attacks. Banks defend against this by limiting the number of guesses before they will confiscate the card. Second there is the matter of how to check if a PIN that has been entered is the correct one. Storing the PIN on the card's magnetic stripe is not a good idea because a thief who steals the card can easily determine the associated PIN (and then subvert the 2-factor authentication protocol). Storing an encrypted copy of the PIN on the card's magnetic stripe does not exhibit this vulnerability, though.

  • Proximity card or RFID. These cards transmit stored information to a monitor via RF. There is currently a debate in this country as to the merits of using RF proximity cards (RFID tags) for identification of people and products. Walmart speaks about puttung RFID tags on every product they shelve, and both the German and U.S. governments are including them in passports. With RFID tags on Walmart products, for example. then somebody with a suitable receiver could tell what you have purchased (even though your purchase is hidden in a bag) --- and this is seen by some as a privacy violation. With RFID tags in passports, somebody with a suitable receiver could remotely identify on the street citizens of a given country and single them out for "special treatment" (likely unpleasant).There are two types of RF proximity cards: passive and active. The former is not powered, and use the RF energy from the requester to reply with whatever information is being stored by the card. The latter is powered and broadcasts information, allowing anyone who is in range and has a receiver to query the card. You could imagine that if RF tags are put into passports, then some people might start carrying them in special Faraday-cage passport holders, because now an interloper can learn about someone without the victim's knowledge (or permission).

  • Challenge/Response cards and Cryptographic Calculators. These are also called smart cards and perform some sort of cryptographic calculation. Sometimes the card will have memory, and sometimes it will have an associated PIN. A smart card transforms the authentication problem for humans, because we are no longer constrained by stringent computational and storage limitations. Unfortunately, today's smart cards are vulnerable to power-analysis attacks. Furthermore, one must exercise care in using a cryptographic calculator --- if it is used to generate digital signatures, for example, then somehow the device owner must be made aware of what documents are being signed.One prevalent form of smartcard is the RSA secure id. It continuously displays encrypted time; and each RSA secure id encrypts with a different key. Whoever has an RSA secure id card responds to server challenges by typing the encrypted time (so, in effect, it is secret) --- a server, knowing what key is associated with each user's card, can then authenticate a user. (The server must be somewhat generous with respect to what times it will accept. Accept too many and replay attacks become possible; accept too few and message delivery delays and execution times prevent people from authenticating themselves).


Something You Are


Since people forget things and lose things, one might contemplate basing an authentication scheme for humans on something that a person is. After all, we recognize people we interact with not because of some password protocol but because of how they look or how they sound --- "something they are". Authentication based on "something you are" will employ behavioral and physiological characteristics of the principal. These characteristics must be easily measured accurately and preferably are things that are difficult to spoof. For example, we might use




  • Retinal scan

  • Fingerprint reader

  • Handprint reader

  • Voice print

  • Keystroke timing

  • Signature


To implement such a biometric authentication scheme some representation for the characteristic of interest is stored. Subsequently, when authenticating that person, the characteristic is measured and compared with what has been stored. An exact match is not expected, nor should it be because of error rates associated with biometric sensors. (For example, fingerprint readers today normally exhibit error rates upwards of 5%.)


Methods to subvert a fingerprint reader give some indication of the difficulties of deploying unsupervised biometric sensors as the sole means of authenticating humans. Attacks include:




  • Steal a finger. Difficult to do without the owner of the finger noticing. Good supervision of the biometric sensor defends against this attack.

  • Steal a fingerprint. Lifting a fingerprint is not that hard (at least, according to those TV crime-drama shows). Again, though, good human supervision of the biometric sensor defends against this attack because a guard will notice if somebody is not inserting a naked finger into the reader.

  • Replace the biometric sensor. At first glance, this type of attack might seem even more difficult to execute than the two above. Social enginnering might be easier for the attacker to employ, here, though. It suffices that the guard believe that the senor should be changed (maybe because the the old one is "broken").


There are several well known problems with biometric-based authentication schemes:




  • Reliability of the method. Similarity of physical features (faces, hands, or fingerprints) and inaccuracy of measurement may together conspire to create an unacceptably high false acceptance rate (FAR).

  • Cost and availability. Currently, some readers cost $40-50 and more. Are end users willing to pay that much for an authentication method that does not work as well as passwords?

  • Unwillingness or inability to interact with biometric input devices. Some people are uncomfortable putting a body part into a machine; some are uncomfortable having lasers shined in their eyes for a retinal scans; and some don't have fingers or eyes to be measured.

  • Compromise the biometric database or system. It might be possible to circumvent the system's biometric sensor and provide an "input" from another source. The sensor is, after all, connected to a system and hijacking that channel might be possible. Knowledge of the stored representation for a characteristic would then allow an attacker to inject the correct characteristic and impersonate anyone.

  • Revocation. What does it mean to revoke a fingerprint?


The literature on biometric authentication uses the following vocabulary to characterize what a scheme does and how well it works:




  • FAR: (false acceptance rate). This is the probability that the system will fail to reject an impostor (aka FMR: false match rate)

  • FRR: (false reject rate). This is the probability that the system will reject a bona fide principal. (aka FNMR: false non-match rate)

  • One-to-one matching: Compare live template with a specific stored template in the system. This corresponds to authentication.

  • One-to-many matching: Compare live templates with all stored templates in the system. This corresponds to identification.


Summary


Having looked at all these methods for authentication, we can see that as a secondary form of authentication (but not identification!) biometrics might be promising. The most likely form of authentication in the future, however, will be a combination of something you have and something you know. Passwords will be around for a long time yet.


Fuente: http://www.cs.cornell.edu/courses/cs513/2005fa/nnlauthpeople.html

Inyecciones SQL

Inyecciones SQL

Clonezilla - Clonando nuestro Disco Duro [Parte 2]

clonezilla

Clonezilla es un software GPL basado en Debian, para la clonación de discos y particiones. Puede clonar una máquina individual, partición o disco y guardarla como un archivo de imagen o como una copia exacta de datos. Los datos pueden ser guardados localmente, en un servidor SSH, servidor Samba o un recurso compartido de archivos NFS para restaurarlos posteriormenter. Podemos ejecutar el programa desde un LiveCD o LiveUSB .

Ofrece diversos tipos de clonación:

  • Copia de dispositivo a imagen: hacer backup o restaurar.

  • Copia de dispositivo a dispositivo: clonar un disco entero o únicamente una partición de este.


Opciones de directorio, donde almacenar o restaurar nuestra imagen.

  •     Máquina local: ya sea un disco duro interno como externo.

  •     Servidor SSH.

  •     Servidor Samba.

  •     Servidor NFS.


Opciones de compresión:

  •     Compresión gzip: imagen algo más pequeña que la real.

  •     Compresión bzip2: la más comprimida.

  •     Compresión lzo: más rápida que gzip y con un tamaño parecido.

  •     Sin compresión: la más rápida pero también la que más nos ocupará.


Su interfaz no es tan amigable como  la de los otros dos programas explicados anteriormente, pero al hecho de ser un programa GPL se añade su versatilidad y eficiencia, además de que soporta casi todo tipo de formato de archivos. Cuenta así mismo con una versión para servidores que posibilita la instalación de imágenes en red.

Lo descargamos de su página oficial

Clonezilla



Crear una Imagen con Clonezilla

Una vez descargado el programa, y como siempre, preparamos un LiveCD o un LiveUSB.
Luego configuramos el arranque de la BIOS, y arrancamos el sistema.

Se iniciará el software:



Seleccionamos nuestro idioma:


Dejamos sin tocar el sistema de teclado:


E iniciamos el proceso:


Seleccionamos la primera de las opciones:


Ahora indicamos el lugar donde vamos a guardar o tenemos guardada la imagen de Clonezilla. En el caso de este ejemplo se trata de un dispositivo local, concretamente un USB, de modo que seleccionamos:


Tal y como nos indica, pulsamos Intro para que el programa detecte el USB:


En este punto, una vez detectado el dispositivo a utilizar, lo seleccionamos:


Ahora Clonezilla indica el directorio por defecto donde crear la imagen. Aceptamos:


Analiza:


Y en el siguiente punto elegimos modo principiante:


Definimos ahora si vamos a clonar el disco duro o una partición. En este ejemplo es el dico duro:


Nos crea el nombre por defecto de la imagen, que podemos dejar o cambiar por otro:


Ahora le indicamos que disco duro o partición va a ser clonada:


La reconoce perfectamente, de modo que proseguimos:


Nos solicita confirmación, cosa que hacemos:


Empieza el proceso de creación de la imagen:


Una vez finalizado el proceso nos pregunta si deseamos seguir o terminar. Seleccionamos la segunda opción puesto que ya hemos logrado nuestro propósito.


Apagamos el sistema con la opción 0 y ya hemos terminado; creando con éxito una imagen de nuestro disco duro que podremos restaurar posteriormente.




 
Restaurar una Imagen con Clonezilla

Procedemos como en el apartado anterior hasta llegar a la siguiente pantalla, donde elegiremos restaurar una partición o un disco. En el caso de este ejemplo, una partición:


Seleccionamos la  imagen a restaurar:



Elegimos la partición donde vamos a restaurar la imagen:




Continuamos:


Confirmamos:


Y aquí está en marcha:



Nos informa de que se ha finalizado el proceso correctamente:


Y ahora ya podemos apagar o reiniciar el equipo y encontraremos nuestro sistema restaurado.



Fuente: http://freesiete.site90.com/ImagenSO.html#Clonezilla

Redo Backup - Clonando nuestro Disco Duro [Parte 1]

redo

Redo Backup es un software GPL para clonar discos duros, recuperar datos y ayuda en la  creación y restauración de imágenes de nuestro sistema. Funciona tanto en ambientes Windows y Linux, destacando por su interfaz de gran sencillez, la rapidez y eficiencia que este presenta.

El software no tiene un tamaño mas allá de 75 MB y puede ser utilizado tanto como Live CD o Live USB. Además se puede conectar a nuestra red local para guardar la imagen o restaurarla, así como configurar nuestra wifi y navegar o descargar archivos.

Lo puedes descargar aquí -> Descargar Redo Backup & Recovery


Aquí vemos la pantalla principal con gran cantidad de opciones


Herramientas diversas tales como el editor de particiones GParted, recuperador de archivos, utilidades de disco, sincronización de archivos....


E incluso el navegador web Firefox


Acceso a nuestras particiones y archivos




Y sin más, vamos a crear nuestra imagen del sistema. Más intuitivo no puede ser. Seleccionamos la opción Backup:


Escaneará las particiones y discos para permitirnos elegir la que deseemos:


En este caso, ha encontrado un disco duro que seleccionamos para clonar:


Elegimos ahora el disco donde queremos guardar la imagen:


Y la carpeta donde deseemos hacerlo:


Le damos un nombre a nuestro backup o dejamos el propuesto por defecto:


Aceptamos y el programa empezará a realizar la copia


En unos minutos la habrá terminado


Restaurar una Imagen con Redo Backup & Recovery

El proceso de restauración es igualmente sencillo. Elegimos la opción Restore


Y procedemos como en la creación de la imagen. Es decir, seleccionamos el disco donde está guardada la imagen a restaurar


Y la imagen misma


Ahora le decimos en qué partición o disco debe restaurarla


Nos avisa de que se sobreescribirán todos los datos existentes, como es lógico:


En unos minutos volveremos a tener nuestro sistema.





Articulo Original: http://freesiete.site90.com/ImagenSO.html