Tag: security

cyberstorm.mu meetup on OpenSource Licensing with Dr Till Jaeger

It was a great opportunity to meet with Dr. Till Jaeger, Attorney at Law on cybersecurity, laws, trademarks and opensource licensing on Tuesday the 02nd of October 2018 at Flying Dodo, Bagatelle Mall. The event was announced on the official cyberstorm.mu community Facebook group by Logan days back. Those present for the meetup was Loganaden Velvindron, Jagveer Loky, Rahul Golam, Kifah Meeran, Veegish Ramdani, Muzaffar Auhammud, Jeremie Daniel and myself from the cyberstorm.mu team.

Who is Dr. Till Jaeger? – Till Jaeger has been a partner at JBB Rechtsanwälte since 2001. He advises large and medium-sized IT businesses as well as government authorities and software developers on matters involving contracts, licensing and online use. Till Jaeger also covers conventional areas of copyright law and entertainment law, advising corporate clients on matters relating to open content, web design and photography. – Source: JBB.DE

Some pictures during the informal event:

 

OpenSource licensing with Dr. Till Jaeger and cyberstorm.mu

42935540_10212323570864049_8368692107799429120_n
42968234_10212323572504090_2567889336288673792_n
42950830_10212323576784197_4654246000414687232_n
43006824_10212323574624143_3826122953662136320_n
42972026_10212323735508165_2228714038051733504_n
42985512_10212323573544116_1829255669769830400_n
43021478_10212323736348186_8197301708435488768_n
43070514_249074402474539_4146444367671853056_n
43097410_10212323575984177_8134476138010378240_n
43119656_10212323575344161_97068219394686976_n
51e27cd0-87f1-402d-a02a-474cf81b9f39
Screen Shot 2018-10-07 at 6.59.57 PM
Screen Shot 2018-10-07 at 7.00.09 PM
Screen Shot 2018-10-07 at 6.59.25 PM
Screen Shot 2018-10-07 at 6.59.25 PM

I should admit that it was really an informal meeting over some beers, juice, Dame-Blanche, and Pizzas with Dr. Till Jaeger. It was very fruitful and amazing to the team. We received lots of advice for ourselves as well as for the cyberstorm.mu team. Some days back, the National Computer Board conducted a workshop on Opensource licensing which where Dr. Till Jaeger was the main resource person to deliver this workshop. Thanks to the National Computer Board for making this event a success. Cyberstorm.mu members were also invited to the event.

We have also welcomed Rahul Golam for joining cyberstorm.mu team and looking forward to work together. I seized this opportunity to announce that cyberstorm.mu  is proud to announce it’s official logo. Thanks to the hard work of the team.


Photo Credits: cyberstorm.mu
Photo Credits: cyberstorm.mu
Photo Credits: cyberstorm.mu
Photo Credits: cyberstorm.mu

IETF 102 hackathon remotely from Mauritius

The hackers.mu team has been participating in several IETF hackathons these recent years. For the IETF 102 hackathon, we focused tremendously on innovation: The goal to create two teams for the TLS 1.3 project, one for the Implementation team and the other is Interop. At the same time, getting hands on the HTTP 451 project. The IETF hackathon encourages developers to collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. It is not a competition but a collaborative event.

For this IETF hackathon, myself and Loganaden Velvindron core members of hackers.mu team decided to lead the event. We searched a marvelous venue at Pointe aux Piments, a remote coastal area in the north-west of Mauritius which was very peaceful and can accommodate the whole team including first-timers of the IETF hackathon for three nights. As regards food, the best place is at Triolet, a village nearby which is famous for street foods including Pizza, Indian food, Grilled, Burgers and Brianis. We also chose that venue as it included a WiFi hotspot, several rooms, bathrooms and even a swimming pool.

The participants from the hackers.mu team was: Loganaden Velvindron, Rahul Golam, Kifah Sheik Meeran, Nigel Yong Sao Young Steven Ken Fouk, Muzaffar Auhammud, Codarren Velvindron, Yasir Aulear and myself – Nitin J Mutkawoa. As regards to the first-timers were: Veegish Ramdani, Jeremie Daniel, Jagveer Loky, Nathan Sunil Mangar and Avishai Poorun.

