Suspicious DNS Requests ... Issued by a Firewall
An anonymous reader contacted us because he noticed DNS requests for malicious domains originating from his Windows machine, even before he opened a browser.
Looking at the provided capture file, I noticed indeed DNS requests for malicious domains, but also for security related domains, like ClamAV. But these DNS requests were not followed by TCP connections.
With more information provided by the reader, I could confirm one of my theories: on his Windows machine, the reader was using a firewall (Privatefirewall) that accepts rules with domain names to allow/block. There were rules designed to block access to the malicious domain names this reader was noticing.
Here I configure it to block www.example.com (on 32-bit Windows, the firewall hanged on my 64-bit Windows VM):
To establish TCP connections, a destination IP address is needed: hostnames like www.example.com have to be translated to an IP address before a TCP connection can be established.
Likewise, for a firewall to block TCP connections with rules with hostnames, the firewall has to lookup these hostnames via DNS requests.
This is what this firewall does, soon after user logon.
It's not an indication of malicious activity, but normal behavior of a security tool that has to translate hostnames to IP addresses to be able to do its job.
Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com
The danger of sending information for API consumption without adequate security measures
by Manuel Humberto Santander Pelaez (Version: 1)
Migrating an on-premise application to the cloud can bring numerous business advantages to companies, among which we have fast deployment times and reusability of functions and decrease complexity in operation and evolution through the use of microservices that are communicated through of the use of API.
During the work of the course for the conformation of incident response teams that I direct at Instituto Tecnológico Metropolitano in Medellín, Colombia, we noticed the following case of a production API: there is an API that is consumed to perform the authentication of a fingerprint that was read through an APP located in a mobile phone. The fingerprint is digitalized using the Wavelet Scalar Quantization (WSQ) Gray-scale Fingerprint Image Compression Algorithm, which is the standard for the exchange of 8-bit, 500ppi fingerprint images, used as well in the criminal justice community. If you have and enforced connection with controls like HTTP Strict Transport Security (HSTS), Perfect Forward Secrecy (PFS) and mutual TLS cert authentication, you will have a strong protection against man-in-the-middle attacks. If not, your connection might be tampered. The following snippet was captured when performing an MITM (snippet truncated for security purposes):
Base64 is not a good choice to hide information. When you decode this information, you get a binary file which is in WSQ format. We will use the NIST Biometric Image Software Mirror located at https://github.com/lessandro/nbis to decode it and then we have a complete fingerprint that can be used to impersonate the owner's identity (truncated for security purposes):
How can you enforce the confidentiality and integrity of the communication and message?
- Make sure you have implemented HSTS, PFS and mutual TLS cert authentication.
- If using XML, the XML message must be crypted as well. You can follow the XML Encryption Syntax and Processing guide to review the best options for your application.
- If using JSON, you can use JSON Web Encryption (JWE) RFC.
Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
Comments