CompTIA CASP+ CAS-004 – Chapter 04 – Implementing Security for Systems, Applications, and Storage Part 5

38. Application Issues

To truly understand how to secure applications though, you need to understand exactly what you’re up against. You have to know at least some basic knowledge about a number of specific security issues and attacks. So let’s start with the Insecure Direct object references. Applications are frequently using the actual name or the actual key of an object when they generate web pages, and they don’t always verify that the user is authorized for that target object. That results in this insecure direct object reference flaw. So an attack can come from an authorized user, meaning that the user has permission to use the application, but they’re accessing information to which they shouldn’t actually have access. In order to prevent it, you need to have each direct object reference undergo an access check and that would come up during the code review of the application.

Assuming that we have this specific issue in mind, a fairly familiar one is XSS or cross site scripting. This is when an attacker locates a website vulnerability and then injects malicious code into the application. A lot of websites allow and even incorporate user input into a web page because it allows us to customize the page. But if the web application doesn’t properly validate the input, then one of two things can happen. Either the text is going to be rendered on the page or a script may be executed when other users visit the page. And that’s how an XSS attack can be utilized. How do you defend against it? Well, just proper validation of all input needs to be performed that will prevent it, and that involves identifying all the user supplied input and then testing the potential output. CSRF cross site request forgery is an attack that causes an end user to execute unwanted applications actions on a web application.

So the user is authenticated, they’re connected, but in this case, an attacker has exploited the website’s trust of the browser rather than the other way around. So the website thinks the request came from the user’s browser and was actually made by the user. But the request was really planted in the user browser and it usually gets there by them following a URL that already has the code to be injected. So they’ve just clicked a clicked a link.

Now, there are some different things that you can do to help prevent that. Techniques like HTML encode, which will encode all output based on input parameters for special characters, and it’s just trying to prevent malicious scripts from executing. You can filter input parameters based on special characters and you can filter output based on input parameters for special characters. Clickjacking is another one. Sounds kind of fun. That’s not fun at all. An attacker uses a clickjack attack to craft a transparent page, or it’s basically like a transparent frame that sits over a legitimate looking page. It’s enticing the user to click on something, but when they do, they’re really not clicking on the actual URL. They’re clicking on a different URL.

In a lot of cases, the site or application may then entice the user to enter credentials and those can then be captured and used later by the attacker. Most responsibility for preventing this rests on the owner of the site. So when we’re designing web applications that needs to be taken into account, session management involves taking measures to protect against session hijacking. This is when a hacker is able to identify the unique session ID that’s assigned to a particular authenticated user. It’s important that the process used by the web server to generate those IDs is truly random. Because hackers would need to identify or discover the session ID in order to steal it.

They could guess it. That just involves gathering samples of session IDs and then trying to guess one. Or they could steal it. SSL hides these IDs, but a lot of sites don’t require an SSL connection when using session ID cookies. They can also be stolen through the cross site scripting attacks. Input validation is something that we mentioned. In fact, many of these attacks are because the web application is not validating any of the data that’s being entered by the user or attacker. And input validation is just simply checking all the input, looking for proper format, looking for proper length. And in a lot of cases, these validators will either use the black listing of certain characters or patterns that are known to cause attack, or they’ll whitelist. They’ll say only these characters or patterns are allowed for a phone number, for an address, those kinds of things.

But the input needs to be checked, and not just the characters that the length should also be checked because that helps to prevent buffer overflows SQL injection attacks, insert or inject an SQL query as the input data from the client to the application. And the result is that you potentially have an attacker who’s able to read sensitive data from a database, maybe even modify database information, possibly execute administrative operations on the database, like deleting records, recovering the content of particular files. So this is a very dangerous type of attack. And the way to prevent it, you guessed it, that would be input validation, blacklisting and whitelisting, of special characters. And the final one is improper error and exception handling.

So web applications, just like any other application, are going to suffer from errors, they’re going to have exceptions in the code. These are not unique problems there to be expected. But the way that the application reacts to those errors and exceptions, that’s going to determine whether security can be compromised. One of the problems is in reality, is that error messages may reveal too much information. They’ve may reveal information about the system that the attacker can find useful. So typically, error messages describing problems need to be kept as generic as possible. It makes supporting those applications a little bit more difficult, but it’s a very good idea.

39. Application Issues conti…

