Expressions: June 2020

Tuesday, June 30, 2020

¿Habrá Una Segunda Ola Del Nuevo Coronavirus?

Si queremos ser breves, la respuesta es "no lo sabemos"

Pero podemos hacer algunos comentarios. Nos podemos fijar, por ejemplo, en qué ha ocurrido en otras situaciones similares. En el siglo pasado hubo tres pandemias de gripe. La de 1918 fue la más mortífera. Se desarrolló en tres oleadas: en primavera de 1918, en otoño de ese mismo año y en invierno de 1919. La realmente virulenta y mortal fue la segunda en la que ocurrieron el 64% de los fallecimientos. En realidad, la primera oleada fue la menos fuerte, solo fue responsable del 10% de los muertes de aquella pandemia. En la segunda oleada, se han podido documentar cambios en el genoma del virus que podrían explicar que fuera más virulento. En 1957 apareció un nuevo virus gripal que originó la "gripe asiática", que cursó también en tres olas epidémicas: la primera en primavera-verano de 1957 y con una incidencia relativamente baja, la segunda a principios de 1958 y la tercera en invierno entre 1958 y 1959. La mortalidad fue más alta en las dos segundas olas. Diez años después, en 1968 un nuevo virus de la gripe causó la denominada "gripe de Hong Kong" cuya difusión fue más lenta e irregular, comenzó en otoño-invierno en el hemisferio norte y le siguió una segunda ola el invierno siguiente con una mayor incidencia. La última pandemia de gripe, la denominada "gripe A" de 2009-2010, finalmente no tuvo tanta incidencia y acabó teniendo el efecto de una gripe estacional. De hecho este virus acabó adaptándose al ser humano y siendo una de las cepas que circulan y predominan desde entonces cada año. Como vemos, lo de las segundas y terceras olas más letales ha ocurrido con el virus de la gripe con anterioridad.

En el caso del SARS-CoV2, la aparición de nuevas olas epidémicas dependerá del propio virus, de su capacidad de variación y adaptación al nuevo hospedador, al ser humano; de nuestra inmunidad, de si realmente estamos inmunizados y protegidos contra él; y de nuestra capacidad de trasmitirlo y controlarlo.

El virus

¿Puede el virus mutar y hacerse más virulento como ocurrió con el de la gripe de 1918?

No lo sabemos. Pero a diferencia de la gripe, SARS-CoV2 no es el campeón de la variabilidad. El virus de la gripe también tiene un genoma de ARN, pero son ocho pequeños fragmentos que se pueden mezclar con otros tipos de virus de gripe aviar o porcina, dando lugar a nuevos reagrupamientos. Su capacidad de mutación y de recombinación es mucho mayor, por eso las vacunas de la gripe hay que cambiarlas cada año y se originan virus pandémicos con más frecuencia. Desde que comenzó el SARS-CoV2, se han secuenciado y comparado los genomas de varios miles de aislamientos y, … ¡Claro que el virus muta! Todos los virus mutan, pero de momento, como esperábamos, éste parece un virus mucho más estable que el de la gripe. Quizá sea porque este coronavirus tiene una proteína (nsp14-ExoN) que actúa como una enzima capaz de reparar los errores que pueden ocurrir durante la replicación del genoma. Por lo tanto, aunque en este caso sigue siendo válida esa definición de virus como una "nube de mutantes", el SARS-CoV2 parece que de momento no acumula mutaciones que afecten a su virulencia.

Pero además, en otras ocasiones se ha comprobado que los virus al "saltar" de una especia animal a otra, como en este caso, con el tiempo se van adaptando al nuevo hospedador y van disminuyendo su virulencia. O sea, que no siempre que un virus muta es para hacerse más virulento, sino generalmente lo contrario. De todas formas, habrá que seguir vigilándolo de cerca.

La inmunidad de grupo

¿Estamos ya inmunizados contra este virus?

