Why you should not use ‘OR 1=1’ when testing for SQL injection (part 2)

In my previous post, I explained why testing for SQL injection using ‘OR 1=1’ can lead to data loss. In this article, I will describe an alternative and safer approach.

I like to use ‘AND 1=0’ instead of ‘OR 1=1’. This does not increase the number of items affected by a query, but (in most cases) results in the query returning 0 rows (as 1=0 is never true ?). In our previous example of a site displaying articles, no article would have been displayed. The resulting query would become:

SELECT title,text,hitcount FROM articles WHERE id=1234 AND 1=0

That query would return 0 rows. So now what? We’re looking at the site we’re testing and no article is displayed, so what? It doesn’t mean there’s SQL injection. Well, now we enter ‘AND 1=1’ after the articleID and the following query is executed:

SELECT title,text,hitcount FROM articles WHERE id=1234 AND 1=1

Now the ‘AND 1=1’ does not affect the original query, and article 1234 is displayed. At this point I am pretty sure I have SQL injection and could try a UNION SELECT to extract more information from the database.

Of course, this is not the only solution to this problem, but it’s one of the safest to use (unless the application displays SQL errors). For bypassing authentication I still sometimes use the OR approach, but in most cases you do not have to take the risk.

Why you should not use ‘OR 1=1’ when testing for SQL injection (part 1)

Everybody who has read a paper on SQL injection has seen the ‘OR 1=1’ example (or the similar ‘ OR ‘’=’). It is the classic method for bypassing authentication when an application does not sanitize user input before using it in SQL queries.

I think it is somewhat overused. Often I see pentesters throwing this kind of string into each input field, hoping to trigger an SQL injection or some kind of error. Some tools which test for SQL injection (for example Nessus) also do it.

So why do I think it’s bad? Well, because it can have a major impact on the query that’s executed and has the potential to break things. Production systems are often the target of pentests and we should try not to break those.

Unless you have the source code to the application, you can’t know exactly what happens with your input string. Most people assume they are injecting into SELECT statements, but of course, applications also use DELETE, UPDATE and INSERT, which modify the database. Let me give you a real life example, we once cam e across an application which did this ($articleID comes from user input):

‘SELECT title,text,hitcount FROM articles WHERE id=’ + $articleID

A prime target for SQL injection! But a little further in the code something else happens:

‘UPDATE articles SET hitcount=’ + $hitcount+1 ‘ WHERE id=’ + $articleID

So the application first retrieves the title,text and hitcount for a certain article from the database, all is well here, the only thing that happens if we enter ‘OR 1=1’ after the articleID is that the application will receive all articles from the database and will most likely pick the first one.

The next statement is a different story, as the application tries to change something. It has retrieved the ‘hitcount’ for the article in the previous query (the hitcount being the number of times the article has been viewed) and uses it in a different query, to update the hit counter with a new view. Our articleID is used again as well, but in this case the resulting query becomes something like:

UPDATE articles SET hitcount=1338 WHERE articleID=1234 OR 1=1

This will set the hitcount to 1338, but instead for just just article 1234, it changes it for all articles in the table, not what we intended to do! Of course this is in most cases a relatively harmless scenario (and an example of lousy software engineering), but had our articleID been used in a DELETE statement, all articles would have been deleted from the table.

In the next part of this article, I will describe an alternative approach.

My DECT handset actually wants to encrypt!

I had the opportunity to test some more DECT phones and interception worked great on most of them. A friend’s Siemens Gigaset 4010 and a Panasonic 720 both did not encrypt conversations and were easy to eavesdrop on.

When I got to another friend’s house, it was a different story. He had two DECT handsets, a Profoon (similar to the one without encryption I own) and a Siemens C455 IP. The C455 is very similar to the C475 listed on dedected.org which uses encryption, so I expected this one to encrypt as well. It did use encryption, the only audio I got was static. I was surprised to see (or hear) however, that his Profoon used encryption as well. It turned out he did not use the base station which came with the Profoon handset, he had instead paired the handset with the C455 base station.

I had brought my own Profoon handset and base station so we decided to pair it with the C455 base station as well to see if it would encrypt. It turns out it did! So what I bought is a handset which does support encryption, but a base station which refuses to encrypt. To confirm this we paired his C455 handset with my base station and as expected, no encryption. I knew to use encryption, both the handset and base station need to support it, but I did not expect they would be selling ‘incompatible’ combinations. It does make sense though, the manufacturers probably just buy the cheapest chipset for both the handset and base station. As there is a standard, they have no problems communicating, but the manufacturer might not even realize they are unable to encrypt.

