Month: March 2016

Alienvault Certified Security Engineer (ACSE)

acse

After a slight delay, our company now have an Alienvault Certified Security Engineer (ACSE)

To be honest, a lot of customers still go “What?” when we talk about AlienVault, but we hope to get more and more people acquainted with the product. Especially in PCI-DSS, it simply works. Having an ACSE goes a long way to ensure our commitment to provide the best services we can to our clients.

The exam itself is around 70 – 75 multiple choice questions over 90 minutes. You will likely not use the full 90 minutes, but it basically will give you enough time to think it over. Frankly for me, it’s simply either I know it or I don’t. And for those that I don’t know (and for sure, there will be a number of them), well, take a shot.

It had a good mixture of linux questions, user interface questions, overall architecture and how AV works, so you need to know not just the theory but you will need to get your hands dirty with the system. Luckily, Alienvault provides a free 30 day trial to install in VMWare ESXi – which itself has a trial period of 60 days, so I recommend that you get this up and running and do some testing. Without hands on experience, you will find it difficult to answer a lot of the questions – unless you are a good (and lucky) chooser.

If you don’t have the resources to set up VMWare and the 30 day trial of Alienvault, you could get OSSIM (the free version) up and running on any virtualbox system (including your laptop). Be warned though, it might tax your resource a little, so make sure you have sufficient RAM and Hard drive to do it. I won’t recommend it on any system under i5. I run on Core i7 with 16GB of Memory and I am still struggling with OSSIM running in virtualbox (of course, having multiple Linux systems and a CISCO emulator installed doesn’t help as well).

Overall, the ACSE covers a good balance of technical and theory, and worth taking. It will certainly help as we prepare for numerous Proof Of Concepts ahead of us!

Alienvault with NXLog

For various reasons unknown to mankind, Windows has a very retarded relationship with logs. Because it was designed without any inkling of networking or internet in mind, Windows logs are very local and very stupid. I don’t know why, maybe because whoever created windows never really thought that their OS will be in a networked environment.

Anyway, to get Windows to work with a sort of syslog capability, NXLog can be used. In the next few articles, we will explore how to get it working, because like everything else in Windows, it needs some work. 10 years from now, our children will probably do the same thing by clicking an icon and everything magically works. For now, its back to CLI.

First – NxLog runs on TCP 514. Alienvault by default listens on UDP only.

Go ahead to /etc/rsyslog.conf 

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

The ones in bold were commented, so just go ahead uncomment it and service rsyslog restart.

Do a netstat -tulpen | grep rsyslog and you should see it listening. For good measure, do nc – vt 127.0.0.1 514 and it will say its open.

Done!

Not really. Alienvault has additional issues. For some reason, even if you turn off Alienvault Firewall from the setup menu, you still cannot telnet to 514 from another system. Something is obviously blocking it.

I will assume you have installed nxlog in your windows. In nxlog.conf under C:\Program Files (x86)\nxlog\conf, you should see

<Output out-5141>
#Send to central nxlog listener on tcp port 5141, change host address
Module om_tcp
Host xxx.xxx.xxx.xxx
Port 514
OutputType LineBased
</Output>

Just replace the xxx with the IP of your Alienvault

Go ahead to

C:\Program Files (x86)\nxlog\data\nxlog.log

You might encounter

2016-03-23 10:31:47 ERROR couldn’t connect to tcp socket on <IP ADDRESS>:514; A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.  

Obviously, the IP is your Alienvault IP. This generally means there is some issue. Try telneting to port 514 from your Windows and you will get a timeout.

On your Alienvault

VirtualUSMAllInOne:/var/log# tcpdump -i eth0 “tcp port 514”

Restart your nxlog on your windows and you will see some packets coming in. It’s just not connecting. This shows you that the packets are reaching your AV, but for some nefarious reason your AV is not willing to talk.

Firewall?

As I mentioned, disabling firewall on the Alienvault menu doesn’t help because…I don’t know. It just doesn’t.

Luckily, we know a secret.

/etc/ossim/firewall_include

This little file is where you configure your policies for firewall. Just add

-A INPUT -p tcp -m state –state NEW -m tcp –dport 514 -j ACCEPT

At the bottom. This opens up the port 514 to chat.

Now, you need to reload the ossim config. No, service ossim-server restart or service ossim-agent restart won’t work. You need to do the full ossim-reconfig.

Once that is done, do a telnet again, or a tcpdump or check the nxlog log (after restarting).

2016-03-23 11:12:08 INFO nxlog-ce-2.8.1248 started
2016-03-23 11:12:08 INFO connecting to <IP ADDRESS>:514

Your port 514 is open now.

We will configure NXlog in the next article to send logs over to Alienvault.

DROWN Vulnerability: Cross-protocol attack on TLS using SSLv2

This is a security advisory on the DROWN Attack (CVE-2016-0800).

What is DROWN Attack (CVE-2016-0800)

DROWN, stands for “Decrypting RSA with Obsolete and Weakened eNcryption”, is a serious vulnerability that affects HTTPS and other services that rely on SSL and TLS, some of the essential cryptographic protocols for Internet security. These protocols allow everyone on the Internet to browse the web, use email, shop online, and send instant messages without third-parties being able to read the communication.

Any communication between users and the server, typically includes, but is not limited to, usernames and passwords, credit card numbers, emails, instant messages, and other sensitive information. Under some common scenarios, an attacker can also impersonate a secure website and intercept or change the content the user sees.

A group of security researchers discovered that SSLv2 (Secure Sockets Layer protocol version 2.0) is vulnerable to the Bleichenbacher RSA padding oracle attack, which can be used to decrypt RSA cipher text without the knowledge of the matching private RSA key. This can be done by observing responses from a server that has the private key and performs the decryption of attacker-provided cipher texts using that key. A cross-protocol attack was discovered that could lead to decryption of TLS sessions by using a server supporting SSLv2 and export cipher suites such as Bleichenbacher RSA padding oracle. The cross-protocol attack allows decryption of SSL/TLS sessions using newer protocol versions – SSLv3 or any current TLS (Transport Layer Security) version (1.0 – 1.2) – using this SSLv2 weakness. Note that traffic between clients and non-vulnerable servers can be decrypted provided another server supporting SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP) shares the RSA keys of the non-vulnerable server (CVE-2016-0800. This flaw is SSLv2 protocol issue and affects all implementations of the protocol.

Who is Vulnerable?

Websites, mail servers, and other TLS-dependent services are at risk for the DROWN attack.

How to check if server is vulnerable?

A server is vulnerable to DROWN if:

  • It allows SSLv2 connections. This is surprisingly common, due to misconfiguration and inappropriate default settings.
  • Its private key is used on any other server that allows SSLv2 connections, even for another protocol.

How to fix

It is recommend to:

  • Ensure that servers private keys are not used anywhere with server software that allows SSLv2 connections. This includes web servers, SMTP servers, IMAP and POP servers, and any other software that supports SSL/TLS.
  • OpenSSL 1.0.2 users should upgrade to 1.0.2g, OpenSSL 1.0.1 users should upgrade to 1.0.1s
  • Disable the complete support of SSLv2 by following the vendor’s advisory:
    Internet Information Services (IIS)

    Apache

    Postfix

    Nginx

    IBM HTTP Server

© 2024 PKF AvantEdge

Up ↑