Archivo

Posts Tagged ‘Noticias’

SUBE: la seguridad informática en duda

agosto 12, 2012 Deja un comentario

SUBE: la seguridad informática en duda

Expertos en protección de datos cuestionan las falencias del sistema; denuncian robo de identidad y demoras en el trámite online

Miércoles 14 de marzo de 2012

Por Cynthia Palacios  | LA NACION

 

“Es una solución ágil y sencilla diseñada para el transporte público de pasajeros”, rezaba el eslogan. Pero hacerse de una tarjeta SUBE resultó poco ágil y menos sencillo para miles de usuarios del transporte público. Y para muchos, más que una solución, obtener la tarjeta más nombrada de los últimos tiempos resultó un dolor de cabeza.

Con la disminución de los puestos de entrega del plástico del Sistema Unico de Boleto Electrónico (SUBE), de 600 a 10, el eje de la polémica pasó de las visibles -e interminables- colas a un terreno casi invisible: el virtual. Los pasajeros denuncian robo de identidad, pérdida del crédito, problemas para seguir el trámite por Internet y escasas medidas de protección de sus datos personales.

La Secretaría de Transporte asegura que se entregaron más de 11 millones de tarjetas, y la falta de plásticos en los puestos callejeros hizo que colapsara la página web oficial luego de que se tramitaron 12.000 en dos horas.

La falta de un usuario registrado con su correspondiente contraseña es la primera alarma que detectan los especialistas en seguridad informática consultados por LA NACION.

“La falencia más grande es que no tiene ningún paso de seguridad”, opinó Cristian Borghello, licenciado en sistemas y director del sitio segu-info.com.ar.

“Los datos de los recorridos que figuran en la SUBE son personales y están amparados por la ley 25.326, de protección de datos personales. Esa norma dice que toda base de datos tiene que contar con medidas de seguridad adecuadas para evitar su acceso remoto o no autorizado”, explicó el abogado especialista en derecho informático y director de informaticalegal.com , Miguel Sumer Elías.

La vulnerabilidad informática del sistema inquietó a los integrantes del Centro de Protección de Datos Personales de la Defensoría del Pueblo de la Ciudad, que libraron un oficio a la Secretaría de Transporte, cuya respuesta están esperando. “Queremos que el sistema ofrezca garantías personalizadas y se pueda constatar que el usuario está averiguando sobre sí mismo. Sabemos que hay bases de datos públicas con más elementos que la SUBE y esta tarjeta no será un sistema de información de primera línea, pero es vulnerable”, consideró Eduardo Peduto, a cargo del centro.

“La disposición 11/2006 de la Dirección Nacional de Protección de Datos Personales establece tres medidas de seguridad. La SUBE no cumple ni siquiera con las medidas de seguridad mínimas”, destacó Elías.

Peduto contó que la defensoría porteña recibió varios casos de ciudadanos que pidieron su tarjeta a través de la página web. “Después de algunos días recibieron como respuesta que había sido rechazado porque ese peticionario ya tenía una tarjeta SUBE otorgada”, relató.

“El robo de identidad de las tarjetas es notable, porque no hay controles”, lamentó Elías. En el sitio que dirige recibieron más denuncias de usuarios que fueron a tramitar su tarjeta y se encontraron con la sorpresa de que ya había sido pedida por otra persona. “En esos casos la carga de la prueba corresponde al afectado. La denuncia debe hacerse por un teléfono que jamás te atienden”, agregó.

“Cualquiera que llame al número del SUBE y diga que cree que le robaron la tarjeta, al informar un número de documento le dan el número de la tarjeta -señaló Borghello-. Si pensamos en los más chicos y en la cantidad de robos que hay, nos preocupa que con tanta facilidad se pueda planificar un delito contra un menor.”

Los responsables del sitio Segu-Info se pusieron en contacto con la página oficial para que mejoren este sistema de control de las tarjetas y les explicaron que los datos son almacenados porque “si la tarjeta es perdida o robada, ellos la bloquean y el usuario recupera el dinero que tenía cargado al momento de la pérdida”. “Lo que no explican es por qué esa información se encuentra publicada casi sin control”, afirmó Borghello.

“Creo que el sistema se implementó muy rápido, sin pensar en el daño que podía ocasionar”, reveló el especialista en Derecho de las Nuevas Tecnologías y Protección de Datos Personales Daniel Monastersky, director del sitio identidadrobada.com. “El alta se debería dar con un nombre de usuario y contraseña. Lo comparo con el home banking : tienen datos que son mucho más sensibles, pero cumplen con medidas de seguridad y uno confía en el banco”, destacó.

“La preocupación es exagerada. No creo que se pongan a hacer inteligencia ni que el Estado esté armando un Gran Hermano de la tarjeta SUBE”, dijo el fiscal general Ricardo Sáenz, especialista en delincuencia informática. Y objetó. “Está bien que junten nuestros datos, pero no que sean accesibles para cualquiera”.

Complicaciones

 

  • Robo de identidad: los usuarios se quejan de que, al tramitar la tarjeta, el proceso es rechazado porque ese beneficiario ya tenía una tarjeta otorgada. Comienza allí una batalla legal donde deben demostrar que no la han solicitado.

 

  • Carga misteriosa: algunos pasajeros se quejan porque desaparece el dinero de su tarjeta y el trámite para recuperarlo puede demorar más de un mes .

 

  • Dinero en el ciberespacio: otros usuarios explican que, al renovar la tarjeta, el crédito que tenían cargado no aparece en la nueva tarjeta. ¿Cómo recuperarlo? En las mismas oficinas que expiden la tarjeta, donde las colas son larguísimas.

 

  • Virtual, pero en persona: algunas personas que tramitaron la tarjeta a través de la página web reciben luego una respuesta de que no pudo identificarse su domicilio y deben retirarla personalmente en una oficina de la Anses. Otra vez colas interminables. Una vecina de Munro que tuvo este problema contó que a su marido, ante un trámite igual, le llegó al domicilio sin problemas.

 

  • Al alcance de todos: los especialistas en seguridad informática señalan que sabiendo el número de documento de una persona se puede conocer, vía telefónica, el número de la tarjeta SUBE y así conocer sus recorridos.

Fuente: LANACION

Un “tweet” desencadenó el ataque de hoy a la red Twitter

agosto 12, 2012 Deja un comentario

21/09/10 – 17:54

Los hackers escribieron código informático y lo introdujeron en el sistema a través de un breve mensaje de menos de 140 caracteres. Demostraron, de este modo, que los filtros de la red social pueden fallar.

