26C3 #4
Congress last day, I’ve been chasing the guy of the chipcard lab kit for two days now, it’s incredible hard to get in touch with him, when I finally talked to him he doesn’t have any assembled kit, and just have one PCB left, without any components. That really sucks, he could have told that two days ago and I wouldn’t lost my time asking for him every two hours… that kind of things really suck. OK live is like that, we’l have to assume that.
The morning session started with the SecuBT talk. This framework provides a secure execution environment for a process in userspace, so no kernel modification is needed, just execute the program after specifying with the LD_PRELOAD environment variable the SecuBT library and that’s it. Doing this you set a wrapper around the process that controls all the interactions with the kernel, so signals, system calls and all those stuff can be restricted or modified in runtime. From a security point of view, a suspicious process can be “jailed” with this technique, so any evil action that it tries to perform can be aborted before it actually can break somthing. Or from a reverse engineering point of view, you could spy the behaviour of the process or inject information to it “customizing” the reads performed from file handlers or network sockets. All this application sandboxing/virtualization thing is a very interesting area of researching.
Next, Finding the key in the haystack lecture. Actually I am not a hardware geek, so any kind of hardware talk is a chance for me to learn new things. This talk was very interesting because it focused on a side-channel attack on a hardware implementation of the AES algorithm to extract the key measuring the power consumption of the chips involved in the cryptographic operations. I am familiar with a very similar kind of attack, but in software, the timing attacks (either local or remote). The idea is very similar, but you’ve to measure the time needed to perform an encryption, a decryption, or maybe the validation of a digital signature, or even the checking of a hash. Through a differential analysis of how last a valid operation compared to an invalid one, you can extrapolate useful information about how the system works, or even extrapolate the key at a byte level. In this case, the analyst intercepts the electrical signals that go in or out the chips, so knowing which algorithm is implemented and it’s internal design (as happens with AES) you can extrapolate the internal status of the algorithm looking the power consumption, and even injecting text probes to compare the consumption between a correct or incorrect key. Doing this you could brute force the key, a byte each time, and guessing if the value it’s correct or not looking at the power consumptions which leaks the status of the internal operations. Just magic! :)
And with this, 26C3 was over for us! :( We spent the rest of the day as perfect tourists, enjoying Berlin.
26C3 #3
Our day started with the DECT (part II) talk, a followup of the previous year DECT talk. The speakers focused on the DSC (DECT Standard Cipher) crypto algorithm currently used in DECT phones. The interesting thing is the reverse engineering work done to understand how this algorithm works, note that sniffing a couple of hours of traffic between a phone and the base station, gives you enough information to crack the algorithm and get the keystream used in that conversation, but the capture is pretty special, they said that a useful capture would be something like a continuous silence in the line, that isn’t usual, but possible like if you’re using your DECT phones as an intercom system for small child surveillance, in that case you’ll have an audio channel completely muted, and the other channel with the baby room noise. Anyway, they promised a complete release in january 2010, so more details and specific implementation of the DSC attack then. If you think that exposing weak designs to the public won’t change things, this talk is the perfect example this not always is true. The DECT industry has acknowledged the great work of the dedected.org group and from 25C3 a lot of things changed, the DECT manufacturers are working know to improve the standard and make it more robust. The next DECT standard will be open source, not closed as it’s now and they are working together with the security researchers, to be advised on how to do thinks correctly from a security point of view.
I wanted to attend Playing with the GSM RF Interface but finally I missed this one, the room was completely full and we couldn’t go into, so we tried the DDoS/Botnet talk but I’m sorry to say that we just lasted 10 minutes there, I was expecting a much more technical talk about DDoS countermeasures or maybe botnet shutdown techniques, but instead that, the talk was about online communities like BBS, IRC, blogs and message boards… and what good practices you’ve to follow to monitor them if you’re the admin. We thought that maybe would be a better idea to jump directly to saal1 and take a sit for the next talk, which was Using OpenBSC for fuzzing GSM handsets.
OK, a kind of followup from past year again, when Harald showed us OpenBTS with a BTS bought on eBay, it was amazing. A year after, Harald has talked again about GSM networks, its basic topology and protocolos used. The point here is that GSM networks are pretty closed, they are hard to play with, but the availability of BTS hardware and pieces of software like OpenBTS and OpenBSC make things much easier. The objective from here is to fuzz the network from our very own BTS and audit the implementation of the protocol stack. This is a very closed world, so a bug founded in a device is very likely to be present in others.
By the way, it seems that the GSM RF talk was about a DoS attack (resource exhaustion) launched from a terminal that affects the cell in wich the terminal is registered. I’m looking forward to finding the video recording to watch it, as soon as I do, I’ll write a little reference here, but for now I guess that either the terminal uses some kind of customized firmware (more likely the TSM30) or the attack was launched using a microBTS/nanoBTS connected to a laptop or something like that. I guess that these are the same slides used today.
Last talk of the day, Black Ops of PKI featured by Dan Kaminsky who reviewed all the security flaws that have raised up during the last couples of years. It was the same talk in the BlackHat/Defcon so nothing new under the sun. The first problem explained is about the hash algorithms used by the CAs to sign the certificates. You can find a lot of MD5 signed certificates, and if you remember the last year CCC talk about SSL certificates, it was completely broken using a selected prefix collision attack, doing this you could build your own intermediate certificate, so you can sign other certificates, to get this tou use the public key binary block sent in the CSR to the CA as the “selected prefix”, once you get your signed certificate you could fix it to convert it in a intermediate CA certificate and reuse the same signature from the CA, due to the “magic block” that generates the collision. This was showed last year, and reviewed again this year. Dan pointed out too the use of MD2 as a hash algorithm, but this would be right now a very strange case, despite the example that he has used is an old root certificate of Verisign. Everybody must use SHA-1 nowdays. The other kind of attacks were the “semantic” attacks. One example is to send a CSR to the CA where the CN has a NULL as part f the string. This is fixed, but could be allowed to get valid certificates for CN that you don’t own, or wildcard certificates. To finish, some examples using ASN.1 encoding, so you can take advante of integer overflows in the OID BER encoding.
Well, that was all for today, I skipped some talks in the afternoon, but we had some fun in the RealWorld ;)
26C3 #2
We’ve planned to attend the JTAG debugger talk at 10:30 this morning, but we felt so comfy in the cafeteria where we were having breakfast that we stayed there a couple of hours chatting instead of going to the talk, so we finally missed it :( but that wasn’t such a big deal, I guess that in a few days the video recordings will be available to download.
The next talk scheduled in our very personal agendas :) was about the Google Lunar X-Prize and how the Part-Time-Scientist team is working to achieve it. The talk was amazing, in the sense that they explained all the steps given to date to build the robot, launch it, land it safely on the moon surface, capture and transmit back to earth the HD video, and finally let the robot survive as much time as possible up there. They explained all the robot internals, how it was built and the communication systems used to provide the upload channel to send commands to the robot, and the fat download pipe to get the HD images. It was amazing, more than 30 antennas all around the globe, to provide an unique “virtual big antenna” from the moon point of view, that provides 24/7 500kbps link to/from the moon-robot/earth. A nice detail was the live video-conference with one of the NASA engineers that participate in the original Apollo missions he talked us, from their home in the US, about the Apollo mission and how his work back then in the NASA.
After this some asian style lunch in the food court of the mall across the street, and back to the BCC to attend the Milkymist talk. Not much to say here, we learned about this open hardware platform, its design, how it is programmed and the visual effects that it provides in real time. More info in the project page.
More hardware stuff in the Advanced microcontroller programming lecture the talk was a summary of advanced programming and debugging techniques learned after a year of hardcore microcontroller programming based on Atmel CPU. How to success with subjects like microcontroller C++ development, profiling, real time programming, timing and concurrency, and agile development techniques.
The Fuzzing the phone talk was pretty nice. The fuzzing technique is usually used to find bugs by forcing buffer overflows and probing all kind of malformed, oversized and mangled inputs. Applied to last-generation smartphones, SMS fuzzing is an interesting way of finding flaws in the phone software that handles the messages by injecting custom, specially formated or malformed SMS messages. The talk exposed how the SMS fuzzing framework was used against iPhone, Android and HTC WM6 phones, and the results obtained with the experiments. The design of the framework is pretty interesting, remember that phones based on Android or the Apple iPhone are little Unix boxes and therefore you can use some of the familiar and nice techniques that you already know, like programming a middle layer (a daemon in practice) that renames the /dev/XXX serial device used to talk to the radio modem interface, after that creates its own device so the SMS application in the OS do the I/O there, and our process takes control of all the information that the OS SMS app writes to this device. In the other hand our daemon opens the true serial devices that talks to the modem, so we can receive all the modem messages and relay the app messages to the modem. By doing this, the fuzzing process is pretty efficient, because we can inject the SMS directly to the OS app, and it will think that they are being received through the modem. So, a nice MiTM attack using some basic unix system programming. To inject the messages the daemon open a TCP socket, so we can send them through the WiFi network, connecting to this TCP socket, cool! This very same talk took place in BlackHat’09 so you can get more info about it in BlackHat web and also in the project page.
Defending the poor by Phenoelit/FX. This talk wasn’t about attacking but about defending :) Flash isn’t a good designed languaje/environment, and malware take advantage of this to execute itself and do all kind of nasty things, like URL redirecting, fake clicking, etc. What FX introduced in his talk is a countermeasure to disable all attempt of attack from a malicious swf by patching the bytecode and make the attack fail. It’s in a very early status of development, but it has been released just now during the congress, so anybody can improve it, or make some nice plugin based on it. Check it out.
Unfortunately I missed the Haste ma’n netblock? lecture :( and I didn’t get the netstream of it, so I’ll have to wait to download it, so let’s jump to the last talk I attended today, the SS7 network hacking this talk was really interesting, the kind of talk that discover you a completely new world and encourage you to research and learn more about it. The speaker focused on the SS7 network design, which systems you can find there (gateways to other networks, authentication systems, roaming systems…), the complete protocol stack, the link with the well-known world of TCP/IP, and the most interesting part, some basic knowledge about auditing SS7 networks, what to search and where, how to make scans and how to take advante of the information gathered through those scans, and finally some links to tools. Unfortunately the time given to this talk (1 hour) was insufficient to cover all the subjects, but he had been talking hours and hours if he could… really nice talk. The problem is… how to reach the SS7 network? Thats the point, if you aren’t inside the network for auditing purposes, you’ll have to find some entry point, maybe an IP gateway reachable from the Internet. Remember that some SS7 systems, mainly SMS related, communicate through the Internet via standard IPSEC VPN links, so maybe this could be an entry point, or you could try the SST over SIP encapsulation trick, that would be nice. As I said before, a completely forgotten world waiting for us to have fun. It’s interesting to point out that this phone systems are increasingly considered strategic and critical infrastructures, so governments want to audit them and assure that they aren’t vulnerable, it’s a nice area to work on if you get the opportunity.
By the way, remember the “Sleep Hacking” talk/workshop? A wiki has been created to get all the stuff related to this subject there, so check it out and colaborate if you’re interested. and if you’re successful hacking your sleep cycles, begin searching new hobbies because you’ll get a lot of extra free time ;)
26C3 #1
Summary of Day#0
This year the CCC has started pretty chaotic, which isn’t strange because we’re in the Chaos Computer Congress ;)
I say that this year started chaotic, because the ticket selling desk was supposed to be up&running at 5 PM yesterday, but the opening was delayed until 10 PM. I was there at 5, it wasn’t ready, I went for a 2 hours talk, I was there at 7 again, but I saw that the place was open but the selling desks weren’t working yet, and finally after a long walk one more time through the nice xmas markets around the city (I had and overdose of curry bradwurst) I met with Luy, we had a couple of beers(yes, just a couple! ;)) and went to BCC at 10 PM, just to find a looooooong, loooooooong queue :( I haven’t seen anything like that the previous years, the line was all inside the ground floor in the BCC… luckily for LuY and I, JAG was already there, he has been in the line for about 15 minutes and we joined him. We were there, queueing, about 1 hour… the longest queueing time that I remember in a CCC Congress :( if the last year the congress was crowded, this year gonna be crowded++
Day#0 is almost finished, time for something to eat… we had a kebab in Alexanderplatz, some chatting to catchup in the everyday lives of all of us, and time to calling sleep() system function ;)
Day#1 of 26C3 has started.
We met at 10 in Alexanderplatz to have some breakfast. This year we started our personal schedule pretty late compared to other years as the opening lecture, the keynote, this year is in german instead of in english as opposed to previous years, so the first bunch of talks would be the lighting talks. Here we had a mix of german and english talks, I don’t speak a word of german so the talks in this language are totally encrypted for me, that’s a pity because some of them seem pretty interesting. Anyway, we had here a lot of short (4 minutes long) talks, most of them really interesting. People frequently use these lighting talks to briefly introduce the projects in which they’re working on. The talks that I found more interesting, and that I’ll try to know more deeply in the next few days are the following ones:
Sleephacking. If you’re like me, I guess that you have tried polyphasic sleep or at least you have read about it. This talk was a summary of what hacking-sleep-techniques are out there, and invite us all to the workshop about polyphasic sleep. I didn’t attend it, but I’d liked to.
Radio Broadcasting. Maybe you thing trhat radio broadcasting is completely dead. Who wants to FM or AM broadcast when you can broadcast whatever you want globally through the Internet. Take a look at the opendigitalradio project, it’s worth it, maybe you change your mind after know what you can do with a USRP and some radio oriented open software.
Sybil Attack & DDOS with BitTorrent DHT. The idea behind this was very interesting despite the guy giving the talk seemed really nervous… take it easy man, we’re all friends! :) OK, the idea was cool… a DDOS attack forced when you inject some fake DHT info to the torrent network, so you’re telling that some pieces of information are available in IP addresses that really don’t, forcing other people looking for these chunks to connect to the target, and doing that, you create a TCP connection storm against the target.
There were a cool talk about a guy who built a pong watch and asteroid watch, really funny… your binary led watch looks like crap compared with this pong watch. You have to watch it out! :)
More details about the lighting talks here, try to google to find more information about each subject.
After a couple of giant bratwurst for lunch I attended the talk Our darknet and bright spots about the VPN system created to link all the hackerspaces around the world. It was about ChaosVPN (network tha links EU hackerspaces, mainly the german ones) and Agora (network that links all US hackerspaces as noisebridge in SF or Resistor in NYC). Which network topology to use, why a centralized (star kind) topology doesn’t work for them, and why popular VPN software like OpenVPN doesn’t fit their needs. These intranets are based on the tinc and dn42 as the core software for linking all the nodes and a workshop was setup to teach how to get into the hackerspace mesh network. The idea of joining and sharing resources, or participate in the 24/7 CTF is really cool, and catch all my attention, so I’ll take a look at home again in a few days. If I finally get into, I’ll write a post of how to join the network, and what services are on it.
The next talk I’ve attended was Exposing Crypto Bugs through Reverse Engineering. It was a nice talk about how good crypto can be totally cracked if the implementation is bad. The first example was a crypto key, FIPS approved, that creates several encrypted file systems, with 4 different passwords, one for private data, another on for public data, a fake private password that you can use when someone asks you to give him/her your private key, so you can use this fake password that opens and decrypts a simulated real file system, and doing that you fool the guy in the border, for example. Well, the bug in this crypto key was that through reverse engineering was known the structure of the crypto file where the four blocks of data were stored. The structure keeps the passwords SHA hashed. By a brute force attack, or a rainbow table attack, you could crack one or more than one of the four passwords. And what was the funny trick that exposed the really bad implementation? Well, if you could find 1 of the 4 passwords, you could decrypt any of the four data blocks not only the data block associated with the password cracked. So, in the talk he cracked the panic password, which is the 4th password that you can define, the panic password is the one that you’d use to wipe out all the information in your private block, rebuilding the crypto file from scratch. As you can imagine the panic password should be short, so you can type it really fast if you’re on problems. So it’s the one easier to brute-force. So, if you have a weak password, the panic one, you crack it, and you can use it due to the bad implementation to decrypt the private and really secret data… then this system is completely useless.
Next GSM: SRSLY? talk. This kind of talks about GSM encryption aren’t new in CCC, the last couple of years had been talks to inform about the state of art of A5/1 cracking using pre-calculated tables. This time, the H4RDW4RE group has talked about the viability of the attack, which has been evolving from the last 12 years, being completely feasible for everyone with an USRP2 device, what permit you to make a MiTM attack to the GSM terminals, using OpenBTS and forwarding the calls through your own Asterisk PBX if needed. By the way, the USRP is a REALLY AMAZING device, I want one of those :-O it’s a really amazing device to play with radio networks, that’s BT, WiFi, GSM, and radio broadcasting… really cool, don’t you think?. If you’re interested in this subject, check the project page and don’t hesitate to colaborate with the calculation effort.
The last talk I attended today was the cat /proc/sys/net/ipv4/fuckups. Cool talk about how to bypass level 3/4 layer filters taking advance of a faulty Linux device driver of a Realtek giga network card, how to poison squid DNS cache, or how to execute arbitrary code on a remote IM client using the custom emoticons… nice talk, much in the style of “How to own…” book series, linking a bunch of isolated “epic fails” or misconfigurations to reveal a scenario in which taking advantage of all these bugs, one after the other, you can own the system. Nice talk, specially the explanation about the stupid and dangerous implementation of the MSN custom emoticons, so easy to own the remote IM client…
To end the night before going to the hostel, a late night Kebab at our usual place with Max, the guy from Austria that we met last year, and that we’ve met this year again in the CCC. Sai Emrys joined us in the Kebab place, and we had a cool talk about cryptography and the “free space filesystem” idea that he throw in his lightning talk of today, tomorrow he’ll talk about “how to create languages”.
Nice first day… I’m uploading this report while having the last beer in the hostel bar, goind to sleep() to have more hacker’s fun tomorrow morning… nice hacking!
Merry Xmas
My master and I want to wish you a merry christmas ;)
26th Chaos Communication Congress
Just in a week from now I’ll be in Berlin to attend 26C3. I’ll meet there with the rest of people that usually hang around during those days like in years past. I hope to see JAG and Holger there, Mega will miss the con this year, but LuY will come for his first time, so the group is in balance ;)
I’m trying to shape my personal schedule for those days, and I’ve got the feeling, for what I’ve seen so far, that this year’s fahrplan is a bit poor :( OK, OK… I know, usually the schedule changes a lot a couple of days before the congress get started, and all those blanks get filled with amazing and techie talks… but now, I got a lot of free time to hand around on Berlin.
OK, let’s see which talks I’ll attend next week:
Sunday December 27th:
- 12:45-15:00 (Saal 3) Lightning Talks
- 16:00-17:00 (Saal 3) ChaosVPN/Darknet/dn42
- 18:30-19:30 (Saal 1) Exposing crypto bugs through reverse engineering
- 20:30-21:30 (Saal 2) cat /proc/sys/net/ipv4/fuckups
- 21:45-22:45 (Saal 1) GSM: SRSLY?
- 22:45-23:45 (Saal 2) Coreboot
Monday December 28th:
- 11:30-12:30 (Saal 3) Building a debugger
- 12:45-14:45 (Saal 1) Google Lunar X Prize
- 17-15:18-15 (Saal 3) Advanced microcontroller programming
- 20:30-21:30 (Saal 1) Defending the poor
- 23:00-00:00 (Saal 2) SCCP & SS7 & SIGTRAN Hacking
Tuesday December 29th:
- 12:45-14:45 (Saal 3) Lightning Talks
- 16:00-17:00 (Saal 2) Playing with the GSM RF interface
- 17:15-18:10 (Saal 1) Using OpenBSC for fuzzing GSM handsets
- 18:30-19:30 (Saal 1) On kleptography & cryptovirology
- 20:30-21:30 (Saal 3) Location tracking
- 23:00-00:00 (Saal 1) Black Ops of PKI
Wednesday December 30th:
- 11:30-12:30 (Saal 2) secuBT
- 14:00-15:00 (Saal 1) JTAG Reverse Engineering
Well, this is my draft of personal schedule. I’m looking forward to attend the GSM & telephony talks as the ever funny Kaminsky show :)
See you there!
Rooted CON
Me acaba de llegar ahora mismo un E-Mail confirmando mi inscripción a la Rooted CON en la cual me registré hace unos días. Este evento tendrá lugar en Madrid, del 18 al 20 de Marzo de 2010. Aún no hay publicada agenda (ni oficial ni oficiosa) ni se sabe aún qué propuestas de las recibidas en respuesta al CFP han sido aceptadas (el plazo finaliza en un par de días, el 20 de Diciembre). Lo que sí es seguro es que, en cualquier caso, será un evento interesante. Es la primera vez que se celebra una “con” de este tipo en Madrid, y quién sabe… con el tiempo, y si esta primera edición sale bien y establece un buen precedente, puede que dentro de unos años tengamos en Madrid una “con” de la envergadura del CCC de Berlin, o la Defcon/Blackhat de Las Vegas. En cualquier caso, ¿vas a ir?, ¿aún no te has registrado? ¡nos vemos en la Rooted en Marzo!
Taking advantage of regexp for fun&profit
I’m gonna tell you a story, based on real events.
Let’s assume a big network, with a highly restrictive policy about who can access the Internet and which sites you can browse. The users can’t access the Internet directly from their workstations (from a layer 3 routing point of view) the only way out is using the corporate browser (an IE6 by the way) which is configured and locked to use a proxy to get access to the world out there.
This proxy is the typical corporate web proxy, I mean, it demands the user to authenticate before it grants access to the requested URL, that previous authentication avoids any anonymous surfing moreover it’s used to track how long the user has been surfing, the requested URL is checked against a set of rules based on regular expressions that allow the proxy admins to filter which URLs or sites are allowed. In practice only a bunch of sites and URLs are allowed by the security policy, so the “interesting” Internet is completely blocked by this ‘fraking’ proxy, no google, no webmail, no access to the server in your home, no pr0n, nothing… just a bunch of bored and only work-related URLs.
Of course, the only protocols allowed by this proxy are HTTP and HTTPS, and as the access to the Internet isn’t network routed from the point of view of the local workstation but proxified at the application level, SSH, the magic-hacker-tool for network tunneling, is useless too :(
Nothing new under the sun so far, we’ve got the typical corporate Internet access scenario based in a HTTP/HTTPS proxy… but there’s more, the foolish-admin-factor works in our favor :)
As an eager mind myself, I wanted to check how these rules were setup by the admin. I managed to get a user account in the proxy server, and of course the first thing that I did was to learn more about the proxy that was installed there finding the config file… and you know what? the file rights were rw-r–r–
I like this admin :) config files readable to everyone in the system. I guess (and now I know for sure) that the admin doesn’t care about these kind things, he should think that everybody is good in this world, that everybody agree with the restrictions and the rules… or maybe he thinks that nobody cares about his servers and his config files… well, he’s wrong!
Be able to read the config file isn’t a big deal if there’s nothing interesting in the file… but if reading the file reveals a bad configuration that creates a hole in the system, then it’s important! I’m talking about how the regular expressions in the filtering rules were coded by our dear admin.
Let’s say you want your users be able to access slashdot.org, a simple and easy way to write a regular expression to permit this could be one like this: http://.*\.slashdot.org/.*
What do you say if someone claims to filter the access with a rule like this one: .*slashdot.org.*
Not so clever, don’t you think? This rule just says: accept any URL that has the string slashdot.org and the dot isn’t really a dot, is any character as it isn’t escaped :)
OK, let’s say you got your own DNS domain, so you can create whatever DNS name you want in it. Let’s say your domain is itsucks.org so you can create the name slashdot.org.itsucks.org so that matches the filtering rule that our “savvy” admin has written in his proxy configuration file.
So, just creating the right name in our DNS pointing at the IP of one of our systems, we got a direct link between the “protected” inside workstation in the “highly restricted” inside network and our external server.
Note that we haven’t cracked, tampered or modified in any way the browser, the proxy or the network. We’ve just took advance of the misconfiguration to reach directly a machine under our control from our internal PC.
Of course, we could use our external server as a forward or reverse proxy to freely browse any site or page, or better than that, we could create a SSH tunnel or any other kind of VPN tunnel being able to connect through the HTTPS proxy to freely get any TCP connection out or even in.
If you have an Apache server running in your server, you can do the trick with a configuration like this:
<VirtualHost *:443>
SSLEngine On
SSLProtocol All -SSLv2
SSLCertificateFile /etc/apache2/ssl/cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/key.pem
ServerName slashdot.org.itsucks.org
ServerAdmin root@itsucks.org
ErrorLog /var/log/apache2/proxy/error.log
CustomLog /var/log/apache2/proxy/access.log common
ServerSignature On
ProxyRequests On
ProxyVia On
AllowCONNECT 22
<ProxyMatch slashdot.org.itsucks.org>
Order deny,allow
Deny from all
Allow from 1.2.3.4
</ProxyMatch>
</VirtualHost>
First of all, I didn’t want to move my SSH server from the 22/tcp to the 80/tcp or 443/tcp, doing that I could avoid the trick and connect directly to the SSH server, but I wanted to keep my HTTP/HTTPS ports for the web services so the connection redirection from Apache turn out to be pretty useful.
How it works:
A SSL virtual host is defined in the standard way on the 443/tcp port. The X.509v3 certificate and the private RSA key are created and defined. The server name is the one that is recognized as a valid and allowed external site by the corporate proxy as it matches the regular-expression filtering rules. This DNS name is resolved by our own DNS server to our own external server IP address. At this point, the HTTPS connection reach our Apache web server from our PC. The forward proxy feature is enabled with the ProxyRequests sentence but the access is denied from all but the IP address that we know is the public address of the corporate proxy that give us access to the Internet from the internal LAN.
The AllowCONNECT sentence is an interesting one, it defines which ports the proxy will be able to connect to when the HTTP CONNECT method is in use. In this case we’re interested in transport the SSH session inside the HTTPS session so when the connection ends in the Apache server and the SSH client sends the CONNECT method to connect to the SSH server, it’ll try to connect to the 22/tcp port so we’ve to permit it.
The last piece of this puzzle is the SSH client. Any client with HTTPS proxy support will do the trick. I got PuTTY in my PC which is perfect to do the trick. You only need to configure the corporate proxy in the Connection/Proxy preferences, try to connect to your server using the funny DNS name that matches the regexp and here you have!
Now, if you configure a tunnel using a local port to go out or a remote port to go in, or even if you use PuTTY as a socks server, you’ll have free rein.
Reto Hack-It de la Euskal Encounter 17
Dice el refrán popular que “más vale tarde que nunca” y en este caso particular más vale publicar la solución de este reto cinco meses después de la Euskal, que no hacerlo nunca :)
Este año, al igual que hice el año pasado, he realizado mi modesta aportación al Hack-It de la Euskal Encounter con una prueba para gozo y disfrute del personal que tuvo a bien participar en lo que, en mi opinión personal, es una de las mejores actividades que se realizan durante este evento y al que llevo acudiendo ya la friolera de 13 años si mi memoria no me falla. Agradecer a hey_neken el haber incorporado mi reto al Hack-It de este año.
Bien, basta de rollos, ¡pasemos a la acción! :)
El sufrido participante del Hack-It, una vez llega a mi prueba, se encuentra con que lo único que se le proporciona es una dirección IP, correspondiente al servidor del Hack-It en la LAN de la party, y un puerto TCP. Lógicamente, el primer paso es hacer uso de lo que nos dicen y conectar mediante un telnet a ver qué pasa. La conexión se establece sin problemas, apareciendo lo siguiente en el terminal desde el que realizamos el telnet:
# telnet 1.2.3.4 9999
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
CONNECTED
Enter received access code:
Nos pide que introduzcamos un código, pero no sabemos la longitud del mismo o incluso el juego de caracteres válido. De igual forma, en unos pocos segundos la conexión se corta, por lo que parece que hay un timeout definido, durante el cual es necesario que introduzcamos el código que nos pide. Ahora bien, ni en la página del reto se nos da pista alguna sobre este código, ni parece que haya información oculta de ningún tipo. Debe ser que hay que extraer algo más de información de esta conexión que establecemos, que parece que es lo único que tenemos en este momento para seguir investigando.
En retos de este tipo, siempre es buena idea tener un ojo en la red, ver qué se mueve por el cable (o las radiofrecuencias) más allá de lo que vemos, así que es buena idea repetir la conexión telnet pero con un sniffer capturando todo el diálogo, no sea que haya cosas que no vemos pero que nos pueden aportar información útil. Para ello, podemos usat tcpdump, snoop, wireshark o cualquier aplicación de captura de tráfico. Repetimos el telnet y veamos que se mueve por la red…
18:01:46.461990 IP 5.6.7.8.45385 > 1.2.3.4.55555: S 2307708527:2307708527(0) win 5840 <mss 1460,sackOK,timestamp 3301879450 0,nop,wscale 5>
18:01:46.650067 IP 1.2.3.4.55555 > 5.6.7.8.45385: S 2158051019:2158051019(0) ack 2307708528 win 5792 <mss 1460,sackOK,timestamp 1964456258 3301879450,nop,wscale 3>
18:01:46.650092 IP 5.6.7.8.45385 > 1.2.3.4.55555: . ack 1 win 183 <nop,nop,timestamp 3301879497 1964456258>
18:01:48.109403 IP 1.2.3.4.31337 > 5.6.7.8.31337: UDP, length 90
18:01:48.113211 IP 1.2.3.4.55555 > 5.6.7.8.45385: P 1:11(10) ack 1 win 724 <nop,nop,timestamp 1964456624 3301879497>
18:01:48.113228 IP 5.6.7.8.45385 > 1.2.3.4.55555: . ack 11 win 183 <nop,nop,timestamp 3301879862 1964456624>
18:01:48.306398 IP 1.2.3.4.55555 > 5.6.7.8.45385: P 11:39(28) ack 1 win 724 <nop,nop,timestamp 1964456673 3301879862>
18:01:48.306415 IP 5.6.7.8.45385 > 1.2.3.4.55555: . ack 39 win 183 <nop,nop,timestamp 3301879911 1964456673>
18:02:03.120239 IP 1.2.3.4.55555 > 5.6.7.8.45385: P 39:40(1) ack 1 win 724 <nop,nop,timestamp 1964460376 3301879911>
18:02:03.120293 IP 5.6.7.8.45385 > 1.2.3.4.55555: . ack 40 win 183 <nop,nop,timestamp 3301883614 1964460376>
18:02:03.124090 IP 1.2.3.4.55555 > 5.6.7.8.45385: FP 40:67(27) ack 1 win 724 <nop,nop,timestamp 1964460376 3301879911>
18:02:03.124220 IP 5.6.7.8.45385 > 1.2.3.4.55555: F 1:1(0) ack 68 win 183 <nop,nop,timestamp 3301883615 1964460376>
18:02:03.308138 IP 1.2.3.4.55555 > 5.6.7.8.45385: . ack 2 win 724 <nop,nop,timestamp 1964460423 3301883615>
Analicemos la captura, paso por paso:
- Los tres primeros paquetes intercambiados es el establecimiento de conexión TCP.
- Nada más establecerse la conexión con el servidor, éste nos envía un paquete UDP.
- Hay un intercambio de segmentos TCP, ya que el servidor también nos envía los datos correspondientes a lo que nos aparece en el terminal, la petición del código.
- Tras 15 segundos, durante los cuales nosotros no hacemos nada, el servidor finaliza la conexión.
¡Bingo!. ¿Qué es ese paquete UDP que nos envía el servidor cada vez que conectamos?. Si se hace un dump del contenido del paquete y se realizan varias conexiones para comparar varios paquetes UDP se advierte que:
- El juego de caracteres es limitado, aparece el espacio y los caracteres _ – |
- Siempre se devuelven 90 caracteres.
- Cada conexión devuelve una secuencia de caracteres distinta.
Por tanto, viendo esto, ¿estará el código codificado con esos caracteres?. Eso parece improbable, al igual que pensar que es algún tipo de cifrado, ya que la cadena que se devuelve en el paquete UDP desde el servidor únicamente hace uso de estos 4 caracteres (los tres tipos de barras y el espacio). Ahora bien, y si estos caracteres son una representación “gráfica” de algún tipo (ASCII art) del código. Eso podría ser… ;)
Si os digo “display de 7 segmentos”… ¿a que a muchos se os acaba de encender un LED de alta luminosidad sobre la cabeza? ;)
Pues efectivamente… lo que nos está llegando en el paquete UDP es la representación “7 segmentos” del código. Si intentamos “dibujar” un digito (suponemos inicialmente que el juego de caracteres del código es exclusivamente numérico) como lo hacen los displays de 7 segmentos en ASCII nos damos cuenta de que necesitamos 9 caracteres para “dibujar” el dígito. Por tanto, podemos suponer que nos están enviando una secuencia de 10 digitos.
Hagamos una prueba. Vamos a hacer el telnet, y en otro terminal, con un nc vamos a visualizar la secuencia de caracteres que nos llegan en el paquete UDP:
# nc -l -u -p 31337 > /tmp/datos.txt
# cat /tmp/datos.txt
_ _ _ _ _ _ _ _ |_ |_||_||_| | ||_| _|| ||_ |_||_| | | | ||_||_ |_||_|
Vamos a validar la teoría, reformateamos esta secuencia, insertando un CR/LF cada 30 caracteres y… ¡et voilà!
# cut -b1-30 </tmp/datos.txt; cut -b31-60 </tmp/datos.txt; cut -b61-90 </tmp/datos.txt
_ _ _ _ _ _ _ _ |_ |_||_||_| | ||_| _|| ||_ |_||_| | | | ||_||_ |_||_|
Ante nuestros ojos (para esto mejor tener una fuente de espaciado fijo) aparece la secuencia numérica, en este caso, 6894178206. Ahora bien, únicamente nos queda resolver un pequeño “problema”. La recepción del paquete UDP, decodificación de la secuencia y envío de la contestación debe, de alguna forma, automatizarse para poder realizar toda esta secuencia de pasos dentro del timeout que cierra la conexión, o bien ser muy rápidos cambiando de un terminal a otro y tecleando el código :)
Por cierto, recordad que cada vez que nos conectamos la secuencia numérica cambia, por lo que no vale eso de conectarse, capturar y decodificar, volver a conectarse y dar como respuesta el código enviado en la conexión anterior… el malvado diseñador del reto nos obliga a programar para automatizar la decodificación, jeje ;)
Hacemos el programa, se conecta, decodifica la secuencia, la devuelve y… ¡mierda! esto aún no ha terminado, obtenemos nueva información en nuestro terminal ;)
Access Granted!
Your code is correct, use it to select the right characters and get the passphrase ;)
0 1 2 3 4 5 6 7 8 9 0 M V U S H c C s L D 1 L T J r U X d P o p 2 m Y O o q t A N j d 3 A x h W e q A s k N 4 A O j J q F g V X i 5 O N K f D F c F S N 6 S U M B r g r t H f 7 J c e s l W B V t Y 8 L M n S r r Z V x u 9 k T Q w W L L P H L
NO CARRIER
La conexión se corta tras presentar esta matriz de caracteres. De nuevo, con cada conexión tanto el código numérico como la matriz de caracteres que se obtiene al devolver el código correctamente cambia. la passphrase del nivel está oculta dentro de esa matriz de caracteres, así que parece que hay que seleccionar la secuencia de caracteres correcta para obtener la passphrase alfanumérica del nivel, y así continuar con el siguiente reto.
¿Qué coordenadas elegir?, ¿qué fila y columna seleccionar y en qué orden?… Parece lógico pensar que el código numérico y la matrix están relacionados, además ambos cambian con cada conexión. La matriz de caracteres además viene indexada del 0 al 9 tanto para filas como para columnas… ¿y si el código numérico nos indica la fila y la columna de cada caracter de la passphrase que buscamos?
Siguiendo con el razonamiento anterior, y tras algunas pruebas fallidas hasta que damos con la lógica del maquiavélico diseñador del reto ;) damos con la solución. Cada digito del código indica la columna que se debe seleccionar en cada una de las filas, y esto nos permite extraer los caracteres de la matriz. En este ejemplo concreto, los caracteres correctos son los correspondientes a las posiciones:
Caracter 0 = Fila 0, Columna 6 => C
Caracter 1 = Fila 1, Columna 8 => o
Caracter 2 = Fila 2, Columna 9 => d
Caracter 3 = Fila 3, Columna 4 => e
Caracter 4 = Fila 4, Columna 1 => O
Caracter 5 = Fila 5, Columna 7 => F
Caracter 6 = Fila 6, Columna 8 => H
Caracter 7 = Fila 7, Columna 2 => e
Caracter 8 = Fila 8, Columna 0 => L
Caracter 9 = Fila 9, Columna 6 => L
La passphrase buscada en este caso concreto es… CodeOFHeLL
Espero que os haya gustado, y a los que la pasastéis en el Hack-It de la Euskal, espero que os divirtiese romper este reto :)
Transmisión #42 de El Geek Errante
El Geek Errante ha vuelto :)
Tras más de un año y medio en “animación suspendida”, los integrantes de El Geek Errante volvemos a la carga, en lo que se podría denominar el comienzo de la “segunda temporada” :)
Los motivos por los cuales se ha producido este corte en nuestras transmisiones han sido tanto de caracter profesional, como de caracter personal, en todos y cada uno de los integrantes de la tripulación. Al final se nos hacía muy complicado el poder preparar y grabar el podcast semana tras semana, con los contenidos y nivel de calidad que le queríamos dar, así que hemos tenido que esperar todo este tiempo hasta que el ordenador central de la nave ha visto que disponiamos de ciclos de CPU suficientes como para poder abordar de nuevo esta tarea con garantías y nos ha sacado de nuestro estado de ibernación :)
En esta segunda temporada, el formato se mantendrá casi sin variación respecto a nuestras transmisiones previas y la periodicidad es la que pasará a ser mensual en vez de anual. Lógicamente las noticias que demos no serán tanto de actualidad, como antes, y pasaremos a tratar temas más “atemporales” en lo relativo a noticias, y por supuesto mantendremos nuestro formato de monográficos-tecnológicos de las cosas que nos gustan y que sabemos que a vosotros también os interesan ;)
Pues nada… que aquí estamos de nuevo. Agradecer a todos los que durante todo este tiempo habéis insistido en que grabásemos de nuevo, nos habéis preguntado, animado… ¡muchas gracias!
[ ADVERTISEMENT MODE: ON ]
Disponible la transmisión #42 de tu podcast favorito: El Geek Errante.
[ ADVERTISEMENT MODE: OFF ]