Sería muy util poder administrar todos nuestros servidores desde la palma de la mano.
Sin embargo una shell linux, no es viable en el teclado de un teléfono incluso de un tablet, sobretodo porque hay que escribir muchos símbolos, por ejemplo el guión, y estos teclados están pensados más bien para texto.
Pues bien, de esta necesidad surgió la aplicación SSHControl:
Esta problematica la he solucionado a base de utilizar nevegadores y estructurar los outputs para no acumular excesiva información en la pantalla.
- Navegador de ficheros - Navegador de procesos - Navegador de conexiones - Navegador de logs - Navegador de drivers de kernel
Esto permite administrar múltiples servidores con un solo dedo :)
Controlar la seguridad de sus servidores ahora es bastante sencillo y ágil, por ejemplo con solo hacer un "tap" encima de un usuario, podemos ver sos procesos asociados, con hacer otro tap en un proceso podemos kilearlo, ver mas info etc .. Con hacer un tap encima de una apliacción, vemos sus conexiónes, con un tap en una conexión podemos agregar una regla de filtrado en el firewall, etc ..
En la siguiente versión habilitaré la opción de "Custom Commnands", la cual es muy util, cada administrador o usuario linux, tiene una serie de comandos que repite con mucha frecuencia, bien pues esta opción permite pre-programar estos comandos habituales, de manera que puedes lanzarlos con un simple tap.
En el roadmap tengo pensadas nuevas funcionalidades muy útiles :)
Everything over the internet is secured by the passwords. You need a login to do any stuff on any social or banking website. Passwords are the first security measure for these type of websites. So, I brought a tutorial on how to hack such sort of login passwords. This tutorial is based on credential harvester attack method. In which you will know about hacking passwords using credential harvester attack method.
HACKING PASSWORDS USING CREDENTIAL HARVESTER ATTACK
REQUIREMENTS
It's very simple and easy to follow. Before you start, you need the following things to work with.
Kali Linux OS
Target Website
STEPS TO FOLLOW
Run the Kali Linux machine. If you have not Kali Linux installed, you can grab a free copy and install it as a virtual machine. You can learn more about Kali Linux VirtualBox installation.
Sign in to Kali Linux by entering username root and password toor.
As you'll sign in, navigate to the Applications > Social Engineering Tools> Social Engineering as shown in the following screenshot.
Now you will see the different options. You have to choose Social Engineering Attacks by simply entering its number in the terminal. Once you do it, it will show a few options further. Simply choose Website Vector Attack by putting its number.
Website vector attack will show up it's a different type of attacks. We are going to use Credential Harvester Attack.
Choose the Site Clone option. As you do it, it will ask for your public IP address. Just open up a new terminal and type ifconfig. It'll show the public IP. Just copy it and paste in the previous terminal as shown in the following screenshots.
After we do it. Enter the target website of which passwords you want to hack. Make sure to use a website that has username and password on the same page.
All done now. As someone opens up the browser on the public IP we specified, it'll show up the website that we entered in the previous step. Now as someone enters their username or password, it will be captured in the terminal.
That's all. If you're not clear yet. You can watch the following complete video tutorial on how to do it.
Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers.
The issue: CORS misconfiguration
Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misconfigurations which can potentially be exploited. For more technical details on the issues read the this fine blogpost.
Misconfiguation
Description
Developer backdoor
Insecure developer/debug origins like JSFiddler CodePen are allowed to access the resource
Origin reflection
The origin is simply echoed in ACAO header, any site is allowed to access the resource
Null misconfiguration
Any site is allowed access by forcing the null origin via a sandboxed iframe
Pre-domain wildcard
notdomain.com is allowed access, which can simply be registered by the attacker
Post-domain wildcard
domain.com.evil.com is allowed access, can be simply be set up by the attacker
Subdomains allowed
sub.domain.com allowed access, exploitable if the attacker finds XSS in any subdomain
Non-SSL sites allowed
An HTTP origin is allowed access to a HTTPS resource, allows MitM to break encryption
Invalid CORS header
Wrong use of wildcard or multiple origins,not a security problem but should be fixed
The tool: CORStest
Testing for such vulnerabilities can easily be done with curl(1). To support some more options like, for example, parallelization we wrote CORStest, a simple Python based CORS misconfiguration checker. It takes a text file containing a list of domain names or URLs to check for misconfigurations as input and supports some further options: CORStest can detect potential vulnerabilities by sending various Origin request headers and checking for the Access-Control-Allow-Origin response. An example for those of the Alexa top 750 websites which allow credentials for CORS requests is given below.
Evaluation with Alexa top 1 Million websites
To evaluate – on a larger scale – how many sites actually have wide-open CORS configurations we did run CORStest on the Alexa top 1 million sites: This test took about 14 hours on a decent connection and revealed the following results: Only 29,514 websites (about 3%) actually supported CORS on their main page (aka. responded with Access-Control-Allow-Origin). Of course, many sites such as Google do only enable CORS headers for certain resources, not directly on their landing page. We could have crawled all websites (including subdomains) and fed the input to CORStest. However, this would have taken a long time and for statistics, our quick & dirty approach should still be fine. Furthermore it must be noted that the test was only performed with GET requests (without any CORS preflight) to the http:// version of websites (with redirects followed). Note that just because a website, for example, reflects the origin header it is not necessarily vulnerable. The context matters; such a configuration can be totally fine for a public sites or API endpoints intended to be accessible by everyone. It can be disastrous for payment sites or social media platforms. Furthermore, to be actually exploitable the Access-Control-Allow-Credentials: true (ACAC) header must be set. Therefore we repeated the test, this time limited to sites that return this header (see CORStest -q flag): This revealed even worse results - almost half of the websites supporting ACAO and ACAC headers contained a CORS misconfigurations that could be exploited directly by a web attacker (developer backdoor, origin reflection, null misconfig, pre-/post-domain wildcard):
The Impact: SOP/SSL bypass on payment and taxpayer sites
Note that not all tested websites actually were exploitable. Some contained only public data and some others - such as Bitbucket - had CORS enabled for their main page but not for subpages containing user data. Manually testing the sites, we found to be vulnerable:
A dozen of online banking, bitcoin and other payment sites; one of them allowed us to create a test account so we were able to write proof-of-concept code which could actually have been used to steal money
Hundred of online shops/e-commerce sites and a bunch of hotel/flight booking sites
Various social networks and misc sites which allow users to log in and communicate
One US state's tax filing website (however, this one was exploitable by a MitM only)
We informed all sites we manually tested and found to be vulnerable. A simple exploit code example when logged into a website with CORS origin reflection is given below.
The Reason: Copy & Paste and broken frameworks
We were further interested in reasons for CORS misconfigurations. Particularly we wanted to learn if there is a correlation between applied technology and misconfiguration. Therefore we used WhatWeb to fingerprint the web technologies for all vulnerable sites. CORS is usually enabled either directly in the HTTP server configuration or by the web application/framework. While we could not identify a single major cause for CORS misconfigurations, we found various potential reasons. A majority of dangerous Access-Control-* headers had probably been introduced by developers, others however are based on bugs and bad practices in some products. Insights follow:
Various websites return invalid CORS headers; besides wrong use of wildcards such as *.domain.com, ACAO headers which contain multiple origins can often be found; Other examples of invalid - but quite creative - ACAO values we observed are: self, true, false, undefined, None, 0, (null), domain, origin, SAMEORIGIN
Rack::Cors, the de facto standard library to enable CORS for Ruby on Rails maps origins '' or origins '*' into reflecting arbitrary origins; this is dangerous, because developers would think that '' allows nothing and '*' behaves according to the spec: mostly harmless because it cannot be used to make to make 'credentialed' requests; this config error leads to origin reflection with ACAC headers on about a hundred of the tested and vulnerable websites
A majority of websites which allow a http origin to CORS access a https resource are run on IIS; this seems to be no bug in IIS itself but rather caused by bad advises found on the Internet
nginx is the winner when it comes serving websites with origin reflections; again, this is not an issue of nginx but of dangerous configs copied from "Stackoverflow; same problem for Phusion Passenger
The null ACAO value may be based on programming languages that simply return null if no value is given (we haven't found any specific framework though); another explanation is that 'CORS in Action', a popular book on CORS, contains various examples with code such as var originWhitelist = ['null', ...], which could be misinterpreted by developers as safe
If CORS is enabled in the crVCL PHP Framework, it adds ACAC and ACAO headers for a configured domain. Unfortunatelly, it also introduces a post-domain and pre-subdomain wildcard vulnerability: sub.domain.com.evil.com
All sites that are based on "Solo Build It!" (scam?) respond with: Access-Control-Allow-Origin: http://sbiapps.sitesell.com
Some sites have :// or // as fixed ACAO values. How should browsers deal with this? Inconsistent at least! Firefox, Chrome, Safari and Opera allow arbitrary origins while IE and Edge deny all origins.
Preparation for next year's conferences is underway. I had the pleasure of meeting people from our community at a recent ISACA Ireland event where I had an OWASP stand. I also had lots of swag to give away, loads left which I plan to share out amongst the community.
I was on a call recently with both WIA leadership and a number of individuals looking to broaden our diversity reach, forming DIA (diversity in AppSec). This was a positive call and I look forward to reviewing their proposal under the committee 2.0 operating model.
I'd like to thank our volunteers, chapter and project leaders for making OWASP what it is today. We wouldn't have a foundation without you. We always want to make things better, to this end, it would be great if you could fill out the following feedback form.
Thank you,
Owen Pendlebury, Vice-Chairman
FROM THE EXECUTIVE DIRECTOR
As we wind down 2019, we are planning lots of new opportunities to get involved with OWASP next year. The current working draft of the 2020 Operating Plan can be found on our staging site for our new website which is planned to launch next month.
Some of the highlights for 2020:
Quarterly Town Hall meetings.
Two Project Summits - the first in February 2020
Pilot single-day AppSec Days worldwide to offer local training and community.
We are also set to further increase the transparency of the daily workings of OWASP through our Staff Projects page. The pages linked there will always be a work in progress; some of which today are still only templates but still a great resource to know what's going on at OWASP.
All of this which adds to our Global and Regional Events, ongoing local chapter support, and other member activities. Our plans are ambitious and we look forward to your continued support this and every month as we look to better secure the web.
OWASP Foundation Global AppSec Event Dates for 2020
NEW OWASP Project Summit - Winter 2020 February 2020 in Cancun, Mexico
The OWASP Foundation will host a three-day working session for FIVE selected projects in Cancun, Mexico, February 2020. Arrival day will be Wednesday the 19th and departures will be the 23rd. Projects must apply and then get selected to participate. The application process will require project meeting goals, work plans, key contributors, and expected attendance. The OWASP Foundation Officers Group will make the final selection. For more information click here.
Announcing a New Opportunity to become part of a Global AppSec Program Team
Conference Program Teams are constituted for each Global AppSec event and consists of members of OWASP members and staff. The selection of team members is based on subject-matter expertise and a balanced representation of the OWASP community. For planning purposes, team members shall reside on the continent of the Global AppSec for which they serve. Teams are constituted no later than six months prior to the Global AppSec event.
To apply to become a member of the Conference Program Team click here.
We are so excited to announce that both the London OWASP and WIA community have been asked to speak at BlackHat Europe 2019 on Wednesday 4 December at the EXCEL London. Andra Lezza is leading the panel of women to "Share insights gained at different stages of their careers to help other women in the field." Thank you, Andra, for leading the initiative and also to Sonya Moisset, Bibi Sanjarani, Katy Anton and Lauren Chiesa for volunteering to be part of the panel. Also from the OWASP Community and a London Chapter Leader Sam Stepanyan and Paul Harragan. Sam and Pau will be presenting a more in-depth demo on the OWASP Nettacker. Good luck to all the speakers have a great conference.
I would like to encourage all of the OWASP community that will be attending BlackHat Europe to please make every effort to attend and support our fellow OWASP members Wednesday, 4 December 2019. (Click to view the schedule details.)
OWASP Members don't forget you are eligible for € 200.00 discount, email marketing@owasp.org for code to use when registering.
BlackHat Europe has extended an invitation to our London WIA community to lead a panel to "Share insights gained at different stages of their careers that could help other women in the field." Thank you to Andra Lezza for leading this initiative and Sonya Moisset, Bibi Sanjarani, Katy Anton and Lauren Chiesa for volunteering to be part of the panel and to contribute. Good luck I am sure your session will be a huge success.
BlackHat Europe 2019 London at EXCEL London 2019 December 2-5 The OWASP Booth 1015 Business Hall December 4 & 5 December 4, 10:30 AM - 7:00 PM December 5: 10:00 AM - 4:00 PM
EVENTS
You may also be interested in one of our other affiliated events:
As the foundation moves toward the migration of the OWASP web presence from the old wiki site to our new Github-hosted home, some of you may still have questions regarding what to move and how to move it. Essentially, if you have a chapter page or project page and you have not migrated it to the new website, that would be first. Steps on what to do and what is needed can be found at https://www2.owasp.org/migration There are also some minor instructions on the default project or chapter page itself. And if you are wondering where that page is located, you can go to https://github.com/OWASP and type your chapter name in the repository search bar. If your project or chapter is not there, contact me. Lastly, there are a number of excellent examples already done by other leaders (also linked on the migration page).
And, as a precaution, you should click over into the 'Settings' of your repository and then click the 'Collaborators & teams' link on the left menu and check to make sure that the usernames added to Collaborators match what you expect. Having someone you do not know edit your web page without your knowledge is no longer the expected behavior.
Some resources, mostly for projects, have been uploaded to the OWASP Site Theme Repository and can be linked to via the /assets/image/common/<file> URL.
After your chapter or project page is done, there is a www-community repository which would include any files from the wiki that are not currently in a project or chapter or board/staff policy area. For instance, there are pages there for GSoC and XSS and CSRF. A list of the top pages that need to be migrated can be found attached to one of the TODO cards on our website migration Trello board which you are invited to join if you want to help migrate loose pages and/or perform some automation work.
Our current plan can be found on the Website Relaunch project page.
PROJECT ANNOUNCEMENT
As part of OWASP's participation in Google's Season of Docs, the ZAP project has had Nirojan Selvanathan (@sshniro) working on API documentation. The first iteration of the documentation is now live. It includes Java, Python, and shell example snippets all presented in a responsive and accessible design which we will continue to build on in the future.
Big thanks to Nirojan for his efforts on this wonderful initiative! Congratulations and thanks to Google Open Source for helping to bring the open-source and technical writer communities together!
COMMUNITY
Welcome to our New OWASP Chapters
Colombo, Sri Lanka Des Moines, IA Harrisburg, PA Louisville, KY Monterrey, Brazil Moscow, Russia
Contributor Corporate Members
*Ads and logos are not endorsements and reflect the messages of the advertiser only. *