Los hackers escribieron código informático y lo introdujeron en el sistema a través de un breve mensaje de menos de 140 caracteres. Demostraron, de este modo, que los filtros de la red social pueden fallar.

Un breve tweet, un mensaje de menos de 140 caracteres. Sólo eso necesitaron los hackers hoy para poner en vilo a Twitter, una de las redes sociales del momento.

Claro, no era un mensaje cualquiera. Se trataba de código de informática (conocido en la jerga como “exploit”) con el que buscaron demostrar la vulnerabilidad del sistema, informó a Clarín Ignacio Sbampato, de la empresa de seguridad informática Eset Latinoamérica. En este caso, aprovecharon un error en la programación de Twitter y lograron que la “infección” se propagara viralmente, a la velocidad que adquiere el mundo interconectado.

“El error estaba en el acortador de URL t.co, que es de Twitter. Es uno de los tantos servicios que acortan las direcciones electrónicas largas para que entren en un mensaje de solo 140 caracteres. Esto usaron para generar el exploit. El usuario veía el mensaje con link, pero allí estaba escondido el exploit que modificaba la programación del sitio”, agrega Francisco Amato, de Infobyte Security Research.

“Se trató de un ataque XSS (Cross-site scripting). Los atacantes no ingresaron al sitio de Twitter pero pudieron introducir código en la parte pública del servidor, que es lo que todos vemos –explica Sbampato–. Pudieron vencer los filtros de Twitter e introducir ese código a través de un exploit de menos de 140 caracteres. Tuvieron que aprovechar al máximo ese breve espacio”.

 

Tres versiones

El exploit afectó sólo al servicio de Twitter en la Web y no a las aplicaciones relacionadas que corren tanto en la computadora como en los teléfonos celulares.

En rigor, se trató de tres versiones del exploit que lograron distintos efectos. Uno de ellos lograba que, con solo situar el mouse sobre cualquier mensaje, éste se retuiteara automáticamente. Otro era una especie de spam, que redirigía al usuario a un sitio pornográfico. Y el tercero cambiaba los colores de la plataforma.

Los especialistas creen que el de los colores fue el primero, y que con ese exploit los hackers estaban probando su efectividad. Y que los otros dos vinieron después, como una forma de darle visibilidad a su creación.

Los hackers suelen hacer este tipo de ataques con frecuencia con el objetivo de mostrar las vulnerabilidades de los sistemas y, eventualmente, ofrecer las soluciones. “Así funciona el mercado de las vulnerabilidades. Están probando todo el tiempo. Y acá mostraron un error en Twitter. La opinión general es que esto nació como algo inofensivo, pero luego tomó viralidad”, dice Sbampato.

Amato cree que pudo haber existido la intención de tomar computadoras para armar “redes zombies” (conocidas en la jerga como “botnets”). “Cuando el enlace te enviaba a un sitio pornográfico, en realidad podría tratarse de un sitio que explota la vulnerabilidad del navegador y toma control de tu PC. El final podría haber sido una botnet, pero no lo sabemos”, dice.

Para Sbampato problemas de este tipo van a seguir ocurriendo, a medida que los hackers consigan vulnerar el filtro de Twitter, como el de cualquier otro servicio web. “Siempre que tenés un sitio que acepta usuarios estás propenso a que esto suceda. Lo mismo con los formularios web”.

Sbampato cuenta que Twitter tomó la decisión de arreglar la cuestión sin “apagar” el sitio, y ese fue el motivo por el cual el problema demoró más de dos horas en solucionarse. “Desde el punto de vista de la seguridad, tenían que haber dado de baja el servicio. Nosotros siempre decimos, que servicio que anda mal se para. Pero en este caso, decidieron seguir adelante”.

 

Recomendaciones

Aunque sin dudas fue muy molesto para los usuarios, el ataque de hoy a Twitter no significó un peligro para la privacidad de los datos que se manejan en esa red social. Por eso, los especialistas no creen que sea necesario cambiar la contraseña de Twitter. “Aunque siempre es bueno ir cambiandola, te quedás más tranquilo”, puntualiza Sbampato.

Claudio Avin, de la Cámara Argentina de Internet (CABASE) dice que esta es una buena ocasión para que la gente recuerde que “nunca la contraseña en redes sociales y otros servicios web debe ser la misma que la que se usa en cuentas bancarias o cajeros automáticos, porque nunca estarán bien protegidas”.

Amato, por su parte, recomienda a los usuarios de Firefox que instalen el plug in No Script, que detecta y avisa cuando hay un ataque XSS.

Mientras que Sbampato aconseja darle un vistazo a la cuenta de Twitter @safety, que –dice—tiene buena información sobre seguridad y en un lenguaje accesible a las personas no especializadas. Aunque, claro, en inglés.

 

En Twitter: @RickyBraginski

Fuente: Clarín

 

Uno de cada cuatro sitios web está expuesto a ciberataques

agosto 12, 2012 Deja un comentario

Lo anunciaron dos jóvenes expertos en seguridad informática, uno de ellos argentino. Son los sitios desarrollados con un sistema de Microsoft, entre ellos de home banking. Los programadores tienen herramientas para protegerlos.

Lo anunciaron dos jóvenes expertos en seguridad informática, uno de ellos argentino. Son los sitios desarrollados con un sistema de Microsoft, entre ellos de home banking. Los programadores tienen herramientas para protegerlos.

Por RICARDO BRAGINSKI

El 25 por ciento de los sitios web de todo el mundo están expuestos a ataques, robos de datos y sabotaje anunciaron dos jóvenes expertos en seguridad informática –un argentino y un vietnamita– que participan de la cumbre de expertos en ciberdelitos Ekoparty que se realiza esta semana en Buenos Aires.

Juliano Rizzo y Thai Duong presentarán pasado mañana los detalles de su investigación, en la que exhiben las vulnerabilidades que tiene el sistema ASP.NET, de Microsoft, con el que están desarrollados el 25 por ciento de las páginas web, según el sitio BuiltWith. El error afecta a más porcentaje aún en el caso de las grandes empresas y los bancos, que usan mucho más los sistemas de Microsoft..

Los investigadores detectaron la falla en la forma en que ese sistema encripta los mensajes que le envían a los usuarios. “Cada vez que una persona se conecta con un servidor que usa ASP.NET, éste le deja en su navegador ciertos datos con la historia de esa sesión. Sería el equivalente a si uno va a un banco y le dan un ticket con la historia del trámite para que se pueda seguir más adelante . El ticket puede ser una serie de números que nadie entiende, sólo el cajero el día que uno vuelva –explica Rizzo a Clarín–. La comunicación entre el navegador y el sitio con ASP.NET es similar. El servidor deja un código que, supuestamente nadie entiende. Pero nosotros descubrimos que se puede vulnerar“.

