Contenido principal

Backdoor CTF 2015 - RSANNE

Abril 3, 2015

We are given with two files in this challenge: an encrypted file and a 4484 bit RSA public key. The challenge is to get the plaintext from the encrypted file.

The first step is to get the modulus from the PEM file:

# openssl rsa -inform PEM -pubin -text -modulus < id_rsa.pub
Public-Key: (4484 bit)
Modulus:
    0f:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:fd:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    f8:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:01
Exponent: 65537 (0x10001)
Modulus=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDFFFFFFFFFFFFFFFFF
FF80000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000001
writing RSA key
-----BEGIN PUBLIC KEY-----
MIICUjANBgkqhkiG9w0BAQEFAAOCAj8AMIICOgKCAjEP////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
//////////////////////////3////////////4AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAECAwEAAQ==
-----END PUBLIC KEY-----

N is the product of two Mersenne primer numbers, so the second step is to make a script which is used to find them:

#!/usr/bin/env python

mersenne = [2, 3, 5, 7, 13, 17, 19, 31, 61, 89, 107, 127, 521, 607, 1279, 2203, 2281, 3217, 4253, 4423, 9689]

for n1 in mersenne:
    for n2 in mersenne:
        m1 = (2 ** n1)  - 1
        m2 = (2 ** n2) - 1
        if m1 * m2  == 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDFFFFFFFFFFFFFFFFFFF80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001:
            print "Match! ", m1, m2

The two prime numbers are: 22281 - 1 and 22203 - 1.

We use rsatool.py from ius to reconstruct the private key PEM file (which is used later to decrypt the content of the file using the OAEP padding scheme):

-----BEGIN RSA PRIVATE KEY-----
MIIKCAIBAAKCAjEP////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//3////////////4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAECAwEAAQKCAjEIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yge
d+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB53
4Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfh
iB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GI
HnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yge
d9+AgH9/gIB/f4B4YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhh
B574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEH
nvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee
+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574
YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhh
B6ECggEeAf//////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////wKCARQH////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//8CggEeAYCAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CA
f3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/
f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/
gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+A
gH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CA
f3+AgH9/fwKCARQGWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZ
aaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllp
ppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmm
lllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaW
WWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZ
aaUCggEeAKqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqq
qlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVU
qqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpV
VUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqq
pVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVS
qqpVVUqqqQ==
-----END RSA PRIVATE KEY-----

Final step is to decrypt the file:

# openssl rsautl -decrypt -in flag_d.bin -out plaintext.txt -inkey private.pem -oaep
Loading 'screen' into random state - done

# cat plaintext.txt
the_flag_is_e4972e14...

Archivado en: Criptografía, Retos informáticos | Comentarios (0)

B-Sides Vancouver CTF 2015 - garbage file

Marzo 18, 2015

Description

Your buddy Joey left a USB key with some data he needs your help with. He pulled it from the firewall logs at a 'secure file format'-as-a-Service provider, so he's pretty sure it might be protected or obfuscated somehow.

garbagefile.pcapng.gz

Solution

A PCAPNG file is provided, there we can see some UDP packets where the data is located:

We need to get all the data sent over UDP, we can do it by using tshark:

$ tshark -r garbagefile.pcapng -Y "udp" -T fields -e data
00026163636f756e742d646174612e62696e006f6374657400
00040000
0003000100004edf00002e77789c0173018cfe4435d00b168b...
00040001
00030002803434680f53d41a3d4068007a801a1ea0341a1ea7...
00040002
00030003142dfea2fb389f6ded40c310f8dcc905034127d07f...

Each message is composed by two short integers (first one to indicate which is sending the message + second one an incremental ID), and the data itself. I used this script on PHP to separate data from metadata and create bzip files (based on bzip headers found on the dump):

<?php

$file = file('data.txt');

$out = '';
for ($i = 2; $i < count($file); $i += 2) { // ignore first and second line, then each two
    $out .= hex2bin(substr(trim($file[$i]), 8)); // strip metadata
}

$i = 0;
$bzs = explode('BZh', $out);
foreach ($bzs as $bz) {
    file_put_contents('bzips/' . $i++, 'BZh' . $bz);
}
?>

Twenty two files are created, it is time to decompress them using python:

import bz2
import sys

for i in xrange(0,22):
    try:
        file = bz2.BZ2File(str(i), "r")
        print file.read()
    except:
        sys.stderr.write('file '+ str(i) + ' invalid\n')

There are only three "corrupted" files:

file 0 invalid
file 8 invalid
file 21 invalid

First file does not contain a bzip header, so it was skipped. Second file is the heaviest (20.8KB) and it is possible the file we are looking for. We are making a guess now, the file seems to have a Zlib header:

It is decompressed properly giving us a base64 encoded file:

iVBgMA0KNH0AAC56SUhqJQAALO0AAC4TCAIudwCpR3DoAC53AXN8MEIAgLkc6S53AAleP1lzLncL
Ey53CxMvd5qcNncAQC4+REF6DwHt83C8BWsCMPB7xwsIBH9SBQojRUGjPbH3OPolxPZlTYIDJj8T
Y3saExvhmNgfMRMLBOHERp5W2MAofwgoM9MqKqxXWL7RyXlvwZnM7FMM997V/ez88Ji+2ffuM2fg
... (cropped)
a0ANOm8oMH4XoMBu9tWlbty/38TVNdQQJ2Cg7jeBgSx0BQYkA6fAjrm700S/OVBO18BAr/YCAyuh
KAUoAr5GFRFAa463QIGvdQMFKH10p+7Xzrv9Hcg5fhegwG72gQItctYoK3F1vmhMZkBF18BAr/YC
AytxCnSJt6DOlaRqyBcnYKDuN4GBLHQF1gZyBnWQMTtmbhygwG72gQItcgYKWtDA/ymC2qJiimhr
73cAAC4+RU5q2UJgrA==

Final result is a PNG file encrypted with XOR using "00 00 2E 77" as key:

Flag

key{03087-08351-27H}

Archivado en: Miscelaneo, Retos informáticos, Seguridad | Comentarios (0)

FREAK on Colombian domain names and Heartbleed one year later

Marzo 4, 2015

I am here writing again about some statistics, this time is for the new vulnerability found on SSL/TLS (FREAK Attack) against critical Colombian domain names. Same methogolody of Overview of OpenSSL security bug (CVE-2014-0160) on critical Colombian domain names is used in this post.



FREAK Attack on restricted colombian domain names

Identifying vulnerable domains

A python script was used to identify in a non-intrusive way the affected Colombian domain names (gov.co, edu.co, mil.co, and org.co):

    for domain in domains:
        result = ''
        IP = domain_exists(domain)
        if IP != False:
            if check_connectivity(IP):
                if check_FREAK(IP):
                    result = 'VULNERABLE'
                else:
                    result = 'NOT-VULNERABLE'
            else:
                result = 'SECURE-CHANNEL-UNSUPPORTED'
        else:
            result = 'NON-EXISTENT'

Results

2975 domain names were tested against the vulnerability, the results are impressive, from 1815 domains that support HTTPS only 46 are affected (it is possible to make a man in the middle attack while the domains is using SSL/TLS):



This is the detail of the results classified by each Third-level domain:

:arrow: gov.co, 662 not vulnerable, 18 vulnerable.
:arrow: edu.co, 689 not vulnerable, 15 vulnerable.
:arrow: mil.co, 58 not vulnerable, 1 vulnerable.
:arrow: org.co, 360 not vulnerable, 12 vulnerable.



Finally, we got the distribution of the vulnerable Colombian third-level domains:



Heartbleed a year later

One year later the same script and data were used to test the heartbleed vulnerability (Overview of OpenSSL security bug (CVE-2014-0160) on critical Colombian domain names), this is what I found:

:arrow: Only 2 domain names were found to be free of the Heartbleed vulnerability, 16 are still vulnerable.
:arrow: 177 domain names have implemented HTTPS.
:arrow: 115 domain names were deleted (or DNS A record does not exist).
:arrow: 86 domain names dropped HTTPS support.

Archivado en: Seguridad | Comentarios (0)

Overview of OpenSSL security bug (CVE-2014-0160) on critical Colombian domain names

Abril 10, 2014

* Update on methodology and results: Statistical sample
* Update on methodology and results: Retest

The TLS heartbeat read overrun (CVE-2014-0160) (also known as The Heartbleed Bug) is the hot topic right now on the information security field. While this publication is not about the technical detail of the bug but some statistics of critical affected Colombian domains, I will show you a big picture of the vulnerability and the results of my research.

If you would like to know more about it, please take a look at the following resources: The Heartbleed Bug, Sean Cassidy's technical analysis, Robert Erbes' technical analysis.

Vulnerability summary

The Heartbleed Bug allows an attacker to read sensitive information contained in the memory of the process which depends on the OpenSSL implementation (OpenSSL from version 1.0.1 to 1.0.1f).

Sensitive information such as user credentials, session IDs, data sent to the server and received by the client, private keys, and anything you can imagine could be found by exploiting this vulnerability.

Affected users are recommended to fix the issue as soon as possible by updating to the latest version of OpenSSL (1.0.1g).

Methodology and results

Restricted Colombian domain names

