Search and you will WHAT???

As much as I loved stumbling on google when it was starting up, as eager I have been finding even better engines.

It is amazing how difficult it is to build a better google. The latest attempt is called cuil and it too, fails.

I challance you to find anything. So far only the simplest of searches yields useable results. Like searching for linkedin actually gives www.linkedin.com as a first hit: well done. Searching for 'mokum von Amsterdam' give two pages of something I once posted on the Wired blog and that has been replicated 1.000 times on other sites: no link to this blog or anything usefull.

Try searching for 'ING bank' in google and in cuil. Tell me why on earth ING Poland & Timisoara show up in Cuil on page one? How on earth did these guys fill up their repository?

Altavista does better FFS! [as a matter of fact, altavista showed me a nice bar in Berlin I will visit next time around].

Lessons learned: stick to google, use altavista more often, wait till cuil grows up, if ever.

DE ONTVOERING

hun hebben zij
klaagt de klant tegen de kapper

hun hebben zij
is niet goed Nederlands, meneer
wist de knipper

zij hebben haar, meneer
zij hebben haar

-- Frans Engels

Why OpenDNS [if you can not run DJBDNS]

To test, I let DHCP update my resolve file with the DNS servers of my [horribly slow!] KPN Internet mobile connection:

bash-3.2# cat /etc/resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 62.133.126.28
nameserver 62.133.126.29

The top two address are my 'normal' DNS entries, from the fine folks of OpenDNS [who where secure since day one].

Now let's check the DNS servers from both OpenDNS & KPN mobile with a simple dig:

bash-3.2# dig @208.67.220.220 +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"208.69.34.6 is GOOD: 28 queries in 1061.8 seconds from 28 ports with std dev 17429.24"
bash-3.2# dig @208.67.222.222 +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"208.69.34.4 is GOOD: 26 queries in 4.3 seconds from 26 ports with std dev 20231.33"

bash-3.2# dig @62.133.126.28 +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"62.133.126.28 is POOR: 26 queries in 4.2 seconds from 1 ports with std dev 0.00"
bash-3.2# dig @62.133.126.29 +short porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"62.133.126.29 is POOR: 26 queries in 4.2 seconds from 1 ports with std dev 0.00"

Of course, nothing beats djbdbs, but for day today use, OpenDNS p0wnserz your provider's DNS hands down.

To keep your resolve.conf file save and clean on OSX and prevent DHCP from updating it, set the immutable bit:
chflags uchg /var/run/resolv.conf
To remove the flag use:
chflags nouchg /var/run/resolv.conf

CloudTablet or CloudPannel?

Interesting idea over at TechCrunch: a simple, US$200 WebTablet, running FireFox & Skype.

For me this is the ultimate CloudPannel [zero hits ATM], or CloudTablet [less then 350 hits ATM], whatever you prefer.

I would like 5 or 10 laying around the house for easy web 2.0 access!

DNS issues released

The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.

1.

Pretend for the moment that you know only the basic function of DNS — that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.

Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bob’s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice — once when he is called to the counter to place his order and again when he’s called back to get his sandwich. If you’re wondering, Bob likes ham on rye with no onions.

If you’ve got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. It’s called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.

2.

Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.

First, QIDs.

Bob’s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.

It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If I’m Mallory and I’m attacking Bob, how can he distinguish my packets from Alice’s? Because I can’t see the QID in his request, and the QID in my response won’t match. The QID is the only thing protecting the DNS from Mallory (me).

QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, here’s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded —- until Mallory gets Bob to query for WWW.VICTIM.COM. If Mallory’s response gets to your computer before the legitimate response arrives from your ISP’s name server, you will be redirected where Mallory tells you you’re going.

Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bob’s request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race.

But there’s a bunch more problems here:

• If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.

• If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, she’ll break the RNG and be able to predict its outputs.

• 16 bits just isn’t big enough to provide real security at the traffic rates we deal with in 2008.

