Checking Your Web Application

December 23, 2017

To check for broken links:

To check Cascading Style Sheets (CSS):

To check for exposed directory structure:

  • Nikto (one of the many server vulnerabilities Nikto can discover)
  • Wikto

To check for SQL Injection vulnerabilities:

To check for Cross-site scripting (XSS) vulnerabilities:

Cross-site scripting (XSS) is a client attack. If a web application accepts text (such as the following) into a field and (by presenting the entered data to the client) produces an alert on the client, then the web application can be used to attack the client.

alert("Vulnerable to XSS");

Typical reflected XSS example: a URL containing a script. The script does not reside on the server.

Typical stored XSS example: script included in data entered or uploaded. The script does reside on the server.

A more interesting attack would be an iframe which opens a link to an untrustworthy web page. The assumption that the web application is making: data entered into this field is the data I am expecting to see (also referred to as “valid data”).

The demo version allows you to scan any web site, operated by you, for Cross Site Scripting Vulnerabilities. Acunetix WVS will report the vulnerabilities’ location and will suggest techniques to fix them. Note that this edition does not allow saving of the reports.

The demo version you can also test all aspects of the product (including scanning for SQL Injection, Google hacking, and directory traversal attacks) against these Acunetix test sites:
http://testphp.acunetix.com
http://testasp.acunetix.com
http://testaspnet.acunetix.com

Host user-uploaded content on a separate domain (e.g. usercontent.example.com). Any script in the user-uploaded content won’t have access to content in your application domain.

  • DOMinator is Firefox-based software for analysis and identification of DOM based Cross Site Scripting issues (DOMXss or “type-0 XSS”). (blog)

To check for Cross-Site Request Forgery:

Cross-Site Request Forgery (CSRF) is a client attack tricking a user into submitting a request. Tricking a person into clicking a link while they are logged into an application (such as electronic banking) and thereby submitting an unintended (“forged”) request would be an example of a CSRF attack. The assumption that the web application is making: the transaction was submitted by the application user, and not by a third party which is riding the application user’s session. Same origin policy enforcement at the client side would prevent CSRF attacks, but the web application cannot assume that same origin policy is enforced. A CSRF attack can be difficult to prevent. You must inspect the business logic, and not simply scan for input. You can expect any “Are you sure?” measures, which are intended to alert the user when an unintended server interaction is suspected, to be ineffective. You can expect the user to choose the “Yes” option without reading the text. More elaborate measures (such as Captcha codes) will slow down the user in hopes of more informed decisions. The OWASP CSRFGuard Project attempts to address the issue of request integrity through the use of unique request tokens. See also PaulDotCom Episode 214 for Cross Site Request Forgery scanning with Pinata. (Something known as MonkeyFist is also intended to help discovery CSRF vulnerabilities.) See Michael Brooks’ DEFCON presentation “CSRF Bouncing” [pdf].

To check for Cross-site tracing (XST):

If a Web server supports the TRACE method, an attacker can craft a special HTTP request that bounces malicious scripts into a victim’s browser, resulting in an XST attack. You do not need the TRACE method in production environments.

  • Either disable or block the TRACE method.
  • In Apache, use mod_rewrite.
  • In IIS, use UrlScan.

To check for JavaScript errors:

By default, Internet Explore does not notify the user about JavaScript errors. When testing your own web site, choose ‘Internet Options’ on the Advanced tab. Uncheck ‘Disable script debugging’.

To check for SWF errors:

  • Review Flash applications with HP’s SwfScan (functionality is in HP’s WebInspect).
  • See the blog from Peleus Uhley of Adobe regarding Creating more secure SWF web applications. Updated to include changes made in Flash Player 10.
  • IBM has a site (demo.testfire.net/vulnerable.swf) which illustrates Flash vulnerabilities (Cross-Site Flashing Examples); read IBM’s Flash Parameter Injection whitepaper and HP’s Blinded by Flash Solving the widespread security risks Flash developers currently can’t see that threaten enterprise data.
  • FlashFirebug – Debug ANY AS3 SWF files on the web. Edit properties and inspect elements. Redirect SWF output to the extension. Run AS3 code and transform objects on the fly. Access SWF assets with the decompiler. View AMF calls and Shared Objects and much more!

