Stephen Smith's Blog

Sage ERP Accpac 6.0A comes with a new Web Portal (http://smist08.wordpress.com/2009/12/03/the-sage-erp-accpac-6-0a-portal/) along with Web based screen integration to SageCRM (http://smist08.wordpress.com/2009/12/17/sage-erp-accpac-6-0-quote-to-orders/). A common question is how I set this up in a secure manner so that these new features won’t be exploited by hackers.

Most people will probably just setup Accpac 6.0 and/or SageCRM running on their local network. If you don’t expose the web server to the internet, then your security concerns are the same as they are today. You are just regulating what bits of information your local users are allowed to see. Generally (hopefully) you aren’t as worried about your own employees hacking your network. The big concern for security here is usually social engineering (http://en.wikipedia.org/wiki/Social_engineering_(security)) which really requires good education to prevent. Note however that we have seen sites where people have added Internet access for all their employees, but unwittingly exposed their network to the Internet. It’s never a bad time to re-evaluate your current security to see if there are any weaknesses.

For Sage ERP Accpac 6 we’ve taken security very seriously and are involving security consideration into all parts of our Software Development Methodology. Additionally we commissioned a third party security audit of our product. From this audit we then made a number of changes to tighten up our security further. This way we’ve been looking for and being careful about SQL Injection attacks (http://en.wikipedia.org/wiki/SQL_injection) and cross site scripting attacks (http://en.wikipedia.org/wiki/Cross-site_scripting), among others.

For any site you should do some sort of threat risk modeling perhaps like: http://www.owasp.org/index.php/Threat_Risk_Modeling. Generally this sort of exercise gets you thinking about what you are trying to protect and what the possible threats are. Even if you do something simple like:

• Identify bad guys – young hackers, disgruntled ex-employees, competitors, etc.
• Identify assets – databases that you want protected, servers that should be secure, etc.
• Identify risks – having your data stolen, having your website vandalized, having your data modified.

Then you can develop plans to protect your assets and to watch for your adversaries.

A lot of security isn’t a matter of being perfect, just being better than others. This way hackers will come across your web site, quickly see it has security in place and then move on to easier targets. Hackers tend to employ automated scripted scanning tools to search the Internet for unprotected servers (http://en.wikipedia.org/wiki/Port_scanner), just starting by being HTTPS and not having any other ports open, sets the bar quite high for hackers and the scanning tool will keep scanning.

Nmap/Zenmap

When you expose a web server to the Internet, your first line of defense is the firewall. The firewall’s job is to hide all the internally running processes from the Internet, such as SQL Server or Windows Networking. Basically you want to ensure that the only things people can access from the outside are HTTP and HTTPS (these are ports 80 and 443 respectively). This way the only things a hacker can attack are these ports. Generally hackers are looking for other ports that have been left open for convenience like RDP or SQL Server and then will try to attack these.

A great tool to test if any ports have been left open is Nmap/Zenmap (http://www.nmap.org/). You run this tool from outside your network (perhaps from home) to see what ports are visible to the Internet. Below is a screen shot of running this tool against www.yahoo.com. We see that ports 80 and 443 are open as expected but so are ports 25 and 53 (which are for email authentication and DNS). Since there are 4 ports, as a hacker if I have an exploit for any one of these I can give it a try. Obviously the fewer ports open, the better. Ideally only port 443 for HTTPS (though port 80 is often left open to give a better error message to use HTTPS or to redirect people to HTTPS automatically).

It is well worth running Nmap so you don’t have any surprises, especially since configuring firewalls can be complicated.

HTTPS

Now with your site protected so the only thing that can be attacked is the web site, we need to ensure it is only accessed in a secure manner. As a first step we only access it through HTTPS. This encrypts all communications, ensuring privacy and validates that users are talking to the right server avoiding man-in-the-middle attacks (http://en.wikipedia.org/wiki/Man-in-the-middle_attack).

To turn on HTTPS you need a server digital certificate. If you already have one, then great you are all set. If you don’t have one then you can purchase one from companies like VeriSign (http://www.verisign.com/).

To turn on HTTP for a web site in IIS, go to the IIS management console, select the “Default Web Site” and choose “Bindings…” from the right hand side. Then add a binding for https, at this point you need to reference you digital certificate for your server.

As a further step, you should now choose “SSL Settings” in the middle panel and check the “Requre SSL” checkbox. This will cause IIS to reject an HTTP:// requests and only accept HTTPS:// ones.

Other IIS Settings

If you browse the Internet there are many other recommended IIS settings, but generally Microsoft has done some good work making the defaults good. For instance by default virtual directories are read-only so you don’t need to set that. Also remember that Accpac doesn’t store any valuable data in IIS, Accpac only stores some bitmaps, style sheets and static html files here. So if someone “steals” the files in IIS, it doesn’t really matter, this isn’t where your valuable accounting data is stored. We just want to ensure someone can’t vandalize your web site by uploading additional content or replacing what you have there. The valuable data is stored in the database and only accessible through Tomcat, not directly from IIS.

Database Setup

The new Web Portal honors the security settings, set from the Security button in Database Setup. These should be set according to the screen shot below. The most important setting is to disable a user account after x failed password attempts. This prevents automated programs from being able to try every possible password and eventually guessing the correct one. With the settings below and automated program can only try 3 passwords every 30 minutes which will usually get the hacker to move on to find a less secure site to try to hack.

Vigilance

It is generally good practice to remain vigilant. Every now and then review the logs collected by IIS to see if there is a lot of strange activity, like strange looking URLs or login attempts being aimed at your server. If there is, chances are you are being attacked or probed and want to keep an eye on it. If it is very persistent you might want to work with your ISP or configure your Firewall to block the offending incoming IP addresses entirely.

Summary

The important steps are to:

• Configure IIS for HTTPS (SSL).
• Disable HTTP (require SSL).
• Set more stringent security restrictions in Database Setup
• Do an NMap port scan of your server.

Plus follow normal good IT practices like applying Windows Updates and not running services you don’t need. Practices you should follow whether running a web site or not. Then keep an eye on the IIS logs to see if you are being probed or attacked.

These steps should keep your data and your server safe.

With version 6, Accpac will still be an on-premise deployed application. Even though Accpac will now be a Web Based application, customers can still deploy it on their LAN and do not need to expose the Accpac application to the greater World Wide Web. By not exposing the application to the Web and keeping it all behind a firewall and/or DMZ, their data will be very safe.

However more adventurous customers will want to expose Accpac to the Web. They will want employees to be able to login from home, airports, hotels or on the road. Probably from places (like many Hotels) where VPN is blocked by a local firewall. They will want their data just as safe as before, but much more accessible. For these customers especially, but really all customers, we have to do extensive security testing of Accpac to make sure their data is safe. Generally for security we want to ensure the service is available, all transactions are confidential and that the transactions can’t be tampered with.

Accpac will be setup to do all communications through a secure connection called Transport Layer Security (TLS) (previously called Secure Socket Layer (SSL)). This is a very secure method to protect the communication between two computers. It will prevent people spying on the network from reading the information or tampering with the information that is transmitted on the network. It also provides a high level of authentication so you know who you are talking to. This does mean that customers will need to purchase a server digital certificate so that remote clients can ensure they are communicating with the correct service and that an intermediary hasn’t been installed in-between (man in the middle attack).

TLS does not protect the Browser memory or the Browser User Interface. Malicious web pages may be able to steal data from our user interface forms (cross site scripting attacks (XSS)). Bad user input may be able to cause bad side affects by interfering with our business logic (SQL Injection attacks). We have to test our software to ensure the browser side of our web pages are secure and that malicious user input is caught and dealt with.

There are attacks that are outside the scope of our application. If customers don’t follow good practices for maintaining and configuring their servers, then perhaps they can be attacked independently of Accpac. If the customer has malware like a keystroke logger program installed (perhaps by a virus) on their computer, then that program can steal their passwords. These are threats even today with desktop applications. Hence the importance of corporate security practices, like virus checkers and reduced privilege users.

A form of attack that technology can’t solve is “social engineering” attacks. Say someone phoning a customer and persuading them they are the support department and need the customer’s password for some reason. These types of attacks are usually the easiest and most successful. Some sort of awareness training is required for employees to be aware of these and to know to never give out sensitive information like their password over the phone, or via any other means.

Other attacks aren’t intended to steal anything, but to just take your system down. These are denial of service attacks. A hacker could say setup hundreds of computers (real or virtual) to make invalid login requests to your web server. None would ever succeed, but the load of rejecting these, could make your system unusably slow. Or perhaps they can find a way to crash your web server or application. Then the hacker could blackmail you, so he’ll stop. Or maybe he doesn’t care, and is only just doing it because he can. Or maybe a competitor is trying to put you out of business. These are certainly very serious attacks that must be guarded against.

Security testing is fun, because the testers become hackers and have to find ways to break into the software. They get to use new techniques like fuzz testing to find problems (http://www.owasp.org/index.php/Category:OWASP_JBroFuzz). They get to study criminals to learn their techniques to ensure we are safe from them. Security tends to be a journey; hackers are always inventing new techniques to gain access. Often testers will use “hacker” tools downloaded from the Internet to ensure they can’t be used to compromise our application. The tester study the traffic on the wire with tools like WireShark (http://www.wireshark.org/) to study all the packets on the network. There are many tools to scan your application and server for vulnerabilities. Source code has to be reviewed and tested to ensure clever user input can’t cause problems from things like SQL Injection attacks (http://en.wikipedia.org/wiki/SQL_injection).

Generally we want to ensure that when installed properly on a Web Server using TLS that Accpac is a very hard to crack application. We will need to publish best practices for installing and configuring servers. Generally newer server operating systems turn everything off by default so there isn’t much for hackers to latch onto. Mainly its up to the operators to ensure only a minimum of services are installed, that all patches are installed and to monitor the server logs for strange activity. Hopefully this will mean making Accpac available to remote Web users will be fairly easy and safe. But as always with security it always pays to be vigilant.

I bought Bruce Schneier’s boxed set of three books: “Applied Cryptography”, “Practical Cryptography” and “Secrets and Lies”. Hopefully reading all this will make me sufficiently paranoid to deal with the security threats we’ll be facing as we move into the SaaS world. Bruce says that originally when he wrote “Applied Cryptography” he thought all the security problems on the Internet could be solved by Mathematics. That a few powerful cryptographic algorithms would solve all the security problems out there. He now realizes that this isn’t the case. That there are so many other weak links to be exploited, like bad implementations, lack of vigilance, human error, etc. In fact many people feel that if they are connected to a web site via SSL or TLS that they are fully secure. However this just isn’t the case.

SSL and TLS only protect the connection between the client computer and the server. They don’t protect the client computer. They don’t secure or encrypt data stored in the Browser’s memory. They don’t force you to use secure passwords. They don’t force you to check the validity of the root certificate authority used by a server. They don’t force you to use the maximum encryption settings possible. They don’t force you to run anti virus and spybot software.

Generally the security business is described as a “Red Queen’s Race”. This means the people trying to protect systems are running harder and harder just to stay in the same place. It seems the advances made by hackers are very impressive. Even now that most crytographic algorithm’s patents have expired and governments aren’t trying to supress them anymore as military secrets, that it will take much more than mathematics to provide a secure Internet.

Another point he makes is that it is possible to create a secure operating system. But since there is no liability to software vendors when break-ins occur, that there is no real motivation for anyone to make a more secure operating system. For instance it would cost Microsoft billions to really address the problems in Windows, but since there isn’t any liability, besides a bit of bad press, why would they? As it is they are content just to spend a bit of time releasing Windows Updates they discover holes found by hackers. But what about all the holes that hacker’s have found and not told them about?

But in spite of all the negativity, it is possible to create a reasonably secure system (ie secure enough that hackers will look elsewhere for easier targets). With a reasonable amount of vigilance, following of best practices and intelligence, you can run a secure system. But you have to stay alert and not believe that SSL and a firewall are all protecting.

In the good old days, database APIs separated the commands from the data, so usually you passed in a command like update or read to one parameter and the data to update or read in a separate parameter as a data buffer. In this case the data wouldn’t interfere with the commands or cause any sort of code execution.

Now in the brave new world (well not that new really), data is mixed with commands in the form of SQL statements that are passed to the database as a single string containing both the data and the command, like “SELECT * FROM ARCUS WHERE IDCUS = 1200 AND SWACT = 1″. Now if the data is manipulated by hackers they can insert additional commands to be executed.  For instance in the string before what if the use typed “1200 OR 1=1″, then it would return data for all customers. To avoid this you put the data in quotes like “IDCUS = ’1200′. But then what if quotes are in the string? The solution is to “escape” them. For SQL this means doubling them up, ie changing ‘ to ”.

Theoretically this should make the SQL statement secure. However there are some subtle points, such as if the string is all single quotes then you need a buffer twice the size of the original to handle the data. What about leading and trailing spaces, how should these be handled? Is escaping single quotes sufficient? Are there other “special” characters that need to be dealt with?

Generally if you know your database you can handle this easily. However a gotcha can happen if you change databases. For instance the scheme above works fine for SQL Server and TSQL, but if you switch to MySQL, it becomes inadequate because \ is a valid escape character. So if the user enters \’, it gets changed to \” which now leaves one unquoted quote for hackers to maliciously use.

Besides user data causing invalid SQL statements, hackers can exploit these problems to find ways to execute extra code. If you can close the quote then the can add any SQL command they like, resulting in a SQL Injection attack.

Anyway it adds to the consequences of getting it wrong. Some databases provide routines to safely quote strings in their APIs. Its best to use these, since the database vendor should know all the ways to escape characters (documented or not) and hopefully these routines have been well tested (including by white hat hackers).

As we develop the web based version of Accpac, we are having to develop a lot of knowledge about hacking and web based security exploits. Learning about these things is very interesting but also very eye opening and scary. Once you expose your application to the web you are definitely in a different world.

We currently offer an on-line version of Accpac through www.accpaconline.com, but here we are using citrix server and relying on Citrix and Microsoft to protect us. You first have to login to a Windows domain and then these services provide the secure connection. Of course we do have to be vigilant and make sure all security patches are installed promptly. We also have to keep auditing our server configurations to ensure they are secure. We have to ensure there are the minimum services running that can be exploited. We have to ensure that a pissed off user can only damage their own data and things of that nature.

Once we leave the comfort of the Citrix/Windows Domain world and expose our log-in page as the first line of defense, then we are in a very different world. We now take on responsibility for new level of security, where all the previous threats still exist, but now there are a great many more. It will be the hacker living in their parents basement patiently staying up all night trying to get past our login screen; patiently probing and trying to find any crack that can be exploited; putting together many disparate bits of information to learn how to get past our security.

We need to now deal directly with denial of service (DoS), sql injection, cross site scripting (XSS) and many other forms of attack. We have to train our QA department how to be hackers. How to think like hackers and how to probe our software to find these cracks before the black hat hackers do. Our programmers have to be vigilant in everything they do, about what are the security concerns.

Certainly this is going to be a very challenging journey, but a very rewarding journey. The challenges are very unique and interesting. It certainly adds an extra dimension to software development, beyond just getting the functionality correct (challenging enough), but to be correct and secure.