primer_ataque_dos

¿El primer ataque DoS de la historia?

Estamos en 2017, lo que implica que el ataque DoS (Denegación de Servicio – Denial of Service) cumple 43 años. Lo que nació como la obra de un geek (o friki como decimos por aquí) se ha ido convirtiendo en algo muy elaborado que afecta a multitud de sistemas. Además, gracias a Internet, su variante DDoS (Distributed DoS) es sin duda uno de los quebraderos de cabeza de los que trabajamos en esto.

Un poco de historia

Cuenta la leyenda que el primer ataque DoS ocurrió en 1974 gracias a la curiosidad de David Dennis, un estudiante de 13 años de la Universidad de Illinois. David se percató de la existencia de un comando en los terminales PLATO (uno de los primeros sistemas computerizdos de aprendizaje compartido, antecesor de los sistemas multiusuario) llamado «ext».

Este comando permitía conectar dispositivos externos y suponía que cuando se lanzaba, el dispositivo estaría presente, avisando de que únicamente era útil usarlo en ese caso.

Sin embargo, no avisaba de lo que ocurriría si no había dispositivos conectados. Cuando el comando se ejecutaba en un terminal así, se bloqueaba requiriendo un reinicio para volver a funcionar.

En este escenario, David tuvo la curiosidad de comprobar si era capaz de bloquear a todos los usuarios a la vez, de forma que el laboratorio quedase colapsado. Con esto en mente, desarrolló un programa que enviaba el comando «ext» a todos los terminales PLATO al mismo tiempo.

Como podéis imaginar, la ejecución fue un éxito rotundo, ya que bloqueó los terminales de más de 30 usuarios ante el asombro general. Este movimiento terminó con el bloqueo de la ejecución del comando «ext» de forma remota.

Os dejo la historia contada por David Dennis:

As far as I know, I’m the first person to have created a DoS of a room full of PLATO terminals deliberately. Systems people could of course kick anyone out they wanted, and «operator wars» had existed for years, but those tended to be consensual attacks on each other. What I did was I heard about a new command called the «external» command in TUTOR, or ‘ext’. Specifically, one of the music kids was saying how if you didn’t have a device attached, an ext command would cause your terminal to lock up and have to be powered off. Remember that powering off was discouraged, due to always-concern over flaky power to the plasma panels.

The other piece of this was they had rolled out the external command for everyone in the fall of 1974, after it having been only in use by the Music project. This meant that every user account on PLATO was set to defalt «can accept ext commands.» Default on.

If you recognize default enabled from any firewall work you’ll immediately recognize the trouble…

Anyway, I heard this and immediately thought of how a room full of annoying users could be locked up at once. My little 13 year old brain wanted to see a room full of users all be locked up at once.

So, I wrote a little program that sent exts to everyone within a range of site numbers, waited til I was over at CERL one morning, and let er rip.

It worked as advertised, 31 users all had to power off at once, great mayhem in the classroom, site monitors notified. No logging of course, I was never detected. Quietly left the room, went back over to uni.

Accessed the site displays I knew of from author mode, and looked up other sites around town or the country, and tried sending them some ext’s too. Was delighted to see mass posting on notesfiles about a locking out they were experiencing.

Soon some systems guys figured it out, probably a combination of common sense and maybe looking in some sort of logs, though I was never prosecuted or even approached, so I have to think to this day it was undetected. A few weeks later the ext command was withdrawn from ‘open all’ and a while after that was redeployed, this time with the default set to OFF. As it should have been all along. 🙂

So was there ever a DoS on a networked system prior to 1974 ? Im sure there had to be, but at least for the moment I’m claiming it !

Y la moraleja es…

Al final, es la historia de siempre. Si hacemos algo pensando en que la situación perfecta es la única, lo más probable es que alguien se de cuenta de que, si esa situación no se da, ocurre algo indeterminado. A partir de ahí, encontrada la vulnerabilidad, lo demás es jugar y eso es precisamente lo que hizo David.

Como dijo Chema en alguno de sus posts:

Entendemos como Software Fiable aquel que hace lo que tiene que hacer y como Software Seguro aquel que hace lo que tiene que hacer y nada más. Ese algo más entre el software fiable y el software seguro son los bugs.

En este blog puedes encontrar algunas entradas que te pueden ayudar a desarrollar software seguro como las de las contraseñas (esta o esta) o las de auditoría de código (esta, esta o esta). Con estos consejos podrás lidiar en la medida de lo posible contra ataques DoS como el que hizo David. En cuanto a los DDoS, eso es otra historia…

SecurityInside Live: CloudForum 2017

En esta ocasión asisto al CloudForum de IDC orientado a las tecnologías cloud. Expertos de grandes empresas como Fujitsu, Telefónica o IBM (entre otras) nos ofrecen su experiencia de primera mano.

Leer más