Los detalles de la investigación y cómo se puede atacar estos sitios serán revelados por los dos jóvenes pasado mañana, en el cierre de la conferencia Ekoparty. Sin embargo, Rizzo adelantó a Clarín que la técnica que ellos utilizaron consiste, básicamente, en enviarle “tickets” falsos al servidor uno tras otro y estudiar la respuesta que reciben. “En función de esta respuesta podemos construir un “ticket” verdadero y hacernos pasar por administrador, por ejemplo”, explica Rizzo.

Como todo problema tiene su solución, los programadores de estos sitios ya cuentas con herramientas para proteger a sus usuarios, antes de que Microsoft termine de solucionar la vulnerabilidad. “Hay posibilidades de bloquear el agujero a través de herramientas conocidas como Web Application Firewall. Los detalles que vamos a presentar les van a permitir protegerse aún más”, dice Rizzo.

Juliano Rizzo y Thai Duong se conocieron el año pasado cuando participaban en una competencia online coreana. Debían resolver problemas matemáticos en equipos. “En cierto momento mi equipo estaba cabeza a cabeza con el de él y empezamos a chatear. El me preguntaba cosas y yo le decía que si te ayudo pierdo. Después nos seguimos mandando desafíos, y entre ellos estuvo el origen de esta investigación”, cuenta Rizzo.

Esta es la sexta edición de Ekoparty, la conferencia anual que reúne a consultores, investigadores, programadores y entusiastas de la tecnología de todo el mundo. La cita esta vez es en la Ciudad Cultural Konex, durante esta semana, y ya están participando más de 600 personas.

La idea de Ekoparty surgió del circuito “underground” de IT. Con el tiempo, fue sumando a más y más especialistas de empresas y estudiantes de sistemas. Discuten cómo ingresar a sistemas ajenos y cómo defenderlos de posibles ataques.
Fuente: Clarín

El 25 por ciento de los sitios web de todo el mundo están expuestos a ataques, robos de datos y sabotaje anunciaron dos jóvenes expertos en seguridad informática –un argentino y un vietnamita– que participan de la cumbre de expertos en ciberdelitos Ekoparty que se realiza esta semana en Buenos Aires.

Juliano Rizzo y Thai Duong presentarán pasado mañana los detalles de su investigación, en la que exhiben las vulnerabilidades que tiene el sistema ASP.NET, de Microsoft, con el que están desarrollados el 25 por ciento de las páginas web, según el sitio BuiltWith. El error afecta a más porcentaje aún en el caso de las grandes empresas y los bancos, que usan mucho más los sistemas de Microsoft..

Los investigadores detectaron la falla en la forma en que ese sistema encripta los mensajes que le envían a los usuarios. “Cada vez que una persona se conecta con un servidor que usa ASP.NET, éste le deja en su navegador ciertos datos con la historia de esa sesión. Sería el equivalente a si uno va a un banco y le dan un ticket con la historia del trámite para que se pueda seguir más adelante . El ticket puede ser una serie de números que nadie entiende, sólo el cajero el día que uno vuelva –explica Rizzo a Clarín–. La comunicación entre el navegador y el sitio con ASP.NET es similar. El servidor deja un código que, supuestamente nadie entiende. Pero nosotros descubrimos que se puede vulnerar“.

Los detalles de la investigación y cómo se puede atacar estos sitios serán revelados por los dos jóvenes pasado mañana, en el cierre de la conferencia Ekoparty. Sin embargo, Rizzo adelantó a Clarín que la técnica que ellos utilizaron consiste, básicamente, en enviarle “tickets” falsos al servidor uno tras otro y estudiar la respuesta que reciben. “En función de esta respuesta podemos construir un “ticket” verdadero y hacernos pasar por administrador, por ejemplo”, explica Rizzo.

Como todo problema tiene su solución, los programadores de estos sitios ya cuentas con herramientas para proteger a sus usuarios, antes de que Microsoft termine de solucionar la vulnerabilidad. “Hay posibilidades de bloquear el agujero a través de herramientas conocidas como Web Application Firewall. Los detalles que vamos a presentar les van a permitir protegerse aún más”, dice Rizzo.

Juliano Rizzo y Thai Duong se conocieron el año pasado cuando participaban en una competencia online coreana. Debían resolver problemas matemáticos en equipos. “En cierto momento mi equipo estaba cabeza a cabeza con el de él y empezamos a chatear. El me preguntaba cosas y yo le decía que si te ayudo pierdo. Después nos seguimos mandando desafíos, y entre ellos estuvo el origen de esta investigación”, cuenta Rizzo.

Esta es la sexta edición de Ekoparty, la conferencia anual que reúne a consultores, investigadores, programadores y entusiastas de la tecnología de todo el mundo. La cita esta vez es en la Ciudad Cultural Konex, durante esta semana, y ya están participando más de 600 personas.

La idea de Ekoparty surgió del circuito “underground” de IT. Con el tiempo, fue sumando a más y más especialistas de empresas y estudiantes de sistemas. Discuten cómo ingresar a sistemas ajenos y cómo defenderlos de posibles ataques.

El reconocimiento facial de Facebook, en el punto de mira en Noruega

agosto 6, 2012 Deja un comentario

Las autoridades de protección de datos de Noruega investigan a Facebook por su servicio de reconocimiento facial automático, ya que advierten de que atenta contra los derechos de privacidad del usuario.

Desde Noruega han hecho comentarios rotundos respecto a la privacidad de Facebook, muestra de ello es lo que dice el miembro del comisionado de protección de datos de Noruega, Bjorn Erik Thon: “Es una herramienta de Facebook muy poderosa y que todavía no está claro cómo funciona realmente”.

Los reguladores de protección de datos de los 27 países de la Unión Europea han estado investigando las características de la función de reconocimiento facial de Facebook que, automáticamente, sugiere al usuario los nombres de las personas que aparecen en una foto para que sean etiquetadas en la misma.

A principios de este año el artículo 29 del Grupo de Protección de Datos de la Unión Europea dictaminó que la función de Facebook en cuestión solamente podía ser usada bajo el consentimiento del usuario de la red social. Esta es la idea que reclaman ahora desde las autoridades de protección de datos noruegas pero, desde la red social no han hecho comentarios al respecto. Según el grupo del Artículo 29 el pasado 22 de marzo: “Los usuarios siempre deben contar con la posibilidad de retirar su consentimiento de forma sencilla”.

