Understanding the Linux Backdoor: Implications for Open Source [When Penguins Cry]

Dave's Garage
4 Apr 202410:06

Summary

TLDREl video ofrece una discusión sobre una vulnerabilidad reciente en SSH que podría haber permitido a los atacantes acceder a cualquier sistema Linux. Dave, un ex ingeniero de sistemas operativos de Microsoft, explica cómo el backdoor funciona y sus implicaciones. Destaca que el problema fue detectado temprano gracias a un empleado de Microsoft que notó una anomalía en el tiempo de inicio de sesión de SSH. La discusión también aborda la ventaja de sistemas de código abierto frente a los de código cerrado en cuanto a la prevención de backdoors, y cómo los procesos de revisión y control de calidad en las empresas pueden ayudar a detectar y prevenir tales vulnerabilidades. Además, Dave comparte una anécdota de su tiempo en Microsoft donde un compañero de trabajo insertó un comando especial en el programa de copia que resultó en un incidente. El video concluye destacando la importancia de los procesos y controles en la prevención de vulnerabilidades en el software.

Takeaways

  • 🔑 Se ha detectado una vulnerabilidad en Linux que permite a los atacantes iniciar sesión en cualquier sistema Linux mediante una clave privada insertada en SSH.
  • 💥 Las implicaciones de esta 'puerta trasera' son catastróficas, dando acceso ilimitado a cualquier sistema Linux afectado sin necesidad de contraseña.
  • 🔍 El problema fue introducido en las versiones 5.60 y 5.61 del utils XZ, pero no se filtró a versiones estables de distribuciones como Ubuntu 20.04.
  • 🛠️ La puerta trasera no se detectó simplemente revisando el código fuente, sino que se insertó mediante datos binarios cifrados y comprimidos en el archivo Makefile de XZ utils.
  • 👀 La detección de este tipo de vulnerabilidades puede ser más difícil en proyectos de código abierto debido a la complejidad y oscuridad de los archivos Makefile.
  • 🌐 La difusión del problema fue rápida gracias a un empleado de Microsoft que notó un cambio anómalo en el tiempo de inicio de sesión de SSH durante sus pruebas.
  • 📚 La discusión sobre si el software de código abierto es más seguro que el de código cerrado surge como un punto de debate importante en este contexto.
  • 🏭 En el pasado, las prácticas de Microsoft incluyeban múltiples revisiones y pruebas antes de la liberación de cualquier cambio en un producto, lo que podría haber detectado y evitado este tipo de vulnerabilidades.
  • 👥 La responsabilidad y la revisión de los cambios de código por parte de los desarrolladores y mantenedores de proyectos de código abierto es crucial para prevenir este tipo de problemas.
  • 📖 El video también comparte una anécdota personal del narrador sobre un incidente de puertas traseras en un entorno de trabajo en Microsoft en 1993.
  • 💻 A lo largo de su carrera y en más de 30 años en el desarrollo de sistemas operativos, el narrador no ha conocido ningún caso de una puerta trasera en Windows.

