Infrastructure Information Security

This article will be a certain departure from the heavily technical blogs that I have published so far. This one is more of a philosophic and moral meandering around what one feels is the right thing to do in the spirit of a professional commitment and obstacles that threat one's financial or professional reputation. Recently, I discovered two previously unknown vulnerabilities in the products of two reputable vendors however, vendors that are focused on highly specialised areas of telecom business. Lack of their proper engagement is the reason I will not detail their names, products or intricacies of their products' vulnerabilities. In both cases I was following guidelines of a responsible security disclosure - a procedure where one informs the vendor of the specifics of the vulnerabilities in their product and refrains from publishing the discovery until vendors agree it's safe to do so. Mostly, one would publish the research when the respective vendor developed and r...

 In today's blog I will outline some steps aimed toward the inspection of the information Checkpoint Firewall exposes to an unauthenticated access. This remote gathering therefore assumes no internal information about the firewall - blackbox approach with only the IP address of the firewall known. In this particular case I had an IP address assigned to the firewall management interface (which will be exposed only internally in most of the cases).  Below is the description of the steps, tools and approach I used in the assessment. I started the assessment by looking at the publicly available tools for either information gathering or exploiting the Checkpoint. Not much was found, but one of the tools that attracted my attention was a metasploit module found in auxiliary/gather/checkpoint_hostname. This module retrieves the names of the firewall enforcement module and its management server. One only needs to specify the IP address and the port of the Checkpoint. I found that seve...

Recently I came across a dilemma when faced with proposal of a client to use password protected ZIP archives intended to be sent over email to 3rd party. Plain email protocols such as SMTP were not designed with security considerations. SMTP is a plain text protocol that, once intercepted, would allow an unauthorised individual to recover the content of the respective email. There are options to send SMTP via SSL (Socket Secure Layer), but this requires that the destination SMTP server also supports SMTP over SSL, and RFCs related to SMTP do not mandate SSL.The task was then to assess the security of a password protected ZIP files. Google search reveals several tools worth trying against password cracking, but they are all based on brute force attacks of some kind. Given the customer uses sufficiently strong password, the question remains - how strong are password protected ZIP files? I decided to design a little experiment with the following setup. I will create the total of four ...

This article will outline the major steps required to check and troubleshoot some simple defects in SNMPv3. The reason why I am specifically focusing on SNMPv3 is the fact that since its version 3, SNMP has introduced authentication and encryption, often referred to "Auth" and "Ident". Bear in mind that this article does not contain step-by-step full procedure to configure SNMP, only outlines some basic errors and ways how to diagnose them. To start with, one needs to create a user. Before that we will stop the snmpd service and only create the user after the service has been stopped. This is shown in the Figure above. Note that the user requires both password for authentication ("authPassword1") , hashing algorithm for password ("SHA"), encryption pre-shared key ("encryptPassword1") and symmetric encryption algorithm ("AES").  The next step is checking if the restarted SNMP service is listening on its default (161) UDP...

In this article I will elaborate the research I did in relation to DNS (Domain Name Service). The particular issue discussed here is when and how DNS uses TCP or UDP transport layer in relation to the packet size. Normally, DNS will run queries and replies via UDP protocol unless there is a Zone Transfer , incremental or full (IXFR or AXFR , respectively). According to the original DNS specification as given in the RFC 1035 (https://www.ietf.org/rfc/rfc1035.txt), DNS will also use TCP for packets larger than 512 bytes. However, there was another RFC issued in 2013 which is RFC 6891 (Extension Mechanism for DNS), labelled as EDNS(0). https://tools.ietf.org/html/rfc6891 I came across this issue accidentally, but as we will see in the text, some issues were noticed that are some not well documented reasons why DNS may fail to comply with EDNS. To do the proper investigation, here are some assumptions I worked with: a) I wanted to check DNS clients from both Windows and Linux b) I wan...