Into.the.Void.

The title may sound a bit pompous, but please read on and you’ll see how certain decisions can cripple, or totally disrupt modern Internet services and communications as these are offered(?) by Vodafone’s mobile Internet solutions.

== The situation ==
I’ve bought a mobile Internet package from Vodafone Greece in order to be able to have 3G access in places where I don’t have access to wifi or ethernet. I am also using a local caching resolver on my laptop (Debian Linux), running unbound software, to both speed up my connections and to have mandatory DNSSEC validation for all my queries. Many of you might ask why do I need DNSSEC validation of all my queries since only very few domains are currently using DNSSEC, well I don’t have a reply that applies to everyone, let’s just say for now that I like to experiment with new things. After all, this is the only way to learn new things, experiment with them. Let’s not forget though that many TLDs are now signed, so there are definitely a few records to play with. Mandatory DNSSEC validation has led me in the past to identify and investigate a couple other problems, mostly having to do with broken DNSSEC records of various domains and more importantly dig deeper into IPv6 and fragmentation issues of various networks. This last topic is so big that it needs a blog post, or even a series of posts, of it’s own. It’s my job after all to find and solve problems, that’s what system or network administrators do (or should do).

== My setup ==
When you connect your 3G dongle with Vodafone Greece, they sent you 2 DNS servers (two out of 213.249.17.10, 213.249.17.11, 213.249.39.29) through ipcp (ppp). In my setup though, I discard them and I just keep “nameserver 127.0.0.1” in my /etc/resolv.conf in order to use my local unbound. In unbound’s configuration I have set up 2 forwarders for my queries, actually when I know I am inside an IPv6 network I use 4 addresses, 2 IPv4 and 2 IPv6 for the same 2 forwarders. These forwarders are hosted where I work (GRNET NOC) and I have also set them up to do mandatory DNSSEC validation themselves.
So my local resolver, which does DNSSEC validation, is contacting 2 other servers who also do DNSSEC validation. My queries carry the DNS protocol flag that asks for DNSSEC validation and I expect them to validate every response possible.

As you can see in the following screenshot, here’s what happens when I want to visit a website. I ask my local caching resolver, and that resolver asks one of it’s forwarders adding the necessary DNSSEC flags in the query.
The response might have the “ad” (authenticated) DNSSEC flag, depending whether the domain I’m visiting is DNSSEC signed or not.

[Screenshot of DNS queries]

== The problem ==
What I noticed was that using this setup, I couldn’t visit any sites at all when I connected with my 3G dongle on Vodafone’s network. When I changed my /etc/resolv.conf to use Vodafone’s DNS servers directly, everything seemed work as normal, at least for browsing. But then I tried to query for DNSSEC related information on various domains manually using dig, Vodafone’s resolvers never sent me back any DNSSEC related information. Well actually they never sent me back any packet at all when I asked them for DNSSEC data.

Here’s an example of what happens with and without asking for DNSSEC data. The first query is without requesting DNSSEC information and I get a normal reply, but upon asking for the extra DNSSEC data, I get nothing back.
[Screenshot of ripe.net +dnssec query through Vodafone’s servers]

== Experimentation ==
Obviously changing my forwarders configuration in unbound to the Vodafone DNS servers did not work because Vodafone’s DNS servers never send me back any DNSSEC information at all. Since my unbound is trying to do DNSSEC validation of everything, obviously including the root (.) zone, I need to get back packets that contain these records. Else everything fails. I could get unbound working with my previous forwarders or with Vodafone’s servers as forwarders, only by disabling the DNSSEC validation, that is commenting out the auto-trust-anchor-file option.

Then I started doing tests on my original forwarders that I had in my configuration (and are managed by me). I could see that my query packets arrived at the server and the server always sent back the proper replies. But whenever the reply contained DNSSEC data, that packet was not forwarded to my computer through Vodafone’s 3G network.

More tests were to follow and obviously my first choice were Google’s public resolvers, 8.8.8.8 and 8.8.4.4. Surprise, surprise! I could get any DNSSEC related information I wanted. The exact same result I got upon testing with OpenDNS resolvers, 208.67.222.222 and 208.67.220.220. From a list of “fairly known” public DNS servers that I found here, only ScrubIT servers seems to be currently blocked by Vodafone Greece. Comodo DNS, Norton DNS, and public Verizon DNS all work flawlessly.

My last step was to try and get DNSSEC data over tcp instead of udp packets. Surprise, surprise again, well not at all any more… I could get back responses containing the DNSSEC information I wanted.

== Conclusion ==
Vodafone Greece for some strange reason (I have a few ideas, starting with…disabling skype) seems to “dislike” large UDP responses, among which are obviously DNS replies carrying DNSSEC information. These responses can sometimes be even bigger than 1500bytes. My guess is that in order to minimize hassle for their telephone support, they have whitelisted a bunch of “known” DNS servers. Obviously the thought of breaking DNSSEC and every DNSSEC signed domain for their customers hasn’t crossed their minds yet. What I don’t understand though is why their own DNS servers are not whitelisted. Since they trust other organizations’ servers to send big udp packets, why don’t they allow DNSSEC from their own servers? Misconfiguration? Ignorance? On purpose?

The same behavior can (sometimes -> further investigation needed here) be seen while trying to use OpenVPN over udp. Over tcp with the same servers, everything works fine. That reminds me I really need to test ocserv soon…

== Solution ==
I won’t even try to contact Vodafone’s support and try to convince their telephone helpdesk to connect me to one of their network/infrastructure engineers. I think that would be completely futile. If any of you readers though, know anyone working at Vodafone Greece in _any_ technical department, please send them a link to this blog post. You will do a huge favor to all Vodafone Greece mobile Internet users and to the Internet itself.

The Internet is not just for HTTP stuff, many of us use it in various other ways. It is unacceptable for any ISP to block, disrupt, interrupt or get in the middle of such communications.
Each one of us users should be able to use DNSSEC without having to send all our queries to Google, OpenDNS or any other information harvesting organization.

== Downloads ==
I’m uploading some pcaps here for anyone who wants to take a look. Use wireshark/tcpdump to read them.

A. tcpdump querying for a non-DNSSEC signed domain over 3G. One query without asking for DNSSEC and two queries asking for DNSSEC, all queries go to DNS server 194.177.210.10. All queries arrived back. The tcpdump was created on 194.177.210.10.
vf_non-dnssec_domain_query.pcap

B. tcpdump querying for a DNSSEC signed domain over 3G. One query without asking for DNSSEC and three queries asking for DNSSEC, all queries go to DNS server 194.177.210.10. The last three queries never arrived back at my computer. The tcpdump was created on 194.177.210.10.
vf_dnssec_domain_query.pcap

C. tcpdump querying for a DNSSEC signed domain over 3G. One query without asking for DNSSEC and another one asking for DNSSEC, all queries go to DNS Server 8.8.8.8. All queries arrived back. The tcpdump was created on my computer using the PPP interface.
vf_ripe_google_dns.pcap

Filed by kargig at 11:11 under Encryption,Greek,Internet,Linux,Networking,Privacy
Tags: dig, dns, dnssec, Linux, pcap, tcpdump, unbound, validation, vodafone, Vodafone Greece, wireshark
3 Comments | 24,226 views

Some months ago I started playing with the idea of creating a world map that would have every Tor node on it. Obviously I wan’t the first one…I soon discovered Moritz Bartl’s post on the same topic. Luckilly he had his code posted on Github so I could fork it and add features that I wanted. The original python script parsed the consensus and the misrodescriptors, put Tor nodes into some classes and created a KML file with some description on each node.

Some differences
I changed some parts of the python script to better suit my needs.
a. Create a separate kml files for each Tor node class.
b. Add new classes: Bad, Authority and Named.
c. Pay more attention on requesting every external URL over HTTPS.
d. Generate HTML code that displays those KMLs on a Google Maps overlay.
e. Add some small randomization to each nodes’s coordinates so that nodes in the same city don’t overlap.

You can find a complete changelog at kargig/tormap GitHub repo.

And here’s the outcome: World city map of Tor nodes at https://tormap.void.gr/
One of my main goals was to have selectable classes of nodes that will appear on the map.

To produce the map overlay, a cron script runs every hour, which is also the period it takes for Tor Authority nodes to produce a new consensus, and creates some static files which are then served by nginx.

I’m not a web developer/designer and I don’t really know any javascript. So please, feel free to fork my code and make it look better, run faster and add your own features. I’ll happily accept patches/pull requests!

Extras
On kargig/tormap repo you will also find a handy script, ‘runme.sh’, that downloads all necessary files that need to be parsed by the python script.

Missplaced nodes on the map
Well, blame MaxMind’s GeoIP City database for that. But I think it’s kinda funny to see Tor nodes in Siberia and in the middle of the sea though (look at the West coast of Africa), heh. For those wondering, these nodes are gathered there because their geoip Lat,Long is set to 0,0.
Really though, what’s “Ben’s Cat Shaque” diplayed there next to all those nodes in the west coast of Africa? Anyone has some clue ?

Conspriracy people
I’m sure that people who love conspriracy theories will start posting about those ‘Bad’ Tor nodes in Iran and Syria. Why do you think these are there ? What does it mean ? Let the flames begin!

