– Letras bilingües Inglés/Español

Letras y Traducción

[Español]

Hola, soy Craig Rowland, fundador de Sandfly Security.

Hoy les voy a hablar sobre una forma muy poco conocida

de acceder a SSH mediante claves autorizadas.

Esto se hace a través del archivo authorized_keys2.

Muchos saben que si editan el archivo authorized_keys

de un usuario en SSH, pueden añadir su clave pública

y eso les permite acceder al host.

Pero lo que mucha gente desconoce es

que existe un archivo obsoleto llamado authorized_keys2,

con un número 2 al final.

Si colocan su clave ahí, muchas versiones antiguas

de SSH les permitirán iniciar sesión en ese host

y autenticarse con esa clave.

De esta manera, evitan ponerla

en el archivo authorized_keys convencional.

¿Por qué alguien haría esto?

Básicamente porque la mayoría busca el archivo

authorized_keys, y muy pocos conocen

la existencia del archivo authorized_keys2.

Así que es una forma de ocultar una puerta trasera

en un sistema que podría evadir los mecanismos de detección estándar.

Permítanme mostrarles a qué me refiero

con esto en el sistema Sandfly.

Sandfly es un producto de detección y respuesta

en endpoints sin agentes para Linux.

Podemos monitorear Linux sin instalar agentes en los equipos.

También rastreamos claves SSH, auditoría de contraseñas,

detección de cambios y mucho más.

Pero para hoy, lo que hice fue escanear un sistema

y en él identificamos una alerta.

La alerta que detectamos para la demostración de hoy

es que marcamos al usuario admin porque tiene

un archivo SSH authorized_keys2 presente

en su directorio SSH.

El nombre del archivo authorized_keys2 es una alternativa

que utiliza SSH para las claves autorizadas y, si está habilitado,

puede permitir a los usuarios acceder al host sin listar sus claves

en el archivo estándar authorized_keys.

Básicamente, esto significa que hay dos formas

de que una clave pública sea reconocida por el

demonio SSH en muchos sistemas, especialmente en versiones antiguas de Linux.

of especially older versions of Linux.

Cuando miramos aquí nuestros datos de resultados en bruto,

veo la información sobre ese usuario, el archivo en cuestión

see the file here in question and I can see

y la ruta completa donde encontramos esa clave SSH.

Cambiemos a la terminal para explorar esto un poco más.

En la terminal, estoy en el directorio principal. Voy a entrar

al directorio del usuario admin y luego a .ssh.

to the admin directory and I'm going to go to .ssh

Ejecuto "ls -al" y noten algo aquí:

authorized_keys2.

Exacto, lo que esto significa es que, básicamente,

se espera encontrar el archivo authorized_keys.

Si leo este archivo, el formato es idéntico

al de un authorized_keys estándar.

De hecho, podría ejecutar el archivo authorized_keys

y este archivo al mismo tiempo.

Así que puedes tener dos lugares

donde guardar una clave.

Pero lo importante aquí es que si inicio sesión en ese sistema

usando SSH, voy a usar una clave privada.

Voy a entrar como admin.

Y, como ven, he accedido a la terminal.

No hay un archivo authorized_keys aquí.

Noten que es authorized_keys2.

Eso es lo que realmente lo activó.

Ahora, hay un par de cosas más interesantes aquí.

Permítanme limpiar esto.

things here that are interesting.

Si reviso el archivo de configuración

de SSH y bajo un poco...

Vean, aquí dice que se espera que SSH ignore

authorized_keys2 por defecto en el futuro.

De hecho, las versiones más recientes de OpenSSH

de los últimos años ignoran este archivo.

Pero la configuración por defecto aquí es no ignorarlo.

Y ven que aquí está comentado,

pero aun así considerará ese archivo como legítimo.

Así que esto es una forma muy astuta

de mantener una clave oculta.

Ahora, si volvemos a Sandfly, les mostraré algo más interesante.

De hecho, también identificamos esto

a través de nuestro "SSH hunter".

Probablemente sea mucho para cubrir en este video,

pero lo veremos en videos futuros.

Pueden verlo en nuestro canal.

Marcamos esto como una zona de seguridad SSH interna

y obtuvimos una violación que muestra que este sistema

tiene un usuario que ha añadido una clave.

