Slashdot Mirror

I bet you didn't click on the ID link describing how to fix it did you?

I did and, first of all, your link describes a proposed standard 5 years ago. I do not see that it has been accepted as a standard to IETF. Second in Eastlake's presentation he notes: "Provides weak authentication of queries and responses. Can be viewed as a weak version of TSIG. No protection against “on-path” attackers, that is, no protection against anyone who can see the plain text queries and responses"

I read that as it probably would work if adopted but it is only slightly more secure than DNS but not my much. Port randomization probably does more.

But yea major re-architecture..blah blah blah..

Well if you need a more thorough explanation you can read this much more detailed and illustrative one.: "As has been alluded to several times, it's the small space — just 16 bits — of the Query ID that makes this attack possible. Though certainly one might wish to increase that ID to something larger (perhaps 32 bits), it's simply not possible do that in the short term because it would break DNS on the internet: the fields are what they are, and they can't be changed casually.

Don't care about popularity contests or who said what.

So you don't care how the hacker who found the problem proposes to fix it. By the way, Kaminsky has never liked DNSSec but he says it's the best solution for now. He actually would prefer DNSCurve but at the time was not ready. It might eventually replace DNSSec. Who do you care about? What about IANA: "DNSSEC is the current answer to this problem. This attack provides clear incentive to deploy a solution like DNSSEC, because without security the DNS will continue to be vulnerable to cache poisoning attacks."

The transport picture and the risk it represents to the larger network is unacceptable regardless of how "secure" DNSSEC is.

In response to this attack all the root servers implemented the solution Kaminksy suggested. People who know far more about Internet security than you and me did this. Either they implemented a popular but less secure solution. Or they don't know as much as you. Or they know what they are doing.

I'll mention this because it's what I'm doing and I haven't seen anyone else suggest it yet.

What I personally do for remote help is to use SSH with X forwarding directly, without using anything like VNC. I always set up SSH servers on non-default ports and also install fail2ban "just in case" a remote attacker actually finds the SSH servers and tries to brute-force them -- of which no attempt has ever been made so far. [And I can say that because I also set up 'logcheck', tweak logcheck to filter out noise so that it only reports actual issues, and then I actually read the resulting emails it sends.] In addition I also set up a "pre-shared" ssh key with no password and copy the key to the remote router so that the password to log into the router is not passed over the 'net, and also disable root logins. (Okay -- call me paranoid. :-P)

One place I've found with simple instructions for setting up pre-shared ssh keys:
    http://rcsg-gsir.imsb-dsgi.nrc-cnrc.gc.ca/documents/internet/node31.html

And although I know I could do the same thing to log into the user's box through the router via pre-shared keys and ssh-agent forwarding:
      http://unixwiz.net/techtips/ssh-agent-forwarding.html
instead I don't actually bother to do so, and just use a normal ssh password login to the user's box.

Login steps to get to user's box:
      - log in via SSH to the remote router, with X fowarding
          ssh -l (normal_user_username) -X -p (port) (remote_router) # ex: ssh -l mooha -X -p 1022 router.mydomain.com
      - log in via SSH (as a normal user) to the user's box, with X forwarding
      - su to root on user's box
      - su to that user
      - tell the user to quit the program they're having a problem with
      - run the specific program they're having a problem with myself and have a look