Future TODO
a. OpenStreetMap
I have started working on an OpenStreetMap implementation of the above using OpenLayers. The biggest hurdle is that OSM does not provide a server that serves map tiles over HTTPS. Makes me wonder…is that actually so difficult ?
b. More stats
I would like to add small graphs on how the number of nodes in each class evolves.

Other Tor mapping efforts
https://b.kentbackman.com/2010/10/04/view-tor-exit-nodes-in-google-earth/
http://freehaven.net/~ioerror/maps/v3-tormap.html

Don’t forget, you can always help Tor by running a node/bridge or sending some money to Tor or EFF!

Filed by kargig at 01:55 under Encryption,Internet,Linux,Networking,Privacy
Tags: Authority, Bad, consensus, debian, geoip, geoipcity, Google maps, html, javascript, map, mapping, maxmind, nginx, OpenStreemMap, python, tor, tormap, tormap.void.gr
1 Comment | 23,632 views

On Sunday the 11th of November we finally had our first CryptoParty in Athens, Greece. We hosted it at the Athens Hackerspace.

Organizing
We organized our first CryptoParty in a very ad-hoc way. A pad was set up and advertised on Twitter/Facebook. Almost immediately people started writing their thoughts, views and interests there. We soon had a list of topics that people were interested in and another list of people willing to give presentations/workshops. Later on we set up a doodle so people would choose the most convenient dates for them. From the group of 50 people that originally expressed their interest to attend the CryptoParty, at least 20 voted on the doodle. That’s how the final date of November the 11th was chosen.

It was surprising/refreshing that even though everything was organized through an anonymously editable pad, nobody tried to vandalize it.

The actual event
Through the pad, we chose 3 topics for the first meeting. “Using SSL/TLS for your Internet communications”, an “introduction to Tor” and another “introduction to I2P”.
The time for the event was set for 12:00 in the morning, probably a very bad choice. The next one should definitely be later in the afternoon or even night. We learn by our mistakes though…People started showing up at around 11:30, but the event didn’t start until 12:30 when someone from hackerspace.gr gave a 5′ intro talk about what the hackerspace is to people who had never been there before. People kept coming even until 13:00 and the audience had grown to more than 30 people.
After the three workshops/presentations around 10-15 people stayed and we ordered pizza.

All in all I’d say it was fairly successful since more than 30 people came and actually did things to improve their security.

The presentations/workshops
“Using SSL/TLS for your Internet communications” (in English) was my effort to show people how cleartext data travels through the Internet and how any intermediate “bad guy”/LEA can easily read or manipulate your data. People were instructed to install wireshark so they could actually see for themselves what the actual problem is. It was very “nice” to see their surprise upon watching cleartext packets flowing through their network cards. It was even nicer to see their surprise when I used tcpdump on hackerspace’s router to redirect traffic to wireshark running on a Debian laptop to display their data, without having “direct” access to their computer. Then people were introduced to the idea of Transport Layer Security (SSL/TLS), and how HTTPS protects their web data from prying eyes. After this tiny “privacy apocalypse” it was very easy to convince users to install HTTPS-Everywhere. And so they did. Afterwards they got instructions on how they should change SSL/TLS settings for their E-email and IM clients.
My original intention was to “scare” people a bit. It was funny to see their faces when they logged in to yahoo mail and they could see their emails cleartext on wireshark. People don’t understand how data travels through the Internet unless they experience it for themselves. I’m glad that people who had absolutely no idea about HTTPS are now using HTTPS-Everywhere to protect themselves. Hopefully they’ll show that to their friends as well.

“Introduction to Tor” (in Greek) gave people an idea at what anonymity is, how it differs from security and how users should be combining both TLS and Tor usage for security and anonymity at the same time. A brief explanation of what hidden services are was given as well. Even though George asked people to download and install Tor Browser Bundle and use it, we’ll definitely need more “hands on” Tor workshops in the future. It will be interesting to convince more people to actually use it and why not, even set up their own hidden services.

“Invisible Internet Project a.k.a. I2P” (in English) by @alafroiskiotos was probably the hardest of the three presentations to keep up for people that had no previous idea about anonymity networks. It’s unique architecture and some difficulties in it’s usage raised a lot of interesting questions by attendees.

Thoughts on future CryptoParties
After the end of the workshops/presentations we had a lengthy discussion with the attendees as to what they would like to see/experience in the future CryptoParties. Unfortunately people were not very vocal. Very few participated and openly expressed their thoughts/opinions. A great part of the discussion was spent trying to figure out whom should CryptoParty presentations/workshops target at, users? developers? geeks? It’s obviously very hard to target all groups of people at the same time.

So here are my thoughts on what future CryptoParties should be. CryptoParties should be about changing user habits, they should be closer to workshops than presentations. They should be focused mainly on users not developers nor computer science students. Just simple users. People don’t want theoretical talks about cryptography, they need advice they can use in their daily lives. It’s already very hard to talk about modern crypto to people who haven’t got a strong mathematical background, you have to oversimplify things. Oversimplifying things then makes geeks/nerds unhappy and still doesn’t “teach” people about proper crypto. Even a fairly “simple” HTTPS negotiation contains key crypto concepts that are very difficult for a “crypto-newbie” to grasp. So it’s a lose-lose situation.

We need to teach, or better convince, users on using good, secure, audited tools and not just tell them about technologies and concepts. We, weirdos, might like that, but most users don’t. People need our help to learn how to avoid “fancy” tools and false security prophets. We need to show them how security should be applied in a layered approach. Getting people to care about their own privacy is key to the success of CryptoParties in the way I see them. To achieve that, we, people that know a few things more than the average Joe, should all become volunteers to such efforts. We should be joining CryptoParties in order to help others and not in order to improve ourselves and our knowledge. (Actually when you study in order to make a good workshop/presentation you improve your own knowledge as well, but let’s leave that beside for now.) We can have our separate geeky/nerdy events to present fancy tech and cool crypto stuff, but let’s keep CryptoParties simple and practical. Oh and we’ll need to repeat things again and again and again. That’s the only way people might change their habits.

If you want to find out more about the next Athens CryptoParty keep an eye at Hackerspace’s events and the athens cryptoparty pad. Join us!

Good luck to all the CryptoParties worldwide!

Filed by kargig at 21:23 under Encryption,Internet,Linux,Networking,Privacy
Tags: anonymity, athens, CryptoParty, HSTS, https, HTTPS-Everywhere, I2P, Networking, presentation, Privacy, security, SSL/TLS, tcpdump, tor, wireshark, workshop
No Comments | 10,034 views

*WARNING* 14/01/2014 This post is quite deprecated. For example obfsproxy has been completely rewritten in python and there is a newer and more secure replacement of obfs2, named obfs3. Please read this obfsproxy-debian-instructions for any updates.

Some countries like China, Iran, Ethiopia, Kazakhstan and others, like installing some nasty little boxes at the edges of their country’s “internet feed” to monitor and filter traffic. These little boxes are called DPI (Deep Packet Inspection) boxes and what they do, is sniff out every little packet flowing through them to find specific patterns and then they provide their administrator with the option to block traffic that matches these patterns. These boxes are very sophisticated and they don’t just filter traffic by src, dst or port, they filter traffic by the content (payload) the packets carry.
Unfortunately, it’s not just these countries that deploy DPI technologies, but some private companies also use such devices in order to monitor their employees.

The 10 thousand feet view
Tor is a nice way to avoid basic censorship technologies, but sometimes DPI technology is so good that it can fingerprint Tor traffic, which is already encrypted, and block it. In response to that, Tor people devised a technology called Pluggable Transports whose job is to obfuscate traffic in various ways so that it looks like something different than it actually is. For example it can make Tor traffic look like a skype call using SkypeMorph or one can use Obfsproxy to obfuscate traffic to look like…nothing, or at least nothing easily recognizable. What’s cool about obfsproxy though is that one can even use it separately from Tor, to obfuscate any connection he needs to.

A warning
Even though obfsproxy encrypts traffic and makes it look completely random, it’s not a fool proof solution for everything. It’s basic job is to defend against DPI that can recognize/fingerprint TLS connections. If someone has the resources he could potentially train his DPI box to “speak” the obfsproxy protocol and eventually decrypt the obfuscated traffic. What this means is that obfsproxy should not be used as a single means of protection and it should just be used as a wrapper _around_ already encrypted SSL traffic.
If you’re still in doubt about what can obfsproxy protect you from and from what it can’t, please read the Obfsproxy Threat Model document.

Two use cases
Obfuscate an SSH and an OpenVPN connection.
Obviously one needs a server outside the censorship perimeter that he or someone else will run the obfsproxy server part. Instructions on installing obfsproxy on Debian/Ubuntu are given in my previous blog post setting up tor + obfsproxy + brdgrd to fight censhorship. Installing netcat, the openbsd version; package name is netcat-openbsd on Debian/Ubuntu, is also needed for the SSH example.

What both examples do is obfuscate a TLS connection through an obfsproxy server so that it looks innocent. Assuming that the most innocent looking traffic is HTTP, try running the obfsproxy server part on port 80.

SSH connection
Scenario:
USER: running ssh client
HOST_A (obfsproxy): running obfsproxy on port 80 and redirecting to HOST_B port 22
HOST_B (dst): Running SSH server on port 22

What one needs to do is setup the following “tunneling”:
ssh client —> [NC SOCKS PROXY] —> obfsproxy client (USER)—> obfsproxy server (HOST_A) —> ssh server (HOST_B)

