/\ /^/_ _ __ __ _|^|_ __ ___ / \/ / _` '_ \/ _` | | '_ ` _ \ / /\ / (_| |_) (_| | | | | | | | / / \/ \__, .__/\__,_|_|_| |_| |_| |_| . . . ..n7: 2000.10.06 --------------------------------------------------------------------------- all content copyright © 2000 by the individual authors. all rights reserved --------------------------------------------------------------------------- # prtvtoc . . . ..................................................................... 0x00 Editor's Comments 0x01 URLs 0x02 CISSP Certification (Part 2) 0x03 Security Holes in LPPlus 0x04 Using IPSEC and Samba to integrate Windows Networks 0x05 Resource Protection Mechanisms 0x06 Music Reviews 0x07 Credits ..................................................................... . . . ___________________________________ --------------------------- - kynik [=] 0x00: Editor's Comments Xploita has the spotlight in this issue, with an even longer article than Ajax's last IPSEC epic. Due to lack of volunteers, and just for this issue, I'm handing over the music review section to c_routine so he can talk all he wants to about the new Rancid album. In other news, gh0st.net looks to be arising from the ashes like the phoenix of myth. Things are still pretty much under wraps, but when it all comes to light, it'll be very damn cool. Also look forward to a number of articles coming from gh0st.net's founder phatal. If any of you are interested in providing commentary, music reviews, full articles, or just have questions you'd like answered, feel free to email us at napalm@firest0rm.org and we'll include it in the next issue! ____________________________ -------------- - kynik, ajax [=] 0x01: URLs Persistent uniform resource locators http://www.purl.org/ Various security extensions to FreeBSD http://www.trustedbsd.org/ Another security extension to FreeBSD http://www.securebsd.org/ Yet another security extension to FreeBSD http://www.eth-security.net/files/rna.tar.gz Set up your home network http://arstechnica.com/guide/networking/installation-1.html Artificial Neural Networks for Misuse Detection http://secinf.net/info/ids/nn-idse/ Lots of links to securityware http://www.opensec.net/ ______________________________________________ -------------------------------------- - kynik [=] 0x02: CISSP Certification (Part 2) In response to my previous article about CISSP ceritification, I got a few emails from subscribers: Ariel Silverstone wrote: Yes, IT IS WORTH it. It Doubled my salary to over $100K Ariel Silverstone, CISSP [And later wrote:] I hire a lot of people in my job, I especially look for CISSPs all over. That is another benefit. Ariel Silverstone, CISSP ----------------------------------------------- Fabian Oliva wrote: Sup Kynik, I just recently passed the CISSP, after two weeks of studying. It seems like a really tough test, but its not. Now on the subject if its really worth it? Speaking in terms of security competency, example: to secure a Solaris server...not a chance. Some people have referred to the CISSP exam as the "vocabulary test" But when you talk about salary, then the picture gets pretty. One guy who took the test and passed got a 40% salary increase - not bad, huh? I will see if my company will give me a increase if not... bye bye... Anyways...let me know if you want some help preparing for the exam.. I can mail you my study notes, which books to study and which areas to concentrate on. BTW- Great Mag.. I would definately like to write a article, just was so busy studying. But I'm done studying *political stuff* for the year. On to the funstuff - C, shell scripting and breaking *nix boxes. In the end certifications dont mean much, just that your good at memorizing books, but they help your pay... Peace, Fabian J. Oliva CISSP CCSE CCNA MCSE-yuk N+ [And later wrote:] Its not 3 years of Security set in stone, its more of 3 years of security related work. Example: I have 1 yr experience as a Security Consultant, but 2 years as a Network Administrator/Support, and since being a Network Admin involves some of the tasks of "security", they were cool with that. The Handbook [of Information Security Management] is an OK book; it doesn't cover all the areas, but it's better than nothing. Read the older handbook online 3rd edition, i belive its at www.itknowledge.com They offer a one day review session that lasts for like 10hrs, that was pretty intense, that helped me prepare for the exam big time. Also read up on the following: * X.509 Digital Certificates * Know SSL, IDEA, PGP, The different encryption algorithms * Also know physical security, such as CCTV cameras If are like me (more technical than political) then the "technical" crap won't be a problem at all, it was mostly questions based on the OSI model. That was the only real knowledge you needed, I felt that you could think the other questions through... but again, that was my observation... www.securityfocus.com has a email list group ___________________________________________________ ------------------------------------------- - echo8 [=] 0x03: Multiple Security Holes in LPPlus Summary ------- LPPlus is Plus Technologies' print management system for unix. It contains several serious security holes, some of which undermine the integrity of the printing subsystem, some of which threaten the security of the system on which the product is installed. Details ------- Hole #1: Of the 74 binaries that the installer put on my Solaris system, 26 were installed suid to root and world-executable. On my linux box, it was 26 out of 64. Several of these should not be suid-root, or should be group-executable only, and carefully restricted. For example, the following binaries are installed mode 4755 by the installer: $LPHOME/bin/dccsched $LPHOME/bin/dcclpdser $LPHOME/bin/dccbkst $LPHOME/bin/dccshut $LPHOME/bin/dcclpdshut $LPHOME/bin/dccbkstshut The first three start the scheduler, LPD server and network status daemons, respectively. The next three stop the aforementioned services. In the default configuration, all six can be executed by any unprivileged user, effectively giving any user on the system the ability to start and stop printing services. No checking of userid, group or anything else is done prior to execution. Hole #2: $LPHOME/system/lpdprocess is created mode 777. This file contains the process ID of the dcclpdser process. The combination of this file's permissions and the fact that dcclpdshut is executable by any user allows an unprivileged user to send signal 2 (SIGINT) to any process on the system. All that's required is for an unprivileged user to replace the PID in $LPHOME/system/lpdprocess with the PID of their target process and then run $LPHOME/bin/dcclpdshut. Hole #3: $LPHOME/bin/dccscan is suid-root and can be executed by any user. It may allow an unprivileged user to print files to which he does not have read access. The ramifications are fairly obvious: although an unprivileged user cannot read /etc/shadow (for example), using this utility, he may be able to print it out. In my testing, this worked even when sending to printers to which my user was not given any access in the LPPlus security configuration (in fact, my test user had no access to ANY printers, or ANY LPPlus services). Some other potential holes: * if the archive module is installed, $LPHOME/bin/dccasweep can be executed by any user. This may undermine the integrity of the archiving facility. * if the web interface is installed, it utilizes a very old beta version of apache, and the installation requires that the server (and all of its children, which run as nobody out-of-the-box) run as root. * on the linux system, $LPHOME was created mode 777. Root's umask was set to 022. This didn't seem to be the case on the Solaris system, although the reason for this may be the different version of LPPLUS rather than the different unixes (see below for version info). Demonstrations -------------- Hole #1: $ id uid=600(test) gid=300(users) $ ps -ef|grep dcc test 26357 26351 0 18:18:06 pts/0 0:00 grep dcc root 26262 1 0 17:41:50 ? 0:01 /opt/lpplus/bin/dccsched root 26272 1 0 17:42:03 ? 0:00 /opt/lpplus/bin/dcclpdser root 26276 1 0 17:42:14 ? 0:00 /opt/lpplus/bin/dccbkst $ dccbkstshut $ dcclpdshut LPD048E Signal sent to dcclpdser to shut down. $ dccshut LPP054I LP Plus scheduler ordered to shutdown. $ ps -ef|grep dcc test 26253 26239 0 17:39:45 pts/0 0:00 grep dcc $ Hole #2 $ id uid=600(test) gid=300(users) $ ps -ef|grep inet test 26285 26279 0 17:42:42 pts/0 0:00 grep inet root 12276 1 0 Aug 22 ? 0:00 /usr/sbin/inetd -s $ cat > $LPHOME/system/lpdprocess 12276 ^D $ dcclpdshut LPD048E Signal sent to dcclpdser to shut down. $ ps -ef|grep inet test 26291 26279 0 17:45:17 pts/0 0:00 grep inet $ Hole #3: # id uid=0(root) gid=1(other) # ls -alt /root/test total 6 drwx------ 2 root other 512 Sep 5 17:46 . -r-------- 1 root other 365 Sep 5 17:46 foo drwx------ 3 root other 512 Sep 5 17:46 .. # su - test Sun Microsystems Inc. SunOS 5.6 Generic August 1997 $ id uid=600(test) gid=300(users) $ ls -alt /root/test /root/test: Permission denied $ dccscan /root/test 30 5 "-dlp0" $ # now, go to the printer and wait for the files to come out, or watch them # being queued as root, if you have access to dccstat Vulnerable Versions ------------------- 3.3.0 for Unix (on Solaris 2.6). 3.2.1 for Linux (on Redhat 5.2). * These are the only versions I had available for testing. Workarounds ----------- At this time, no patches or updated versions are available. However, most of the utilities in question either don't need to be suid, or can be group-owned by a more restricted group and mode 4750. The web interface works fine with a newer version of Apache, and the web server does not need to run with all the children spawned as root. The vendor was notified of these problems on 8/24/2000. They did respond, confirming the existence of the holes. However, a request for an ETA on an updated release or patches has thus far been ignored. ______________________________________________________________________ ------------------------------------------------------------- - _azure [=] 0x04: Using IPSEC and Samba to integrate Windows Networks /Intro _/why and how Occasionally you may be in a position where you are required to join two Windows networks together across the Internet in a secure manner. I'll leave detailed descriptions of possible motivations up to your ample imagination. This paper aims to ease your acquisition of experience in the Windows/NetBIOS world by sharing the fruits of my experimentation. Technical discussion will begin with a simple overview of various networking tools (and their configuration) under OpenBSD, and continue with the actual integration of Windows machines into a functioning IPSEC VPN. Feel free to skip portions of this article if you are already familiar with these concepts. _/suggested uses ---/apps server The hot new buzzword seems to be 'B2B' (Business to Business). Many companies are rolling out 'ASP' (Application Service Provider) services -- designed to provide access to various applications across the Internet from a single, 'secure' location. Several that I have been exposed to are NT-only machines completely installed and provided by the vendor. In these cases, you may not have permission(!) to install additional software on said device. Our 'secure solution' is completely transparent to the machine making use of it. ---/secure sharing People want to share their files. Many times, separate offices may be using e-mail to transmit sensitive information back and forth between locations. We can do our best to break that habit by enabling them to share their files in an 'easier' way. Yes, I refer to the 'Network Neighborhood'. ---/vpn in general It just makes good sense. Utilizing OpenBSD/Samba gateways removes the liability for the encryption and connection from the NT servers or other proprietary machines that no one one site (or on staff) may have access to. It also eliminates the possibility users on client machines (that might otherwise be gateways themselves) will contaminate or knock out your connection. _/for openbsd 2.7 The methods outlined in this article are tailored to the IPSEC implementation included with OpenBSD 2.7 (it may be beneficial to experiment with a -current build, as 2.7 requires some patching). Earlier versions of OpenBSD differ in the way IPSEC is configured, and therefore may require some tweaking in the rules generated by ipsec_config_esp.pl to work. ---/links to other operating systems Some other operating systems also offer support for IPSEC. Below is a link to the project home page for an IPSEC implementation that has been ported to Linux. FreeS/WAN on Linux: http://www.xs4all.nl/~freeswan/ /Connections _/choose_provider Choosing a provider can be more tricky than it looks. Some providers have outlawed VPNs in their Terms of Service (TOS) agreements. Some providers are particularly reluctant to provide a static IP address. Still other providers do not offer enough bandwidth to make Windows integration worthwhile over the Internet. Many will cling to some unwieldy combination of the three. ---/fast_enough? Generally speaking, you will want something equivalent to or faster (preferably _much_ faster) than an ISDN connection for your filesharing adventures to be worthwhile. At slower speeds, Windows networking becomes extremely flaky, and your users will start claiming that 'Unix sucks.' [ And we couldn't have that, could we? {kynik} ] _/alternatives Cable modems or DSL can make a great cost effective solution to your bandwidth problems. In many markets, you can purchase connection speeds approaching T1 speeds for under $100 a month. Some cities with fiber ring installations are also now offering 'point to point' connections of up to 100mbs for less than you will probably pay for a traditional T1. /Gateways The first step in setting this all up is drawing a basic network map. You will need one gateway box on each end of your proposed VPN. Your setup should look something like this: [NetworkA]----> [OpenBSD/Samba] <----> [OpenBSD/Samba] <----[NetworkB] This is a standard IPSEC VPN setup as outlined in the faq material available at the OpenBSD website: http://www.openbsd.org/faq/index.html We're using tunnel mode ESP in our configuration. Once you have your network established, you can begin installing and configuring your gateway machines for our more specialized purposes. _/machine_config ---/connection Depending on how you are connected to the internet, you will configure your box accordingly. ---/dhcpd? Offering dhcpd services for the client machines behind your gateways can be a good idea; especially if the number/location of workstations is likely to change often. See dhcpd(8). ---/dns? You may consider running DNS for your workstations _on_ the gateway machine itself. This can increase overall performance and speed up responses on the workstations. IPF will of course be configured to block this for external queries. //kernel_config ---/customizing Customizing your kernel to fit your specific hardware is always a good idea. It cuts down the size of the file that is loaded into memory; thus increasing system performance. For our purposes, you will want to enable at least the following options: option IPFORWARDING option IPFILTER option IPFILTER_LOG Since I am typically on a 100mbps LAN on my internal side, I also usually kick up my NMBCLUSTERS to 8192 as recommended in the performance tuning faq at: http://www.openbsd.org/faq/faq11.html You will need to edit /etc/rc.conf to activate ipfilter and IPNAT at boot time. You will also need to have net.inet.ip.forwarding=1 in your /etc/sysctl.conf file. ---/patches It's also a good idea (especially in the case of software packages like IPF and IPSEC that are constantly under development) to patch your system from the latest sources. In the case of OpenBSD 2.7, you'll definitely want to do this to make sure you nab nasty bugs the software contained as it shipped. See http://www.openbsd.org/errata.html for info on current patches. ---/state_table The state table in particular is something to pay attention to. In versions of OpenBSD prior to 2.7, the default max limits of the state table were not very big. This could lead to dropped packets and other unpredictable problems in the course of your network's operation. Extremely difficult to track down if you aren't looking for the problem in the first place. Take a look at /usr/src/sys/netinet/ip_state.h: #define IPSTATE_SIZE 257 #define IPSTATE_MAX 2048 /*Maximum number of states held */ It may be wise to increase these (in -current, this has already been done) to insure you don't fill up your state table and bonk your connection inexplicably: #define IPSTATE_SIZE 5737 #define IPSTATE_MAX 4013 /* Maximum number of states held */ If you want to tune these, the rules of thumb are: - IPSTATE_MAX should be ~70% of IPSTATE_SIZE (for good hash table performance) - IPSTATE_SIZE should be prime; and avoid primes near powers of two You should be able to increase these to whatever values suit you. (thanks to kjell@openbsd.org via deadly.org) You will of course then need to recompile your kernel. _/ipnat Machines behind your gateways will have to know how to talk to machines outside of your LAN. This is accomplished through a novel mechanism called _routing_. In our case, all of our client boxen will be located in private address space. OpenBSD ships with IPF, and this includes a handy utility known as IPNAT. IPNAT handles Network Address Translation, which will be crucial in establishing connectivity to the Internet from our workstations. While not directly necessary to accomplish our stated goal of joining Windows networks; we will probably want our workstations to do more than simply share files across the VPN. If not, you can safely skip this section. The VPN gateway boxen will also end up serving as Internet gateways for the other machines, while protecting them from the outside world with IPF. A simple configuration that will get us up and running is as follows. In this example we will use the following network addresses: - external ip (on ne0): xxx.xxx.xxx.1/32 - internal net (on xl0): iii.iii.iii.0/24 # /etc/ipnat.conf map ne0 iii.iii.iii.0/24 -> xxx.xxx.xxx.1/32 portmap tcp/udp 10000:60000 map ne0 iii.iii.iii.0/24 -> xxx.xxx.xxx.1/32 map ne0 iii.iii.iii.0/24 -> xxx.xxx.xxx.1/32 proxy port ftp ftp/tcp The first line maps private addresses in the 10000 port range to the public address in the 60000 range. The second line maps ports outside these ranges identically. The third line tries to make up for quirks in the ftp protocol. Packets traveling across the gateway to leave the machine will be transformed in this manner before being spit onto the Internet; and converted back when replies are received. _/ipf In the example below, ne0 will represent our external ethernet interface. Since I get my Internet connection from a cable modem, my external connection is hooked up directly to a 10mbps card, and my internal network is connected through a 100mbps card. I've found that this setup is effective and reliable. Generally, it's not necessary to waste a 100mbps capable card on an interface that can only handle 10mbps. Much has been written http://www.deja.com/dnquery.xp?QRY=ipf+rules&ST=MS&svcclass=dncurrent&DBS=2 concerning different philosophies of firewall configuration. I generally choose to adopt a 'default-deny' stance, as this simplifies the process of deciding what ports to block -- I simply only allow access to ports that I want to be open. In tandem with this is the choice to perform stateful packet inspection; roughly: only accepting packets that are part of an active session initiated from inside our network. (See http://www.obfuscation.org/ipf/ipf-howto.html#TOC_20 for more on why this is a good idea.) Continuing with our example format: - external ip (on ne0): xxx.xxx.xxx.1 - internal ip (on fxp0): iii.iii.iii.1 The initial rule will block all traffic indiscriminately, and log any attempts at a connection to /var/log/ipflog (not specifying a log level will cause IPF to log things to /var/log/system and the console as well, which may or may not be desirable). block in log level local0.info on ne0 Right out of the gate we have blocked all traffic coming to or passing out from ne0. This means you are pretty much dead in the water. Fortunately, we did not use the argument 'quick' yet, which would force the ipfilter to immediately discard everything and refuse to read any more rules. Since we didn't, the ipfilter moves on. The next thing we do is to get a little more specific about what we are blocking. We will use the 'quick' argument to make sure these rules are not accidentally overridden later. The following lines are useful to prevent IP spoofing and DoS attacks. Since packets from these addresses should never be coming in on your external interface, we're not too worried about blocking them entirely. block in quick on ne0 from 127.0.0.0/8 to any block in quick on ne0 from 10.0.0.0/8 to any block in quick on ne0 from 172.16.0.0/12 to any block in quick on ne0 from 192.168.0.0/24 to any block in quick on ne0 from any to xxx.xxx.xxx.0/32 block in quick on ne0 from any to xxx.xxx.xxx.255/32 At this point we have setup a firewall that will allow no traffic in, and no traffic out. This is probably not too useful. What we want to do now is allow certain traffic from behind the firewall to make connections to the outside. Used in conjunction with IPNAT, this would allow machines on our internal network, using our firewall host as their IP gateway, to surf the net. However, connections to the inside from the Internet would still be completely blocked. Here are the rules. Note that each address is allowed individually, and that TCP, UDP, and ICMP are each allowed with separate rules. This is an important detail. Even if someone were to setup on your internal LAN and choose an un-used address in your private subnet, they would still have to be added in manually to the firewall rules before they could talk to the Internet. If this is not practical or necessary for your network, you can allow in subnets in place of individual addresses. pass out quick on ne0 proto tcp/udp from xxx.xxx.xxx.1/32 \ to any keep state pass out quick on ne0 proto icmp from xxx.xxx.xxx.1/32 \ to any keep state pass out quick on ne0 proto tcp/udp from iii.iii.iii.2/32 \ to any keep state pass out quick on ne0 proto icmp from iii.iii.iii.2/32 \ to any keep state pass out quick on ne0 proto tcp/udp from iii.iii.iii.3/32 \ to any keep state pass out quick on ne0 proto icmp from iii.iii.iii.3/32 \ to any keep state pass out quick on ne0 proto tcp/udp from iii.iii.iii.4/32 \ to any keep state pass out quick on ne0 proto icmp from iii.iii.iii.4/32 \ to any keep state Now your firewall machine itself, as well as your internal machines iii.iii.iii.2, iii.iii.iii.3, and iii.iii.iii.4 will be able to surf. We've used the 'keep state' argument to enforce that packets not emanating from your specific TCP/IP session be blocked. The next step involves opening whatever ports you want to face the Internet to traffic from the outside. Since this machine will be devoted to acting as a gateway for your private network, you may not wish to enable _any_ remote access. However, if you decide to enable access to a port, you would add a rule like this: pass in quick on ne0 proto tcp from any to xxx.xxx.xxx.1/32 \ port = 22 flags S keep state keep frags This will allow tcp traffic in to xxx.xxx.xxx.1 on port 22 from anywhere. All other traffic coming in on ne0 will be blocked completely, and logged to /var/log/ipflog. And that's pretty much it. By keeping state on all packets in and out, you are protected against FIN scans and most denial of service attacks. No packet will be admitted into your external interface unless it meets with your stringent criteria. Any port scan will have to complete a full TCP connection to one of your open ports before it will get anything in return. To the outside world, your blocked ports look like they do not exist. Pat yourself on the back, this is a Good Thing(tm). Now all you have to do is sit back and watch your ipflog grow to mammoth proportions. (Don't rest too easily; there will be more changes to this configuration necessary after we meddle with IPSEC). A useful tool for parsing the obscene amount of data you will be collecting can be found at: http://www.antibozo.net/ogata/webtools/plog.txt _/ipsec_ config This has been discussed at great length in previous articles (see ajaxx's overview in _Napalm #6_). Since we're using a basically text-book example of an IPSEC/ESP VPN; I've cut to the chase here and included a handy perl script that will generate our rulesets for us: ipsec_config_esp.pl (download from: http://www.inri.net/openbsd/perl/ipsec_config_esp.pl) [ Or you can snag this from the addenda on the main page. {kynik} ] First of all, make sure you have net.inet.esp.enable=1 and net.inet.ip.ipsec-acl=1 enabled in /etc/sysctl.conf on your gateway machines. Then, copy the files ipsec_config_esp.pl creates and copy them to their prescribed locations. Before we can fire up our IPSEC connection, there are some changes to /etc/ipf.conf that need to be made in order to allow our ESP-encrypted traffic to pass between the gateways. On both machines you will need to add the following rules (again keeping with our previous example conventions): Gateway A - external ip (on ne0): xxx.xxx.xxx.1 - internal ip (on fxp0): iii.iii.iii.1 Gateway B - external ip (on ne0): yyy.yyy.yyy.1 - internal ip (on fxp0): hhh.hhh.hhh.1 On Gateway A: # /etc/ipf.rules # # pass in IPSEC stuff # pass in quick proto esp from yyy.yyy.yyy.1/32 to xxx.xxx.xxx.1/32 pass out quick proto esp from xxx.xxx.xxx.1/32 to yyy.yyy.yyy.1/32 pass in quick on enc0 from hhh.hhh.hhh.0/24 to iii.iii.iii.0/24 On Gateway B: # /etc/ipf.rules # # pass in IPSEC stuff # pass in quick proto esp from xxx.xxx.xxx.1/32 to yyy.yyy.yyy.1/32 pass out quick proto esp from yyy.yyy.yyy.1/32 to xxx.xxx.xxx.1/32 pass in quick on enc0 from iii.iii.iii.0/24 to hhh.hhh.hhh.0/24 And of course, to enable our changes we will have to do: # ipf -Fa -f /etc/ipf.rules At this point you are ready to run your IPSEC scripts on each gateway. Once this step is completed, your VPN should be functioning between both of your private networks. netstat -rn -f encap should yield results similar to: Encap: Source Port Destination Port Proto SA(Address/SPI/Proto) iii.iii.iii/24 0 hhh.hhh.hhh/24 0 0 yyy.yyy.yyy.1/00001001/51 iii.iii.iii/24 0 yyy.yyy.yyy.1/32 0 0 yyy.yyy.yyy.1/00001001/51 xxx.xxx.xxx.1/32 0 hhh.hhh.hhh/24 0 0 yyy.yyy.yyy.1/00001001/51 xxx.xxx.xxx.1/32 0 yyy.yyy.yyy.1/32 0 0 yyy.yyy.yyy.1/00001001/51 Ping test between your to private nets to make sure everything is kosher. If not, trouble-shooting tips are as easy as clicking to: http://www.openbsd.org/faq/faq13.html And then it's time to move onto the Windows Networking portion of our show... _/samba_config Samba is our friend. It will help us coax the Windows machines into talking to each other in a reasonable manner. Fortunately for us, Samba is a robust package that allows us to replicate many of the same services you would otherwise have to look towards a licensed copy of Microsoft Windows NT 4.0 Server for. With it, we can convince Windows client machines that it really is in their best interest to comply with our demands. We can even get them to recognize the fact that they are on a network and other machines exist. By using Samba in this way, we can overcome many of the annoying factors in trying to connect disparate networks and fileshares over a non-NetBEUI connection. Since Microsoft themselves are dropping emphasis on NetBEUI with Windows 2000, this even seems to be a positive move from a marketing stand point. [ It is suggested by Microsoft on Windows 2000 running Active Directory a minimum rate of 512KB/s should be sustained between sites for Intra-Site Replication to function correctly. On lower bandwidth sites, you should use an Inter-Site Replication design. See MS Active Directory Documentation for more information. {Reverse Corruption}] We'll trust that you've accomplished the installation of Samba either from the ports tree, from a package, or by compiling it from scratch on your own. A basic overview of configuring Samba follows: ---/naming conventions Naming your gateway hosts in Samba is the first step. We'll start with a fresh (blank) /etc/samba/smb.conf file and work our way up. It's usually a good idea to name your gateway's NetBIOS name identically to its name in DNS and /etc/hosts. We'll start our file like this: # Global parameters [global] netbios name = HOSTNAME workgroup = WORKGROUP Each gateway in the VPN will have its own separate Workgroup. Name these accordingly (i.e., OFFICE1, OFFICE2, etc.). It is not required that these Workgroups be a part of the client network. Since we are merely using Samba as a WINS server; our clients can safely ignore all its other features. ---/domain logons It may be important to note that we are configuring the Samba servers as though they were handling Domains when we may not necessarily configure the Windows clients for Domain Logons. For synchronization of browse lists between subnets, Samba requires that the Samba servers function as Domain Master Browsers even if there are no clients actually logging in through Domains. domain logons = Yes security = user For a thorough overview of using Domain Logons with Samba and Windows clients, you can refer to the on-line edition of _Using Samba_ at: http://www.oreilly.com/catalog/samba/chapter/book/ch06_01.html ---/browse lists Getting Network Neighborhood to work across the VPN can be very helpful to frustrated users. Samba provides a relatively easy mechanism for synchronizing browse lists between separate subnets. On each side of the VPN, we'll want to make sure our Samba server has taken control of the local browse list, and let it know to sync that browse list with the Samba server on the other end. This will allow all client machines connected to our VPN to show up in each other's Network Neighborhood. os level = 34 local master = Yes preferred master = Yes domain master = Yes remote browse sync = iii.iii.iii.iii iii.iii.iii.iii = the private IP address of the Samba server on the opposite end. ---/misc global parameters The 'server string' is just whatever info you want to show up as a description of your gateway machine when someone tries to browse it. Log file location and size is up to you! server string = Samba Server log file = /var/log/smbd.%m max log size = 50 We won't have Samba default back to DNS if it can't find a share-name: dns proxy = No ---/wins and lmhosts We _do_ however want Samba to act as a WINS server. In general, by configuring this option you will save yourself a lot of headache when it comes to operating your Windows clients on a network. By enabling WINS services, your Windows machines can advertise and retrieve SMB information to/from your Samba server rather than spraying broadcast packets all over the LAN every time it has to access its network device. This will significantly reduce collisions and can greatly increase the efficiency of your connection. wins support = yes name resolve order = lmhosts wins bcast By setting a resolve order, we'll let Samba know how to resolve requests for SMB information when it receives them. The LMHOSTS file, similar to /etc/hosts in Unix (except that it contains NetBIOS naming information rather than hostname information), can be used to create hard-coded WINS entries for certain machines. It would normally reside in /etc/samba, and it's format looks like this: iii.iii.iii.1 HOSTNAME Unfortunately, merely creating an LMHOSTS entry for a host does _not_ make it show up in the Network Neighborhood. Synching the browse lists (as mentioned above) is a necessary step to achieve this functionality. ---/filesystems We're not foolish enough to try to use our firewall/gateway as a fileserver are we? ---/printers Ditto. ---/start it up This is actually all there is to it. Having seen the default-install smb.conf, you might not believe that a seventeen-line file could achieve your wildest dreams. Since we are not actually accessing (or creating) any shares on the Samba server, it is not necessary to create any Samba users on the gateway machine at all. The only real service our clients will be _accessing_ is WINS; which does not require a login. It's good to start Samba with the -D (daemon-mode) flag, so that it won't hang if something goes wrong with a session. # smbd -D # nmbd -D /Workstations The workstation: bastion of extended uptime and functionality. What we'll be doing is configuring network addressing and naming for the machines on the private side of your networks. We'll assume that you A.) are running some 'modern' permutation of Windows 9x, and B.) have a working NIC connected, installed and ready to go. _/gateways Windows clients will use the VPN gateway box as their TCP/IP default gateway (follows, doesn't it?). Right-click on Network Neighborhood. Scroll down and select 'TCP/IP -> NIC' (whatever your NIC is). Click 'Properties'. Click the 'Gateways' tab. Enter the address of the gateway's internal interface (iii.iii.iii.1 or hhh.hhh.hhh.1). Click 'Add'. _/addresses Each workstation will be assigned a unique IP address in the subnet of the gateway's private side (iii.iii.iii.0/24 or hhh.hhh.hhh.0/24). Click the 'IP Address' tab. Enter a correct IP address and Subnet Mask. _/wins Here's where we add WINS services on the client. As was mentioned before, this greatly increases the usability of Windows networking by eliminating the need for your machine to send broadcast packets to the LAN every time it accesses the network. Click 'WINS Resolution'. Enter the private-side address of the gateway. Click 'Add'. _/dns Click the 'DNS' tab. If you decided to run DNS on the gateway machine(s), you'll enter the private-side address of the gateway here. Otherwise, enter a known-good DNS server. Click 'Add'. Enter your hostname and domain (if you have one) as appropriate. Click 'Okay'. _/identity We'll want to correctly identify your machine here so that other workstations will understand what they are looking at when they see you pop up in Network Neighborhood. This is also where you'll configure your Workgroup so that everything will remain tidy. Click the 'Identification' tab. Computer Name: This is your hostname. Minus the domain information. Workgroup: WORKGROUP Computer Description: Analogous to 'server string' in smb.conf Click 'OK' and say yes when it asks if you want to reboot (we know you're lying, but the machine doesn't care). _/sharing The main point of this entire exercise is to be able to access Windows shares across the VPN we've established. In order to accomplish this, we'll have to have enabled sharing in Windows. ---/mapping drives You'll probably have some machines that need regular access to other machines. Mapping drives on remote computers is one way to make this less time-consuming. - - -/batch files I've had much better luck with mapping drives through batch files than in trusting Windows to remember all of the information with its internal mechanisms. This seems to be true of many of Windows' networking functions. A simple batch file to map drive F: on iii.iii.iii.200 to drive F: on hhh.hhh.hhh.2 might look like this: @echo off rem *** map drive f: on iii.iii.iii.200 to f: net use f: \\iii.iii.iii.200\f /yes Save that to map.bat and put it in the StartUp Menu. When you reboot, the drive will be automatically mapped. _/network neighborhood Thanks to our setup in smb.conf, this should work for you out of the box. Simply cruise to the machine you want to access. /Programs _/known caveats Windows tends to panic, crap itself, and cease to function in the face of actual network connectivity, but this is a known issue; especially with Windows 95A/B. Patience with the installation (and re-installation) of network drivers is sometimes a must. Be gentle. Tend its needs. Never expect your changes to have taken effect if you power off the machine before it finishes shutting down on its own; no matter how long it takes. ---/speed issues Running a program that is stored on a remote server is often a desirable way to reduce disk usage on workstations, and consolidate/secure the information users will be manipulating. Programs that hog a lot of memory are not going to run very well on a slow connection. There are obvious issues of waiting for various components to load; but Windows also demonstrates its own proprietary tidbits of flakiness when it takes too long to load a piece of software over a network. Large clunky applications may not demonstrate the best performance when run across the VPN. /Summary _/further reading http://www.openbsd.org http://www.samba.org /Conclusion A relatively elementary once-over, yes; but this should provide some indication of real-world uses for these open source tools. IPSEC under OpenBSD provides a robust VPN alternative to high-priced commercial packages; and can spell the difference between secure connections and plain-text transactions in many situations where end-users (and the people in charge of end-users) are less than astute operators of computers in general. Working from this framework also leaves plenty of options open for expansion, should OpenBSD be needed to come to the rescue of other network tasks. Viva la revolution. _/signed _azure _/contact information azure@gh0st.net (http://www.nsacom.net) _______________________________________________________ ---------------------------------------- - Fl@w Xpl0it@ [=] 0x05: Resource Protection Mechanisms Resource Protection Mechanisms: Implementations in Operating Systems This is an introduction to resource protection mechanisms in operating systems with an analysis of the protection mechanisms as implemented by Windows NT 4.0 and generic UNIX systems. Where significant modifications have been made to the implementation of a protection mechanism by one of the UNIX variants, this is also highlighted and discussed. Also, potential threats to many of the resource protection mechanisms were identified and included. The most unsettling aspect of this file is the ease with which most of these mechanisms can be compromised. This document merely seeks to encourage system administrators not to rely on the operating system alone to provide complete protection for their system. Introduction ============ Resource management is one of the tasks performed by the operating system. Each computer system contains within it several types of resources that are capable of different functionality. Some of these resources include the CPU, input-output devices and various types of software. Each process executing on a computer requires access to several of these different resources to allow it execute properly. It is the role of the operating system as a resource manager to allocate them in an efficient and fair manner. This allocation should also be performed in such a manner that it does not starve processes of needed resources. The operating system is also responsible for keeping track of the status of all resources to determine which process each resource has been allocated to and which resource has been freed by its assigned process. Additionally, it also tracks the resource needs of each process and schedules which processes should get what resource and the time period this resource is available to the process. Another important task of the operating system is the protection of these resources. This is to ensure that processes can access a resource only when the resource manager gives them permission to access it and that they relinquish control of the resource when commanded to do so. This task of the operating system as the protector of resources will be the focal point of discussion in this paper. Resource Types ============== The resource types managed by an operating system fall under two categories: - Hardware Resources These are physical resources present in the system, which have a finite capacity. On most computer systems, the number of processes that can be run far exceed the number of available physical resources, hence the operating system creates virtual instances of some of these physical resources and make them available to individual processes. These physical resources include [1]: * Processor - Process management system * Memory - Memory management system * I/O devices - Input Output system * Disks - File system - Software Resources These are resources created by the virtualization of the hardware resources available on the system. Not only does this protect the hardware resource from direct access, it also provides processes with improved versions of the physical resources. These software resources include [1]: * Processes - The virtualization of the entire computer including a virtual processor that abstracts the hardware processor * Virtual memory - The virtualization of physical memory * Logical devices - The virtualization of various physical devices available on the system * Files - The virtualization of storage devices * IPC objects - Inter-process communication objects that includes pipes, semaphores, message queues and ports Importance of Resource Protection ================================= It has been noted that as a resource manager, one of the tasks of the operating system is to grant permissions to processes on when and how to access system resources. In the operating systems being evaluated, these processes can be initiated by several different users with varying levels of permissions and authority on the system. Therefore to protect users from each other and also protect itself from damage, the operating system determines that each process has the proper authorizations before it permits them to access or modify any of the resource which they are requesting. Failure to provide proper protection of resources often result in one or all of the following four (4) violations: - Unauthorized disclosure of information: This occurs when private information held in a computer system is revealed to a user not allowed to view it. - Unauthorized modification of information: This occurs when an unauthorized user is able to modify information stored on a computer system. - Unauthorized use of service: This occurs when an unauthorized user is able to use a service on the computer system which they are not allowed to. - Denial of service: This occurs when an authorized user of a system simultaneously accesses several systems resource in such a way that it prevents other authorized users from accessing needed resources. [ A denial of service violation doesn't necessarily have to be an authorized user, though the damage an authorized user can generally do is much greater. For example, an unauthorized user could flood the network with packets in the hope that this will interrupt service. On the other hand, an authorized user could run a program locally that allocates more memory than the computer has available (say, 80M when the computer only had 64 available) and there are no quota mechanisms in place. I don't know anybody that'd do such a dastardly deed ;) {kynik} ] Historical Background ===================== The Windows NT operating system was developed by Microsoft Inc., and first released in 1992. It originated as a joint effort with International Business Machines (IBM) Corporation as a part of their OS/2 operating system. Unlike its 16-bit predecessor Windows 3.x, NT was designed to be a 32-bit operating system with support for processes, multiple threads, symmetric multiprocessing and distributed computing. It is also a Fault Tolerant Operating System, with each 32-bit application operating in its own Virtual Memory address space preventing an application from interfering with another's memory space. Largely implemented in the C language so as to allow portability to other hardware platforms, NT is available today on the x86, MIPS and Alpha platforms. Windows 2000 however is only avaible for the x86 architecture. It also adopts the NT File System (NTFS) as its native file system gaining from this the increased security features built into the file system. [ NT 4 was also available for the PowerPC, and earlier versions were known to run on all kinds of weird hardware, the m88k for instance. {ajax} ] The current version of Windows NT is version 5.0 also named Windows 2000. This version is built on the same core NT technologies with minor update and modifications. It also provides support for previously unavailable features such as Plug-and-Play, support for USB devices, power management, DirectX 7.x and more. UNIX was brought into being at Bell Labs by Ken Thompson, Dennis Ritchie and others to provide a working environment for themselves. Written originally in assembler for the PDP-7 and then ported to C, UNIX quickly became very popular among the academic computer science community. Further refinement of this primitive operating system by various institutions possessing the source quickly pushed UNIX to become top class operating system while at the same time ensuring that it would produce several different implementations. Some of these include FreeBSD, NetBSD and OpenBSD which descended from projects being worked on at the University of California Berkeley (Berkeley Software Distribution). Other known variants include Solaris, developed by Sun Microsystems Inc., and originally based on the ATT SvR4 code and Linux whose origin was merely influenced the previous UNIX implementations. So many variants of UNIX exist today such that it is not quite possible to list all the supported hardware platforms and architecture here. Although for portability's sake most UNIX system architecture still remain mildly similar, specific mention is made in this paper whenever the implementation of a feature being discussed is radically different from that of other UNIX variants. Comparisons of Protection Mechanisms ------------------------------------ In an operating system, protection refers to the methods implemented to control user access to system resources [2]. We will observe different protection mechanisms instituted by different operating systems. Please note though that this does not file include resource management in the form of scheduling or memory partitioning. Identification: =============== Windows NT Usernames on Windows NT are mapped onto a unique number known as the SID (Security Identifier). This identifier is a long alphanumeric sequence which is created to be unique within the domain (Footnote:!) in which the system exists and is attached to a username during its entire lifetime. To preserve this uniqueness, SIDs are never reused even after the username they are attached to is deleted. As we will discuss later, access control is built around SIDs so this prevents users from being defaulted into gaining permissions which they shouldn't. UNIX Users are identified on a UNIX system by the use of a username. On creation of the account, the system administrator selects a number that would be used to attached to the username. There are no strict requirements for the value of this number, known as the UID (User Identification number) to be unique. Traditionally, UIDs with a value less than 500 are reserved for special names in the system such as the bin and daemon users. The system administrator typically known as root is assigned the UID of 0 (zero). Potential Threats ----------------- UNIX Not forcing UIDs to be unique has the capacity to provide equivalent level of authority for multiple users on the system. In this situation, users with the same UIDs have the ability to fully access and modify each others documents. Due to the nature of the /etc/passwd file being world readable, attackers could scan through this file and detect who they have the same UIDs with. Another potential attack results from the recycling of user IDs. Since the file system stores the UID of the file owner as its identification mechanism, recycling of the UID provides new users with full access to files that were owned by the previous owners of the UID. User Authentication =================== Windows NT Windows NT uses passwords to authenticate users. Passwords entered by a user are encrypted and compared against the encrypted version stored within the system. A successful comparison grants the user access to the system with all permissions accorded to the attached SID in place. Traditionally, passwords are stored on an NT system in a portion of the registry known as the SAM (Security Accounts Manager).[6] These passwords are stored not as clear-text but as hashes (Footnote:@). One is known as the LANMAN hash and is converted to a non-case sensitive state and then encrypted using a variant of the DES encryption mechanism while the other is called the NT-native password and encrypted with the MD4 (Footnote:#) algorithm. NT security relies partly on the difficulty of users retrieving the password hashes from the SAM as the passwords within it are accessible only by the operating system and not even by the machines Administrator account. The security also partly relies on the difficulty of reversing the one way functions used to encrypt the passwords. However, this second point is becoming much less of a deterrent with tools like L0phtCrack (Footnote:$) which have the capacity to guess several thousand passwords per second. Windows 2000 To combat the wide spread use of L0phtCrack, Microsoft released a tool called Syskey with the NT Service Pack 4 that allowed for Administrators to encrypt their SAM databases. However the use of this was entirely optional resulting in many systems not implementing this security mechanism. With Windows 2000 however, the use of Syskey to encrypt the SAM database has become mandatory. Additionally, the hashes of local users are the only things stored in the SAM while those of domain users have been moved to the Active Directory Service (ADS). The major change here is the move to using two separate security databases. The ADS hash storage mechanism functions much like its SAM equivalent and is also mandatorily encrypted. Tools like pwdump2 (version 2) however already exist that can read LM-hash and NT-native hash values in the Windows 2000 ADS and dump them to a text file. UNIX User authentication is also performed on UNIX systems using passwords. After identification, the password provided by the user is encrypted using the DES (Footnote:%) algorithm and compared against the original encrypted version stored in /etc/passwd. A match then grants the user access to the system. The world readable feature of the /etc/passwd file makes it very susceptible to attack. While the DES encryption method was sufficiently difficult to break some time ago, programs like Crack 5.0 and John the Ripper have been able to successfully decrypt passwords from this file in relatively little time. root:2pcCUSGVgSyAk:0:0:Super User:/root:/bin/false bin:*:1:1:bin:/bin: daemon:*:2:2:System Daemon:/sbin: adm:*:3:4:adm:/var/adm: httpd:*:5:5::/home/httpd:/bin/false nobody:*:99:99:Nobody:/: flaw:bR.cxeOc5uCW.:500:500::/home/flaw:/bin/bash xploita:MwrYkBLXF2k4k:500:501::/home/xploita:/bin/bash stealth:cF.cjioc5uCW.:502:502::/home/hell:/bin/tcsh nel:vb.8ijKleop8vt:503:503:Nelleke Karst:/root:/bin/bash Listing 1: This displays the typical contents of a /etc/passwd file A remedy to this is the use of 'shadow' files in many systems. In this method, the encrypted passwords are moved to the /etc/shadow file which requires elevated permissions to view. This leaves the /etc/passwd file to be accessible to all other programs that need it without giving away the encrypted passwords. No UNIX distribution has at yet implemented a non world readable /etc/passwd file as this would render the multitude of programs, that access this file for information, useless. Note however that improperly securing this file by the system administrator still exposes the system to the previous threats it was designed to overcome. An alternative to the above approach was therefore developed. This method known as Pluggable Authentication Modules (PAM) runs the authentication process through an abstraction layer allowing applications to support a pluggable method of authenticating user identity. By modifying the /etc/pam.conf file, the system administrator could alter the authentication mechanism of his system to use Kerberos (Footnote:^), MD4 or any other method.[4] [ "Any other method" means anything you can write a PAM plug-in for, which at present includes Radius, TACACS+, LDAP, SMB, NIS[+], a few one-time password schemes, smart cards... It should be noted that Unix logon security with PAM is equal to the security of the protocol doing the authentication; for example, a PAM SMB module is equivalent to an NT login, which makes it vulnerable to the attacks above. {ajax} ] Potential Threats ----------------- Both Windows NT and UNIX share the design weakness of requesting and accepting clear-text passwords sent from the users workstation to the server during the authentication process. All that is required in this case is for an individual to install a network packet analyzer between the local and remote host to intercept the password of the user. To prevent this, some UNIX variants have adopted the use of SSH (Secure Shell) which allows for encrypted communications to be sent between two untrusted hosts over an insecure network. SSH utilizes a public-key encryption system to authenticate remote hosts and ensures that the machine has not been duplicated. [5]. Windows NT As can be deduced from the earlier discussion, the greater difficulty of circumventing Windows NT authentication control mechanism is getting access to the LM-hash or NT-native password hashes. Windows NT dubiously subscribes to a method of security through obscurity in its attempt to keep the SAM out of unauthorized hands. In some systems, it allows for an encryption key stored within the system to be applied in encrypting the contents of the SAM. Widely available tools exist that can seek out this encryption key and utilize it to defeat the SAM's encryption. Once this is done, permissions can be modified to allow Administrator access to view the contents of the SAM and hence the precious hashes. An alternate method of attack is for a user to use the same undocumented API calls that NT uses to access the SAM to dump out its contents. The use of two password in NT doubles the possibility of obtain the actual user password. This is because attackers now have a choice of cracking the MD4 or DES encrypted hashes. The MD4 one-way hash function was initially thought to be impossible to decrypt until Hans Dobbertin in his paper Collisions in MD4 [11] described how two separate data strings could produce the same hash value. This discovery, named MD4 collisions after the paper significantly narrows the number of guesses a brute-force password cracking program needs to make in other to guess a fitting NT-native password [8]. UNIX As previously stated, the world writeable nature of the /etc/passwd file on UNIX systems provides attackers with the ability to copy and remotely crack passwords user passwords. The next most common cause of defeat of the authentication mechanism of a UNIX system is however misconfiguration of the shadow file. This is often in the form of setting the wrong file permissions to this file thus making its contents easily accessible. Access Control ============== Windows NT Windows NT provides a unified access control mechanism to all the objects and subjects within the system. A subject in Windows NT refers to a process with one or more threads being run on behalf of a user. An object refers to the items stored within the system. In this implementation, the access control mechanism relies on two components. * Access Token (AT) - This is associated to every process in the system. * Security Descriptor (SD) - This is connected to every process that supports interprocess access. On completion of a successful user authentication process, an access token is generated by the system and attached to the users initial process. This token contains the users SID which is used by the system to determine the users access to various resources. Every process created by this user inherits this AT [9]. Subjects are allowed to contain several access tokens with the initial token handed to them being known as the primary token. This token as noted earlier contains the users SID and also contains the group SID of the user as well as permissions they hold. Before this subject (process) can access any object, all token SIDs held by the subject are compared against the information stored in the ACL of the object it wishes to access. All objects in the Windows NT system have an associated Access Control List (ACL) entry. This list consists of a number of Access Control Entries (ACE). Each ACE contains a SID and either the operation that the owner of this SID is allowed to perform on the object or the operations they are forbidden to perform. ACEs that describe actions a SID is forbidden to perform are stored ahead of ACEs listing the actions a SID is allowed to perform. These lists are stored in the Local Security Policy Database which is maintained by the Local Security Authority (LSA). On creation users may attach an ACL to the object. On failure to do this, the system seeks to determine if the object can inherit the directory's ACL. If this is also not possible, the ACL of the processes primary token will be attached to the object [8]. Comparison of the SID within a subject's access token to the objects ACL is performed by the Security Reference Monitor (SRM) when the first attempt to access this object is made. A search within the objects ACL of the ACE containing the SID of the subject is made in a 'first match' fashion. This ensures that if there are any forbidden action which the subject is not allowed to undertake, this is discovered first. The search is terminated when a suitable match is found and if access is granted, a handle to the object is created by the SRM and handed to the subject. Subsequent calls to this object make use of the handle. As inferred from the above sections, a subject can contain several access tokens. One of these access token is known as the impersonation token and it adds the convenience of allowing users to run processes with privileges assigned to other users. [ VMS' access control mechanism is very similar. The major problem with both is that there is a privilege that allows a subject to give itself privileges, which is the analog of a "root" privilege. In Unix, you have one account to protect, but in multi-level privilege systems, you have to audit every means by which a user could gain a privilege; while that can be more secure, it is also harder to manage. {ajax} ] UNIX Access control is implemented in UNIX through the file system. Each file on the system is represented by both an inode (information node) and one or more data blocks. The inode contains information on what permission level is required by a process to gain access to the data block. Information contained within an inode include: * File Owner UID * File Owner GID * File Type - { regular, directory, symbolic link, character device, block device, pipe, socket } * File Access Permissions - { owner, group, other; read, write, execute } * File Access Times - + Last Modified + Last Accesses + Inode Last Modified * File Size - in bytes machid:/home/xploita>ls -l s* -rw-r--r-- 1 xploita users 2570 Jul 9 1999 scan.c -rwxr-xr-x 1 xploita users 6708 Jul 6 1999 self* -rw-r--r-- 1 xploita users 663 Jul 7 1999 self.c -rw-r--r-- 1 xploita users 3360 Aug 20 1999 socket.c Listing 2: A listing of files on a UNIX system displaying the contents of their inodes. Each initiated process in UNIX possesses a pair of effective and real UIDs and GIDs. This allows a user to execute processes while temporarily assuming the permission and authority of another user. This is not as bad as it sounds, in fact it is quite useful. Lets say you run a web server on your machine and this web server is configured to run some CGI scripts. It is preferred not to run these scripts using the same user privileges as the owner of the web server, but to run the scripts using the borrowed privileges of user with much lesser authority. Solaris Solaris is one of the UNIX variants with a substantitive adoption of the use of ACLs. In this implementation, usage is supported in the following files systems: UFS (UNIX File System), NFS (Network File System, Versions 2 and 3), CacheFS (Cache File System), and LOFS (Loopback File System). In these filesystems, ACLs may be applied to files, directories, pipes and symbolic links [7]. On the creation of ACLs for a file, the file's inode is linked to a shadow inode that has the capacity to store ACL information. This link is done by the creation of a pointer in the file inode called i_ufs_acl to link to the shadow inode data structure called the si structure. There is further linkage of additional kernel data structures from the si structure that are used by the kernel for ACLs. inode -------------- ic_acl | i_mode | -->structure | i_size | | ---------- | . | si structure | | *owner --1| ufs_ic_acl | . | --------------- | | *group --2|--> structure | *i_ufs_acl-|-->| *next | | | *other --3| (1,2,3,4,5) -------------- | *s_forw | | | *users --4| ---------------- | s_flags | | | *group --5| | *acl_ic_next---- | s_shadow | | | mask | | mode | | | s_dev | | ---------- | acl_id_who | | | s_signature | | ---------------- | | s_use | | ic_acl | | s_ref | | -->structure ufs_ic_acl | | s_lock | | | ---------- structure <----- | s_a <----------- | | *owner | ---------------- | s_d <--| | | | *group | | *acl_ic_next | ---------|----- | | *other | | mode | | | | *users | | acl_id_who | ----------- | *group | ---------------- | mask | ---------- Listing 3: A visual representation of the Solaris ACL structures [ That is probably one of the best ASCII charts I've ever seen! {kynik} ] The shadow inode structure contains various fields needed by the kernel for its implementation of ACLs. The kernel caches shadow inodes in memory to facilitate access. When an ACL is created for a file, the kernel searches the shadow inode first to determine if a resident shadow inode exists that can be used. If one exists, a link is simply made between this object and the memory resident shadow inode. If none exists the kernel allocates a UFS inode to store the newly created ACL information and points the I_shadow pointer in the files original inode to this. 1 sunsys> getfacl file1 2 # file: file1 3 # owner: jim 4 # group: staff 5 user::rw- 6 user:moe:rw- #effective:r-- 7 group::r-- #effective:r-- 8 mask:r-- 9 other:r-- 10 sunsys> su moe 11 Password: 12 $ id 13 uid=2001(moe) gid=22(stooges) 14 $ echo "write test" >> file1 15 file1: cannot create 16 $ exit 17 sunsys> setfacl -m m:rw- file1 18 sunsys> getfacl file1 19 # file: file1 20 # owner: jim 21 # group: staff 22 user::rw- 23 user:moe:rw- #effective:rw- 24 group::r-- #effective:r-- 25 mask:rw- 26 other:r-- 27 sunsys> su moe 28 Password: 29 $ echo "write test" >> file1 30 $ exit 31 sunsys> Listing 4: ACL information for objects are set in Solaris using the getacl and setacl commands. Outputs of these programs are displayed. [ Sun's Trusted Solaris takes this to the NT/VMS level of having an ACL bound to non-file objects. HP's VirtualVault OS, basically an extended HP-UX, has multi-level priveleges, and also does some funky process partitioning. {ajax} ] Potential Threats: ------------------ Since not all file systems support ACL, operating systems that use ACL have had to find a workaround solution for this problem. In the case of Solaris, any file system that does not support ACLs will only have access to the inode access information stored in the inode of the file. While this is not extremely secure, it is considered sufficient enough as many UNIX implementation rely on this alone. Windows NT on the other hand has a mechanism of providing default ACL to objects. When a device object is first created to represent a file system, the ACL of the device object is set to traverse access for everyone and read/write for administrators. Therefore, when files are created on this file system that cannot store their security descriptor, the access rights of the files are defaulted to that of the operating system thus granting traverse rights to anyone on the system. Windows NT One of the disadvantages of Windows NT usage of the Access Token mechanism is that the access token is created on user authentication and held throughout the life time of the login process. This therefore makes it impossible for any changes made to the users privileges to take effect until the user logs off the system and logs back on (hence causing a new access token to be created). This often causes discontinuity of services when modifications are made to a needed service and it has to be cycled in this way to pick up the changes. Access Control Using Capabilities --------------------------------- Some distributions of UNIX especially of the Linux variant are now in circulation with built in support for capabilities. While ACLs are stored with an object recording who/what has the right to access this objects, capabilities are stored with the object dictating what objects this process has the right to access [2]. Each subject contains a list of capabilities which in turn contain two items: * Object Descriptor - This is an identifier for the object which might include the address of the object or any other unique method of representing the object. * Access Rights - This is the list of access rights which the subject holds for this object. The capabilities list can be looked at as a ticket which is presented to the resource manager whenever a request to access a new resource is made. The resource manager then inspects the ticket and grant the ticket holder the accesses specified. Since capabilities may be embedded inside user programs and data structure, the inspection process should consist of mechanism to ensure that the capabilities presented have not been forged. This methodology is discussed in the designed but unimplemented Extremely Reliable Operating System architecture [10]. [ One of the URLs at the top of this ish contains a link to a capabilities implementation for FreeBSD. {ajax} ] Auditing ======== Windows NT Auditing in Windows NT is handled by the Security Resource Manager, Local Security Authority and the Event Logger. Event to be logged are placed into one of seven types of event groups. These are: * System * Logon/Logoff * Object Access * Privilege Use * Detailed Tracking * Policy Change * Account Management Whenever an event occurs that is to be audited, the LSA determines what is to be audited from the systems Audit Policy and hands this to the SRM to construct the audit record. In some cases, the LSA constructs the audit record. This constructed record is then handed to the Event Logger to commit to disk. The constructed audit record contains the following information [11]: * Date - The date the event occurred. * Time - The (local) time the event occurred. * User - The username of the user on whose behalf the event occurred. This is the client ID if the event was actually caused by a server process, or the primary ID if impersonation is not taking place. Where applicable, a security log entry contains both the primary and impersonation IDs. * Computer - The name of the computer where the event occurred. (Event Viewer can be used to view event logs on other Windows NT computers on a network.) * Event ID - A unique number identifying the particular event type. The first line of the description usually contains the name of the event type. For example, 562 is the ID of the event that occurs when a new object handle is created, and so the first line of the description of such an event is "Handle Allocated." * Source - The name of the system component that actually recorded the event in the security log. Usually, this is Security, indicating that it is the result of Windows NT security auditing. Applications can also define their own auditable events that can be recorded in the security log. * Type - Either Success Audit or Failure Audit, indicating whether the audit is a record of a successful or failed attempt. In Event Viewer's normal list view, these are represented by a key or a lock, respectively. * Category - A classification of the event by the event source. For security audits, this corresponds to one of the event types for which success or failure auditing can be enabled in the User Manager Audit Policy dialog. UNIX There are three (3) main classes of audit logs generated in UNIX systems. These are handled by a combination of frequently used programs, the kernel and daemon processes. These audit classes include [12]: * Connect Time Accounting * Process Accounting * Error and Administrative Logging Connect time accounting is instituted when an attempt is made to connect to the system by a user. Upon successful authentication of the user, entries are made into the wtmp and utmp files by the login program. The locations of these files are often dependent on the UNIX variant being used. The utmp file maintains only a current listing of the users available on the system while the wtmp file tracks when the user logs in and also when the user logs out. This provides a detailed tracking of a users access to the system. Fields collected by the wtmp file includes: * The name of the terminal on which the user is logged in * The name of the user logged in * The name of the remote host from which the user logged in * The time the user logged in or out of the system For systems that support this, process accounting is performed by the UNIX kernel which appends audit logs to the end of the /usr/adm/pacct file on the termination of every process. Logging this information is useful to provide information on which user is running what process and also the duration of time this process is being run. It instantly alerts the system administrator to user s who continuously usurp system resources. Fields stored in the /usr/adm/pacct file includes * Accounting flags that detail if the process ever forked another process and if it ever attained super-user privileges. * Exit status * Accounting UID * Accounting GID * Controlling terminal * Time of invocation * Time spent in user state * Total elapsed time * Average memory usage * Number of characters transferred * Blocks read or written The third class of auditing known as the error and administrative logging is handled by the syslog logging facility which is started during the boot up phase of the system. The logging daemon known as syslogd and accepts audit log messages from processes designed to communicate with it. These messages contain a priority code known as a facility and also the system entity that generated the log entry known as the level. Syslogd depending upon configuration has the ability to append messages to appropriate files, send mail to the system administrator, send output to the system console or send message via the network to another hosts. The configurations for this file is found in the /etc/syslog.conf file. Normally, configuration of this file is based on the facility of the log entry. As noted earlier, this contains the priority code of the log entry. Possible values include: * Emergency - A panic condition. This is normally broadcast to all users. * Alert - A condition that should be corrected immediately, such as a corrupted system database. * Critical - Critical conditions, such as hard device errors * Error - Common errors * Warnings - Warning messages. * Notices - Conditions that are not error conditions, but that may require special handling. * Info - Informational messages. * Debug - Messages that contain information normally of use only when debugging a program Summary ======= Operating System developers are faced with many issues during the design of the system with security being only one of these. Hence a feature could be introduced which heavily jeopardizes security this feature could provide some enhancement in other areas of the system. Hence it is imperative the system administrators do not rely on default system configurations. Hopefully, this document has helped in understanding the implementation of many resource protection features such that you could tighten the security of your system within crippling any useful features. Or better yet, it has helped you discover how to defeat protection mechanisms in use by comparable systems. Footnotes: --------- (!) A domain is a group of one or more NT computers which are connected together and which share a common security accounts manager (SAM) database and a common security policy. (@) Hashes are the result of the application of 'one way' functions to a value. These functions are such that they are easy to compute but very difficult to reverse to their original form. (#) MD4 is a one way hash function developed by RSA Inc. ($) L0phtCrack is a copyright of Lopht Heavy Industries and was developed and is marketed by the same aforementioned entity. (%) DES is the popular encryption standard used and supported by the National Bureau of standards. (^) Kerberos is an authentication mechanism developed at the Massachussets institute of Technology Terminology ----------- ADS Active Directory Service ACE Access Control Entry ACL Access Control List CacheFS Cache File System CGI Common Gateway Interface CPU Central Processing Unit DEA Data Encryption Algorithm DES Data Encryption Standard GID Group IDentifier IPC InterProcess Communication LSA Local Security Authority LAN Local Area Network LOFS Loopback File System NFS Network File System NT New Technology NTFS NT File System PAM Pluggable Authentication Module SAM Security Accounts MAnager SID Security Identifier SRM Security Resource Manager SSH Secure Shell URL Universal Resource Locator UFS UNIX File System UID User Identifier WWW World Wide Web Web Resources ------------- This is a list of URLs for web resources found to be useful for this paper. http://www.ntsecurity.net http://www.securityfocus.com http://www.l0pht.com http://www.cultdeadcow.com http://www.ssh.fi http://www.microsoft.com http://www.artstechnica.com http://www.ntbugtraq.com References ---------- [1] Charles Crowley, Operating Systems: A Design Oriented Approach. Time Mirror Higher Education Group, 1997. [2] Mukesh Singhal & Niranjan Shivaratri, Advanced Concepts in Operating Systems. McGraw Hill, 1994. [3] Hans Hedbom, Stefan Lindskog, Stefan Axelsson & Erland Jonsson, A Comparison of the Security of Windows NT and UNIX, October, 1998. [4] David Corcoran, Introduction to Authentication, May 2000. [5] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne & S. Lehtinen, INTERNET DRAFT, SSH Protocol Architecture, June 1999. [6] Frank O'Dwyer, Ensuring Password Quality on NT networks, April, 1999. [7] Jim Mauro, Controlling Permissions with ACL, Sun World. March, 2000. [8] Hans Hedbom, Stefan Lindskog, Stefan Axelsson & Erland Jonsson, Analysis of the security of Windows NT, March, 1999. [9] Jeffrey M. Richter, Creating, Managing and Destroying Processes and Threads under Windows NT. Microsoft Systems Journal, Volume 8, Number 7, pp: 55-76, July, 1993. [10] Jonathann Stauss Shapiro, EROS: A Capability System. March, 1999. [11] NCSC, FINAL EVALUATION REPORT. Microsoft Inc: Windows NT Workstation and Server Version 3.5 with U.S. Service Pack 3. National Computer Security Center, 1996. [12] Stefan Axelsson, Ulf Lindquist, ulf Gustafson, Erland Jonsson, An Approach to UNIX Security Logging, 1998 [ You forgot the kitchen sink, xploita! Just kidding, this is a damn good article! {kynik} ] ___________________________________ ----------------------- - c_routine [=] 0x06: Music Reviews Album Review: Rancid - Self-Titled (2000) c_routine routine@gh0st.net East Bay punk band Rancid came out with their new album August 1st, on their own record label, Hellcat records (http://www.hell-cat.com/). This album is less ska-influenced and much more oi! and 77 influenced than their previous three albums. Only a band like Rancid could put out an artsy, dub/raggae-influenced album like "Life won't Wait" and turn around and kick us all in the balls with their latest fare. This album is a throwback in spirit to their very first album, back in 1993, also self-titled. From the hard-grinding guitar riffs of 'Axiom' and 'Not to Regret' to the screaming lyrics of 'Dead Bodies' to their trade-off lyrical switch in songs like 'Disgruntled' and 'Corruption', Rancid delivers a solid ass kicking. It's nice to hear Matt Freeman's vocals again even though I'm not a big fan of his singing. This marks the first time he's sang lead vocals on a song since 1993. He's easily one of the best bass players in punk rock; the bass prodigy behind operation ivy, a classically trained cellist, and the anchor responsible for starting Rancid to help get lead singer Tim Armstrong out of alcoholism. Every song on this album is quite good. Rancid said that most songs on this album were recorded on their first take and if you've ever seen them live, you wouldn't doubt it. This is one of the punkest new albums I've heard in 2 years. Go to your downtown corporate mega-store and steal it. cheers, routine@gh0st.net [ Not long ago, I took routine's advice and picked up this CD. It's everything he says it is. {kynik} ] ____________________ ----------------- - [=] 0x07: Credits Editor: Kynik Co-Editor: ajax Article Contributions: echo8 _azure xploita Music Reviews: c_routine 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 .n7! - eof