Para evitar la extensión de una epidemia hay que cortar la cadena de transmisión del virus. Esto se consigue cuando hay un número suficiente de individuos (por lo menos más del 60%) que están protegidos contra la infección, actúan como una barrera e impiden que el virus alcance a aquellos que todavía podrían contagiarse. Esto es lo que se denomina inmunidad de rebaño, de grupo o colectiva, se consigue cuando la gente ha pasado la enfermedad o cuando se vacuna. Pero contra este virus todavía no tenemos una vacuna. ¿Hay inmunidad de grupo contra este virus? Pues parece que no. En el estudio preliminar sobre seroprevalencia de la infección por el coronavirus SARS-CoV2 en España, una de las conclusiones más importantes es que la prevalencia nacional se sitúa en el 5%: algunas comunidades presentaban prevalencias inferiores al 2%, mientras que otras superan el 10%. Estos datos se obtuvieron mediante la detección de los anticuerpos IgG anti SARS-CoV2 mediante la técnica de inmunocromatografía, los test rápidos. En definitiva lo que indican es que como mucho, en algunas zonas, no más del 10% de la población ha tenido contacto con el virus. Estamos muy lejos de ese 60% o más, necesario para conseguir la inmunidad de grupo.

Pero todo esto es mucho más complejo de lo que parece. Todavía no sabemos si el tener anticuerpos contra el SARS-CoV2, o sea, el haber dado positivo en los test serológicos, realmente te asegura que estés inmunizado frente al virus. No sabemos, a ciencia cierta, cuánto tiempo duran esos anticuerpos ni si son neutralizantes, si bloquean al virus y te protegen de una segunda infección. Tampoco tenemos datos de la inmunidad celular, esa otra parte de nuestro sistema de defensa que no depende de los anticuerpos sino de las células y que es muy importante para vencer las infecciones virales.

Es cierto, que en el caso de otros coronavirus, el haber pasado la infección y haber generado anticuerpos, estos duran unos meses o años y parece que tienen cierto efector protector, pero esto también puede depender de la persona (no en todas las personas ocurre lo mismo). También es cierto que hay algunos ensayos con plasma de pacientes curados del coronavirus que está bloqueando al virus y tienen un efecto beneficioso en personas infectadas, lo que demostraría que esos anticuerpos son protectores. En ensayos con macacos infectados con el virus se ha comprobado que sus anticuerpos sí les protegen frente a una segunda infección. Pero esto se ha hecho en macacos. También se ha sugerido que el haber tenido contacto previo con otros coronavirus, los que producen los catarros y resfriados comunes, podría tener cierto efecto protector contra el SARS-CoV2. Esto de momento solo se ha demostrado en ensayos in vitro, pero podría explicar la gran cantidad de personas asintomáticas. En definitiva, la inmunidad de grupo… ¡Sigue siendo un misterio!

Tres posibles escenarios

Teniendo todo esto en cuenta, algunos (1) han propuesto tres posibles modelos.

1) Una segunda ola mucho más intensa en invierno de 2020 seguida de olas más pequeñas a lo largo de 2021. Este escenario sería similar a las pandemias de gripe, pero ya sabemos que este coronavirus no es una gripe, no tiene porque comportarse igual. Este escenario, podría requerir volver a algún tipo de medidas de confinamiento más o menos intensas durante el otoño-invierno para evitar de nuevo el colapso del sistema sanitario.

2) Varias olas epidémicas durante un periodo de uno o dos años. Este primer pico epidémico que acabamos de sufrir estaría seguido de olas repetitivas que ocurrirían de forma consistente durante un par de años hasta desaparecer en algún momento en 2021-22. La frecuencia e intensidad de estos rebrotes dependería de las medidas de control de cada país.

3) Pequeños brotes sin un patrón claro de nuevas olas epidémicas. Esta primera ola estaría seguida de pequeños rebrotes que se irían apagando poco a poco, dependiendo también de las medidas de control y contención de cada país. Este escenario no requeriría volver a medidas tan drásticas de confinamiento, aunque el número de casos y de muertes podría continuar durante un tiempo.

