Exploiting SSH key based authentication

This is rather be a quick post and intended to be a reference note for me (and you all). 

Recently, I exploited a vulnerability to gain shell of the remote system. Yeah, this is remotely over SSH connection..:) The pre-requisites are:

1. Remote server must have SSH service running.

2. Remote server must have vagrant module installed.

3. Support key based authentication.

To detect server has vagrant module installed, browse http://example.com/vagrantfile. This should give you a pop-up to download a file. Refer here for vagrantfile info.

When vagrant is installed on the box, it creates a default user called vagrant with www rights and accepts incoming connections for the user vagrant having valid keys. The keys are known and can be downloaded from here. To exploit, replace these keys with your public and private keys or use below command:

ssh -i <key_files> vagrant@<remote_server_ip>

And here you go, you gain access to shell instantly and own the box...:)

Happy testing and hacking!!!

تابع القراءة ←

Ncat - Swiss Army Knife

Netcat as simple chat server.

Open a port to listen. Allow firewall access.

Connect from another machine on that port. Once connected type any message and press enter.

From kali, sent text appeared here. Now type something and send to kali.

 Binding Linux shell to windows

Open port and bind Linux shell on it.

Windows can access Linux shell on that open port since shell is bind on that port via Linux machine itself.

 Binding Windows shell to Linux

Open port and bind windows command shell to it.

Access Windows Shell via Linux machine on that particular port.

Reverse Shell Scenario and Need
Consider Person A using Linux
             Person B using Windows

Person A has no control over router. Hence he can not forward traffic from it to his local machine. Thus how person A can not bind a port to local machine and he needs help.

Any way to connect? Yes
Instead binding port with shell locally, he will send his shell control to person B directly. Then person B will able to access person A's shell. This scenario is called reverse shell.
 

Reverse Shell Scenario

Windows needs help from Linux. Windows can not bind port on its local machine then follow below steps for reverse shell scenario.
 
1. Find which port is open on Linux machine. Port 1337 is opened for this activity.

2. IP address of linux is 192.168.1.107. Windows will send its shell control directly to Linux with the help of Linux's IP address as shown below.

3. Getting upon connected, you can see that Linux can use windows's shell and provide help to windows. This is reverse shell scenario in which you do not bind shell on port and let others connect to you. You simply give control of your shell to another person and thus how reverse shell gets executed.

File transfer using NC

Windows expects to welcome chintan.txt file

Linux sends chintan.txt to windows on that open port.

Windows successfully receives chintan.txt file.

# Resource : http://resources.infosecinstitute.com/netcat-tcpip-swiss-army-knife/

تابع القراءة ←

Facebook’s Oculus – Cross-Site Content Hijacking (XSCH) to Bypass SOP

First off, before going in-depth about this I would like to paste you what a crossdomain.xml file is,here is something that are taken from Ookla, you can read more here.

What is the crossdomain.xml file?

The crossdomain.xml file is a cross-domain policy file. It grants the Flash Player permission to talk to servers other than the one it's hosted on. 

In what circumstances do I need to use one?

You need a crossdomain.xml file when your Speedtest uses external hosts as testing servers. 

Crossdomain.xml files

Flash Player’s default security model enforces the same origin policy similar to contemporary browsers and does not allow cross domain data read operations. However, it can make exception to this rule and disregard its default security model if a website in question hosts a cross-domain policy file (named crossdomain.xml) to allow data access from other domains. Insecurely written cross-domain policy files can expose critical application data over the internet. The example policy file below shows once such example where the website opens itself to read access from every running instance of Flash Player.

“

This forexample is how a (super) vulnerable crossdomain file looks like,

<cross-domain-policy>  

      <allow-access-from domain="*" />

</cross-domain-policy>

When flash requests to access that domain, it first asks the domain if it’s okay to snoop its contents. It does that by requesting domain.com/crossdomain.xml file and reading it, that crossdomain file says "Allow-access-from *(all) domains". This means, where ever our flash file is hosted (attacker.com/hack.swf), it will be able to read the contents of domain.com. This is much like a Cross Site scripting, but less in some case. We can only request and read, we cannot write. So it less.

Using this we can steal AntiCSRF tokens, craft CSRF exploits. Read html files using victim sessions (Messages, account balance…)

Here is a great example,”
A user logs on to the banking website.

The user then visits another website in different browser tab and that website hosts a malicious Flash file to retrieve user information from the bank website.

When the Flash Player notices an attempt to perform cross-domain read operation, it retrieves crossdomain.xml file from the bank website to discover the permitted operations.

It then sends out a read request to a known bank URL that returns sensitive information like user bank account numbers, account balance etc…

The browser adds user’s session cookies to the outgoing requests and since the user is logged in, the malicious Flash file is served with critical user information.

Th Flash file then passes it on to the malicious server.

“

You see? This is serious s***!

There is a particular flash exploit for this attack by Gursev Singh Kalra here.http://pastebin.com/EwqkGkxp

I was bored so I gave a shot of each oculus domain. All turned out to be safe, excpet one. It says

<allow-access-from domain="*.oculus.com" secure=”true”/>

It means everything that is hosted at *.oculus.com have read access at developer.oculus.com domain.  

Luckily, I know support.oculus.com have an upload box. While submitting a ticket, you can also upload image files. You see what I am going with this? I made my malicious flash.swf file, change the extension to flash.jpg, upload it at support.oculus.com and that file now have access to developer.oculus.com because the crossdomain allowed it.

The great about flash is, despite the file Mime, or format say flash.jpg, when we embed it as flash, it will act like flash despire its content/mime type.  

The exploit Scenario follows as:

1.       1. Create a malicious flash.swf that does malicious action, like read antiCSRF tokens or   messages.