Steps:
1. on HOST_A setup obfsproxy server to listen for connection and redirect to HOST_B:
# screen obfsproxy --log-min-severity=info obfs2 --dest=HOST_B:22 server 0.0.0.0:80

2. on USER’s box, then configure obfsproxy client to setup a local socks proxy that will obfuscate all traffic passing through it:
$ screen obfsproxy --log-min-severity=info obfs2 socks 127.0.0.1:9999
Then instead of SSH-ing directly to HOST_B, the user has to ssh to HOST_A port 80 (where obfsproxy server is listening).

3. on USER’s box again, edit ~/.ssh/config and add something along the following lines:

Host HOST_A
    ProxyCommand /bin/nc.openbsd -x 127.0.0.1:9999 %h %p

This will force all SSH connections to HOST_A to pass through the local (obfsproxy) socks server listening on 127.0.0.1:9999

4. Finally run the ssh command:
$ ssh -p 80 username@HOST_A

That’s it. The connection will now pass get obfuscated locally, pass through obfsproxy server at HOST_A and then finally reach it’s destination at HOST_B.

OpenVPN connection
Scenario:
USER: running OpenVPN client
HOST_A (obfsproxy): running obfsproxy on port 80 and redirecting to HOST_B TCP port 443
HOST_B (dst): Running OpenVPN server on port 443

What one needs to do is setup the following “tunneling”:
openvpn client —> obfsproxy client (USER)—> obfsproxy server (HOST_A) —> OpenVPN server (HOST_B)

Steps:
1. on HOST_A setup obfsproxy server to listen for connection and redirect to HOST_B:
# screen obfsproxy --log-min-severity=info obfs2 --dest=HOST_B:443 server 0.0.0.0:80

2. on USER’s box, then configure obfsproxy client to setup a local socks proxy that will obfuscate all traffic passing through it:
$ screen obfsproxy --log-min-severity=info obfs2 socks 127.0.0.1:9999
Then instead of connecting the OpenVPN client directly to HOST_B, the user has edit OpenVPN config file to connect to HOST_A port 80 (where obfsproxy server is listening).

3. on USER’s box again, edit your openvpn config file, change the ‘port’ and ‘remote’ lines and add a ‘socks-proxy’ one:

port 80
remote HOST_A
socks-proxy 127.0.0.1 9999

This will instruct the OpenVPN client to connect to HOST_A passing through the local (obfsproxy) socks server listening on 127.0.0.1:9999

4. Finally run the openvpn client command:
$ openvpn client.config

That’s it.

Security Enhancement
You can “enhance” obfproxy’s security by adding a shared secret parameter to command line, so anyone who doesn’t have this secret key won’t be able to use the obfsproxy server, decryption of packets will fail:
# screen obfsproxy --log-min-severity=info obfs2 --shared-secret="foobarfoo" --dest=HOST_B:443 server 0.0.0.0:80
$ screen obfsproxy --log-min-severity=info obfs2 --shared-secret="foobarfoo" socks 127.0.0.1:9999

Documentation
Or at least…some documentation.

Your best chance to understand the internals of obfsproxy is to read the protocol specification

For more info about obfsproxy client part, read the documentation here: obfsproxy client external
For more info about obfsproxy server part, read the documentation here: obfsproxy server external

Screenshots
For those who like meaningless screenshots, here’s what wireshark (which is certainly NOT a DPI) can tell about a connection without and with obfsproxy:

Without obfsproxy

With obfsproxy

*Update*
one can find openvpn configuration files for use with obfsproxy here:
Linux Client
Windows Client

Filed by kargig at 01:54 under Encryption,Internet,Linux,Networking,Privacy
Tags: censorship, china, debian, Encryption, firewall, gfw, Linux, Networking, obfsproxy, openvpn, Privacy, security, ssh, tls, tor, vpn
5 Comments | 70,352 views

*WARNING* 14/01/2014 This post is quite deprecated. For example obfsproxy has been completely rewritten in python and there is a newer and more secure replacement of obfs2, named obfs3. Please read this obfsproxy-debian-instructions for any updates.

*Updated* look at the bottom for list of changes

This post is a simple guide to create a debian/ubuntu packages out of the latest versions of Tor, obfsproxy and brdgrd in order to setup a “special gateway” and help people who face censorship issues. Sharing some of your bandwidth helps a lot of people get back their freedom.

Tor
I guess most people already know what Tor is, quoting from Tor’s website:

Tor is a network of virtual tunnels that allows people and groups to improve their privacy and security on the Internet. It also enables software developers to create new communication tools with built-in privacy features. Tor provides the foundation for a range of applications that allow organizations and individuals to share information over public networks without compromising their privacy.

obfsproxy

obfsproxy is a tool that attempts to circumvent censorship, by transforming the Tor traffic between the client and the bridge. This way, censors, who usually monitor traffic between the client and the bridge, will see innocent-looking transformed traffic instead of the actual Tor traffic.

brdgrd

brdgrd is short for “bridge guard”: A program which is meant to protect Tor bridges from being scanned (and as a result blocked) by the Great Firewall of China.

Combining these to work together is quite easy if you follow this simple guide/howto.

////// Become root
$ sudo su -

////// Get build tools/packages
# cd /usr/src/
# apt-get install build-essential libssl-dev devscripts git-core autoconf debhelper autotools-dev libevent-dev dpatch pkg-config
# apt-get install hardening-includes asciidoc docbook-xml docbook-xsl xmlto
# apt-get install screen libnetfilter-queue-dev

////// Get latest versions of tor/obfsproxy/brdgrd
# git clone https://git.torproject.org/debian/obfsproxy.git
# git clone https://git.torproject.org/debian/tor.git
# git clone https://git.torproject.org/brdgrd.git

////// Compile obfsproxy & create package
# cd obfsproxy/
# ./autogen.sh 
# debuild -uc -us 

////// Compile tor & create package
# cd ../tor/
# ./autogen.sh 
# debuild -uc -us 

////// Install packages
////// The following package versions might be different depending on your configuration. Change them appropriately by looking at the deb files in your path: ls *.deb

# cd ..
# dpkg -i tor-geoipdb_0.2.4.3-alpha-1_all.deb obfsproxy_0.1.4-2_amd64.deb tor_0.2.4.3-alpha-1_amd64.deb

////// Create Tor configuration
////// PLEASE SEE THE CHANGEME_X VARIABLE BELOW BEFORE RUNNING THE FOLLOWING COMMAND

# cat > /etc/tor/torrc << EOF 
AvoidDiskWrites 1
DataDirectory /var/lib/tor
ServerTransportPlugin obfs2 exec /usr/bin/obfsproxy --managed
Log notice file /var/log/tor/notices.log
## If you want to enable management port uncomment the following 2 lines and add a password
## ControlPort 9051
## HashedControlPassword 16:CHANGEME
## CHANGEME_1 -> provide a nickname for your bridge, can be anything you like.
Nickname CHANGEME_1
## CHANGEME_2 -> How many KB/sec will you share. Don't be stingy! Try putting _at least_ 20 KB.
RelayBandwidthRate CHANGEME_2 KB
## CHANGEME_3 -> Put a slightly higher value than your previous one. e.g if you put 500 on CHANGEME_2, put 550 on CHANGEME_3.
RelayBandwidthBurst CHANGEME_3 KB
ExitPolicy reject *:* 
## CHANGEME_4 -> If you want others to be able to contact you uncomment this line and put your GPG fingerprint for example.
#ContactInfo CHANGEME_4
ORPort 443 
#ORPort [2001:db8:1234:5678:9012:3456:7890:1234]:443
BridgeRelay 1
## CHANGEME_5 -> If you don't want to publish your bridge in BridgeDB, so you can privately share it with your friends uncomment the following line
#PublishServerDescriptor 0
EOF

////// Restart Tor

# /etc/init.d/tor restart

////// Compile and run brdgrd
////// If you've changed ORport in Tor config above, be sure to change the "--sport 443" port below as well
////// brdgrd does not help since obfsproxy is already running in front of the bridge, but won't hurt either.

# cd brdgrd/
# make
# iptables -A OUTPUT -p tcp --tcp-flags SYN,ACK SYN,ACK --sport 443 -j NFQUEUE --queue-num 0
////// brdgrd Can't do IPv6 yet...so the next line is commented out
////// ip6tables -A OUTPUT -p tcp --tcp-flags SYN,ACK SYN,ACK --sport 443 -j NFQUEUE --queue-num 0
////// You can run brdgrd without root, just by setting some correct cap_net_admin rights
////// Instead of: screen -dmS brdgrd ./brdgrd -v
$ sudo screen -dmS brdgrd setcap cap_net_admin=ep ./brdgrd -v

# tail -f /var/log/tor/notices.log

The above guide has been tested on Debian Squeeze and Ubuntu 12.04.

That’s it. You just made the world a better place.

*Update*
I’ve made some changes to the post according to comments on the blog post and #tor-dev.
a) Changed URLs for the git clone operations to https:// instead of git://
b) Changed brdgrd git url to gitweb.torproject.org instead of github.
c) Changed config sections of torrc file
d) Added some more info on brdgrd

*Update2*
Tor has published “official” instructions for setting up obfsproxy bridges on Debian boxes –> Setting up an Obfsproxy Bridge on Debian/Ubuntu

*Update3*
Update sample config to inform about unpublished bridges.

