Monday, November 11, 2013

A great loss

I wish I were breaking radio silence with something else but I just received confirmation that Cédric Blancher, the security researcher and friend whom I was referring to in my previous post, died in an accident yesterday...

RIP

Sunday, December 6, 2009

On the legal uncertainty surrounding security education in France

An excellent read, by Cédric Blancher of EADS (in French sorry, automated translation to English here).

Basically it discusses a highly subject to interpretation French law that criminalizes informing people about dangers in Information Technology, and has me pulling my hair out to find interesting yet completely inoffensive stuff to tell you on Information Security...

All I can say is: remember the "I'm not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself?" joke? Yeah, the victims won't be the security people.

Sunday, July 26, 2009

From Maximum Risk To Maximum Security

Hey there!

Sorry, once again I have been too busy to work on my blog, notably with a prolific Paris Air Show last month, but I finally found some time here over the clouds somewhere between Vilnius and Copenhagen :-)

For new readers, this is the follow-up to a first part entitled "Internet By All Means" in which I was describing how to maximize your chances to get a full & secure Internet access almost anywhere.

In order to achieve this goal we had to achieve maximum reachability on the Internet for various networking services and thus, maximum exposure to remote attacks... making this an interesting case study for discussing the implementation of a maximum of security measures.

First of all, let's assume that at least one of these networking service WILL get hacked. What do we have at stake? What mustn't the hacker be able to do from there?
  • read, alter or delete data that might be stored on the stepping stone
  • record or tamper with traffic in the network the stepping stone resides in (think ARP cache poisoning etc)
  • record or tamper with traffic going through the stepping stone
  • escalate privileges inside the stepping stone
  • hack other computers in your private network
  • use your stepping stone as a relay to hide behind your IP address
So now that we established the risk level as far beyond unacceptable, let me walk you through the steps to counter that and by the way achieve a level of security much better than the usual:


1. Protect your valuables

The first two issues can simply be addressed by a common best practice: run the stepping stone on a dedicated (virtual) machine and isolate it from the rest of the network by placing it inside a DMZ. This is an easy way to physically contain an intrusion, but not sufficient as we still want to avoid it.


2. Ensure system integrity

As the stepping stone OS is somewhat static once it is configured, why not make it into a liveCD or read-only VM disk image? This would prevent a hacker from applying any permanent changes to the system, and by having the system regularly reboot you will erase whatever RAM-resident stuff the hacker might have, driving him nuts :-)


3. Relinquish privileges

Many network services require privileges so that they can for example bind to a port under 1024 or create virtual network interfaces. The thing is: they usually need these privileges only during startup, so why have them still available afterwards? A hacker could find profit in that, especially since full (root) privileges are often given to such services instead of just a selection of the privileges they require.

Therefore, these network services must be made to drop their privileges as soon as possible. Problem is: since only they know when it becomes indeed possible, this security feature has to be built in each of them. Fortunately, most of them already have it (see the "-u" flag in Iodine, "user" and "group" options in OpenVPN, etc) and when they don't, the beauty of open source software is that you can add the feature yourself like I did for PingTunnel.

In effect, what you have now is software running with a (preferably dedicated) least-privileged user account, which is a huge improvement compared to letting software run with administrative privileges but still not sufficient:


4. Restrict filesystem access

With a complex filesystem tree you can never be so sure as to have all the file access rights covered: with incorrect read access control on a pseudo terminal device for example a hacker could manage to perform keylogging, and with incorrect write access control in some place or the setuid-bit set on the wrong binary a hacker could perform a privilege escalation.
But thanks to filesystem isolation security features available in modern operating systems, it is possible to convince a program that the filesystem tree starts in a directory of your choice; that way, you can simply forbid any file operation to a process by just "chroot'ing" it in an empty directory with no write permission.


5. Restrict network access

The same principle of least privilege can and should be applied to network access. For example, if you use HttpTunnel to access the OpenSSH service over HTTP tunneling, the HttpTunnel server (hts) should not be given the possibility to connect to anything else than TCP port 22 on the loopback interface:

iptables -N HTS
iptables -A OUTPUT -m owner --uid-owner hts -j HTS
iptables -A HTS -o lo -p tcp --dport 22 -j ACCEPT
iptables -A HTS -j LOG
iptables -A HTS -j REJECT --reject-with icmp-admin-prohibited


6. Protect the kernel