Your computer’s resolver is probably a stub. Which means it won’t really save the response. You don’t want it to. The stub asks a real DNS server, probably run by your ISP. That server doesn’t know everything. It can’t, and shouldn’t, because the whole idea of DNS is to compensate for the organic and shifting nature of internet naming and addressing. Frequently, that server has to go ask another, and so on. The cool kids call this “recursion”.

Responses carry another value, too, called a time to live (TTL). This number tells your name server how long to cache the answer. Why? Because they deal with zillions of queries. Whoever wins the race between Alice and Mallory, their answer gets cached. All subsequent responses will be dropped. All future requests for that same data, within the TTL, come from that answer. This is good for whoever wins the race. If Alice wins, it means Mallory can’t poison the cache for that name. If Mallory wins, the next 10,000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0.

3.

Then there’s that other set of DNS vulnerabilities. These require you to pay attention in class. They haven’t really been talked about since 1997. And they’re hard to find, because you have to understand how DNS works. In other words, you have to be completely crazy. Lazlo Hollyfeld crazy. I’m speaking of course of RRset poisoning.

DNS has a complicated architecture. Not only that, but not all name servers run the same code. So not all of them implement DNS in exactly the same way. And not only that, but not all name servers are configured properly.

I just described a QID attack that poisons the name server’s cache. This attack requires speed, agility and luck, because if the “real” answer happens to arrive before your spoofed one, you’re locked out. Fortunately for those of you that have a time machine, some versions of DNS provide you with another way to poison the name server’s cache anyway. To explain it, I will have to explain more about the format of a DNS packet.

DNS packets are variable in length and consist of a header, some flags and resource records (RRs). RRs are where the goods ride around. There are up to three sets of RRs in a DNS packet, along with the original query. These are:

• Answer RR’s, which contain the answer to whatever question you asked (such as the A record that says WWW.VICTIM.COM is 1.2.3.4)

• Authority RR’s, which tell resolvers which name servers to refer to to get the complete answer for a question

• Additional RR’s, sometimes called “glue”, which contain any additional information needed to make the response effective.

A word about the Additional RR’s. Think about an NS record, like the one that COM’s name server uses to tell us that, to find out where WWW.VICTIM.COM is, you have to ask NS1.VICTIM.COM. That’s good to know, but it’s not going to help you unless you know where to find NS1.VICTIM.COM. Names are not addresses. This is a chicken and egg problem. The answer is, you provide both the NS record pointing VICTIM.COM to NS1.VICTIM.COM, and the A record pointing NS1.VICTIM.COM to 1.2.3.1.

Now, let’s party like it’s 1995.

Download the source code for a DNS implementation and hack it up such that every time it sends out a response, it also sends out a little bit of evil — an extra Additional RR with bad information. Then let’s set up an evil server with it, and register it as EVIL.COM. Now get a bunch of web pages up with IMG tags pointing to names hosted at that server.

Bob innocently loads up a page with the malicious tags which coerces his browser resolve that name. Bob asks Alice to resolve that name. Here comes recursion: eventually the query arrives at our evil server. Which sends back a response with an unexpected (evil) Additional RR.

If Alice’s cache honors the unexpected record, it’s 1995 —- buy CSCO! —- and you just poisoned their cache. Worse, it will replace the “real” data already in the cache with the fake data. You asked where WWW.EVIL.COM was (or rather, the image tags did). But Alice also “found out” where WWW.VICTIM.COM was: 6.6.6.0. Every resolver that points to that name server will now gladly forward you to the website of the beast.

4.

It’s not 1995. It’s 2008. There are fixes for the attacks I have described.

Fix 1:

The QID race is fixed with random IDs, and by using a strong random number generator and being careful with the state you keep for queries. 16 bit query IDs are still too short, which fills us with dread. There are hacks to get around this. For instance, DJBDNS randomizes the source port on requests as well, and thus won’t honor responses unless they come from someone who guesses the ~16 bit source port. This brings us close to 32 bits, which is much harder to guess.