Filed by kargig at 18:50 under Encryption,IPv6,Linux,Networking,Privacy
Tags: 12.04, brdgrd, bridgedb, censorship, debian, guide, HOWTO, ipv6, Linux, obfsproxy, Precise Pangolin, Privacy, Squeeze, tor, ubuntu
7 Comments | 30,736 views

I’ve just uploaded an experimental version of HTTPS-Everywhere Google Chrome extension containing Greek rules.

You can find it on https-everywhere-greek-rules downloads page on github.

To install it, download the .crx from github, open Extensions Settings and drag the downloaded .crx on the Extensions page. It will prompt you to install it.

After installation you can visit www.void.gr or www.nbg.gr to test it. You should be seeing a new icon on the left of the url bar to notify you that HTTPS-Everywhere applied some rules.

I’ve tested it on Google Chrome Version 21 on Linux and it seems to work ok. If you have any problems open up an issue on github.

Happy safer surfing…

Filed by kargig at 14:13 under Encryption,Greek,Internet,Networking,Privacy
Tags: Greek, https, HTTPS-Everywhere, Linux, ssl
2 Comments | 13,666 views

HTTPS Everywhere is a browser addon by EFF whose job is to redirect you to the HTTPS versions of certain, whitelisted, web sites. What this means is that HTTPS Everywhere protects your communication with those websites by forcing them to be encrypted.

The current HTTPS Everywhere ruleset lacks any Greek websites, so I started yet-another-list to create rules for Greek websites. This is the fourth list I’m maintaing after GrRBL, Greek Spammers Blacklist and Greek AdblockPlus Filter rules and it is the only one where being included is actually a good thing.

You can find some more info about Greek rules for HTTPS Everywhere on my github page.

Until the rules get adopted upstream by HTTPS Everywhere team, in order to use them you should download the rules and place them inside your Firefox profile directory. But first of all you need to install the plugin/extension/addon/call-me-whatever-you-want by going to HTTPS Everywhere page.

Step 1: Instructions for Linux users
Go to the HTTPSEverywhereUserRules directory inside your firefox profile directory:

$ cd .mozilla/firefox/XYZXYZXYZ.default/HTTPSEverywhereUserRules/
(XYZXYZXYZ will be different in your machine)

and download the current Greek ruleset:
$ wget https://raw.github.com/kargig/https-everywhere-greek-rules/master/Greek.xml

Step 1: Instructions for Windows users
Download https://raw.github.com/kargig/https-everywhere-greek-rules/master/Greek.xml with your favorite browser.
Then, according to this Mozilla support page, open Fifefox, go to Help->Troubleshooting Information and under the Application Basics section, click on Open Containing Folder. There a window will appear and you should copy the previously downloaded Greek.xml file inside the HTTPSEverywhereUserRules folder.

Step 2: Instructions for any OS
Either restart your browser to load the new rules or click the HTTPS Everywhere icon beside the url bar, select “Disable HTTPS Everywhere”, then click it again and select “Enable HTTPS Everywhere”. The new rules should now be loaded, you can test by going to http://void.gr and it should immediately redirect you to https://void.gr

Some notes
The ruleset is experimental. If you find any problems please report them as issues to github.
If you want a Greek website added to the list, either report it as a new issue on github or fork the repository, add your own rules and open a pull request.

A small rant
I found some webmails in Greece that don’t even offer HTTPS as an option to the user. They ‘POST’ user details, including passwords of course, over unencrypted HTTP connections. I will be updating a text file called hallofshame.txt inside the github reposity of Greek rules for HTTPS Everywhere with such websites. I am planning to inform the operators of such websites every now and then, so if you know any other cases please open up new issues so we can help protect innocent users.

A big rant on current HTTPS status of top Greek websites
The status of HTTPS support on top 100 Greek websites (according to Alexa) is SAD. No wait, it is EXTEMELY SAD. Out of these 100 websites, taking into account only the ones that are actually run by Greeks, that means excluding Google, Facebook, Youtube, LinkedIn, etc, only 2, yes you read correctly, just two websites offer HTTPS support.
The reason 95% the others don’t is probably because they are based on Akamai-zed services and either don’t have the money to buy Akamai’s HTTPS products or don’t have the technical skills to do it properly.

If you don’t run an Akamai-zed website and want a completely free 1-year SSL certificate please visit https://www.startssl.com/. If you need professional help with your setup please don’t hesitate to contact.

There’s a very good (financial) explanation why these high traffic Greek sites have prefered Akamai’s services and haven’t deployed their own servers in Greece but this will be the content of another blog post coming soon.

Filed by kargig at 19:51 under Encryption,Greek,Internet,Linux,Networking,Privacy
Tags: EFF, Encryption, https, HTTPS-Everywhere, Linux, Networking, Privacy, security, ssl, tls
2 Comments | 18,363 views

Από δελτίο τύπου του Οργανισμού Πνευματικής Ιδιοκτησίας:

…στις 16 Μαΐου 2012 δημοσιεύθηκε η απόφαση 4658/2012 του Μονομελούς Πρωτοδικείου Αθηνών, η οποία έκανε δεκτό αίτημα οργανισμών συλλογικής διαχείρισης δικαιωμάτων επί μουσικών και οπτικοακουστικών έργων να υποχρεωθούν εκτός άλλων οι ελληνικές εταιρίες παροχής υπηρεσιών σύνδεσης στο διαδίκτυο να λάβουν τεχνολογικά μέτρα προκειμένου να καταστεί αδύνατη η πρόσβαση των συνδρομητών τους σε διαδικτυακές τοποθεσίες μέσω των οποίων πραγματοποιείται παράνομη παρουσίαση και ανταλλαγή έργων. Η απόφαση εφαρμόζει ουσιαστικά για πρώτη το άρθρο 64 Α του ν. 2121/1993 που ενσωματώνει πρόβλεψη Οδηγίας της Ευρωπαϊκής Ένωσης για τη δυνατότητα λήψης ασφαλιστικών μέτρων κατά των διαμεσολαβητών (παρόχων υπηρεσιών διαδικτύου), οι υπηρεσίες των οποίων χρησιμοποιούνται από τρίτο για την προσβολή του δικαιώματος του δημιουργού ή συγγενικού δικαιώματος. Παρόμοιες αποφάσεις έχουν ήδη εκδοθεί σε άλλα κράτη μέλη της Ευρωπαϊκής Ένωσης και αποσκοπούν στην προστασία της πνευματικής ιδιοκτησίας στο διαδίκτυο χωρίς να θίγονται τα δικαιώματα των χρηστών….

Την πλήρη απόφαση μπορείτε να την διαβάσετε εδώ: 4658/2012
*Update*
Επειδή το site του ΟΠΙ δεν παρέχει πια την απόφαση, την έχω ανεβάσει εδώ: Απόφαση-του-Πρωτοδικείου-Αθηνών-για-την-αντιμετώπιση-της-διαδικτυακής-πειρατείας

Γιατί είναι σημαντική αυτή η απόφαση για τους χρήστες
Για πρώτη φορά στην Ελλάδα δικαστήριο επιβάλλει συγκεκριμένα τεχνικά/τεχνολογικά μέτρα παρεμπόδισης της πρόσβασης χρηστών σε ιστοσελίδες/servers. Σήμερα μπορεί να είναι μια ιστοσελίδα που παρέχει “πειρατικό” περιεχόμενο και ο ιδιοκτήτης της βγάζει χρήματα μέσω των διαφημίσεων, αύριο μπορεί να είναι ένα site που ο ιδιοκτήτης του δεν βγάζει χρήματα και μεθαύριο ένα πολιτικό site, ένα θρησκευτικό site, ένα blog που διαφωνεί με τις μεθόδους μιας εταιρίας, μιας κυβέρνησης, κτλ. Οπότε πρέπει ως χρήστες να ξέρουμε τι επιβάλλει το δικαστήριο και να δούμε πως εμείς, ως μέλη της κοινωνίας του Internet, μπορούμε να κάνουμε κάτι για να ακυρώσουμε στην πράξη μια τέτοια απόφαση αν πιστεύουμε πως αυτή είναι λανθασμένη.

Τι περιγράφει η απόφαση
Η απόφαση περιέχει μια λεπτομερή τεχνική έκθεση που εξηγεί πως δουλεύει ένα site, ποια πρωτόκολλα χρησιμοποιούνται από τα μηχανήματα των χρηστών/πελατών για να αποκτήσουν πρόσβαση στο site και έπειτα περιγράφει τρόπους να διακοπεί η σύνδεση των χρηστών με ένα site. Οι τρόποι που παρουσιάζονται είναι οι εξής 2:
Ι) Εφαρμογή κατάλληλων φίλτρων στους δρομολογητές (routers) των ISPs ώστε να αποκλειστεί οποιαδήποτε κίνηση καταλήγει σε συγκεκριμένη IP.
ΙΙ) Εφαρμογή κατάλληλης ανακατεύθυνσης, μέσω τροποποίησης των DNS εγγραφών στους nameservers του κάθε ISP ώστε, ώστε τα αιτήματα προς συγκεκριμένα domains να καταλήγουν σε διαφορετικούς ιστοτόπους. Αυτοί οι ιστότοποι θα μπορούσαν να περιέχουν και ένα προειδοποιητικό μύνημα ώστε να καταλαβαίνουν οι χρήστες γιατί δεν έχουν πρόσβαση στο κανονικό site, όπως αναφέρει το η έκθεση.