Many sysadmins and even security engineers stop at step #4, if not less... It's a huge mistake! Why? Because of kernel exploits: if a hacker can make one of your processes perform a vulnerable system call, he can obtain kernel privileges (the highest privileges possible) and all of a sudden it's game over!

So, in order to prevent that from happening, we want to forbid each process from performing system calls it does not need. Since kernel exploits are usually found in lesser used system calls like vmsplice, and since the stepping stone related processes once initialized will need little more than network I/O related system calls which can now be considered hardened, we can safely assume that with this technique we zero out the likelyhood of this scenario.

As it is often the case in the UNIX world, there are many alternatives for that: Security-Enhanced Linux (SELinux), GRSecurity, RSBAC, AppArmor, the Linux Intrusion Detection System (LIDS), etc... each having its own advantages and disadvantages.

Personally I use SELinux, probably the most cumbersome one but the most production-ready one in my opinion. Yes, NSA SELinux... If you think I'm crazy for recommending software from a spy agency, I've got a question for you: which one is the most endangering, a closed-source operating system like Windows or a completely open source Linux Security Module?

Most SELinux policies (like the ones found in the Reference Policy project) are applied on programs at the moment they are launched, which makes for over-complicated and coarse-grained policies. The one for OpenVPN for example deals with far much more than just network I/O: notably it deals with (and permanently allows) modifying network interface properties and routing table, something OpenVPN only needs to do at startup; this adds for one unnecessary complexity, but also, importantly, insecurity as letting a hacker play with your routing table is definitely not something you want to do.

As explained above in the paragraph on relinquishing privileges, it often makes much more sense to have each software apply security policies to itself as only it knows the best moment for that is. Therefore I added SELinux support to Iodine, PingTunnel and both 2.0 & 2.1 branches of OpenVPN. In the case of HttpTunnel it is not necessary as it needs only network I/O from the start.


7. Gatekeeping

At this point, a successful hacker should only be able to use the networking capabilities of your stepping stone, which is far better than average but still: we don't want anyone to be able to use our stepping stone as a relay for hacking or illegal downloading (especially with the new Internet access suspending laws like HADOPI in France), do we?

But if you consider your tunneling software compromised, how do you differentiate between legitimate traffic (the traffic that was tunneled) and illegitimate traffic (traffic generated by the hacker inside the compromised tunneling software)?

For that you need to authenticate the legitimate traffic, and this is exactly what IPsec's Authentication Headers are for. Note that even though IEEE 802.1X is a network authentication mechanism too, it won't do here as basically once a network cable is authenticated it allows whatever traffic coming through it.

So the idea is to have something like this:



As you can see, the stepping stone is separated from the rest of the LAN by being both a DMZ (in the proper sense of the term) and a DMZ host in order to receive all traffic from the Internet (except for the NAT-related one in my case since it belongs to other computers in my home network).

Speaking of my home network, for the sake of clarity I put nothing more than an icon, but for the ones willing to play Catch 22, I have two words: Intrusion Detection.

Now, since what's underneath whatever encapsulation we used to reach the stepping stone by all means is actually IPsec traffic, providing us with authentication and encryption capabilities, we can have a completely compromized stepping stone that is neither able to send any other traffic than the one it is meant to forward nor able to sniff said traffic.

Indeed: the firewall, acting as an IPsec gateway (agreed it is tunneling software like OpenVPN etc, but it is simple enough that it can be considered hardened) will allow only:
  • any traffic from the Internet to the stepping stone
  • return traffic from the stepping stone to the Internet, which was established by the latter
  • new traffic to the Internet if it is correct IPsec, which can only have been generated by the laptop

It should be sufficient, but if like me you are the kind to wince at the first bullet, this last paragraph should be of interest:


8. Cherry on top: two-factor network access control

Our biggest problem is being able to reach the stepping stone at any moment from anywhere on the Internet, but it doesn't mean everybody should be able to! :-D

People suggested that I use port knocking which is a nifty idea in general, but not possible in our case as we won't always have a direct connection to our stepping stone: it is likely that we'll have to route our DNS tunneling through other servers, our HTTP(S) tunneling through proxies, etc.

However, when you want to use your stepping stone you are most likely to have a second means of telecommunications at your disposal: the phone! Combining it with the firewall allows us to solve the problem, by performing something that I like to call two-factor Network Access Control.