Al no formar parte de la Unión Europa, Noruega ha conseguido la colaboración de Irlanda para llevar a cabo su cometido, enviar un cuestionario que probablemente se centrará en el reconocimiento facial de Facebook, según Thon.

Pero el reconocimiento facial de Facebook no es la primera vez que recibe quejas sobre su política de privacidad. De hecho, el pasado 2 de julio de 2011 la red social anunciaba la posibilidad de deshabilitar la opción a sus usuarios.

Lo que esta tecnología hace es escanear las fotografías subidas recientemente, compara las caras con fotos anteriores e intenta encontrar los rostros y sugerir etiquetas. Cuando hay una coincidencia, Facebook avisa al que subió las fotos y le invita a “etiquetar” o identificar a la persona de la foto.

.

Fuente: EnfoqueSeguro

Categorías:Noticias, Privacidad Etiquetas: , ,

La ‘Dirty Dozen’ aplicaciones mas vulnerables del 2010

agosto 6, 2012 Los comentarios están cerrados

Bit 9 y la ‘Dirty Dozen’ con caras de líderes tecnológicos

El 16 de Noviembre, Bit9 desveló la cuarta edición de su lista anual de las aplicaciones que más vulnerabilidades de seguridad han publicado. Llamada la “Dirty Dozen” (Docena Sucia), esta lista intenta avisar a las empresas sobre los peligros que corren cuando permiten que empleados se bajen programas no aprobados (y para los cuales no se ha diseñado la estrategia de seguridad), o cuando no se mantienen a la par con las actualizaciones disponibles.

 

La lista incluye a empresas de las más conocidas del mundo tecnológico y sus aplicaciones más populares, tanto para compañías como consumidores. Por ejemplo, los miembros más ‘galardonados’ son Apple (contrario a la percepción general) y Adobe, pero también incluye a Google y Microsoft.

Lista Bit9 del 2010 de aplicaciones más vulnerables

La lista se clasifica por las aplicaciones que más vulnerabilidades de ‘alto riesgo’ han publicado, y es la siguiente para el 2010:

1. Google Chrome – 76 vulnerabilidades publicadas
2. Apple Safari – 60
3. Microsoft Office – 57
4. Adobe Reader and Acrobat – 54
5. Mozilla Firefox – 51
6. Sun Java Development Kit – 36
7. Adobe Shockwave Player – 35
8. Microsoft Internet Explorer – 32
9. RealNetworks RealPlayer – 14
10. Apple WebKit – 9
11. Adobe Flash Player – 8
12. Apple QuickTime y Opera – 6 (empate).

Criticas a la lista de Bit9

Como las vulnerabilidades tienen que estar publicadas, la lista suscita la crítica de que Bit9 fomenta el silencio sobre problemas de seguridad ya que castiga a los desarrolladores responsables, y además no toma en consideración la rapidez con la que se detectan y arreglan las vulnerabilidades. Pero Bit9 argumenta que su estudio clarifica a los IT managers la presencia predominante de vulnerabilidades de aplicaciones hasta en los productos más populares, y cómo diseñar la protección de sus redes teniéndolo en cuenta. “La realidad es que todas las empresas, incluidos nosotros, están usando como mínimo una de estas aplicaciones,” dijo Harry Sverdlove, CTO de Bit9, “y las vulnerabilidades no parcheadas son el punto de acceso más utilizado en los ataques dirigidos a empresas que vemos en las noticias.”

Fuente: Bit9

Categorías:Noticias Etiquetas:

¿Qué son los Rootkits?

agosto 5, 2012 Deja un comentario

rootkit_ilustration Rootkit es un conjunto de herramientas usadas frecuentemente por los intrusos informáticos o crackers que consiguen acceder ilícitamente a un sistema informático. Estas herramientas sirven para esconder los procesos y archivos que permiten al intruso mantener el acceso al sistema, a menudo con fines maliciosos. Hay rootkits para una amplia variedad de sistemas operativos, como Linux, Solaris o Microsoft Windows. Por ejemplo, el rootkit puede esconder una aplicación que lance una consola cada vez que el atacante se conecte al sistema a través de un determinado puerto. Los rootkits del kernel o núcleo pueden contener funcionalidades similares.

 

Un backdoor puede permitir también que los procesos lanzados por un usuario sin privilegios de administrador ejecuten algunas funcionalidades reservadas únicamente al superusuario. Todo tipo de herramientas útiles para obtener información de forma ilícita pueden ser ocultadas mediante rootkits

¿Cuales son sus objetivos?

Tratan de encubrir a otros procesos que están llevando a cabo acciones maliciosas en el sistema. Por ejemplo, si en el sistema hay una puerta trasera para llevar a cabo tareas de espionaje, el rootkit ocultará los puertos abiertos que delaten la comunicación; o si hay un sistema para enviar spam, ocultará la actividad del sistema de correo.

Los rootkits, al estar diseñados para pasar desapercibidos, no pueden ser detectados. Si un usuario intenta analizar el sistema para ver qué procesos están ejecutándose, el rootkit mostrará información falsa, mostrando todos los procesos excepto él mismo y los que está ocultando.

O si se intenta ver un listado de los ficheros de un sistema, el rootkit hará que se muestre esa información pero ocultando la existencia del propio fichero del rootkit y de los procesos que esconde.

Cuando el antivirus hagan una llamada al sistema operativo para comprobar qué ficheros hay, o cuando intente averiguar qué procesos están en ejecución, el rootkit falseará los datos y el antivirus no podrá recibir la información correcta para llevar a cabo la desinfección del sistema.

¿Cómo prevenirnos?

Es necesario un sistema que vigile no únicamente la actividad de los archivos en el disco, sino que vaya más allá. En lugar de analizar los archivos byte a byte, debe vigilarse lo que hacen al ejecutarse.

Un rootkit necesita llevar a cabo algunas tareas que se podrían considerar “típicas”, como adquirir derechos de root, modificar llamadas básicas al sistema operativo, falsear sistemas de reporte de datos del sistema… Todas estas tareas, una a una, entrañan poco peligro. Pero todas ellas, juntas y en el mismo momento, llevadas a cabo por el mismo programa, proporcionan información clara de que algo extraño está pasando en la computadora. Si las soluciones antivirus fracasan definitivamente a la hora de detectar un rootkit, las nuevas tecnologías de detección de amenazas por comportamiento tienen su mejor prueba de eficacia en la detección y bloqueo de rootkits. Estas tecnologías no basan su funcionamiento en condicionantes previamente aprendidos sobre patrones cerrados de identificación de amenazas. Su éxito se basa en la investigación inteligente y automática de la situación de un proceso en una computadora.