En cualquier caso parece que no podemos descartar que el virus SARS-CoV2 continúe circulando entre nosotros durante un tiempo, quizá se acabe sincronizando con la época invernal, y vaya disminuyendo su severidad. Aunque no haya nuevas olas epidémicas, incluir un nuevo virus respiratorio que puede tener consecuencias muy graves para un grupo importante de la población, en la lista de decenas de virus respiratorios que nos visitan cada año, no es una buena noticia. Cada temporada de gripe se saturan las urgencias de muchos hospitales, añadir un nuevo virus ya es un problema.

Controlar y evitar rebrotes: adelantarse al virus

El virus no ha desaparecido. Yo me inclino, es más una esperanza que una certeza, por el tercer escenario: pequeños brotes sin un patrón claro de nuevas olas epidémicas que se irán apagando poco a poco. Pero no olvidemos que eso puede seguir dejando muertos por el camino. Esto es lo que está ocurriendo en otros países, que ya habían terminado su primera ola antes que nosotros, como Corea del Sur. En España, también se han producido rebrotes en algunas ciudades durante el inicio de la desescalada. En la mayoría de los casos, has estado relacionados con aglomeraciones de población (fiestas o comidas familiares). Pero no podemos estar confinados eternamente ni podemos esterilizar todos los ambientes: "es imposible … y además no se puede hacer". Para disminuir la frecuencia e intensidad de estos rebrotes son fundamentales dos acciones.

Por parte de los ciudadanos: evitar el contagio. Ya sabemos cómo se transmite el virus y que, afortunadamente, es fácil de inactivarlo. Los contagios son más frecuentes en ambientes cerrados o con mucha gente. No lo olvidemos: mucha gente, muy junta y moviéndose es lo mejor para el virus. Evitar aglomeraciones, distanciamiento entre personas, uso de mascarillas, higiene frecuente de manos, limpieza y desinfección (en ese orden), seguir las recomendaciones de Sanidad. Esto es lo que hay que exigir al ciudadano, no nos podemos relajar.

Por parte de las autoridades sanitarias: rastrear al virus. No podemos seguir como hasta ahora detrás del virus, hay que tomarle la delantera. Hay que instaurar un sistema capaz de detectar a una persona infectada al menor síntoma, poder rastrear y obtener información de sus contactos, hacerles un seguimiento clínico y test de PCR y serológicos, y si es necesario aislarlos. Detectar un brote y aislarlo. Esto requiere personal, equipamiento y sistemas de diagnóstico. Y hay que estar preparados para que el sistema sanitario no vuelva a colapsarse. Esto es en lo que hay que ocuparse ahora mismo, a lo que hay que dedicar todos los recursos, no en hacer test masivos a toda la población, para sacar "una foto fija" de la situación. Las decisiones tienen que ser por razones sanitarias, no políticas. Esto es lo que hay que exigir a nuestros gobiernos, tampoco pueden relajarse.

Si has estado en contacto estrecho sin las medidas de precaución con alguien que haya tenido síntomas de COVID-19, a menos de 2 metros durante más de 15 min, tú deberías aislarte durante 14 días, y deberías exigir a las autoridades sanitarias que te hicieran los test a la persona con síntomas y a ti.

Puede haber una segunda o más olas, … o puede que no. Ahora hemos apagado el incendio, pero no lo hemos extinguido, quedan rescoldos que pueden avivar el fuego. El relajamiento de las medidas de confinamiento no es porque hayamos vencido al virus, es porque también hay que salvar el medio de vida. Un confinamiento muy largo también puede causar muertes. No vamos a acabar con el virus, lo podemos esquivar. Podemos mitigar sus efectos. No puede volver a ocurrir lo que ha pasado, esta vez sí que tenemos que proteger a los más débiles. Y eso depende de los ciudadanos y de los gobiernos.