Personally my landline phone service includes a free SIP (VoIP) account, which makes it very easy to trigger a script on the firewall by just making the phone ring: no need to have the script pick up, that way it costs absolutely nothing even when calling from abroad! Here's an example of such a script.

The idea is to allow traffic to the stepping stone only from a selection of trusted Internet sources (wherever you successfully used it from), and every time you move to a new place, just make the phone ring to lower the firewall for a short period of time, have it learn from where you are connecting, and raise again.

Another method (for people won't do have a VoIP account) would be using Twitter: you could have your firewall monitoring a Twitter feed, and whenever you would want your firewall to lower, you could send a message to this Twitter feed via SMS, but this costs money...


*phew*

So here you are... I hope I haven't forgotten anything as I just finished writing this in a hurry to finally get it over with. Some day I might explain how to generate the stepping stone liveCD with Debian Live... In the meantime: questions, suggestions, comments etc are welcome :-)

Saturday, June 6, 2009

Internet by all means

(Sorry for the delay; doing now what I should have done a long time ago: split my article in two parts, as it is the second part that really keeps me back... What do you want? Being a perfectionist I can't publish a "From Maximum Risk To Maximum Security" article until I have everything covered :P)

What I describe here should be very useful to you if you can find yourself in at least one of the following situations:
  • you can use an Internet access but it lacks security (e.g. free WiFi hotspots, campus Internet, etc)
  • you want to demonstrate ineffective firewalling during a pentest
  • you subscribed to a 2-years contract for "unlimited mobile Internet access" - so unlimited their marketing department even named it "Illimythics 3G+" in my case - asked every rep you could if it would indeed correspond to your needs, and while none of them seemed to know what SSH is, they all blatantly assured you that it was possible... until you realized, too late, that it is in fact HTTP-only
  • you feel ripped-off by a hotel reservation that you chose specifically because it advertised Wi-Fi access for customers, but once there you realize they charge extra for it.
All in all, this comes down to a simple problem: how to get a full & secure Internet access in (almost) every case?

To address this problem, we'll rely on what I call a "stepping stone", i.e. a computer reachable by all means, preferably 24/7, with a private full Internet access and to which we will tunnel our Internet traffic by whatever mean we have available at some point.

Now, being able to reach your stepping stone depends on what kind of traffic you are allowed on the connection you try to reach it from... Let's enumerate them from best case to worst case in terms of usability:


1. IPSec traffic directly to the stepping stone

I cite IPSec first because it is THE standard for secure Virtual Private Network-ing and therefore available on all operating systems. However, you will only be able to use it if there is no firewall or if the firewall doesn't filter it (cf. paragraph on IPv6 below), and if behind a NAT router, if you're the sole IPSec user or if the router supports NAT-T.


2. any kind of traffic directly to at least one UDP port on the stepping stone

In this case the best is to use OpenVPN; if you know the port number in advance all you have to do is configure OpenVPN to bind on this port, otherwise you can redirect traffic arriving on other UDP ports to OpenVPN with Netfilter:

iptables -t nat -A PREROUTING -i eth0 -p udp -j REDIRECT --to-port 1194


I made my OpenVPN reachable on all UDP ports because every now and then I am surprised to see some exotic UDP port allowed through a firewall, no idea why... HD Moore wrote a very useful script to test that.


3. any kind of traffic directly to at least one TCP port on the stepping stone

Here you can use OpenVPN like above (but two separate configuration files are needed in order to get it to listen both to UDP and TCP) or OpenSSH tunneling.

I put TCP under UDP because TCP over TCP is considered a bad idea so OpenVPN over TCP or OpenSSH with its new VPN capability (ssh -w) won't work as well as OpenVPN over UDP.

Personally I chose OpenVPN on TCP too because:
  • using OpenSSH to tunnel to a HTTP proxy (like Squid) on the stepping stone is definitely quick to setup (ssh -L 3128:127.0.0.1:3128, and adjust HTTP proxy parameters in your browser, instant messaging client, etc accordingly), or to act itself as a SOCKS proxy (ssh -D 1080) which is even quicker if your applications support SOCKS proxying (all browsers do), but that requires having a highly-privileged daemon facing the Internet for little reason
  • it sure is nice to be able to administer your stepping stone remotely with OpenSSH, but you can always do that once you're connected with OpenVPN
And, same as above, if you know the port number in advance all you have to do is configure OpenVPN to bind on this port, otherwise you can redirect traffic arriving on other TCP ports to OpenVPN with Netfilter:

iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-port 1194


Like with UDP, you never know what crazy TCP port a firewall might allow. I once found a firewall that would allow me nothing but emailing the whole Internet (TCP port 25) : what the f... oh well.


4. IPv6 traffic directly to the stepping stone

While not answering the communications confidentialy aspect by itself (but it goes along with IPSec pretty well), if you're lucky enough to have IPv6 support on both sides and if the firewall administrators were as clueless as to have a default allow policy (yes... they're many) and as not to take IPv6 into account (usually that goes together), IPv6 is a firewall traversal mean deserving to be mentioned.


5. any kind of traffic or just SSL traffic to at least one TCP port (typically 443, the HTTPS port) on the stepping stone via a HTTP or SOCKS proxy

Many people use OpenSSH tunneling with connect.c to get through such proxies; it is indeed convenient but once again, I'm not comfortable with the security implications. Fortunately, OpenVPN supports HTTP and SOCKS proxying out of the box. You can make OpenVPN reachable on TCP port 443 and other ports like explained above.

Note: some mobile Internet operators filter access to their proxy based on the User-Agent string of the web browser shipped with your smartphone; copy it to OpenVPN via the "http-proxy-option AGENT" parameter and off you go!


6. ICMP (like ping) traffic directly to the stepping stone

If for example you are able to ping 4.2.2.2 (one of the easiest publicly pingable IP address to remember), chances are you can use PingTunnel to connect to a TCP port on your stepping stone, and from there access the whole Internet securely by using OpenVPN or OpenSSH... There are issues with some NAT routers, so you might want to try "unprivileged mode" in PingTunnel, not for security reasons (I heavily patched PingTunnel to make it super tight; you'll see in next blog post) but because it then uses real ICMP Echo requests and replies (to the cost of throughput), which get through the NAT routers that don't like how PingTunnel normally operates.

Also, a firewall not allowing ICMP Echo doesn't mean it won't allow ICMP messages of other types... Come to think about it, I'll have to add this feature too to PingTunnel.


7. recursing DNS requests to the stepping stone via some DNS server


Now, about DNS tunneling: I put it among the last in this list because it provides less throughput than the previous solutions and really, from a protocol engineering point of view, it's ugly... Then again, it's AWESOME because it works almost everywhere!

In order to use it, you will need a domain name (or a subdomain at DNSTunnel.de, kindly offered by Julius Plenz) and one of the following: NSTX, Iodine, OzymanDNS, Heyoka...

Research is still active on the subject of DNS tunneling, this is why there are many tools already and more coming up. NSTX is the historical one, Iodine offers better throughput than NSTX and is available for most operating systems. OzymanDNS and Heyoka are less than a year old and still a bit proof-of-concept-ish but nonetheless interesting: the former is Dan Kaminsky's attempt, and the latter has the highest ambition.

Personally I'm more than happy with Iodine.

EDITED TO ADD: As Nicolas Ruff pointed out, DNS tunneling can "severely degrade network performance" of everybody else using the same DNS server, so be reasonable.



8. HTTP traffic to TCP port 80 on the stepping stone through a (transparent) HTTP proxy


As the name suggests, transparent proxies transparently redirect your connections to the Internet on TCP port 80 to a local HTTP proxy; it may look like you are simply allowed TCP port 80 to the Internet, but try sending anything else than HTTP on this port, it won't work. Good thing to know though: even if the transparent HTTP proxy doesn't let you through for some reason, you will most likely be able to do DNS tunneling (see above) as letting the clients perform their own DNS requests is mandatory in transparent HTTP proxy setups.

Now, allowing HTTP but not HTTPS is utterly suspicious, besides breaking many web authentication procedures. Fortunately it is very rare, but in case you end up in this situation, HTTPTunnel is the way out: it will give you the possibility to connect to another TCP port on your stepping stone (and thus reach OpenVPN or OpenSSH) while making your traffic look like HTTP.

Note: User-Agent filtering can happen in this case too, see paragraph on HTTP and SOCKS proxies for solution.



9. other means of relaying data to and from the stepping stone via some reachable server


Apparently my friend Mubix has a super-secret project coming on that... in addition to having a Hak5 episode on tunneling SSH over DNS :)

EDITED TO ADD: You were several to guess that what was left out in this list was email tunneling... I did so intentionally as I didn't want to give away Mubix's project. Now it appears Mourad Ben Lakhoua beat him to it, but only with HTTP, which we'll count as cheating because HTTP has basically the same transfer encodings as emails and the same request-response model :-P Sure, HTTPTunnel can most likely be stacked on top of that (and we would end up with TCP/IP over SSH over HTTP over SMTP&IMAP, heh) but it would be interesting to see if other, better methods of email tunneling are conceivable.



As you can see, if you want to maximize your chances to reach your stepping stone and thus get a full & secure Internet access, you basically have to make it face the Internet with all TCP ports open, all UDP ports open and even ICMP tied to a daemon... While I generally disagree with the people who say a computer with 10 ports open is more insecure than a computer with 4 ports open, I have to concede that we are kind of daring the devil here...

And that is why in the other half of this article (which I'll hopefully manage to find the time to finish within the week) I will explain how to achieve maximum security! :)

Friday, April 17, 2009

Per-process routing

Just a quick tip before the big monthly blog post :-)

Today I was asked by a friend if it was possible to assign different network interfaces to different programs for their Internet traffic...

For example, let's say you're a student living on-campus; the university provides you with broadband Internet access via Wi-Fi, which is great, except for the fact that you cannot trust it (yes, even when you're careful to use HTTPS and so on, I'll cover that in subsequent blog posts). A general solution to that problem would be getting your very own private Internet access, but being a student, you would prefer not to waste too much money into it, so you'll most likely take the cheapest subscription. So now you have two routes to the Internet: a fast but insecure one, and another that is private but slow. How to use both on the same computer? As bandwidth-intensive applications are often also the ones that don't really require privacy, one could imagine categorizing programs in a way so as to watch Internet TV over the Wi-Fi network while corresponding over the cable.

Here's how to do it with Linux, assuming that the default route is your private connection and that your Wi-Fi interface is named ath0, has IP address 10.1.2.3 and gateway 10.0.0.1:
  1. Create a "wifi" user

    adduser wifi

  2. Mark packets coming from the wifi user

    iptables -t mangle -A OUTPUT -m owner --uid-owner wifi -j MARK --set-mark 42

  3. Apply the Wi-Fi IP address on them

    iptables -t nat -A POSTROUTING -o ath0 -m mark --mark 42 -j SNAT --to-source 10.1.2.3

  4. Route marked packets via Wi-Fi

    ip rule add fwmark 42 table 42
    ip route add default via 10.0.0.1 dev ath0 table 42

  5. Launch programs as the wifi user

    sudo -u wifi vlc

Step 1 is of course required only once; steps 2, 3 and 4 are better put together in a shell script. Regarding step 5, it is much more practical to edit your KDE menu entries for example and there specify that the program has to be run as the wifi user.

One last remark: know your localhost network architecture, some of the wifi user's traffic might still go via the default route! This will be the case if, for example, you use a local DNS cache such as NSCD or any other kind of local proxying (Privoxy, Tor, etc).

Wednesday, March 25, 2009

Cracking passwords with Wikipedia, Wiktionary, Wikibooks etc

One effective way of assessing password strength is to try and
crack them, and as most of you probably know, dictionary attack is the simplest yet formidable technique for cracking passwords.

Now, the problem is: your dictionary has to be as exhaustive as possible. Relying solely on common dictionaries (such as The Collins, Le Larousse, the ones contained in spell checkers, etc) just won't do because these are very limited, whereas basic human nature has us looking around when prompted to choose a password; a lot of people will then choose "belinea" because it's the brand of the monitor sitting in front of their eyes, "abnamro" because it's the bank outside their window, and so on.

However, it is very likely that any word you can put your eyes on is already in Wikipedia: try it, it is amazing.

A couple of years ago I generated a quick & dirty wordlist from Wikipedia in a dozen of languages. It helped quickly crack countless passwords, a lot of which bruteforcing would never get to.

Recently I managed to spare some time in order to generate a new one, inventorying words from 2009 (my old Wikipedia wordlist doesn't even have "twitter", imagine that :-P ) and from a way more comprehensive list of sources:

aawiki aawikibooks aawiktionary abwiki abwiktionary advisorywiki afwiki afwikibooks afwikiquote afwiktionary akwiki akwikibooks akwiktionary alswiki alswikibooks alswikiquote alswiktionary amwiki amwikiquote amwiktionary angwiki angwikibooks angwikiquote angwikisource angwiktionary anwiki anwiktionary arcwiki arwiki arwikibooks arwikinews arwikiquote arwikisource arwiktionary arzwiki astwiki astwikibooks astwikiquote astwiktionary aswiki aswikibooks aswiktionary avwiki avwiktionary aywiki aywikibooks aywiktionary azwiki azwikibooks azwikiquote azwikisource azwiktionary barwiki bat-smgwiki bawiki bawikibooks bawiktionary bclwiki betawikiversity bewiki bewikibooks bewikiquote bewiktionary be-x-oldwiki bgwiki bgwikibooks bgwikinews bgwikiquote bgwikisource bgwiktionary bhwiki bhwiktionary biwiki biwikibooks biwiktionary bmwiki bmwikibooks bmwikiquote bmwiktionary bnwiki bnwikibooks bnwikisource bnwiktionary bowiki bowikibooks bowiktionary bpywiki brwiki brwikiquote brwiktionary bswiki bswikibooks bswikinews bswikiquote bswikisource bswiktionary bugwiki bxrwiki cawiki cawikibooks cawikinews cawikiquote cawikisource cawiktionary cbk-zamwiki cdowiki cebwiki cewiki chowiki chrwiki chrwiktionary chwiki chwikibooks chwikimedia chwiktionary chywiki commonswiki cowiki cowikibooks cowikiquote cowiktionary crhwiki crwiki crwikiquote crwiktionary csbwiki csbwiktionary cswiki cswikibooks cswikinews cswikiquote cswikisource cswikiversity cswiktionary cuwiki cvwiki cvwikibooks cywiki cywikibooks cywikiquote cywikisource cywiktionary dawiki dawikibooks dawikiquote dawikisource dawiktionary de-labswikimedia dewiki dewikibooks dewikinews dewikiquote dewikisource dewikiversity dewiktionary diqwiki dsbwiki dvwiki dvwiktionary dzwiki dzwiktionary eewiki elwiki elwikibooks elwikiquote elwikisource elwikiversity elwiktionary emlwiki en-labswikimedia enwiki enwikibooks enwikinews enwikiquote enwikisource enwikiversity enwiktionary eowiki eowikibooks eowikiquote eowiktionary eswiki eswikibooks eswikinews eswikiquote eswikisource eswikiversity eswiktionary etwiki etwikibooks etwikiquote etwikisource etwiktionary euwiki euwikibooks euwikiquote euwiktionary extwiki fawiki fawikibooks fawikiquote fawikisource fawiktionary ffwiki fiu-vrowiki fiwiki fiwikibooks fiwikinews fiwikiquote fiwikisource fiwiktionary fjwiki fjwiktionary foundationwiki fowiki fowikisource fowiktionary frpwiki frwiki frwikibooks frwikinews frwikiquote frwikisource frwikiversity frwiktionary furwiki fywiki fywikibooks fywiktionary ganwiki gawiki gawikibooks gawikiquote gawiktionary gdwiki gdwiktionary glkwiki glwiki glwikibooks glwikiquote glwikisource glwiktionary gnwiki gnwikibooks gnwiktionary gotwiki gotwikibooks guwiki guwikibooks guwikiquote guwiktionary gvwiki gvwiktionary hakwiki hawiki hawiktionary hawwiki hewiki hewikibooks hewikinews hewikiquote hewikisource hewiktionary hifwiki hiwiki hiwikibooks hiwikiquote hiwiktionary howiki hrwiki hrwikibooks hrwikiquote hrwikisource hrwiktionary hsbwiki hsbwiktionary htwiki htwikisource huwiki huwikibooks huwikinews huwikiquote huwikisource huwiktionary hywiki hywikibooks hywikiquote hywikisource hywiktionary hzwiki iawiki iawikibooks iawiktionary idwiki idwikibooks idwikiquote idwikisource idwiktionary iewiki iewikibooks iewiktionary igwiki iiwiki ikwiki ikwiktionary ilowiki incubatorwiki iowiki iowiktionary iswiki iswikibooks iswikiquote iswikisource iswiktionary itwiki itwikibooks itwikinews itwikiquote itwikisource itwikiversity itwiktionary iuwiki iuwiktionary jawiki jawikibooks jawikinews jawikiquote jawikisource jawikiversity jawiktionary jbowiki jbowiktionary jvwiki jvwiktionary kaawiki kabwiki kawiki kawikibooks kawikiquote kawiktionary kgwiki kiwiki kjwiki kkwiki kkwikibooks kkwikiquote kkwiktionary klwiki klwiktionary kmwiki kmwikibooks kmwiktionary knwiki knwikibooks knwikiquote knwikisource knwiktionary kowiki kowikibooks kowikiquote kowikisource kowiktionary krwiki krwikiquote kshwiki kswiki kswikibooks kswikiquote kswiktionary kuwiki kuwikibooks kuwikiquote kuwiktionary kvwiki kwwiki kwwikiquote kwwiktionary kywiki kywikibooks kywikiquote kywiktionary ladwiki lawiki lawikibooks lawikiquote lawikisource lawiktionary lbewiki lbwiki lbwikibooks lbwikiquote lbwiktionary lgwiki lijwiki liwiki liwikiquote liwikisource liwiktionary lmowiki lnwiki lnwikibooks lnwiktionary lowiki lowiktionary ltwiki ltwikibooks ltwikiquote ltwikisource ltwiktionary lvwiki lvwikibooks lvwiktionary map-bmswiki mdfwiki mediawikiwiki metawiki mgwiki mgwikibooks mgwiktionary mhwiki mhwiktionary miwiki miwikibooks miwiktionary mkwiki mkwikibooks mkwikisource mkwiktionary mlwiki mlwikibooks mlwikiquote mlwikisource mlwiktionary mnwiki mnwikibooks mnwiktionary mowiki mowiktionary mrwiki mrwikibooks mrwikiquote mrwiktionary mswiki mswikibooks mswiktionary mtwiki mtwiktionary muswiki myvwiki mywiki mywikibooks mywiktionary mznwiki nahwiki nahwikibooks nahwiktionary napwiki nawiki nawikibooks nawikiquote nawiktionary nds-nlwiki ndswiki ndswikibooks ndswikiquote ndswiktionary newiki newikibooks newiktionary newwiki ngwiki nlwiki nlwikibooks nlwikimedia nlwikinews nlwikiquote nlwikisource nlwiktionary nnwiki nnwikiquote nnwiktionary nostalgiawiki novwiki nowiki nowikibooks nowikimedia nowikinews nowikiquote nowikisource nowiktionary nrmwiki nvwiki nywiki nzwikimedia ocwiki ocwikibooks ocwiktionary omwiki omwiktionary orwiki orwiktionary oswiki pagwiki pamwiki papwiki pa-uswikimedia pawiki pawikibooks pawiktionary pdcwiki pihwiki piwiki piwiktionary plwiki plwikibooks plwikimedia plwikinews plwikiquote plwikisource plwiktionary pmswiki pntwiki pswiki pswikibooks pswiktionary ptwiki ptwikibooks ptwikinews ptwikiquote ptwikisource ptwikiversity ptwiktionary qualitywiki quwiki quwikibooks quwikiquote quwiktionary rmwiki rmwikibooks rmwiktionary rmywiki rnwiki rnwiktionary roa-rupwiki roa-rupwiktionary roa-tarawiki rowiki rowikibooks rowikinews rowikiquote rowikisource rowiktionary rswikimedia ruwiki ruwikibooks ruwikinews ruwikiquote ruwikisource ruwiktionary rwwiki rwwiktionary sahwiki sawiki sawikibooks sawiktionary scnwiki scnwiktionary scowiki scwiki scwiktionary sdwiki sdwikinews sdwiktionary sewiki sewikibooks sewikimedia sgwiki sgwiktionary shwiki shwiktionary simplewiki simplewikibooks simplewikiquote simplewiktionary siwiki siwikibooks siwiktionary skwiki skwikibooks skwikiquote skwikisource skwiktionary slwiki slwikibooks slwikiquote slwikisource slwiktionary smwiki smwiktionary snwiki snwiktionary sourceswiki sowiki sowiktionary specieswiki sqwiki sqwikibooks sqwikiquote sqwiktionary srnwiki srwiki srwikibooks srwikinews srwikiquote srwikisource srwiktionary sswiki sswiktionary stqwiki stwiki stwiktionary suwiki suwikibooks suwikiquote suwiktionary svwiki svwikibooks svwikinews svwikiquote svwikisource svwiktionary swwiki swwikibooks swwiktionary szlwiki tawiki tawikibooks tawikinews tawikiquote tawikisource tawiktionary testwiki tetwiki tewiki tewikibooks tewikiquote tewikisource tewiktionary tgwiki tgwikibooks tgwiktionary thwiki thwikibooks thwikinews thwikiquote thwikisource thwiktionary tiwiki tiwiktionary tkwiki tkwikibooks tkwikiquote tkwiktionary tlhwiki tlhwiktionary tlwiki tlwikibooks tlwiktionary tnwiki tnwiktionary tokiponawiki tokiponawikibooks tokiponawikiquote tokiponawiktionary towiki towiktionary tpiwiki tpiwiktionary trwiki trwikibooks trwikiquote trwikisource trwiktionary tswiki tswiktionary ttwiki ttwikibooks ttwikiquote ttwiktionary tumwiki twwiki twwiktionary tywiki udmwiki ugwiki ugwikibooks ugwikiquote ugwiktionary ukwiki ukwikibooks ukwikimedia ukwikinews ukwikiquote ukwikisource ukwiktionary urwiki urwikibooks urwikiquote urwiktionary uzwiki uzwikibooks uzwikiquote uzwiktionary vecwiki vewiki viwiki viwikibooks viwikiquote viwikisource viwiktionary vlswiki vowiki vowikibooks vowikiquote vowiktionary warwiki wawiki wawikibooks wawiktionary wikimania2005wiki wikimania2006wiki wikimania2007wiki wikimania2008wiki wikimania2009wiki wowiki wowikiquote wowiktionary wuuwiki xalwiki xhwiki xhwikibooks xhwiktionary yiwiki yiwikisource yiwiktionary yowiki yowikibooks yowiktionary zawiki zawikibooks zawikiquote zawiktionary zeawiki zh-classicalwiki zh-min-nanwiki zh-min-nanwikibooks zh-min-nanwikiquote zh-min-nanwikisource zh-min-nanwiktionary zhwiki zhwikibooks zhwikinews zhwikiquote zhwikisource zhwiktionary zh-yuewiki zuwiki zuwikibooks zuwiktionary

All this represents tens of gigabytes of XML data that I processed with a little C program, but I'm not releasing the source code for this one as I don't want to be responsible for a bandwidth hit on the Wikimedia Foundation; I'm already more than grateful to them for helping me on a daily basis...

For the record: I didn't alter the case before saving this wordlist. If you want to force lowercase on all the words, be advised that:
  • sure JohnTheRipper's derivation algorithms will uppercase letters here and there, but it might miss passwords like "hawKeye" or "amaroK"
  • forcing case on UTF-8 text is tricky
Currently, the wordlist can be downloaded from a temporary storage provided by my ISP: wikipedia-wordlist-sraveau-20090325.txt.bz2 (MD5=e28104f22192b84854d259d9e93b5042, just for integrity). Feel free to leave a comment if you need a re-upload, or better yet if you can provide hosting ;-)

EDITED TO ADD:

The wordlist is now mirrored at several places:
Many thanks to Tyop , sbz, s0kket and Sorcier_FXK!

Also, for those wondering: there are 58427178 words in the wordlist, and it weighs 213MB (710MB uncompressed).

Tuesday, February 17, 2009

Playing with DNS servers... some more

Killing time in the metro by listening to podcasts of past security conferences, I got the idea of using DNS caches to check IP-spoofing capability.

Now, the easiest way to check if you can send packets to the Internet with a fake source IP address would be with two computers (in different ASs), but that's no fun, is it? :)

Basically, the idea is you can know from a DNS caching server if you are the first client getting the reply to some query by either
  • asking it about a domain for which it would have to recurse, while forbidding recursion: if you get a positive reply this means somebody else asked the same question before you
  • comparing maximum Time-To-Live value for the test domain with the TTL value you received in the reply: if different, this too means somebody else asked the same question before you
So, if you issue an improbable query (for example 0.577493021235...325521009964.ws which will resolve correctly because .ws uses wildcard records) to a DNS caching server while faking the source IP address, and then issue the very same query from your real IP address a couple of seconds after, the reply to the latter will tell if the DNS server received the former.

The only problem is making sure no network equipment enforced a real source IP address on the packets... Some ISPs might simply rewrite the source IP address (instead of just dropping the packet, which most of them do) : this is easy to detect because you would get replies to both the "fake" and real queries. NAT routers are more annoying: mine accepts the fake public IP address as source to the packets, stores it in its table, forwards the packets with its real IP address, and when the replies arrive... doesn't know whom to send the packets to, other than to the DMZ (which is noticeable because it starts sending ARP requests for it)... Stupid, stupid NAT router!

Anyway, here's the code.