Stephen Smith's Blog

Musings on Machine Learning…

Archive for the ‘Security’ Category

The Technology of “Influence” – Part 2 VPN

leave a comment »

Introduction

In my novel “Influence”, the lead character J@ck Tr@de performs various hacking tasks. In the book he spends a lot of time securing his connections, hiding his identity and hiding his location. In a series of blog posts, I’m going to talk about the various technologies mentioned in the book like VPN, the Onion Browser, Kali Linux and using VHF radios. I talked about HTTPS in my last post and in this article, we’re going to discuss Virtual Private Networks (VPNs).

For anyone interested, my book is available either as a paperback or as a Kindle download on Amazon.com:

Paperback – https://www.amazon.com/dp/1730927661
Kindle – https://www.amazon.com/dp/B07L477CF6

What is a VPN?

We talked about HTTPS last time as a way to secure the communications protocol that a Browser uses to talk to a Web Server. Now consider a corporate network. People at work have their computers hooked directly into the corporate network. They use this to access email, various internal corporate websites, shared network drives and other centrally deployed applications. All of these services have their own network protocols all different than HTTP. Some of these protocols have secure variants, some don’t. Some have heavy security, some light security. Now suppose you want to access these from home or from a hotel while on a business trip? You certainly can’t just do this over the Internet, because its a public network and anyone can see what you are doing. You need a way to secure all these protocols. This is the job of VPN. When you activate VPN on your laptop, it creates a secure tunnel from your laptop through the Internet to a server in your secure corporate data center. The security mechanisms VPN uses are largely the same as HTTPS and pretty secure. Using VPN then allows you to work securely from home or from remote locations while travelling.

Why Would J@ck Use VPN?

J@ck Tr@de doesn’t work for a corporation. Why does he use VPN? Whose VPN does he use? In the example above, if I’m connected to my corporate VPN, all my network traffic is tunnelled through the VPN to the corporate server. So if I browse the Internet while connected to VPN, my HTTPS requests are sent to the corporate server and then it sends them to the Internet. This extra step slows things down, but it has an interesting side-effect. If I’m not signed into Google and I Google something, Google will see my Internet Address as the corporate server rather than my laptop. That means Google won’t know who I am exactly. It also means my location shows up as the location of the corporate server. This then hides both my location and my identity, things J@ck is very interested in doing.

But J@ck doesn’t work for a corporation? Whose VPN does he use? This “feature” of hiding identity and location is sufficiently valuable that people like J@ck will pay for it. This has resulted in companies setting up VPNs just for this purpose. Their VPN server doesn’t connect to other corporate network programs, only the Internet. Using one of these VPN services will help hide your identity and location, or at least websites can’t determine these from the address fields in your web network packets.

VPNs are popular with non-hackers as well to get at geographically locked content. For instance if you live in Canada, then the content you can get from Netflix is different than the content you get in the USA. But if you are in Canada and connect to a US based VPN server then Netflix will see you as being located in the USA and will give you the US content while you are connected.

Downsides of VPN

Sounds good, so what’s the catch? One is that since these are usually paid services, so you need to pay a monthly fee. Further, you need to authenticate to the VPN service so they know who you are. The VPN knows your IP address so it can trace who and where you are.

So do you trust your VPN? Here you have to be careful. If the VPN provider is located in the USA, then its subject to the Patriot Act and law enforcement can get ahold of their info. If you want US Netflix content, then you have to use an US based VPN, but at the same time US law enforcement really doesn’t care that much about the vagaries of what Netflix allows where. If you are a hacker then you really care and probably want to use a VPN in a country with some protections. For instance in Europe, getting a warrant for this is very difficult. Or perhaps use a VPN in the Caribbean that tend to ignore external law enforcement agencies requests. A bit of Googling can help here. Some hackers use a two or three VPNs at once, located in wildly different jurisdictions to make it even harder to be traced.

Internet bandwidth is expensive, so feeding streaming movies through a VPN can require their delux expensive plan. Doing little bits of hacking doesn’t require that much bandwidth so can be a little cheaper.

There are free VPNs, but most of these are considered rather suspect since they must be supporting themselves somehow, perhaps by selling secrets. VPNs are illegal in some countries like Iraq or North Korea. VPNs are required to be run by the government in other countries like China and Russia. So be wary of these.

Summary

VPNs are a way to secure your general Internet communications. They have the desirable side-effect of hiding your Internet address and location. VPNs are absolutely necessary for corporate security and useful enough that lots of other people use them as well,