Q & A

  • ¿Qué vulnerabilidad de SSH fue mencionada en el video?

    -Se mencionó una vulnerabilidad de back door en Linux que permite a un atacante iniciar sesión en cualquier sistema Linux con SSH.

  • ¿Cómo funciona la vulnerabilidad SSH en Linux?

    -La vulnerabilidad consiste en que se ha insertado una clave privada en el código de SSH, lo que permite a cualquiera con la clave pública correspondiente iniciar sesión sin necesidad de una contraseña y con acceso root.

  • ¿Cómo se insertó la clave pública en el proceso de compilación de SSH?

    -Los atacantes insertaron datos binarios cifrados y comprimidos en el archivo makefile de XZ utils, que se descifra y inserta en el proceso de compilación sin modificar el código fuente.

  • ¿Por qué no fue fácil detectar la vulnerabilidad por medio de la revisión del código fuente?

    -Como los datos se insertaron a través del makefile y no se modificaron los archivos de código fuente, los cambios no son evidentes y requieren una revisión minuciosa del makefile, que a menudo es complejo y difícil de seguir.

  • ¿Qué versión de XZ utils estaba afectada por esta vulnerabilidad?

    -Las versiones 5.60 y 5.61 de XZ utils estaban afectadas por la vulnerabilidad.

  • ¿Cómo fue descubierto el back door en SSH?

    -Un empleado de Microsoft que trabajaba en la base de datos Postgres notó que los tiempos de inicio de sesión de SSH se alargaron y, tras investigar, descubrió la vulnerabilidad.

  • ¿Qué ventaja tiene un sistema de código abierto sobre uno de código cerrado en términos de seguridad?

    -Un sistema de código abierto permite a una comunidad más amplia revisar y auditar el código, lo que podría detectar vulnerabilidades más rápidamente. Sin embargo, esto también depende de que haya suficiente escrutinio de los cambios en el código y los procesos de compilación.

  • ¿Cómo podría haberse detectado la vulnerabilidad en un entorno de desarrollo más estructurado como el de Microsoft?

    -En entornos estructurados, los cambios en el código pasan por un proceso de revisión manual, pruebas de verificación básicas y benchmarks que podrían detectar cambios en el rendimiento o en la funcionalidad, como el impacto en el tiempo de inicio de sesión de SSH.

  • ¿Por qué el proceso de integración continua y entrega continua (CI/CD) es importante en el desarrollo de software?

    -El proceso CI/CD ayuda a detectar problemas temprano en el ciclo de desarrollo al realizar pruebas y verificaciones constantes, lo que asegura la calidad y la seguridad del software antes de su entrega.

  • ¿Qué implicaciones tiene una vulnerabilidad como la mencionada en la confianza de los usuarios en el sistema operativo?

    -Una vulnerabilidad de back door puede erosionar la confianza de los usuarios en el sistema operativo, ya que pone en riesgo la seguridad y la privacidad de sus datos y operaciones.

  • ¿Cómo se podría mejorar la seguridad en el proceso de desarrollo de software?

    -Se podría mejorar la seguridad mediante la implementación de revisiones más rigurosas de los cambios en el código, la utilización de herramientas de análisis estático y dinámico, y la promoción de un ambiente donde los desarrolladores y revisores sean conscientes de las prácticas de seguridad.

Outlines

00:00

😀 SSH Vulnerabilidad Backdoor en Linux

El video comienza hablando de una vulnerabilidad backdoor en Linux que permitiría a un atacante iniciar sesión en cualquier sistema Linux. Se discute qué implica esto y cómo funciona. Además, se explora la cuestión de si el software de código abierto es más seguro que el de código cerrado. Se menciona que el backdoor se insertó en una versión reciente del software XZ utils y que solo afectaría a quienes utilicen versiones de vanguardia. La vulnerabilidad fue detectada por un empleado de Microsoft que notó que los tiempos de inicio de sesión de SSH se habían vuelto más lentos. La discusión destaca la importancia de la revisión del código y los procesos de construcción en la detección de vulnerabilidades.

05:01

🤔 ¿Código Abierto vs Cerrado en la Prevención de Backdoors?

Se cuestiona si un sistema de código abierto o uno de código cerrado es más protector contra este tipo de backdoors. Se argumenta que el hecho de que el código fuente sea abierto no es relevante si no hay una revisión cuidadosa del código de compilación y los makefiles. Se compara con el proceso de lanzamiento de Windows NT, donde el código pasa por varios procesos de verificación antes de compilar. Aunque no hay garantías, estos procesos pueden detectar muchos problemas. Se destaca que la vigilancia y la responsabilidad de los desarrolladores son clave para prevenir la introducción de backdoors.

10:02

👋 Despedida y Llamado a la Acción

El video concluye con un llamado a la acción para que los espectadores den like y se suscriban si encuentran el contenido informativo o entretenido. También se menciona un libro gratuito del presentador sobre autismo en Amazon.

Mindmap

Keywords

💡Linux

Linux es un sistema operativo de código abierto que se utiliza ampliamente en servidores, dispositivos embebidos y computadoras personales. En el video, se discute una vulnerabilidad recientemente descubierta en Linux, que podría permitir a un atacante obtener acceso no autorizado a sistemas que utilicen esta vulnerabilidad.

💡SSH (Secure Shell)

