Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security Networking IT

Anatomy of a Hack 98

Posted by Zonk from the illegal-dissection dept.
Tiberius_Fel writes "Informit.com is running an extensive article about the anatomy of a hack against a sample network. It's an excerpt from a book titled Protect Your Windows Network: From Perimeter to Data. Even though it makes references to Windows, the techniques can be applied to other operating systems fairly easily." From the article: "Although attacking networks can be fun and informative--not to mention illegal if you do not have all the proper permissions--the fact remains that the vast majority of us do not need to know how to do so. Frankly, becoming a good penetration tester (pen tester) takes more than a week-long class. It takes commitment, dedication, intuition, and technical savvy, not to mention a blatant disregard for the rules and the right way to do things."
This discussion has been archived. No new comments can be posted.

Anatomy of a Hack More

Anatomy of a Hack

Comments Filter:

  • How to protect your Windows Network (Score:4, Funny)

    by casings ( 257363 ) on Monday July 04, 2005 @05:58PM (#12981807)
    Shut it off.

  • For Some, it just isn't worth it. (Score:5, Insightful)

    by Quentusrex ( 866560 ) on Monday July 04, 2005 @06:03PM (#12981831)
    For all too many business owners and managers out there it just isn't worth it for them to learn to secure computers. They have enough trouble learning and keeping up with the business they have. Normally it isn't until they are breached that they realize that security is a need.

    But that's what America is for. They need something, but don't have the time to do it. So you learn how to provide for their need, and sell it to them.
    • Isn't this the truth...

      While working for a fortune 500 company who will remain anonymous, I "handled" security and disaster recovery for the Unix team, after September 11th, I had a new title, was flying to the sunguard site in phili every 3 months for testing and had close to an unlimited budget to make sure we where safe from hackers, terrorists, could handle a major disaster etc..

      It's very unfortunate that companies don't see the need for security and disaster recovery (which by the way go hand in
    • From the summary "becoming a good penetration tester (pen tester) takes more than a week-long class"

      Using the few thousand business and government networks I've seen over many years, about 99% of them could be cracked very quickly by anyone with half a clue. What's more, in the majority of cases, the technical people involved (either in-house or consultants) pretty much all knew that.

      It may take more than a week to become a good pen tester because that involves a more comprehensive look at finding ALL the vulnerabilities and providing priorities and instructions on fixing them, but it sure doesn't take that long to learn enough to crack most network security.

      The most common network used to be completely un-hardened hosts running multiple insecure applications on unsegmented networks with multiple unmonitored internet connections.

      About the only improvement in the "average" network nowadays is that a firewall or at least NAT device is generally found on the internet facing edges of that insecure network and not much more.

      Sure, I've worked for large ecommerce companies where we had better security than most banks (at least according to our regular third-party security auditors), but the vast majority of networks out there are either small to medium businesses run by managers with no clue and less inclination to spend money on security, or large companies and government agencies where no one knows what's going on enough to close all the gaps.

      Especially government agencies. A friend worked as a security consultant for a cabinet level agency that ran for years with all the firewalls in simple routing mode because one of the high level bureacrats decided it simplified things (you know, no pesky security in the way) and their IDS would be good enough security by itself. If you've seen most government contracted IDS, you know how much of a joke that is.

      It's routine at some of the agencies I did consulting work for to have all the employees in the office using the same username and password. Of course, the password being "password" made it easy for them all to remember and happy to give it out to any outside who they thought might need it.

      Just this last saturday I listened to someone in the park on their mobile phone tell their customer that their company email password was "password" so that the customer could check their email for a document they wanted.

      Now with widespread unsecured wireless network use showing up all over the place..... ahhhh... the lack of security is too much to contemplate! At least you used to have to be able to somewhat guess an IP range if you wanted to target a specific office. Now people can generally just park nearby and watch all the packets go past.

  • hey beavis! (Score:5, Funny)

    by sycotic ( 26352 ) on Monday July 04, 2005 @06:04PM (#12981832) Homepage
    heh heh heh, he said "penetration testing", heh heh heh

  • CYA (Score:2, Interesting)

    by Hungus ( 585181 )
    I have done my fair share of security work and with regards to the blurbs "not to mention a blatant disregard for the rules and the right way to do things" I can say that one rule to never violate is always have a lawyer go over the contract and make certain the customer signs it before you do anything. Further is is a good thing to record all your activities on a black box while testing the system.
  • I like to check out the security of my network using the nessus vulnerability scanner. It's free, it works, and it makes me think happy thoughts. :) ( and it keeps me from doing a lot of work )

  • Raising the bar (Score:5, Informative)

    by lheal ( 86013 ) <{moc.oohay} {ta} {9991laehl}> on Monday July 04, 2005 @06:09PM (#12981855) Journal

    A lot of people will post on this story about how weak Windows is, or how great OpenBSD is, or whatever.

    The keys to secure computing are

    1. Deciding what you value.
    2. Finding your comfort level - how "secure" do you need to feel?
    3. Creating a multi-layer system to make it more diffificult to attack your network than the next one.

    The use of multiple layers is crucial. Never depend on just a firewall, encrypted transmissions, or just on password protection. Never depend on your vendor to secure your data - it's your data, not your vendor's. Read your EULA, and you'll note how little they care.

    • Risk Management would be the first step. Deciding what you value is part of that. But you also have to consider threat probability and whether or not the perceived value of assets is worth protecting. And if they are worth protecting, you have to make the cost of obtaining those assets greater than the intruder's perceived value.
      Also remember that social engineering can be used to penetrate networks.
    • Add to that:

      4. Not having stupid users
    • I'd like to state a fundamental rule of data security: your data is secure against attack from entity A if and only if A's cost in obtaining and using it is greater than its worth to them (and they know it). Note that the cost in obtaining the data (decrypting it, social engineering, whatever) is relatively independent of who A is (depending on how many resources they already own). Its worth and cost to use is different for everyone. (Governments and large organizations might have a lower cost to use illici

      • For each potential attacker, you have to do a cost-benefit analysis.

        For each potential attacker class, and for every attack vector open to that class.

        Some avenues of attack are more expensive or more difficult than others, and that depends on the class the attacker fits. Governments can do things that script kiddeez can't afford, while script kiddeez (for example) don't have to get a court order to try.

        Also, it's not necessary for attackers to know a priori that compromising your systems will b

  • Difference between hacking and cracking... (Score:5, Insightful)

    by Krankheit ( 830769 ) on Monday July 04, 2005 @06:10PM (#12981858)
    Isn't hacking more about the creation of something than the destruction of something? This sounds more like cracking. Anyone can open up a locked car with a coat hanger and hot wire it, but that doesn't make them equal with the skill of the engineers that created the car.
    • Isn't hacking more about the creation of something than the destruction of something?

      Hey, these are /. "editors" we're talking about here. You don't actually expect them to edit anything, do you?
    • it would be nice if Slashdot made the distinction, but the most of the world, hacking~cracking. BTW its become really difficult to open cars doors with coat hangers. You need to leave the VT52 terminal once and a while and get out more!
    • Not to defend the ethics of cracking, but I think a good crack and a good hack are nigh indistinguishable.

      To crack a system, one needs to find a hole the developers missed, without access to source. This can take insight and engineering skills on par with the designers, if missapplied. This is why so many hunt for vunrabilities and then release security notices, leaving it to the kiddies to craft the crack.

      In the virus world, the same applies. The SQL injection worm was an awesomely crafted HTTP packet,

    • Actually cracking is often creating something new too. At least when it is interesting it is. You are taking something, shattering it and then glueing it back together in a way that was never intended on a much lower level. To crack a system you have to understand the code much better than you would to simply design the system. I view this destruction as an art form. This is not to say that someone who runs the latest greatest "0day sploit" against a random system is an artist. But the person who figured ou
    • Cracking: Breaking cryptographic, copyprotection measures or digital restriction management systems.

      At least that is what "cracking" used to mean before ESR thought he could use it as substitute for "breaking into computer systems".
    • Actually, cracking today is a bit more like hotwiring a car using the just the fusebox. It takes about as much knowledge of the electrical subsystem to build the car as it does to do that.
  • Q sex comments
  • If you want to get the bad guy, you have to become him. Think about what you would do to break into a network. It's really part of critical thinking where you poke holes in your own arguments. In this case, you're poking holes in your own work.
  • Protect Your Windows Network: From Perimeter to Data.

    Who in his fucking right mind would put Windows boxes at the edge of his network?! If you must use it, at least use a proper OS for babysitting.

    • <sigh>

      You may not have R'd TFA, but if you had, you'd notice that the techniques they illustrate to gain increasing and ultimately complete access to the network aren't particularly Windows-centric. The attack starts with a SQL injection vulnerability, for example, which is just as possible on a fully patched LAMP box if it's carelessly set up. The tools and specifics might be different on another system, but don't kid yourself that running non-MS machines at the edge of your networks is some kind o

      • Non-MS machines not being perfect, and the parent comment that Windows should never be on the perimeter defense, are two entirely different things.

        Network security in general, like another poster already commented, is about risk management. You'll NEVER be 100% secure - this doesn't mean that OS with the worst security track record in history is good enough. The idea is to get yourself to a comfortable level of paranoia vs functionality.

        After watching Code Red, Blaster, Slammer, Sasser, etc, etc, etc run

        • The thing is, I think you guys are confusing "Windows machine" with "naively configured machine". I'll concede in advance that there is a high correlation. ;-)

          You seem to be extrapolating from the fact that Sasser and friends were a widespread pain in the ass that Windows sucks. The latter may be true, but the former doesn't imply it. I got the feeling (just from reading the reports at the time, nothing fancy) that those worms mostly spread through stupidly configured home-user systems, not professionally

  • Stilling from the blind is not an act to be written in history.

  • Article has a good page on cleaning systems (Score:5, Interesting)

    by billstewart ( 78916 ) on Monday July 04, 2005 @06:31PM (#12981930) Journal
    About page 10 of the article, the author gets to a discussion of what you can do to clean up a compromised system, and uses the analogy of cleaning a swimming pool with undesirable liquids in it - you can't just clean the water, you've got to drain the whole thing and start over. He lists a large number of things you can no longer trust on a compromised system, and explains how each of a number of successively more difficult approaches won't work.
    • You can't just patch the hole the attacker used - he installed a bunch more new holes one he got in.
    • You can't just reinstall from backup, because you don't know if your backup files are compromised too.
    • You can't look in your log files to figure out when you got compromised, because any good cracker knows to wipe his traces out of the log file.
    • You can't just reinstall the operating system over the existing one - too many dangerous files may still be there, including things left in the data and application directories.
    • 3... 4... 5. DON'T PROFIT! 6...
    • You're stuck reinstalling the OS and applications from known-good media onto a clean disk, and hoping you can salvage some of the data, depending on whether your applications make this possible.

    What he doesn't really go into his how to build your production systems in a way that *ASSUMES* you're going to get attacked, maintains a clean environment for developing them in, and gives you the tools to rebuild rapidly from trustable versions. On the other hand, he does show how his example's victim's system was thoroughly broken into, getting from the production system to the development system, because it really *is* hard to do a good job of separating them adequately in a real environment, so even if you think you have a clean-room, you might not.

    • You know, there's something that's really rather simple that secures your backups from being toyed with.

      All of my backups end in .tar.gz.gpg.

      Ah, simplicity of well thought out security. (Concerning backups, anyways.)

      Shameless plug follows
      A bit ago, I accidently nuked my home dir, so I made myself a backup script that scans $HOME for ".nobackup" files, and then archives everything but those directories containing those (I really don't need three copies of the kernel source in my backups, you know?).

      • Re:Article has a good page on cleaning systems (Score:5, Insightful)

        by bombshelter13 ( 786671 ) on Monday July 04, 2005 @06:59PM (#12982054)
        I don't think this isn't really what the author meant about the backups being compromised.

        If you were a hacker, and had just broken into someone's computer/network, would you start playing around and messing things up as soon as you got in?

        Hell no. Only a moron would do that. You would (very quietly) install another backdoor or two, to make sure you can still get in, and then you'd wait five or six months, maybe a year or so, and ~then~ start causing trouble.

        If you start making a mess right away, there's a good chance you'll get detected, and they'll do something about it to lock you out, maybe even going back to those backups and restoring them. That's no good.

        On the other hand, if you wait, then by the time you start causing noticeable damage, they've already made new backups several times. With your exploits already in them. So they can restore the backups, and you can log right back in. The only way to get uncompromized backups will to use very old ones, from before you got in in the first place.

        Patience is a virtue, in hacking just as in everything else.
      • You know, there's something that's really rather simple that secures your backups from being toyed with. All of my backups end in .tar.gz.gpg.

        Look up , yeah right now..... that plane you see up there is carrying the point you missed !

        How do you _know_ that the files weren't compromised before you zipped and encrypted them ?

        Still think that's well thought out security ?

    • You can with Debian. (Score:3, Interesting)

      by khasim ( 1285 )
      All you have to do is to boot with a known good rescue CD (Knoppix is great for this).

      Then you can mount the infected drive and validate the checksums against the packages available on the web.

      This will not tell you anything about your data, but none of your data should be executable anyway, right?

      The same goes for Red Hat or any other distribution that has checksums for both packages and files contained within those packages.

      You can even completely re-install the kernel on a Debian system in this fashi
      • Sure, you can check the files that are part of the standard distribution. That won't find additions to your password files or the similar permission files for half a dozen different programs that track who's authorized to do what, or find extra programs in root's home directory or search path or /bin (such as a modified version of a file that's normally in /usr/bin, with the /usr/bin version left untouched), and it won't find modified versions of files that get modified during the installation process, and

        • Sure, you can check the files that are part of the standard distribution.

          Yep. And those are the ones that would be replaced by a rootkit.

          That won't find additions to your password files or the similar permission files for half a dozen different programs that track who's authorized to do what...

          It doesn't have to. Those should be easy to check manually.

          You DO know what accounts are necessary on your systems, right?

          ...or find extra programs in root's home directory...

          Why would there be any apps i

          • Sure it will. Every file there should be part of a package. All you have to do is have the system check which package each file belongs to.

            Any files that don't belong to a package, you delete.

            [...]

            And those mod's are instantly identifiable because they won't have the same checksum as the originals.

            And where are the package content checksumss kept? That's right, on your compromised system. I'm not even sure debian mandates MD5 checkums on all it's pacakge files yet.

            Also there are more than

            • And where are the package content checksumss kept? That's right, on your compromised system.

              No. They're on the web site of the distribution that you used.

              You compare the checksum of the package on your system with the checksum listed on the website.

              You DO know what a checksum is, right?

              I'm not even sure debian mandates MD5 checkums on all it's pacakge files yet.

              Mandates or not, they are there.

              Also there are more than a few files that don't belong to a package (like /etc/fstab -- and very much d

              • No. They're on the web site of the distribution that you used.

                Let's stick to debian instead of pretending that all distributiuons are the same (although, AFAIK, no distributions allows what you claim they all do).

                So, with debian, you can boot into knoppix. There is no general tool to say "I'm booted into knoppix, please verify /mnt/foo which is a debian installation with wesite bar using gpg key XYZ".

                So, what can you do ... you can have a trusted version of debsig-verify, and a trusted version o

                • So, with debian, you can boot into knoppix. There is no general tool to say "I'm booted into knoppix, please verify /mnt/foo which is a debian installation with wesite bar using gpg key XYZ".

                  Unlike certain Windows-centric individuals, I am not limited by the presence or absence of a tool specifically written to perform a function. I can script my own.

                  That is because I rock.

                  Attend, Grasshopper, and I will provide you illumination upon your path to True SysAdmin-hood.

                  Argue for your limitations, and the

              • Dude, there's no need to be insulting or condescending.

                Actual production systems are typically much more complex than a raw Debian installation. It takes a *lot* of discipline to run a good configuration management environment at all, something that far too many companies with web sites don't do well, much less to run it in a way that gives you a trusted base for every application on your system.

                You're probably not just going to have raw Debian and some data files. There'll be databases (typically O

                • Dude, there's no need to be insulting or condescending.

                  Sure there is. When I say 2+2=4 and someone else is saying it's 6, then condescending is spot on.

                  Actual production systems are typically much more complex than a raw Debian installation.

                  No, they are not.

                  They have the same BASIC system and then they have whatever specifics needed for that app.

                  If I can validate everything except that app, then it is just a matter of re-installing that app. And that is the issue.

                  It takes a *lot* of discipline t

  • ..into other people's networks.

    I wouldn't have figured that out without them. From what I understand, laws describe what is legal, and individuals decide what is moral. Then again, maybe psycopaths need to be told...

  • Old, old news... (Score:3, Informative)

    by LO0G ( 606364 ) on Monday July 04, 2005 @06:43PM (#12981962)
    This was posted in Microsoft Technet magazine way back in January.

    http://www.microsoft.com/technet/technetmag/issues /2005/01/AnatomyofaHack/default.aspx [microsoft.com]
  • ...Jon Katz, is that you?

  • No new news here (Score:5, Informative)

    by michaelaiello ( 841620 ) on Monday July 04, 2005 @06:51PM (#12982028) Homepage
    Quick overview of the meat of the article

    1. Do a WHOIS lookup of the IP range the network is on.
    2. Search newsgroups for previous network internals that the SA has posted somewhere.
    3. Do a port scan and fingerprint.
    4. If there is a vulnerable service running, use a common exploit.
    5. A quick description of how sql injection attack works on a web-application login.
    6. Use xp_cmdshell on MS-SQL to download remote shell code via tftp.
    7. Once somone has the sql server under control, use the poorly configured internal network to become domain admin.

    Somone needs to put together a description on how a "social engineering" penetration test should be done objectivly. If there is one out there please let me know. =P

    • Re:No new news here (Score:1, Insightful)

      by Anonymous Coward
      1. Call helpdesk, impersonate corporate boss, tell them you forgot your password and connection information, get it reset.
      2. Connect with VPN/dialup access.
      3. Exploit local root hole

      Simple!

    • Re:No new news here (Score:3, Informative)

      by burns210 ( 572621 )
      "Stealing the Network: How To Own The Box" is a good book about general hacking/cracking/forensics/geekery. 10 chapters, 10 different stories talking about how a person (playing on offense or defense) goes about a computer or network hack. One of the stories in the middle is a good one on a former employee that does some real-life social engineering and whatnot to get to his end goal.

      Just finished the book, well worth the fairly short read. All non-true stories but are based in a realistic setting. Gets mi

    • Somone needs to put together a description on how a "social engineering" penetration test should be done objectivly. If there is one out there please let me know. =P

      Kevin Mitnick [mitnicksecurity.com] has written some interesting books that cover social engineering attacks extensively. More info here [amazon.com] and here [amazon.com]. They are a must read for anyone working in security.

  • Sad to see (Score:5, Insightful)

    by Knights who say 'INT ( 708612 ) on Monday July 04, 2005 @07:35PM (#12982180) Journal
    Slashdot surrendering to the mainstream, negative meaning of "hack".

    I though it was supposed to be a hacker forum :~

  • "Since any competent pen tester (or system administrator) with a need for these types of tools can write them, there is no reason for us to distribute them here."

    Ah so, it is true then, Jedis do build their own light sabers. [howstuffworks.com]

    Disclaimer: I've seen this link on /. before but I'm too lame to look for it.

  • strange definitions of warez, xss, etc. (Score:5, Interesting)

    by lonedroid ( 888148 ) on Monday July 04, 2005 @08:27PM (#12982351)
    I just read the whole FA (yup, I'm new here as my user ID can tell ;) and I'm not sure what to think about it.

    The metodology used is not extraordinary: setting up a purposedly insecure network then hacking (sic) it themselves using the known holes is kind of cheesy. It helps to show how it works, but I prefer the honeynet approach: setting up boxes with known (or not) security holes, then analysing how a real intruder creates havoc.

    Then there's some strange (re)definition of words.

    For example, straight from TFA:

    There are several techniques for getting our tools (often called "warez") onto the database server.

    Then, as a side note:

    Warez is a hacker/attacker colloquialism. It comes from the term "software," but is now used varyingly to mean either "attack tools" or "bootlegged software." In this chapter, we use it in the former context.

    I think it's the first time I see the term "warez" used to describe "attack tools" (sic). I used to live in ancient times where "warez" weren't yet called "warez", then "warez" became "warez". Now what? "warez" aren't "warez" anymore? As it changed? (then a great many online dictionaries definition should be updated btw.).

    The definition of XSS is also interesting:

    In Figure 2-5, we see that not only do we get logged on, but the application also displayed the fake username we sent it on the home page. This latter artifact is actually a separate type of vulnerability known as a cross-site scripting (XSS) vulnerability, where the user input is echoed directly to the screen without sanitizing it first. We will not use it in the following attack, but it is interesting to note that it is there.

    This definition of XSS is wrong: it's not because we see what was typed that the input weren't sanitized (sic). And it's certainly not because we see what was entered that this could lead to code being executed on another user's computer. Moreover I find the last sentence of this paragraph misleading: We will not use it in the following attack, but it is interesting to note that is is there. Of course they're not using it: they're "hacking" the server(s), not joe random visitor's box.

    Then there are quite a lot half-truth, that can also be misleading:

    A fully compromised system cannot be trusted to tell you the truth. Even virus scanners must at some level rely on the system to not lie to them. If they ask whether a particular file is present, the attacker may simply have a tool in place that lies about it.

    If by "fully compromised" it means that the BIOS has been flashed and now lies about the files it reports, I then more or less agree. However such a tool is improbable (not enough room in the BIOS memory and not all BIOS can be flashed at will). So by "fully compromised" that's probably not what they meant. How would then an attacker lie when booting from a CD and running the scan from the CD? Or when hooking the compromised HD as a second HD on a clean system? It's not like everybody run their virus/trojans/rootkits scanners from the suspicious host.

    Then at the end of TFLA (the 'L' stands for "Long") they explain, in a very windowish style, how to recover from a "hack": reinstall everything, because there's nothing you can trust (besides Windows's installation medium?)

    So is it about the anatomy of a "hack" or how to recover from a "hack"? Both? Then why not a single word about how to configure an IDS?

    Speaking of IDS, from TFA: Once we took over an entire network through an intrusion detection system.

    WTF? I'm not sure if by their definition Snort qualifies as an IDS, but I run Snort in a passive way: no IP, not a single packet emitting from the box, etc. If an IDS becomes an entry point for intruders, then it's not an IDS but an IAS: Intrusion Automation System ;)

    The article could be summarized like this (like others already pointed out i
    • as i've taught technical material (novell, microsoft, cisco) i've gotten a a deeper understanding of how things work. from doing labs, building demos for students, having students provide a different way of looking at things, this knowledge builds. a degree in computer science helps also.

      understanding something completely is the best way to break it, compromise it, protect it. you must also have some creativity and/or intuition.

      just some thoughts.

      eric
    • Your commentary is interesting, but there's one bit that's worthy of further consideration.

      TFA:
      A fully compromised system cannot be trusted to tell you the truth. Even virus scanners must at some level rely on the system to not lie to them. If they ask whether a particular file is present, the attacker may simply have a tool in place that lies about it.

      Your critique:
      If by "fully compromised" it means that the BIOS has been flashed and now lies about the files it reports, I then more or less agree. Ho

    • The article is not realistic, the scenarios described are way too simplified, and it's not something a true security guru would waste 5 minutes even contemplating as a "real life" example of how stuff works.

      Remember, though, that by even knowing that the topic of security exists, you're ahead of 80% of the crowd. Firewall? 90%. What are ports and sockets? 95%. SQL Injection? Cross-site scripting? Packet rebuilding with Scapy? Memory manipulation? Bus mastering? Whoa.

      If anything, I have noticed m
    • Speaking of IDS, from TFA: Once we took over an entire network through an intrusion detection system.

      WTF? I'm not sure if by their definition Snort qualifies as an IDS, but I run Snort in a passive way: no IP, not a single packet emitting from the box, etc. If an IDS becomes an entry point for intruders, then it's not an IDS but an IAS: Intrusion Automation System ;)

      Interestingly enough, there have been vulnerabilities in Snort that actually did allow one to compromise it. Seems impossible given that Sn
  • Yeah guys, I RTFA, what do you think of this:

    Naturally, many other ports can be open, particularly if the target system is not a Windows system. However, these are the ones we look for in this chapter.

    Wasn't windoze the OS with stupid, wide-range, unexplainably open ports? Any volunteers to slap the author senseless?

  • Pathetic (Score:2, Insightful)

    by HaydnH ( 877214 )
    The article relies on somebody setting up a web server that allows SQL injection and runs using the admin user... who in their right mind would set up a system like this??

    They may aswell have written an article on how to crack a system if somebody sends you the SA password... pathetic!
  • It seems that much of the article relies on "SQL-injection" which is, to my experience, a disappearing trend. A few years ago, SQL injections was very widespread. I would rather say that the article demonstrates the eggshell-principle of how 1 bad script can make it crack.
  • All your Base are...

Slashdot Top Deals

One half large intestine = 1 Semicolon

Close