On day 1, we all set up our lab environments and since most first-timers were in the TLS 1.3 Interoperability team, a plan was already designed. We knew since the beginning that there would be the logistic issues, so we brought spare laptops, screens, memory card, projector etc.. Logan explained the situation we had to deal with especially when it comes to interoperability to the first-timers. Then, they assigned themselves some tasks. At first, it was time-consuming to get started, but at the end of day1, I can feel how everyone was working as a team and looking in the same direction for the TLS 1.3. On the other hand, Veegish was getting hands-on HTTP 451. Whilst the Interoperability team was having fun, the implementation team, on the other hand, was yet another challenge: Improving source code for TLS 1.3 compat layer.

On day 2, everyone woke up early and went for a morning walk. Afterward, the team was back to coding and debugging. Whilst some were on the implementation and Interoperability tasks, Veegish already advanced on the HTTP 451 project. A debrief carried out by logan to understand where the team stands. We had to constantly evaluate ourselves so that we knew in which direction we are moving. At the end of the day, most of us were already in the pool for some chilling moments. I seized the opportunity to make a Time Lapse video with my iPhone 7+ 🙂

On day 3, the atmosphere was intense. The implementation team needs to make sure the code has been tested and it is running correctly. I was heavily involved in the PHP CURL library part. The testing part was very challenging. At some moment I was so tired and hopeless as the testing part was really complex. At the same time, others were trying to help each other. Kifah was also on some bash scripting for the interoperability part. He wanted to automate some tasks. Logan was also looking at his code and helping the others. Well, at the end of the day we were so happy to be able to accomplish what we had planned. Everyone looked so tired. The only option is to go back to the pool.

We also decided to make some mini videoS to relate our experience during the hackathon. I uploaded the videos on YouTube. You can view it from the playlist below:

On day 4, we packed up to our destination. At that very moment in Montreal, the hackathon was still going on. I reached home at about 19:00 hrs Mauritius time. I was assigned a three minutes presentation for the hackathon carried out by the Mauritius team. It was already midnight. I was so tired. I knew that the presentation had to be carried out. Logan was constantly texting me to make sure that I did not fall asleep. You can view the presentation remotely live in Montreal Canada.

What did IETF hackers say about the IETF 102 hackathon?

“What I think was the most productive output during this time for me was pair-programming…” – Kifah

“I was very excited to be part of the Inter-operability team where I worked with OpenSSL, BoringSSL, WolfSSL, and tlslite using TLS1.3 protocols.” – Jagveer

“Making Internet Protocols great again during the IETF 102 hackathon” – Logan

“Finally after long hours of debugging he managed to test the protocol being used by NRPE locally” – Rahul

“Then… we finally got a Client Hello from Wireshark and made the PR” – Nigel

“At first I thought that it would only be working, working and working but besides of work we started creating bonds.” – Jeremie

“I got a lot of advice, support, and motivation to work with my team members and try to implement on a strategic basis and critical thinking the internet protocols and see their limit on a technical perspective.” – Avishai

“Once OpenSSL was installed, I then performed my first TLS 1.3 Handshake, Resumption, and 0-RTT but did run into difficulties with NSS.” – Chromico

“But while everyone is waiting, we are working. We have reached a deeper understanding of how it will affect our lives.” – Codarren

“IETF 102 was very fun and challenging experience in which I got to work on several opensource projects” – Muzaffar

“At first, I did encounter some issues like parsing JSON files, but I manage to work on those issues” – Veegish

We also had a follower on Twitter appreciating our effort and participation during the IETF 102 hackathon. Thanks, Dan York, senior manager at ISOC.

I’m happy that this hackathon was at the required level. It was a great initiative from the hackers.mu team. No major incidents occurred in our HQ at Pointe aux Piments. Everything that was planned went all and it’s worth investing yourself in this collaborative event.

Operation JASK – Just a Single Keystroke

Apart from the IETF hackathons, the hackers.mu team also focused on internal hackathon either remotely or on-site participation. Another remote hackathon was already in progress since Saturday the 16th of June 2018. It was named Operation JASK – Just a Single Keystroke. Announced publicly on Sunday the 17th of June 2018 after noticing that several Crypto currency mining tools were vulnerable to CVE-2018-12356. By the time, many members of the team were already mobilised even if it was a public holiday in Mauritius. The operation was named JASK – Just a Single Keystroke as the security issues is concerned with the hardening of a regular expression, in particular requiring [GNUPG:] to be at the beginning of a line (^\[GNUPG:\]). We had to fire a single keystroke at the right place to fix a single vulnerability.