Upsides:
    - secure
    - gives user some privacy (can't see their screen)
    - never "take over" the user's mouse
Downsides:
    - can't see the user's screen
    - need to know the actual program name to run, rather than using the menus in the window manager
    - difficult to have a look at "non-application" programs such as desktop widgets (which is usually not a problem)

http://unixwiz.net/techtips/be-consultant.html

Run windows as a standard user and it requires a password too. (It only prompts for yes/no if you are already logged in as an administrator.) See screenshots here:

http://unixwiz.net/techtips/win7-limited-user.html [unixwiz.net]

Note it is also possible to configure windows to always require the password entry. But I do not think this makes it more secure.

Interesting, this should make privilege escalation exploits much more difficult to pull off than the standard setup where the user is actually an administrator who just gets warnings before performing admin tasks.

Requiring programs to be exec modded before running

I've downloaded tons of stuff for linux, and I rarely have to make an explicit exec mod before running it.

Not determining file type by extension

And that adds to security how?

Requiring your password to escalate privileges rather than a yes/no dialog

Run windows as a standard user and it requires a password too. (It only prompts for yes/no if you are already logged in as an administrator.) See screenshots here:

http://unixwiz.net/techtips/win7-limited-user.html

Note it is also possible to configure windows to always require the password entry. But I do not think this makes it more secure.

Installing an overwhelming majority of your software through a repository rather than random websites

This is only true while linux is a 2% marketshare identity. In a world where linux a major or dominant player, the worlds annual production of proprietary software, shareware, trialware, demoware, shovelware, will all be pumped out for linux, and most of it will be unlikely to make it into repos.

Repos work for OSS. The overwhelming majority of software for linux is OSS right now. But if linux were dominant it would attract commercial software the same way it would attrack malware attention.

Tons of software end users will want will NOT be available via repos. From quickbooks to photoshop to itunes ... end users will want the shiny, and will click to get it.

Sure thing.
# openssl speed sha1
Doing sha1 for 3s on 16 size blocks: 4925162 sha1's in 3.00s
Doing sha1 for 3s on 64 size blocks: 3460802 sha1's in 2.99s
Doing sha1 for 3s on 256 size blocks: 1972423 sha1's in 3.00s
Doing sha1 for 3s on 1024 size blocks: 722903 sha1's in 3.00s
Doing sha1 for 3s on 8192 size blocks: 104552 sha1's in 2.99s
OpenSSL 0.9.8g 19 Oct 2007
built on: Mon Jun 7 19:28:26 UTC 2010
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DMD5_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
sha1 26267.53k 74077.37k 168313.43k 246750.89k 286451.50k

26 MB/sec on small blocks in sha1sum. String compares I don't have a command handy to time, but I know that they will be in the hundreds of megabytes / sec range. Now this does not cover security concerns at all. I think that, since we are talking about a security system, we should talk about them.

Passwords are salted and hashed because storing a plaintext password is a grave security mistake. Anyone working with the database could grab a single table and know what everyone's passwords were. That is exceptionally bad, even if they only used the password in that one place. Someone could use that knowledge to legitimately log in as a user. Extrapolate from there. Worse still, many people use the same passwords in a few places, perhaps with a few variants.

Without just telling you to Read More Schneier (which would be rude) , I'd like to make you aware that hashing is one of the most amazingly cheap non-arbitrary things one can do on a modern processor, and that all other operations in a useful system take vastly longer (database lookups, disk access, network access, public key cryptography to establish an SSL session which you better hope your password travels over).

Cryptographic hashes are one of the best building blocks for secure systems, and you may find their application interesting. Give it a look-see. I do recommend Schneier, but some free links follow:
http://unixwiz.net/techtips/iguide-crypto-hashes.html (decent primer, little long winded)
http://mathworld.wolfram.com/BirthdayAttack.html (simple explanation of the birthday attack)
http://en.wikipedia.org/wiki/Salt_(cryptography) (I know a wiki link, but this ties in VERY closely with password security)
http://en.wikipedia.org/wiki/Message_authentication_code (another, I know. But it has a lot of titillating links in it that should be followed)

Also for further reading: Package transforms and Schneier's book Applied Cryptography.

Security is important, and I'd think that if you have such strong opinions you could put them to good use. Happy reading!

PS: None of the links I provided talk about timing attacks. That is very important, but once you've got your head around cryptographic hashes you will know that a well salted and properly implemented hash library will not be vulnerable to many timing attacks. Figured I'd warn you.

Unable or unwilling admins is more like it.

A side effect of buying into the so-simple a monkey could run it sales pitch from Microsoft: You end up with monkeys that can only stroke the big boss telling him or her to sit tight till the next free t-shirt^H^H^H^H^H^H^H service pack. As these monkeys are able to bullshit their way into training positions, they will do what any other weak or insecure monkey will do: bogart their already limited knowledge. Thus with each iteration you get progressively more ignorant monkeys, that have to rely and specialize more and more in social engineering and keeping the managers away from real it staff to keep their jobs. That same level of skill and knowledge permeate that one vendor's products and services. When the products or services get enough bad press, they just rename them. Enough of that though.

There are some good interviews about the DNS flaw, like the one at Black Hat. For the details of the 2008 flaw, not the x.509 cert flaw, Steve Friedl has An Illustrated Guide to the Kaminsky DNS Vulnerability. If you played with DNS during 2006 or 2007 you probably at least spotted symptoms of the flaw as it seemed to be in growing use.

Frustratingly, the solution has been there in front of us for many years and most systems have been more than capable of deploying DNSSEC, either as part of IPv4 or IPv6, for many years. Except for one vendor that can't. Take a guess which one. Take a guess how much it has cost us to let them hold back the net.

Whooooooosh.

I've been a Unix systems engineer for years. I once updated the OS on an AT&T 3B2/400 running SVR3.2. (No, that's not SVR4, that's SVR3.2!)

Whooooooosh.

I've been a Unix systems engineer for years. I once updated the OS on an AT&T 3B2/400 running SVR3.2. (No, that's not SVR4, that's SVR3.2!)

So you mean it's like chroot?

Lots of practical advice in this article

I know this is likely to get lost in all the comments, but bookmark this: http://www.unixwiz.net/techtips/be-consultant.html

No, that's not it. If the perp controls the domain.com domain, they don't need to play any CNAME tricks, they can spoof www.domain.com directly.

In simple terms, the Kaminsky exploit fools a caching nameserver's notion of what addresses are associated with example.com's nameservers, by eliciting a bunch of doomed-to-failure queries of names underneath example.com (e.g. a.example.com, aa.example.com, xyz.example.com) along with fake, source-address-spoofed answers to those queries. Eventually the query ID # matches, the caching nameserver accepts the response, including the NS records and associated A/AAAA records (collectively called "glue") in the response identifying the example.com nameservers, and subsequent queries of all example.com names -- including the omnipresent www.example.com -- are redirected to the bad guy's nameservers, until the TTL on the glue records expire.

The reason for not just querying the same name under example.com is because negative caching would substantially drive up the number of packets required for a successful attack. That's the innovation that Kaminsky brought to bear on the scenario; using a series of doomed-to-failure subdomain queries instead of the same name over and over. That makes the attack much faster, and thus far more likely to be successful in the limited-time windows that hackers have available to them for source-address spoofing.

The long-term fix is something like DNSSEC to crypto-authenticate the packets. In the meantime, randomizing the source ports of queries adds enough entropy, in addition to randomizing the query ID #, that the packet volume of a would-be attacker is (hopefully) detected and their attempt blocked before it succeeds

You might want to check out http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html, which appears to be a fairly good "beginner's guide to iterative DNS resolution and its vulnerability to the Kaminsky attack" document. Lots of pretty diagrams...

I didn't find the linked article very informative, but with the help of Google found this very nice explanation of the problem.

You aren't misinterpreting -- from Dan Kaminsky's blog:

After evaluating several options, one approach was clear -- and, I must admit, somewhat embarassing to Paul [Vixie, primary architect of BIND].

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that's no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got âoeluckyâ here â" he ended up defending himself against an attack he almost certainly never encountered.

Note the weasel words here, that DJB got lucky and ended up defending against an attack he never encountered. Even while crediting him for being right, Kaminsky won't admit that Bernstein anticipated these attacks several years ago, documented them clearly, and designed djbdns to deal with them as best the broken protocol allows.

In all of Kaminsky's self-congratulatory hype about finding the bug and coordinating the patch effort, he never once suggests the obvious -- that people at least consider using the most secure DNS software available by switching to djbdns.

Steve Friedl is better at crediting Bernstein -- way down near the bottom of the excellent An Illustrated Guide to the Kaminsky DNS Vulnerability Friedl says this:

DJB Was Right

One nameserver is notable for having gotten both the query-id and source-port randomness right from the start: DJBDNS by the legendary Daniel J. Bernstein.

Though long a lightning rod for controversy, he's clearly walked the walk on security: there's never been a security vulnerability in DJBDNS.

The notion that Bernstein drives people crazy and has been a lightning rod for controversy stems from his appropriately harsh and blunt assessments of poorly designed software, particularly Sendmail and BIND. But Bernstein's critics are essentially admitting that for them, correctness is less important than not having one's feelings hurt.

Actually they scraped the plan to give away 2b1 computers in exchange for giving away 3b2s ;)

