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.


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:


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.



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



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.



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




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.


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.


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)


Test for open recursive DNS resolver (UDP port 53)


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



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


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


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


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


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


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


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


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


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.


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


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


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


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.


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


Read the rest of this entry »

Security Awareness Training

October 19, 2014

Security Awareness Training Framework Wiki

Measuring Human Risk: What is Your Organization’s Security Score? The methodology and results of a multi-year human security risk assessment and security awareness initiative at Michigan Technological University.

This presentation covers effective security awareness training and measuring its effectiveness. When I was doing security awareness training it was largely saying the same thing as last time, expecting a different result. Additional ideas were always appreciated. This presentation is worth listening to and the handout contains useful information.
Securing The Human in EMEA – Next Generation Awareness Programs
Confidentiality – only authorized / appropriate persons have access to the particular information
Integrity – accurate and adequately complete information
Availability – all authorized persons have access as needed
Accountability – actions cannot be repudiated
Authentication – validate the agent
Authorization – control which agents can access which assets
Accounting – determine which agents access which assets and what they did there
Property Threat
Authentication Spoofing
Integrity Tampering
Non-Repudiation Repudiation
Confidentiality Disclosure
Availability Denial of Service
Authorization Elevation of Privilege
WASC Threat Classification
OWASP Application Security Verification Standard 2009 (pdf)

New hire initial assessment

October 9, 2014

You’ve just been hired and Information Security is now your responsibility.

Who has immediate concerns?

Introduce yourself and ask what most concerns them. Get their names. This is for your use only. Try to remember their names. Can you take a photograph?


NIST Special Publication 800-115: Technical Guide to Information Security Testing and Assessment [pdf]

What company policies and regulatory requirements exist? What compliance programs (SOX, PCI, HIPAA, SSAE 16) must be observed?

Individual Products

The National Checklist Program (NCP), defined by the NIST SP 800-70 Rev. 2, is the U.S. government repository of publicly available security checklists (or benchmarks) that provide detailed low level guidance on setting the security configuration of operating systems and applications. NCP is migrating its repository of checklists to conform to the Security Content Automation Protocol (SCAP). SCAP enables standards based security tools to automatically perform configuration checking using NCP checklists. For more information relating to the NCP please visit the information page or the glossary of terms.

Risk Assessment

The SANS 20 Critical Controls

  • When doing the inventory of authorized and unauthorized software. include software composition analysis. What libraries are being used? Do these libraries have vulnerabilities?

The California Department of Technology Risk Assessment Toolkit has links to great resources.

Prioritize Tasks

What gaps do you you fill first?

There will always be risk. What level of risk is acceptable?


Check your work. Repeat.