There are a number of other application issues. I said finally because it was the last one on the slide. But let’s talk about some more here. Privilege escalation is the process of exploiting a bug or weakness in the operating system. It allows the users to receive privileges to which they’re not entitled. These privileges can be used for anything delete files, view private information, install malware. There are two basic types of privilege escalation there’s vertical. That’s when you have a lower privileged user that’s accessing functions or content reserved for higher privileged users, and there’s horizontal, and that’s when a normal user is accessing functions or content that’s reserved for somebody else. In order to prevent this, we just want to make sure that databases, any related systems and applications are operating with minimum privilege levels, only what they require to function. And we should be following least privilege with the users too, only giving them permission to do what they need to do in order to perform their job.

And with databases, we never want to run with root administrator or any other privilege account permissions, if at all possible sensitive information in the discussion of applications involves usernames passwords, encryption keys, paths that the application needs to function but would cause harm if they were discovered. So we have to determine the proper method of securing that. It’s pretty critical, it’s not easy. It’s generally accepted that you don’t hard code passwords, although older applications, you may still find that it wasn’t always considered, but it is definitely considered a best practice now. Instead of hard coding passwords, passwords need to be protected by using encryption when they’re used in application code. That’s going to make it difficult to modify them as well as difficult to discover them. In general, if you’re trying to prevent the disclosure of sensitive information from storage, you want to make sure that memory locations are locked, ACLs are used to protect anything that’s sensitive encryption methods are used, et cetera.

Fuzz testing, or Fuzzing, involves the injecting of invalid or unexpected input, often referred to as faults into an application just to see how the application is going to react. It’s typically done with a software tool that’s going to help to automate the process, but the input can be just about anything environmental variables, keyboard mouse events, API calls. We’re just feeding this application with essentially bogus information to see how is it going to handle it. There are two basic types. There’s mutation fuzzing, which involves changing existing input values in a blind fashion, and then generation based fuzzing, which means that we’re generating inputs from scratch and it’s based on a particular specification or format. If you want to prevent these types of attacks, you need to implement Fuzz testing, because that’s going to help you.

Fault injection is the actual name of the attack. Fuzzing is the test that’s going to help you to identify how the application is going to react and if it’s not reacting correctly, then we can take it back and modify it. And then developers just need to adhere to safe coding practices and we might even want to deploy application level firewalls cookies are little text files that are stored on a user’s hard drive. Most of us are familiar with this. Sometimes they’re stored in memory. They store information about the user’s internet habits, the browsing information, how much they’ve spent. And web servers are using these for legitimate reasons.

They’re using them to identify you when you come back to the site to save shopping cart information, to save account data. But malicious sites can use cookies to discover a large amount of information about the user. The information on the hard drive usually doesn’t have any confidential information. But the attacker can use the cookie to obtain information about the users and that can help them to develop better targeted attacks. So it may reveal, for instance, that you use a particular bank or a particular credit card.

And so then the attacker can model a phishing attack by sending you an email from said bank or credit card company. And so it looks like it’s coming legitimate Source a lot of your antivirus and anti malware applications have the functionality to allow you to limit the cookies downloaded and also hide PII like email addresses. But sometimes these are more trouble than they’re worth because they actually affect legitimate internet communication. So if we’re responsible for creating web applications, then we really should give some thought to the secure storage of cookies. Cookies should be encrypted and they should not contain essential information. If it does need to contain essential information, then it should be stored on the server and we just give the client a pointer to it. A buffer overflow. What is that? Well, buffers are portions of system memory that are used to store information.

And a buffer overflow is just an attack that occurs when you have the amount of data submitted is larger than the buffer can handle. It’s usually possible just because of poorly written code, either at the application level or at the operating system level. But it can result in the injection of malicious code. Usually that’s a SQL injection or a denial of service. Best protection of this is patches. Latest service packs latest patches for applications as well as programmers actually testing their applications for that particular problem. It’s a very common problem, it’s been out there for quite some time. Applications also use memory to store resources, objects, variables, et cetera. And if an application mismanages the memory it’s been assigned, then several things can occur. One is that over time it doesn’t return the allocated memory back to the operating system at that point. At some point at least you would potentially exhaust the memory of that source system.

Also, objects that are stored in memory may then become inaccessible. So this is what was referred to as a memory leak integer. Overflow is when math operations try to create a numeric value that’s too big for the available space. It is the register width on the processor that determines the range of values that can be represented. And so that is what makes this possible. You can mitigate this by using strict input validation or using a language or compiler that does bounds checking race conditions. That’s an attack where the hacker inserts himself or herself between instructions, introduces changes, and then alters the order of execution. And so thereby they can alter the outcome. One type of race condition is the time of check time of use. So this is an attack where the system is changed between a condition check and the display of the checks results.

