MongoDB / NoSQL Database

Differences:

http://www.oracle.com/technetwork/database/database-technologies/nosqldb/documentation/nosql-vs-mongodb-1961723.pdf

Modelling methods:

Differences between SQL and NoSQL:

image9

image12

image15

Automated conversion of SQL to MongoDB syntax:

MySQL to MongoDB converter:

Update performance:

How kernel modules is loaded and organized in memory?

Just piecing together various resources from internet:

image3

image4

image5

image6

image7

image8

Linux userspace rootkit detector

Looking through the various rootkit detector:

A-Protect https://github.com/sincoder/A-Protect.git
Blackbone https://github.com/DarthTon/Blackbone.git
chkrootkit https://github.com/Magentron/chkrootkit.git
kjackal https://github.com/dgoulet/kjackal.git
ossec-hids https://github.com/ossec/ossec-hids.git
rootkit.com https://github.com/bowlofstew/rootkit.com.git
rootkit_detector https://github.com/Freedzone/rootkit_detector.git
rootkit-detector https://github.com/CMQY/rootkit-detector.git
ScDetective https://github.com/kedebug/ScDetective.git
wazuh https://github.com/wazuh/wazuh.git

Some are linux, and some are Windows. So here I am proposing more features to add to this technology – linux userspace rootkit detector (not kernel-based rootkit):

1. Dynamic library injection through LD_PRELOAD. So upon the startup of the process, the envionment variable LD_PRELOAD would have been defined. This is not common, but can be easily detected:

/proc/PID/environ will display all the environment variables upon starting up of process.

As you can see above, the environment variables are NULL terminated, and so “grep” will not work – which is newline based, but overcoming this is easy.

2. Network port opening: rootkit may be listening on certain ports waiting for incoming connections. Thus a simple “netstat” should reveal some abnormal listening ports.

3. Network connections: for a server which mainly deals with LAN-based transaction (eg, Oracle database) then all the communications most likely will arise from local communication. But the existence of a rootkit will disrupt this generalization adnd patterns. Some internet IP address in this communication exchanges will likely indicate the existence of internal LAN-based agent communicating with internet-based agents.

4. In dynamic library injection as described in (1) above, you will like to see some weird library files injected into the traditional locations of library files:

Either “lsof” or “cat /proc/PID/smaps” will reveal all the dynamic libraries loaded by the process:

Therefore detect the possible existence of outliers in the dynamic libraries enumeration – for example, the name of the library files can come from some other non-standard directories – is this normal?

BUT do take note that the non-existence of the dynamic files does not mean it is not used – a shellcode can be written to dynamically call dlopen() to load the library file.    (and then you have to use vulnerability to execute the shellcode).  And thereafter dlclose() it after use.

And there are so many other possibilities: what if a process is actively snooping on the keyboard buffer (for each terminal)? what if someone is listening on the mouse?

Doing a “dmesg|grep hda”, I can find a lot of references to /devices/pci* indicating things like /sound/cardx/inputy, or devices/*sound/card0/input0 – these are called “devfs”.

Two techniques are available:   Linux notification API and devices capturing program via devfs.

If you issue a “lsof” you can easily estimate how many mouse and keyboard listening processes are there: