Known password length, brute force character in place? We all know that brute forcing is a very slow process and trying all unnecessary possibilities is dumb. By knowing the password length, we can skip trying possibilities of other password lengths and saves us huge amounts of time. Still this change is insignificant for very long passwords. So I was wondering if we can brute force every character in place. It would be like cracking a combination for a mechanical lock. We try every character in place until it "clicks" into place, then we move on to the next character, and so on.

If you have a password verification mechanism which lets you know, in any way, whether a given letter is correct or not, independently of the others, then you have an awfully weak, stupidly designed password verification mechanism. That's what happens when you let Hollywood scenarists deal with reality.

This board game is an illustration of how bad it is: if a letter "clicks into place", as you put it, then your password can be beaten by an 8 years old kid from the early 70s (and without any computer at all). I strongly hope that login screen security has increased a bit beyond the Disco kid security level.


CGI-BIN - suspicious activity (unknown IP made request) I have a python-script being run regularly on my Linux system by means of a cron daemon process - every weekday 18:00 scraping stockmarket data.
This scraping script is placed in cgi-bin folder so that it can be run on a remote client.
Port 80 is open on the default gateway
Webbserver: Apache2
No domainname is bound to my public IP so the IP is used
So the script is run on a remote client by the following url
xxx.xxx.xxx.xxx/cgi-bin/pytest.py
So - luckily a confirmation mail is sent to my email when the pythonscript is run. Since cron launches this script at 18:00 monday - friday I get this mail.
Today something happended - the script was run 2 times:

17:56
18:00

second time is when cron executes the script. But why was it executed 17:56?
I checked the apache access-log and got the following
 37.123.187.232 - - [16/Feb/2021:17:56:27 +0100] "GET /cgi-bin/pytest.py HTTP/1.1" 200 2090 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36"

So someone could execute the script and my question is -
How could someone know about my IP (yes you can portscan IF you know the IP) and even more strange - know the name of the pythonscript?
I can only think of 2 possibilities:

theres a method to systematically scan IP-adresses on internet and check which ports are opened. But how know whats inside cgi-bin?

I sent this url to a friend of mine some weeks ago since he helps me scrape now and then. Could the mailbox be hacked? (I will emphasize that he DID NOT scrape at that point of time)

IP / port scanning is something that is happening on a daily basis. The cgi-bin directory is a standard directory and included in almost if not all wordlists used by directory brute forcing tools such as dirb, dirsearch etc. The cgi-bin directory is also of interest in relation to a know vulnerability ShellShock (read further to see whether your system is vulnerable or not). In regards to the script name, I believe it can be enumerated easily with already mentioned tools. If you care, you could employ firewall rules to restrict who, from where can access it (think of IP based restrictions, or perhaps use a custom User Agent and reject other connections). None of this are bulletproof but can help.


Can more than one app claim a URL in Universal Links / App Links? What happens? Can I have more than one application claim the same URL for Universal Links or App Links?

What occurs on the end user device when such a (developer permitted) collision occurs?

Is the experience the same on Android and iOS?
Will there be a prompt, allowing the user to pick which app to open the deep link URL in?

No, a collision is not possible.

The way that app links and universal links work is

Your web page contains a URL to a file on your web server
The file contains the information that tells the device what app to open.

The link might look like this:
https://<domain>/apple-app-site-association

The file might look like this:

"applinks": {
    "apps": [],
    "details": [
        {
            "appID": "9JA89QQLNQ.com.apple.wwdc",
            "paths": [ "/wwdc/news/", "/videos/wwdc/2015/*"]
        },
        {
            "appID": "ABCD1234.com.apple.wwdc",
            "paths": [ "*" ]
        }
    ]
}

So in order to create an app association using of of these links, you have to own a server that matches the domain in the URL.

You can only put files on web servers that you own, of course; nobody else can (unless you have given them permission or they have hacked you).  So whoever owns the web server also owns the app association.  No collisions.


Is Google cookie a first-party cookie? Recently, after blocking third-party cookies, I thought that all non-domain cookies will be blocked.
But as a surprise Google (google.com) cookies are not removed even if there is no link between the visited domain and google.com, and still, that cookie is present.
Does anyone have an idea why Google cookies are treated differently?
Browser: Microsoft Edge (Chromium)

No, it's not (assuming you aren't on google.com, as indeed you aren't in that screenshot). However, depending on the way the browser works, there are a few things that could be going on here:

The browser might not actually block all third-party cookies, just ones you haven't visited. This is the default behavior in some browsers, like Safari. Since you've presumably visited google.com, it would be trusted.
The browser might only be blocking new/updated third-party cookies, and not prevented from sending existing ones (that haven't expired) from before that setting was applied.
The browser might be reporting all the cookies it has for all pages with content on the page, but not actually sending the third-party cookies. That's weird, but hardly the weirdest thing I've seen browsers do.
The browser might automatically trust certain domains. Chromium is made by Google, after all, even if Microsoft then wraps it up in their own little-c chrome.
The browser might have been explicitly configured to trust google. It's widely used and trusted, including for single sign-on, and potentially you or somebody else acknowledged the value to allow it on third-party sites.

There are probably more options; those are just the ones that seem most likely to me.


Is using password_verify($password, "") to block access to an account secure? We are migrating an old website, which used pretty old password hashing to the new php password verify function. The old method used an old hash, and we would like to use password_verify instead of the old method were just a hash and a salt was stored. The old hash algorithm was outdated, so we don't want to convert the old hash to the password_verify structure (which might be possible).

Instead, we will block access and require an user to reset its password before continuing.

Question

Can we set the hash used in password_verify to "" (empty string) to block access to the account?

From the pure hashing view, yes, it is secure. The new password verify uses bcrypt or blowfish to encrypt the password, in none of the cases could it be made to an empty string by a tricky password.

However, there are other views which you could consider.

First, security is not only about closing the known attack possibilities, it is also about closing out any currently unknown. This is really hard. Defense is easy against anything what you know.

Second, a secure code should be also easy to understand, to avoid the appearance of secholes by multiple programmers not knowing eachothers work enough well. I would like to mention the remote root ssh sechole from some years ago (although in this case there is a possibility that it was an intended attack).

In my opinion, you would do your task better if you would somehow clearly sign in your database that an account is closed because of the algorithm upgrade, and not on some other reason, and your login / auth code should specifically handle this case. This is what you should do even in the case if it leads to seemingly redundant code.


Organisation's use of SSL inspection and duplication of root CA certs An organisation (a school in this example) requires connecting personal devices to install root CA certs to allow SSL inspection to occur. Whether is this ethical or unethical is another issue - in the context of verifying that the content accessed is appropriate for a school, SSL inspection is probably overkill and begs a question as to why SSL inspection is actually implemented on the network.

The organisation's administration staff do not properly understand the security issues present with this setup and thus the issues cannot be communicated back to the network administration staff.

Guests are encouraged to have their device join the network, which then the root CA certificates are required to be installed and accepted.

The root CA certificates were issued for 10 years from 2016 - a recent upgrade to the network required them to be re-issued and re-installed, meaning old root CA certificates are still installed on hundreds, if not thousands of machines.

Clients (students) - hundreds - leave every year and their personal devices will still have the root CA certificates installed, with no instruction provided by the school to remove them

Is this quite significant? or should it all be ignored - how can you express the issues associated to computer illiterate administration staff

Let's unpack your questions:

  Is this quite significant? or should it all be ignored

and

  how can you express the issues associated to computer illiterate administration staff

tl;dr: "It depends".

You've already discussed the privacy / ethics concern with the school fully monitoring all traffic of all devices in their building, so let's assume for now that we're ok with this and talk about the technical concerns:

The CA was rolled over and the old one left of devices.
Graduating students (or guests leaving the building) do not remove the root certs from their trust stores.

Before we can go any further, we need to define our threat model. I assume you're worried about random cyber-criminal-hacker-trenchcoat people compromising these devices because of the presence of these trusted roots?

I think there's only two ways this can happen:

The CA cert uses weak crypto and can be brute-forced before it expires.

Certainly a 10 year cert on RSA-1024 would be in this category. You'll need to look at the root cert itself to see what crypto they're using.

The admins were sloppy about storing the private keys, and hackers were able to hack into the school and steal the private key file.

Yup, now any website visited by a device with the school's root cert could potentially be a phishing site and the device / user won't know the difference.

So, the question is: how hardened are the school's networks against the CA cert private key being stolen. For example, has the school hired external penetration testers to help them harden? The way to pitch this to administration is the cost of hardening the network vs the risk of making every student / staff / guest's device vulnerable to attackers both on and off the school's network.


Applicability of CVE-2018-14721 My project uses different versions of jackson library at a number of places, and a security scanner flagged that the binary is vulnerable to CVE-2018-14721. My reading of https://nvd.nist.gov/vuln/detail/CVE-2018-14721 is that the vulnerability is about deserialization of axis2-jaxws classes resulting in SSRF.
Is this CVE applicable if axis2 is not used in the project?
Is this CVE applicable to jackson-mapper-lgpl:1.9.3?

I have the same reading as you about the fact that only the axis2-jaxws is concerned.
However, not using this module in your project could not be sufficient if you are using other parts of jackson whose make call to this vulnerable axis2-jaxws.
In order to be sure, you should inspect every part of jackson you are using, check their dependencies (if axis2-jaxws is in the list it's not good), check the dependencies of their dependencies (if axis2-jaxws is in the list it's not good), and so one.
At least, in your specific case, we could say that, as it is discouraged to use multiple version of the same software in a project, it is strongly recommended that you simply use the most recent one.


Does Tor browser work with college network? I'm in a system where my modem connects to a college network (KotNet) that monitors its internet traffic.  Since I'd like some privacy I was wondering if a Tor browser would hide my identity or if it would not work since I first have to log in to the college net (with username and password) before I can have access to internet.

The short answer is that any internet connection you access that is also tied to you personally (e.g. the login credentials on a college network) can be traced back to you. Therefore it is not suitable for full anonymity online. You enter your login credentials to access the network, the network admins can trace your connections through their network to a Tor node. Theoretically that should be all they can see because your traffic should be encrypted. But if your adversary is some No Sugar Added ice cream it might also be monitoring exit traffic of their hosted Tor nodes. This would make you risk a pairing up of your traffic with exit traffic.

If Tor will connect is a different question. This would depend on if your ISP (sometimes the college for many universities and colleges) has blacklisted any IPs.

So, it really depends what you need the anonymity for. Investigative journalism critical of your host country? I'd say probably not a good idea. Avoiding the eyes of malicious non-state actors - You're probably okay to use it.

One other thing to consider is if your college bans Tor traffic and what policies regarding this are on your campus.


Learning ethical SQL injection with php login form I'm learning ethical hacking and now I'm on sql injection topic. I'm also new to SQL and php. Ok, so I have local damn vulnerable website with back-end Linux, MySQL and Apache and now trying to use sql injection to login. The login form is php script, the login page consists of 2 boxes: username and password. I tried adding the "'" sign at the end of password and i do get sql error, so it is probably injectable. Then I tried adding the "' OR 1=1" and "' OR 'a'=a'" at the end of the password, but with not much success.
So now I need some help! Any ideas or suggestions will be helpful.
The partial php login code is below:

// Sanitization is present

if (isset($_POST['user']))
{
$user = sanitizeString($_POST['user']);
$pass = sanitizeStringSQL1($_POST['pass']);

if ($user == "" || $pass == "")
$error = "Not all fields were entered<br>";

else
{
$result = queryMySQL("SELECT user,pass FROM members WHERE user='$user' AND pass='$pass'");
if ($result->num_rows == 0)

You're syntax is a little off in both of your attempts at this. Since you mention you're using DVWA I'll provide the source here (so that we can rule out PHP/DB errors on your side)

<?php

if(isset($_GET['Submit'])){

// Retrieve data

$id = $_GET['id'];

$getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";
$result = mysql_query($getid) or die('
' . mysql_error() . '
' );

$num = mysql_numrows($result);

$i = 0;

while ($i < $num) {

    $first = mysql_result($result,$i,"first_name");
    $last = mysql_result($result,$i,"last_name");

    echo '
';
    echo 'ID: ' . $id . '
First name: ' . $first . '
Surname: ' . $last;
    echo '
';

    $i++;
}
}
?>

The following line will trigger a successful injection:

foo' or '1' = '1

Notice that there is no tick at the beginning nor at the end of the payload. This is because (as you can see in the source) that the query itself is providing it (on both ends of $id).

In your examples of

' OR 1=1 and ' OR 'a'=a'

The first case is missing ticks all together, and the second case has an ending tick. Both will likely produce SQL syntax errors.

If you want to check your SQL syntax use an online resource such as this.


Data Transport Encryption - Small Scale Solution I have a web based application for a network that needs to be able to run without internet access. I have wanted to add TLS to protect certain data in transport. I have explored options like Lets Encrypt and OpenSSL but neither seem truly viable for my situation. Lets Encrypt requires internet access and OpenSSL requires you to add an additional trusted CA to client machines. For many of the environments this app could run, robust TLS may be overkill but I would still like to protect some information in transport. I had an idea to accomplish this. I am hoping those here can explain why this solution may not be recommended and if an existing solution may be more desirable.

So lets say I have a login form where TLS is not available. To prevent a valid user's credentials from being observable when sent to the server I would do the following:

When serving the page first generate a high entropy random token and relate this token to the un-validated session ID.
When the user submits their credentials, first encrypt the values on the client using the token as a key.
When the credentials arrive at the server the server will find the associated key for this session ID.
Once we have a possible key we will then decrypt the login credential and test against those that are valid.
Whether this login is successful or not, if this key is valid it will be destroyed.
A successful login will destroy the key and generate a new session ID while invalidating the previous ID.

Please explain to me why this solution may not be recommended and some possible weak points. DOS attacks are not of large concern.

It looks for me that you try to invent your own security solution not because the existing solutions don't work but only because you don't understand how the existing solutions work. In other words: don't roll your own crypto.

In detail:

  Lets Encrypt requires internet access and OpenSSL requires you to add an additional trusted CA to client machines.

You are comparing apples and apple trees. Let's Encrypt is a CA which can be used to issue certificates. OpenSSL is a library which implements TLS and also can be used to create your own certificates.

  ... robust TLS may be overkill but I would still like to protect some information in transport.

You feel that TLS may be overkill but don't explain why. If it is about certificates - TLS can be used without these, i.e. it can work with a pre shared key too.

  ... When serving the page first generate a high entropy random token and relate this token to the un-validated session ID. ...

Basically the server creates a secret which is later used by the client - i.e. a shared secret. Only the client cannot even be sure that the secret is created by the server since it can be created by a man in the middle. Without proper authentication of the server the client does not know who it is communicating with, it might be the server but it might also be an attacker. In TLS certificates or pre shared keys provide this authentication you are missing.

Thus basically you just assume that the first connection will be to the real server. This is called TOFU - Trust On First Use. It can be achieved with TLS too: the server might have some certificate the client has never seen before but the client will trust it once and later check that the same certificate is used for all following connections.

  A successful login will destroy the key and generate a new session ID while invalidating the previous ID.

Only it is not really TOFU since the clients seems to forget the server as soon as it logged in and will hopefully connect to the proper server and not some attacker for the next login too - but that's just hoping since the client will not actually check.

  Please explain to me why this solution may not be recommended ...

The main problem with this is that you don't have enough understanding of established methods so that you think that established methods don't work in your case. Again, don't roll your own crypto but instead use established ones were lots of experts worked on it.


Is there a security benefit to requiring a login before and after a captcha test? On Stack Exchange, if you login with your email address and password and then get captcha tested, you have to provide your credentials a second time after passing the captcha.

I've been trying to figure out what the possible security advantage is to this. It seems to me that by authenticating in the first instance, I've proven that I have possession of the credentials, and that by passing the captcha I've proven that I'm a human. These seem like independent tests to me.

Is there a security advantage and if so what is it?

This could potentially be an additional protection measure against password-guessing botnets. As far as I can see, it is meant to confuse automated attackers even when they have a CAPTCHA farm, perhaps fooling them into detecting a rejected password attempt, although a correct password was given.

Due to this, it is likely designed to foil everyone except for a human who is highly confident that they have a correct password, which is to say, the authentic user.


How is OTR messaging with Socialist Millionaire Protocol (SMP) protected from Man In The Middle? So imagine the next situation:

Alice wants to initiate OTR instant messaging session with Bob but Joe is Man In The Middle.

Alice negotiates a shared secret 'X' with Joe (thinking he is Bob) using Diffie-Hellman.

Joe negotiates another shared secret 'Y' with Bob (who thinks Joe is Alice) using Diffie-Hellman.

Now Alice and Bob both know that they have established the so called "unverified OTR session", meaning that they are encrypted but none of them have verified their identities (none of them know about the existence of Joe).

So from what I understand, the Socialist Millionaire Protocol is supposed to be the solution of this problem. Alice has to match her shared secret 'X' with Bob's 'Y' and if they don't match - they will know that they have someone (Joe) in the middle, haven't they?

Anyway… Obviously X != Y because Joe is in the middle.

Now, I think I understand the steps in the Socialist Millionaire Protocol but still… I can't see what is stopping Joe from pretending in front of Alice that he is indeed Bob and use SMP to match with her their shared secret 'X' (which they both know)?

Am I missing something? What is the thing that makes OTR with SMP protected from MitM?

As far as I understand, SMP does not protect against MitM per se. The paper's authors clearly state,

  Suppose that Alice and Bob are chatting online using OTR and decide to
  run the SMP, but have not previously selected a secret and possess no
  channel more secure than their current conversation. They can still
  select an appropriate secret in this case, but they will be more
  vulnerable to attack.

The SMP protocol is used to compare that shared secret without needing to send it in the clear, but the shared secret must already exist.

Otherwise, to Alice's eyes, there would be no difference between Bob and Joe. For the same reason, Alice and Joe would be identical to Bob's eyes. Which would lead to a perfect man-in-the-middle scenario.


How to log into sites that you have set up Google 2 Step Authenticator if you lose your phone? If you use Google Authenticator to log into sites using 2 Factor Authentication, how do you log in after you lose your phone?

Can you install Google Authenticator on another device?

You can install Google Authenticator on another device. However, that new application will not have access to the prior secret shared between the server and your phone.

In Google's case, they recommend printing out backup passwords and keeping them somewhere safe in the event anything happens. It is up to other sites using Google Authenticator as a means of 2FA authentication to provide similar ways of recovering from such a loss. The HOTP and TOTP algorithms themselves do not allow for any recovery.


Dynamic analysis tools in windows I'm sorry, i'm newbie in security, i'm looking for a software that detect changes in the whole operating system during its execution, that's helps analysing the behaviour of malicious software to know its impact in OS ?

I've already seen this kind of software but i have forgot his name.

I tend to use SysInternals in general and ProcMon (procmon.exe) specifically to monitor what an application does in the system. It will give you all registry operations, DLL operations, etc.


Could a phishing page generate a genuine session with the targeted service? At the end of this tutorial the author gives a few ideas for improving a basic phishing attack.

One of them intrigued me, in particular: Is it possible to use the credentials that a victim enters in your phishing page and use, say Facebook's or Twitter's (or whichever) API and send those credentials to the actual service, hence creating a genuine session so that the victim never realized that they've been phished?

Yes it is possible for a phishing site to act as a proxy between the user and the expected website and thereby record/inject data. It would require something more sophisticated than just SSLstrip sitting on the phishing site though.

The URL in the browser would reference the phishing site throughout the session.


How do I add application level encryption to an Android BLE connection? The Android Bluetooth Low Energy documentation  recommends adding application layer encryption on-top of the BLE connection if the exchanged data is sensitive:

Caution: When a user pairs their device with another device using BLE, the data that's communicated between the two devices is accessible to all apps on the user's device.
For this reason, if your app captures sensitive data, you should implement app-layer security to protect the privacy of that data.

As I would like to avoid "rolling my own encryption", I am looking for a production-ready way to encrypt packets.
I have an out-of-band channel to exchange one message (e.g key) from one participant to the other (QR code). Both participants are Android devices, one operating in server mode (peripheral), and one as a client (central).
I looked at the Noise Protocol Framework as a more lightweight alternative to TLS, but that feels like it is still to much manual work(?).
Is there an easy solution? It seems like this has to be a solved problem.

First, a word of advice: StackExchange is not for recommending specific products, so I'm going to be relatively general here. Whoever reads this in the future may be in a world where there are new and much better alternatives, or even where the old guard has been found to be broken.
There are several high-level crypto libraries that - given a pre-shared key - will handle message or possibly stream encryption (and related security requirements such as data integrity) with a minimum of effort. Simply searching for "easy crypto library" will find you some candidates. Note that lots of people ignore the advice against rolling your own crypto, and some of them publish it, so you do want to make sure the library you pick is well-reviewed by experts, ideally unrelated to its development.
You'll also want to consider what exactly you want (and need) from your library. Does it need to support arbitrary-length encrypted streams (or very large messages that don't easily fit in memory), or will a simple message-based protocol work? Must the library be very small, in install footprint or RAM usage? Very fast, on a particular CPU? Compatible with any particular other library? Use specific ciphers or other primitives for compliance reasons (I hope not)? Available in a particular language?

For a few well-regarded examples as of mid-2020, consider LibSodium or Monocypher. Both are well-regarded, reviewed, and focused on ease of use. Other alternatives are NaCl, LibHydrogen, and so on. Note that not all of these focus equally on security, speed, or convenience; for example, TweetNaCl emphasizes minimal code size, sacrificing a lot of speed and potentially some security in the process, compared to the original NaCl.


Registration Password Is it best to create an application that allows a user to sign up with username and email at the beginning and password once you click the generated email sent to you or should the password entering be in place before you get an email to continue sign up process?

Of the two, the prior method is more secure and should be used. As imjoevasquez said, its used to curtail signups and make sure email address is legitimate.
The other thing you could do is send a randomly generated code to the email, and ask to enter that to let the user create the account.


How effective is a basic password modification algorithm compared to password reuse Password reuse is bad for many many reasons.  More secure systems require changing a password regularly preventing reuse.

One potential solution to this is a password generation scheme.  Imagine a base password and a simple algorithm for modifying it based off of a very simple or short password that is made up each time.  The simplest version being appending the short password to the base password.

Looking at the simplest version, I have some base password foo and for each website I come up with some easily remembered, not overly secure, word to modify it.  So my password for gitlab becomes fooGit and my password for facebook is fooFace etc.  For places that require changing passwords every month, it could be as simple as fooOne, fooTwo, fooThree etc, some easy to remember modification each month.

Assuming that foo is actually a relatively strong password, how secure would such an approach like this be?

If the algorithm I mentioned was as trivial as what I mentioned it would be easy for someone who gets your old password to guess at a new password.  However, someone would have to have access to at least two alternative passwords to figure out your using an algorithm like this, and even then they would need to guess the value appended to it.  They would lack rainbow tables for your password algorithm, so unless they can just guess what your next password is they have limited means of attacking your password I would guess?

My belief is that this approach would lead to a relatively secured approach, despite the potential for guessing at passwords once someone figures out the algorithm.  My reasoning is basically that no one is looking for this algorithm and so it's likely to go unnoticed.  Is that true, or are attackers aware of people trying something like this and actively attempting to exploit it?

If the algorithm was mildly more complex than 'just append the two values", but still simple enough to be done quickly in one's head, would that do anything to increase its security?

Assuming a foo of reasonable complexity then on the face of it you would get a decent level of password complexity out of it, enough to make it very hard to brute force, whilst still being easy to remember.

As such it is quite suitable for sites that are of medium to low value ie not your bank or email, probably not your social media.

However sooner or later one site you use it for will be compromised and they will have stored it as an unsalted md5 hash and it will be broken.

At that point the complexity of the second part becomes critical. If it is as simple as the first 4 letters of the domain then it may well compromise the entire algorithm and all of your logins.

Literally millions of password cracks from breaches are in the public domain and are analysed by both black and white hats for this type of thing.

Just using a simple algorithm likely puts you in the top few percent of difficulty and a slightly more complex one eg face => gbdf plus a decent value of foo probably puts you even higher.

Even though the lack of reuse does prevent basic credential stuffing, any algorithm easy enough to remember and compute easily by a person is susceptible to automated analysis of existing breach data. Distributed credential stuffing is incredibly hard to detect and whilst your pattern is better than most internet users it would probably be better to use a password manager.

You could also register with https://haveibeenpwned.com

This would notify you if your pattern was exposed in a public breach.


What needs to be done on a Citrix Netscaler to protect from SSL Renegotiation attacks? I'm under the impression that the TLS/SSL renegotiation hack has been fixed.  I'm not sure if the software has to be deployed on the server side, client side, or both.

Based on this blog, TLS renegotiation is a good thing, but only if done securely... and disabling TLS renegotiation is only a temporary workaround until the server (and clients??) get patched.

Is this understanding correct?

If SSL Labs says my netscaler supports "insecure renegotiation", what must I do to make it secure?

Citrix says the vulnerability is "fixed" in newer versions of the software, but what must I do to enable it?

What is confusing me is an internal discussion that this should be disabled on the load balancer with the option of "client".  I'm not sure what that means in reality.

Here is an explanation of what this "renegotiation hack" is all about.

An SSL/TLS session begins by a procedure called the "handshake": right after connecting, the client and the server exchange a few administrative messages in which cryptography happens, and afterwards client and server have a shared session-specific secret with which subsequent data is encrypted and integrity-protected. The secure tunnel is established.

The renegotiation is the ability to perform a second handshake within the tunnel. The administrative messages are then encrypted and integrity-protected (with the shared secret which has been established through the first handshake), and they result in a second shared secret, which then replaces the previous one.

Why would anybody want to do that ? Mainly to circumvent the combined shortcomings of HTTPS and Web browsers, in particular Internet Explorer.

It so happens that during the handshake, the server shows his certificate (by which the client authenticates the server), and may request that the client does the same, i.e. present a certificate and use the corresponding private key. The client is free to deny the request (i.e. not to send a certificate) and this is not nominally fatal to the handshake (the server may elect to continue the handshake). Client certificates are rare, but are considered nifty, notably because they avoid the issues with user-chosen passwords (they have their own issues, but not the same). Some banks use client certificates, which they issue themselves to their customers.

Now HTTPS is HTTP-within-SSL. The client (browser) connects to the server, establishes a SSL tunnel, and then, within the tunnel, sends an HTTP request (or several successive HTTP requests, with keep-alive). The tricky point is that the server knows the target URL only at that point, because it is part of the HTTP request; and that's after the handshake. So the server should decide whether to ask for a client certificate or not before knowing the actual target URL.

Unfortunately, requesting a client certificate triggers some inconvenient behaviour in some browsers. In particular, Internet Explorer 6.0, upon receiving a request for a client certificate from the SSL server, displays the following "helpful" popup:

This screenshot is for a French version of Windows, but you get the point: a technical-looking popup asking to select a client certificate within... an empty list. Indeed, IE 6.0 scans the certificates in the local machine for one which matches the request from the server, and shows the popup even if there is none. This kind of behaviour is apt to confuse users, in particular a bank customer who does not have a certificate yet, since he is coming to the bank Web site for the first time, and may opt to register for the certificate-based client authentication system. That is, if he has not been scared away.

IE 9.0 appears to be better behaved in that respect, but the idea remains: client certificates are not well handled by Web browsers with regards to UI, so servers wish to request client certificates only for specific parts of the site which only "trained" (registered) users will try to reach. But since the handshake happens before the sending of the target URL, we need a renegotiation. Things are supposed to happen that way:

A client connects. A handshake is performed, and the server does not ask for a client certificate. The client is not authenticated yet.
The client sends the HTTP request within the newly established SSL tunnel.
The target URL in the request is part of the "registered area" (it is a "GET /registered/index.html" request). The server says Aha! The user must be registered, let's do the SSL thing again, this time with a client certificate.
The server asks for a new handshake (a renegotiation). This time, the server asks for a client certificate. The client complies. Note that this renegotiation happens at a "lower layer" than the HTTP request; the HTTP request is still pending at that time.
Now that the server has positively authenticated the client, he may grant the request, and send the HTTP response within the second tunnel, which has replaced the first.

Now let's have a look at the hack. The important characteristics of SSL renegotiation are the following:

The new handshake can be initiated by the server or the client at any time (the scenario explained above assumes that the server triggers the renegotiation, but in SSL the client could trigger it too).
The whole handshake business happens at the tunnel level, regardless of the applicative data (the HTTP requests and responses) which are transported in the tunnel.
The handshake messages for a renegotiation are byte-to-byte identical to what they would be for a first handshake (except that for a renegotiation, the messages go through the encryption layer established by the first handshake).

So, now, the attack. We assume a server like the one described above. Moreover, some requests that can be sent to the server have an "effect" which requires client authentication, and is valuable to the attacker (e.g. a request for a fund transfer). So the attacker first puts himself in a Man-in-the-Middle situation: he can intercept, and modify at will, the bytes exchanged between client and server. The following scheme illustrates how the attack goes:

The attack steps are thus:

The honest client wants to connect, and thus sends the first handshake message (dubbed "ClientHello").
The attacker temporarily blocks that message. Then, the attacker establishes a SSL tunnel of his own with the server, as if he was a normal client. Since the attacker is in the MitM position, he can mimic the client in all its details, including alleged IP address. The server does not ask for a client certificate yet, so the tunnel can be built successfully.
Within his tunnel (that's the red part in the schema above), the attacker sends an HTTP request, for a funds transfer.
The server says: "hold that thought, client, for a funds transfer I need to authenticate you with a certificate". And the server initiates a renegotiation, by sending (to the attacker) an "HelloRequest" message.
The attacker then forwards, encrypted in his tunnel, the initial ClientHello sent by the honest user (who is still waiting at that point).

At that point, the client believes that he is doing his first handshake, and exchanges handshake messages as cleartext. The attacker intercepts them all and encrypts them within the tunnel he established with the server; the attacker also decrypts the handshake messages from the server and sends them to the client. From the point of view of the client, this is the first handshake ever for this connection; from the point of view of the server, this is a renegotiation. But since the handshake messages are identical for both types of handshakes, this works. The honest client successfully concludes his handshake with the server, even though the messages have been transported by the attacker. The server is now content with the authentication from the client...

... and the server just assumes that the client authentication is valid for everything it exchanged since the first handshake, including the POST request made by the attacker. And that is the security issue.

So, who is to blame and how to fix ?

The trouble is that while the TLS specification describes the notion of renegotiation, it does not detail the actual security properties which are achieved in such a situation. Roughly speaking, the renegotiation establishes new cryptographic properties which have a forward effect. Notice that in all of the above, the fundamentals of SSL have not been violated: the honest client does a handshake with the server, with authentication, and whatever the client and server send after that handshake is protected and authenticated.

But in our attack scenario, the server wishes to transport the client authentication, obtained through the renegotiation, over data which was received before the renegotiation (the POST request). That's a backward effect, and, as shown above, this is not part of what SSL renegotiation provides.

So we can blame:

the TLS specification, for not being clear about what renegotiation actually does;
the server designers, for just assuming a backward transport of authentication;
the HTTPS designers, for putting HTTP within a SSL tunnel instead of integrating SSL into HTTP with a STARTTLS command;
the Web browser implementers, for their terrible handling of client certificates.

Blaming is fun but not constructive, so let's see to the fix. For the specific scenario described above, the fix is RFC 5746. It consists in modifying some handshake messages so that messages for a first handshake and for a renegotiation are distinct from each other. Coupled with the cryptographic binding inherent to handshake messages (a handshake message ends with verification messages which are computed over a hash value of the previous messages, so our MitM attacker cannot alter the contents of the handshake messages), this fixes the issue described above. For a more generic solution, the biggest difficulty is defining what we really want; but we know that it entails making the upper layers (e.g. HTTP) aware of the cryptography which occurs underneath. One can have a look at RFC 5056 for a discussion on the subject.

Another possible fix is to modify the application protocol so that the server does not try to transport the authentication in the backward direction. In an HTTP context, this would entail responding to the first request (the unauthenticated request which urged the server into making a new handshake) with an HTTP temporary redirect, so that the client sends the HTTP request again, this time after the new handshake (so the server would first make the new handshake, then send the redirect response).

We may note that the same issue does not raise with client authentication with passwords (HTTP "basic" authentication within a SSL tunnel) because with such an authentication, the server asks for a password, and the client sends it after repeating the target URL. So the issue is not applicable to many Web sites.

Apparently, Citrix found it fit to publish fixes, but without much details. They do not say whether they just changed the way the server asks things (a server-only fix), or whether they implemented RFC 5746, which is a fix only as long as the client supports the extension too. Firefox has supported RFC 5746 since February 8th, 2010. For Internet Explorer (actually Windows, since IE uses Windows' SSL/TLS code), this was part of a patch published on August 10th, 2010.

Possibly, Citrix Netscaler was not affected at all, but the people at Citrix found it smart, as part of Public Relations, to show that they feel concerned about security issues, and added a "fix" which would be more psychological than technical.

My advice would be: apply the patches published by Citrix, and make sure that the client software (OS, browser...) is up-to-date (something which you already want anyway). Then you should be safe from that obscure TLS renegotiation issue.


What, specifically, does the Windows Firewall do? My understanding of the situation is that, when the Windows firewall is off, every port on the computer (all 65535 of them) is fully open. This means that any application running on the computer can send any traffic from the computer through any port to any device on the network or the internet. This also means that any device on the network or the internet can send traffic through any port on the computer.

When the firewall gets switched on, every port is closed (as in inbound and outbound traffic on every port is blocked) unless the user specifically opens one, or Windows UAC indicates to the user that a particular port on the firewall needs opened for an application to run (this usually happens when an application is being installed). In this scenario the user clicks yes and Windows configures the firewall to allow the application to function properly on their behalf.

So there we have it. If the firewall is off, every port is open and any application running on the computer can send and receive data through any port if it is designed to do so. Also any device that can connect to the computer (as a rule of thumb any device that can ping the computer) can send data through any port. Also, turning the firewall makes everything nice and secure right?

Firstly, I am sure that there is more to the Windows Firewall than this so what am I missing? Secondly, what have I misunderstood or got plain wrong about how the firewall works? Thirdly, is it as important as I think it is to have the firewall switched on at all times (I think it is very important) and lastly is the firewall as effective as I think it is (I am currently under the illusion that it is very effective).

Thanks

This means that any application running on the computer can send any traffic from the computer through any port to any device on the network or the internet. This also means that any device on the network or the internet can send traffic through any port on the computer.

Let's deal with that notion first...

Getting traffic on the internet over TCP/IP is kinda like sending post (with a few inconsistencies) to an apartment block. The IP address maps to the address of the apartment block and the TCP port to the apartment number in the building.

In order to send a packet to this address, you must first own an apartment in real life so you have a return address. Then, you try posting your parcel.

If nobody lives in that apartment, your package won't be received. It'll be left in the lobby with the porter and probably abandoned. The same is true of TCP ports - if there's no application listening (or "bound") to the port, the OS won't pass it into an application. However, the porter (the OS) does indeed handle that packet, if only briefly. Bugs in the porter are quite serious.

Now, in reality, just like with post, it's not as simple as you put your packet into the post and it comes out the other end. When you post your packet, your local post service take it so far, look up some information and work out which postal service to pass it on to (think international post).

Now we need to get a bit complicated. Suppose the person you want to post to works in a university building on a campus. Postal services don't deliver there; instead, they deliver to the porter in the main building; he then devices where to direct that package. This is a microcosm of the routing situation I alluded to above and is analogous to NAT.

So so far, we've learned that you can't always get packages to the requisite address, and you need someone there to receive them in the first place.

  When the firewall gets switched on, every port is closed (as in inbound and outbound traffic on every port is blocked) unless the user specifically opens one, or Windows UAC indicates to the user that a particular port on the firewall needs opened for an application to run (this usually happens when an application is being installed). In this scenario the user clicks yes and Windows configures the firewall to allow the application to function properly on their behalf.

Nope. They're only open if there's someone at home with the light on. Otherwise, the porter looks at the package and says "who dis?" before promptly binning it (putting it the trash, if you're American).

  So there we have it. If the firewall is off, every port is open and any application running on the computer can send and receive data through any port if it is designed to do so. Also any device that can connect to the computer (as a rule of thumb any device that can ping the computer) can send data through any port. Also, turning the firewall makes everything nice and secure right?

Well... in a very, very simplistic way, yes, kind of.

See, in truth, it is possible that the person living at the address you're posting to just doesn't like you very much. It's nothing personal, they've just never met you. So they don't open your package either, having had a quick peek at the sender. Many applications, e.g. webservers can direct traffic based on its incoming parameters. A common example is the HTTP HOST: header.

So, now let's fit Windows Firewall into our analogy. Windows Firewall is basically a Porter with a degree from MIT. He looks at the incoming packages and knows about people living in the various apartments. He has a list of rules which he can check recipients against - for example, he might allow Fred to receive packages from anyone on his street, or town, but not from France. How exactly he does this really depends on how he is instructed by whoever owns the building.

That is, in essence, how a firewall works. It does control what ports are open and closed and may do additional filtering based on packet destinations, sources, ports and even contents. However, the on/off idea isn't quite there. It's nowhere near that simple.

To explain, let's assume Fred and George live on the same street. George doesn't like Fred very much, because Fred uses a Mac (or your own stupid reason of choice in here. I just don't like Macs). So George decides to send Fred a stinkbomb.

Fred's porter has a rule that says if anyone wants to send something and they live on the same street, then Fred should be sent the packet. So George posts his package and next thing you know there's a smell of rotten eggs in Fred's flat.

I realise that's not the sort of IT professional-speak, so let's put it another way - your firewall only protects you according to the rules you have allowed. However, if one of those allowed rules gives an attacker a way to exploit your system, and the attacker does, the presence of the firewall will not help. This is true of Windows firewall as much as any other firewall.


Exploits or other security risks with SVG upload? I have a site, where people can upload graphics, you might think of it like an image hoster or a forum for pictures.

Now, I allow upload of raster graphics to a certain size, but no vector graphics as of yet. I'd like to allow SVG upload as well, but there are two concerns circling my head:

Could an SVG be constructed in such way, that when reading meta data it makes the server unresponsive. and could be used as DoS attack on the server?
Could an SVG be constructed in such way, that when rendering the SVG on the client, the client becomes unresponsive and potentially makes every users browser on my site crash?

Also, would it be good practice to generate a small (200x200px) PNG for a thumbnail, or is it better to just manipulate the SVG itself with a zoom factor or something?

In case those SVG exploits are possible, how can I protect myself against them?

Could an SVG be constructed in such way, that when reading meta data it makes the server unresponsive. and could be used as DoS attack on the server?

What do you mean by metadata? If you are after width and height, you would have to parse the SVG files at least partially to get it; there's no shortcut of reading a few bytes from the header like there is with many bitmap formats. That brings in the usual risks of XML parsing, such as:

external entity/DTD-subset inclusion attacks against remote files, local-network sensitive resources, local-machine sensitive files and device-files
nested entity expansion bombs
pathologically-nested tag structures might hit recursion resource limits

as a standard precaution you would disable all DTD processing, XInclude, XSL, XSI and entity resolution.

  Could an SVG be constructed in such way, that when rendering the SVG on the client, the client becomes unresponsive and potentially makes every users browser on my site crash?

Possibly, but it's just as possible that could happen with a bitmap format. See eg the corrupt PNG file vulnerabilities of a while back.

More of a concern for SVG files is that they can include JavaScript, which will operate in the security context of the hosting site, so you have cross-site-scripting to worry about.

Actually all types of uploaded file are vulnerable to this, albeit not in such a direct, easy-to-exploit way. In some cases browsers (particularly IE) will content-sniff them, and if they see things that look like tags they may potentially reinterpret them as HTML, including JavaScript. Also there are some side-issues with treating uploaded files as Java applets and Flash policy files.

The standard mitigation for all of these problems is to serve your untrusted resources, whether bitmap, SVG or anything else, from a different domain to your main site: a domain that has no sensitive session (cookie/auth) information in it and no ability to script into your main site's domain.

  Also, would it be good practice to generate a small (200x200px) PNG for a thumbnail, or is it better to just manipulate the SVG itself with a zoom factor or something?

That would be a nice touch, but you'd have to drag in some dependencies to render to bitmap, for example Batik if you are using Java. Naturally bringing in a new complex library increases attack surface; it might be a good idea to run the thumbnailer as a separate low-privilege-account low-priority daemon task.


Why can I only view HTTPS traffic from some iOS apps with ZAP? I've noticed a curious oddity with some traffic sniffing from my apps on my iPhone. I've installed the ZAP Proxy CA certificate on the device, but I've noticed I can sniff some app traffic, and others I can't. This was apparent six months ago, but I've observed now even more of my suite failing to connect via the proxy, so my presumption is a trusted certificate is no longer trusted.

I'm aware there was an issue with iOS whereby a library permitted untrusted certificates to be used, but surely if I've installed a root CA, explicitly told the device its trusted, then I should be able to view all HTTPS traffic from the device?

Failing this, is it still possible to sniff HTTPS from the device via a proxy?

Yes, it is generally still possible, but techniques like Certificate Pinning and others make it more and more difficult to do a Man-in-the-Middle Attack.

I've also observed quite a lot of apps (on Android though) and found that especially messaging and communication apps (Facebook, Snapchat, ...) try to make sniffing network traffic as hard as possible.

Upadate:

You could try to disable Certificate Pinning on your device / browser. This is easy for desktop systems (@Psiinon linked to a guide How-to disable certificate pinning in Firefox - thanks for pointing this out).

For disabling certificate pinning on smartphones, you need to root / jailbreak the device. A tool for iOS might be SSL Kill Switch 2, and for Android one could use JustTrustMe (root and xposed required).

I have tried neither of the tools listed above. Both tools are listed in this presentation by Anant Shrivastava. See slides 15 and 20.

Last note: Disabling a security feature like certificate pinning is a security threat and is only recommended for testing.


Best way to secure documents? I'm currently tasked with securing our documents stored in our NAS.

Basically, the minimum requirements that is needed are;
1) Watermarking Ability(Any file viewed/downloaded or printed will have the user's name, IP and Time/Date watermarked on the document)
2) Restriction(Not all users can view/download certain files)

I've toyed with XRDP and Ubuntu, so users have to remote into the desktop to be able to access the files, I've even installed Screenlets and used a widget to display their name on the screen but, I've been having issues getting it to work properly.

Can anyone recommend me a good solution to secure the documents? Preferably open-source and with an online document viewer, so there is no need to download the document to view it.

EDIT: Additional information. The document types will be mainly PDF, doc, docx, ppt, pptx, odt, etc. I've tried multiple solutions but, most of them either don't have the watermarking capability or, are not on-premise.

You're describing a basic content/document management system that implements a watermarking library (and online document viewer). This could be created and deployed in a few hours by someone with any coding knowledge. (I get the impression you're more of a sysadmin?)

Basically you deploy something like Drupal to serve as a frontend and handle user authentication and access control. You serve up a list of directories as pages, the user navigates to the file they want, you have a library that can modify files that appends a watermark to the metadata and serves it to the user.

Uses entirely open-source tools but requires a little elbow grease on your part, unless you want to hire a college student to write it for beer money.


Is it possible to feed Firefox Flash plugin with controlled data for privacy reasons? For privacy and security reasons, it would be strongly recommended to deactivate the Flash plugin in the browser. But I don't want to deactivate it, I want to fake privacy relevant information. Companies can create a fingerprint about a user. The Flash plugin serves much information, like:

installed fonts,
IP-address (original one behind a proxy) or
the used OS and kernel system / version

So my question is:
Is it possible to fake such information and how?

When I use for example Firefox, does Firefox serve these system information for the Flash plugin and then I can fake them with a Firefox addon which registers the call event of the Flash extension and returns wrong data? Or has the Flash plugin direct access to the operating system? If yes, can I build software which runs in the OS background and registers the Flash plugin call and then serves faked information?
I know that NPAPI is the interface between the browser and the OS, but I have no idea if it is possible to manipulate the called information in any way and if such information (like installed fonts) are parameters stored in the browser or served by the OS.

[Update]

Example:

Original data: Windows 8.1, Firefox 24, English language, 23 fonts installed

Step: i call a random website with flash fingerprinting tool
Step: the tracking tool starts to collect my fingerprint with flash, calls
action script functions to get installed fonts etc.
Step: through the action script functions, the Flash plugin tries to get the information from Firefox or OS (NPAPI)
Step: Before the flash plugin calls the data from Firefox or OS, my own developed firefox addon, which is installed, detetct and catch the event, prevent the system call and returns instead of the original data, spoofed data (OSX, Firefox 24, English language, 12 fonts installed) from my
firefox addon

Result data for Flash plugin: OSX, Firefox 24, English language, 12 fonts installed

At 4. step i want to spoof system parameter. And the question is, if this is possible in general (with a Firefox extension or a OS native application) and how. And: from where does the Flash plugin get the system information? From Firefox parameter? Through the NPAPI interface from the system?

I know, that there are other fingerprinting opportunities (JavaScript, User Agent, CSS with Cache, Flash Cookies, HTTP-Cookies, etc.), but the focus of this question are the system parameters (installed fonts list, OS, etc) of the Firefox Flash extension.

Is it possible to fake such information and how?

You want to fake such information in order to evade browser fingerprinting done by some websites but you have to know that the simplest fingerprinting algorithm deployed today is able to detect, follow and even guess a fingerprint's changes. Also, you have no idea about the fingerprinting algorithm you want to foil.

An other problem fired by your question is how to fake such information. Well, there is no solution that fits for all the cases. I mean depending on the information you want to fake different solutions and tools may exist or not. For example, I can mention you the Firfox User Agent Switcher which is an addon that performs what its name says.

  When I use for example Firefox, does Firefox serve these system
  information for the Flash plugin and then I can fake them with a
  Firefox addon which registers the call event of the Flash extension
  and returns wrong data? Or has the Flash plugin direct access to the
  operating system? If yes, can I build software which runs in the OS
  background and registers the Flash plugin call and then serves faked
  information?

From the way you worded these question, I feel there are important things you need to know first in order to avoid some erroneous (if I may say so) questions you made:

Can I get hardware and operating system information with Flash?

You need to look to the Capabilities class and see what information it can get from your operating system and hardware. For instance, the cpuArchitecture property  specifies the current CPU architecture. The cpuArchitecture property can return the following strings: "PowerPC", "x86", "SPARC", and "ARM". The server string is ARCH. while the os property specifies the current operating system.

Note:
This paragraph does respond to the question whether such data may be sent using a Flash web application over Internet or not. That will be discussed later on.

What is a Flash web application?

A Flash web application is any SWF/FLV content that can vary from  a video you want to view on your browser to a full fledged and complex  application where Flash plays a very important role such as in sharedtalk.com
What are local shared objects?

The problem with running Flash web application (apart from the Flash vulnerabilities that you are not addressing here) resides in what we call local shared objects (LSOs) better known as Flash cookies. Flash cookies are relatively unknown (Schneier on Security: Flash Cookies).

While an HTTP stores only around 4KB of data, a Flash cookie contains up to 100KB data (ActionScript3.0 Cookbook). You can even enhance the storage capacity of a Flash cookie at your will. A Flash cookie is not stored in a file within the browser space but in a separate Adobe file with a .sol file extension: this means the browser has no control over Flash cookies and when you clear your browser's cookies, Flash cookies are still there on your computer (but there are tools to delete them).
Which content may be stored within a Flash cookie?

For HTTP cookies where contents are determined by the specific website that created that cookie. Contents vary from site to site. This applies for Flash cookies.

The Flash cookie is used generally to save user's settings (for example when you watch a video on Youtube and change the dimensions of the video screen: the dimensions are stored in the Flash cookie).
What are the main privacy issues inherent to LSOs?

Flash cookies contain the information that may be hold in an HTTP cookie and much more except the field related to expiration date: Flash cookies do not have an expiration date by default as it is the case with HTTP cookies (where the common practice of companies' websites set it usually set to 30 days); and one of the reasons for this is because when companies tracking users noticed that lot of users clear their cookies at least once per month lead  to overestimate  the number of true unique visitors to websites, and thus to the overpayment for advertising companies  (The  Impact of Cookie Deletion on the Accuracy of Site- Server and Ad-Server Metric s: An Empirical Comscore  Study).

But what is worse, is that a Flash cookie may recreate HTTP cookies you previously deleted (respawning cookie, persistent identification element)

Note that the less aggressibe LSO contains the globally unique identifier that identifies your computer for the web application that tracks you.
What is Flash hardware acceleration and why to mention it?

Hardware acceleration is  when you have hardware designed to accelerate a specific function. So, for example, when you decode or encode video you do it on the CPU. Some video cards allow you to do this on their GPU instead, so you now have "hardware accelerated video decoding". (What does “hardware acceleration” refer to?). Flash hardware acceleration is a hardware acceleration for Flash (Performance or display issues with certain Flash videos). In most browsers this feature is disabled by default, but activating it to better visualize a given web Flash application exposes you to reveal more information about your hardware.  But why to mention this? Because such information is stored in LSOs.
So may my OS and hardware information be leaked out?

I prefer to quote you this directly from the official documentation (Flash player help)

  Note that it is the person or company that has created
  the application you are using that is requesting such access, not
  Adobe (unless Adobe has created the application that wants to save the
  information). It is the responsibility of the person or company
  requesting access to make it clear to you why they want access and how
  they plan to use the information they save. You should be aware of the
  privacy policy of anyone who is requesting access to your computer.
  For example, see the Adobe privacy policy. Contact the website
  requesting access for information on their privacy policy.

Also, one important thing to read from that documentation:

  (Flash Player 8 and later) If you have downloaded SWF or FLV content
  to your computer, a dialog box might appear alerting you that the
  content is trying to communicate with the Internet. Flash Player 8 and
  later versions do not allow the local SWF or FLV content to
  communicate with the Internet, by default.

And since it is possible to retrieve both OS and hardware information using the Capibilities class described in the first point, and a Flash web application may require, under your permission as you can read from the same last link, more than 100KB, and if the web application is nefarious the definite answer to your question is that it is likely, I mean possible, to happen especially with a misinformed user about security issues.

Given these information, you may achieve what you asked (surely no one will tell you how) after digging deeper. But remember: if you want to do that in the purpose of evading brwoser fingerprinting then better forget the idea and use traditional methods.


Is it possible to detect IDS name and version the title said it. Is it possible to detect IDS name and version. If server use Snort as IDS, would I be able to detect it from external PC? And if it's possible how?

Network IDS's tend to run passively, so they don't respond to network traffic: they just listen.

No way to get it to respond in such a way as to determine that it is running, what kind, or what version. You'd need to go a different route to glean that info.


For users that does not use PGP, what would be the other channel to securely send them a document? I would like to send a document that is confidential to users that have no clue what PGP is (so no point in teaching them how to install it etc...) via email.

The real question is how to do that?

Currently I am thinking of the following approaches and wondering whether anybody knows which one is the most secure:

I have the following options:

encrypt it using the security functionality provided by Microsoft Office Word. Then the name of the document is visible! And I don't know whether or not I should trust this encryption method from Word.
Encrypt it with WINRAR. I can encrypt even the document name, so upon opening, they should be prompted to provide the password and hence even the document name is encrypted.
Make it a PDF file and encrypt it using PDF. Similar to Word maybe a bit more powerful / or less??

Of course some would say use a combination, but I don't want to look that paranoid to my customers ;)

You assume that the document has to be sent via email.  It sounds like you are only protecting against interception while the email is being sent (smtp).  If that is the case, you only need secure transport and not necessarily encryption handled by the end user.

Can't you have them download the document from a web server you control over SSL?  You still have to give them the URL and password in some manner, but at least you can remove the document from the webserver.  They are going to have a clear text version of the document anyway, so it doesn't matter if you keep it in the clear on your webserver, but behind a password.  You can control access and pull it down after they get it.


Does compromise of one cPanel / WHM account on a server mean the other accounts are at risk? I have created multiple cpanel accounts using my server WHM panel.

As of now each domain has separate cpanel in my server.

If one of my cpanel (domain) hacked, does that mean other cpanel are hacked too?

Allow me to start off by saying that setting up a secure WHM & cPanel environment is a very difficult task. There are many source of information on that topic, such as:

10 Tips for making your cPanel and WHM servers
WHM Recommended Security Settings Checklists
How To: WHM Server Hardening And Security Basics

As for your question itself. WHM creates separate cPanel accounts with the aid of the Operating System's access control and permissions; each user has their own directory and they're given access to only what's theirs, so a compromised account shouldn't normally be a problem. But if all of your accounts exist on the same dedicated server, it means that an attacker could exploit a privilege escalation vulnerability to gain access to your root account. From there, it's Game Over. All of the other accounts and even your WHM control panel will be compromised.
Another possibility is a vulnerability in the WHM software itself.

The reality of the situation is somewhat different. Yes, there is a possibility, but the likelihood is very low. WHM is widely used by hosting retailers and we don't hear a lot about major attacks on it.

Conclusion: If you follow the recommended security practices, you've shaved the vast majority of the danger.


How should clients' passwords be managed? How should clients' passwords be managed? By "clients" of course I mean people who you provide a service to, people who need you to work on their stuff (their websites, their servers, their emails, or other services they use in general).

Every time I read about password managers, I always see examples and arguments that only involve personal passwords, not passwords managed on behalf of other people. And I'm not sure if using a password manager for this purpose is a good idea, or if there are better standard practices. What if I'm managing passwords for a hundred clients, and I get hacked? Should I tell each client "Sorry, I got hacked, now we need to change your email password?" A better option would be to avoid storing other people's passwords, but that would mean you'd have to keep asking the client to provide their password every time you need to access their services (which might be often or rarely, depending on the kind of support). Lots of clients might not even know (or regularly forget or lose) some of their passwords, for example those needed to manage their domains, or their web panels, etc., all stuff they never touch but it's still technically "their stuff" anyway.

So I'm wondering if there are some better methods, policies, or practices to deal with these scenarios, or if the usual password manager with "all eggs in one basket" (my eggs and everybody's eggs) is still the only solution.

In an ideal world, you should never use other peoples passwords, and therefore you should have no need to store them. If you need to use a service on behalf of a client, you yourself should have an account at that service and the client should make sure your account has sufficient priveliges for you to do your work. Here you have a clean division or responsibilities - you are responsible for your own account.

In the real world, this is not always possible. You should avoid these situations as much as possible, and only take responsibility for other peoples passwords when you really have to. But let's face it, some times you just have to.

Then a password manager is the best solution. Some advice for how to use it:

Pick a good master password. And when I say good, I mean good.
Consider using an offline password manager, so no files uploaded to any servers anywhere.
2FA (e.g. require a hardware token to decrypt) is also a good idea.
You may want to create separate accounts for each client. Only do this if it is feasible without compromising the quality of the master password.
Finally, be completely transparent with the person who's passwords you are handling. You want to make sure that they know and accept what you are doing. There are probably a ton of legal aspects to this as well, but unfortunately I have no insight into those.


Is an LDAP injection possible for a basic search query? I'm trying to secure a login endpoint by attempting to bypass the login that uses LDAP.

It employs a search query of "cn=" + username + ", dc=example, dc=com" with a filter of "(objectClass=*)".

Is an LDAP injection attack possible here with username? Obviously, I will eventually escape all the queries and filters.

It's not the queries and filters you should be escaping – after all the complete queries and filters do have special characters in them and escaping them would cause the query or filter to break. Instead, you should sanitize the data coming directly from the user, here the username.

As you don't specify the programming language, it's hard to give examples on how this should be done, but if the language has some LDAP encoding functions, you should use them instead of implementing your own.

Although the distinguished name DN has less attack surface than the filters, it still has some special characters: according to OWASP LDAP Injection Prevention Cheat Sheet:

  There are certain characters that are considered special characters in
  a DN.

  The exhaustive list is the following: \ # + < > , ; " = and leading or
  trailing spaces.

  Some "special" characters that are allowed in Distinguished Names and
  do not need to be escaped include:

* ( ) . & - _ [ ] ` ~ | @ $ % ^ ? : { } ! '

E.g. with your "cn=" + username + ", dc=example, dc=com" one could descend
to organization units below the intended OU using "username" aiyan, ou=Administrators, ou=Secret, which would then find the user in

cn=aiyan, ou=Administrators, ou=Secret, dc=example, dc=com


Does Google check for Unicode characters to determine spam now in Gmail? I was reading some tweets from @pwnallthethings regarding the John Podesta spear phishing emails.

What the email looked like:

The Change Password button link, notice the domain com-securitysettingpage.tk

From @pwnallthethings:

  You're probably thinking "wow how come Google algorithms didn't catch
  this email, it's right there asking for your password?". Because the
  letters aren't English to trick the filters. Hackers are smart.

To be specific they are probably Homoglyph unicode characters. Below you can find quite a nice tool to create a text using homoglyphs.

https://www.irongeek.com/homoglyph-attack-generator.php

Example:

ASCII:

Ogglas

Homoglyph unicode:

Οɡɡⅼɑѕ

Does Gmail check Unicode now or is this "vulnerability" still in affect? Most of the spam emails I receive are correctly identified but some still slip through. Some using Unicode but some are still plain ASCII characters.

Find Unicode characters using Notepad++:

https://stackoverflow.com/a/20890052/3850405

Some more articles:

https://www.nytimes.com/interactive/2017/01/06/us/russian-hack-evidence.html

http://p3isys.com/p3isys-tech-blog/153-podestahack

Yes, Google checks for unicode homoglyphs in email now. This is primarily done to make it easier to recognize spam, but it also works fairly well against many phishing attacks. This change was actually done in 2014. In particular, they are using an open standard from the Unicode Consortium for restricting homoglyphs. However, while this does improve security, there are a large number of potential ways to bypass it. A presentation from DEF CON 26 went over some of the possible ways to bypass such detection mechanisms and why it's so difficult to comprehensively detect such attacks from software.


Is pressing random keys a secure way to seed a key generator? There's a couple of programs that I've been using recently that ask you to type random keys as a source of randomness to seed an RNG for key generation.

Is this considered a good practice still, or is it better to rely on /dev/urandom and company as an entropy source?

Yes, but that's how you're getting randomness anyway. In Linux and most other operating systems, the exact time in nanoseconds that a key is pressed is recorded and injected into the entropy pool. This pool is used to seed the CSPRNG that powers /dev/urandom and other cryptographic random APIs.
The similar /dev/random character device is what we describe as blocking. It assumes that all used cryptographic functions are broken (a worst-case scenario) and so will only output randomness when it thinks it has "collected" enough entropy. When you type keys, the operating system uses that as a source of entropy and increases the entropy estimate, causing /dev/random to unblock. This speeds up the entropy collection by programs using that device. Now that doesn't mean that the program sare doing the right thing. They should have just used /dev/urandom which does not block and is still quite cryptographically secure. You should take a look at https://www.2uo.de/myths-about-urandom.
A related document on best practices for randomness generation is BCP 106.


Can server side communicate using cipher that not listed in the CipherSuite? I use these protocols in the configuration of Apache HTTPD server

SSLProtocol -ALL -SSLv3 +TLSv1.2

I have configured these SSLCipherSuite:

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCMSHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCMSHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSAAES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSAAES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSAAES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

I used script described here https://superuser.com/questions/109213/how-do-i-list-the-ssl-tls-cipher-suites-a-particular-website-offers to obtain the list of actual ciphers:

Testing ECDHE-RSA-AES256-SHA384...YES
Testing ECDHE-RSA-AES256-SHA...YES
Testing DHE-RSA-AES256-GCM-SHA384...YES
Testing DHE-RSA-AES256-SHA256...YES
Testing ECDHE-RSA-AES128-GCM-SHA256...YES
Testing ECDHE-RSA-AES128-SHA256...YES
Testing DHE-RSA-AES128-GCM-SHA256...YES
Testing DHE-RSA-AES128-SHA256...YES

Can server side communicate using cipher that not listed in the CipherSuite?
For example can the server side communicate using this DES-CBC3-SHA cipher?

I ask different question. One who use our customers claims that we uses DES-CBC3-SHA. I am sure it is not possible but I will happy for the confirmation.

In short: the client offers the ciphers it likes to use in the ClientHello message of the TLS handshake. The server chooses one of these ciphers based on what is configured on the server side. This means that the server will not chose a cipher from the clients listed when it is not configured on the server side too.

What you describe can thus in theory not happen. In practice it can happen if you look at the configuration of one server but the client actually connects to a different server. This can be for example a SSL terminating load balancer which might forward the clients traffic again with SSL to you, but where the SSL handshake is done between the load balancer and the client and not your server and the client. In this case your configuration does not matter but instead the load balancers configuration is the relevant one from the perspective of the client.


Caching Behaviour on major browsers Before I even ask the question - this is a hard question to frame, so I welcome edits to improve clarity.

How do major browsers decide how to cache responses, especially if said responses are retrieved via AJAX, and have no explicit Cache-Control, or other cache related headers?

The applications I am testing are both fairly similar, in that they use a JavaScript MVC for rendering the page, responding to user actions, and making XHR requests. All responses are in JSON, except for the main page. Both applications are over HTTPS. Application 1 has the HSTS header set, Application 2 does not.

Neither of these applications set Cache-Control headers explicitly. However Application 1 does not cache information, while Application 2 does cache information. The only important distinction between the two is that Application 1's URLs are in the format <URL>/#/some/action/performed while Application 2's URLs are simpler, i.e. <URL>/someaction. My primary argument was that the browser does not cache responses that are returned to any URLs that contain # in them, because as far as the browser is concerned, it is all the same page. However, I am not convinced with this argument, simply because at the end of the day, it is all XHR requests that are being made, so why the different behaviour between applications?

First of all; officially everything after the # isn't part of the URL with respect to requests and responses. It isn't sent to the server, and it is ignored when retrieving and setting caches. It appears in the URL bar, but isn't not part of the resource's specified location.

With respect to the question of how do browsers determine whether to cache pages; the answer is "it depends". IE is somewhat notorious for caching XHRs even when the cache-control header explicitly says not to, which is why jQuery's ajax cache avoidance mechanism exists. The workaround it uses is to append a GET variable with a simple monotonically increasing counter. This makes each request a new URL--because /foo.php?x=123 is a different URL from /foo.php?x=456--and therefore a guaranteed cache miss.

Note that in contrast /foo.php#x=123 followed by /foo.php#x=456 is a potential cache HIT, because the resource in question is just /foo.php, and #x=123 is stripped off before retrieval.

As for what the standard is, I believe that if no cache or age is specified, then the cache behavior is undefined: the browser's author is free to make up his own mind as to what is correct. Different browsers will probably behave differently. And browsers are (well, one browser in particular) famous for basing important behavioral decisions on seemingly random factors. So in that case, making the cache decision based on the URL Fragment is possible despite being absurd.

So, if you're using one of those browsers that makes your more technically-minded peers laugh at you, then expect to experience unjustifiably weird behavior. Don't try to explain it, you'll only make yourself angry.

On the other hand, if you're the app developer then, (A) explicitly set a cache policy in your response headers and (B) if you're dealing with IE then use cache-busting GET parameters.


Possible to sign an imported key with a subkey using gpg? In the interest of safeguarding my master key I store it offline. I have a gpg subkey with indicator SEA that I keep available on my system. When I download software I verify it using the provided asc file and the developer's public key by importing his/her key into gpg and running

  gpg  --verify  filename.asc  filename

In the interest of eliminating the 'not certified with a trusted signature' warning I expected to be able to sign the developer's key with my subkey. However, I get the error

  gpg: signing failed: No secret key

I tried to override the signing key with

  gpg  --local-user  subkeyid!  --lsign-key  developer_keyid

but I still receive the same error. Is it possible to sign a developer's key with my subkey using gpg? If so, is it a good idea and why or why not?

Thanks in advance!

“Signing” a user’s key (in fact, that’s signing his identity) requires the “Certify” capability. As far as I know, GnuPG does not allow you to create a subkey with the “Certify” capability (I don’t know whether the OpenPGP standard allows this). So, unfortunately, no, you cannot “sign” a user’s key with your subkey.


When pushing a DNS resolver to an OpenVPN client, does the resolver see the IP address of the client or the OpenVPn server? When configuring an OpenVPN server, you have the option of pushing DNS resolvers to the client - like so:

push "dhcp-option DNS "

If this approach is used and a public DNS resolver is defined, will the DNS lookup be performed via the connected OpenVPN client, or by the server? In other words - will the DNS resolver see the real IP address of the client running the OpenVPN software, or will it see the IP of the OpenVPN server?

The DNS server will be access based on the routing table and thus the answer depends how the routing is setup and where the DNS server is. Usually: if the DNS server is in the same subnet as the OpenVPN then it will see the OpenVPN specific IP of the client. If the DNS server is outside and all traffic is routed through the VPN then it will see the public IP address of the tunnel endpoint.


Is there any difference between visiting Facebook via their Tor address, and visiting them via their normal address over Tor? From a security perspective, is visiting via the .onion address more/less secure?

I'm using Facebook as an example, but this question is really about any website which has both a 'normal' and a Tor URL.

Here is what using Tor to access an ordinary, non-onion facebook URL looks like:

You -> Tor... -> facebook.com

Now both of those links (from you to Tor and from Tor to facebook.com) happen on the open internet, so an attacker might watch packets flowing across those links like this:

You -> (attacker) -> Tor... -> (attacker) -> facebook.com

In a timing attack, the attacker watches the flow of packets and eventually correlates the timing of packets flowing between you and Tor with the timing of packets flowing between Tor and facebook, and hence realizes that you're accessing facebook. Note that this only lets the attacker determine that you're using facebook; if you're communicating with facebook over https then a timing attack does not help the attacker decrypt your communications.

More on timing/correlation attacks here: https://www.torproject.org/docs/faq.html.en#AttacksOnOnionRouting

Accessing facebook via a hidden service should prevent trivial timing attacks, since it's then much more difficult for an attacker to identify packets flowing between Tor and facebook.


How is the strength of a DDoS attack measured? The DDoS attack on Dyn by Mirai malware that disrupted the internet was largest of its kind in history. Experts say that its strength was 1.2 Tbps. I don't understand the math behind it. How is the strength of a DDoS attack calculated?

It sometimes is hard to measure the exact size of a DDoS attack. When links get saturated you can't tell from the victim's perspective how much more traffic was sent to your network than your network's links could handle. If your network has a 100Gbps uplink, you can't tell the difference between a 100Gbps attack and a 1.2Tbps attack from within your network, since the effect is the same: the link is saturated.

The only place you can check that is at the upstream networks of the network under attack. But it can be the case, especially with enormous attacks as on Dyn, that even links on their network get saturated, so you'd have to check statistics for traffic towards the victim of the DDoS on their upstream networks as well.

Calculating the exact size of the attack may get even more complex when networks between the attackers and the victim are filtering some of the DDoS traffic. Some network automatically filter or rate limit known bad outbound traffic from their network, so it never even reaches the network under attack or its upstreams.

To sum it up: it's hard to give an exact measurement of the size of a (large) DDoS attack, but by aggregating statistics of the network under attack and its upstreams you can make an educated guess.


How can I tell if my ISP account password is encrypted? How can I be sure my ISP encrypts my account password?  I found out accidentally that mine did not.  I had called to report an interruption in service, and in the process of "troubleshooting", the tech read my password off to me!!  What can I do about this?

Other than calling them up and asking (and then hoping your contact knows what they're talking about), you cannot tell if the password is encrypted: anything that can be done with a plain-text password can be done with an encrypted password.

The best clue that the password is hashed (stored in a non-recoverable manner) is how they deal with forgotten passwords.  If they have you provide a new password or send you a temporary password, it's probably hashed.  If they can tell you what your password is, it's encrypted or stored in plain text.


How to use Nmap as a port knocking client? I want to use Nmap for port knocking on CTF machines, so I've read the manual for configuring it properly:

nmap <ip> -p <port1>,<port2>,... -r --max-retries 0 --max-parallelism 1

In particular, -r ensures ports are scanned in the listed order, --max-retries 0 ensures that ports are not probed more than once, and max-parallelism 1 ensures that only a single thread runs.

However, the above Nmap command fails to open the hidden service. If I instead use the following port knocking client everything just works:

https://github.com/grongor/knock

Any ideas?

The knock script sets the socket to 'non-blocking'. Non-blocking in python is the same as setting the timeout to 0 - that is, don't wait for a response. The TCP protocol defaults to 'blocking' - i.e wait for a response.

From Knock git the relevant line is: s.setblocking(False).

Try playing with the settings in nmap that set timeouts to 0:

https://nmap.org/book/man-performance.html

--min-rtt-timeout <time>, --max-rtt-timeout <time>, --initial-rtt-timeout <time> (Adjust probe timeouts) or --host-timeout <time> (Give up on slow target hosts) (suspect it will be the first one though).

Also, you might find that having wireshark running in the background to capture all the traffic to and from the server being useful, as you'd have a record of what was being sent when using nmap and knock, you might uncover something that way by comparing the results.


Best way to encrypt a username in a database? In my database, I would like to encrypt every identifiable piece of information, including the username, such that people with access to the database cannot deduce the actual username (because it could potentially indicate the actual identity of the user).

And, also, users should have the ability to log in.

What would be the best strategy to achieve this?

Currently, I am hashing the username and password together (it's ok that it can never be decrypted).
However, this introduces the ability to perform a rainbow table attack (or?).

My next idea would then be to discard a large chunk of the hash -- large enough so that any outcome of a rainbow table attack would become inconclusive. This would of course introduce a higher collision rate, which is undesirable.

Then again, a rainbow table attack would be able to produce a set of candidates, which would not be good.

Are there any other known strategies to this kind of problem?

There is a standard solution to defeating rainbow tables: Add a salt to what you are hashing. A salt is a random value which you generate separately for each password hash and store together with that hash.

This, however, requires that you have to know which hash you are checking against (unless you want to try every single entry in your database until you found one which matches, of course. When your solution doesn't need to scale to a large number of accounts, this might be a viable option). So you will need to know which account the user wants to log into before you can check if their password is correct. What you could do is to have three columns in your database:

hash(username)
salt
hash(password + salt)

When someone tries to log in with the credentials admin : hunter2, you generate the hash of admin. use it to retrieve the salt, calculate the hash of hunter2salt and see if it matches.

Now it is of course possible to brute-force usernames, and do it even faster with a rainbow-table. But usernames should usually not be nearly as sensitive as passwords. You can make that less convenient by using a slow has function and by using a pepper (a salt which is the same for every entry - works against pre-calculated rainbow tables).


Is it a good idea to use an OpenPGP key that has no password? I'm tarballing and compressing backup files of my system configuration, and other important stuff. The process of tarballing, compressing and encrypting happens every time rsnapshot changes something in my backup folder, which means inserting the password of my personal GnuPG when I want to encrypt the tarball file to, well, myself.

I want to know if doing encryption of files in this way is safe and don't represent a security risk for my files.

This is how I'm currently encrypting files to myself:

#!/usr/bin/sh

UBICACION=/home/jorge/respaldo/configuracion\ del\ sistema
chown jorge "$UBICACION/respaldos.tar.7z"
# lo ciframos
DISPLAY=:0 sudo -u jorge -- gpg --no-tty -z 0 --no-greeting --encrypt --sign --yes --local-user elcorreo@deshackra.com -r elcorreo@deshackra.com "$UBICACION/respaldos.tar.7z"

Encryption does not require the private key

First of all, encryption does not require the password of the private key, encryption is peformed using the (unprotected) public key. The operation requiring the private key's passphrase is signing the data, do you really require this for your backup strategy?

Potential risks of unencrypted private keys

There is one obvious risk: if an attacker gets access to your unencrypted private key (ie. one without a password), he has immediate control over the key. If the key would have been encrypted (by a password), there would still have been the barrier of the password.

With other words: yes, this is a security risk; how large it is depends on your very specific use case, security practice and environment and can hardly be weighted by anybody but yourself.

To get a feeling whether this risk is something you want to take, consider (likely among others, this surely is no complete list):

chances of the machine/hard drive being stolen (in case it's not reasonably encrypted anyway)
somebody might get (physically) hold of the unlocked computer
you share the private key by accident or software issues
unpatched exploits in applications you use, allowing an attacker to backdoor your computer

Use gpg-agent

As an alternative, consider using the GnuPG agent gpg-agent, which is necessary with newer versions of GnuPG anyway, and allows you to cache your passphrase for a while (the exact duration can be configured), which reduces risks heavily without including too many hassles in daily use.