(1) COVID-19: The CIDRAP Viewpoint. Part 1: "The future of the COVID-19 pandemic: lessons learned from pandemic influenza" (Abril 30, 2020). (Fuente de las imágenes).

More information

13 Hacking Websites & forums - Underground hacker sites

Exploit DB: An archive of exploits and vulnerable software by Offensive Security. The site collects exploits from submissions and mailing lists and concentrates them in a single database.
Packet Storm: Information Security Services, News, Files, Tools, Exploits, Advisories and Whitepapers.
NFOHump: Offers up-to-date .NFO files and reviews on the latest pirate software releases.
HackRead: HackRead is a News Platform that centers on InfoSec, Cyber Crime, Privacy, Surveillance, and Hacking News with full-scale reviews on Social Media Platforms.
The Hacker News: The Hacker News — most trusted and widely-acknowledged online cyber security news magazine with in-depth technical coverage for cybersecurity.
Hacked Gadgets: A resource for DIY project documentation as well as general gadget and technology news.
Phrack Magazine: Digital hacking magazine.
DEFCON: Information about the largest annual hacker convention in the US, including past speeches, video, archives, and updates on the next upcoming show as well as links and other details.
Hakin9: E-magazine offering in-depth looks at both attack and defense techniques and concentrates on difficult technical issues.
SecTools.Org: List of 75 security tools based on a 2003 vote by hackers.
SecurityFocus: Provides security information to all members of the security community, from end users, security hobbyists and network administrators to security consultants, IT Managers, CIOs and CSOs.
Metasploit: Find security issues, verify vulnerability mitigations & manage security assessments with Metasploit. Get the worlds best penetration testing software now.
KitPloit: Leading source of Security Tools, Hacking Tools, CyberSecurity and Network Security.

Thursday, June 11, 2020

PKCE: What Can(Not) Be Protected

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.

References

[1] http://mews.sv.cmu.edu/papers/ccs-14.pdf

[2] https://tools.ietf.org/html/draft-ietf-oauth-native-apps-06#section-8.1

[3] https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

Authors

Vladislav Mladenov
Christian Mainka (@CheariX)

How To Protect Your Private Data From Android Apps

The method is quite simple and just need a rooted android device that will allow the Xposed installer to run on the device. And after having the Xposed installer you will be using an Xposed module to disallow the apps to have access to your personal or say private data. For this follow the guide below.

Steps To Protect Your Private Data From Android Apps:

Step 1. First of all, you need a rooted android as Xposed installer can only be installed on a rooted android, so Root your android to proceed for having superuser access on your android.

Step 2. After rooting your Android device you have to install the Xposed installer on your android and thats quite lengthy process and for that, you can proceed with our Guide to Install Xposed Installer On Android.

Step 3. Now after having an Xposed framework on your Android the only thing you need is the Xposed module that is DonkeyGuard – Security Management the app that will allow you to manage the media access for apps installed on your device.

Step 4. Now install the app on your device and after that, you need to activate the module in the Xposed installer. Now you need to reboot your device to make the module work perfectly on your device.

Step 5. Now launch the app and you will see all the apps that are currently installed on your device.

Step 6. Now edit the media permission for the apps that you don't want to have access to your media with private data.

That's it, you are done! now the app will disallow the media access to that apps.

Manually Checking App Permission

Well, our Android operating system offers a nice feature in which we can manage a single app's permission. However, you need to have Android 6.0 Marshmallow or a newer version to get the option.

Step 1. First of all, open Settings and then tap on 'Apps'.

Manually Checking App Permission

Step 2. Now you will see the list of apps that are currently installed on your Android smartphone. Now you need to select the app, and then you will see 'Permissions.'

Manually Checking App Permission

Step 3. Now it will open a new window, which will show you all permissions that you have granted to the app like Camera access, contacts, Location, microphone, etc. You can revoke any permissions as per your wish.