Cuando una serie de acciones se llevan a cabo sobre el sistema y todas ellas (o, al menos, alguna) pueden suponer un riesgo para la integridad de la información o el correcto funcionamiento de la máquina, se evalúan una serie de factores que sirven para calificar la peligrosidad de esa tarea. Por ejemplo, que un proceso quiera tomar derechos de administración en un sistema puede ser más o menos habitual. Y tiene un cierto riesgo, sin duda, pero no hay que alertar por ello. Un simple instalador para un juego puede necesitar tener derechos de administrador para poder llevar a cabo las modificaciones necesarias y poder ejecutarse correctamente.

O por ejemplo, es posible que un determinado proceso deba permanecer oculto, ya que no existe posibilidad de interacción, o que un determinado proceso abra un puerto en concreto para comunicarse, o que registre pulsaciones de teclas. Pero todas esas características juntas hacen que el proceso se pueda considerar como una amenaza y sea necesario un análisis en profundidad para poder autorizar la ejecución de manera segura.

Una vez infectado, ¿qué hacer?

A pesar de lo que viene diciéndose, los rootkits pueden eliminarse (aunque no tan fácilmente). Estos programas se autoprotegen escondiéndose y evitando que ningún otro proceso (como un antivirus) pueda detectarlos. Pero para que ese proceso pueda ocultarse, debe estar en funcionamiento y activado en memoria.

La mejor manera de evitar que el proceso entre en acción, es evitar el arranque del sistema operativo en el disco en el que se encuentra el rootkit, utilizando un disco diferente al del sistema infectado; como puede ser un CD. Así, si el rootkit es conocido, podrá eliminarse.

Sin embargo, si el rootkit no es conocido (es decir, que ha sido desarrollado específicamente para un sistema en concreto), cualquier antivirus fracasará. En este caso, el problema informático es casi el menos importante: hay una persona que, intencionadamente, quiere hacer daño a su empresa y se ha molestado en entrar en el sistema para perjudicarle.

Existen varias herramientas Anti-Rootkits totalmente gratuitas que puede descargar directamente desde Infospyware para comprobar su sistema en busca de estos.

Fuente: InfoSpyware

Virus en GNU/Linux: ¿Realidad o Mito?

agosto 4, 2012 Deja un comentario

Siempre que se forma el debate sobre los Virus y GNU/Linux no tarda en aparecer el usuario (normalmente de Windows) que dice:

En Linux no hay virus porque los creadores de estos programas malignos no pierden el tiempo en hacer algo para un Sistema Operativo que casi nadie usa”

A lo que yo siempre he contestado:

“El problema no es ese, sino que los creadores de estos programas malignos no perderán el tiempo en crear algo que será corregido con la primera actualización que haya del Sistema, incluso, en menos de 24 Horas”

 

 

Y no me equivocaba, como me lo ha demostrado este excelente artículo publicado en el Número 90 (Año 2008) de La Revista Todo Linux. Su autor David Santo Orcero nos brinda de forma técnica (pero fácil de entender) la explicación del por qué GNU/Linux carece de este tipo de Software malicioso.

100% recomendado. Ahora tendrán un material más que convincente para callar a todo aquel que hable sin una base sólida sobre este tema.

Descargar Artículo (PDF): Mitos y realidades: Linux y los virus

 

 

 

 

EDITADO:

Aquí tienen el artículo transcrito, pues consideramos que es mucho más cómodo de leer de esta forma:

========================================================================

El debate sobre Linux y los virus no es algo nuevo. Cada cierto tiempo vemos un correo en alguna lista preguntando si existen virus para Linux; y automáticamente alguien responde afirmativamente y alega que si no son más populares es porque Linux no está tan extendido como Windows. También son frecuentes las notas de prensa de desarrolladores de antivirus diciendo que sacan versiones contra los virus de Linux.

Personalmente he tenido alguna que otra discusión con distintas personas por correo, o por lista de distribución, respecto al tema de si existen o no los virus en Linux. se trata de un mito, pero es complejo derribar un mito o, mejor dicho, un bulo, especialmente si está causado por interés económico. A alguien le interesa transmitir la idea de que si Linux no tiene este tipo de problemas, es porque muy poca gente lo utiliza.

A la hora de publicar este reportaje me hubiese gustado elaborar un texto definitivo sobre la existencia de virus en Linux. Desgraciadamente, cuando la superstición y el interés económico campan a sus anchas, es difícil construir algo definitivo.
No obstante, intentaremos hacer aquí un argumentario razonablemente completo para desarmar los ataques de cualquiera que quiera discutirlo.

¿Qué es un Virus?

Lo primero, vamos a comenzar definiendo qué es un virus. se trata de un programa que se copia y se ejecuta automáticamente, y que tiene por objeto alterar el normal funcionamiento de un ordenador, sin el permiso o el conocimiento del usuario. Para ello, los virus reemplazan archivos ejecutables por otros infectados con su código. La definición es estándar, y es un resumen de una línea de la entrada sobre virus que aparece en la Wikipedia.
La parte más importante de esta definición, y la que diferencia el virus del resto del malware, es que un virus se instala solo, sin el permiso o conocimiento del usuario. si no se instala solo, no es un virus: podría ser un ser un rootkit, o un troyano.

Un rootkit es un parche al kernel que permite ocultar determinados procesos a las utilidades de área de usuario. Dicho de otra forma, es una modificación del código fuente del kernel que tiene como objeto que las utilidades que permiten ver qué se está ejecutando en cada momento no visualicen un determinado proceso, o un determinado usuario.

Un troyano es análogo: es una modificación al código fuente de un servicio concreto para ocultar determinada ac tividad fraudulenta. En ambos casos es necesario obtener el código fuente de la versión exacta instalada en la máquina Linux, parchear el código, recompilarlo, obtener privilegios de administrador, instalar el ejecutable parcheado, e inicializar el servicio –en el caso del troyano– o el sistema operativo completo –en el caso del
rootkit–. El proceso, como vemos, no es trivial, y nadie puede hacer todo esto “por error”. Tanto unos como otros exigen en su instalación que alguien con privilegios de administrador, de forma consciente, ejecute una serie de pasos tomando decisiones de índole técnica.

Lo cual no es un matiz semántico sin importancia: para que un virus se instale, basta con que ejecutemos un programa infectado como usuario común. Por otro lado, para la instalación de un rootkit o de un troyano es imprescindible que un humano malicioso entre personalmente en la cuenta de root de una máquina, y de forma no automatizada realice una serie de pasos que son potencialmente detectables. un virus se propaga con rapidez y eficiencia; un rootkit o un troyano necesitan que vayan específicamente a por nosotros.