SSH es un protocolo de red que permite a los usuarios acceder de forma segura a una máquina remota y ejecutar comandos como si estuvieran físicamente presentes en ella. En el contexto del video, se menciona que la vulnerabilidad de Linux se relaciona con SSH, y cómo un 'back door' podría permitir el acceso sin necesidad de una contraseña.

💡Back door

Un 'back door' en informática es una puerta trasera intencionalmente insertada en un sistema o programa que permite a un atacante acceder de manera no autorizada. En el video, se destaca cómo un back door fue insertado en la versión de SSH de Linux, lo que podría haber tenido consecuencias catastróficas si no se hubiera detectado a tiempo.

💡XZ Utils

XZ Utils es un conjunto de herramientas de compresión de archivos que se utilizan en sistemas Linux. En el video, se indica que el back door fue insertado a través de un cambio en el código de XZ Utils, específicamente en las versiones 5.60 y 5.61, afectando así a SSH.

💡Makefile

Un Makefile es un archivo que contiene instrucciones para el sistema de compilación 'make', el cual automatiza el proceso de compilación de software. En el video, se describe cómo el back door fue introducido a través de un Makefile, insertando datos binarios cifrados y comprimidos que luego se descifran y compilan en el proceso de construcción.

💡Nation-state

Un 'nation-state' se refiere a un país o estado con un gobierno reconocido. En el video, se sugiere que un atacante con la capacidad de un estado podría haber utilizado la vulnerabilidad de Linux para acceder a servidores de forma no autorizada.

💡Root access

El 'root access' es el nivel más alto de privilegios en un sistema operativo, que permite al usuario realizar cambios y operaciones sin restricciones. En el video, se menciona que la vulnerabilidad de SSH proporcionaría acceso root a cualquier sistema afectado.

💡Open source

El 'open source' se refiere a un modelo de desarrollo de software donde el código fuente está disponible para la comunidad para que pueda ser estudiado, modificado y mejorado. En el video, se debate si el software de código abierto, como Linux, es más o menos seguro que el software de código cerrado en términos de vulnerabilidades y back doors.

💡Closed source

El 'closed source' o 'software propietario' es el modelo opuesto al open source, donde el código fuente del software no está disponible públicamente y es propiedad exclusiva del desarrollador o empresa. En el video, se compara la seguridad de los sistemas de código cerrado con los de código abierto.

💡Microsoft

Microsoft es una multinacional de tecnología que desarrolla, manufactures, licencia y soporta una amplia gama de software, dispositivos electrónicos y servicios. En el video, se hace referencia a Microsoft como ejemplo de un proceso de desarrollo de software más estructurado y controlado, que podría haber detectado la vulnerabilidad antes de su propagación.

💡Benchmarking

El 'benchmarking' es el proceso de evaluación del rendimiento de un sistema o componente mediante la comparación con estándares o con el rendimiento de otros sistemas. En el video, se menciona que un empleado de Microsoft que realizó benchmarking en una base de datos detectó una anomalía en los tiempos de inicio de sesión SSH, lo que llevó al descubrimiento del back door.

Highlights

SSH vulnerability back door has been inserted into Linux systems.

The back door allows an attacker with a private key to log into any affected Linux system without a password.

The exploit provides root access to the compromised system.

The vulnerability was introduced through XZ utils in versions 5.60 and 5.61.

The exploit did not modify the source code but injected encrypted binary data via the make file.

The malicious code was not immediately obvious and went undetected in the source code review.

The exploit was discovered by a Microsoft employee performing tests on the Postgres database.

The incident raises questions about the security of open-source versus closed-source systems.

Open-source systems rely on community scrutiny, which may not catch every vulnerability.

Closed-source systems like Windows NT undergo rigorous testing and verification before release.

The process at Microsoft involves manual review and automated testing to ensure no performance regression.

The speaker shares a personal story of an intern inserting a humorous 'back door' in MS DOS 6.2.

The humorous back door was caught during a manual source code change review at Microsoft.

To the speaker's knowledge, no back doors have been officially inserted into Windows.

The importance of processes and checks in preventing unauthorized code changes.

The role of luck in maintaining system security, alongside rigorous processes.