Notice that J@ck doesn’t just rely on an VPN by itself, rather its one layer in a series of protections to ensure his anonymity and privacy.

Advertisements

Written by smist08

December 13, 2018 at 12:34 am

The Technology of “Influence” – Part 1 HTTPS

with one comment

Introduction

In my novel “Influence”, the lead character J@ck Tr@de performs various hacking tasks. In the book he spends a lot of time securing his connections, hiding his identity and hiding his location. In a series of blog posts, I’m going to talk about the various technologies mentioned in the book like VPN, the Onion Browser, Kali Linux and using VHF radios. But first I need to talk about HTTPS which is the normal Internet security mechanism we all use to secure our bank and shopping transactions. I’ll look at what this does protect and what it doesn’t protect. Once we understand the limitations of HTTPS, we can go on to look at why J@ck goes to so much trouble to add so many extra levels of security and misdirection.

For anyone interested, my book is available either as a paperback or as a Kindle download on Amazon.com:

Paperback – https://www.amazon.com/dp/1730927661
Kindle – https://www.amazon.com/dp/B07L477CF6

What is HTTPS?

The communications protocol that Browsers use to communicate with Web servers is called HTTP (HyperText Transfer Protocol). This is the protocol that gets data for websites and downloads it to your browser to be displayed. The S added is for Secure and makes this process secure by encrypting the communications. In the early days of the Web doing all this encrypting/decrypting was expensive both for typical personal computers of the day and for web sites that have quite a high volume of traffic. These days computers are more powerful and can handle this encryption easily, and due to the prevalence of hackers and scammers, the current tendency is to just encrypt all Internet traffic. In fact most modern browsers will not let you use plain old HTTP and require the S for security.

HTTPS is actually quite secure. It is very difficult to decrypt with modern computer resources (even cloud based). It authenticates the server via a digital certificate which is provided by a certificate authority that validates the identity of who has the certificate. The protocol protects against man-in-the-middle attacks where someone impersonates one party and relays the information. It protects against data being tampered with in any way.

Sounds pretty good, and in fact it is pretty good. So why does J@ck feel a need to use VPNs or use the Tor network via the Onion Browser?

Weaknesses of HTTPS

J@ck’s main complaint is that: who he talks to knows who he is and what he is doing. For instance, all Google searches go through HTTPS, so no one can eavesdrop on what you are searching for. But, Google knows. Google logs all your searches and builds a detailed profile of you. Further Google is an American company and subject to the Patriot Act and other government programs to hand over your data if requested. Hence if, say you are Googling on hacking techniques, Google could turn that over to the FBI along with your IP address. Then the FBI can ask your ISP who owns this IP address and identify you and come to your door to ask you some questions. Of course if you are signed into your Google account, then they don’t need to bother with the IP address lookup. J@ck certainly doesn’t want that to happen.

HTTPS has some other weaknesses as well. The process of granting authentication certificates isn’t perfect. One of the most common Windows Updates is to alter the list of trusted certificate authorities, since they are often caught handing out fake certificates to shady operators. Along the same lines, most people don’t check the certificate of who they are talking to. This is how most phishing emails work. They send and email asking you to check your bank account, with a link that is similar to your banks, but not the same. The fake link goes to a page that looks like your bank’s login page, but it isn’t. If you click on the certificate icon in your browser you will see the certificate that that it isn’t your banks. But who does this? If you type in your username and password to this site, the bad actors can then use it to login to your real bank account and steal your money.

Hackers can learn a bit about the content of HTTPS traffic even though its encrypted. Perhaps the URI by comparing the lengths of the strings.

Another worry is that often more companies can see your data than you might think. For instance if you are talking to your bank, then you certainly expect you bank can understand your data. However your bank might use a third party web hosting company to host the web site and then that company can also see your data. Then the web hosting company might host the site on a cloud provider like AWS or Azure and then that group might be able to see your data. Then often websites protect themselves against DDoS attacks using a service like CloudFlare and part of that setup lets CloudFlare see the unencrypted data. So suddenly you aren’t just trusting one company, but four companies. This then provide many more vectors of attack and vulnerable points for hackers. Plus the bank might have hired outsourced programming to set up their website, and those contractors have enough credentials to see unencrypted data. These are actually the main causes for all the security breaches you read about at large Internet sites.

Summary

HTTPS is a pretty good way to secure Internet traffic and if you follow some basic good practices you should be ok. For instance never use a link in an email. Always goto the website through another means (like a favorite or use Google). For data you really care about, like your bank account, only access it from a network you trust, not the Wifi at a hotel or coffee shop.