Okay, so let’s give an example. So at 10:00 a. m. , a hacker is able to obtain a valid authentication token that allows them read write access to a database. At 1015, the security administrator receives alerts from the IDs about a database administrator who’s performing unusual transactions. At 1025, based on that alert, the security administrator resets the password for that database administrator. Then at 1130, the security administrator is still receiving alerts from the IDs.

There’s still unusual transactions happening. So in this situation, a race condition was created by the hacker and that disturbed the normal process of authentication. They remain logged in with the old password and they were still able to change data. Some countermeasures against this are to make critical sets of information, either execute in order in entirety, or roll back and prevent changes. So don’t just do one or two things, you have to do them all, or have the system lock access to certain items that it will access when carrying out that set of instructions.

40. Data Remnants

Data remnant is residual information that’s left on a drive after you have performed a delete process. This can cause inadvertent disclosure of sensitive information. Now, the problem is that simple deletion and formatting doesn’t remove the data. So during media disposal, we need to make sure that no data remains on the media. Most reliable secure means of removing data from magnetic storage, magnetic tape or cassette is through degaussing.

That exposes the media to powerful alternating magnetic fields and it removes any of the previously written data. But there are some other disposal methods. Data purging can be used that is technically a method like degaussing to make older data unavailable. Even with forensics, it renders the information unrecoverable at that point and then data clearing is the type of disposal that renders the information uncoverable by a keyboard.

So it extracts information from the storage media and it does that by executing software utilities, keystrokes or other system resources executed from a keyboard. It’s actually been estimated that 90% of software components that are downloaded or are downloaded from code repositories. And these types of repositories hold code that can be reused. That’s actually something that’s really important for us to do. We want to use those repositories. Not only is it going to speed up software development because it eliminates the time that it would take to create these components from scratch, but they’re also, generally speaking, more secure.

41. Securing Applications

There are a number of other options that exist for securing applications. One is sandboxing. Sandboxing an application just means you’re limiting the parts of the OS that the user files, or OS and user files, I should say, that the application is allowed to interact with. So it prevents the code from making any permanent changes to, say, the kernel or data outside of certain directories.

The sandbox does have to contain all the files that the application is going to need to execute. And that’s one potential problem. If you have applications that need to interact with one another and they’re sandboxed, then you can have an issue. And sometimes sandboxing actually does create more problems than it solves. Security encrypted Enclaves that’s a part of the OS that can’t be compromised even when the kernel is compromised, because the enclave really has its own CPU and it’s separated from the rest of the system. It means that security functions remain intact even when somebody’s gained control of the OS. Now, this is relatively recent technology, but Cisco, Microsoft, Apple, they all have implementations of secure enclaves that differ slightly. Database activity monitoring, or dam, is going to involve monitoring transactions and the activity of database services so that can be used for monitoring unauthorized access or fraudulent activities can also be used for simple compliance auditing.

Web Application firewalls WAF we’ve mentioned before that applies rule sets to an Http conversation. Those rule sets by default will cover common attacks, typically without any sort of customization. The WAF is going to project against SQL injection, cross site scripting, resource exhaustion attacks, et cetera. And then when a web application is developed, one of the decisions that need to be made is what information is going to be processed on the server and what information is going to be processed on the client. Client side processing is self explanatory. Server side processing is self explanatory. And so you really have to kind of get into the mind of a developer to understand the difference between those. But a lot of web designers like processing to occur on the client side because it taxes the web server less and it allows the web server to serve more users.

The problem with that is you’re sending the client the processing code, and all of that information could be useful in attacking the the server. So in reality, we just need a good balance between the two.

42. Using JSON and REST

Let’s talk about a couple of technologies JSON and Rest. Rest is representational. State transfer. It’s a client server model that’s used to interact with content on remote systems, usually using Http, and it involves accessing and modifying existing content. It can also be used to add content to a system in a particular way. Now, Rest doesn’t require a specific message format for Http VP Resource exchanges that’s up to the Restful web service to choose the format that’s supported, and XML and JavaScript Object notation JSON are two of the most popular formats used by Restful Web services. JSON is just a simple text based message format that’s used with these. Like XML.

