To be or not to be - hacked - a "visitor"

It took it's time or I didn't even notice :-) before I got a visitor. And when it finaly happened it was not as exciting as I had hoped. So where did the attempts origin from? A typical week you would see something like this:

 1.93.24.0/24 | CN | DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. 
1.93.0.0/16 | CN | CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 
1.93.0.0/16 | CN | CNIX-AP China Networks Inter-Exchange 
120.194.0.0/16 | CN | CMNET-V4HENAN-AS-AP Henan Mobile Communications Co.,Ltd 
120.236.0.0/16 | CN | CMNET-GUANGDONG-AP China Mobile communications corporation 
122.154.0.0/16 | TH | CAT-AP The Communication Authoity of Thailand, CAT 
182.73.0.0/16 | IN | BBIL-AP BHARTI Airtel Ltd. 
222.33.0.0/16 | CN | CTTNET China TieTong Telecommunications Corporation 
88.198.0.0/16 | DE | HETZNER-AS Hetzner Online AG 
91.236.116.0/24 | NL | PORTLANE Portlane Networks AB 
114.80.192.0/19 | CN | CHINANET-SH-AP China Telecom (Group) 
115.236.0.0/17 | CN | CHINANET-BACKBONE No.31,Jin-rong Street 
117.239.208.0/20 | IN | BSNL-NIB National Internet Backbone 
123.108.108.0/22 | HK | PANGNET-AS-AP Pang International Limited-AS number 
179.88.0.0/15 | BR | TELEFÔNICA BRASIL S.A 
192.81.208.0/21 | US | SERVERSTACK-ASN - ServerStack, Inc. 
201.249.48.0/20 | VE | CANTV Servicios, Venezuela 
218.26.0.0/16 | CN | CHINA169-BACKBONE CNCGROUP China169 Backbone 
222.186.30.0/24 | CN | CHINANET-JS-AS-AP AS Number for CHINANET jiangsu province backbone 
60.220.0.0/14 | CN | CHINA169-BACKBONE CNCGROUP China169 Backbone 
62.212.64.0/19 | NL | LEASEWEB LeaseWeb B.V. 
64.251.0.0/19 | US | INFOLINK-MIA-US - Infolink 
77.40.48.0/22 | RU | MARTELCOM-AS OJSC Rostelecom 
78.94.0.0/17 | DE | UNITYMEDIA Unitymedia NRW GmbH 
93.174.88.0/21 | NL | ECATEL-AS AS29073, Ecatel Network
 
And when finally some one found the provided ssh user/pwd combo of admin/admin. Is it actually possible that this is something that someone, other than me :-), makes available on the internet. Below is the sequence of comands used on the first, and only visit. Waited a good 14 days for the second visit that didnt come.
So this is what we done in the only visit.