Manually Checking App Permission

Well, the same thing you need to perform if you feel that you have installed some suspicious app on your Android. By this way, you can protect your private data from Android apps.

Read more

TLS-Attacker V2.2 And The ROBOT Attack

We found out that many TLS implementations are still vulnerable to different variations of a 19-year old Bleichenbacher's attack. Since Hanno argued to have an attack name, we called it ROBOT: https://robotattack.org

Given the new attack variants, we released a new version of TLS-Attacker 2.2, which covers our vulnerabilities.

Bleichenbacher's attack from 1998

In 1998, Daniel Bleichenbacher discovered that the error messages given by SSL servers for errors in the PKCS #1 1.5 padding allow an adversary to execute an adaptive-chosen ciphertext attack. This attack also belongs to the category of padding oracle attacks. By performing the attack, the adversary exploits different responses returned by the server that decrypts the requests and validates the PKCS#1 1.5 padding. Given such a server, the attacker can use it as an oracle and decrypt ciphertexts.

We refer to one of our previous blog posts for more details.

OK, so what is new in our research?

In our research we performed scans of several well-known hosts and found out many of them are vulnerable to different forms of the attack. In the original paper, an oracle was constructed from a server that responded with different TLS alert messages. In 2014, further side-channels like timings were exploited. However, all the previous studies have considered mostly open source implementations. Only a few vulnerabilities have been found.

In our scans we could identify more than seven vulnerable products and open source software implementations, including F5, Radware, Cisco, Erlang, Bouncy Castle, or WolfSSL. We identified new side-channels triggered by incomplete protocol flows or TCP socket states.

For example, some F5 products would respond to a malformed ciphertext located in the ClientKeyExchange message with a TLS alert 40 (handshake failure) but allow connections to timeout if the decryption was successful. We could observe this behaviour only when sending incomplete TLS handshakes missing ChangeCipherSpec and Finished messages.

See our paper for more interesting results.

Release of TLS-Attacker 2.2

These new findings motivated us to implement the complete detection of Bleichenbacher attacks in our TLS-Attacker. Before our research, TLS-Attacker had implemented a basic Bleichenbacher attack evaluation with full TLS protocol flows. We extended this evaluation with shortened protocol flows with missing ChangeCipherSpec and Finished messages, and implemented an oracle detection based on TCP timeouts and duplicated TLS alerts. In addition, Robert (@ic0ns) added many fixes and merged features like replay attacks on 0-RTT in TLS 1.3.

You can find the newest version release here: https://github.com/RUB-NDS/TLS-Attacker/releases/tag/v2.2

TLS-Attacker allows you to automatically send differently formatted PKCS#1 encrypted messages and observe the server behavior:

$ java -jar Attacks.jar bleichenbacher -connect [host]:[port]

In case the server responds with different error messages, it is most likely vulnerable. The following example provides an example of a vulnerable server detection output:

14:12:42 [main] CONSOLE attacks.impl.Attacker - A server is considered vulnerable to this attack if it responds differently to the test vectors.
14:12:42 [main] CONSOLE attacks.impl.Attacker - A server is considered secure if it always responds the same way.
14:12:49 [main] CONSOLE attacks.impl.Attacker - Found a difference in responses in the Complete TLS protocol flow with CCS and Finished messages.
14:12:49 [main] CONSOLE attacks.impl.Attacker - The server seems to respond with different record contents.
14:12:49 [main] INFO  attacks.Main - Vulnerable:true

In this case TLS-Attacker identified that sending different PKCS#1 messages results in different server responses (the record contents are different).

$$$ Bug Bounty $$$

What is Bug Bounty ?

A bug bounty program, also called a vulnerability rewards program (VRP), is a crowdsourcing initiative that rewards individuals for discovering and reporting software bugs. Bug bounty programs are often initiated to supplement internal code audits and penetration tests as part of an organization's vulnerability management strategy.