The necessity for assigned roles to review code changes and be responsible for their outcomes.

Transcripts

00:00

so I don't want to scare you but did you

00:01

know that somebody checked a back door

00:02

into Linux that allows the attacker to

00:04

log into any Linux system I'll tell you

00:07

about that and I'll also tell you about

00:09

the time somebody tried to check a back

00:10

door into Ms Doss and did it from my

00:13

office that's a cool

00:14

[Music]

00:21

story hey I'm Dave welcome to my shop

00:24

I'm Dave plumber retired operating

00:26

systems engineer from Microsoft going

00:27

back to the MSDS and Windows 95 days and

00:30

today we're going to talk about the new

00:32

SSH vulnerability back door that's been

00:34

inserted into Linux what it means how it

00:36

works and what the implications are and

00:38

whether open source is any better off

00:39

than closed source and these types of

00:41

scenarios first off obviously I'm not a

00:43

Linux developer I mean I write code for

00:45

Linux but I've never contributed at

00:46

least not since about 1993 when I

00:49

checked in a bugfix to was it Minix I

00:51

think it was early Linux um or email the

00:54

I should say but suffice to say I'm not

00:56

a Linux contributor or developer so

00:57

while I may not be a Linux expert that's

00:59

probably good for you right now cuz I

01:01

have to explain things in terms that I

01:02

understand which means you will likely

01:04

understand them as well so before we

01:06

look at what happened first what are the

01:08

implications what does this back door do

01:10

somebody checked in some code and it

01:12

looks for a private key and it has a

01:14

public key built into SSH and what are

01:16

the implications well to put it simply

01:22

catastrophic had this not been detected

01:24

as early as it was it would have been

01:26

truly catastrophic for Linux because

01:28

let's say that this this is a nation

01:30

state what they've done is they've built

01:32

a backdoor private key into SSH that

01:35

anybody with the public key or actually

01:37

vice versa they put the public key in

01:38

the product and then they hold the

01:39

private key anybody who holds that

01:41

private key and only that person nobody

01:43

else can use this exploit I should be

01:45

clear about that only if you hold the

01:47

private key which the original person

01:48

who inserted the back door does then you

01:51

can connect to any Linux server with

01:53

this back door inserted in fact you

01:55

don't need a password you just need to

01:56

connect by SSH and the SSH server will

01:58

say hey you've got the right private key

02:00

in your metadata or whatever extra data

02:02

is sent along with login request it

02:04

matches that logs you right in basically

02:07

not only a completely open door it's

02:09

even better than that because it gives

02:10

you root access

02:15

I that side of it's a little more

02:16

technical but suffice to say the result

02:19

is that you get unfettered access to any

02:21

Linux system in the world that you want

02:23

that's running this exploit and you get

02:25

rud access so how' they do it well what

02:27

they did is they checked code into XZ

02:29

utils and when I'm saying they I'm

02:32

talking about one of the main developers

02:34

of the XZ utils the good news is this is

02:36

in 5.60 and 5.61 versions of the XD

02:39

utils and that's pretty much bleeding

02:41

edge it did make it into a few very

02:43

early drops of dros but not it's not

02:46

going to be like in 20.04 won't be

02:47

picked up immediately or anything into

02:49

there so if you're not running on the

02:51

bleeding edge long story short you're

02:53

probably

02:54

safe but surely you can't put a price on

02:57

your login safety I wouldn't have

02:59

thought so either but here we are so

03:01

they checked code into xzu tills that

03:03

long story short bakes the public key

03:06

into SSH and then accepts connections

03:07

from anybody with the private key but

03:10

wouldn't that be obvious it seems like

03:11

this should be obvious and easy to

03:13

detect just by reviewing the source code

03:15

change logs but in fact it's not because

03:17

they were very clever about how they did

03:19

it they didn't modify the source code at

03:21

all instead they injected encrypted and

03:24

compressed binary data that is decrypted

03:26

and then inserted into the build process

03:28

via the make file for the XZ tills if I

03:31

understand it correctly but this means

03:33

there's no changes to the code so

03:35

anybody reviewing the source code

03:36

changes doesn't see any change and who

03:39

reads make file changes I mean they're

03:40