Από αυτούς τους 2 τρόπους, στην απόφαση επιβάλλεται η χρήση μόνο του τρόπου (I) ως τεχνολογικό μέτρο διακοπής της πρόσβασης στις “παραβατικές” ιστοσελίδες.

Τα προβλήματα της απόφασης
Τα προβλήματα της απόφασης για μένα είναι αρκετά. Κάποια αναφέρονται και στην ίδια την τεχνική έκθεση που περιέχεται στην απόφαση.
Συγκεκριμένα αναφέρει:

Αν και υπάρχουν δυνατότητες παράκαμψης των συγκεκριμένων τεχνικών μέσων από την μεριά των χρηστών του διαδυκτύου, οι τεχνικές αυτές είναι άγνωστες στη μεγάλη πλειονότητα των πελατών (συνδρομητών) των ISP, που είναι οι δυνητικοί επισκέπτες των ιστοτόπων στους οποίους έχει διακοπεί η πρόσβαση.

Θα αναφερθώ μόνο στα πολύ βασικά όμως…
α) Καταρχήν τα sites έχουν αλλάξει IPs. Το www.ellinadiko.com πλέον δεν δείχνει στην IP που αναφέρεται στην απόφαση, για την ακρίβεια δεν δείχνει πουθενά αυτή τη στιγμή, ενώ το www.music-bazaar.com λειτουργεί αλλά δείχνει σε διαφορετική IP. Άρα η εφαρμογή της οδηγίας (Ι) είναι πρακτικά άχρηστη ως προς τους σκοπούς της απόφασης χωρίς πολλά πολλά. Από την άλλη όμως μπορεί να δημιουργήσει προβλήματα πρόσβασης σε άλλα sites που μπορεί αυτή τη στιγμή να φιλοξενούνται σε εκείνες τις IP για τις οποίες πρέπει να μπουν φίλτρα. Άρα αν εφαρμοστεί η απόφαση ως έχει κινδυνεύει να διακοπεί η πρόσβαση στο site μιας ελληνικής ή ξένης εταιρίας ή προσώπου χωρίς να φταίει σε τίποτα! Ακόμα να μην είχαν αλλάξει IPs τα sites αυτά όμως, πάλι προκύπτει πρόβλημα. Η σύγχρονη τεχνολογία, των τελευταίων 15+ ετών, επιτρέπει την φιλοξενία πολλαπλών ιστοτόπων στην ίδια IP μέσω της τεχνολογίας virtual hosting, κάτι που εφαρμόζεται κατά κόρον ώστε να εξοικονομηθούν IPs. Αυτό έχει σαν αποτέλεσμα πως αν αποτραπεί η κίνηση προς μία συγκεκριμένη IP από ένα φίλτρο ενός ISP, τότε παρεμποδίζεται και η κίνηση προς όλα τα υπόλοιπα sites που φιλοξενούνται στην ίδια IP. Άρα υπάρχει πιθανότητα “τιμωρίας” αθώων ανθρώπων που δεν έχουν κάνει απολύτως τίποτα.

β) Η τεχνική έκθεση και η απόφαση περιέχει συγκεκριμένα domains που θα πρέπει να εφαρμοστεί το (II). Αυτό όμως δεν εμποδίζει σε τίποτα τον διαχειριστή της “προβληματικής” ιστοσελίδας να αλλάξει αύριο domain κρατώντας ακριβώς το ίδιο περιεχόμενο. Οπότε εμποδίζοντας την πρόσβαση στους πελάτες πίσω από ένα ISP σε ένα συγκεκριμένο domain δεν καταφέρνεις και πολλά. Ακόμα όμως και να μην αλλάξει domain ο διαχειριστής μιας και υπάρχουν ελέυθεροι nameservers (Google Public DNS, OpenDNS, κ.α) στο Internet, το μόνο που θα είχε να κάνει ο χρήστης θα ήταν να χρησιμοποιήσει αυτούς έναντι των nameservers του ISP του. Άρα πάλι τα τεχνικά μέτρα είναι εντελώς ανεπαρκή ως προς τον σκοπό της απόφασης. Πέραν αυτού και λόγω της προτεινόμενης ανακατεύθυνσης που προτείνει η τεχνική έκθεση τίθεται και ένα θέμα ιδιωτικότητας σε περίπτωση που εφαρμοζόταν το μέτρο (ΙΙ). Λόγω της ανακατεύθυνσης όλοι οι πελάτες θα “πήγαιναν” σε μία νέα ιστοσελίδα που θα ήταν υπό τη διαχείριση (μάλλον?) του ISP, άρα ο ISP αποκτάει πολύ εύκολα πρόσβαση στο ποιός θέλει να επισκεφτεί τον ιστότοπο αυτό. Τίθεται λοιπόν ζήτημα παρακολούθησης της κίνησης των πελατών. Προσωπικά το θεωρώ απαράδεκτο, όπως απαράδεκτο είναι να προσπαθείς να αλλάξεις τον τρόπο που λειτουργεί το internet. Άλλωστε όπως έχει πει ο John Gilmore:

The Net interprets censorship as damage and routes around it

Μετάφραση:

Το Δίκτυο ερμηνέυει τη λογοκρισία ως ζημιά και δρομολογεί (την κίνηση) γύρω από αυτό (ξεπερνώντας την ζημιά)

Τι θα μπορούσαν να κάνουν οι χρήστες για να παρακάμψουν το “πρόβλημα” αν τους επηρέαζε
Σε περίπτωση εφαρμογής του (II), όπως αναφέρθηκε παραπάνω το μόνο που θα είχαν να κάνουν οι χρήστες θα ήταν να αλλάξουν nameservers στο PC/δίκτυο τους. Αυτό εξηγείται αναλύτικά στις σελίδες της Google Public DNS αλλά και του OpenDNS. Τόσο απλά. Είναι υπόθεση 1 λεπτού αν έχει ο οποιοσδήποτε τις οδηγίες μπροστά του.

Σε περίπτωση εφαρμογής της τεχνικής (Ι) και την στιγμή που το site δεν μπορεί για τους Χ λόγους να αλλάξει IP, αυτό που πρέπει να κάνουν οι χρήστες είναι να χρησιμοποιήσουν κάποιον proxy server, ένα VPN ή κάποιο άλλο δίκτυο που δρομολογεί διαφορετικά τις συνδέσεις τους, για παράδειγμα το Tor. Ο ευκολότερος τρόπος να βρει κάποιος δωρεάν proxies στο δίκτυο είναι να ψάξει στο Google, ενώ η αγορά ενός VPN ξεκινά από τα 3€. Η χρήση του tor είναι πλεόν αρκετά απλή και το μόνο που απαιτείται είναι να κατεβάσει κανείς το Tor Browser Bundle και να τρέξει το Vidalia. Όταν κάποιος τρέξει το Vidalia θα ανοίξει ένας νέος browser (Firefox) και έπειτα η δρομολόγηση των πακέτων προς το site που θέλει να επισκευτεί κανείς γίνεται μέσω του Tor δικτύου το οποίο είναι αρκετά δύσκολο να το σταματήσουν οι ISPs. Σίγουρα πάντως η απόφαση ασφαλιστικών μέτρων 4658/2012 δεν είναι ικανή να σταματήσει το Tor ή οποιονδήποτε άλλο από τους παραπάνω τρόπους παράκαμψης του “προβλήματος”.

Τι πρέπει να γνωρίζουν οι χρήστες του Internet
Οι χρήστες του internet πρέπει να γνωρίζουν πως ανά πάσα στιγμή μια τέτοια απόφαση μπορεί να τους αλλάξει τις συνήθειές τους αλλά και να τους κόψει την πρόσβαση από πηγές πληροφορίας που μέχρι τώρα είχαν ελεύθερη πρόσβαση. Για να μην βρεθούν τελευταία στιγμή να αναρωτιούνται τί και πώς πρέπει να φροντίζουν να ενημερώνονται για τους κινδύνους και τα προβλήματα. Είναι μάλιστα επιτακτικό ο ένας χρήστης να ενημερώνει τους άλλους. Γι αυτούς ακριβώς τους λόγους τους τελευταίους 2-3 μήνες έχει ξεκινήσει μια προσπάθεια ενημέρωσης των Ελλήνων χρηστών για τα ψηφιακά τους δικαιώματα, τους κινδύνους που υπάρχουν στο διαδίκτυο, πως προστατεύει κανείς τα προσωπικά του δεδομένα και πως αποφεύγει προσπάθειες εταιρικής ή κρατικής λογοκρισίας μέσω κάποιων παρουσιάσεων που γίνονται στο hackerspace της Αθήνας. Η επόμενη παρουσίαση γίνεται στις 30/05/2012 και αφορά την χρήση του δικτύου Tor. Όσοι ενδιαφέρονται είναι ευπρόσδεκτοι να έρθουν να ακούσουν και φυσικά να ρωτήσουν για τυχόν απορίες που ίσως έχουν σχετικά με την ψηφιακή τους ζωή.

Οργανωθείτε!
Αν σας ενδιαφέρει να παλέψετε και εσείς για τα ψηφιακά δικαιώματα και τις ελευθερίες στην Ελλάδα καλό θα ήταν να διαβάσετε το κείμενο θέσεων του Δικτύου για την Ψηφιακή Απελευθέρωση (Digital Liberation Network) και αν συμφωνείτε να εγγραφείτε στην mailing list του DLN.