Nuevamente, puedo ver quién es ese usuario, es admin.

Veo que añadió una clave y que está presente

en el archivo authorized_keys2.

Puedo ver todo sobre quién usa esa clave,

a qué host tienen acceso, y demás.

Pero lo principal es entender lo del archivo authorized_keys2.

Básicamente, si veo a un usuario usando este archivo,

asumiría que no tiene buenas intenciones.

Y les aconsejo encarecidamente que hagan lo mismo.

No hay razón por la que alguien deba usarlo hoy,

salvo para evitar ser detectado.

Y si están tratando de evitar la detección,

deben averiguar por qué decidieron hacerlo.

Pero es muy probable que si están usando ese archivo,

no sean amigables y deberían hacer preguntas serias.

Soy Craig Rowland de Sandfly Security.

Muchas gracias por ver este video.

Echen un vistazo a nuestros otros videos

para más consejos sobre análisis forense en Linux,

detección de intrusiones y análisis.

Agradezco su tiempo.

Gracias de nuevo y adiós.

Thanks so much for watching this video.

Check out our other videos as well for

more Linux forensics, intrusion detection and analysis tips.

I appreciate your time.

Thanks again and goodbye.

[Inglés]

Hi, I'm Craig Rowland, founder of Sandfly Security.

Today I'm going to tell you about a very

little known way to access SSH with authorized keys.

And this is called the authorized_keys2 file.

Now, many of you are aware that if you edit the authorized_keys

file for SSH for a user, you can add your public

key to it and that allows you access to the host.

But what many people don't know about is

there is a deprecated file called authorized_keys2, just

the number 2 on the end of it.

And if you put your key in there, many

older versions of SSH will allow you to log

into that host and authenticate with that key.

And this way you avoid putting

it into the authorized_keys file.

Now why would you do this?

Basically because most people look for

authorized_keys, very few people know

about the authorized_keys2 file.

So this is a way to hide backdoor access onto

a system that might evade standard detection search mechanisms.

So let me show you what I

mean by that in the Sandfly system.

In Sandfly, it's an agentless endpoint

detection and response product for Linux.

We can monitor Linux without deploying endpoint agents.

We also track SSH keys, password

auditing, drift detection, a lot more.

But for today, what I did is I scanned a

system here and on this system we identified one alert.

And the alert here that we identify for today's

demonstration is that we flag the user admin and

we set the user admin has an SSH authorized_keys2 file

present in their SSH directory.

The authorized_keys2 file name is an alternate name

for SSH to use for authorized keys and if enabled,

can allow users to access the host without listing keys

in the standard authorized_keys file.

Basically what this means is that there's two ways

to get a public key to get recognized by

SSH daemon on a lot of systems, a lot

of especially older versions of Linux.

And when we look here at our raw result data,

I see the information about that user and I could

see the file here in question and I can see

the full path of where we found that SSH key.

So let's switch to the terminal so we can explore

this a little bit more. On the terminal itself,

I'm now in the main directory here. I'm going to go

to the admin directory and I'm going to go to .ssh

and I do an "ls -al" and notice something here:

authorized_keys2

Right, so what does this mean is

basically you're expected to see authorized_keys.

If I cat out this file it has an identical layout to it.

That's a standard authorized_keys.

In fact, I could run the authorized_keys

file and this file at the same time.

So that way you can have two

places to have a key in there.

But the thing to understand here is that if I

log in to that system, I'm going to SSH in,

I'm going to use a private key here.

I'm going to add log into that box as admin.

And you see here that I dropped in to a shell.

There is no authorized_key file here.

See that it's authorized_keys2.

This is what actually activated it.

Now there's a couple more

things here that are interesting.

Let me clear this out here.

If I do a look at the config file

for SSH and I scroll down here a bit.

Let's see here it is here it says expect SSH authorized_keys2

to be disregarded by default in the future.

And in fact later versions OpenSSH over the past

couple of years do in fact ignore this file.

But the default here is not to ignore it.

And you see here this is actually commented out,

but it still will view that file as legitimate.

So this is actually something that's a very sneaky

way again to keep a key lying around.

Now if we go back over here to the

Sandfly, I'll show you something else that's interesting

on this. Is that we actually did identify this

through our SSH hunter as well.