Marcus Brinkmann, who is a free software activist explained “An issue was discovered in password-store.sh in pass in Simple Password Store 1.7 through 1.7.1. The signature verification routine parses the output of GnuPG with an incomplete regular expression, which allows remote attackers to spoof file signatures on configuration files and extensions scripts. Modifying the configuration file allows the attacker to inject additional encryption keys under their control, thereby disclosing passwords to the attacker. Modifying the extension scripts allows the attacker arbitrary code execution.” 

However, simple the patch is, the attack aimed GnuPG signature verification process which is specific to pass the Simple Password Store. It can give the attacker access to passwords and remote code execution. On theRegister.co.uk – Pass gets a fail: Simple Password Store suffers GnuPG spoofing bug, Loganaden Velvindron core member of the hackers.mu explained “It’s hard to identify just how many downstream projects inherit a vulnerability like the one Brinkmann spotted, but the number of problem projects will likely be non-trivial because the GnuPG cryptography suite has applications beyond e-mail protection.”

The hackers.mu usual suspects during Operation JASK hackathon are: Kifah Meeran, Loganaden Velvindron, Rahul Golam, Muzaffar Auhammud, Nigel Yong and myself (Nitin J Mutkawoa) all members from the hackers.mu. Some of the projects are Bitcoin, Litecoin, Dash, Bitcoin Gold, Monacoin, Binarium, Terracoin, SmartCash and many other crypto currency projects.

Hackers.mu is now looking forward for other hackathons. We are also inviting everyone to meet us at Flying Dodo Bagatelle conference room for the Security Disclosure Process event. Feel free to RSVP on meetup.com  and Facebook before attending.

Linux memory analysis with Lime and Volatility

Lime is a Loadable Kernel Module (LKM) which allows for volatile memory acquisition from Linux and Linux-based devices, such as Android. This makes LiME unique as it is the first tool that allows for full memory captures on Android devices. It also minimises its interaction between user and kernel space processes during acquisition, which allows it to produce memory captures that are more forensically sound than those of other tools designed for Linux memory acquisition. – Lime. Volatility framework was released at Black Hat DC for analysis of memory during forensic investigations.

Analysing memory in Linux can be carried out using Lime which is a forensic tool to dump the memory. I am actually using CentOS 6 distribution installed on a Virtual Box to acquire memory. Normally before capturing the memory, the suspicious system’s architecture should be well known. May be you would need to compile Lime on the the suspicious machine itself if you do not know the architecture. Once you compile Lime, you would have a kernel loadable object which can be injected in the Linux Kernel itself.

Linux memory dump with Lime

1. You will first need to download Lime on the suspicious machine.

git clone https://github.com/504ensicsLabs/LiME

2. Do the compilation of Lime. Once it has been compiled, you will noticed the creation of the Lime loadable kernel object.

make

3. Now the kernel object have to be loaded into the kernel. Insert the kernel module. Then, define the location and format to save the memory image.

insmod lime-2.6.32-696.23.1.el6.x86_64.ko "path=/Linux64.mem format=lime"

4. You can view if the module have been successfully loaded.

lsmod | grep -i lime

Analysis with Volatility

5. We will now analyze the memory dump using Volatility. Download it from Github.

git clone https://github.com/volatilityfoundation/volatility

6.  Now, we will create a Linux profile. We will also need to download the DwarfDump package. Once it is downloaded go to Tools -> Linux directory, then create the module.dwarf file.

yum install epel-release libdwarf-tools -y && make

7. To proceed further, the System.map file is important to build the profile. The System.map file contains the locations of all the functions active in the compiled kernel. You will notice it inside the /boot directory. It is also important to corroborate the version appended with the System.map file together the version and architecture of the kernel. In the example below, the version is 2.6.32-696.23.1.el6.x86_64.

8. Now, go to the root of the Volatility directory using cd ../../ since I assumed that you are in the linux directory. Then, create a zip file as follows:

zip volatility/plugins/overlays/linux/Centos6-2632.zip tools/linux/module.dwarf /boot/System.map-2.6.32-696.23.1.el6.x86_64