2.       2. Change the extension of flash.swf to flash.jpg

3.       3. Navigate to support.oculus.com, create a ticket and upload our malicious flash.jpg file as a supporting image to the support team

4.       4. In our malicious domain (say attacker.com) host,  

<object type="application/x-shockwave-flash" data="https://support.oculus.com/attachments/token/APToMFwKw6O45WRIS5lf1HTP7/flash.jpg" width="1" height="1">

<param name="movie" value="https://support.oculus.com/attachments/token/APToMFwKw6O45WRIS5lf1HTP7/flash.jpg" />

</object>

5.       6. Now we navigate our victim to attacker.com and as soon as the flash files runs, Boom! We get everything we need. 

   Facebook had an amazing (better?) support about this. I got the fix (less than 9hrs)
   Hope you enjoyed the post! Comments would be nice! :)

     

   Report Timeline:

      Jan 21, 2015 6:59am - Initial Report

      Jan 27, 2015 9:09am  - Facebook Initial Confirmation

      Jan 27, 2015 6:55pm  - Fix!

      
Great cooperation guys! and I would like to thank the Facebook Security team and the program it self.

Conclusion:

-          Permit access from your crossdomain.xml because a simple mistake or “*” can cause a disaster.

-          In another option, make your uploaded files have a content-disposition header with appropriate values. 

تابع القراءة ←

Deep Inside Malicious PDF

When we start to check the PDF files that exist in our Pc or Laptop we may use antivirus scanner but in this days it seems not good enough to detect malicious PDF that counties a shell code because, as attacker mostly encrypt it’s count -ant to bypass the antivirus scanner and in many times target a zero day vulnerability that exit in Adobe Acrobat reader or in updated version. Before we start analyze malicious PDF we going to have a simple look at PDF structures as to understand how the shell code work and where it locate. PDF components PDF Header The first line of pdf show the pdf format version the most important line that give to you the basic information of the pdf file for example “%PDF-1.4 means that file fourth version. PDF Body The body pdf file consist of objects that compose contents of the document, these objects include fonts, images, annotations, text streams and user can put invisible objects or elements, this objects can interactive with pdf features like animation, security features. The body of the pdf supports two types of numbers (integers, real numbers). The Cross-Reference Table (xref table) The cross- reference counties links of all objects and elements that exist on file format, you can use this feature to see other pages contents (when the users update the PDF the cross-reference table gets updated automatically). The Trailer The trailer contains links to cross-reference table and always ends up with %%EOF to identify the end of a PDF file the trailer enables a user to navigate to the next page by clicking on the link provided. Malicious PDF through Metasploit Now after we have talking a tour inside PDF file format and what it contains we will start to install old version of Adobe Acrobat reader 9.4.6 and 10 through to 10.1.1 that will be vulnerable to Adobe U3D Memory Corruption Vulnerability. This exploit are exist in Metasploit framework so we going to create the malicious PDF and analysis it in KALI Linux distribution. Start opens the terminal and type msfconsole. We going to setting some Metasploit variables to be sure that everything is working fine. *After choosing the exploit type we going to choose the payload that will execute during exploitation in the remote target and open Meterpreter session. The file has been saved on /root/.msf4/local. So we going to move the file to Desktop for easier located by typing in the terminal root@kali :~# cd /root/.msf4/local root@kali :~# mv msf.pdf /root/Desktop PDFid Now we going to use pdfid to see what the pdf continue of elements and objects and JavaScript and see if something interesting to analyze. The PDF has only one page maybe its normal. There are several JavaScript objects inside… this is very strange. There is also an OpenAction object which will execute this malicious JavaScript So we going to use peepdf. Peepdf Peepdf its python tool very powerful for PDF analysis, the tool provide all necessary components that security researcher need in PDF analysis without using many tools to do that, it support encryption, Object Streams, Shellcode emulation, Javascript Analysis, and for Malicious PDF it Shows potential Vulnerabilities, Shows Suspicious Elements, Powerful Interactive Console, PDF Obfuscation (bypassing AVs), Decoding: hexadecimal – ASCII and HEX search. Analysis If we going to start analysis go to the directory of the PDF file then start with syntax /usr/bin/peepdf–f msf.pdf. *choose the LHOST which is our IP address and we can view through typing ifconfig in new terminal *finally we type exploit to create the PDF file with configuration we created before We use –f option to avoid errors and force the tool to ignore them. This the default output but we see some interesting things first one we see is the highlighted one object 15 continue JavaScript code and we have also one object 4 continue two executing elements (/AcroForm & /OpenAction) and the last one is /U3D showing to us Known Vulnerability for now we will start to explore this objects by getting an interactive console by typing syntax /usr/bin/peepdf –i msf.pdf The tree commands shows the logical structure of the file, and starting explore object 4 (/Acro-Form). When we type object 4 it gave you another objects to explore for now we didn’t see any impotent information or seems suspicious except object 2 (XFA array) that gave us the element <fjdklsaj fodpsaj fopjdsio> and seems to us not continue something special. Let’s move to the another object (Open Action). Now we can see JavaScript code, that will be executed when the pdf file will be opened. The other part of the JavaScript code is barely obfuscated like writing some variables in hex and in this code we can see a heap spraying with shell code plus some padding bytes. The attackers typically use unicode to encode their shell code and then use the unescape function to translate the unicode representation to binary content (now we are sure that defiantly a malicious pdf) Defend We defend our network from that type of malicious files by providing strong e-mail and web filter, IPS and by application control: disable JavaScript and Disable PDF rendering in browsers, Block PDF readers from accessing file system and Network resources. Security awareness.

تابع القراءة ←