Incident Response

April 11, 2018

I was recently asked to respond to the hypothetical situation “We just got hacked! Customer data is compromised. Build out a bulleted checklist of 10 things you need to do next.”

I could come up with only two. This is what you do next.

1.  Take out your incident response checklist and start gathering information.

  • What is the initial indicator of the event?
  • When did the initial indicator occur?
  • Who identified the initial indicator?
  • Is the indicator continuing to occur?
  • Has the initial indicator evolved?
  • Have any additional personnel been notified? Are they working on the event presently?
  • What business processes are affected?
  • What assets are affected and to what degree? For example, is there a system outage? Has intellectual property been lost? Has personally identifiable information been lost?

You are in the Identification phase of your Incident Response Plan. Document the current situation and why (in the hypothetical situation described) you believe customer data may be compromised.

2.  Take out your incident response team contact list and start calling the team members.

You are in the Containment phase of your Incident Response Plan. Let your incident response team know that customer data may have been compromised. Pass along the information from your incident response checklist.

That was what you do next. These two phases (Identification and Containment) should take minutes to complete. That requires preparation. What you do next relies upon what you did before.

A take-away from this exercise: If you are the on-call person, you have an incident response checklist and you have an incident response contact list. These should be physical, paper objects; do not rely upon computer access for your incident response documents.

These documents were created as part of preparatory work you have done; that is, they are products of the Preparation phase of your Incident Response plan.

With Preparation, Identification, and Containment phases complete, you move on to the Eradication, Recovery, and Lessons Learned phases.

What happens during the Eradication, Recovery and Lessons Learned phases will vary. For example, if a thumb drive containing unencrypted customer data has been lost, then you have limited next steps. Inform the executive, consult with the legal and public relations teams, and (in all likelihood) contact customers promptly.

On the other hand, if you see that an unknown person has system access, your actions would be more involved. The Containment phase has taken the system with customer data offline. The Eradication phase has determined how access was obtained and taken measures to prevent access from being restored once the customer data is back online. The customer data would no longer be trustworthy. The Recovery phase would require restoration from a known good backup. Updates since the backup have been lost. The Lessons Learn phase would implement measures that prevent access in the future.

You want your Preparation phase to go through more than these two scenarios in order to flesh-out the contact list, containment measures, eradication measures, and recovery measures. The incident response checklist should be fairly complete, but table-top exercises may indicate that other questions should be asked as well.


Can we get Joe Gray‍’s presentation “Dear Blue Team: Forensic Advice for System Admins, Engineers, and other Blue non-forensicators” (RSA, April 18, 2016)? That would be appropriate here. YouTube, slides on Peerlyst.


As part of your “malware detected” playbook, include VirusTotal (the premium offering, VirusTotal Intelligence, is preferred). See the SANS Webcast “Advanced Malware Threat Hunting and Investigation with VirusTotal Intelligence” (Apr 24, 2018).

Advertisements

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 »


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) requires 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

See also: the Identifying Phishing blog post at MxToolbox

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