Using domain name searching methods I was able to get a long-enough list of third-level domains (the list does not include subdomains) which are classified by NIC.CO as restricted user domains, this is, the person who register the domain have to meet certain legal requirements to be able to get a restricted domain name (gov.co, edu.co, mil.co, and org.co).

These domains are used by Colombian government agencies or institutions, Colombian educational sector institutions recognized by the Ministry of National Education, Agencies or institutions of the Colombian Armed Forces, and Companies or nonprofit institutions resident in Colombia.

Update note about the statistical sample

Through this methodology, a sample of 2612 domain names were found which is a 99% representative sample for a hypothetical case of 10000 (*) valid and functional domain names.
* Approximate data provided by NIC.CO

Evaluation date

Start time: 08/04/2014 - 22:48
Finish time: 08/04/2014 - 23:30

Identifying vulnerable domains

A modified version of the Jared Stafford's python script was used to identify in a non-intrusive way the affected domains (no data was stored or viewed on the test, the script just only show the status of the server).

    for domain in domains:
        result = ''
        ip = domain_exists(domain)
        if ip != False:
            if check_connectivity(domain):
                try:
                    if check_heartbleed(domain):
                        result = 'VULNERABLE'
                    else:
                        result = 'NOT-VULNERABLE'
                except Exception:
                    result = 'SECURE-CHANNEL-UNSUPPORTED'
            else:
                result = 'SECURE-CHANNEL-UNSUPPORTED'
        else:
            result = 'NON-EXISTENT'

Results

2612 restricted domain names were tested against the vulnerability (perhaps this is not the total number of valid domain names). There are 1592 domains that are not vulnerable and 252 that are (a total of 1844 domains with HTTPS support distributed on 985 different IPs, and 768 not applicable):



This is the detail of the results classified by each Third-level domain:

:arrow: gov.co, 602 not vulnerable (51.99%), 70 vulnerable (6.04%), 486 not applicable (41.97%).
:arrow: edu.co, 639 not vulnerable (68.34%), 104 vulnerable (11.12%), 192 not applicable (20.53%).
:arrow: mil.co, 17 not vulnerable (25.76%), 42 vulnerable (63.64%), 7 not applicable (10.61%).
:arrow: org.co, 334 not vulnerable (73.73%), 36 vulnerable (7.95%), 83 not applicable (18.32%).



Finally, we got the distribution of the vulnerable Colombian third-level domains:



Retest

One month later 252 domains have been tested against the vulnerability, the results are shown:

:arrow: 228 (90.48%) domains do not have the bug anymore.
:arrow: 5 (1.98%) domains turn off their HTTPS support.
:arrow: 6 (2.38%) domains do not have an A record associated on the DNS.
:arrow: 18 (7.14%) domains on 16 IPs are still vulnerable.

Comparison of vulnerable domains one month later:


Final overview of the OpenSSL security bug on Colombian third-level domain names:


Incident handling

:arrow: 08/04/2014 - Start of the security test.
:arrow: 09/04/2014 - colCERT was contacted to coordinate the incident handling and communicate the issue to the affected domains.
:arrow: 10/04/2014 - First contact with colCERT (list of 252 affected domain names was provided), they are taking now all necessary steps to solve the issue on the affected domains.
:arrow: 11/04/2014 - First contact with NIC.CO, they are working together with colCERT to solve the issue on all the affected domains.
:arrow: 08/05/2014 - Start of the security retest.
:arrow: 10/05/2014 - Final update.

Archivado en: Seguridad | Comentarios (1)

Campus Party Colombia 2013

Octubre 13, 2013

Esta semana, del 7 al 13 de Octubre, se llevó a cabo la sexta edición de Campus Party Colombia en la ciudad de Medellín. En el área de seguridad se encontraba la propuesta de la competencia para este año, en total fueron 30 retos, de los cuales se solucionaron 23.

En el siguiente enlace puede encontrar la solución para cada uno de lo 23 retos resueltos:

:arrow: Solución retos de seguridad Campus Party Colombia 2013

En el sitio principal de NULL Life puede encontrar solucionarios a otros eventos organizados a nivel nacional e internacional.

El tablero "final" de puntuación es el siguiente:
Scoreboard Campus Party Colombia 2013

Tanto en el juego presencial como en la gráfica se puede evidenciar el juego no limpio, la gráfica con los valores reales queda a consideración de los organizadores.

Debido a esto, y a otros sucesos, el equipo NULL Life, anuncia públicamente que no volverá a participar en este tipo de eventos, a menos que reglas claras y concisas sean establecidas antes del juego, y estas se respeten.

Archivado en: Criptografía, Ingeniería Inversa, Retos informáticos, Seguridad | Comentarios (0)