Now that we understand the strength and weaknesses of HTTPS we can look at the extra layers that J@ck uses to stay anonymous and secure.

Written by smist08

December 11, 2018 at 2:33 am

Posted in Security, Writing

Tagged with , ,

Kali Linux on the Raspberry Pi

leave a comment »

Introduction

Raspbian is the main operating system for the Raspberry Pi, but there are quite a few alternatives. Raspbian is based on Debian Linux and there has been a good uptake on the Raspberry Pi which means that most Linux applications have ARM compiled packages available through the Debian APT package manager. As a consequence it’s quite easy to create a Raspberry Pi Linux distribution, so there are quite a few of them. Kali Linux is a specialist distribution that is oriented to hackers (both black and white hat). It comes with a large number of hacking tools for gaining access to networks, compromising computers, spying on communications and other fun things. One cool thing is that Kali Linux has a stripped down version for the Raspberry Pi that is oriented towards a number of specialized purposes. However with the apt-get package manager you can add pretty well anything that has been left out.

If you watch the TV show Mr. Robot (highly recommended) then you might notice that all the cool in-the-know people are running Kali Linux. If you want to get a taste of what it’s all about and you have a Raspberry Pi then all you need is a free micro-SD card to give it a try.

Are You a Black or White Hat?

If you are a black hat hacker looking to infiltrate or damage another computer system, then you probably aren’t reading this blog. Instead you are somewhere on the darknet reading much more malicious articles than this one. This article is oriented more to white hat hackers or to system administrators looking to secure their computing resources. The reason it’s important for system administrators to know about this stuff is that they need to know what they are really protecting against. Hackers are very clever and are always coming up with new hacks and techniques. So it’s important for the good guys to know a bit about how hackers think and to have defenses and protections against the imaginative attacks that might come their way. This now includes the things the bad guys might try to do with a Raspberry Pi.

Anyone that is responsible for securing a network or computer has to test their security and certainly one easy way to get started is to hit it with all the exploit tools included with Kali Linux.

Why Kali on the Pi?

A lot of hacking tasks like cracking WiFi passwords take a lot of processing power. Cracking WPA2 passwords is usually done on very powerful computers with multiple GPU cards and very large dictionary databases. Accomplishing this on a Raspberry Pi would pretty much take forever if it could actually do it. Many hacking tasks are of this nature, very compute intensive.

The Raspberry Pi is useful due to its low cost and small size. The low cost makes it disposable, if you lose it then it doesn’t matter so much and the small size means you can hide it easily. So for instance one use would be to hide a Raspberry Pi at the site you are trying to hack. Then the Raspberry Pi can monitor the Wifi traffic looking for useful data packets that can give away information. Or even leave the Pi somewhere hidden connected to a hardwired ethernet connection. Then Kali Linux has tools to get this information to external sources in a secretive way and allows you to remotely control it to direct various attacks.

Many companies build their security like eggs with a hard to penetrate shell and often locating a device on their premises can bypass their main security protections. You can then run repeated metasploit attacks looking for weaknesses from the inside. Remember your security should be more like an onion with multiple nested layers, so getting through one doesn’t give an attacker access to everything.

Installing Kali Linux

The Kali Linux web site includes a complete disk image of the Raspberry Pi version. You just need to burn this to a micro-SD card using a tool like ApplePi Baker. They you just put the micro-SD in your Raspberry Pi, turn it on and off you go. However there are a few necessary steps to take before you really start:

  1. The root password is toor, so change this first time you boot up.
  2. The Kali Linux instructions point out you need to refresh your SSH certificates since otherwise you get the ones included with the image. The download page has instructions on how to do this.
  3. The image is configured for 8Gig so if you have a larger SD card then you need to repartition it to get all the free space. I used the GParted program for this which I got via “apt-get install gparted”. Note that to use apt-get you need to connect to WiFi or the Internet. Another option is to get Raspbian’s configuration program and use that, it works with most variants of Debian Linux and allows you to do some other things like setup overclocking. You can Google for the wget command to get this.
  4. Update the various installed programs via “apt-get update” and “apt-get upgrade”. (If you aren’t still logged on as root you need to sudo these).

Now you are pretty much ready to play. Notice that you are in a nice graphical environment and that the application menu is full of hacking tools. These aren’t as many hacking tools as the full Kali distribution, but these are all ones that work well on the Raspberry Pi. They als limited the number so you can run off a really cheap 8 Gig micro-SD card.

I see people say you should stick to command line versions of the tools on the Pi due to its processing power and limited memory, but I found I could add the GUI versions and these worked fine. For instance the nmap tool is installed, but the zenmap graphical front end isn’t. Adding zenmap is easy via “apt-get install zenmap” and then this seems to work fine. I think the assumption is that most people will use the Raspberry version of Kali headless (meaning no screen or keyboard) so it needs to be accessed via remote control software like secure shell which means you want to avoid GUIs.

Summary

Installing Kali Linux on a micro-SD card for your Raspberry Pi si a great way to learn about the various tools that hackers can easily use to try and penetrate, spy on or interfere with people’s computers. There are quite a few books on this as well as many great resources on the Web. Kali’s website is a great starting point. Anyway I find it quite eye opening the variety of readily tools and how easy it is for anyone to use them.

Written by smist08

January 16, 2018 at 3:01 am

Spectre Attacks on ARM Devices

leave a comment »

Introduction

I predicted that 2018 would be a very bad year for data breaches and security problems, and we have already started the year with the Intel x86 specific Meltdown exploit and the Spectre exploit that works on all sorts of processors and even on some JavaScript systems (like Chrome). Since my last article was on Assembler programming and most of these type exploits are created in Assembler, I thought it might be fun to look at how Spectre works and get a feel for how hackers can retrieve useful data out of what seems like nowhere. Spectre is actually a large new family of exploits so patching them all is going to take quite a bit of time, and like the older buffer overrun exploits, are going to keep reappearing.

I’ve been writing quite a bit about the Raspberry Pi recently, so is the Raspberry Pi affected by Spectre? After all it affects all Android and Apple devices based on ARM processors. The main Raspberry Pi operating system is Raspbian which is variant of Debian Linux optimized for the Pi. A recent criticism of Raspbian is that it is still 32-Bit. It turns out that running the ARM in 32-bit mode eliminates a lot of the Spectre attack scenarios. We’ll discuss why this is in the article. If you are running 64-Bit software on the Pi (like running Android) then you are susceptible. You are also susceptible to the software versions of this attack like those in JavaScript interpreters that support branch prediction (like Chromium).

The Spectre hacks work by exploiting how processor branch prediction works coupled with how data is cached. The exploits use branch prediction to access data it shouldn’t and then use the processor cache to retrieve the data for use. The original article by the security researchers is really quite good and worth a read. Its available here. It has an appendix at the back with C code for Intel processors that is quite interesting.

Branch Prediction

In our last blog post we mentioned that all the data processing assembler instructions were conditionally executed. This was because if you perform a branch instruction then the instruction pipeline needs to be cleared and restarted. This will really stall the processor. The ARM 32-bit solution was good as long as compilers are good at generating code that efficiently utilize these. Remember that most code for ARM processors is compiled using GCC and GCC is a general purpose compiler that works on all sorts of processors and its optimizations tend to be general purpose rather than processor specific. When ARM evaluated adding 64-Bit instructions, they wanted to keep the instructions 32-Bit in length, but they wanted to add a bunch of instructions as well (like integer divide), so they made the decision to eliminate the bits used for conditionally executing instructions and have a bigger opcode instead (and hence lots more instructions). I think they also considered that their conditional instructions weren’t being used as much as they should be and weren’t earning their keep. Plus they now had more transistors to play with so they could do a couple of other things instead. One is that they lengthed the instruction pipeline to be much longer than the current three instructions and the other was to implement branch prediction. Here the processor had a table of 128 branches and the route they took last time through. The processor would then execute the most commonly chosen branch assuming that once the conditional was figured out, it would very rarely need to throw away the work and start over. Generally this larger pipeline with branch prediction lead to much better performance results. So what could go wrong?

Consider the branch statement:

 

if (x < array1_size)
    y = array2[array1[x] * 256];


This looks like a good bit of C code to test if an array is in range before accessing it. If it didn’t do this check then we could get a buffer overrun vulnerability by making x larger than the array size and accessing memory beyond the array. Hackers are very good at exploiting buffer overruns. But sadly (for hackers) programmers are getting better at putting these sort of checks in (or having automated or higher level languages do it for them).

Now consider branch prediction. Suppose we execute this code hundreds of times with legitimate values of x. The processor will see the conditional is usually true and the second line is usually executed. So now branch prediction will see this and when this code is executed it will just start execution of the second line right away and work out the first line in a second execution unit at the same time. But what if we enter a large value of x? Now branch prediction will execute the second line and y will get a piece of memory it shouldn’t. But so what, eventually the conditional in the first line will be evaluated and that value of y will be discarded. Some processors will even zero it out (after all they do security review these things). So how does that help the hacker? The trick turns out to be exploiting processor caching.