I did a quick google and found this as a description for sql injection. I would think that, at the very least, if you handle all your strings (and numbers) properly then this problem goes away. Say you have a field "LastName". If you just concatenate the value entered into the field into your SQL then you're asking for all kinds of problems (Any O'briens etc. out there?).

For all my fields I use a simple function to ensure that the data being put into the query is safe for the query (Replace(foobar, "'", "''") - for SQL Server). For numeric values, well, you just make sure that they are numerical as part of the validation (or you limit the characters they can type into a numeric field).

Please excuse my late reply, I took a week off /..

I could ramble a few things, but I think you best bet to get started to check out this:
http://www.unixwiz.net/techtips/be-consultant.html

It has some really good and valid points to get your started.

You ask how you find customers?

Well the simple answer to this is you HAVE to be social.

I recommend showing up to networking nights/seminars, and I'm not talking about playing Doom.

Building a business is similar to building a social network of friends. The more relationships and contacts you attain the better chance you have of being billable.

Perform presentations. Show that you are an expert in your field.

Doing your first few jobs with very cheap rates to get your foot in the door can also win customers.

Treat your customers with absolute respect, and BE ON TIME. If you say you are going to fix something or do something, then DO IT. You'd be suprised how much confidence you can garner just by being reliable.

Hope this helps, and good luck.