La transmición de virus en Linux:

El mecanismo de transmisión de un virus, por lo tanto, es lo que realmente lo define como tal, y es la base de la existencia de los mismos. un sistema operativo es más sensible a los virus cuanto más fácil sea desarrollar un mecanismo eficiente y automatizado de transmisión de estos.

Supongamos que tenemos un virus que quiere transmitirse solo. Supongamosque ha sido lanzado por un usuario normal, de forma inocente, al lanzar un programa. Dicho virus tiene exclusivamente dos mecanismos de transmisión:

  • Replicarse tocando la memoria de otros procesos, anclándose a ellos en tiempo de ejecución.
  • Abriendo los ejecutables del sistema de ficheros, y añadiendo su código –payload– al ejecutable.

Todos los virus que podemos considerar como tales tienen al menos uno de estos dos mecanismos de transmisión. O los dos. No hay más mecanismos.
Respecto al primer mecanismo, recordemos la arquitectura de memoria virtual de Linux y cómo funcionan los procesadores intel. Estos poseen cuatro anillos, numerados de 0 a 3; a menor número, mayores los privilegios que tiene el código que se ejecute en dicho anillo. Estos anillos corresponden con estados del procesador, y, por lo tanto, con lo que se puede hacer con un sistema estando en un anillo concreto. Linux hace uso del anillo 0 para el kernel, y del anillo 3 para los procesos. no hay código de proceso que se ejecute en anillo 0, y no hay código de kernel que se ejecute en anillo 3. Solo hay un único punto de entrada al kernel desde el anillo 3: la interrupción 80h, que permite saltar del área donde está el código de usuario al área donde está el código de kernel.

La arquitectura de Unix en general y de Linux en particular no hace factible la dispersión de virus.

El kernel mediante el uso de la memoria virtual hace creer a cada proceso que tiene toda la memoria para él solo. Un proceso –que trabaja en anillo 3– solo puede ver la memoria virtual que le han configurado, por el anillo en el que opera. No es que la memoria de los otros procesos esté protegida; es que para un proceso la memoria de los otros está fuera del espacio de direcciones. Si un proceso diese una batida a todas las direcciones de memoria, no sería capaz ni de referenciar una dirección de memoria de otro proceso.

¿Por qué esto no se puede trampear?
Para modificar lo comentado –por ejemplo, generar puntos de entrada en anillo 0, modificar los vectores de interrupciones, modificar la memoria virtual, modificar la LGDT…– solo es posible desde el anillo 0.
Es decir, para que un proceso pudiese tocar la memoria de otros procesos o del kernel, debería ser el propio kernel. Y el hecho de que haya un único punto de entrada y que los parámetros se pasen por registros complica la trampa –de hecho, se pasa por registro hasta lo que se debe hacer, que se implementa luego como un case en la rutina de atención a la interrupción 80h–.
Otro escenario es el caso de sistemas operativos con cientos de llamadas no documentadas al anillo 0, donde esto sí es posible –siempre puede quedar una llamada olvidada mal implementada sobre la que se pueda desarrollar una trampa–, pero en caso de un sistema operativo con un mecanismo de paso tan simple, no lo es.

Por ello, la arquitectura de memoria virtual impide este mecanismo de transmisión; ningún proceso –ni siquiera los que tienen privilegios de root– tienen forma de acceder a la memoria de otros. Podríamos argumentar que un proceso puede ver el kernel; lo tiene mapeado a partir de su dirección de memoria lógica 0xC0000000. Pero, por el anillo del procesador en el que se ejecuta, no puede modificarlo; generaría un trap, ya que son zonas de memoria que pertenecen a otro anillo.

La “solución” sería un programa que modificara el código del kernel cuando es un fichero. Pero el hecho de que estos se recompilen, lo hace imposible. No se puede parchear el binario, ya que hay millones de kernels binarios distintos en el mundo. Simplemente con que al recompilarlo le hubiesen puesto o quitado algo al ejecutable del kernel, o le hubiesen cambiado el tamaño de alguna de las etiquetas que identifican la versión de compilación –algo que se hace incluso involuntariamente– el parche binario no se podría aplicar. La alternativa sería descargar el código fuente de Internet, parchearlo, configurarlo para el hardware apropiado, compilarlo, instalarlo y reiniciar la máquina. Todo esto lo debería hacer un programa, de forma automática. Todo un reto para el campo de la Inteligencia Artificial.
Como vemos, ni siquiera un virus como root puede saltar esta barrera. La única solución que queda es la transmisión entre ficheros ejecutables. Lo que tampoco funciona como veremos a continuación.

Mi experiencia como administrador:

En más de diez años que llevo administrando Linux, con instalaciones en cientos de máquinas de centros de cálculo, laboratorios de alumnos, empresas, etc.

  • Nunca me ha “entrado” un virus
  • Nunca he conocido a alguien que le haya ocurrido
  • Nunca he conocido a alguien que haya conocido a alguien que le haya ocurrido

Conozco a más gente que ha visto al monstruo del Lago Ness a que haya visto virus para Linux.
Personalmente, reconozco que he sido un temerario, y he lanzado varios programas que los autoprocramados “especialistas” denominan “virus para Linux” -en adelante, los denominaré virus, para no hacer pedante el texto-, desde mi cuenta habitual contra mi máquina, para ver si es posible un virus: tanto el virus bash que circula por ahí -y que, por cierto, no me infectó ningún fichero-, como un virus que se hizo muy famoso, y salió en la prensa. Intenté instalarmelo; y después de veinte minutos de trabajo, me rendí cuando vi que entre sus exigencias estaba tener el directorio tmp en una partición del tipo MSDOS. Personalmente, no conozco a nadie que cree una partición específica para tmp y la formatee en FAT.
De hecho, algunos supuestos virus que he probado para Linux necesitan un nivel de conocimientos altos y la clave de root para ser instalados. Podríamos calificar, cuanto menos, de “cutre” un virus si necesita nuestra intervención activa para que nos infecte la máquina. Además, en algún caso requieren amplios conocimientos de UNIX y la clave de root; lo que está bastante lejos de la instalación automática que se le supone.

Infectando ejecutables en Linux:

En Linux, un proceso puede hacer simplemente lo que le permita su usuario efectivo y su grupo efectivo. Es cierto que existen mecanismos para intercambiar el usuario real con el efectivo, pero poco más. Si nos fijamos donde están los ejecutables, veremos que solamente root tiene privilegios de escritura tanto en dichos directorios, como en los ficheros contenidos. Dicho de otro modo, solamente root puede modificar dichos archivos. Esto es así en Unix desde los 70, en Linux desde sus orígenes, y en un sistema de ficheros que soporte privilegios, aún no ha aparecido ningún error que permita otro comportamiento. La estructura de los ficheros ejecutables ELF es conocida y está bien documentada, por lo que es técnicamente posible que un fichero de este tipo cargue el payload en otro fichero ELF… siempre que el usuario efectivo del primero o el grupo efectivo del primero tengan privilegios de lectura, escritura y ejecución sobre el segundo fichero. ¿Cuántos ejecutables del sistema de ficheros podría infectar como usuario común?
Esta pregunta tiene una respuesta simple, si queremos saber a cuántos ficheros podríamos “infectar”, lanzamos el comando:

$ find / -type f -perm -o=rwx -o \( -perm -g=rwx -group `id -g` \) -o \( -perm -u=rwx -user `id -u` \) -print 2> /dev/null | grep -v /proc

Excluimos el directorio /proc porque es un sistema de ficheros virtual que muestra información sobre cómo funciona el sistema operativo. Los archivos de tipo fichero y con privilegios de ejecución que encontraremos no suponen un problema, ya que con frecuencia son enlaces virtuales que constan como que pueden leerse, escribirse y ejecutarse, y si un usuario lo intenta, nunca funciona. También descartamos los errores, abundantes –ya que, especialmente en /proc y en /home, hay muchos directorios donde un usuario común no puede entrar–.Este script tarda bastante. En nuestro caso particular, en una máquina donde trabajamos cuatro personas, la respuesta fue:

/tmp/.ICE-unix/dcop52651205225188
/tmp/.ICE-unix/5279
/home/irbis/kradview-1.2/src
/kradview

La salida muestra tres ficheros que podrían infectarse si se ejecutase un hipotético virus. Los dos primeros son ficheros de tipo Unix socket que se borran en arranque –y que no pueden verse afectados por un virus–, y el tercero es un fichero de un programa en desarrollo, que cada vez que se recompila se borra. El virus, desde el punto de vista práctico, no se propagaría.
Por lo que vemos, la única forma de propagar el payload es siendo root. En ese caso para que un virus funcione es necesario que los usuarios tengan siempre privilegios de administrador. En ese caso sí puede infectar archivos. Pero aquí viene la trampa: para transmitir la infección, necesita tomar otro ejecutable, mandarlo por correo a otro usuario que solamente emplee la máquina como root, y que repita el proceso.
En sistemas operativos donde es necesario ser administrador para tareas comunes o para ejecutar muchas aplicaciones diarias, esto sí se puede dar. Pero en Unix es necesario ser administrador para configurar la máquina y modificar los archivos de configuración, así que es escaso el número de usuarios que emplea como cuenta diaria la de root. Es más; algunas distribuciones de Linux ni siquiera tienen habilitada la cuenta de root. En casi todas, si accedes como tal al entorno gráfico, el fondo se cambia a rojo intenso, y se repiten mensajes constantes que recuerdan que no se debe emplear esta cuenta.
Finalmente, todo lo que se debe hacer como root es posible hacerlo mediante un comando sudo sin riesgo.
Por ello, en Linux un ejecutable no puede infectar a otros siempre que no estemos usando la cuenta de root como cuenta de uso común; y aunque las compañías antivirus se empeñan en decir que hay virus para Linux, realmente lo más parecido que se puede crear en Linux es un troyano en área de usuario. La única forma de que estos troyanos puedan afectar algo del sistema es ejecutándolo como root y con lo privilegios necesarios. Si solemos emplear la máquina como usuarios de a pie, no es posible que un proceso lanzado por un usuario común infecte al sistema.

Mitos y mentiras:

Encontramos una gran cantidad de mitos, bulos y simplemente mentiras sobre los virus en Linux. Hagamos una relación de los mismos basándonos en una discusión acontecida hace ya tiempo con un representante de un fabricante de antivirus para Linux que se ofendió mucho por un artículo publicado en esta misma revista.
Aquella discusión es un buen ejemplo de referencia, ya que toca todos los aspectos sobre los virus en Linux. Vamos a repasar todos estos mitos uno a uno según se comentaron en aquella discusión concreta, pero que tantas veces se ha repetido en otros foros.

Mito 1:
No todos los programas malignos, particularmente los virus, necesitan privilegios de root para infectar, sobre todo en el caso particular de los virus ejecutables (formato ELF) que infectan otros ejecutables”.

Respuesta:
Quien realice semejante afirmación desconoce cómo funciona el sistema de privilegios de Unix. Para poder afectar a un fichero, un virus necesita el privilegio de lectura –hay que leerlo para modificarlo–, y de escritura –hay que escribirlo para que la modificación sea válida– sobre el fichero del ejecutable que quiere ejecutar.
Esto es así siempre, sin excepciones. Y en todas y cada una de las distribuciones, los usuarios que no son root no disponen de estos privilegios. Luego simplemente con no ser root, la infección no es posible. Prueba empírica: En la sección anterior vimos un simple script para comprobar el rango de ficheros que pueden ser afectados por una infección. Si lo lanzamos en nuestra máquina, veremos como es ínfimo, y respecto a ficheros de sistema, nulo. Además, a diferencia de operativos como Windows, no es necesario tener privilegios de administrador para realizar tareas comunes con programas que emplean comúnmente usuarios normales.

Mito 2:
Tampoco necesitan ser root para entrar en el sistema por vía remota, es el caso de Slapper un gusano que explotando una vulnerabilidad en el SSL de Apache (los certificados que permiten comunicación segura), creó su propia red de máquinas zombie en septiembre de 2002”.