Filed by kargig at 21:06 under Encryption,General,Greek,Internet,Linux,MacOSX,Networking,Privacy
Tags: 4658/2012, access list, censorship, dns redirection, freedom_of_speech, google dns, Greek, hackerspace, Networking, opendns, Privacy, proxy, security, tor, vpn, ανακατεύθυνση, λογοκρισία, ΟΠΙ
10 Comments | 19,948 views

Alternate title: “Being a lamb around a pack of wolves” … A venue full of hackers that are eager to attack your systems…

On 3-4/05/2012 the third AthCon conference was held in Athens. AthCon is an international security conference whose motto is “The First HIGHLY TECHNICAL Security Conference in Greece”.

Even though I am not a security professional, my daily job title is “Systems and Services Engineer” which of course includes various aspects of security but I am certainly not a security researcher, I had decided months ago that I would be attending this year’s AthCon. Since I like messing a lot with IPv6 for the past 2-3 years, I decided that I could try and submit an introductory talk about IPv6 security issues. My talk was accepted, so I was not only attending AthCon this year but I was going to give a presentation as well.

My presentation – Are you ready for IPv6 insecurities ? was during the first day of the conference. I am always worried when I give presentations on IPv6 that the people attending have probably no clue about this ‘not-so-new’ protocol. Most people think that IPv6 is like IPv4 with bigger addresses and ‘:’ instead of ‘.’ to separate the address groups, which is of course a HUGE mistake/misunderstanding. I was hopeful that this wouldn’t be the case in AthCon, so when I started my presentation and I asked the crowd ‘how many of you know what SLAAC is ?’ and I only saw 3-4 hands raised I kinda froze, I was expecting at least a double digit…I was going to give a presentation on IPv6 security concepts to people that have absolutely no idea what I’m talking about. Being prepared for the fact that some people would need some ‘refreshing’ on their IPv6 knowledge, I had prepared around 20 introductory slides explaining some IPv6 concepts before I entered the security details, but I doubt these were enough for most people there. I am hopeful though that some of the attendees might be motivated to read more about the protocol since I think my security slides contained enough details, references and links to get people started. If someone needs more details feel free to contact me.

Enough with my presentation, what about other presentations ?
My personal view is that this year’s AthCon had some great talks, some that were ok and some that I didn’t like. I won’t mention which ones I didn’t like, but I noticed that a LOT of people were gossiping about these in the hallways. I will only mention here the ones that I really liked.

Day 1:
“Packing Heat!” by Dimitrios Glynos
A presentation that every pentester should download/watch somehow. Techniques about packing your executables to avoid detection by anti-virus programs, need I say more ? Great content and very well presented. Congrats Dimitris!

“PostScript: Danger Ahead” by Andrei Costin
How to use PostScript programming language to take advantage of Printers, OS, etc. Very interesting concepts were presented and also the examples/demos shown were pretty cool and easy to understand.

Day 2:
“Apple vs. Google Client Platforms” by Felix ‘FX’ Lindner
I guess mostly everyone reading this blog knows FX and what a great speaker he is. If you don’t then start watching his previous presentations and start reading about his work. His presentation at AthCon, apart from being the best one in terms of “presenting it”, was also extremely interesting. He connected the security concepts behind Apple’s iOS and Google’s Chromebook with their business tactics and policies. Just wait for AthCon to publish the videos and watch it. Probably the best talk at AthCon 2012.

“Advances in BeEF: RESTful API, WebSockets, XssRays enhancements” by Michele Orru
Jaw-dropping. That’s all I have to say about BeEF. Scary. Watch it to see what browsers and IDS have to face and defend against…not in the future but right now.

“Exploitation and state machines” by Halvar Flake
This presentation was about exploitation techniques and why automated exploitation engines don’t work that well. Even though reversing and exploitation is far from my interest topics I enjoyed the talk a lot. Very well structured and very clear points. Too bad this talk did not appear on the schedule and was there as “tbc”, I am sure many more people would come just to listen to this talk and speak to Halvar.

If I were to suggest a couple of things for next year…
a) Please put the CTF in separate slots within the day, not at the same time with the presentations. In a conference of 150-200 people (just guessing here) having 30+ people leaving the presentation room and just attending the CTF all day long leaves the main room a bit empty. I am pretty sure there were people that wanted to attend both the presentations and the CTF, unfortunately they had to make a choice.
b) Send some details/info to the speakers about the conference a few days earlier. Maybe non-greek presenters were given but we weren’t, at least I wasn’t.
c) The venue is really nice, but maybe it would help if the next AthCon was organized somewhere downtown. Yeah I can understand that the cost would be higher but number of people attending would also raise (I think).
d) Give us even more highly technical presentations/speakers! People starve for these kind of talks!

My congratulations fly to AthCon people for organizing the conference. See you next year!

You can find some of the pics I took from the speakers at: AthCon 2012 speaker pics (if any of the speakers wants his pic removed please contact me ASAP)

Filed by kargig at 15:07 under Encryption,Internet,IPv6,Linux,Networking,Privacy
Tags: apple, athcon, athens, beef, conference, ctf, exploitation, google, hacking, ipv6, packing, postscript, presentation, security, vulnerability, web application, xss
No Comments | 6,716 views

I’ve had this thought for some time now, I needed a nice interface for GrRBL so that it would make it easier for others, read more, people to contribute. Many people have been, politely, complaining about lack of features, policy and so on.

Right now most people use either the submission form or they bounce their emails to grrbl [at] void [dot] gr. Then their emails get manually processed, filtered and if everything goes well the “useful” parts of their email end up in the DNS RBL or the email address blacklist. This process is not automated at all, entries are manually added to a database, and is therefore quite time consuming. What’s worse is that people who are listed don’t have an ‘easy’ way to opt-out, apart from emailing us. The algorithm of adding someone to these lists is also not well-defined. The main rule that is followed is that an IP or email address is added to these lists when at least 3 people have submitted them on different days.

Hopefully this is about to change soon (I don’t know how soon, but soon!). During the past month I’ve been trying to code an interface in django, even though I had no prior experience in it. It’s mostly a self educating process and I like it very much. This django application will be generic enough to cover submissions and listings for IPs, emails and possibly URLs.

Short term goals:

Anonymous users will only get to see details about an IP they search for. People though will be able to register and add their own entries to a database. These registered users will be able to see the complete listings. Each user will belong to a group and every group will have a different weight which will depend on his ‘expertise’ (I know this is broad, but read on). For example, the group of the individual users will certainly have less weight than the group of the postmasters of Greek ISPs (yeap there are some who regularly contribute). Using their weights users will be able to vote on each entry that’s inside the database. Upon a certain score these entries will be flagged as eligible to be on the blacklist. Listed people will be able to opt-out but this process will be moderated by the superusers, that means that spammers like the infamous sofokleous10 will never get a chance to opt-out even for a single second.
Most of this functionality is already coded and is working quite well.

Mid term goals:

Various export formats will be supported (BIND/RBLDNSD, Spamassassin/Postifix/Exim/sendmail/etc). Selective/custom export of entries will be provided. Users will be able to select if they want to export/use a strict blacklist, that is hosts that are scored very high, a moderate one and a very broad/risky one. Levels have yet to be defined. An API will be published so that entries can be re-used in other applications (json format ?)

Long term goals:

A method/interface that someone would copy/paste their email and it would automagically parse it, provide the user with the discovered malicious entries (IP, emails, URLs) and propose him to add them to the database. Maybe automate this even further so that they are added on a separate moderated queue without user interaction, that would be suitable for submitting entries via email plugins for clients such as mutt/thunderbird/etc.

The code:

The django application code resides in github for now: https://github.com/kargig/grrbl_django. Everyone is welcome to submit ideas (as issues) and code! Feel free to download, test and provide feedback.

Greek Adblock Plus Filter

Since the code is very flexible I am thinking whether Greek Adblock Plus Filter can also be benefited by this voting system. It probably can, so expect some changes to that list as well. One interface to rule them all.

Many thanks go to @apoikos who has been helping me a lot with the tons of questions I still have on django stuff.

Filed by kargig at 21:27 under Greek,Internet,Linux,Privacy
Tags: adblock, adblock plus, antispam, django, dns, filtering, grrbl, Linux, python, rbl, spam
No Comments | 5,782 views

Say that a user has an email account at the company he works for. Before going on vacation he activates his cool “vacation auto-reply” feature that adds

Out of Office – I will be back from holidays at the end of July.

on the top and then quotes the email he was sent.

During his vacation, he receives a call and he is told he has to urgently sent an email about some financial updates. He rushes to an internet cafe and sends the email. He makes a mistake though and mistypes one of the email addresses of the recipients. Instead of sending the email to “user@domain.com” he sends it at “usar@domain.com”.

His company’s SMTP server though receives the following error message from the remote SMTP server while trying to deliver the email:

<usar@domain.com>: host mx.domain.com[1.2.3.4] said: 550 5.1.1
   <usar@domain.com>... User unknown (in reply to RCPT TO command)

This means that his SMTP server will then send an email to him informing him about the error and quoting parts if not all of the email he had previously sent. The email will likely appear to be from “postmaster@company.com” or “do-not-reply@company.com” or something similar.
It will look like this:

This is the mail system at host mail.company.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                  The mail system