I will never again work for "the man" again.

We found this out the hard way last week. Four years ago I published my wife's cookery book, which included about 80 commissioned paintings. All the text was stored in subversion but the image data took up about 40GB in its various forms. It was all backed up and we had multiple copies on different disks, but having just sold the rights to the book I discovered that I had reused the 250GB disk that held the images, putting it into a Windows XP system my wife used for her printing business. We had changed our tape drives a couple of years ago and didn't have any of the old tapes -- we just didn't notice when we lost the files. Fortunately we were lucky: only 10% of the disk had been reused, so I made a low-level copy of the disk, used scandrive to find undamaged superblocks and then e2fsck recovered the about half the contents of the disk. As we had the files in multiple formats we actually ended up only losing three of the images, which was miraculous.

I used this resource when I did what you are considering doing: "So You Want to Become a Consultant?"

Most cracks are extremely simple, crackers are simply looking for a conditional and unconditional jump instruction, that's it! Then it's all about stepping into the code step by step and having break points.

if ( !condition ) { error_message(); }

http://www.unixwiz.net/techtips/x86-jumps.html

So, one easy way is as simple as by passing the checks by renaming JZ into JNZ, JE into JNE, JO into JNO, or similar when the serial number is checked.

This way any invalid serial is now actually valid...
You might have to add a NOP to make the instruction the same length.

Other serials are simply generated by having the serial key code compare being blindly copied into another program to create a keygen.

if ( input_key != calculated_key ) { error(); }

Another way is to run it in debug mode and then see the content of the register having calculated_key.

The only product scheme which are more difficult to crack is those which they *seems* to be cracked, but fail unexpectively after a period of time which is very far apart the actual "test".
Days or weeks is a good delay.

And for products which prevent "debug mode" utilities, well, there exist other products to go around this issue by simply masquerading the WinIce/SoftIce application, so it doesn't get detected and prevented from running in "debug mode".

That's all I can tell.

Some of course are encrypted, but even then the code must be "decrypted" before being run so...
it's still possible to analyze it, just a bit harder.

In the end, the best way for a product is to be good, useful, have nice manuals and have a proper support at the right price, then the majority of people will buy it, especially if it's bundled with good hardware, since it wouldn't make sense otherwise.

I know when the same technique is used to compromise web sites with SQL in the back end it's called SQL injection. I guess this would be XML Injection? Or perhaps PHP Injection and XML is only the wrapper. XML Injection sounds cooler.

New wireless technology called XMax?

Unixwiz.net Tech Tip: An Illustrated Guide to Cryptographic Hashes

I would say first and foremost that there are geographic considerations, though those can be somewhat mitigated by available technology. You might be in NYC, but using some form of shared desktop...netmeeting, even...you could be "fixing" a computer in Kansas...that person will not want to pay NYC rates.

As a massive overgeneralization, I would charge around $50 an hour for absolute strangers, $35 an hour for acquaintances, $25 an hour for friends, and keep it going for free to closest friends, friends who have already or may someday repay the favor with services/goods of their own profession, and family.

There was a good article posted recently that provided excellent guidance on a more advanced form of this same work. Though it was written beyond the level of helping clean up some windows rot here and there, I think some of the main ideas still apply. Click here for the article.

I'm much more on the technical side of consulting, and the only "marketing" I do is publishing original, technical content. Mainly I write C code all day, though I'm sure that this slashdot post is seen as "marketing"...

Steve

Yes, aside from the AMD64 NX bit, they've added some overflow detection. According to this article they do it by placing a cookie after the end of buffers and then checking this cookie for changes. They call it 'software-enforced DEP(Data Execution Prevention)' and more information can be found at http://support.microsoft.com/kb/875352 and codeguru has the best description I've found. If you have XP with SP2 you can go to Control Panel, System, Advanced, Performance Settings button and choose the Data Execution Prevention tab to play with settings.

In particular, the fact that it has "CodeRedII" inside means that it couldn't possibly be the original worm -- the name wasn't attached until after it was released.

If this beast is truely wicked, it will scan assorted websites such as Slashdot, Wired, etc, and as soon as it will see talk about itself it will enter its active phase...