The role and limitations of automated testing

Automation can be used to identify vulnerabilities of the following Technical Attack types:

  • Command Execution
  • Buffer Overflow
  • Format String Attack
  • LDAP Injection
  • OS Commanding
  • SQL Injection
  • SSI Injection
  • XPathInjection
  • Information Disclosure
  • Directory Indexing
  • Information Leakage
  • Path Traversal
  • Predictable Resource Location
  • Client-Side
  • Content Spoofing
  • Cross-site Scripting
  • HTTP Response Splitting

You will need people to identify the following non-technical, business logic vulnerabilities:

  • Authentication
  • Brute Force
  • Insufficient Authentication
  • Weak Password Recovery Validation
  • Cross-site Request Forgery (CSRF)
  • Authorization
  • Credential/Session Prediction
  • Insufficient Authorization
  • Insufficient Session Expiration
  • Session Fixation
  • Logical Attacks
  • Abuse of Functionality
  • Denial of Service
  • Insufficient Anti-automation
  • Insufficient Process Validation

Read the rest of this entry »

Advertisements

PDF Files

December 23, 2017

See Didier Stevens PDF Tools when examining a PDF file for malware. Avoid rendering a suspicious PDF file.

See his InfoSec Handlers Diary Blog “Encrypted PDFs” for decrypting PDFs.

 


Disable, or plan to disable, SMBv1

August 26, 2017

SMBv1 is s deprecated protocol, replaced by SMBv2 and SMBv3.

A vulnerability in SMBv1, which was patched in MS17-010, has been exploited by Petya ransomware to propagate itself within a network. Another vulnerability in SMBv1 can crash a server. Microsoft will not be patching this vulnerability.

https://threatpost.com/windows-smb-zero-day-to-be-disclosed-during-def-con/126927/

Learn if you have a dependency upon SMBv1. Windows prior to Vista (including Windows XP) require SMBv1. A variety of third party products use SMBv1:

https://blogs.technet.microsoft.com/filecab/2017/06/01/smb1-product-clearinghouse/

Manage SMBv1 using group policies. While a registry modification would work, you want group policy to enforce the change on any systems which may have been missed, any new systems, and any unsupported maintenance.

https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and-windows

 

Additional products may be discovered when Microsoft disables SMBv1 by default on new builds of Windows 10.

 https://www.bleepingcomputer.com/news/microsoft/microsoft-to-disable-smbv1-in-windows-starting-this-fall/


Disable LLMNR and NBT-NS

August 26, 2017

Link-Local Multicast Name Resolution (LLMNR) (UDP/5355)

Netbios Name Service (NBT-NS) (UDP/137)

LLMNR and NBT-NS are unnecessary Windows protocols and therefore unnecessary Windows attack surfaces.

LLMNR and NBT-NS are local subnet broadcast name resolution mechanisms. If DNS is working, you don’t need these protocols. If DNS isn’t working, fix it. Since they are local subnet mechanisms they are not scalable. There is no reason to fall back upon these protocols. You would not want to learn that you were relying upon these protocols.

Additionally, there are malware kits which exploit these protocols to capture user credentials (a compromised machine on the subnet responds to a name resolution request and receives user name and the NTLMv2 hash of the credentials; use Jack the Ripper and you have the password).

How do you disable LLMNR and NBT-NS? You want to use group policies. While a registry modification would work, you want group policy to enforce the change on any systems which may have been missed, any new systems, and any unsupported maintenance.

https://www.sternsecurity.com/blog/local-network-attacks-llmnr-and-nbt-ns-poisoning

http://blog.westmonroepartners.com/secure-nbt-ns-poisoning-attacks/

There is a feature that will stop working when LLMNR is disabled: ad hoc networking will fail.