Probably too much to get into this video here, but

we'll get into it in other videos in the future.

You can see on our channel.

But we marked this as an internal SSH security zone

and we did get a violation showing that this system

here has a user on it that's added a key.

And again I can see who that user

is over here I can see it's admin.

I can see here they added a key and again that

key is present in the authorized_keys2 file here.

And again I could see everything about who's using that

key, what host they have access to, and so on.

But the main thing here to

understand authorized_keys2 file.

Basically, if I were to see a user using this

file, I would assume they're up to no good.

And I strongly advise you to do the same thing.

There's no reason why people should be

using it today except to avoid detection.

And if they're trying to avoid detection,

if they're friendly, you should find out

why they've decided to do it.

But odds are very high if they're using that

file that they're not going to be friendly and

you should be asking some serious questions.

So I'm Craig Rowland from Sandfly Security.

Thanks so much for watching this video.

Check out our other videos as well for

more Linux forensics, intrusion detection and analysis tips.

I appreciate your time.

Thanks again and goodbye.

Vocabulario clave

Vocabulario	Significados
founder /ˈfaʊndər/ B2	noun - fundador
authorized /ˈɔːθəraɪzd/ B2	adjective - autorizado
deprecated /ˈdɛprəkeɪtɪd/ C2	adjective - obsoleto
authenticate /ɔːˈθɛntɪkeɪt/ C1	verb - autenticar
backdoor /ˈbækdɔːr/ B2	noun - puerta trasera
evade /ɪˈveɪd/ C1	verb - evadir
detection /dɪˈtɛkʃən/ B2	noun - detección
agentless /ˈeɪdʒəntləs/ C1	adjective - sin agente
monitor /ˈmɒnɪtər/ B2	verb - monitorizar
auditing /ˈɔːdɪtɪŋ/ B2	noun - auditoría
demonstration /ˌdɛmənˈstreɪʃən/ B2	noun - demostración
alternate /ˈɔːltərnət/ B2	adjective - alternativo
identical /aɪˈdɛntɪkəl/ B2	adjective - idéntico
disregarded /ˌdɪsrɪˈɡɑːrdɪd/ C1	verb - ignorado
legitimate /lɪˈdʒɪtɪmɪt/ C1	adjective - legítimo
sneaky /ˈsniːki/ B2	adjective - furtivo
violation /ˌvaɪəˈleɪʃən/ B2	noun - violación
forensics /fəˈrɛnsɪks/ C1	noun - forense

Estructuras gramaticales clave

• Today I'm going to tell you about a very little known way to access SSH with authorized keys.

  ➔ Futuro próximo (be going to)

  ➔ Usamos "be going to" para expresar una acción planificada o intención para el futuro cercano.

• Many of you are aware that if you edit the authorized_keys file, you can add your public key to it.

  ➔ Condicional tipo 1 (if + presente, will/can + infinitivo)

  ➔ La cláusula "if" establece una condición y la cláusula principal indica el resultado usando un verbo modal.

• There is a deprecated file called authorized_keys2, just the number 2 on the end of it.

  ➔ Estructura existencial 'there is'

  ➔ Use "there is" para indicar la existencia o presencia de algo en una ubicación específica.

• This is a way to hide backdoor access that might evade standard detection.

  ➔ Verbo modal de posibilidad (might)

  ➔ Usamos "might" para expresar que algo es un resultado posible, indicando incertidumbre.

• We can monitor Linux without deploying endpoint agents.

  ➔ Preposición + Gerundio (without deploying)

  ➔ Después de una preposición (como 'without'), debemos usar la forma de gerundio (-ing) de un verbo.

• The alert here that we identify is that we flag the user admin.

  ➔ Cláusula relativa con 'that'

  ➔ La cláusula "that we identify" proporciona más información sobre el sujeto "alert".

• There is no authorized_key file here; it is authorized_keys2.

  ➔ Negación existencial con 'no'

  ➔ Usar 'no' + sustantivo es una forma común y enfática de expresar que algo no existe.

• If I were to see a user using this file, I would assume they're up to no good.

  ➔ Condicional tipo 2 (If + were, would + infinitivo)

  ➔ Se usa para situaciones hipotéticas o poco probables. 'Were' se usa a menudo para todas las personas.