pretty obtuse and opaque to begin with

03:42

and if you have any idea what a make

03:44

file is doing it's either a simple make

03:45

file or you're having a really good day

03:47

because a lot of make files are pretty

03:49

complex and hard to follow once you get

03:51

to a certain complexity of a project so

03:53

at this point we've got a back door in

03:54

the Linux source code and all we have to

03:56

do or all they have to do is wait for it

03:58

to be propagated through out all the

04:00

builds and dros and trickle down

04:02

everybody and if it doesn't get caught

04:03

before that boom hey by the way one

04:07

thing I've noticed lately on YouTube is

04:08

that people are like bang ending their

04:10

videos immediately and I guess this must

04:12

appease the algorithm in some way so I'm

04:14

going to do that today which means if

04:16

I'm going to tell you the stuff that I

04:17

tell you at the end of every episode I

04:18

have to tell you now like halfway

04:20

through so here it is I'm mostly in this

04:22

for the subs and likes so if you're

04:23

finding today's episode to be any

04:25

combination of informative or

04:26

entertaining please leave me one of each

04:28

before you go today and if you or

04:30

anybody you know is on the Spectrum then

04:32

please check out the free sample of my

04:34

book on Amazon where I tell you

04:35

everything I know about autism that I

04:37

wish I'd know in way back then so who

04:39

caught it

04:41

Microsoft well not really Microsoft guy

04:43

that works for Microsoft also happens to

04:46

do benchmarking and so on on the postgis

04:49

database and he was running his tests

04:51

and he noticed that the SSH logins were

04:53

taking a lot longer than they used to

04:54

and this happened all of a sudden so he

04:57

dug into it and he's the hero that found

04:59

the information and the back door and

05:00

published it and let us all know about

05:02

it so had it not been for that this

05:04

would have likely been uncaught now of

05:07

course this promps the bigger question

05:08

of which is more protective against this

05:10

type of back door an open source system

05:12

or a closed Source system and I'd say in

05:15

this case the source code actually isn't

05:17

all that relevant of course it's open

05:19

but so is the make file was anybody

05:21

really scrutinizing the make file and if

05:22

they had would they have caught it if

05:24

they looked at it carefully well nobody

05:26

even at Microsoft is probably hand

05:28

reviewing and scrutinizing the make

05:29

build code changes unless they cause a

05:31

problem if they slow things down they're

05:34

going to take a look at it but if you

05:35

make changes to the make file and the

05:37

binary pops out then everything is cool

05:39

it's probably not going to get that much

05:40

scrutiny unlike a change to the actual

05:42

source code that's going to go through

05:43

several layers of review and approval

05:46

and again I've been gone for Microsoft

05:47

20 years so I'm talking about how we did

05:49

it back 20 years ago which was probably

05:50

pretty sloppy and lazy and horrible

05:52

compared to what they're doing now but

05:54

here's the beauty of a regimental

05:56

commercial release with something like

05:57

Windows NT you don't just check in code

06:00

and then wait for it to show up in the

06:01

build it goes through a lot of processes

06:03

in between first there's a build lab

06:05

that picks up just your change build

06:06

your change independently builds a build

06:08

with your change kicks that out and it

06:11

goes through basic build and when all

06:13

the changes are collected for the day

06:14

that build will go through bvts or basic

06:17

verification tests and that's going to

06:18

check to make sure that all the normal

06:20

stuff works the smoke tests pass the

06:22

build boots does everything correctly

06:24

and that the performance is not

06:25

seriously degraded from previous builds

06:27

and that's how it would have been caught

06:28

early at Microsoft because the

06:29

significant impact to the login chain

06:32

would have caused the regression in when

06:33

log on if it were you know the

06:35

equivalent component in Windows and that

06:37

would have been detected immediately now

06:40

that's not to say that every such change

06:42

would be so it's not a golden guarantee

06:44

or anything but the fact that any change

06:47

to the product goes through both human

06:48

manual review of the textual changes to

06:50

the source code and then through a bunch

06:52

of verification tests and benchmarks and

06:54

several other verification tests that

06:56

make sure the functionality and the

06:58

performance hasn't regressed that

07:00

catches a lot of things it still won't

07:02