https://blogs.technet.microsoft.com/networking/2008/04/01/how-to-benefit-from-link-local-multicast-name-resolution/

 

 


Ending unsolicited email (SPAM)

January 10, 2017

The traditional email acceptance model is to accept email unless you have a reason to reject it. Trust, unless there is a reason not to. The spammer sends emails; recipients complain and filters are adjusted to block the current batch. The spammer makes changes that avoid the filters, and the cycle continues.

One such filter is sender’s IP address. Blocking email by sender IP address is a maintenance burden made worse by IPv6.

The model needs to change to one that accepts only those sources where there is a reason to trust. The solution must extend the current email mechanisms when adding a trust mechanism.

Part of the solution is for the sender to implement a Sender Policy Framework (SPF) text record in the Domain Name System (DNS). The SPF record lists which IP addresses are permitted to email on behalf of the domain. The recipient’s email server (Mail Transfer Agent or MTA) can compare the sending IP address with those listed in the DNS. The MTA can make informed decisions about whether to accept the email without requiring maintenance.

A DomainKeys Identified Mail (DKIM) text record in the DNS enables the sending organization the sign messages. The DKIM record contains a public key from a asymmetric RSA key pair. The recipient’s MTA can verify that the message was sent by the organization which claims to have sent it.

A Domain-based Message Authentication, Reporting & Conformance (DMARC) text record in the DNS indicates the recommended disposition of an email which fails SPF source verification or DKIM authentication. The recipient MTA could be advised to accept the email, accept the email as spam, or reject the email.

Responsible mail senders are advised to implement SPF, DKIM, and DMARC quickly. Email recipients will want a no-maintenance method for disposing of spam.

https://blogs.msdn.microsoft.com/tzink/2016/02/19/common-errors-in-spf-records/


My Web Site Was Hacked?

December 27, 2015

If someone may be using your site to participate in a DDoS attack, it may be due to a configuration error: You may want to see what ports you have open.

http://www.t1shopper.com/tools/port-scan/

Is someone using you to perform a denial of service attack on someone else? It is not just an annoyance to someone else, it also uses bandwidth that costs you money.

Test for misconfigured NTP server (UDP port 123)

http://openntpproject.org/

Test for open recursive DNS resolver (UDP port 53)

http://www.openresolver.com/

If chargen (port 19) is found, disable it. This antiquated service is of no use to you and can be used to attack others.

If LDAP (port 389) is found, determine if exposing your email server is necessary. Best practices say it is not. If your mail server must be exposed to the Internet, make sure UDP port 389 (connectionless LDAP or CLDAP) is not exposed to the Internet. This service can be used to attack others.

That list is UDP ports 19, 53, 123 and 389.

About participating in WordPress Pingback DDoS attacks

https://isc.sans.edu//forums/diary/Wordpress+Pingback+DDoS+Attacks/17801

http://fooplugins.com/prevent-wordpress-pingback-ddos/

Is someone using you to send spam? Test for an open SMTP mail relay (port 25)

http://www.mailradar.com/openrelay/

The above attacks (NTP, DNS, Chargen, and WordPress Pingback DDoS attacks, as well as using you to send spam) do not indicate that you have lost information or that a virus has infected your system. They indicate that someone is taking advantage of a misconfiguration to use your site for their own purposes and make it look like you are responsible.

On the other hand, you can loose information and host viruses through other misconfiguration choices. PHP-based web sites (using Joomla, WordPress or Drupal for example) are often compromised through vulnerable plugins. For examples and corrective measures, see C99Shell not dead.

WordPress best practices https://bestvpn.org/bloggers-guide-to-wordpress-security/

WordPress Security Scan‍ https://hackertarget.com/wordpress-security-scan/
wpscan‍ https://wpscan.org/
WPscans‍ https://wpscans.com/
Web Shell Detector http://www.shelldetector.com/
PHP-Shell-Detector https://github.com/emposha/PHP-Shell-Detector
PHP-backdoor-detector https://github.com/yassineaddi/PHP-backdoor-detector


OWASP Top 10

November 5, 2014

