Category Archives: Security Blogs

Start-up Security Guide – DIY Style no

photo-1585144499819-651e1c1c97ec

Inspired by this blog by Isaiah Sarju and this presentation given during the 2017 Denver Startup Week, I am sharing my own version: A DIY (do it yourself) Cybersecurity Guide for Startups!

This guide includes some of my favorite resources that I believe can serve as a great starting point for founders to use and build a strong security foundation for their startups.

Please make sure you check-out Isaiah’s post and the Denver presentation above; both of these are extremely thoughtful and valuable pieces!

Category Resources
Start Here Security Planner, DIY Cybersecurity, Take-Five (financial fraud focus), APWG, SSD
Multi-Factor Authentication Availability TwoFactorAuth
Password Manager Quick Guide, Password Strength Test, Identify Compromised Account
Browser Extensions Privacy Badger, HTTPS Everywhere,
Application Security OWASP, Checklist/EBooks, Secure Coding Course, DIY Hack
Sensitive Info Sharing Wire, Wire’s Audit, Signal, Signal’s Audit
System Encryption PC, MAC: Src1, Src2 Portal Media: Src1, Src2
OS Update PC, MAC
VPN Background, Comparison
Separate Work & Personal on a Budget VirtualBox, VMWare Player, Workstation Pro, MAC Fusion, Trial Virtual Machines, Live OS
The principle of Least Privilege Windows 10, Windows 7, MAC OS
Backup Everything PC, MAC
Who’s Watching Privacy Screens, Webcam Covers
Prevent Accidental Data Exchange SyncStop
Report Abuse / Take Down Request AWS, Azure, Google Cloud, Salesforce, Cloudflare
Check/Request Domain Category Google, Windows Defender, Norton, Symantec, McAfee, Palo Alto, Web of Trust
Internet Crime Complaint Center IC3
Public Security Page Security Page
Phishing Report APWG
Security Education/Awareness Stop.Think.Connect, Interactive Game, Safe Online,
Sector-based Information Sharing and Analysis Centers ISACs
Cyber Readiness Index by Country CRI

Report Google: to report an incorrect marked page as phishing to Google: https://safebrowsing.google.com/safebrowsing/report_error/?hl=en

If you found this helpful please let me know by sending me your comment and feedback below!

I plan to keep this a live list so if you know of a resource that is not already listed but will benefit others, feel free to share and I will make sure to include it!

Also, as you may know, Phishing remains as the most common tactic used by attackers to compromise both companies and individuals.
“Three out of ten people will open a phishing email while one of those will proceed to click on the link, possible infecting not only their own computer but the whole firm”. – Ref.

As part of this post, I am offering a practical, hands-on training on how you can triage and respond to Phishing attacks to protect yourself, your employees and ultimately your company.

Complete the form below and let me know if you would like to learn more!

Tagged , , ,

Free IDS and Full Packet Capture Software

Recently, I have been involved in configuring an Intrusion Detection System IDS (IDS) with full packet capture using the SecurityOnion distribution (distro) in the production environment. Previously, I had set up a SOHO IDS environment when I was learning during the first Compromise, Detect, and Respond (CDR) project. But that IDS deployment was done using a different distro and it also did not have the full packet capture capabilities. So to better familiarize myself with SecurityOnion, I decided to do a quick post about it.

Just in case you are not familiar with SecurityOnion, you can check out their awesome page here. I am not going to try to explain much about the distro itself because my explanation will not do it enough justice. Besides, their website has a whole lot more information than I can provide. They do a great job of explaining how you can start from scratch and have a system up and running in no time. They even go over how you can customize it for your specific environment and maintain the system going forward.

I followed the installation steps here and the post-installation guide here and within an hour, give or take, I had the IDS up and running (including the time it took to download the 1.3GB ISO image over my home connection). And just like my previous labs, the whole setup here was very simple: I used my laptop’s VMware Workstation for the SecurityOnion. I placed the network interface in promiscuous mode to capture traffic from the host. Note: this method typically results in a significant packet loss, however, it is fine for just practice.

NETWORK PROMISCUOUS MODE

Enabling and verifying promiscuous mode configuration

After finishing the IDS configuration, my Snorby screen looked like the above. You will notice that there isn’t much activity here compared to what we saw during the first CDR project. The main reason for this is that in the previous setup we had Metasploit running and had been running exploits, but this setup is a vanilla setup. Nevertheless, it’s pleasing to be able to get basic IDS up and running easily and quickly.