SecurityInside Live: Mundo Hacker Day 2017

Al igual que el año pasado, me voy al evento «Mundo Hacker Day 2017» para asistir en primera persona a las interesantes charlas que grandes expertos en seguridad van a ofrecer.

Leer más

Seguro que te interesa (GitHub behind the scenes – parte 1)

Esta entrada es un poco atípica, realmente no es más que una excusa para presentaros el nuevo repositorio en GitHub de esta web.

Poco a poco quiero ir ofreciendo los scripts que me hacen la vida más sencilla y que pueden ayudaros en ciertas tareas. Para estrenar el repo, he pensado en contar cómo hago la entrada de los Viernes en las que os listo las noticias que me han parecido más interesantes de la semana.

Tras unas cuantas entradas en las que iba recopilando enlaces a mano, decidí que así no podía continuar. Como dice un gran amigo, soy muy vago, pero vago de los buenos. Eso me hace pensar en cómo automatizar absolutamente todo lo que hago para que las tareas repetitivas las haga una CPU y yo pueda centrarme en ideas felices o a imaginar qué isla me compraré cuando me toque la lotería.

Gracias a lo de internet, tiro de Twitter para estar al tanto de las noticias de última hora y suelo hacer retweet de lo que me llama la atención. Noticias, herramientas, análisis, humor… pero todo relacionado con lo que me apasiona, la seguridad de la información.

Como últimamente le he cogido cariño a Python (al pitón como le llamo alegremente por la oficina de Dive), decidí tirar de un poco de crawling vía BeautifulSoup para buscar en twitter ciertos elementos.

Básicamente lo que hago es abrir la página de Twitter de SecurityInside y busco todos los retweets. De cada uno, me quedo con los elementos interesantes (título, autor, imágen y texto) y los pongo en forma de tabla para que se vea de forma decente como una entrada del blog. Básicamente esto:

# Get retweet info
# ---------------------------------------------------------------------------------------
req = requests.get(url)
statusCode = req.status_code

if statusCode == 200:

    html = BeautifulSoup(req.text, "html.parser")

    for timeline in html.find_all('div', {'data-test-selector':'ProfileTimeline'}):
        for oltag in timeline.find_all('ol', {'id':'stream-items-id'}):
            for litag in oltag.find_all('li'):
                for div in litag.find_all('div', {"class" : "tweet"}):
                    try:
                        if div['data-retweet-id']:

                            for small in litag.find_all('small', {"class" : "time"}):
                                for a in small.find_all('a', {"class" : "tweet-timestamp"}):
                                    try:
                                        date = a['title'].encode("ascii", "ignore")

                                    except Exception as e:
                                        None

                            title = div.find('p', {'class':'TweetTextSize'}).getText().split('http')[0].encode("ascii", "ignore")

                            link = div.find('a', {'class':'twitter-timeline-link'}).getText().encode("ascii", "ignore")

                            name = div.find('span', {'class':'username'}).getText().split('@')[1].encode("ascii", "ignore")
							
                            for img in div.find_all('img'):
                                if 'avatar' in img:
                                    image = 'http://securityinside.info/wp-content/uploads/logo.png'
                                else:
                                    image = img['src'].encode("ascii", "ignore")

                            print '<tr><td style="vertical-align:middle;border:0px;margin: 0px 0px"><img class="aligncenter" src="' + image + '" alt="' + name + '" width="150"/></td>\n<td style="vertical-align:middle;border:0px;margin: 0px 0px"><strong><a href="https://twitter.com/' + name + '" target="_blank">' + date + ' @' + name + ':<br></a></strong> <a href="' + link + '" target="_blank">' + title + '</a></td></tr>'

                    except Exception as e:
                        None

else:
    print "Status Code %d" %statusCode

El ejemplo es sólo parte del script completo. Si quieres utilizarlo o modificarlo, puedes descargarlo desde nuestro repositorio en GitHub.

 

Como podéis ver, sólo tengo que copiar la línea que me genera el script e insertarla en la entrada. La tarea se completa añadiendo el texto habitual y configurando las categorías, la imágen y los valores SEO.

Vale, me vais a decir que eso también se puede automatizar. La respuesta es que si, por eso os dejo pendiente la segunda parte del artículo en la que dedicaré otro rato a generar la entrada completa (insertando en base de datos y demás).

Pero poco a poco, que estoy un poco liado gestionando los backups anti malware de la junta directiva… pero eso es otra historia que os voy a contar en breve.

¿Os lo vais a perder?

rooted17

SecurityInside Live: RootedCON 17

Un año más, preparo la mochila y me voy a pasar los próximos tres dias a Kinépolis para disfrutar de mi congreso de Seguridad favorito: la RootedCON. Si te interesa, puedes repasar lo que nos gustó (o no) de la edición 2016. ¿Nos habrá leído Román y este año tendremos café?

Leer más