Fix 2:

The RR set poisoning attack is fixed by bailiwick checking, which is a quirky way of saying that resolvers simply remember that if they’re asking where WWW.VICTIM.COM is, they’re not interested in caching a new address for WWW.GOOGLE.COM in the same transaction.

Remember how these fixes work. They’re very important.

And so we arrive at the present day.

5.

Let’s try again to convince Bob that WWW.VICTIM.COM is 6.6.6.0.

This time though, instead of getting Bob to look up WWW.VICTIM.COM and then beating Alice in the race, or getting Bob to look up WWW.EVIL.COM and slipping strychnine into his ham sandwich, we’re going to be clever (sneaky).

Get Bob to look up AAAAA.VICTIM.COM. Race Alice. Alice’s answer is NXDOMAIN, because there’s no such name as AAAAA.VICTIM.COM. Mallory has an answer. We’ll come back to it. Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM.

Alice’s advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is 6.6.6.0!

Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didn’t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact interested in VICTIM.COM for this query. Mallory has combined attack #1 with attack #2, defeating fix #1 and fix #2. Mallory can conduct this attack in less than 10 seconds on a fast Internet link.

----

On a side note: can stuff no longer published but found in google's cache be copyrighted?

Geotagging iPhone gone bad :(

Great feature: geotagging the images taken with the iPhone [already the most Popular Cameraphone on Flickr].

Just imagion that you take photos during the holiday and all you need to do is dump them in, say, google earth and all pics are shown in the correct location. Right, that was the plan. Unfortunatly Apple made a couple of errors with the implementation, again.

The UIImagePicker application that is used when you email a photo from the iPhone, strips out the EXIF location data, DUH! iPhoto mutilates [strips the "Ref" tag] the EXIF geodata when resizing photos, DUH.

So what you get is third party apps that sort-of-help, like AirMe. It will upload the photo to Flickr and geotag it, but then you have to take the pic with AirMe and have NO geodata stored in the EXIF data of the photo at all, and that is bad.

Who knows, maybe if Apple would put a little less invain effort in the locking down of the iPhone they'd be able to get MMS working? Some more features in the camera? Geotagging stored correctly? How difficult is that? How come 17 year old's CAN do that but a multi bilion company can't?
Photo source

Italians...

Good thief's maybe, but crooks. Living with mama till >30. Not being able to clean their own rubbish. Lovely, but lousy cars makers. And so on.

To wrap it up, even in the IT world they show up. And the pain got a name: Zibri. A thief, but then in code.

Read this to get an idea about this crook:

The following opinions are mine, and not those of the DevTeam as a whole, although many members agree with me:

Free thoughts...

There's something that's been on my chest for a while, and it's been bothering others on the team as well. The name of this particular thorn in our sides begins with the letter Z and ends with "ibri". Yes, I'm sure all of you are rolling your eyes at the "drama" we hacker "kids" are stirring up, but I'm sure if you had your work taken without permission, you would feel the same way. It's particularly galling that he is still spreading FUD on his blog in an attempt to save face. I'm going to try to address some of them in this post.

Zibri implies that our jailbreak is not "real", saying instead that our release is a "software upgrade, total internat [sic] firmware modification and custom firmware".

For him, a "real hack" works in a few minutes because it only needs to modify a few bytes here and there.

When Pwnage 1.0 was released, it was indeed the ultimate hack for the iPhone/iPod Touch. Never before had the devices been under the user's control from the very bottom up. Prior, less sophisticated jailbreaks were still subject to the whims of the kernel, which couldn't be modified because the bootloader checked its signature and refused to boot if it was incorrect.

Back in those days, the definition of "hack" above was still a feasible one, as the chain of trust ended at the kernel. Once you gained write access to the root filesystem, you could run arbitrary programs and make patches at will to many system components. Indeed, many such patches were needed, to make activation allow unapproved SIM cards, and to make Springboard display unauthorized apps.

Fast forward back to the present, and you'll see the situation has changed. Solutions that using a ramdisk simply made a change or two to the filesystem now must contend with the mighty kernel's signature checking of all installed apps and libraries. Mounting the root filesystem and modifying /etc/fstab to make it writable is quite alright, but the moment you make patches for activation or anything else, the kernel will refuse to run the modified programs, unless you can somehow steal Apple's private signing key. Furthermore, such a jailbreak would be essentially useless because the system would refuse to run any of your custom software (such as Installer.app or Cydia), again because of the lack of signatures on it.

Given the above situation, it becomes clear that if you want to use 2.0 for anything but screenshots, you either need to get ahold of Apple's signing key (start preparing your army now) or you need to patch the 2.0 kernel. Hard as we tried, we couldn't find much of an army, so we took the latter approach.

We adapted our Pwnage technique to the 2.0 firmware, using a new unreleased exploit that we'd been keeping to ourselves, in the hope that Apple wouldn't patch it. This allows us to cut the signature checks out of the device bootloaders, allowing us to remove signature checking from the kernel, and enabling you to run all the custom software and patches you please.

Please note other than my facetious army suggestions, patching the bootloaders is the _only_ way to get a functional jailbreak for 2.0. Under the aforementioned definition of "real hack", there is no such thing as a "real hack" for 2.0. I hope you agree with me by now that Pwnage, the exploit it uses, and its subsequent obliteration of the device's chain of trust, is a "real hack".

More FUD is spread by this undying rumor of "Palladium" (or TPM) being used fully on Apple's devices, making it impossible for you "to play online with legit buyers." This is nothing but uninformed nonsense, and while there is the potential for some definition of trusted computing on iPhone and iPod Touch, Apple is not using it, and they have no way to remotely distinguish your pwned device from a legitimately activated one. This should have been obvious from our examples of running App Store applications next to our custom ones, but "obvious" is a very relative term.

On an unrelated note, I and the others take issue with Zibri's definition of open source. No, Linux distributions are not stealing, but our work was not released as open source, with any kind of permissive license, so the open source he brings into the discussion is entirely irrelevant. He took our work, our private exploits (such as the unreleased one we were able to use for Pwning 2.0), and without our permission (trying to defame us with fake comments, no less) used them in his work, that he made significant amounts of money on. He did this not by selling "his work", but by portraying himself as the reasonable "dev" who fought against the tyranny of the dev team and Apple, and requesting donations to his "cause" (recall his older iphone-elite.googlecode.com and his self-righteous bashing of the dev team for accepting donations; funny how principles change). Furthermore, with his millions of hits and occasionally obscene ads, he made his site into a complete money machine. So although he did not sell our work, it is more than fair to say that he made plenty of money from it.

And as to his most recent update, I'm not really sure what to say. I'd call it the swan song, but that would imply he was a swan, which is certainly not my intention. Maybe the chicken song would be more appropriate. ZiPhone was "developed" 9 months after the iPhone release, so he's justifying his lack of releases now, okay. Once again he pushes the "real hack" idea, which we hope we've already pounded sufficiently into the ground above. We're not sure how the fact that we were so popular it took down multiple unmetered gigabit servers is a point in his favor. We've had close to a third of his total visits since last week.

I want to dedicate a special paragraph to something that's been bugging us for a while, too. The myth that ZiPhone never harmed a phone. Certainly, we all know that iPhones are almost impossible to brick, but flashing unmatched fls/eep pairs to the baseband is plain irresponsible on Zibri's part. Does he not care about messing up phones, or does he simply not know better? And the laughable WiFi fix he released for issues that he called "user error" (actually a consequence of the above design choice) where he unconditionally set every ZiPhone WiFi MAC address to 0:Z:i:b:r:i? How did he expect that to work? It doesn't take a networking genius to figure out that two such phones on the same network would cause havoc, and indeed it did.

The following few "facts" on his blog are just more FUD. Our tools can't kill iPhones, because the only way to kill an iPhone through software (and even then just the radio) is to flash an incomplete image as the S-Gold bootloader. Apple cannot remotely kill pwned iPhones because as I mentioned earlier, it has no way to detect which iPhones are pwned.

I'm not sure why he goes on to say that you should be satisfied with Apple's AppStore. It certainly contains many good programs, but to quote Zibri just a couple of weeks earlier:

As of today you will have 2 choices:
1) Believe in the community and don't upgrade to 2.0
2) Say goodbye to Installer and freedom and upgrade.