So, in order to generate some interesting IDS alerts, I set up TOR in my test environment, and as you can see, it has triggered some high severity events:
Sample Alert

Now we can select any of the above alerts to view the packet details. Here are the steps for that: Select the event that you want to analyze > Select “Packet Capture Options” on the top right-hand corner > select “Custom” and then “Fetch Packet“.

Packet Analysis

After you have completed the above steps, you will be presented with a new page: “capME!”

CapME

After logging into the new interface above, you will be able to view the assembled packet behind the event. Pretty cool, huh?!

But our IDS interface is only displaying events that have some potential malicious behavior associated with them. However, there are a whole lot of packets stored in the back end of our SecurityOnion server that we can review via the following path: /nsm/sensor_data/seconion-virtual-machine-eth0/dailylogs:

DailyLogs

You will now see logs broken up into multiple files. Depending on the volume, you may see several files for each day. In my case, there are only two files (2014-11-27 is the latest and has the most amount of data).

We can open the snot.log.xxxxxxxxx file using a number of tools, e.g. Wireshark, TCPdump, SiLK, Netwitness, etc. I opened mine using Wireshark (depending on the file size and your machine’s power, this may take some time).

TOR traffic was definitely the loudest, making up most of the logs:

Encrypted Traffic

And when we try to reassemble it, this is what we get:

TCP Stream_Encrypted

Enabling and verifying promiscuous mode configuration

But by looking at the Protocol Stats, we notice that there is a bunch of other traffic in this capture as well:

Traffic Protocol Statistics Wireshark Protocol Hierarchy ]

Now, we will do some SiLK kung-fu and see what we can pull out of this capture.
The first step is to open the snot.log.xxxxxxxxx file using Wireshark (or any similar tool) and save it as a new .pcap file. In the second step, I used SiLK’s rwp2yaf2sillk to convert our newly created .pcap file into flow format.

# rwp2yaf2silk –in=1417046408.pcap –out=1417046408.silk

Now, we will go through the basic analysis on our capture using various SiLK commands.

5 largest senders of bytes of data:largest-senders

5 TCP connection per source and destination IP:5-tcp-connections

Show all records from the capture with either a source or destination IP of TOR:specific-ip-find

TCP flows with a source IP of our VM and determines the top 5 destination ports by the number of flow records:top-5-destination-ports

Per above output, the majority of our destination ports are 443, with the second largest being port 9001 with 15 total records. Let’s see the amount of data associated with this port:unique-port

Now, as the last step, we will go back to Wireshark and see if we can find the data that is going to port 9001:TCP Port eq 9001Based on the above, it seems like the traffic generated on port 9001 (default TOR port) are simply connection synchronization attempts followed by erupt connection resets.

Anyway, this concludes my quick walk through on setting up IDS with full packet capture using the SecurityOnion distro.  If you are looking for a great IDS and Full PCAP solution on a shoestring budget, this is it!

Tagged , , , , ,

KRACK WPA2 Wi-Fi Vulnerability

A serious security vulnerability in wireless (Wi-Fi) protocol has been identified: KRACK, short for Key Reinstallation Attack. Comprehensive details on the vulnerability and proof-of-concept exploitation video can be found on vulnerability’s official website:  https://www.krackattacks.com/

Great vulnerability summary and what to do:

Monitor & Remediate: 

Assigned CVEs:

  • CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the four-way handshake.
  • CVE-2017-13078: Reinstallation of the group key (GTK) in the four-way handshake.
  • CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the four-way handshake.
  • CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
  • CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
  • CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
  • CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
  • CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
  • CVE-2017-13087: reinstallation of the group key (GTK) while processing a Wireless Network Management (WNM) Sleep Mode Response frame.
  • CVE-2017-13088: reinstallation of the integrity group key (IGTK) while processing a Wireless Network Management (WNM) Sleep Mode Response frame.

List of Affected Vendors:

*Nix Distributions:

Additional References:

 

Tagged , ,

Burp Suite installation and features

The other day I came across a social media post that was about utilizing Burp Suite to identify vulnerabilities in web applications. I had heard of Burp before but never really had the chance to play around with it – until now.

Just like a lot of other security tools, Burp has a community version along with its commercial product. I decided to download the free edition from here in my home lab.  The installation process is straightforward and in no time you have Burp up and running. Here is how the initial interface looks like:

Burp

Right when I finished my installation of  Burp, I realized that I did not have a web application running in my lab that I could use to test Burp against. Bummer! Now I had to decide between setting up a web server myself or finding a commercial distribution that came pre-built with one. This was a no-brainer – and within minutes I found a few distributions that were designed for testing and learning web application security; such as SamuraiWTF, WebGoat and Kali Web Application Metapackages. I decided to go with SamuraiWTF.

SamuraiWTF gives you the option to run from a live disk or install it in a VM. I decided to install the VM. Here is a good guide to the installation process. I give my VM instance 4GB RAM and 3 cores; more than enough horsepower.

This distribution comes pre-installed with Mutillidae, which is a “free, open source, deliberately vulnerable web-application providing a target for web-security enthusiasts”. This was perfect for what I was looking for. Setting up the Mutillidae in pretty simple – all I had to do was change my network configurations to NAT and that was it. However, if you need more information on configuration here are some great video guides on Mutillidae; in fact, I used some of these myself while configuring Burp to work with Mutilliade.

After finishing all of the above prep work, I was ready to run Burp!

For those who are not familiar with Burp, it’s an interception proxy which sits between your browser and the web server and by doing so it is able to intercept requests/responses and provides you the ability to manipulate the content. To do so you have to configure Burp as your proxy. On your VM, this would be your localhost (Proxy Tab > Options):

Proxy

Likewise, you would have to configure your browser to that same proxy. Here is my proxy configuration on Firefox:

Firefox Proxy Configuration

Now as you navigate through your Mutilliadae webpage, all your requests should go through Burp. One thing you have to do is turn on the Intercept option in Burp. It’s under Proxy > Intercept.

What this allows you to do is see the request as its made but gives you the control to either forward it to the web server or simply drop the request (like a typical MiTM). For example, on the login page of Mutilliade i used admin name and admin123 password. And as soon as I hit “Login” I saw the request being made from my browser to the web server in Burp:

Burp Intercept

In the screenshot above, you can see the two options: Forward and Drop. If you hit forward, the web server will receive this request from your browser and will respond as it would normally. In this case, the account I used to log in did not exist:

Web Server Respose

Burp has the capability to also capture the responses. It is an option that you can turn on by going to Proxy > Options and towards the middle of the page you will see “Intercept Server Responses”. By turning this on you will be able to see and control both sides of the requests:

Request and Response

If you look at Target > Site Map; on the left pane you will see a list of all the sites that you have visited with the Burp proxy on:

History Map

One advantage of the above feature is that it allows you to go back and revisit requests and responses. The sites that are in grey color are those that are available on the target web page but you have not visited them.

Another neat feature is that if you do not want to visit each page individually you can run the “Spider” feature which will map the whole target page for you.

Spider

If you go under Spider > Control you are able to see the status of the Spider as it runs:

Spider Status

When you intercept request or response, you have the ability to send that to other features of Burp. You are able to view these additional options by right-clicking on the intercept:

Intercept Additional Options

Towards the bottom of the official Burp Suite guide page here you can see a brief description of most of the options shown in the screenshot above. The one I found really neat is the “Repeater” option which allows you to modify and re-transmit requests repeatedly without having the need to perform new intercepts each time.

This concludes my brief journey of getting started with Burp using SamuraiWTF. There is a whole lot more than I had the chance to explore but here is a great reference for advanced topics.

Below  is a quick blurb on some of Burps features:

Spider: crawls the target and saves the numerous web pages that are on the target.

Intruder: automated attack feature which tries to automagically determine which parameters can be targeted i.e. fuzzing.

Fuzzing options: Sniper (fuzz each position one-by-one), Battering Ram (all positions on the target receive one payload), Pitchfork (each target position is fuzzed in parallel) Cluster Bomb (repeats through payloads for multiple positions at once).

Proxy: used to capture requests & responses to either just monitor or manipulate and replay.

Scope: controls what (pages, sites) is in/out of the test “scope”.

Repeater: manually resubmit requests/responses; allows modification.

Sequencer: used to detect predictability of session tokens using various built-in tests i.e. FIPS 140-2.

Decoder: allows encoding/decoding of the target data i.e. BASE64, Hex, Gzip, ASCII, etc.

Comparer: allows side-by-side analysis between two requests/responses.

Cheers!

Tagged , , ,
Advertisements