<usar@domain.com>: host mx.domain.com[1.2.3.4] said: 550 5.1.1
   <usar@domain.com>... User unknown (in reply to RCPT TO command)
Reporting-MTA: dns; mail.company.com
X-Postfix-Queue-ID: AE4812AE328
X-Postfix-Sender: rfc822; employee1@company.com
Arrival-Date: Thu,  5 May 2011 20:05:27 +0200 (CEST)

Final-Recipient: rfc822; usar@domain.com
Original-Recipient: rfc822;usar@domain.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.domain.com
Diagnostic-Code: smtp; 550 5.1.1 <usar@domain.com>... User unknown

From: Loyal Employee <employee1@company.com>
Date: July 5, 2011 9:05:29 PM GMT+03:00
To: User User <usar@domain.com>
Subject: Re: Financial updates

Financial data goes here

But the user has still his vacation auto-reply turned on, so when the automatic postmaster’s email reaches his mailbox, the system will automatically reply back to the “postmaster@company.com” quoting the previous email and adding his auto-reply message:

Out of Office – I will be back from holidays at the end of July.

So the postmaster@company.com currently has all the financial details that he shouldn’t!

Apart from the fact that the user was sending financial data to somebody else in a clear text email instead of an encrypted one, the second biggest mistake that the user has made was that he has enabled vacation auto-replies that quote the email he was previously sent. That’s very very wrong. If you don’t want sensitive stuff ending at the postmaster’s inbox avoid quoting previous emails in your auto-replies by all means.

Based on a true story 🙂

Filed by kargig at 12:20 under Internet,Privacy
Tags: auto-reply, email, Privacy, vacation
2 Comments | 15,153 views

Intro
As said in my previous post about Fosscomm 2011, during the conference there was a wargame consisting of 5 challenges. We played in a team consisting mainly of the following members: manji/manjiki, trelo_mpifteki, mickflemm and me. Along with us was maisk mainly acting as our manager (!!) shouting at us when we did something he did not like. He was of course a great help (sometimes :P).

Few words about the team
As most people who regularly read this blog already know, I consider myself a sysadmin even though I currently work at a company that produces Linux based xDSL routers where I do most of the things required about networking and system interaction like QoS, VoIP, IPv6, firewall, etc. My coding is confined among the realms of scripting languages. Manji is also a sysadmin who has lately started to mess with VoIP. Trelo_mpifteki is mostly a java developer and so is maisk. mickflemm is a coder and a very good one, frequently messing with Linux kernel’s wireless driver support. Obviously, we are certainly not the typical wargame players…

The challenges
Be sure to download the challenges from: http://patras.fosscomm.gr/fosswar/

As soon as the wargame was on we split the challenges among us. Since mickflemm was the only coder he started to mess with challenge number 5 (reverse engineering). Me and trelo_mpifteki started to look at challenge number 1 (networking) while manji started poking at challenge number 3 (networking).

Challenge 1:
Type: Networking
Players: kargig, trelo_mpifteki
The first challenge said just this:

Connect to the elite port and find the secret message.

Everyone knows that elite = 31337
So we just did a nc X.Y.Z.W 31337 (where X.Y.Z.W is the IP address of the server) and the following message appeared:

IP protocol = 1
Timestamp
id = 1337
seq = 0xCAFE
orig = 0xDEAD

As it is easily understood one must create a packet, the problem is what kind of packet. And then was when I did a huge mistake stalling my team for more than 10 mins by insisting that Protocol 1 is IP. So we started trying to create an IP packet using scapy. Obviously we hit lots of problems because IP’s header clearly misses most of the above options, especially timestamp. Our next idea was to create a TCP packet in order to embed some of the options. This also lead to a dead end. The I looked again at my /etc/protocols file and I saw that Protocol 1 is ICMP. Timestamp is type 13, code 0 and the rest are just options. So our solution was this:

>>> packet_2= IP(dst='X.Y.Z.W')/ICMP(type=13, id=1337, seq=0xcafe, ts_ori=0xdead)
>>> send(packet_2)

Using Wireshark we captured the response packet which looked like this (this setup is on my box atm):

One can see the message: feedadeadface in it.

Hint:
If you need to compile listenicmp.c yourself you have to do something like this:

 # aptitude install libpcap-dev
# gcc -o listenicmp listenicmp.c -lpcap

Challenge 2:
Type: Steganography
Players: kargig,trelo_mpifteki,maisk
For this challenge the organizers gave us a hint what we needed to find was close to the end of the image.jpg and after “BAADF00D”.

# hd image.jpg | tail -n 4
000152a0  d4 4d 77 22 b9 9a 68 ba  ad f0 0d 78 9c 0b c9 c8  |.Mw"..h....x....|
000152b0  2c 56 00 a2 44 85 e2 d4  e4 a2 d4 12 85 dc d4 e2  |,V..D...........|
000152c0  e2 c4 f4 54 3d 00 72 da  08 ef                    |...T=.r...|
000152ca

so we found “ba ad f0 0d” and the next characters were “78 9c”. We googled those and came up with the result that it was the magic of zlib compression. So what we had to do was get the rest of the file after “ba ad f0 0d” and then uncompress that. To get the rest of the file we found the size of the file and subtracted the bytes (31) that were of interest to us:

# du -b image.jpg
86730  image.jpg
# split -b 86699 image.jpg koko
# mv kokoab final

Then we run python to decompress “final” file.

>>> import zlib
>>> ourfile=file('final')
>>> ourfile
<open file 'final', mode 'r' at 0xb7473020>
>>> chunk=ourfile.read()
>>> chunk
'x\x9c\x0b\xc9\xc8,V\x00\xa2D\x85\xe2\xd4\xe4\xa2\xd4\x12\x85\xdc\xd4\xe2\xe2\xc4\xf4T=\x00r\xda\x08\xef'
>>> zlib.decompress(chunk)
'This is a secret message.'

Challenge 3:
Type: Networking
Players: manji,maisk,kargig

While me and trelo_mpifteki were trying to solve challenges 1 and 2, manji was looking into challenge 3 pcap file for weird things. Once again we were given a hint that we needed to look at strange headers. Finding strange headers in a 800+ kb pcap file is not an easy task though. At a point manji was looking for very big sequence numbers…and then we got another hint, that we shouldn’t look at those big numbers at all. When me and trelo_mpifteki finished the other two challenges we started looking at Wireshark.
We applied the following filter:
(ip.host == 64.22.109.100) && ((tcp.seq == 0) || (tcp.seq ==1))
And the we had the following results in front of us:

Since we knew that the message was sent to “64.22.109.100” we needed to look at packets originating from “192.168.1.3”. The first thing I noticed were packets with strange TTLs, they were going up and down..so I made a guess that the secret message could be hidden there. Transforming those TTL values to ASCII was a dead end. Then we started to look closer at every packet that 192.168.1.3 sent to 64.22.109.100 and we grouped them by destination port. There was clearly something going on with destination port 58900. A careful eye will also notice that packets towards port 58900 don’t have an MSS set while others mostly do. So, we expanded our filter with packets that also had destination port 58900:
((ip.host == 64.22.109.100) && ((tcp.seq == 0) || (tcp.seq ==1))) && (tcp.dstport == 58900)
and came up with this:

If you look closely at the selected packet from Wireshark, you’ll see that the sequence number while set to 0 (zero) contains the letter ‘r’ inside it. The next packet contained the letter ‘o’ and the next one the letter ‘t’. Writing all these letters down we had this sequence:

r
o
t

q
r
n
q
o
r
r
s

That was a rot13 encrypted message! with google’s help we found a rot13 decryptor. The decrypted message was:
D E A D B E E F

That’s it! we had 3 out of 5 while no other team had more than 2. So we had wooooon! Congrats to everyone on our team!

Filed by kargig at 11:41 under Encryption,General,Internet,Linux,Networking,Privacy
Tags: fosscomm, Fosscomm 2011, fosswar, hd, hexdump, icmp, maisk, manji, mickflemm, Networking, rot13, scapy, split, steganography, trelo_mpifteki, wargame, wireshark
7 Comments | 10,402 views

Generic comments
I just got back home from Fosscomm 2011 and I must admit it has been one of the best organized events of this kind I’ve seen in Greece ever. The single most important fact was that presentations and workshops were always _on time_. They started on time, they finished on time. The organizers had to face even a power cut by the national energy company but they still managed not to fall behind on schedule. My only remark would be about the selection of the presentations that took place in the big room (called BA). Most of them gathered far less people than other presentations which took place in smaller rooms (B3 for example) and those rooms got extremely crowded from time to time. Maybe the organizers thought that generic open source presentations would attract more people than the technical ones but, unfortunately for them, and fortunately for “the greater good”, they were very wrong. This doesn’t reduce their achievement though. Another thing I would like to see on the next Fosscomm is less material given out to participants and instead spend this money on paying for travel expenses of people coming to speak on Fosscomm from abroad. Giving one (or even more) of the phones that HTC kindly provided to the voted by the participants best talk/presentation/workshop would also be very nice. My sincere congratulations to the organizing committee.