sshd[23781]: Accepted password for admin from 78.94.37.56 port 56255 ssh2 
sshd[23781]: pam_unix(sshd:session): session opened for user admin by (uid=0) 
admin: admin [23820]: ls [0] 
admin: admin [23820]: cat /etc/issue [0] 
admin: admin [23820]: cat /etc/hosts [0] 
sudo: admin : TTY=pts/1 ; PWD=/home/admin ; USER=root ; COMMAND=/bin/su 
sudo: pam_unix(sudo:session): session opened for user root by admin(uid=0) 
su[23988]: Successful su for root by root 
su[23988]: + /dev/pts/1 root:root 
su[23988]: pam_unix(su:session): session opened for user root by admin(uid=0) 
admin: root [23989]: nano .bash_history [0] 
su[23988]: pam_unix(su:session): session closed for user root 
sudo: pam_unix(sudo:session): session closed for user root 
admin: admin [23820]: sudo su [0] 
admin: admin [23820]: passwd admin [10] 
passwd[24030]: pam_unix(passwd:chauthtok): authentication failure; logname=admin uid=1001 euid=0 tty= ruser= rhost= user=admin 
admin: admin [23820]: passwd admin [10] 
admin: admin [23820]: passwd admin [10] 
admin: admin [23820]: passwd admin [10]
admin: admin [23820]: passwd admin [10] 
admin: admin [23820]: passwd admin [10] 
admin: admin [23820]: passwd admin [10] 
passwd[24086]: pam_unix(passwd:chauthtok): password changed for admin 
gnome-keyring-daemon[24095]: Gck: gck_module_new: assertion 'funcs != NULL' failed 
gnome-keyring-daemon[24095]: module_instances: assertion 'module' failed 
gnome-keyring-daemon[24095]: egg_error_message: assertion 'error' failed 
gnome-keyring-daemon[24095]: couldn't find secret store module: (unknown) 
gnome-keyring-daemon[24095]: lookup_login_keyring: assertion 'GCK_IS_SESSION (session)' failed 
gnome-keyring-daemon[24095]: create_credential: assertion 'GCK_IS_SESSION (session)' failed 
gnome-keyring-daemon[24095]: egg_error_message: assertion 'error' failed 
gnome-keyring-daemon[24095]: couldn't create new login credential: (unknown) 
passwd[24086]: gkr-pam: couldn't change password for the login keyring: the passwords didn't match. 
admin: admin [23820]: passwd [0] 
sudo: admin : TTY=pts/1 ; PWD=/home/admin ; USER=root ; COMMAND=/bin/su 
sudo: pam_unix(sudo:session): session opened for user root by admin(uid=0) 
su[24165]: Successful su for root by root 
su[24165]: Successful su for root by root  
su[24165]: + /dev/pts/1 root:root 
su[24165]: pam_unix(su:session): session opened for user root by admin(uid=0) 
admin: root [24166]: nano .bash_history [0] 
admin: root [24166]: nano .bash_history [130] 
admin: root [24166]: history [0] 
admin: root [24166]: ls -la [0] 
admin: root [24166]: cat .bash_history [0] 
admin: root [24166]: rm -rf .sudo_as_admin_successful [0] 
admin: root [24166]: ls -la [0] 
admin: root [24166]: ls -la [130] 
admin: root [24166]: cd [0] 
admin: root [24166]: ls -la [0] 
admin: root [24166]: cat .bash_history [0] 
admin: root [24166]: nano /bin/h [0] 
admin: root [24166]: chmod +x /bin/h [0]
admin: root [24166]: h [1] 
useradd[24348]: new group: name=http, GID=1002
useradd[24348]: new user: name=http, UID=0, GID=1002, home=/home/http, shell=/bin/sh
admin: root [24166]: /usr/sbin/useradd -o -u 0 http [0]
passwd[24361]: pam_unix(passwd:chauthtok): password changed for http
passwd[24361]: gkr-pam: couldn't update the login keyring password: no old password was entered
admin: root [24166]: passwd http [0]
admin: root [24166]: ls -la [0]
admin: root [24166]: cat /etc/passwd [0]
admin: root [24166]: cat /etc/gshadow [0]
admin: root [24166]: cat /etc/group [0]
admin: root [24166]: passwd shadow [1]
admin: root [24166]: passwd shadow [130]
useradd[24491]: failed adding user 'http', data deleted
admin: root [24166]: /usr/sbin/useradd -o -u 0 http [9]
useradd[24500]: failed adding user 'shadow', data deleted
admin: root [24166]: /usr/sbin/useradd -o -u 0 shadow [9]
admin: root [24166]: /usr/sbin/useradd -o -u 0 shadow [130]
admin: root [24166]: passwd shadow [1]
admin: root [24166]: cat /etc/passwd [0]
admin: root [24166]: paswd libuuid [127]
passwd[24546]: pam_unix(passwd:chauthtok): password changed for libuuid 
passwd[24546]: gkr-pam: couldn't update the login keyring password: no old password was entered
admin: root [24166]: passwd libuuid [0]
admin: root [24166]: ls -la [0]
admin: root [24166]: history [0]
admin: root [24166]: [0]
admin: root [24166]: ls -la [0]
admin: root [24166]: ls -la /var/backups/ [0]
admin: root [24166]: cp /etc/shadow /var/backups/shadow.bak [0]
admin: root [24166]: cp /etc/passwd /var/backups/passwd.bak [0]
admin: root [24166]: cp /etc/gshadow /var/backups/gshadow.bak [0]
admin: root [24166]: cp /etc/group /var/backups/group.bak [0]
admin: root [24166]: cp /etc/group /var/backups/group.bak [0]
admin: root [24166]: cp /etc/gshadow /etc/gshadow- [0]
admin: root [24166]: cp /etc/shadow /etc/shadow- [0]
admin: root [24166]: cp /etc/group /etc/group- [0]
admin: root [24166]: cp /etc/passwd /etc/passwd- [0]
admin: root [24166]: ls -la /var/backups/ [0]
su[24165]: pam_unix(su:session): session closed for user root sudo: pam_unix(sudo:session): session closed for user root 
admin: admin [23820]: sudo su [0]
sshd[23781]: syslogin_perform_logout: logout() returned an error N


Comments

Post a Comment

Popular posts from this blog

Possible SYN flooding on port 3306 (MySQL)

The system setup is such that the MySQL servers that put the "Possible SYN flooding on port 3306" in the log files only are exposed to system internal backend services. These in turn aren't exposed to the wild wild web. Fronting the system we have the servers publishing services to internet. Thus I was kind of stunned when the log messages started to appear and even though we had done a release of the system I found it far fetched that we should start to DOS our self. So why did the messages appear? Two different error messages could be identified in the log files and they seem to be related, especially since the Java servers with link failure do communicate with the MySQL servers. Possible SYN flooding on port 3306 @ MySQL server Communication link failure @ Java backend servers After some tcpdumping, head scratching and googling I think I have it down to the root cause, hidden in how TCP works in general, and the OS config in combi...
Read more

Part 1 - Disaster Recovery with SRM and vSphere Replication

Image
Abstract  The company I work for has needs for disaster recovery but there is also external demands for it. The company not being very big has so far not been able to implement any automated disaster recovery solution although we do have a documented disaster recovery plan. The plan regardless of how good or bad it is isn't tested in a long time and the RTO (Recovery Time Objective) is wished by management to be days but I can't see that it is anything else than weeks. Since we virtualized our production system I've been looking at VMware vCenter Site Recovery Manager as a driver but the cost array based replication has stopped any attempts dead in their tracks. VMware vSphere® Replication has been around for a while now and we hope that it's hardened enough for a slightly bigger production critical implementation. In this article I will try to document and explain how we experiment, design and implement disaster recovery and even more important, in my opinion...
Read more

Part 2 - Disaster Recovery with SRM and vSphere Replication

Image
In the previous article we went through the installation and configuration of the SRM and vSphere infrastructure. The time has now come to actually doing some tests and failover some VM's.  In the simple scenario I expect everything to go smoothly but there are a few things that I'm concerned about at this point since the protected environment I'm ultimately is failing over isn't so simple. It has multiple dvSwitches, vLans, load balancer, firewall, ldap, a set of test drivers to verify the integrity of the system and access to the system in a sensible way for administrators so there are a few things that needs to be resolved. Protected Setup Test Failover The small test In this scenario I do a test failover of a single machine and verifies that it starts and that I can log into it. The steps are: Setup the machine running RHEL 5.5.  Install VMware tools  Kick of the vSphere Replication Create a Protection Group and ... no that didn...
Read more