Processor Caching

No matter how fast memory companies claim their super fast DDR4 memory is, it really isn’t, at least compared to CPU registers. To get a bit of extra speed out of memory access all CPUs implement some sort of memory cache where recently used parts of main memory are cached in the CPU for faster access. Often CPUs have multiple levels of cache, a super fast one, a fast one and a not quite as fast one. The trick then to getting at the incorrectly calculated value of y above is to somehow figure out how to access it from the cache. No CPU has a read from cache assembler instruction, this would cause havoc and definitely be a security problem. This is really the CPU vulnerability, that the incorrectly calculated buffer overrun y is in the cache. Hackers figured out, not how to read this value but to infer it by timing memory accesses. They could clear the cache (this is generally supported and even if it isn’t you could read lots of zeros). Then time how long it takes to read various bytes. Basically a byte in cache will read much faster than a byte from main memory and this then reveals what the value of y was. Very tricky.

Recap

So to recap, the Spectre exploit works by:

  1. Clear the cache
  2. Execute the target branch code repeatedly with correct values
  3. Execute the target with an incorrect value
  4. Loop through possible values timing the read access to find the one in cache

This can then be put in a loop to read large portions of a programs private memory.

Summary

The Spectre attack is a very serious new technique for hackers to hack into our data. This will be like buffer overruns and there won’t be one quick fix, people are going to be patching systems for a long time on this one. As more hackers understand this attack, there will be all sorts of creative offshoots that will deal further havoc.

Some of the remedies like turning off branch prediction or memory caching will cause huge performance problems. Generally the real fixes need to be in the CPUs. Beyond this, systems like JavaScript interpreters, or even systems like the .Net runtime or Java VMs could have this vulnerability in their optimization systems. These can be fixed in software, but now you require a huge number of systems to be patched and we know from experience that this will take a very long time with all sorts of bad things happening along the way.

The good news for Raspberry Pi Raspbian users, is that the ARM in the older 32-Bit mode isn’t susceptible. It is only susceptible through software uses like JavaScript. Also as hackers develop these techniques going forwards perhaps they can find a combination that works for the Raspberry, so you can never be complacent.

 

Written by smist08

January 5, 2018 at 10:42 pm

Installing the New Sage 300 Web UIs Securely

with 5 comments

Introduction

Sage 300 2016 comes with new Web UIs. With beta release I talked about how to install these, but I didn’t get into the details of securing your setup to be exposed to the Internet. If you just follow the instructions from the last blog post, then you are ok in a protected LAN environment, but need a number of additional steps to go beyond that. 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 Sage 300 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 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.

A common way to extend to the Internet if via VPN connections. This usually works well for some devices like laptops but then very badly for others like tablets. If you need better performance and don’t want to worry about supporting VPN clients on a whole variety of devices, then using the standard Internet security protocols is a better way to go. All that being said, if your needs are simple, VPN is a good way to go.

For Sage 300 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 and cross site scripting attacks, 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. You should perform this exercise even if you don’t have any web servers and feel you have a very protected environment.

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, 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. 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.

nmap

Qualsys and CloudFlare

Zenmap is nice because it’s simple and free. However there are more sophisticated tools available that you might want to consider. For instance Qualsys is a very good commercial security scanner which will do a deeper analysis than Zenmap. If you website is protected by authentication, you might want to run Qualsys against a test system with authentication turned off, then it can do a much more thorough scan of all your web pages (i.e. find vulnerabilities that are only visible if you are successfully logged in).

Another protective layer is to put your site behind CloudFlare. Among other things, this will provide protection against distributed denial of service DDoS attacks. This is where hackers enlist thousands (or millions) of zombie computers to all access your site at once, bringing it down.

HTTPS

Now with your site doesn’t have any unneeded open ports, we need to ensure the web site 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.

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.

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.

bindings

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.

sslsetting

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 Sage 300 doesn’t store any valuable data in IIS, Sage 300 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.

One thing that security experts do recommend is that you replace all the generic IIS error messages, this is so the hacker doesn’t learn the exact HTTP error code or help recognize your exact server/IIS version. You can either edit or replace these pages which are located under C:\inetpub\custerr by language code, or you can configure IIS to redirect to Sage 300’s generic error message rather than use the stock error messages (ie /Sage300/Core/Error). You do this from the server’s error message icon in the IIS manager.

