Custom Search
By Keith Siilats, Thursday, July 13, 2000, Version 2.
1. Users enter information in a format they are supposed to
a. Password crackers
b. Password sharing ("pass sites")
c. Restricting administrative access in case password becomes known.
2. Users enter information not in a format they are supposed to
a. Sql strings
b. Includes
c. Executing code on the server
d. Session snooping
e. Cookie snooping
f. Cross site scripting
g. URL guessing
h. Unneeded Scripts in FrontPage extensions etc.
i. FileOpen calls in perl with URL parameters
3. Server vulnerability in software independent of xxx.com written software.
a. Denial of service
b. NT vulnerabilities
c. IIS vulnerabilities
d. Websphere vulnerabilities
e. New security bulletins left unimplemented
f. Unneeded ports open in firewall
g. War dialers
4. Social engineering
a. Email forging
b. Stealing of information by former and present employers
c. Physical access
5. Preventive methodologies
a. Monitoring users
b. Monitoring performance
6. Abuse methodologies
a. Do we want to employ people to hack into competitor.com?
The new toolbar architecture is ideally suited for securing every single page against the first two problem groups - exploitable code in our own applications combined with a malicious user.
The third and fourth security issues require co-operation of the network administrator and an appropriate policy defined at the corporate level.
1. Passwords
Problems:
a. weak passwords
b. no counting of retrial attempts
Solution:
a. single login stored procedure called pLogin (on dev/Blah sql server at the moment)
b. a table for storing failed login attempts and the time
c. a select statement
select @Attempts=count(*) from UserLogin where datediff(h,Date,getdate())<2
if @Attempts>50 return 0
d. in the stored procedure if @len(password)<4 or search(@username,@password)>0 return 0
e. log the IP of every user, and the username and do
select @Attempts=count(IP) from Log where username=@username and Date=today()
inside the pLogin procedure. This will eliminate password sharing.
Related issue is the restricting of password. There should be a firewall in place that does not allow NetBios (port 139 and 138) through. SQL servers should use named pipes only and should only use Trusted Authentication to be accessible from ASP and JSP (confirm with sysadmin and configure)
2. Direct SQL strings.
Present: asp pages have SQL embedded in them with strings from request object concatenated to them.
Problem: It is very hard to escape the SQL string against all possible malicious code attempts.
Example: rs.open "select * from members where mem_user_id='" & request("username")
What if I submit ';dump Xxx; select ' as my username?
Update: there is a procedure called xp_cmdshell so stuff like
';xp_cmdshell 'del c:\*.*'; select '
works. As an immediate measure, I have created a user identical to sa called dbowner, that logs in from asp pages, that does not have this right.
Solution:
Quick: select * from members where mem_user_id='" & server.urlencode(request("username"))
By no means should people be writing their own escape function.
This will work for string data inside ' symbols, however, not for numeric ID data as "union" operator could be used.
Proper: all pages should pass all form variables that are required into a stored procedure. This will also facilitate logging and will separate business logic from presentation and will allow smooth transition to jsp-s. There is no union problem.
Scope: about 20 files are affected, anyone can delete our whole database by just typing
%'; dump Blah; select '
into almost any form.
About 10 stored procedures need to be created. This is a well known and a high priority security risk.
This problem is a lot wider including | problem, dts scripting, linked server and other issues. They are all eliminated by the use of stored procedures.
3. Includes
Problem: When printing variables submitted by users back to the users (like Hello Keith Siilats) instead of Keith Siilats users can enter their name as <!-include file="c:\windows\system32\backup\sam"--> to get the administrator password.
Scope: IIS does not allow dynamic includes nor does jsp. So unless we are using perl or schell scripts somewhere, we do not have a problem.
4. Executing code on the server
Sometimes parameters have to be passed on to external programs running on the server. One of them is the document center. Including & sign into the program name can trick the operating system into running arbitrary code on that server.
Scope: Document center. Problem is very unlikely.
Difficulty: This exploit is extremely hard to use and extremely hard to test against. Brief review of the java code should reveal 95% and the vendor should be responsible if their server can be tricked to execute.
5. Session snooping
Problem: Sessions are determined by a cookie called ASPID. Proxy servers or people with access to clients computer can reveal that and take over the session.
Scope: We use sessions.
Severity: Only one user at the time can be compromised and we cannot really prevent them writing their password on a PostIt note above the monitor.
Solution: We are logging the IP and will check if it has changed more than x times during the session, to prevent more widespread abuse in case of discovery. SSL with client certificates should also be implemented for critical things.
6. Cookie snooping
Problem: We are storing user info in persistent cookies in the computer without encryption. Users do not have a choice in allowing the cookies.
Scope: Only one user at a time can be compromised.
Solution: Implement in ASP a checkbox "remember me" so that users can determine if they are using a secured computer. Store the ID of the user only, a different one to what gets used in a session object. Track IP addresses so that widespread abuse is prevented.
7. Cross site scripting
Problem: If people submit something that can be viewed by other people they can
Scope: Exchange and others. Very severe as automatic tools have been developed for exploit.
Solution: Server.htmlencode(string) everywhere and stored procedures. Extremely unreliable solution. QA testers should try submitting ‘test into all forms. Microsoft DTC would be the recommended solution, but company policy is not to use it.
8. URL guessing
Problem: People can type in a URL to a members only page and view it
Scope: Severe, there are thank you pages etc. that do not test for Session("user_id"), the current method.
Solution: A nice clean 4 lines of code in toolbar.asp that makes all files in general available to users and requests a valid user_id for others without any programmers intervention.
Related problem: Shippers can view information for forwarders
Solution: Determine the severity from Business side, if severe, make special folder where only files accessible for that group go. Unix like permission system where a new folder is created for every useful group (ie Forwarders and Shippers but not carriers). Will confuse things so avoid if possible.
Related problem: Administration pages, when we have them
Solution: Implement SSL and NTLM authentication.
9. Unneeded Scripts
They exist at the moment and will be deleted. This includes example files on websphere and example databases on production servers.
10. Server vulnerability
Should be delegated to a system administrator who should make sure RAS users have strong password and that he receives and implements the security bulletins from www.microsoft.com/security on weekly basis.
11. Social engineering
Somebody can send an email pretending to be me, like:
Mail from: [email protected]
Subject: urgent
Body: Please push your screen to this IP so that I can fix a toolbar problem
And then take control of the xxx.com network.
Solution:
Add a line to all messages coming from outside our internal network saying "This message is not sent from a server trusted by xxx.com"
Use aol instant messenger. www.siilats.com/rf for installation.
Use pgpi and public signatures if necessary. www.pgpi.com
12. Preventive methologies
This prevents against denial of service.
Logging is trivial when we use stored procedures. I have written a nice normalized structure allowing new stored procedures to be added already. We require the session("user_id") and existing application id to be submitted with each stored procedure to allow path mapping.
For performance, we need independent computers, one in USA and one in Russia running a bot that checks a couple of ASP pages that will just return the time of the day from the database or an error message. The error message should be emailed if repeated for more than 5 minutes and should be logged otherwise.