My IPv6 workshop
On my application to Fosscomm I had asked for one presentation and a separate workshop. This unfortunately wasn’t accepted, probably due to the large amount of other presentations/workshops, so I was given the first workshop on the very first day of Fosscomm, about “Using IPv6”- on Linux. Since I only had one hour, my original plans were to do a quick 15 min introductory presentation on IPv6 and then a 45 min hands-on lab. Since University of Patras could not provide IPv6 connectivity to the Lab, my other option was to have some remote VMs that would have upstream IPv6 connectivity and people on the Lab would ssh to. These VMs were kindly provided to us by Grnet and I have to publicly thank them one more time. My planning was bad though, people had far more questions about introductory IPv6 issues than I expected and the intro presentation was not finished until more than 35 mins had passed. This lead to the unfortunate result that the workshop could not be completed as I had planned. I am glad though that almost everyone logged into the VMs and had the chance to at least set up an IPv6 IP manually as well as an IPv6 default route. They also had their first ping6s. Some got even further by setting up ip6tables rules…What I definitely wanted to have shown during the workshop, and I didn’t have enough time to, was auto-configuration (SLAAC) which I consider to be one of the most intriguing features of IPv6. Next time I am doing either a presentation or a hands-on workshop, definitely not both in one session. Lesson learned.

Presentation/Workshop material:
Quick Intro to IPv6
Using IPv6 on Linux (workshop notes)

Talks I attended
All the talks I attended were very interesting, I probably did a very good job picking them 🙂 The ones I attended were:
Saturday
a) “A unified user account manager using LDAP/KRB5/CIFS” by Giorgos Mamalakis, Chariton Karamitas
b) “Network Exploitation with Ncrack” by Fotis Chatzis
c) “Wargames” by Patroklos Argyroudis, Fotis Chatzis, Chariton Karamitas
Sunday
a) “Intro to Arduino” by Pierros Papadeas, Kostas Antonakoglou
b) “Φωνή VoIPόντως εν τη ερήμω” by Effie Mouzeli
c) “Bright side of the Darknets” by Athanasios Kostopoulos
d) “Automated Testing Framework” by Giorgos Keramidas
e) “Performing Digital Forensics with Open Source tools” by Dimitrios Glynos
f) “Patras Heap Massacre” by Chariton Karamitas, Patroklos Argyroudis

I consider the most well presented one being: “Performing Digital Forensics with Open Source tools” while the one with the best slides was definitely: “Patras Heap Massacre”. If you weren’t there to see them, definitely try and find at least the slides if not the video.

Wargames
I had never participated before in any wargames because I considered that to be out of my league. That’s the reason I had not even registered for Fosscomm’s wargame called “fosswar”. I was curious though about what it’s like, so me and 3-4 more friends decided to stand in line and enter the room among the other people. The Lab room was crowded, really crowded. At first I thought that one reason for this would be the prize for the winner, an Android phone donated by HTC. I was later proven wrong though. Fosswar started and the organizers presented us with the 5 challenges. Two of those had to do something with networking…so I said to my self that I would be lucky even if I understood what one of those asked. Another challenge had to do with steganography, another one with exploiting a vulnerability in C and the last one was about reverse engineering. While this game could only have one winner, since me and my friends were not actually interested about the prize we decided to work as a team and see whether we can solve anything. Me and a friend looked at the first challenge, another 1 was looking at the third while 2 more were each looking at the fourth and fifth. During the wargame HTC asked for the names of people that wanted to take part in the competition, there nobody actually wanted to give his name. Most of them were there “just for the kicks”. That was even more exciting! HTC then told us that if nobody wanted to give his name the phone would be given on a lottery…so 10-15 people decided to give our names so the phone would “stay” at the fosswar. After solving the first challenge we got so excited that we just had to try the others, we couldn’t give up. So, after 3 hours of thinking and coding, the result was that our team managed to solve 3 of the five challenges, the details on what the challenges were and how we dealt with them will follow in a separate blog post, and we ended up being the winners because no other team had solved more than two. Yes, we had won! We had managed to solve the two networking challenges and the steganography one. That was soooo unexpected!

Pictures
My pictures from Fosscomm 2011 are at: https://picasaweb.google.com/kargig/2011050720110508Fosscomm2011#

My conclusion
Fosscomm this year definitely showed a trend. People don’t need generic presentations about open source any more, they know what it is, they believe in it, they use it. People really ask for technical presentations, and we need more of them.

Whoever couldn’t manage to attend Fosscomm 2011, should definitely attend Fosscomm 2012. I am certainly looking forward to it!

Filed by kargig at 01:23 under Greek,Internet,IPv6,Linux,Networking,Privacy,VoIP
Tags: fosscomm, Fosscomm 2011, Greek, ipv6, Linux, Open Source, presentation, wargame, workshop
5 Comments | 8,653 views

Χρησιμοποιώντας πριν 2 μέρες το νέο σύστημα ηλεκτρονικής κράτησης εισητηρίων του ΟΣΕ αντιμετώπισα το εξής παράδοξο. Μετά την επικύρωση της πιστωτικής μου κάρτας και αφού είχα δώσει και τα ονόματα των συνεπιβατών μου, το σύστημα μου ζητούσε να δώσω μια “μυστική φράση-κλειδί” που θα την ήξερα μόνο εγώ και ο ελεγκτής των εισητηρίων. Αδυνατούσα να καταλάβω που χρειάζεται αυτό και έτσι την επόμενη μέρα το απόγευμα (στις 18:00) έστειλα ένα email στην διεύθυνση που αναφέρει το website ζητώντας πληροφορίες για το κλειδί.

Το email μου:

Καλησπέρα

καταρχήν συγχαρητήρια για το σύστημα online κράτησης εισητηρίων. Ήταν κάτι που χρειαζόταν εδώ και χρόνια.

Έχω μια απορία όμως, ποιά είναι η λογική πίσω από την χρήση “μυστικής φράσης-κλειδί” ? Εφόσον το εισητήριό μου αναφέρει επάνω τον κωδικό του, έχει το ονομά μου και θα έχω και εγώ ταυτότητα επάνω μου…τι επιπλέον προσθέτει στην ασφάλεια του ΟΣΕ αυτή η φράση ?

Με τιμή,

Στις 21:50 (!!!!) την ίδια μέρα πήρα την εξής απάντηση:

Καλησπέρα,

Η μυστική φράση έχει να κάνει με τις περιπτώσεις όπου θέλετε να κάνετε δώρο το εισιτήριο ή το βγάζετε για λογαριασμό κάποιου τρίτου, ο οποίος προφανώς δεν θα φέρει μαζί του την πιστωτική κάρτα με την οποία εκδόθηκε ο τίτλος. Και δεδομένου ότι Ελλάδα είμαστε και δεν είναι όλοι οργανωμένοι να κουβαλάνε μαζί τους ταυτότητες κλπ, εισάγαμε την ιδέα του μυστικού κωδικού σαν ένα επιπρόσθετο μέτρο για να μπορείτε να εξασφαλίσετε το εισιτήριο σας και να αποδείξετε ότι είστε ο πραγματικός του κάτοχος.

Κατ’ αυτό τον τρόπο μπορείτε να εξασφαλίσετε την αγορά σας σε περίπτωση που κάποιος αντιγράψει το εισιτήριο σας ή το τυπώσει (πράγμα καθόλου δύσκολο *) και ανεβεί στο τρένο προσποιούμενος ότι είστε εσείς. Στην περίπτωση αυτή αν και οι δύο δεν φέρετε ταυτότητα ή πιστωτική κάρτα, μόνο ο μυστικός κωδικός μπορεί να ξεδιαλύνει την κατάσταση, ο οποίος κωδικός βρίσκεται τυπωμένος μόνο στην λίστα που έχει ο ελεγκτής.

* το παρόν σύστημα έχει σχεδιαστεί με την λογική ότι κάποιοι και θα τυπώσουν εισιτήρια 3ων πέρα από τα δικά τους και θα προσπαθήσουν να τα χρησιμοποιήσουν, και ότι κάποιοι άλλοι θα τα φωτοτυπήσουν / Photoshop-άρουν. Οπότε το “τί πληροφορία είναι μοιρασμένη σε ποιο έγγραφο” είναι πολύ προσεκτικά σχεδιασμένο.

Σε κάθε περίπτωση, η εισαγωγή του “μυστικού κλειδιού” είναι προαιρετική για την αγορά του εισιτηρίου.

Με εκτίμηση,

Δεν θα σχολιάσω την εξήγηση που πήρα, αλλά το γεγονός πως κάποιος από το δημόσιο τομέα μου απάντησε σε email την ίδια μέρα και μάλιστα βράδυ. Εκπληκτικό!

Filed by kargig at 11:05 under Greek,Privacy
Tags: Ελλάδα, κλειδί, ΟΣΕ, τραίνο, ΤΡΑΙΝΟΣΕ, τρένο, φράση
17 Comments | 14,287 views

The pet-project of GrRBL,which is an IP-based blacklist, The Greek Spammers Email Addresses Blacklist, previously described at a previous post of mine, has grown to 400++ verified addresses of Greek spammers.

From now on, apart from the usual rsync access to anyone who asks for it, there will be a public link on the web with a PGP/GPG signed list of the spammers for anyone to get. The public link will not update as often as the list from rsync, probably once or twice per month is enough.

For anyone who wants to read a bit more: http://grrbl.void.gr/#email_blacklist.

Direct link to the signed Greek Spammers Email Addresses Blacklist.

Don’t forget to read the disclaimer and to submit greek spam at GrRBL Submission.

Filed by kargig at 20:01 under Greek,Internet,Linux,Networking,Privacy
Tags: blacklist, gpg, Greek, grrbl, spam, spammers
No Comments | 7,430 views