Use the OWASP Application Security Verification Standard. Do not limit your focus to the OWASP Top 10 Vulnerabilities.

SQL Injection (SQLi)

Problem: Malicious user input is interpreted as a database query.

Cause: The malicious user input has had inadequate data validation by the web tier.

Detection: If you have the application tier source code, review it. If you don’t, mechanically test through the web tier (e.g., sqlmap).

Mitigation: Parametrize queries in the application; that is, use variables in prepared SQL statements. Never construct queries by concatenating user input. If you don’t have access to the application source code, use an already available known and proven HTML sanitizer. SQL Injection can be mitigated with a Web Application Firewall.

See Secure Web Application Development

  • Use Parameterized APIs for Data Access
  • Use Positive Input Validation
  • Avoid Using Command Interpreters
  • Escape Special Characters, If Parameterized APIs Are Not Available

https://www.owasp.org/index.php/Top_10_2010-A1
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet

Cross-site Scripting (XSS)

Problem: Malicious user input is displayed on a web page. The user’s web browser processes the malicious input, attacking themselves. The user shot themselves, but didn’t know they were holding a gun.

Cause: The malicious user input has had inadequate data validation by the web tier.

Detection: If you have the application tier source code, see the OWASP Code Review Guide article on Reviewing code for Cross-site scripting Vulnerabilities.  If you don’t, then the Browser Exploitation Framework (BeEF), XSS Cheat Sheet, burp and manual tests would be a start.

Mitigation: Use safe re-encoding of the user input before it is displayed on a web page. Use an already available known and proven encoder such as OWASP ESAPI. Input validation is often used, but displaying content in a safe manner is to be preferred. Cross-site scripting can be mitigated with a Web Application Firewall.

  • Escape All Untrusted Data in HTML Contexts
  • Use Positive Input Validation

https://www.owasp.org/index.php/Top_10_2010-A2
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

Session Hijacking

Problem: In order to maintain a conversation, a web application needs to keep track of where it left off. The web application needs to preserve a session’s state. A person can impersonate a web application’s state, the web application can take incorrect actions.

Cause: Session tokens (how you maintain state in web applications) are passed in clear text.

Detection: Review packet captures for tokens passed in clear text.

Mitigation: Encrypt communication using HTTPS. Additionally, use session inactivity timeouts.

  • Centralize Authentication and Session Management Controls
  • Protect Session IDs from XSS

https://www.owasp.org/index.php/Top_10_2010-A3
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

Parameter Manipulation (Insecure Direct Object References)

Cause: User supplies a value in the URL and the application accepts it.

Detection: Review packet captures for URL parameters.

Mitigation: If you have access to the application, server-side validation should be used. Is the returned value acceptable? Are there errors in business logic? Additionally, use session parameters (where the data elements are stored on the server side and accessed through the session identifier) instead of URL parameters (which are exposed on the client side). If you don’t have access to the application … a web application firewall can help sanitize input, but cannot prevent that input from being modified and cannot fix errors in business logic.

  • Use Per-User or Per-Session Indirect Object References
  • [OR] Check Access Control Permissions Whenever Performing Direct Object References
  • Disable Directory Browsing

https://www.owasp.org/index.php/Top_10_2010-A4

Cross-site Request Forgery (CSRF)

Problem: The user establishes an authenticated session. The user then connects to an unrelated site. The unrelated site takes advantage of the user’s authenticated session to perform actions.

Cause: The user’s intended web application supports URLs which can specify complete session information using parameters. The unrelated site performs the unauthorized action through a crafted URL. The URL requires no user interaction, or minimal interaction.

Detection: Review web application for URL parameters. Review packet captures for URL parameters.

Mitigation: If you have access to the application, implement CSRF session tokens (for each page a new token is created and hidden on the user’s web page; the server checks the next transaction for the predetermined token). Session timeouts would limit the availability of authenticated sessions. Re-authentication before the transaction is completed would require user interaction.

  • Include Unique Tokens in HTTP Requests

https://www.owasp.org/index.php/Top_10_2010-A5
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet

CSRF Proof of Concept with OWASP ZAP

ASP.NET: The anti-forgery token can be used to help protect your application against cross-site request forgery. To use this feature, call the AntiForgeryToken method from a form and add the ValidateAntiForgeryTokenAttribute attribute to the action method that you want to protect.

Security Misconfiguration (Insecure Configuration)

Cause: Insufficient hardening. Lack of configuration management process. Lack of account management process. Lack of patch management process. Security patches not installed, unnecessary services enabled, default passwords, excessive permissions

Detection:

Mitigation: Repeatable hardening process. Recurring inventory and audits.

  • Establish A Repeatable Hardening Process
  • Keep Up with Security Updates
  • Design a Strong Application Architecture
  • Run Scans and Perform Audits

https://www.owasp.org/index.php/Top_10_2010-A6
https://www.owasp.org/index.php/Security_Architecture_Cheat_Sheet

Insecure Cryptographic Storage

Cause: Sensitive information is stored or transmitted in an insecure manner. The cryptographic method may be obsolete or the implementation may be weak.

Detection:

Mitigation: There may be specific regulatory requirements to consider. Review information to determine if it is sensitive and if it should be stored. (Classify assets, model realistic weaknesses, determine threats which may exploit those weaknesses, implement defenses.) Use known, strong encryption methods, long keys and a key management system.

  • Consider the Threats You Plan to Protect Data from
  • Encrypt Off-site Backups
  • Ensure Strong Algorithms Are Used
  • Hash and Salt Passwords
  • Protect Keys and Passwords

https://www.owasp.org/index.php/Top_10_2010-A7
https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet

Failure to Restrict URL Access (Forced Browsing)

Cause: Incorrect web server configuration. Insufficient restrictions in application logic. User can guess a URL that  provides access to information or processes that should be restricted.

Detection: Crawl the application for page access. Should these pages be exposed? Test exposed pages for insufficient authorization enforcement.

Mitigation: Authorization checks within the application. Page level authorization at the web server. Can be mitigated with a Web Application Firewall.

  • Require Authentication and Authorization for Each Sensitive Page
  • Use Role-based Authentication and Authorization
  • Make Authentication and Authorization Policies Configurable
  • Deny All Access by Default

https://www.owasp.org/index.php/Top_10_2010-A8

Insufficient Transport Layer Protection (Clear-text Communication, Cookie Poisoning)

Cause: Sensitive information is sent unencrypted. This could include unencrypted session cookies which, if exposed, can be used to impersonate the authenticated user (capture their session).

Detection: Review packet captures for sensitive information passed in clear text.

Mitigation: Implement “always on” SSL (HTTPS) with strong keys (greater then 128 bit ciphers) and disable weaker protocols (SSLv1, SSLv2, SSLv3). Implement a key management policy. Alternately, encrypt the sensitive information (such as cookies) and sign it (so it cannot be modified). Consider disabling HTTP if the site is sensitive. Can be mitigated with a Web Application Firewall.

  • Enable SSL
  • Use SSL for All Sensitive Pages
  • Set the Secure Flag on All Sensitive Cookies
  • Use Only Strong SSL Algorithms
  • Use Valid SSL Certificates
  • Secure Backend Connections

https://www.owasp.org/index.php/Top_10_2010-A9
https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

Unvalidated Redirects and Forwards (Unchecked Redirects)

Cause: Lack of validation when using forms or parameters to forward or redirect users. This enables hackers to use your site as a trusted name or domain when redirecting to their malicious site.

Detection:

Mitigation: Don’t use parameters to forward or redirect users. Use session information stored on the server. Alternately, whitelist the URLs that the user can be forwarded to and verify that the user has authority to access the web page.

  • Don’t Use Redirects or Forwards, If Possible
  • Don’t Use User Input for Calculating Destinations of Redirects or Forwards
  • Use Mapping Values When Calculating Destinations of Redirects or Forwards

https://www.owasp.org/index.php/Top_10_2010-A10

Read the rest of this entry »