iiserrorconfig

Database Setup

The new Web UIs 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.

Also ensure security is turned on for each system database, or you don’t need a password to login. Further make sure you change the ADMIN password first since everyone knows the default one.

secsettings

Update 2015/08/15: Its been pointed out to me that a good practice for Database Setup is for each database to have its own DBO and password. Then anyone getting access to one database doesn’t get access to any other. This includes creating a separate DBO and password for the Portal database.

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.

PS

This article is an update to this 2010 article I did for the 6.0A Portal. Now that we have a new Web technology stack a lot of these previous articles will need to be updated for the new technologies and for what has happened in the last five years.

Written by smist08

August 8, 2015 at 4:57 pm

More Thoughts on Security

leave a comment »

Introduction

Last week I blogged on some security topics that were prompted by the Heartbleed security hole. Heartbleed was hot while it lasted, but in the end most servers were quickly patched and not a lot of damage was reported. Now this last week Heartbleed was completely pushed aside by the latest Internet Explorer security vulnerability. A lot of the drama of this problem was caused by speculation on whether Microsoft would fix it for Windows XP. Although the problem existed in all versions of Windows and IE, it was assumed that Microsoft would fix it fairly quickly for new versions of Windows, but leave Windows XP vulnerable.

The IE Problem

Microsoft’s Internet Explorer has had a history of problems with letting rogue web sites take over people’s computers by downloading and executing nasty code. The first cases of this was that IE would run ActiveX controls, which basically are compiled programs downloaded to your computer and then run in the Browser’s process space. These led to all sorts of malicious programs and viruses. First Microsoft tried to make ActiveX controls “signed” by a trusted company, but generally these caused so many problems that people have to be very careful which ActiveX controls to allow.

internet-explorer-ie10

With ActiveX controls blocked, malicious software writers turned to other ways to get their code executed inside IE. A lot of these problems date back to Microsoft’s philosophy in the early 90s of having code execute anywhere. So they had facilities to execute code in word processing documents, and all sorts of other things. Many of the new malicious software finds old instances of this where Microsoft unexpectedly lets you run code in something that you wouldn’t expect to run code. Slowly but surely these instances are being plugged one by one through Windows Updates.

The next attack surface is to look for bugs in IE. If you’ve ever tried running an older version of IE under Bounds Checker, you would see all sorts of problems reported. Generally a lot of these allow attackers to exploit buffer overrun problems and various other memory bugs in IE to get their code loaded and executing.

Another attack surface is common plugins that seem to always be present in IE like for rendering PDF documents or for displaying Adobe Flash based websites or using Microsoft Silverlight. All these plugins have had many security holes that have allowed malicious code to execute.

Plugging these holes one by one via Windows update is a continuing process. However Microsoft has taken some proactive steps to make hacking IE harder. The have introduced things like more advanced memory protections and ways to randomize memory buffer usage to make it harder for hackers to exploit things. However they haven’t trimmed down the functionality that leads to such a large attack surface.

internet-explorer-vml-bug-zero-day-vulnerability

The latest exploit that was reported in the wild last week got around all Microsoft’s protections and allowed a malicious web site to take over any version IE on any version of Windows that browsed that site. Then the malicious web site could install software to steal information from the affected computer, install a keyboard logger to catch typed passwords or install e-mail spam generation software.

Why the Fuss?

This new exploit was a fairly typical IE exploit, so why did it receive so much attention? One reason is that after Heartbleed, security is on everyone’s mind. The second is that Microsoft has ended support for Windows XP and publicly stated it would not release any more security updates. So the thinking was that this was the first serious security flaw that wouldn’t be patched in Windows XP and havoc would result.

However Microsoft did patch the problem after a few days, and they did patch the problem on Windows XP as well. After all Windows XP still accounts for about a third of the computers browsing the Internet today. If all of these were harnessed for a Denial of Service attack or started to send spam, it could be quite serious.

People also question how serious it is since you have to actually browse to the malicious web site. How do you get people to do this? One way is when URLs expire, sometimes someone malicious can renew it and redirect to a bad place. Another way is to register URLs with small spelling mistakes from real websites and get unwary visitors that way. Another approach is to place ads on sites that just take the money without validating the legality of the ad or what it links to. Sending spam with the bad URLs is another common approach to lure people.

How to Protect Yourself