It’s designed to be readable that can be very helpful when debugging and testing. It’s derived from JavaScript and therefore it’s a very popular data format in web applications. It has a number of advantages rest JSON over the Soap and XML. One of those is the size. It’s a lot smaller and less bloated, so there’s a whole lot less data passed over the network. That’s particularly important for mobile devices. It’s also easier to parse the data, so it’s easier to extract and convert, which makes it more efficient. It provides improved response times and server loading due to support from caching and then the implementation. It’s just much easier to implement than Soap XML soap XML is generally preferred in transactional services like banking services, but JSON and the Restful system are used elsewhere.

43. Browser Extensions

Everybody’s heard of a browser extension. These are add-ons to the browser. They’re very small programs or scripts that increase the functionality of a website and they come in a number of different varieties. ActiveX was a server side Microsoft technology that’s used in object-oriented programming and it’s based on or, the Component Object Model and decom. Distributed component object model allows software components to communicate. DCOM does the same functionality, but it distributes them across multiple computers. This includes selfsufficient programs called controls and they become part of the OS once they’re downloaded.

 The problem is that they execute under the security context of the current user and in many cases the user has administrative rights. And so that means malicious ActiveX controls can do some fairly serious damage. One of the ways that they’re protected is by using authentic technology to digitally sign the control. But unfortunately, that has some fairly significant flaws. Today, ActiveX controls are generally regarded with suspicion, at least more suspicion than Java applets. A Java applet is a small server side component created using Java that runs in the web browser. It’s platform independent and it creates unique intermediate code that’s not processor specific. So all the user has to do is download the Java applet and then run a Java virtual machine. Now that does have to be present. If you’ve ever visited a website with Java, you know that you have to download and install it. But the Java virtual machine is running in a protected environment called a sandbox.

We talked about that earlier and so it’s much more secure than ActiveX controls. HTML Five is the latest version of the hypertext Markup language. It’s been improved to support the latest multimedia, which is why it’s the successor, likely successor to Flash. Some of the security issues of the previous version of HTML and JavaScript do remain though, in HTML Five. And so we still have some of the same issues that we have to account for Ajax asynchronous JavaScript and XML. That’s a group of interrelated web development techniques that are used on the client side to create Asynchronous web applications. And then soap. Or soap. Simple object access protocol. Protocol, that’s a protocol specification for exchanging structured information in the implementation of web services on computer networks.

44. Application Vulnerabilities

A lot of the traditional operating system vulnerabilities have already been addressed in previous sections. Many attacks have actually moved up the OSI model to the application layer. That doesn’t mean that operating system vulnerabilities are no longer a problem now. They still pose a big issue because as we’ve seen, if you can compromise the OS, then you can compromise everything on the system. Some of the attacks that we still see in the, in the OS or drive by downloads, these involve using exploit kits to redirect users in order to enable the installation of malware, as well as local privilege Escalation or LPE. In this case, the malicious individuals trying to execute exploits and payloads that they would be unable to execute otherwise.

Really best thing you can do to protect against this is going to be patching. Okay? And using a more secure browser. So some browsers are just more secure than others. Internet Explorer continues to be the most vulnerable browser and a lot of people have moved away from it for that reason. Firmware updates might be some of the more neglected but important tasks that we need to perform. A lot of people subscribe to the principle if it’s not broke, don’t fix it. I subscribe to that. But the problem with that approach is that in many cases, firmware updates don’t actually add functionality.

They don’t fix something, it’s that something is wrong, a vulnerability has been found, they address security issues and computers have a ton of firmware in them, all of which is potentially vulnerable. Your USB keyboards, your webcam, your graphics card, sound cards, even computer batteries have firmware. And you can just look up firmware vulnerabilities on Google and it’ll turn up pages and pages of results that detail all of the vulnerabilities. So what’s the key point? We need to make sure that we are addressing firmware updates in a managed fashion.

45. Chapter 04 Review

In this chapter we looked at implementing security for systems, for software and for storage. We started by talking about security for host devices, the concept of the trusted operating system that has been put forward for us, and how we would go through the process of hardening these operating systems, changing default configurations of routers of firewalls switches and windows in Linux and Unix machines, as well as ensuring that patches are updated and malware is installed, et cetera. We also talked about mobile device security and the fact that mobile devices are far more prevalent today than they ever have been before and they represent a unique set of challenges that as security professionals, we need to be able to address. And finally, we talked about some software security controls, in which case the security professional has to work hand in hand with the developers to make sure that the code that is being written is being written with security in mind as opposed to security simply being an afterthought.