catch everything be clear on that so

07:04

there is no Panacea now the other thing

07:06

is when you're checking into code say

07:07

I'm checking into the heat manager well

07:09

the guy who write wrote The Heat manager

07:11

and the person who maintains the heat

07:12

manager is going to very carefully check

07:15

my changes when you get something like

07:16

exz utils I think there was only two

07:18

people working on it so did the other

07:19

person really vet these changes very

07:21

carefully or did lonus you know get out

07:23

of his computer and check every line I

07:25

doubt that so who is actually vetting

07:27

these changes as they go into the build

07:28

and the answer is I don't know because

07:30

I'm not involved in that process so I

07:32

can't really speak to what goes on

07:34

behind the scenes in Linux I can only

07:36

tell you what used to happen in Windows

07:38

how that you extrapolate that forward

07:39

and assume they're more careful now and

07:41

the protective aspects of that now the

07:43

difference is if it's in a part of Linux

07:44

that a lot of people care about a lot of

07:46

people are going to look at it but if

07:47

it's in a part of Linux that a lot of

07:48

people don't care about like xzu tills

07:51

then it's probably not going to get the

07:52

scrutiny that it deserves especially

07:54

when you see the implications of how

07:55

this change manifests so now a bit of my

07:58

own back door stories

08:00

when I was an intern in 1993 I was in MS

08:02

DOS working on MS DOS 6.2 where I worked

08:05

on Smart drive and highe and some of the

08:07

compression engine relocation disc copy

08:11

setup whole bunch of stuff and there was

08:13

a guy in my office that was also an

08:14

intern so we shared an office because we

08:16

were just interns and he decided that he

08:19

was working I believe on the copy

08:20

command and he took the opportunity to

08:22

check not a back door per se but a

08:24

special command line switch so instead

08:26

of you know how with x copy SLS we'll do

08:29

folder

08:30

well with copy he added it so that slart

08:33

which is like asky 254 I forget the

08:35

actual OEM code page at this moment but

08:38

whatever it was he used a special

08:40

graphic character and he made that a

08:41

command line switch and it would just

08:42

print I love sex over and over and over

08:44

and over and over and it would print

08:45

that out I didn't know anything about

08:47

this and then after I'm done my

08:49

internship I get a call from my manager

08:51

at the time who calls me at home and

08:52

says yeah so what did you know about

08:54

this and the answer was I knew nothing

08:57

and uh naturally they did not invite get

08:59

the guy back it was caught in the manual

09:01

source code Change review that I spoke

09:02

of earlier or however they caught it and

09:05

it did not look good for him I don't

09:06

know what the repercussions were I don't

09:08

know what they did I wasn't involved all

09:10

I know is that they took me at my word

09:12

that I wasn't involved and thankfully

09:13

for that because I want up working on

09:15

Microsoft for a long time and I don't

09:17

know if I would have hired me after that

09:18

little incident in my office did I

09:20

really not know about it I didn't so now

09:23

in all my time at Microsoft and in the

09:24

two decades since over this course of 30

09:27

years of Windows and Ms Doss to my

09:29

knowledge there has never been a back

09:30

door inserted into Windows now it's

09:33

possible that one has and it's just

09:34

never been found but I would assume that

09:36

by now there would be some exploit that

09:38

would take advantage of it is that

09:39

diligence process Superior coding or

09:41

pure luck well I'm going to guess a lot

09:43

of it's luck but a lot of it is process

09:46

doesn't mean the developers are any

09:47

smarter it does mean that people have

09:49

day jobs where they are assigned to look

09:50

at code changes in other people's

09:52

products whether they want to or not

09:54

then they are responsible for anything

09:55

that happens as a result of those

09:56

changes and that makes people pretty

09:58

honest and as for the people that aren't

10:00

honest there are processes and checks

10:02

and balances to make sure they don't do

10:04

a lot of harm thanks for joining me see

10:06

you

Rate This

5.0 / 5 (0 votes)

Etiquetas relacionadas
Seguridad InformáticaVulnerabilidad SSHLinuxCódigo AbiertoCódigo CerradoMicrosoftIngeniería de SoftwareRevisión de CódigoBackdoorSSHBenchmarking