Cyberpunk as a commodity

… when “leaked” exploit source code is

• Cleanly formatted, following a clean proper coding style, proper variable naming conventions, the works
• Properly commented, including “THIS IS PROPRIETARY SOURCE CODE OF JIMBOB HACKING CREW”
• Has a comprehensive listing of members, often including email addresses etc
• (last but not least), the word “PRIVATE” are repeated every 10 lines or so ….

More on the hypocrisy of Information Security to come … Perhaps making fun of the script kids and the fame seekers is an easy target. So, for the next “Isn’t it …” line of posts, we will be making fun of our friends, the IT security industry (to use a cliche, “modern age snake oil merchants”. And yes, it will be a “name and shame” game, so keep watching this space.

When zines and tutorials continue to ignore what has been going on for the past three years or so. and still repackage “smashing the stack for fun and profit” from like 2 gens ago?

Note to the reader: While I have changed the names of the parties involved, the rest is AS IS

——————————

Phrack #65 is out …

[edit:] Although for many reasons it is against me, I wholeheartedly agree with most of the contents of

http://www.phrack.org/issues.html?issue=65&id=13#article

Please take the time to read, I find it to be the sad truth

Shock Rock: borderline musical idiom. The performers usually play something relatively extreme as compared to the mainstream of the contemporary music. The main stimuli is visual, as shown in the various acts live performances (or “shows”). Usually, the music is not that good and most of these bands prove to be nothing more than a one trick pony. The amount of shocking acts in public permitted by law is deterministic, the genre is quite unpopular now as most of what is to be seen has been shown already back in the 80s. “How is this related to the IT Security industry?”, the astute reader might remark?

Today I had the dubious pleasure to use a port scanner made by a known security company. I will give no names but trust me you have heard this one and maybe bought a book from them or two. It is your typical win32 software, version X.Y, with X being much much greater to 1 (therefore, been revised and improved with every iteration. Running a portscan towards a firewalled VM, it reported filtered ports as open, while nmap was displaying them as closed or filtered. At first I thought that there was something wrong with my firewall configuration. Upon further investigation, when the tool was trying to make a simple connect() scan, reporting timed out ports (-j DENY) as open.

If you are familiar with Bruce Schneier, in his “Secrets and Lies” book, introduces the “snake oil” merchants. Unfortunately, even with a slightly more security educated IT community, frauds like them described in the book can often be encountered in the field. Like our pals from [CENSORED]. Hey guys, is it too much to ask that your connect() portscanner (with a version greater than 1, mind you) at least expects the presence of a firewall someplace? I am sure that quite a lot of pimping goes into your books, I would not know. I have bought one of your books back in 2001 something and it was a terrible waste of money and time. To cut a long story short, you have a bunch of clueless posers with a good PR department charging the hell outta their clients and presenting themselves as authorities within the IT security industry. Unfortunately, the shock rock effect of their material, the overestimation of how “them pesky hackers are out there to get YOU“, soon will wear off and those morons will be exposed for the frauds they are.

Looks like the idea to separate the blogs payed off! I have the other usual place for personal stuff and this one for thins a bit more techie (says on the tin).

So, a year and some change, how does it looks? Well, generally there are the cash-cow posts (that get linked from the craziest of places), a couple of big-hit for a day or so wonders and the rest stay relatively obscure.

So, lixtetrax is not going away anytine soon. At first I was a bit disappointed with the lack of traffic and comments but slowly, persistence paid off.

What is the aim of this blog? Is it to make a book out of it? Is it to pimp my trade? Is it going to be just an RSS aggregator with a couple of lines here and there?

NO!

It will stay about as it is now, a bit longer piece in long irregular intervals. Having a target of say X posts per week, is not applicable in our example. Quality over quantity.

For the past few months, there is a lot of talk about software security metrics, even a book is out One very common metric is the identified bug per (kilo, mega, whatever is applicable to the size of your code base) lines of code. This method is seriously flawed. Why the astute reader may ask? Let’s demonstrate by example. Consider the following (rather contrived) C snippet

/* for the sake of argument let's assume that msg is controlled by the user and is gotten securely */

printf(msg);

/* ... rest of the program ... */

/* then someplace after our evil printf call */

printf(msg);

So Mr. Johnny Security Consultant gets a fat fee to run his favorite static analysis tool. The tool correctly states that there are two format string bugs. If the program is 100 lines of code, then we get a bug/LOC ratio of  0.02. Each of this bug might potentially lead to a complete application compromise.

Mrs Jane Outsourcer then steps in and does a bit of refactoring

/* this is contrived but it does demonstrate the point */

void myprintf(char *msg) {

printf(msg);

}

/* a bit within main() */

myprintf(msg);

/* a bit later in the code */

myprintf(msg);

Johnny charges yet again his fat fee and is happy to write in his report that the application now contains only one critical bug and the ratio has drop to 0.01.

Is the application any safer? No!

Is it easier to fix? In our example, perhaps.

Will a run of the mill static analysis tool fail to state that the application has still two vulnerable points? Yes

Using pure bugs/LOC can lull the development team into a false sense of security, especially if the program is not something trivial like the one above. Software security is a weakest link model, an application containing one critical vulnerability is not safer than one containing ten critical vulnerabilities.

So next time someone tries to sell you some software and spouts some statistics in your face, you will have a counterpoint.

A ton of people are under the impression that format string attacks are only a C/C++ vulnerability (as in, if you code in a different language, you are safe).First, read this article

Second, try this bit of C#

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace FormatStringsC
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                // if I was a user inputted string you would be in trouble
                String fspec = "{1},{10}";
                Console.Write(fspec, "I don’t know but ", " I’ve been told ");
                // return 0;
            }
            //generic catch all
            catch (Exception e)
            {
                Console.WriteLine("Oops! Shutting down app\n");
            }
        }
    }
}