9. The volatility module has now been successfully created as indicated in part 8 for the particular version of the Linux and kernel version. Time to have fun with some Python script. You can view the profile created with the following command:

python vol.py --info | grep Linux

As you can see the profile LinuxCentos6-2632 profile has been created.

10. Volatile contains plugins to view details about the memory dump performed. To view the plugins or parsers, use the following command:

python vol.py --info | grep -i linux_

11. Now imagine that you want to see the processes running at the time of the memory dump. You will have to execute the vol.py script, specify the location of the memory dump, define the profile created and call the parser concerned.

python vol.py --file=/Linux64.mem --profile=LinuxCentos6-2632x64 linux_psscan

12. Another example to recover the routing cache memory:

python vol.py --file=/Linux64.mem --profile=LinuxCentos6-2632x64 linux_route_cache

Automating Lime using LiMEaid

I find the LiMEaid tools really interesting to remote executing of Lime. “LiMEaide is a python application designed to remotely dump RAM of a Linux client and create a volatility profile for later analysis on your local host. I hope that this will simplify Linux digital forensics in a remote environment. In order to use LiMEaide all you need to do is feed a remote Linux client IP address, sit back, and consume your favorite caffeinated beverage.” – LiMEaid

Tips:

  • Linux architecture is very important when dealing with Lime. This is probably the first question that one would ask.
  • The kernel-headers package is a must to create the kernel loadable object.
  • Once a memory dump have been created, its important to take a hash value. It can be done using the command md5sum Linux64.mem
  • I would also consider to download the devel tools using yum groupinstall “Development Tools” -y
  • As good practice as indicated in part 8 when creating the zip file, use the proper convention when naming the file. In my case I used the OS version and the kernel version for future references.
  • Not all Parsers/Plugins will work with Volatile as same might not be compatible with the Linux system.
  • You can check out the Volatile wiki for more info about the Parsers.

 

Auditing Linux Operating System with Lynis

Auditing a Linux System is one of the most important aspect when it comes to security. After deploying a simple Centos 7 Linux machine on virtual box, I made an audit using Lynis. It is amazing how many tiny flaws can be seen right from the beginning of a fresh installation. Lynis Enterprise performs security scanning for Linux, macOS, and Unix systems. It helps you discover and solve issues quickly, so you can focus on your business and projects again.Cisofy.

Credits: cisofy.com
Credits: cisofy.com

Introduction

The Lynis tool performs both security and compliance auditing. It has a free and paid version which comes very handy especially if you are on a business environment. The installation of the Lynis tool is pretty simple. You can install it through the Linux repository itself, download the tar file or clone it directly from Github.

 

Scanning Performed by Lynis

1. I downloaded the tar file with the following command:

wget https://cisofy.com/files/lynis-2.6.0.tar.gz

2. Then, just untar the file and get into it

tar -xzf lynis-2.6.0.tar.gz && cd lynis

3. Once into the untar directory, launch the following command:

./lynis audit system --quick

 
As you can see from the output above, there are several suggestions at the end of the scan. In case the paid version of the application was used, more information and commands as how to remediate the situation would be given including support from Lynis. As regards to the free version, you can also debug by yourself several security aspects from the suggestions.
 
Suggestions, Compliance and Improvement.

 
1.The first two suggestions were about minimum and maximum password age.

Configure minimum password age in /etc/login.defs [AUTH-9286]

Configure maximum password age in /etc/login.defs [AUTH-9286]

To check the minimum and maximum password age, use the chage command :
chage -l
 

2. Use chage -m root to set the minimum password age and chage -M root to set maximum password age:

Also, you will have to set the parameter in the /etc/login.defs file

3. Delete accounts which are no longer used [AUTH-9288]

It is also suggested to delete accounts which are no longer in use. This suggestion was prompted as I created a user  “nitin” account during installation and did not use it yet. For the purpose of this blog, I deleted it using userdel -r nitin

4. Default umask in /etc/profile or /etc/profile.d/custom.sh could be more strict (e.g. 027) [AUTH-9328]

Default umask values are taken from the information provided in the /etc/login.defs file for RHEL (Red Hat) based distros. Debian and Ubuntu Linux based system use /etc/deluser.conf. To change default umask value to 027 which is actually 022 by default, you will need to modify the /etc/profile script as follows:

5. To decrease the impact of a full /home file system, place /home on a separated partition [FILE-6310]

  To decrease the impact of a full /tmp file system, place /tmp on a separated partition [FILE-6310]

  To decrease the impact of a full /var file system, place /var on a separated partition [FILE-6310]

In the article Move your /home to another partition, you will have detailed explanations to sort out this issue.

6. Disable drivers like USB storage when not used, to prevent unauthorized storage or data theft [STRG-1840]

   Disable drivers like firewire storage when not used, to prevent unauthorized storage or data theft [STRG-1846]

To disable USB and firewire storage drivers, add the following lines in /etc/modprobe.d/blacklist.conf then do a modprobe usb-storage && modprobe firewire-core

blacklist firewire-core
blacklist usb-storage

7. Split resolving between localhost and the hostname of the system [NAME-4406]

This issue is only about hostname and localhost in /etc/hosts which could confuse some applications installed on the machine. According to cisofy, for proper resolving, the entries of localhost and the local defined hostname, could be split. Using some middleware and some applications, resolving of the hostname to localhost, might confuse the software.

8. Install package ‘yum-utils’ for better consistency checking of the package database [PKGS-7384]

      Consider running ARP monitoring software (arpwatch,arpon) [NETW-3032]

The yum-utils and arpwatch are nice tools to perform more debugging and verification. Install it using the following commands:

yum install yum-utils arpwatch -y

9. You are advised to hide the mail_name (option: smtpd_banner) from your postfix configuration. Use postconf -e or change your main.cf file (/etc/postfix/main.cf) [MAIL-8818]

You just have to uncomment the following line and lauch a postconf -e. However, since this is a fresh install, and I’m not using postfix, it is better to stop the service.

 10.  Check iptables rules to see which rules are currently not used [FIRE-4513]

Since, I’m not on a production environment, it is very difficult to identify unused iptables rules right now. Once on the production environment, this situation is different. According to Cisofy, the best way is to “use iptables –list –numeric –verbose to display all rules. Check for rules which didn’t get a hit and repeat this process several times (e.g. in a few weeks). Finally remove any unneeded rules.”

 11. Consider hardening SSH configuration [SSH-7408]

  •     – Details  : AllowTcpForwarding (YES –> NO)
  •     – Details  : ClientAliveCountMax (3 –> 2)
  •     – Details  : Compression (YES –> (DELAYED|NO))
  •     – Details  : LogLevel (INFO –> VERBOSE)
  •     – Details  : MaxAuthTries (6 –> 2)
  •     – Details  : MaxSessions (10 –> 2)
  •     – Details  : PermitRootLogin (YES –> NO)
  •     – Details  : Port (22 –> )
  •     – Details  : TCPKeepAlive (YES –> NO)
  •     – Details  : UseDNS (YES –> NO)
  •     – Details  : X11Forwarding (YES –> NO)
  •     – Details  : AllowAgentForwarding (YES –> NO)

Again, hardening SSH is one of the most important to evade attacks especially from SSH bots. It all depends how your network infrastructure is configured and whether it is accessible from the internet or not. However, these details viewed are very informative.

12. Periodic system scan, malware and ransomware scanners are now a must. According to statistics, servers are being hacked constantly. Pervasive Monitoring is becoming a heavy cash deal for malicious softwares. 

The Lynis Command

Lynis documentation is pretty straight forward with a cheat sheet. The arguments are self explicit. Here are some hints.

1.Performs a system audit which is the most common audit.

lynis audit system

2. Provides command to do a remote scan.

lynis audit system remote <host>

3. Views the settings of default profile.

lynis show settings

4. Checks if you are using most recent version of Lynis

lynis update info

5. More information about a specific test-id

lynis show details <test-id>

6. To scan whole system

lynix --check-all Q

7. To see all available parameters of Lynis

lynis show options

At the end of any Lynis command, it will also prompt you where the logs have been stored for your future references. It is usually in /var/log/lynis.log. The systutorial on lynis is also a good start to grasp the command. All common systems based on Unix/Linux are supported. Examples include Linux, AIX, *BSD, HP-UX, macOS and Solaris. For package management, the following tools are supported:- dpkg/apt, pacman, pkg_info, RPM, YUM, zypper.