Posts

Oracle Network Encryption

Image
 This article will discuss some internals of the Oracle Network Encryption. Generally, there are two ways how you can protect the transmission of the data between application server and the Oracle DB. One way is to deploy TLS, certificate based wrapper around communication channel. This method will not be discussed here. Another way is to deploy Oracle Network Encryption and is the subject of this discussion. When I first tried to evaluate Oracle Network Encryption I did not know the details of protection mechanism - I knew it encrypted DB traffic, that was all. Once the Network Encryption was setup with the server and client (application server), the next step was to run network sniffer and verify the encryption was taking place. Oracle documentation describes how you configure either thick client (Oracle dedicated DB client such as sqlplus) or thin client (jdbc client, which was our case here). Essentially, one needs to configure sqlnet.ora on the server side and sqlnet.ora on the cl

Identifying antimalware signature

Image
 Today's post will explain a simple method that allows you to identify a specific fragment of a binary file that your antimalware finds suspicious. This whole idea was born when I tried to download slammer.pcap file, with idea to see what this worm did with DCE RPC calls. As soon as I tried to download the file from  SampleCaptures - The Wireshark Wiki , my Endpoint Security agent triggered the alarm and deleted the file before it was written to the filesystem (and after it was downloaded). Note that this was no executable file format, the trigger was based on the inspection of a network capture (.pcap) file format. The first thing I intended to do was to download the file somehow and actually inspect it in wireshark and with various tools for binary manipulation to see what exactly is triggering the alert. Once I downloaded the file (via tunneling from NAT-ed virtual machine), I loaded it in the Wireshark, and this is what it looks like. At first glance, it was nothing much -appro

Two stories about how two responsible security disclosures failed

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

Checkpoint Firewall remote security assessment

Image
 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 several p

Security considerations of ZIP password protected files

Image
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

Troubleshooting SNMPv3

Image
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