I will be joining the guys over at the Linux Basix podcast tonight and below are some of the things I intend to discuss.
- 7 Best Network Security Linux Distributions (DoortoDoor): A list of special purpose distros [BackTrack, Network Security Toolkit(NST),Pentoo, nUbuntu(Network Ubuntu),Security Tools Distribution(STD),Helix,Damn Vulnerable Linux]. These distributions are mainly designed to perform network security tasks such as vulnerability assessment and penetration testing in order to prevent and monitor unauthorized entry, abuse, alteration, or denial of computer network resources. Since most of these distros are available as Live CDs, you could instantly try or use them without hard disk installation. Read more over at http://www.junauza.com/2011/01/network-security-linux-distros.html
- Soundminer: A Stealthy and Context-AwareSound Trojan for Smartphones: Researchers have developed a low-profile Trojan horse program for Google’s Android mobile OS that steals data in a way that is unlikely to be detected by either a user or antivirus software. The malware, called Soundminer, monitors phone calls and records when a person, for example, says their credit card number or enters one on the phone’s keypad, according to the study.Using various analysis techniques, Soundminer trims the extraneous recorded information down to the most essential, such as the credit card number itself, and sends just that small bit of information back to the attacker over the network, the researchers said. Read more over at http://www.csoonline.com/article/656264/soundminer-android-malware-listens-then-steals-phone-data
Tech Segment: Password reset the hard way
Problem: I was tasked with retrieving or resetting the web login password to a Linux based custom build system, very similar to an appliance. I currently had limited shell access to the system however I was not certain if the password was stored in /etc/passwd or in some sort of database on the system.
**Before we begin just know that everything mentioned here will probably not work on a normal Ubuntu based system, the manufacture possibly used their know custom Kernel and other system tweaks.**
- netstat – a command-line tool that displays network connections, routing tables, and a number of network interface statistics.
- fuser – a command line tool to identify processes using files or sockets.
- lsof – a command line tool to list open files under Linux / UNIX to report a list of all open files and the processes that opened them.
- /proc/$pid/ file system – Under Linux /proc includes a directory for each running process (including kernel processes) at /proc/PID, containing information about that process, notably including the processes name that opened port.
- uname- Print name of current system
Phase one “Getting to know the system”:
I started off with a few simple commands to try and identify what various of Linux was the system running:
uname -a (Verify what kernel version I was up against)
yum (To see if it was a Fedora based system)
apt-get (To see if it was an Ubuntu based system and it was)
cat /etc/issue (To check what flavor of Ubuntu, turned out it was “Ubuntu 8.04”)
Next I wanted to get Root access without resetting the Root account password. I figured this would prevent me from having to deal with any restrictions issues.
Created a user called testuser
user@host:~$ sudo adduser testuser
Edit the password file and changed UID and GID to that of root (testuser:x:0:0)
user@host:~$ sudo nano /etc/passwd
Then once I logged in newly created testuser and I am automatically given root access.
user@host:~$ su – testuser
Since I know that the service I am interest is running on port 443, I will run few commands to get a better ideal of whats really going on with this port.
Netstat to view the connection stated and PID for the services running on port 443:
root@host:~# netstat -tulpn | grep 443
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 5548/pound
To confirm the processes PID use the fuser command:
root@host:~# fuser 443/tcp
443/tcp: 5548 5549
To find out process name and working directory associated with PID # 5548, enter:
root@host:~# ls -l /proc/5548/exe
lrwxrwxrwx 1 root root 0 Jan 21 14:15 /proc/5548/exe -> /opt/pound/sbin/pound
root@host:~# ls -l /proc/5548/cwd
lrwxrwxrwx 1 root root 0 Jan 21 14:15 /proc/5548/cwd -> /opt/app_name/rails/ssl
Now I have an application name and working directory to go investigate. After further research I found out that Pound is a reverse-proxy load balancing server, and the config file showed me it was passing all connection on port 443 to another port on the same server.
I then used lsof to further investigate the newly discovered port:
root@host:# lsof -Pnl +M -i4
mongrel_r 5623 112 3u IPv4 14528 TCP 127.0.0.1:3000 (LISTEN)
Then to find out the processes own:
root@host:# ps aux | grep 5623
app_user 5623 0.0 1.3 40048 28536 ? Sl 14:14 0:02 /usr/bin/ruby1.8 /usr/bin/mongrel_rails start -d -e production -p 3000 -a 127.0.0.1 -P log/mongrel.3000.pid –user app_user –group app_name
A bit more research and I found out what mongrel_rails was. Mongrel is a fast HTTP library and server for Ruby that is intended for hosting Ruby web applications of any kind using plain HTTP rather than FastCGI or SCGI.
After poking around a bit more I notice the tie in with a postgres SQL server that I notice in a few earlier commands. Now on to the fun part!
Phase two “Modifying the system”:
Now that I have realized that the system has a database, and the user account is not location in the /etc/passwd file its time to access database identify the user account and make some modifications.
su – postgres to change to the postgres SQL user:
root@host:~# su – postgres
Launching PostgresSQL interactive terminal:
List all the roles and Superusers :
List of roles
Role name | Superuser | Create role | Create DB | Connections | Member of
postgres | yes | yes | yes | no limit |
App_User | no | no | no | no limit |
List all database on the system:
List of databases
Name | Owner | Encoding
postgres | postgres | UTF8
App_Name | postgres | UTF8
Connect to a database:
postgres=# c App_Name
List of tables:
Schema | Name | Type | Owner
public | schema_info | table | App_User
public | users | table | App_User
Query table users:
select * from users;
Fields of interest to me were (id, login, email, password, salt_val,passwd_create,passwd_updated)
Now before I went any further I ensured to dump the DB using pg_dump and pg_dumpall
postgres@host:~$ pg_dump dbname > /tmp/dbname.out
postgres@host:~$ pg_dumpall > /tmp/db.out
At this point I had a few options:
- Try to reverse the password encryption and salting mechanism
- Try to find the code that handles the authentication and bypass that
- Get access to another box, create a password and copy that hash and encrypted value over to the DB on the other system.
Luckily for me I had access to another device so I created a password there, and queried that DB and copied over the encrypted password and hash into notepad then used an insert statement to add to the values to the db along with a test user.
Connected back to the DB:
postgres=# c App_Name
Insert new records:
INSERT INTO users (id,login,email,password,salt_val,created_at) values (‘2′,’demo’,’demo@localhost’,’9abdgagf42324243240fdbd’,’8d5d6cd8fa6a0323jb3240988324′,’2006-12-05 21:15:32′);
Went back to the login portal https://ipaddress and bingo! Big shout out to byte_bucket over at irc.freenode.net #pauldotcom, he was very helpful in helping me work through this.