Infrastructure Information Security

Device profiling may at first sound abstract to some readers, so let me first explain what this is.  Device profiling is any mechanism that helps you determine the fingerprint of your device. The fingerprint may be any set of determinations whether your device is running Linux or Windows operating system, what its FQDN is, what version of particular software (antivirus etc.) it runs, maybe even contact details of the system administrator responsible for administering it. This fingerprint can be extracted from various application protocols that the device is using to communicate with the networked resources - it may be using SNMP to allow various diagnostic data about its interfaces, DNS to identify its own name or to resolve other names, Cisco Discovery  Protocol to identify features of neighboring Cisco devices, DHCP to require the IP address, DNS server, default gateway IP address etc.  So, where exactly would such a profiler sit and how does the whole thing work in a real life?  Fir

 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

 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

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