Many software vendors and websites run bug bounty programs, paying out cash rewards to software security researchers and white hat hackers who report software vulnerabilities that have the potential to be exploited. Bug reports must document enough information for for the organization offering the bounty to be able to reproduce the vulnerability. Typically, payment amounts are commensurate with the size of the organization, the difficulty in hacking the system and how much impact on users a bug might have.

Mozilla paid out a $3,000 flat rate bounty for bugs that fit its criteria, while Facebook has given out as much as $20,000 for a single bug report. Google paid Chrome operating system bug reporters a combined $700,000 in 2012 and Microsoft paid UK researcher James Forshaw $100,000 for an attack vulnerability in Windows 8.1. In 2016, Apple announced rewards that max out at $200,000 for a flaw in the iOS secure boot firmware components and up to $50,000 for execution of arbitrary code with kernel privileges or unauthorized iCloud access.

While the use of ethical hackers to find bugs can be very effective, such programs can also be controversial. To limit potential risk, some organizations are offering closed bug bounty programs that require an invitation. Apple, for example, has limited bug bounty participation to few dozen researchers.

More articles

What Is Cybercrime? What Are The Types Of Cybercrime? What Is Cyberlaw In India?

What is cyber crime?

Cybercrime is the use of computers & networks to perform illegal activities such as spreading viruses,online bullying,performing unauthorized electronic fund transfers etc. Most cyber crimes are committed through the internet.
Some cyber crime also be carried out using mobile phones via Sms and online chatting applications.

TYPES OF CYBERCRIME

The following list presents the common types of cybercrimes-

1-Computer Fraud-Intential deception for personal gain via the use of computer system.

2-Privacy Violations-Exposing personal information such as email addresses,phone numbers,account details etc, on social media,websites,etc.

3-Identity theft-Stealing personal information from somebody and impersonating that person.

4-Sharing copyright files/information-This involves distributing copyright protected files such as eBooks and computer program etc.

5-Electronic funds transfer-This involves gaining an unauthorized access to bank computer networks and making illegal funds transferring.

6-Electronic money laundering-This involves the use of the computer to launder money.

7-Atm fraud-This involves intercepting ATM card details such as account numbers and PIN numbers.These details are then used to withdraw funds from the intercepted accounts.

8-Denial of service attack-This involves the use of computers in multiple locations to attack servers with a view of shutting them down.

9-Spam:sending unauthorized emails.

These emails usually contain advertisements.

CYBER LAW

Under The Information Technology Act,2000

CHAPTER XI-OFFENCES-66. Hacking with computer system.

1-whoever with the Intent to cause or knowing that he is likely to cause Wrongfull Loss or Damage to the public or any person Destroys or Deletes or Alter any Information Residing in computer Resource or diminishes its value or utility or affects it injuriously by any means, commits hack.

2-whoever commits hacking shell be punished with imprisonment up to three years, or with fine which may extend up to two lakh rupees,or with both.

Expressions

Tuesday, June 30, 2020

¿Habrá Una Segunda Ola Del Nuevo Coronavirus?

More information

13 Hacking Websites & forums - Underground hacker sites

Thursday, June 11, 2020

PKCE: What Can(Not) Be Protected

OAuth Code Flow

Proof Key for Code Exchange - PKCE (RFC 7636)

PKCE Bypass via App Impersonation

OAuth 2.0 for Native Apps

References

Authors

Related links

How To Protect Your Private Data From Android Apps

How To Protect Your Private Data From Android Apps

Steps To Protect Your Private Data From Android Apps:

Manually Checking App Permission

TLS-Attacker V2.2 And The ROBOT Attack

Bleichenbacher's attack from 1998

OK, so what is new in our research?

Release of TLS-Attacker 2.2

Related posts

$$$ Bug Bounty $$$

What Is Cybercrime? What Are The Types Of Cybercrime? What Is Cyberlaw In India?

Related articles

Followers

Blog Archive

About Me