Here are a few points you can adopt to make your life safer online:

  • Use supported software, don’t use old unsupported software like Windows XP. Windows 7 is really good, at least upgrade to that. If your computer isn’t connected to the Internet then it doesn’t really matter.
  • Make sure Windows Update is set to automatically keep your computer up to date.
  • Don’t click on unknown attachments in e-mails
  • If you receive spam with a shortened or suspicious URL link, don’t click on it.
  • Go through the add-ons in your browser and disable anything that you don’t know you use regularly (including all those toolbars that get installed).
  • When browsing unfamiliar sites on the web, use a safer browser like Google Chrome. Nothing is foolproof but generally Chrome has a better history than most other browsers.
  • Make sure you have up to date virus scanning software running. There are several good free ones including AVG Free Edition.
  • Make sure you have Windows Firewall turned on.
  • Don’t run server program you don’t need. You probably don’t need to be running an FTP server or an e-mail server. Similarly don’t run a whole bunch of database servers you aren’t using, or stop them when not in use.
  • Don’t trust popup Windows from unfamiliar or suspicious websites. I.e. if suddenly a Window pops up telling you to update Java or something, it’s probably a fake and going to install something bad. Always go to a company’s main site of something you are going to install.
  • Never give personally identifiable data to unknown websites, they have no good reason to know your birthday, phone number or mother’s maiden name.
  • Don’t use the same password on all websites. For websites that you care about have a good unique password.
  • Be distrustful of URLs that are sort of right, but not quite (often it’s better to go through Google than to spell a URL directly). Often scammers setup URLs with common spelling errors of popular sites to get unsuspecting victims.

Summary

There are a lot of bad things out on the Internet. But with some simple precautions and some common sense you can avoid the pitfalls and have an enjoyable web browsing experience.

 

Written by smist08

May 3, 2014 at 4:25 pm

Some Thoughts on Security

with 2 comments

Introduction

With the recent Heartbleed security exploit in the OpenSSL library a lot of attention has been focused on how vulnerable our computer systems have become to data theft. With so much data travelling the Internet as well as travelling wireless networks, this has brought home the importance of how secure these systems are. With a general direction towards an Internet of Things this makes all our devices whether our fridge or our car possibly susceptible to hackers.

I’ll talk about Heartbleed a bit later, but first perhaps a bit of history with my experiences with secure computing environments.

Physical Isolation

My last co-op work term was at DRDC Atlantic in Dartmouth, Nova Scotia. In order to maintain security they had a special mainframe for handling classified data and to perform classified processing. This computer was located inside a bank vault along with all its disk drives and tape units. It was only turned on after the door was sealed and it was completely cut off from the outside world. Technicians were responsible for monitoring the vault from the outside to ensure that there was absolutely no leakage of RF radiation when classified processing was in progress.

After graduation from University my first job was with Epic Data. One of the projects I worked on was a security system for a General Dynamics fighter aircraft design facility. This entire building was built as a giant Faraday cage. The entrances weren’t sealed, but you had to travel through a twisty corridor to enter the building to ensure there was not line for radio waves to pass out. Then surrounding the building was a large protected parking lot where only authorized cars were allowed in.

Generally these facilities didn’t believe you could secure connections with the outside world. If such a connection existed, no matter how good the encryption and security measures, a hacker could penetrate it. The hackers they were worried about weren’t just bored teenagers living in their parent’s basements, but well trained and financed hackers working for foreign governments. Something like the Russian or Chinese version of the NSA.

Van Eck Phreaking

A lot of attention goes to securing Internet connections. But historically data has been stolen through other means. Van Eck Phreaking is a technique to listen to the RF radiation from a CRT or LCD monitor and to reconstruct the image from that radiation. Using this sort of technique a van parked on the street with sensitive antenna equipment can reconstruct what is being viewed on your monitor. This is even though you are using a wired connection from your computer to the monitor. In this case how updated your software is or how secure your cryptography is just doesn’t matter.

Everything is Wireless

It seems that every now and then politicians forget that cell phones are really just radios and that anyone with the right sort of radio receiver can listen in. This seems to lead to a scandal in BC politics every couple of years. This is really just a reminder that unless something is specifically marked as using some sort of secure connection or cryptography, it probably doesn’t. And then if it doesn’t anyone can listen in.

It might seem that most communications are secure now a days. Even Google search switches to always use https which is a very secure encrypted channel to keep all your search terms a secret between yourself and Google.

But think about all the other communication channels going on. If you use a wireless mouse or a wireless keyboard, then these are really just short range radios. Is this communications encrypted and secure? Similarly if you use a wireless monitor, then it’s even easier to eavesdrop on than using Van Eck.