Respuesta:
Ese ejemplo no alude a un virus, sino un gusano. La diferencia es muy importante: un gusano es un programa que explota un servicio de cara a Internet para transmitirse. No afecta a programas locales. Por ello, solamente afecta a los servidores; no a máquinas particulares.
Los gusanos han sido siempre muy pocos y de incidencia ínfima. Los tres realmente importantes nacieron en los 80, una época en la que Internet era inocente, y todo el mundo se fiaba de todo el mundo. Recordemos que eran los que afectaban a sendmail, fingerd y rexec. Hoy en día la cosa es más complicada. Aunque no podemos negar que sigue habiéndolos y que, si no se controlan, son extremadamente peligrosos. Pero ahora, los tiempos de reacción ante los gusanos son muy cortos. Es el caso del Slapper: un gusano creado sobre una vulnerabilidad descubierta –y parcheada– dos meses antes de la aparición del propio gusano.
Aún suponiendo que todo el mundo que usara Linux tuviese Apache instalado y funcionando siempre, simplemente con actualizar mensualmente los paquetes hubiese sido más que suficiente para que nunca se corriera ningún riesgo.
Es cierto que el fallo de SSL que originó Slapper era crítico –de hecho, el mayor fallo encontrado en toda la historia de SSL2 y SSL3–, y como tal fue solucionado en pocas horas. Que dos meses más tarde de que se encontrara y se solucionara dicho problema, alguien hiciera un gusano sobre un error ya corregido, y que ese sea el ejemplo más potente que se puede dar como vulnerabilidad, cuando menos tranquiliza.
Como regla general, la solución a los gusanos no es comprar un antivirus, instalarlo y desperdiciar tiempo de cómputo manteniéndolo residente. La solución es hacer uso del sistema de actualizaciones de seguridad de nuestra distribución: teniendo la distribución actualizada, no habrá problemas. Ejecutar solamente los servicios que necesitamos es también una buena idea por dos razones: mejoramos el aprovechamiento de recursos, y evitamos problemas de seguridad.

Mito 3:
No creo que el núcleo sea invulnerable. De hecho existe un grupo de programas malignos denominados con las siglas LRK (Linux Rootkits Kernel), que se basan precisamente en que explotan vulnerabilidades de módulos del kernel y sustituyen los binarios del sistema”.

Respuesta:
Un rootkit es básicamente un parche al kernel que permite ocultar la existencia de determinados usuarios y procesos ante las herramientas habituales, gracias a que no aparecerán en el directorio /proc. Lo normal es que lo utilicen al final de un ataque, en primer lugar, van a explotar una vulnerabilidad remota para tener acceso a nuestra máquina. Después emprenderán una secuencia de ataques, para hacer escalado de privilegios hasta llegar a tener la cuenta de root. El problema cuando lo consiguen es cómo instalar un servicio en nuestra máquina sin ser detectados: ahí entra el rootkit. Se crea un usuario que será el usuario efectivo del servicio que queremos que se oculte, instalan el rootkit, y ocultan tanto dicho usuario como todos los procesos pertenecientes a dicho usuario.
De cómo ocultar la existencia de un usuario es útil a un virus es algo que podríamos discutir largamente, pero un virus que emplee un rootkit para instalarse parece divertido. Imaginemos la mecánica del virus (en pseudocódigo):
1) El virus entra en el sistema.
2) Localiza el código fuente del kernel. Si no está lo instala él mismo.
3) Configura el kernel para las opciones de hardware que procedan para la máquina en cuestión.
4) Compila el kernel.
5) Instala el nuevo kernel; modificando LILO o GRUB si es preciso.
6) Reinicia la máquina.

Los pasos (5) y (6) necesitan privilegios de root. Es algo complicado que los pasos (4) y (6) no sean detectados por el infectado. Pero lo divertido es que haya alguien que crea que existe un programa que puede hacer el paso (2) y (3) automáticamente.
Como colofón, si nos encontramos con alguien que nos dice “cuando haya más máquinas con Linux habrá más virus”, y nos recomienda “disponer de un antivirus instalado y actualizarlo constantemente”, posiblemente esté relacionado con la empresa que comercializa el antivirus y las actualizaciones. Desconfía, posiblemente sea el mismo dueño.

Antivirus para Linux:

Es cierto que existen antivirus para Linux buenos. El problema es que no hacen lo que los defensores de los antivirus argumentan. Su función es filtrar el correo que pasa de malware y virus para Windows, así como verificar la existencia de virus de Windows en carpetas exportadas vía SAMBA; con lo que si empleamos nuestra máquina como gateway de correo o como NAS para máquinas Windows, podemos protegerlas.

Clam-AV:

No terminaremos nuestro reportaje sin hablar del principal antivirus existente para GNU/Linux: ClamAV.
ClamAV es un potentísimo antivirus bajo GPL que compila para la mayor parte de los Unix disponibles del mercado. Está diseñado para analizar los adjuntos a los mensajes de correo que pasen por la estación y filtrarlos de virus.
Esta aplicación se integra perfectamente con sendmail para permitir el filtrado de los virus que puedan almacenarse en los servidores Linux que proveen de correo a las empresas; disponiendo de una base de datos de virus que se actualiza diariamente, con soporte a forma digital. La base de datos se actualiza varias veces al día, y es un proyecto vivo y muy interesante.
Este potente programa es capaz de analizar virus incluso en adjuntos en formatos más complejos de abrir, como pueda ser RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, MS Cabinet files, MS CHM (HTML COmprimido), y MS SZDD.
ClamAV soporta también mbox, Maildir, y archivos de correo en formato RAW, y ficheros Portable Executable comprimidos con UPX, FSG, y Petite. La pareja Clam AV y spamassassin son la pareja perfecta para proteger a nuestros clientes Windows desde los servidores de correo Unix.

 

CONCLUSIÓN

A la pregunta ¿Existen vulnerabilidades en sistemas Linux? la respuesta es ciertamente sí.
Nadie en su sano juicio lo duda; Linux no es OpenBSD. Otra cosa es la ventana de vulnerabilidad que tiene un sistema Linux que sea actualizado adecuadamente. Si nos preguntamos ¿existen herramientas para aprovechar estos agujeros de seguridad, y explotarlos? Pues también sí, pero eso no son virus, son exploits.

El virus debe saltar varias dificultades más que siempre se han puesto como un defecto/problema de Linux por los defensores de Windows, y que complican la existencia de virus reales –kernels que se recompilan, muchas versiones de muchas aplicaciones, muchas distribuciones, cosas que no pasan automáticamente de forma transparente al usuario, etc.–. Los teóricos “virus” actuales hay que instalarlos a mano desde la cuenta de root. Pero eso no puede ser considerado un virus.
Como siempre digo a mis alumnos: no me creáis, por favor. Descargad e instalaros un rootkit en la máquina. Y si queréis más, leed el código fuente de los “virus” que hay en el mercado. La verdad está en el código fuente. Es difícil a un “autoproclamado” virus seguir nombrándolo de esa forma después de leer su código. Y si no sabéis leer código, una única medida de seguridad sencilla que os recomiendo: usad la cuenta de root solo para administrar la máquina, y mantener al día las actualizaciones de seguridad.
Solamente con eso es imposible que os entren virus y muy poco probable que lo hagan gusanos o que alguien ataque vuestra máquina con éxito.

 

Fuente: Blogdesdelinux

Categorías:GNU/Linux, Noticias Etiquetas: ,