So are you suggesting we say goodbye to freedom now? I guess we can't expect much from someone who made a reputation for himself by denouncing the devteam for accepting donations (not even soliciting them) and who now has a website full of ads, exhortations to donate, and very little content? Now we have given you a nice opportunity to upgrade to 2.0, use the AppStore _and_ use community apps. If he really wanted the good of the community, why is he not recommending it?

I would normally just ignore his entries, but as many still look at Zibri as an authority in the scene, I felt the need to dispel some of the FUD he was spreading, and finally denounce his pathetic attempts to stay relevant. Posting the latest root filesystem key after we release PwnageTool? PwnageTool exposes all the keys right within its plist files. And if he knew about the DFU exploit all along, as he implies, why didn't he take advantage of it? We would like to see him write up an article on how it all works, just to prove that Zibri knows all.

Thank you for your patience reading this. We will continue working hard on providing quality hacks and software, but please, to anyone who's tempted, stop spreading bullshit about us and our work. source

How big is your I-EGO?

My I-EGO is pretty big, people tell me. But how big is it really? Time to find out!

Enter your name & domain and let the www.egosurf.org do the rest.

My 'mokum von Amsterdam' EGO is a mere 4700 points but I am sure your's a lot bigger :P

Shabat shalom!

I just text to say...

I would like a pile of these, right next to the complaint & request notes.


A big pile so I could formalize & incorporate the process in my daily live.


Now who would deserve one signed by you?

We are ING!

Shht!

BattleField 2: new patch 1.5 and 3 new maps

It is still secret, the current internal BETA for the long awaited BF2 1.5 patch is currently running in Spain and guess what:

3 new maps will be released with it [act of G*d clause applies].

The names of the maps I cannot reveal but there will be at least one _you_ will like :P

Queing for the iPhone 2.0

In Rotterdam there is a [modest] queue for the T-Mobile shop that will start selling the iPhone 2.0 from 00:00 sharp.

500 phones are available to those that have no friends, no home, no sex and no lust for beer.

Mine will fall out of the air real soon now, but I can not say I am half as tense as I was with the iPhone orginal a year ago.

SSH scanning on the rise. DENYHOSTS

DenyHosts blocked 44 new ssh user scanning hosts in the last 13 hours. That is a lot.

Normally days with >5 new hosts caught by my lone sensor are remarkable, it happens not more often then 4 times a month. This month has been truly busy however. July 1st 10 new addresses, July 3rd 14, where in the whole month of June there where 2 days with >5 [6 & 8 on the 28th & 30th. A busy month globally] with a grant total of 28 for the whole month.

Nothing advanced either, like the botnet-like scanning in May.


This is for those hosts who made it to the largest blacklist of all times.

My users are smarter then yours!

1. Firefox 221 56.81%
2. Internet Explorer 123 31.62%
3. Safari 34 8.74%
4. Opera 8 2.06%
5. Mozilla 2 0.51%
6. Netscape 1 0.26%

Google's Street View spycar clocked in Amsterdam, Holland

I think this is a first: a google car in Amsterdam. Photo taken on the 1st of July 2008 in Amsterdam, on the Gaasperdammerweg, Amsterdam after I picked up the car coming out of the Huigenbos [I know, all these streets do not sound like Amsterdam... but it is, techincally speaking].


Grotere kaart weergeven

In a year or so you can see me doing silly :P