What about your Wi-Fi network? Is that secure? Or is all non-https traffic easy to eavesdrop on? People are getting better and better at hacking into Wi-Fi networks.

In your car if you are using your cell phone via blue tooth, is this another place where eavesdropping can occur?

Heartbleed

Heartbleed is an interesting bug in the OpenSSL library that’s caused a lot of concern recently. The following XKCD cartoon gives a good explanation of how a bug in validating an input parameter caused the problem of leaking a lot of data to the web.

heartbleed_explanation

At the first level, any program that receives input from untrusted sources (i.e. random people out on the Internet) should very carefully and thoroughly valid any input. Here you can tell it what to reply and the length of the reply. If you give a length much longer than what was given then it leaks whatever random contents of memory were located here.

At the second level, this is an API design flaw, that there should never have been such a function with such parameters that could be abused thus.

At the third level, what allows this to go bad is a performance optimization that was put in the OpenSSL library to provide faster buffer management. Before this performance enhancement, this bug would just have caused an application fault. This would have been bad, but been easy to detect and wouldn’t have leaked any data. At worst it would have perhaps allowed some short lived denial of service attacks.

Mostly exploiting this security hole just returns the attacker with a bunch of random garbage. The trick is to automate the attack to repeatedly try it on thousands of places until by fluke you find something valuable, perhaps a private digital key or perhaps a password.

password-heartbleed-thumb-v1-620x411

Complacency

The open source community makes the claim that open source code is safer because anyone can review the source code and find bugs. So people are invited to do this to OpenSSL. I think Heartbleed shows that security researcher became complacent and weren’t examining this code closely enough.

The code that caused the bug was checked in by a trusted coder, and was code reviewed by someone knowledgeable. Mistakes happen, but for something like this, perhaps there was a bit too much trust. I think it was an honest mistake and not deliberate sabotage by hackers or the NSA. The source code change logs give a pretty good audit of what happened and why.

Should I Panic?

In spite of what some reporters are saying, this isn’t the worst security problem that has surfaced. The holy grail of hackers is to find a way to root computers (take them over with full administrator privileges). This attack just has a small chance of providing something to help on this way and isn’t a full exploit in its own right. Bugs in Java, IE, SQL Server and Flash have all allowed hackers to take over peoples computers. Some didn’t require anything else, some just required tricking the user into browsing a bad web site. Similarly e-mail or flash drive viruses have caused far more havoc than this particular problem. Another really on-going security weakness is caused by government regulations restricting the strength of encryption or forcing the disclosure of keys, these measures do little to help the government, but they really make the lives of hackers easier. I also think that e-mail borne viruses have wreaked much more havoc than Heartbleed is likely to. But I suspect the biggest source of identity theft is from data recovered from stolen laptops and other devices.

Another aspect is the idea that we should be like gazelle’s and rely on the herd to protect us. If we are in a herd of 100 and a lion comes along to eat one of us then there is only a 1/1000 chance that it will be me.

This attack does highlight the importance of some good security practices. Such as changing important passwords regularly (every few months) and using sufficiently complex or long passwords.

All that being said, nearly every website makes you sign in. For web sites that I don’t care about I just use a simple password and if someone discovers it, I don’t really care. For other sites like personal banking I take much more care. For sites like Facebook I take medium care. Generally don’t provide accurate personal information to sites that don’t need it, if they insist on your birthday, enter it a few days off, if they want a phone number then make one up. That way if the site is compromised then they just get a bunch of inaccurate data on you. Most sites ask way too many things. Resist answering these or answer them inaccurately. Also avoid overly nosey surveys, they may be private and anonymous, unless hacked.

The good thing about this exploit, seems to be that it was discovered and fixed mostly before it could be exploited. I haven’t seen real cases of damage being done. Some sites (like the Canadian Revenue Services) are trying to blame Heartbleed for unrelated security lapses.

Generally the problems that you hear about are the ones that you don’t need to worry so much about. But again it is a safe practice to use this as a reminder to change your passwords and minimize the amount of personally identifiable data out there. After all dealing with things like identity theft can be pretty annoying. And this also help with the problems that the black hat hackers know about and are using, but haven’t been discovered yet.

Summary

You always need to be vigilant about security. However it doesn’t help to be overly paranoid. Follow good on-line practices and you should be fine. The diversity of computer systems out there helps, not all are affected and those that are, are good about notifying those that have been affected. Generally a little paranoia and good sense can go a long way on-line.

Written by smist08

April 26, 2014 at 6:51 pm