This fact could make mitigating the vulnerability a bit easier. A large organisation with a lot of DECT handsets may not need to replace their entire DECT system, but may be able to keep either the base stations or the handsets. So in my opinion, the ListOfPhones on dedected.org could use another column: whether the lack of encryption on certain sold combinations is caused by the phone, the base station or both.

More on DECT sniffing and attacks

The dedected blog reports the COM-ON-AIR Type II cards are practically sold out, so they are working on supporting the older (less compatible) Type III cards. I took a look on eBay and only Type III and PCI cards are available right now. Looking at the ended auctions, it seems that (in the last two weeks ) over 700 Type II cards have been sold on eBay!

Patches are now available on the dedected mailing-list which allow capturing directly to audio files. So no more converting captured calls. These should be integrated into the main SVN soon (apparently there are some licensing issues). I did not have a chance to test the patches so far. A draft of the paper detailing the attacks and the DSAA algorithm is also available on the dedected wiki: Attacks on the DECT authentication mechanisms.

Finally, the DECT forum has reacted on the possibility of DECT eavesdropping. They state this:

"It is impossible to accidentally eavesdrop on telephone conversations and therefore the risk for users is very low. Only those with a clear criminal energy and intent and a sophisticated knowledge would be capable of eavesdropping."

I can’t say I agree with them. Yes, of course eavesdropping on other people’s phone calls is illegal and it should be, but with the tools dedected has created it is certainly not hard to do so. I'm not interested in my neighbours phone calls, but a lot of people probably are. Just look at the number of cards sold on eBay, these can’t all be nice pentesters with good intentions :-).

Update: I have tested the patch for capturing directly to audio files. The dect_cli tool does store .wav files as well as .pcap files now. With my handset, the files are sometimes empty (well, their size is 44 bytes) though, while they shouldn't be. When it does work, the .wav files are quite nice, but with my handset, the volume still turns out quite low. A bit of amplification using Audacity works well though.

Sniffing DECT

A couple of weeks ago, at the CCC congress in Germany, a couple of guys gave a presentation about attacks on DECT cordless phones. Basically, you can buy a DECT PCMCIA card and create a rogue base station (tunnel the calls through a VOIP gateway while you record them) or intercept unencrypted phone calls.

Indeed, some of the DECT phones use no encryption at all. DECT phones are supposed to use the DECT Standard Cipher (DSC) but some just do not (maybe encryption is optional in the DECT standard?). The presenters have a website at dedected.org which describes some more technical details.

I decided to buy a COM-ON-AIR DECT PCMCIA card on eBay and it arrived today! The people at dedected.org have created Linux drivers for this card and it was pretty easy to get it working on my Ubuntu laptop.

The dedected SVN includes patches for Kismet-newcore (DECT module) and Wireshark, but also include a couple of handy standalone tools. One of these is called dect_cli. With this tool you can scan for DECT base stations, calls and even record calls. I’ve put some sample output of this tool here (the call I am sniffing is my own).

I also went to a hardware store (GAMMA) this evening and bought the cheapest DECT phone (Profoon PDX-500) so I could play around with it. The box says ‘GAP compatible DECT digital’. I do not have a working landline at the moment so I had to try it without one. This phone, as it turns out, does not use encryption. After recording the call, I could hear myself faintly saying ‘hello hello hello’ (not in a very creative mood), albeit with a lot of static. I’ll try to get my hands on some more DECT phones, I’m curious how many of the phones sold in the Netherlands do not use encryption.

I did not get a clear sound with the current tools. According to the dedected wiki this is something they are still working on. You can listen to a bit of music-over-DECT (and a lot of static) I recorded here (raw dump files here). I simply used sox without any options to convert it to .wav, but there is a 'modified decode' on the dedected wiki which should result in somewhat better quality. In my case, using this filter resulted in a lot of silence but the beeps at the end of the file were very clear :-).

Update: I got the opportunity to test this with another DECT phone. Combined with the 'modified decode' I was able to get really good sound quality.
Also, it turns out that encryption is optional in the DECT standard, as this document (pdf) from the DECT Forum describes (on page 11).