Third, keep watching this space for examples in other languages

(a quick intro: when I read this one, I really had to post about it)

War Story #1:

Navigate here

Check the prices for India. Check the cost of life in India. Check the average market rate for a Greek IT developer. Check the difference between cost of life in India and in Greece. QED

(yeap, I know that the prices quoted there include man in the middle fees, but still it looks pretty grim).

War Story #2:

Talking to a friend, he confided that once his company was needing to buy a software costing appx. 120K for a 5 seat license. The software vendor did a ROI analysis. When they got informed about the cost of developers, they exclaimed “Wow, Greece is cheaper than India!”.

So, dear IT managers. You do not pay well. In fact, you pay a bit better than India. You demand unpaid overtime. Don’t be alarmed when all the guys worth their salt either move out of the Greek job market or get snatched by the major players. Also, don’t be alarmed when you see that given your current skill field, you cannot get any innovative or highly paid projects, been stuck to the good ole fetch the data from backend, format it and present it $2000 t best projects. And for the love of God, don’t be alarmed when your company will die in a few years or become a “mpakaliko”.

(Some meta-info: after all these technical articles, I have decided to take a sidestep into the managerial aspect of things.)

Some managers still go by the good old “if you make your personnel work overtime, all the time, you will finish sooner”. By the same account, some people still believe that the Earth is not round. The overtime will eventually kill your company and here is why I believe so:

• People have lives. Even if you insist on hiring ambitious, single persons, they will be quickly fed up with it. If the employees have a family, you can forget about them.
• If you pay overtime, the costs mount. If you do not (legally) pay overtime, the personnel will soon feel ripped off (as in “Hey, those 4 extra hours a day kinda halve my paycheck”). If you do not pay overtime (the illegal version of it), you might have (and IMHO, you should) legal trouble.
• IT work is not like an assembly line. If you force a person to work say 12 hours a day, it does not mean that he will perform 24 man-hour work in 2 workdays. Chances are that overall fixes that will be required, will take a lot more than the extra day the poor fella “saved” your company.
• Even if the pay is good, persons will quickly fed up. After all, what use are money if you do not get to enjoy them? Even if they stick to it in a “come on, two more months of this and I get the new car”, trust me, they will leave, which leads us to…
• High turnaround. If your people are fed up with you and they have a relatively up to date skillset, prepare to say “Buh-bye” to them. Once a competitor approaches them with reasonable terms, off he goes one person who might know more for your day to day operations than your average middle manager.
• Speaking of managers, constant overtime is a sign of bad management. Even if you choose to ignore the above, if your sales people have no input from the workforce and systematically underestimate the time that is required for a given project, is bad management. If your managers have the slave-driver mentality, it is bad management. “Lowballing” projects is bad management. Hire an extra guy, even a Jr one will take some load off the other persons.
• If you still require overtime, then do the world a favor. Fire all your managers and hire competent ones. If something cannot be done in a normal 40 workweek but needs to be done within a week, you’re out of luck. Perhaps you will get away with it a few times but when you will not, it will hurt.
• While you are at it, why don’t you go ahead and fire some of the HR people? A stick in the mud (or a dick in the team) will hurt your productivity. Hiring only “cheap” persons will not save you money, as it is more likely than not that they will stall and waste time.
• 8 hours of work are usually enough for most day to day operations. Instead of asking people to work more hours, try to implement some in-house productivity measurement and have people work more those 8 hours instead. Try to identify problems in your processes and performance bottlenecks and eliminate them ASAP.
• [edit] If people do not have the time to do their own research (you did bother to hire people that do at least a bit of research in their own time, don’t you?) soon they will stagnate. OJT can only get your people so far, a bit of extra boost is needed. And yeah, if your people are working 50 hour workweeks, you can’t seriously expect them to devote hours in the weekend.

Fortunately, while I have faced most of the above, I do not have to face them now so I consider myself lucky. This is not the case with everyone and while this is no Joel’s, read it