Miércoles 06 de Mayo | Horario de 10:00 a 17:00 hrs. | (hora del centro de México)
- Liderazgo y supervisión de personal a distancia. - Curso en Línea
¿De qué hablaremos?
Si bien la contingencia nos ha obligado a implementar un ambiente de trabajo a distancia, aprender a liderar de esta manera puede ser un gran beneficio, no sólo durante momentos de crisis sanitaria, sino que, sin duda, será un estilo de gestión que podría perdurar en el tiempo gracias a sus innumerables beneficios. Con este taller aprenderás no sólo los beneficios de un ambiente de trabajo ROWE (Results Only Work Environment), sino la forma de implementarlo en tu organización.
¿Qué aprenderás?:
- Ambiente de trabajo ROWE - Habilidades de liderazgo aplicadas a distancia. - Indicadores de desempeño para monitoreo de productividad. - Comunicación y seguimiento de avances del personal. - Motivación y compromiso a distancia.
Solicita información respondiendo a este correo con la palabra LIDERAZGO junto con los siguientes datos:
Nombre: Correo electrónico: Número telefónico: Email Alterno:
Dirigido a: Supervisores, jefes, gerentes, directores y personal en general con gente directa o indirecta a su cargo.
En caso de que haya recibido este correo sin haberlo solicitado o si desea dejar de recibir nuestra promoción favor de responder con la palabra baja o enviar un correo a bajas@ innovalearn.net
Are you tired of reading endless news stories about ethical hacking and not really knowing what that means? Let's change that!
This Post is for the people that:
Have No Experience With Cybersecurity (Ethical Hacking)
Have Limited Experience.
Those That Just Can't Get A Break
OK, let's dive into the post and suggest some ways that you can get ahead in Cybersecurity.
I receive many messages on how to become a hacker. "I'm a beginner in hacking, how should I start?" or "I want to be able to hack my friend's Facebook account" are some of the more frequent queries. Hacking is a skill. And you must remember that if you want to learn hacking solely for the fun of hacking into your friend's Facebook account or email, things will not work out for you. You should decide to learn hacking because of your fascination for technology and your desire to be an expert in computer systems. Its time to change the color of your hat 😀
I've had my good share of Hats. Black, white or sometimes a blackish shade of grey. The darker it gets, the more fun you have.
If you have no experience don't worry. We ALL had to start somewhere, and we ALL needed help to get where we are today. No one is an island and no one is born with all the necessary skills. Period.OK, so you have zero experience and limited skills…my advice in this instance is that you teach yourself some absolute fundamentals.
Let's get this party started.
What is hacking?
Hacking is identifying weakness and vulnerabilities of some system and gaining access with it.
Hacker gets unauthorized access by targeting system while ethical hacker have an official permission in a lawful and legitimate manner to assess the security posture of a target system(s)
There's some types of hackers, a bit of "terminology". White hat — ethical hacker. Black hat — classical hacker, get unauthorized access. Grey hat — person who gets unauthorized access but reveals the weaknesses to the company. Script kiddie — person with no technical skills just used pre-made tools. Hacktivist — person who hacks for some idea and leaves some messages. For example strike against copyright.
Is an open source tool to help you build a valid SSL certificate chain from the root certificate to the end-user certificate. Also can help you fix the incomplete certificate chain and download all missing CA certificates.
How To Use It's simple:
# Clone this repository git clone https://github.com/trimstray/sslmerge
# Go into the repository cd sslmerge
# Install ./setup.sh install
# Run the app sslmerge -i /data/certs -o /data/certs/chain.crt
symlink to bin/sslmerge is placed in /usr/local/bin
Options: --help show this message --debug displays information on the screen (debug mode) -i, --in add certificates to merge (certificate file, multiple files or directory with ssl certificates) -o, --out saves the result (chain) to file --with-root add root certificate to the certificate chain
How it works Let's start with ssllabs certificate chain. They are delivered together with the sslmerge and can be found in the example/ssllabs.com directory which additionally contains the all directory (containing all the certificates needed to assemble the chain) and the server_certificate directory (containing only the server certificate). The correct chain for the ssllabs.com domain (the result of the openssl command):
Certificate chain 0 s:/C=US/ST=California/L=Redwood City/O=Qualys, Inc./CN=ssllabs.com i:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K 1 s:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K i:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - G2 2 s:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - G2 i:/C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority
The above code presents a full chain consisting of:
Identity Certificate (Server Certificate) issued for ssllabs.com by Entrust Certification Authority - L1K
Intermediate Certificate issued for Entrust Certification Authority - L1K by Entrust Root Certification Authority - G2
Intermediate Certificate issued for Entrust Root Certification Authority - G2 by Entrust Root Certification Authority
Root Certificate (Self-Signed Certificate) issued for Entrust Root Certification Authority by Entrust Root Certification Authority
Scenario 1 In this scenario, we will chain all delivered certificates. Example of running the tool:
Scenario 2 In this scenario, we only use the server certificate and use it to retrieve the remaining required certificates. Then, as above, we will combine all the provided certificates. Example of running the tool:
Certificate chain In order to create a valid chain, you must provide the tool with all the necessary certificates. It will be:
Server Certificate
Intermediate CAs and Root CAs
This is very important because without it you will not be able to determine the beginning and end of the chain. However, if you look inside the generated chain after generating with sslmerge, you will not find the root certificate there. Why? Because self-signed root certificates need not/should not be included in web server configuration. They serve no purpose (clients will always ignore them) and they incur a slight performance (latency) penalty because they increase the size of the SSL handshake. If you want to add a root certificate to the certificate chain, call the utility with the --with-root parameter. Certification Paths Sslmerge allows use of two certification paths:
Output comments When generating the chain of certificates, sslmerge displays comments with information about certificates, including any errors. Here is a list of all possibilities: not found identity (end-user, server) certificate The message is displayed in the absence of a server certificate that is the beginning of the chain. This is a unique case because in this situation the sslmerge ends its operation displaying only this information. The server certificate is the only certificate required to correctly create a chain. Without this certificate, the correct chain will not be created. found correct identity (end-user, server) certificate The reverse situation here - message displayed when a valid server certificate is found. not found first intermediate certificate This message appears when the first of the two intermediate certificates is not found. This information does not explicitly specify the absence of a second intermediate certificate and on the other hand it allows to determine whether the intermediate certificate to which the server certificate was signed exists. Additionally, it can be displayed if the second intermediate certificate has been delivered. not found second intermediate certificate Similar to the above, however, it concerns the second intermediate certificate. However, it is possible to create the chain correctly using the second certification path, e.g. using the first intermediate certificate and replacing the second with the main certificate. one or more intermediate certificate not found This message means that one or all of the required intermediate certificates are missing and displayed in the absence of the root certificate. found 'n' correct intermediate certificate(s) This message indicates the number of valid intermediate certificates. not found correct root certificate The lack of the root certificate is treated as a warning. Of course, when configuring certificates on the server side, it is not recommended to attach a root certificate, but if you create it with the sslmerge, it treats the chain as incomplete displaying information about the incorrect creation of the chain. an empty CN field was found in one of the certificates This message does not inform about the error and about the lack of the CN field what can happen with some certificates (look at example/google.com). Common Name field identifies the host name associated with the certificate. There is no requirement in RFC3280 for an Issuer DN to have a CN. Most CAs do include a CN in the Issuer DN, but some don't, such as this Equifax CA. Requirements Sslmerge uses external utilities to be installed before running:
What is BurpSuite? Burp Suite is a Java based Web Penetration Testing framework. It has become an industry standard suite of tools used by information security professionals. Burp Suite helps you identify vulnerabilities and verify attack vectors that are affecting web applications. Because of its popularity and breadth as well as depth of features, we have created this useful page as a collection of Burp Suite knowledge and information.
In its simplest form, Burp Suite can be classified as an Interception Proxy. While browsing their target application, a penetration tester can configure their internet browser to route traffic through the Burp Suite proxy server. Burp Suite then acts as a (sort of) Man In The Middle by capturing and analyzing each request to and from the target web application so that they can be analyzed.
Everyone has their favorite security tools, but when it comes to mobile and web applications I've always found myself looking BurpSuite . It always seems to have everything I need and for folks just getting started with web application testing it can be a challenge putting all of the pieces together. I'm just going to go through the installation to paint a good picture of how to get it up quickly.
BurpSuite is freely available with everything you need to get started and when you're ready to cut the leash, the professional version has some handy tools that can make the whole process a little bit easier. I'll also go through how to install FoxyProxy which makes it much easier to change your proxy setup, but we'll get into that a little later.
Requirements and assumptions:
Mozilla Firefox 3.1 or Later Knowledge of Firefox Add-ons and installation The Java Runtime Environment installed
Download BurpSuite from http://portswigger.net/burp/download.htmland make a note of where you save it.
on for Firefox from https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard/
If this is your first time running the JAR file, it may take a minute or two to load, so be patient and wait.
Video for setup and installation.
You need to install compatible version of java , So that you can run BurpSuite.
Podemos impartir el curso en tu empresa en cualquier parte de la Republica
Para dudas puedo enviarte la información por whatsApp, solo responde el correo con tu número o responde el correo con el nombre de la Ciudad en la que deseas tomar el curso.
Lic. Noemi Mendoza Móvil. 044 55 64363257
Si estás viendo este correo en tu celular enviamos un WhatsApp a:
AVISO DE CONFIDENCIALIDAD Y ALCANCE LEGAL
Este correo electrónico es confidencial y para uso exclusivo de la(s) persona(s) a quien(es) se dirige. Si el lector de esta transmisión electrónica no es el destinatario, se le notifica que cualquier distribución o copia de la misma está estrictamente prohibida. Si ha recibido este correo por error le solicitamos notificar inmediatamente a la persona que lo envió y borrarlo definitivamente de su sistema.
Los correos electrónicos no son necesariamente seguros, por lo que el remitente no será responsable en ningún momento por los cambios que se sufra en su transferencia. Aún cuando se hayan revisado los archivos adjuntos existe siempre la posibilidad de que puedan contener virus o códigos maliciosos que dañen los sistemas del destinatario, por lo que tampoco se asume ninguna responsabilidad en caso de mutaciones en su transferencia y será siempre necesario revisarlos antes de abrirlos.
Las opiniones expresadas en este correo electrónico deberán ser confirmadas por escrito y firmadas por el remitente para tener validez legal, por lo que el correo electrónico no es el medio apropiado para emitir opiniones o recomendaciones formales. Covola nueva PNo imprima este mensaje si no es realmente necesario.
This post is about PKCE [RFC7636], a protection mechanism for OAuth and OpenIDConnect designed for public clients to detect the authorization code interception attack.
At the beginning of our research, we wrongly believed that PKCE protects mobile and native apps from the so called „App Impersonation" attacks. Considering our ideas and after a short discussion with the authors of the PKCE specification, we found out that PKCE does not address this issue.
In other words, the protection of PKCE can be bypassed on public clients (mobile and native apps) by using a maliciously acting app.
OAuth Code Flow
In Figure 1, we briefly introduce how the OAuth flow works on mobile apps and show show the reason why we do need PKCE. In our example the user has two apps installed on the mobile phone: an Honest App and an Evil App. We assume that the Evil App is able to register the same handler as the Honest App and thus intercept messages sent to the Honest App. If you are more interested in this issue, you can find more information here [1].
Figure 1: An example of the "authorization code interception" attack on mobile devices.
Step 1: A user starts the Honest App and initiates the authentication via OpenID Connect or the authorization via OAuth. Consequentially, the Honest App generates an Auth Request containing the OpenID Connect/OAuth parameters: client_id, state, redirect_uri, scope, authorization_grant, nonce, ….
Step 2: The Browser is called and the Auth Request is sent to the Authorization Server (usually Facebook, Google, …).
The Honest App could use a Web View browser. However, the current specification clearly advice to use the operating system's default browser and avoid the usage of Web Views [2]. In addition, Google does not allow the usage of Web View browser since August 2016 [3].
Step 3: We asume that the user is authenticated and he authorizes the access to the requested resources. As a result, the Auth Response containing the code is sent back to the browser.
Step 4: Now, the browser calls the Honest App registered handler. However, the Evil App is registered on this handler too and receives the code.
Step 5: The Evil App sends the stolen code to the Authorization Server and receives the corresponding access_token in step 6. Now, the Evil App can access the authorized ressources.
Optionally, in step 5 the App can authenticate on the Authorization Server via client_id, client_secret. Since, Apps are public clients they do not have any protection mechanisms regarding the storage of this information. Thus, an attacker can easy get this information and add it to the Evil App.
Proof Key for Code Exchange - PKCE (RFC 7636)
Now, let's see how PKCE does prevent the attack. The basic idea of PKCE is to bind the Auth Request in Step 1 to the code redemption in Step 5. In other words, only the app generated the Auth Request is able to redeem the generated code.
Figure 2: PKCE - RFC 7636
Step 1: The Auth Request is generated as previosly described. Additionally, two parameters are added:
The Honest App generates a random string called code_verifier
The Honest App computes the code_challenge=SHA-256(code_verifier)
The Honest App specifies the challenge_method=SHA256
Step 2: The Authorization Server receives the Auth Request and binds the code to the received code_challenge and challenge_method.
Later in Step 5, the Authorzation Server expects to receive the code_verifier. By comparing the SHA-256(code_verifier) value with the recieved code_challenge, the Authorization Server verifies that the sender of the Auth Request ist the same as the sender of the code.
Step 3-4: The code leaks again to the Evil App.
Step 5: Now, Evil App must send the code_verifier together with the code. Unfortunatelly, the App does not have it and is not able to compute it. Thus, it cannot redeem the code.
PKCE Bypass via App Impersonation
Again, PKCE binds the Auth Request to the coderedemption.
The question rises, if an Evil App can build its own Auth Request with its own code_verifier, code_challenge and challenge_method.The short answer is – yes, it can.
Figure 3: Bypassing PKCE via the App Impersonation attack
Step 1: The Evil App generates an Auth Request. The Auth Request contains the client_id and redirect_uri of the Honest App. Thus, the User and the Authorization Server cannot recognize that the Evil App initiates this request.
Step 2-4: These steps do not deviate from the previous description in Figure 2.
Step 5: In Step 5 the Evil App sends the code_verifier used for the computation of the code_challenge. Thus, the stolen code can be successfully redeemed and the Evil App receives the access_token and id_token.
OAuth 2.0 for Native Apps
The attack cannot be prevented by PKCE. However, the IETF working group is currently working on a Draft describing recommendations for using OAuth 2.0 for native apps.
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.
Welcome to my 3rd new tutorial of networking (Routing and Switching). In this blog you will able to watch an interesting video about basic device navigation such as changing device (router or switch) name, configuration of login password, configuring a device information, router IP addresses and many more.
What is router?
Router is a network layer device which is the 3rd layer in the OSI model which is used to communicate different networks. It is an intelligent device fixed at the boundary of network that connects to other networks and responsible for end to end delivery of the packet that requires an IP address which is known as the logical address which is the basic identity of the device just like our identity card number or roll number and so on, for the identification of source and destination devices. Router is the gateway of the network having two interfaces such as inbound and the outbound interface through which the traffic comes in from different networks and comes out traffic to the different networks.
What is an IP address?
Internet protocol (IP) address is a numeric label given to each and every device in the network for the identification of the device just like our roll numbers in collages, universities which identity each and every student uniquely everywhere. So same concept here, it is a logical address which is used whenever the device want to communicate outside the network that means to another network.
What is Switch?
Switch is basically layer 2 device, which is used to connect two or more than two devices with each other in the same network. It is an intelligent device which doesn't allow the broadcast. It requires Media access control (MAC) address to communicate within the network. Now let's move to the video for further.
