When asking the Internet about the definition of a logic bomb, statements, such as the following from Wikipedia, are returned: "A logic bomb is a piece of code intentionally inserted into a software system that will set off a malicious function when specified conditions are met." The definition does only implicitly include, by stating "will set off" instead of "may set off", the requirement that the logic bomb has to actually function to be called that. Otherwise, we call it an embarrassment.
Being invited by mc.fly to speak at the MRMCD event, I found myself talking to a few nice gentlemen about SQL injections and their use. One of them (his name is intentionally left out) lends me his laptop, a brave thing to do in any case, and pointed his browser to a demo web application for employee work time tracking, which he said is used in his work place. The first thing we noticed was that the standard "I'm here to work now" button was labelled "coming", while there was another button labelled for the exceptional case of "coming with a reason". The software vendor selling this application must be an interesting place to work at.
When we played with a few SQL injections in the application's "Search for employee by name" function on the "absence from work" page, a most interesting error message was returned:
The only contributions we made to the statement were a few characters and a single tick, which of course caused the expression to be invalid. The limiting expression
AND p.nummer >= 'AND p.nummer NOT IN (12,17) ORDER BY Nachname'is part of the software. I can only assume that the statement did not work due to the AND operator following directly the >= operator in the first place. Therefore, the brilliant programmer enclosed it in single ticks and no more errors were displayed.
The purpose of the expression was obviously to not display the time records of employee number 12 and 17, since p.nummer is the short form of Personalnummer, the German's term for employee ID. It is arguable if such a feature would never be noticed (as in "Why is Mr. L33t Coder never on the time records?"). Or, as Fefe would put it: "Das merken die NIE !1!!"
What should be noticed here is:
If your software is in a state where random hackers refer to it as a perfect training ground for SQL injection techniques, you should be worried. If the hackers in question identify, with the first injection attempt, your developer's backdoor, which doesn't even work, you should be embarrassed.
And the morale of the story: When you buy software, you don't know what it is going to do. Although the task everything but easy, I think it's high time to fix that.