wlan security - why is it not possible to protect against deauthentication flooding Wireless security (Wikipedia) describes security issues due to the fact that wi-fi deauthentication packets are unencrypted:

  Weak PSK passphrases can be broken using off-line dictionary attacks by capturing the messages in the four-way exchange when the client reconnects after being deauthenticated.

Why is it not possible to protect against wlan deauthentication flooding. I understand that unencrypted managment frames are part of the standard, but why the hack is this necessary??? Especially for something as critical as a deauthentication packet? I asume there are some crytographic reasons for this, but I have no concrete idea, which is why I am asking. It would be great if anyone would know an answer.

Authentication and de-authentication is written into the protocol at a lower level than the encryption. It is the same regardless of whether you use WEP, WPA, or nothing at all.

The risk here is denial of service. A lot of de-auths can mean a lot of re-auths and that can chew things up. Properly implemented and using a good key, the encryption should not be at risk regardless of how many times the encryption is setup.

De-authing is a convenience for the attacker, but it is reasonable to assume that in a 24 hour period somebody will authenticate. If your attacker is interested in something beyond easy internet access, they'll get it.

This isn't the only case you'll find like this. SSL on TCP/IP has the same vulnerability -- the TCP flags, including the RST flag, are plaintext. How else do you tell somebody to end a connection if your system gets out of sync with their system?


Infecting synchronized devices through the cloud I have a laptop with Windows installed and iPhone both synchronised to Dropbox. Also I use Google Drive app on my phone and on my laptop I access Drive using browser. Which way of using cloud is more safe?
Also I don't have as strong security on my laptop so can easily pick up some malware. The second question is: can it spread to my other devices if one device is infected? How can I protect myself in this case?

As for Dropbox vs. Google Drive, I don't know which one is more secure.  I think it's a matter of personal preference.

If you have malware, files on your cloud drive can get infected by viruses, or encrypted by ransomware.  The infected files are then synced to your phone, but it's highly unrealistic that they could do any damage there, since Windows and iOS are very different systems.

It is possible, though, for example by a PDF file that could trigger a buffer overflow in iOS.  But then an attacker should know or guess that you use iOS.


Does having a number in your username make it more secure? So I've noticed a recent (and irritating) trend to require user names to have numbers in them.  Is there really any security value to this?

Other than the fact that user names are not password replacements, because they are often public (or at least less secured):

No, forcing a user to have a number in the input actually decreases the number of possibilites, thus making it less secure against guessing.

As small example, lets have a password of length 4, where each character can be one of 70 possible ones (26 uppercase, 26 lowercase, 10 digits, and some signs like .,?! etc.). That's 70^4 = 24010000 possibilities.
If one of these 4 characters must be a digit, there are 70^3*10*4 = 13720000 possibilities (the 4 is because the digit can be any of the 4 positions).
So without digit, there are about two times as much possibilities here.

Of course this can be generalized for any set of possible characters (as long as it's significantly more than the 10 digits alone) and any password length.

And yes, the fact that humans are no perfect random generators is missing here - forcing a digit could prevent some people from using eg. their own name. On the other hand, other people will use their name with 1 added. Nonetheless, some people actually use good RNGs (password managers etc.etc.), and like shown the digit allows less possible values.


I am having difficulty maintaining a wpa handshake (4 way handshake) airodump-ng Ifconfig wlo1
ifconfig wlo1 down
iwconfig wlo1 mode monitor
ifconfig wlo1 up
airmon-ng check wlo1
kill processes

Airodump-ng wlo1
airodump-ng -c (channel) -w (file) --bssid  wlo1
aireplay-ng -0 0 -a (mac) wlo1

I have received the handshake only a handful of times. If anybody has any advice or insight that would be greatly appreciated!

You could sniff packet using wireshark and check if your NIC is sending those packets. Anyway, I would recommend not to use aireplay with the second 0, maybe someone is trying to start the 4-way handshake and you send him a deauth packet (it is not very likely, but it could happens).


Why are network scans coming from my router? I'm seeing notifications from my antivirus software that scans are being blocked. Some are from external IP addresses, but others are coming from my router. For example, here's the text from one notification from my antivirus about a scan that, apparently, came from my router.

Attack: an intrusion attempt was blocked.
Risk Level | Medium
Attacker Computer
{router internal ip address}:53768
Destination Computer
{webserver internal ip address}:80
Protocol
TCP
Attack Signature
Web Attack: Malicious Scan Request
Attack URL
{webserver external ip address}/cgi/common.cgi
Targeted Application
SYSTEM
Status
Blocked
Action
Resolved - No Action Required
Date & Time
12/4/2017 3:07 PM

Does anyone have any idea of what is going on here?

If it's coming from your router, then your router's been compromised, no question about that. Someone is tunneling through it.

Simply resetting the IP isn't enough. You should do a factory reset of the device,  reset the password, and report the incident to the ISP.


Is it safe to put user-conrolled strings in a HTTP Location header? I am thinking of adding URL shortening to my site.

Let's say my database has already stored url as a plain string, this data was provided by the user and is arbitrary.

So a naive implementation in PHP might look a bit like this

$url = lookup_url ($_POST['url_id']);
if (null !== $url)
{
     header ("Location: ".encode_url($url));
     exit ();
}

with a suitable encode_url to ensure the user-supplied data is confined to the Location header and doesn't leak into the rest of the HTTP response or inject into the database or whatever.

Are there any security vulnerabilities in doing a redirect to an arbitrary user-supplied URL?

EDIT to clarify, in response to @UTF-8's sensible observation -- assume the user doesn't directly interact with the page they are redirected-to. Can an attacker break my security if the user follows the link and does nothing else?

No, this isn't safe. It's dangerous.

A phisher can send an email to your users and and have them click onto a link leading to https://yourwebsite.com/something/something/script.php?someVariable=doesntMatterBecaucseItWontBeRead&someOtherVariable=onlyDesignedToMakeTheUrlLonger&url=https%3A%2F%2Fyourwebsitec.om%2Fsomethinng%2Fsomething%2Fi%2Fdont%2Fcare

Users won't read nor understand that URL. They'll just have a quick look at it – in the best case – and see that it leads to https://yourwebsite.com, so everything is good in their opinions. Then, there is a whole lot of stuffing no one cares about. In the end, the get variable url is defined, starting with https%3A%2F%2Fyourwebsitec.om which is url encoded and when decoded is https://yourwebsitec.om. Notice that the TLD ending is .om, not .com. .om is the TLD ending for Oman and used a lot for phishing (or at least that's my personal impression).

The phisher can simply make the website the user is redirected to look like yours an then get their login information or other personal details from them.


Thorough computer scan I'd like to give my computer an overall deep scan against all kinds of malware.

I was infected about a year ago and I feel like there may still be some hidden rootkit on my HDD or something like that... I already performed scans with multiple AV's which came out negative.  I also ran scans with Hijack This and Farbar Recovery Scan Tool and got the results analyzed by experts - they just found some harmless adware.

Can you please recomend other ways to make 100% sure my PC is clean? Thanks!

The trouble, as described in the conmments, is that there is no way to be "100%" sure.  Anything you can devise to check might be compromised.  You can look at the running processes, but the program that shows them to you might be lying.  The system might be communicating with the bad guys in ways you can't imagine.  You can get a known clean system to watch the network, but your system might be sending out exotic packets that you don't know about, or subtly blinking the caps-lock light, or signalling by pulsing the wifi strength in Morse code.

Your only recourse is to completely start over from a known state.  Otherwise, you can be "mostly sure".


How can a PHP file be added over and over to my hacked site? I'm on a shared hosting plan (I know, I know) on GoDaddy and all the files in it have been hacked. There are multiple sites in the plan, each of them has a folder. The folders and sub-folders of each site are full of hacked files, and so are the folders above public_html.

I've deleted tons of files with malicious code and I feel I have deleted everything except that there's a xm1rpc.php file that shows up again 10 seconds after I delete it. .htaccess, configuration.php and index.php, all in the root of one of the sites, seem to get infected very fast as well.

How do they manage to do that? I've searched for crons in the control panel, changed passwords (FTP, admin, etc), what should I check for next?
So that you know, the sites are Joomla and WordPress.

You might have some backdoor in the database as inline HTML or Javascript.

If you are sure that you have removed everything from the files, look into the database.

Also, make sure you upgrade both CMSes to latest versions and disable / remove all unused modules in both so that they won't hack you again in the same way.

Also look in the WWW server access and error logs if someone is really bombing you.


Filtering safe primes for Diffie Hellman on OpenVPN When creating Diffie Hellman parameters for OpenSSH, there's a two-step process which looks like this to generate and filter secure primes for Diffie Hellman key exchange:

ssh-keygen -b 4096 -G dh4096-insecure
ssh-keygen -f dh4096-insecure -T dh4096

When reading the OpenVPN documentation, they recommend generating DH parameters like so:

openssl dhparam 2048 -out dh2048.pem

Is there a way to filter these primes for safety before using them with OpenVPN?

OpenSSL does filter the primes it generates and then outputs a single one.

You should just not use the -dsaparam option.

Source: manpage


Pass SSL certificates after verification to other components Is it possible to verify the certificate of a server and pass the certificate over to another software component over https for it to use this as trusted certificate for further communications (using CURL)?

This sounds wrong to me. Please explain.

Can the software component verify the certificate it has received from another software component is same as the one from the web server? It is really not using the chain of trust.

Can the software component verify the certificate it has received from another software component is same as the one from the web server?

It might trust the other software component that this is the correct certificate but it cannot verify this.


How can HelloSign be secure without any authentication? [Note: This is not a duplicate of Are documents truly "signed" by DocuSign?. That page does not have an answer to the specific question I am asking in the final paragraph, below. This page, however, does. Hence, not a duplicate.]

HelloTech has a series of documents they want potential technicians to sign. These are delivered by an email containing a link to their documents in the HelloSign document-signing service. Clicking this link sends the potential technician to a document they can sign, but there is no authentication step to verify that the person that's signing the document is who they say they are.

Since anyone could intercept the unauthenticated email link in transit and impersonate the signer, how could the document-signing service verify that someone who signed a particular document really did so?

how could the document-signing service verify that someone who signed
  a particular document really did so?

They don't. They do create a log showing the IP address of the remote computer that issued the "signature"; but they can't identify the legal entity that caused the signature to be made. If the identity of the signer turns out to be in dispute, the parties to the dispute can assemble evidence about that later on.

This sort of functionality is provided in the meat world by a notary public or the medallion signature guarantee system.


What's with the Facebook malware which posts obscene posts in all the groups? How to get rid of the Facebook malware which sends pornographic posts in all the groups you belong to? I always made fun of people who became victim of this malware/virus saying they are not cautious enough, but today morning, I woke up and find I have posted obscene posts in all the groups.
I removed a few apps, which I thought were suspicious and I also checked the browser extension along with recently installed programs, but I couldn't find anything and in the end, so I had to deactivate my Facebook. This was one of the most embarrassing days. I never thought I could become a victim being so cautious while browsing the Internet.

Go through the apps you gave some permission on facebook. Especially the "post on my behalf" permission. Remove any you don't trust (or don't remember giving them permissions).

Anyway, it might be a one time thing, and there is nothing to get rid of. Read through this blog post for more information.

In the extreme case, you might be indeed infected by malware (I don't think so in case you were really cautios and don't remember running any executables). However, if this is the case I recommend scanning your PC for malware (there are various forums out there where you can get help with this).


Securing a Site: Diversity over Simplicity? This question was derived from my off-topic questioning here: Does Centralisation Decrease the Probability but Increase the Damage of Exploits?

Like before, I suspect this may be overly abstract as a question. But the excellent responses to my previous question proved me wrong before.

One of the tenets of security seems to be that if something is overcomplicated, the probability of exploiting increases. For example, if an OS has many corner-cases with the permissions system, it'll probably be easier to bypass. If code involves the juggling of pointers and offsets, it'll be more likely to be exploitable via a buffer overflow than a Python script.

Simplicity, however, implies homogeneity. After all, it's simpler to secure fewer OSes, maintain fewer antimalware solutions, and patch fewer applications.

Diversity on a site -- such as a diversity of OSes, security packages, and applications -- is obviously less simple to maintain, thus more likely to fatigue the sysadmins and hide corner cases. However, diversity is also more likely to stop malware spreading due to environment incompatibilities, and if a system-dependent failure hits, it'll leave the other systems unscathed.

TL;DR: It seems that simplicity is key to security, especially security via correctness. However, diversity reduces the impact of system-dependent malware or failures. Which approach do those securing sites lean towards on the average case? (Whatever on earth an 'average case' in this situation would be.)

One of the tenets of security seems to be that if something is overcomplicated, the probability of exploiting increases.

...

  Simplicity, however, implies homogeneity. After all, it's simpler to secure fewer OSes, maintain fewer antimalware solutions, and patch fewer applications.

You're overloading the word "simplicity". You're using it to mean both "free of complication" and "having few parts".

A system can be both diverse and free of complication. Complication arises through the interaction and interdependence of many parts, and diverse systems need not be overly interdependent. By adherence to consistent interfaces and standards, pieces become interchangeable without requiring them to be uniform.

Think of automobiles, for example. We have literally thousands of varieties, each different by varying degrees. Different fuels, different sizes, different manufacturers, different purposes. But if I learn how to drive a Toyota, my knowledge immediately transfers to a Nissan or a Saab. Steering wheel, gas pedal, brake pedal; I can figure it out in seconds. It's simple.

As for diversity: If one morning all cars made by Hyundai stopped working, it'd be a problem but not an insurmountable disaster. If ceramic brakes were one morning found to be unsafe, people could switch them out for metal ones. The cost isn't zero, but the system survives.


Is letting just anybody see the appearance/html/javascript of your admin pages a security risk? Ok so consider the scenario in which you have two projects, one is a RESTful API, and the other is a public facing website.

The API uses cookie/token based authentication, and contains all of the logic of your application.

The website is built using a client-side MV* technology, what it can and cannot do is based on the role of the user authenticated by the API.

Hosting the HTML/JS/CSS of the website without introducing a third MVC framework is faster (and cheaper).

For example, you can have your RESTful API (maybe built with Django), and a server serving up HTML/JS/CSS as-is (let's say it's Apache), or a RESTful API and have the website itself using a server side MVC technology (such as .net MVC) which restricts access to the HTML/CSS/JS based on the user role provided by the API.

This will slow things down, but is it more secure? Is it worth the overhead to not allow somebody traversing through your publically available client side code to not be able to see how your admin pages look and what API endpoints they call and how they call them, or is this security through obscurity?

Surely a determined attacker could figure this out anyway by using a tool like fiddler while browsing your public pages and then analyse your API with another tool?

Thanks

I wouldn't worry about it.  Imagine it like this: if you use, say, django.contrib.admin, everyone knows what the admin pages look like.  Is that a security risk?  Not if requests are being properly authenticated and authorized.

You might want to take care that the pages themselves do not expose information you'd rather keep secret or would be useful in social engineering, such as "to reset a user's password, call the internal help desk at 212-555-4240."


Where do I find JavaScript malware? I am looking  for JavaScript malware. I need it just for local tests on my computer for a project I am working on. Are there any Internet resources where I could find this?

If you are looking for malware to study and understand how it works metasploit is great. The framework is open source so you can study how it works.

You can search the metasploit database.

I'm not sure what exactly you're looking for when you say "JavaScript Malware" but if you mean JavaScript that could compromise users who view a site CVE-2012-3993 looks pretty cool.

If your looking for JavaScript that if injected to a site could do nasty things OWASP is a good resource.

I also quite like Troy Hunt's Intentionally Vulnerable Site it gives you a good playground where you can break things and he has some good training on what not to do.


Microsoft account security alert - Is this legit? I've just received two emails in a row stating that "We detected something unusual about a recent sign-in for the Microsoft account" and "someone else might have accessed the Microsoft account..." (see image attached). Seems a little "phishy" to me considering it's a gmail account. Last time I checked gmail was owned by Google not Microsoft. But what's weird is when clicking on the recover account button it appears to lead to the real Microsoft website. Can someone please confirm if this is a scam?

I admit that it looks phishy but this, however, is not a scam : https://answers.microsoft.com/en-us/outlook_com/forum/osecurity-oinfosafe/is-this-adress-a-valid-ms-one-or-a-fraud/de185bc8-e2aa-47ba-a526-28d80ad577b1

The fact that you used a GMail address to sign up for a Microsoft service is not abnormal at all (you can also have a Google account and use an @hotmail.com or @outlook.com address for that). It's just the e-mail address where they can contact you on (as they did now)

I would highly recommend

resetting your password asap
setting up an Authenticator app for multi-factor authentication


Why standards organizations give so short protection times for 128 bit encryption? According to this and this, seems even 128 bit encryption should remain secure for a much longer time than what security organizations say.

I saw the standards with this: http://www.keylength.com/en/compare/

For example NIST apparently says 128 bit encryption is considered secure up to around 2030. (it is written '> 2030' - what does it mean exactly?)

Are such near dates because of the possibility of quantum computers becoming real at that time?

By ">2030", NIST is actually stating that 128-bit symmetric encryption should be safe until at least the year 2030. If the current version of any given piece of software that relies on 128-bit cryptography is still around in 17 years, bravo.

As Dan said, it's NIST's job to be pessimistic about these things, because everyone listens to them, and because cryptography, in the cold light of day, has a pretty bad track record; if we had, by now, developed the ideal symmetric encryption primitive (as in, we can mathematically prove there are no attacks more efficient than brute force) that used a finite key length (OTP is provably uncrackable because it uses an infinite key length), we would still be using it.

As it is, almost every cryptographic system that has ever been devised through human history has since been cracked, and while the ones currently in use today (an elite minority of all ciphers ever invented) are believed secure, it's only because the best attacks known against them right now are only better than brute force when applied against a reduced-complexity version of the algorithm (fewer "rounds" of the cipher).


SQL Injection if table structure/db structure not known could an attacker who'd just found out that you're using mysql make an SQL Injection attack with only this information? If you don't know Any table/db name how come you can find it out? Is that even possible and how to avoid that?
Thanks

In addition to what Philipp said, keep in mind that SQL injection attacks are quite often done without knowing the structure of the DB, but once a vulnerability is exposed, it can be used to determine the structure.

For example, one of the first SQL injection string that was once taught used to be ';shutdown--

This makes an assumption that the data user provided was being put in quotes in a SQL query, so the first quote in the string closes it, and the following semi-colon ends the statement, which may result in an error. However, the following statement would still be executed, which would be shutdown. -- indicates that the rest are comments. So, this string could shutdown a server immediately if the input was not sanitized.

Taking the same one step forward in many DB systems, such as SQL server, the list of system tables is well-known and if the account which was executing the query had privileges, it could be used to list users, tables, stored procs, views, and other SQL configuration. Once that is listed, they can dropped, exported, and the structure of tables or views could be listed too.

Similarly, queries can be constructed to bypass authentication, for example by a string such as ' or '1'='1' --

A string such as the above would be inserted in a WHERE clause and no matter what user name or password was provided, this would result in a true evaluation, allowing user to authenticate without providing any credentials. e.g.:

SELECT * FROM USERS WHERE UserName = '' or '1'='1' --

In short, once a SQL injection attack is successful, the attacker has the ability to run code on your server which should be considered the same as if they were sitting on the server itself in terms of threat modelling.

To avoid the attacks, most frameworks and DB systems provide mechanism for parameterized queries. Although you should check for your platform, parameterized queries is usually the most secure way. If you must construct SQL queries yourself (e.g. to pass to some external API that requires it), then consider encoding it properly although I would try to avoid it.


Can my ISP/MSP read my Whatsapp messages? I wonder whether the Whatsapp messages are sufficiently encrypted so that the ISP/MSP ( mobile service provider) cannot read what is inside?

I will be travelling to some of the most oppressive regimes in the world, and I fear that my Whatsapp chats might be monitored because the messages will be passing through local ISPs or MSPs.

Short answer: NO, if you are sure you are using end to end encryption, and MOST LIKELY NO, if you aren't using end to end encryption.

Whatsapp uses encryption two ways: first it has an "outer layer" built by TLS, which has ben analyzed thoroughly by the security company Praetorian in February 2014, with almost all issues pointed out being fixed within a day. The page only says that Whatsapp promised to include certificate pinning, but I assume they did in the meantime. If there is no certificate pinning, then ISPs/Governments with control over certificate authorities can indeed mount a successful MITM attack (and we know that china did this).

The second, inner layer, is more secure, when active. It uses the encryption used by Textsecure, and, if you have verified the keys of the the parties you communicate (e.g. by meeting them in person and comparing hashes), is quite secure (using modern standards, etc, but without a professional review), once you know its activated. The activation part is the problem: you never actually know.

Also, according to this answer, textsecure wasn't encrypted over 3G in the past.


Can I trust a ubuntu repo mirror in a less 'free' country? For example, if I install Ubuntu in Dubai or in Saudi Arabia, I'll probably get a local mirror. Is there a way I can make sure that the ubuntu packages I get when I do apt-get update are the 'real' ones?

Take a look at man apt-secure, apt has done signature checks on release files for well over a decade. The release file contains a hash of all files in the package, and the release file gets signed by a trusted key that is included in the original installation media.

It looks like md5 is still widely used here, which is concerning but not necessarily a deal-breaker (collision attacks on md5 have been around for a long time, but preimage attacks aren't yet possible). It's not difficult to imagine a non-malicious file being included in a package that has the same md5 hash as a malicious file, in which case the malicious version could be distributed instead, but a collision attack like this would require the package maintainer's cooperation, so while not impossible it seems less likely (and you're trusting the package maintainer quite a bit already anyway).


Can Fiddler decrypt HTTPS traffic when using elliptic curves + client cert authetication? Case 1 involves TLS + client certificate authentication with both client and server using secp384 based EC certificates. In this case, when monitoring traffic via fiddler, the tunneling/handshaking as well as encrypted traffic is completely missing from fiddler (as if nothing is happening). We know there is real traffic by monitoring both client and server individually.

Case 2 involves the same client process, same server process, same server certificate but client certificate authentication is disabled. In this case all the traffic as well as the initial handshake is captured within Fiddler.

Is this a known limitation of Fiddler? If yes, how else can I capture the TLS handshake that happens in Case 1? If not, am I missing a setting inside Fiddler? I have aC:\Users\<username>\My Documents\Fiddler2\ClientCertificate.cer setup too ...

Fiddler captures HTTPS traffic by generating on-the-fly a fake certificate for the intended server, thereby running a complete Man-in-the-Middle attack. This requires that the client is configured to accept the Fiddler-controlled CA as a trusted CA, as described in the documentation.

This kind of interception breaks client certificates. When there is a client certificate in SSL/TLS, the client technically signs (during the handshake) what amounts to a hash of all received and sent handshake messages so far; the signature computed by the client will then cover (among other things) the server's certificate as seen from the client, i.e. the fake one generated by Fiddler, not the genuine server's certificate. Therefore, the client signature will not match the handshake messages that the server saw.

If the documentation is to be believed, then Fiddler can fix that, but this requires Fiddler to recompute the client signature. This works only if Fiddler has access to the client's private key. The ".cer" file is not sufficient; the private key is needed. The documentation is a bit unclear; my guess is that Fiddler uses the ".cer" file to know what client certificate to use, then will look for that certificate and private key within the local user's certificate store (which would be why Fiddler's documentation says that you should first import the certificate "as a .pfx file", i.e. with its corresponding private key, and then just export the ".cer" file). In any case, without access to the client private key, Fiddler will not be able to masquerade as the true client when talking to the server.

Now Fiddler could also have a limitation with regards to EC certificates; that I don't know. From what I explain above, Fiddler must run as a TLS client when talking to the genuine server, so if there is a client EC certificate, then Fiddler's code must support it, meaning that Fiddler must be able to generate an ECDSA signature.

From the documentation we see that the private key remains within the entrails of the client machine (a Windows system). Thus, any signature generation will need to go through the cryptographic API offered by Windows. Windows has two completely distinct API: CryptoAPI and CNG. CryptoAPI is the old one; CNG was introduced with Windows Vista and 2008. From the point of view of an application (e.g. Fiddler), a private key stored and managed with CNG can be used only with specific function calls; an application that knows only CryptoAPI cannot use a CNG-stored private key.

Unfortunately, CryptoAPI has no support for elliptic curve. An EC-based key can be used only through CNG. Moreover, Fiddler is said to be written in .NET, and .NET's cryptographic API relies on CryptoAPI only (you can use CNG but you have to do it with explicit invocations of the native DLL ncrypt.dll and bcrypt.dll). Therefore, I find it quite plausible that Fiddler uses only CryptoAPI and, thus, may support only RSA and DSA keys for client certificates, not EC keys.


I want to buy a used docking station for my laptop. Has there ever been a case of a docking station being a security concern? I found a used docking station for my Dell laptop. The price is very interesting and the docking station seems to be in perfect shape. But I'm somehow worried about potential security risks. After all, you could install some kind of keylogger in the station's firmware. Am I being paranoid here or is it possible in any way?

As always: do a risk analysis.
What is the likelihood that that a docking station contains a keylogger? According to @multithr3at3d: it is almost zero. There are easier ways of distributing keyloggers than selling docking stations.
You might look at the vendor. Is it a reputable vendor (good shop, good rep on ebay, things like that) or is it a shady man dressed in a raincoat in a dark alley? I exaggerate a bit here, but you'll get the picture.
If you're really paranoid, you can log the traffic that goes to the outside world (the logged keystrokes must be collected, otherwise they are useless). Netflow should be sufficient and you should be able to identify all the sites that you communicate with.
But if you're that paranoid, you shouldn't even look at second hand stuff.


Can a secure cookie be set from an insecure HTTP connection? If so, why is it allowed? With reference to some security paper I read, I found out that a cookie with the secure flag set can only be sent by the client over connections that are using HTTPS, not HTTP, but the cookie itself can be set from the server with a secure flag from an insecure HTTP connection. Why is it allowed?

Secure cookies can be set over insecure channels (e.g. HTTP) as per section 4.1.2.5 of RFC 6265. It explicitly mentions that the Secure flag only provides confidentiality and not integrity, as a Secure flagged cookie can still be set from an insecure channel, overwriting any previously set value (via a secure channel or otherwise):

The Secure attribute limits the scope of the cookie to "secure"
channels (where "secure" is defined by the user agent).  When a
cookie has the Secure attribute, the user agent will include the
cookie in an HTTP request only if the request is transmitted over a
secure channel (typically HTTP over Transport Layer Security (TLS)
[RFC2818]).

Although seemingly useful for protecting cookies from active network
attackers, the Secure attribute protects only the cookie's
confidentiality.  An active network attacker can overwrite Secure
cookies from an insecure channel, disrupting their integrity (see
Section 8.6 for more details).

Section 8.6 gives several examples, but I won't copy-paste them here due to how long the section is.
As for why, there's no clear use-case that I'm aware of. I suspect that the RFC was written from the perspective of having only the goal of protecting confidentiality, and therefore preventing Secure flagged cookies from being accepted when set over HTTP was an unnecessary restriction for that goal. My guess would be that the rationale was "if we provide this functionality, people may assume that cookie integrity is protected by the Secure flag, and we don't want people to make that assumption".
That said, the fact that the data can be set over an insecure channel does somewhat negate the concept of only sending the cookie value over a secure channel, so the decision's sensibility is arguable. The RFC does at least mention that you lose both confidentiality and integrity if you do this.


Would a public DNS help secure downloads over an unsecure connection? I am downloading large files with their checksums/hashes on a Linux machine with the DNS manually setup to use a publicly available trusted DNS, e.g., Google's 8.8.8.8 since I am aware that DNS can be spoofed to possibly host a compromised version of the files as well as the corresponding checksums/hashes.
If I were to download the software over a connection I suspect may be compromised, e.g., infected router or cell basestation operated by a malicious third-party, would verifying the files using the checksums/hashes be enough to ensure that the files I downloaded were not compromised in any way?
Are there any ways an attacker could compromise the download in this setup?
Naturally, I will be downloading over HTTPS, but does that make a difference here?

This is a very broad question about the security of downloaded files.
So, where do you download from? In the simplest form, you download a file from a URL. The hostname will be translated to an IP address. There are a number of measures to make sure that you connect to the right host:

use Google DNS (weak, but less easy to fake than a local DNS)
use DNSSEC
use hard IP addresses instead of hostnames
etc.

HTTPS does two things:

it authenticates the connection
it encrypts the connection

So yes, using https helps.
Whether checksum or hashes help depends a lot on what you use. A simple MD5 hash is sufficient to determine whether a file transfer has been correctly, but offers little resistance to a malicious attacker. If you need to be absolutely sure, use SHA-2 and have the file signed.
Another way would be to use an encrypted VPN, either directly to the file provider or to a trusted location from where a less dodgy Internet connection is available.
If it is publicly available (f.e. Linux packages), you may consider downloading them from multiple sources and comparing the results.
And the final recommendation is, if your Internet connection is not to be trusted, don't use it for such critical files; invest some time and money in a more trustworthy connection.


What if user can't answer the security question during password reset? I'm thinking out my password recovery logic for an ecommerce system. Some backround: Passwords are stored using bcrypt, password recovery involves the standard reset link, which then can be used to reset the password within a limited amount of time.

I would like to add an additional step before allowing customers to reset, such as a security question. My question is what is best practice, using today's security standards, for situations where the customer can't answer the security question?

Does the system prompt them for some other secure info tied to their last order, such last 4 digits of their credit card? (If yes, what if the customer hasn't placed an order yet?)

In my situation, I would need the entire process to be able to be done online (vs by phone - although, I would be curious to know what the benefits are using phone). We don't want customers not being able to place orders if they can't get through to customer service.

Security questions are usually stupid and useless. They rely on information that is usually easily obtained through a quick Internet search of the target's social media accounts and is not a good way of proving identity.

  Does the system prompt them for some other secure info tied to their last order, such last 4 digits of their credit card? (If yes, what if the customer hasn't placed an order yet?)

The last 4 digits of a credit card is not secure information either. See a recent, well-known case of social engineering that exploits precisely this.

Personally, I'd just fire of a password reset email to the listed email account and be done with it. Any other steps will generally serve to annoy your customers more than protect against any real threat.


What does it mean when a webpage says refresh is disabled? https://www.grc.com/x/ne.dll?rh1dkyd2:

  To safeguard your privacy we have disabled the browser's "reload" or "refresh" facility while you are in sensitive areas of our web site. Reloading pages will function normally once you have left this area . . . but until then please refrain from "reloading" pages.

I'm not understand what that page is trying to say? It says refresh is disabled but I do a Ctrl+R and the browser refreshed..

Well, Mr. Gibson is a bit of a tool when it comes to security. The appropriate term is charlatan.

His secure pages cause the pages to be cached locally, so when you hit refresh it doesn't make a web request, but just pulls the html from local storage.

He didn't "disable" refreshing, he modified the default behaviour of a page request. You can still refresh the page, and you can make the request again.

It really doesn't do much for security because the sensitive stuff is now sitting in your cache for a really long time. It isn't any more secure than making the request again.


What are the Consequences of OpenPGP Key Collisions? In this answer to GPG keys & SHA-1, there's the sentence:

  However, since PGP keys are usually generated by their users, collision attacks are not a problem. They might conceivably be a problem in contexts where someone's key is generated by a third party, which might occur in some corporate environments or other large organizations.

I don't quite understand what this means. Is there a chance that you can generate a PGP key-pair that is the same as another existing key? Let's say that I don't have a particular target, I just want to assume someone else's identity as a laugh. What features of PGP key generation allow for this or prevent it?

You have to distinguish between different kinds of attacks which are in scope of the hash sum algorithm chosen.

The post you referenced on one hand discusses collision attacks (against the whole SHA-1 based fingerprint).

  However, since PGP keys are usually generated by their users, collision attacks are not a problem. They might conceivably be a problem in contexts where someone's key is generated by a third party, which might occur in some corporate environments or other large organizations.

A collision attack means finding two (or more) keys with the same fingerprint. As long as you create your key own your own, this is not an issue -- all you could do is create two keys with the same fingerprint, but they all belong to you anyway. If somebody else creates the key for you (for example, your company), they might be able to perform a collision attack and hand over one key with a given fingerprint while keeping another key with the same fingerprint -- but they might keep the private keys anyway, so there's no need to perform such sophisticated attacks.

A collision attack is simpler/faster to perform as a preimage attack, as you've got more control over the input and can find arbitrary two keys with matching fingerprint instead of having to find a collision for a given, fixed key.

  Preimage attacks on SHA-1 could be a problem, if one only relies on the fingerprint. I can imagine various scenarios where an attacker could fool someone into accepting their key in place of another key. Alice downloads a key from somewhere and calls Bob to verify the fingerprint. An attacker organizes a keysigning party and substitutes their key for someone else's. Such attacks would be difficult, but feasible.

The result is that an attacker would have another key with the same fingerprint. Such a preimage attack would probably fool a bunch (if not most) of OpenPGP implementations in considering the wrong key.

A very relevant, but different attack is a collision attack on short key IDs. Short key IDs are 32 bit subsets of the fingerprint, and have a much too small value range. Those are actually a kind of preimage attacks, as they allow to collide key IDs against existing keys. The solution is not to use short key IDs at all.


SMTP injection, how it is done and what can it cause? There are a few things that I dont understand about the injection.

The injection is something along this line

> .
MAIL FROM:  mail1@gmail.com
RCPT TO: mail@gmail.com
DATA
EMAIL data
.

Here are two ways to inject in an inline fashion:

  %0aDATA%0afoo%0a%2e%0aMAIL+FROM:+%0aRCPT+TO:+%0aDATA%0aFrom:+%0aTo:+%0aS
  ubject:+test%0afoo%0a%2e%0a

or

  %0d%0aDATA%0d%0afoo%0d%0a%2e%0d%0aMAIL+FROM:+%0
  d%0aRCPT+TO:+%0d%0aDATA%0d%0aFrom:+%
  0d%0aTo:+%0d%0aSubject:+test%0d%0 afoo%0d%0a%2e%0d%0a

Why do I use the DATA keyword, what does it do?

Suppose the injection succeeds! what can an attacker do with it, apart from spam?

First and foremost,  in the example above your injection is URL encoded and the SMTP traffic is in plain ASCII. This is confusing,  its assumed that a web application would decode the URL encoded payload prior to the injection point, also this quesiton has nothing to do with web applications.

So what about the DATA command?  I can understand that RFCs can be intimidating to new comers. On the Wikipedia page for the SMTP protocol it says that the DATA command is used to specify the body of the email.

In the context of SMTP command injection a new DATA segment allows an attacker to specify a new SMTP body to terminate the previous SMTP email.  SMTP command injection is always in the header of the email, and header may contain values such as a subject/from/to that is undesirable to the attacker.  Therefore the previous email is terminated with a null body or a body of foo in the above injection, and a fresh email is injected.

Before working with any injection,  work with the language or protocol natively.  In the case SMTP use telnet to interact with an SMTP server on localhost.


Is server-side cryptography with user-only access possible for email services? I came across the Lavabit High Scalability Writeup and got curious.

Do you use any particularly cool technologies or algorithms?
The way we encrypt messages before storing them is relatively unique.
We only know of one commercial service, and one commercial product
that will secure user data using asymmetric encryption before writing
it to disk. Basically we generate public and private keys for the user
and then encrypt the private key using a derivative of the plain text
password. We then encrypt user messages using their public key before
writing them to disk.

As far as I know Lavabit also offered a webmail client. Is server-side cryptography possible where only the user can decrypt the messages but a webmail access is offered at the same time? Lavabit claimed it could not retrieve the password if it would be lost, which means it also could not be reseted, can it?
This would mean the user's credentials need to be stored in the database in order to authenticate him/her. This very same password is used to generate the derivative which is then again used to decrypt the private key which then again can be used to decrypt the public key encrypted emails.
Does that not mean, that Lavabit is/was in possession of the passwords? To my mind, this would only make sense if two passwords are required. A password to authenticate the user and a passphrase to unlock the private key. Where the passphrase, as opposed to the password, is not stored in the database, but entered every time by the user without persisting it somewhere.
Similar I found in the MyKolab.com FAQ's:

Some other providers claim to use server side cryptography to store my
data encrypted so they cannot access it. Do you do that as well?
We currently do not have any plans to do that. The reason is simple.
With server-side encryption, the provider holds the encrypted data,
the key, and the passphrase, as all three need to pass through the web
interface and be available on the server. So the provider does have
access to all the data despite the encryption.
We don't believe in misleading our users in this way.
The only solution would be client side encryption of everything, but
that's very hard to implement and there is a whole set of standards
missing on the browser side to do this properly and securely, also
keeping in mind that sand boxing in browsers does not work from a
security perspective. Therefore, we suggest to use native clients such
as Kontact and use GnuPG for end-to-end encryption.

So what did Lavabit mean when they said retrieving the messages would not have been possible? How can this work in a secure way, respectively only as MyKolab.com has stated it?

The "Lavabit High Scalability Writeup", that you link to, includes this passage, which is enlightening:

  Because we need the plain text password to decrypt a user’s private key, we don’t support secure password authentication. We decided to support SSL instead (which encrypts everything; not just the password).

So here is what they do:

When the user registers, he chooses a password and sends it to the server.
An asymmetric key pair (apparently ECDH) is generated on the server.
The server stores the ECDH public key, and also the private key, but the private key is symmetrically encrypted with a key derived from the user's password. The user's password itself is not stored.
When an email is received (through SMTP), they encrypt it with the user's ECDH public key (with hybrid encryption, possibly ECIES or a variant thereof). They can do that because they have the public key.
When a user connects, through POP, IMAP or the Webmail, simple authentication is used: the user shows his password. The server then uses the password to decrypt the stored ECDH private key; if the private key is obtained and matches the stored public key, then the user is deemed authenticated.
As long as the user is connected, the ECDH private key is kept in the server RAM, and the server uses it to decrypt the user's emails for him.

So the server never stores on its disk the user's password or the user's ECDH private key in clear form. However, they obtain both at some point, but they keep these things in RAM, safe from leaks through stolen backup tapes or SQL injection attacks.

"Secure password authentication" is a kind of challenge-response system where the client does not show the password, but computes a response to a challenge, the response using both the challenge value (sent by the server) and the password. This kind of protocol is a partial protection against password disclosure when the server's identity is not guaranteed (from the client's point of view) or the connection between client and server could be eavesdropped. Since Lavabit uses the user's password both for authentication and for server-side decryption of the ECDH private key, they cannot support "secure password authentication". However, "secure password authentication" implies plaintext storage of the password on the server, so it is not really secure; a more thorough and safer solution is to wrap the whole dialog into SSL, which is what Lavabit does.

If Lavabit wants to purloin the user's emails, well, they can, since they have the user's private key in RAM at several points (when generating, and every time the user connects). However, they must have the plaintext emails too, because that's how the SMTP protocol works: the server necessarily has access to the plaintext emails when received and when sent. In that sense, use of server-side cryptography in Lavabit does not weaken the model.

If you want email protected from the servers (all involved servers), then you must have client-side cryptography with software which is not dynamically obtained from the server, because otherwise the server could still feed you malicious software. So, install something like GnuPG. This, of course, will not work well with the Webmail (the Webmail will let you read... encrypted emails) unless you also install a nifty browser plugin like FireGPG, except that this plugin is discontinued and unsupported.

Without client-side cryptography, I would say that what Lavabit does is fine and is about the best that could be done. (I don't comment on the implementation, which I have not reviewed in any way; I am describing the conceptual design.)


Brute force without DOS'ing the server How to conduct brute force tests for directory traversal or other operations that require trial and error without accidentally turning it into DOS attack?
It comes to how much bandwidth a site is capable of (and other things like memory) and it's different as to every site.
How to measure this bandwidth?
How to determine, or calculate and set the right speed of test?

If you write your own tool, than you can do it with with growing mechanism of requesting.
For example:

Start with 100 threads -> All is ok
Add 50 threads -> 50* errors in 10%
Add 50 threads -> 50* errors in 40%
Remove 70 threads and set 130 for current server. Periodically you can retest this phase.

Manually you can do it with wfuzz, patator or ffuf empirically brute number of threads.


I want to hire someone on Upwork to install a bitcoin trading bot on a cloud server. What vulnerabilities should I watch out for? Context
I tried installing Tribeca (a bitcoin trading bot) myself yesterday, but messed it up somehow, as I'm not very familiar with Docker/Git/NPM/mongoDB technologies (a little knowledge is dangerous &c, &c).
I'd like to pay someone on Upwork to install it to a cloud server for me (I'm thinking Digital Ocean), but I was worried about the possibility of the freelancer being able to access my details/funds after the install and handover were completed.

Question
Is there any way to verify that the install of Tribeca is safe to use without my funds getting stolen and that the freelancer is unable to access it?
Here's what I thought of so far:

To verify that the code is the same, getting the checksum of the installed code and the checksum of the Github repository, and comparing them. I'm not sure if this would work if changes occurred to the files during installation
Entering my exchange API keys myself, after I'm satisfied that the freelancer doesn't have access/backdoors built in (this one is obvious).

Is it even possible to verify that the install isn't malicious, or am I going about this all wrong?

I'm a long-time Sec.SE lurker, but this is the first time I've posted a question. Please comment on how I can improve the question so it's more answerable - thanks :)

If you give them unattended access for any amount of time, you can't.

What you can do is for example to give them access to your desktop using some remote desktop software, then connect to the cloud server from your PC.
If you watch them all the time, you can be sure there is no backdoor, if you understand everything they do.

Most likely you won't understand everything they do, else you'd just do it yourself. But at least you would notice maybe suspicious actions.

Many screen sharing tools also allow to record the screen. This way you could show the recording to someone else to check that no backdoor was installed.

The important point is that you never allow them to access the server on their own and watch everything they do.


Security by design - clarification I work as a contractor in the IS Security field. I was hired by my current client to design and enforce a methodology to make sure security risks are assessed and addressed in all IT projects. Besides this assignment, my client asked me yesterday what my knowledge of the Security by Design (SbD) concept was, if I thought it was applied in his organization and how my mission contributed to this. I honestly replied that while I had a basic understanding of what SbD is, I didn't feel comfortable giving him a definitive answer on the spot and that I would look into it.

Which I did. But it seems pretty hard to find a concrete definition of SbD. My impression is that it is - in practice, I know there is an actual and important concept behind these words - mainly used as a fashionable marketing argument people put in their presentations to please management. But are there concrete criteria to assess if a project / organization applies the SbD concept? Or is it just the idea of taking security problems into account in every aspect of the work, and letting one decide how to enforce this?

It is a little bit of a grey area, as everyone interprets it a little differently, but consistent aspects of Secure by Design include:

an architecture which has security built in by default
a code design and review process which has sufficient checks
developers/designers/architects trained in security
automated checking
continuous monitoring through development (esp DevOps)
4-eyes checking

Etc.

It puts the emphasis on getting security built in early, instead of counting on remediation after the fact.

This has some obvious benefits, including a dramatically lowered lifecycle cost.

To clarify as per jpmc26's comment, building a secure architecture means designing it to have layers of protection, to avoid obvious holes (and also to avoid having accidental holes appear), to default-secure or default-closed when things fail, to understand the security requirements before starting to build so they don't need to be added on afterwards...etc.


How to Remotely Retrieve Password Hash from Computer Just for fun, I wanted to see if I could remotely extract the password hash of my own user account on my own Mac.

Assume that the device is running either the latest version of macOS Sierra (10.12.6) or High Sierra (10.13.3). Also, assume that the computer has remote management and SSH enabled. The only catch is that SSH is set to not allow any user to authenticate.

Knowing this, is there any way that I could remotely grab the password hash of my local account to attempt to crack it on another PC?

There are a number of ways to remotely access a system outside of SSH. Hint: look at the sharing tab in your sys pref. Don't forget about VNC and 3rd party tools (LogMeIn, etc.).

Also, if you are considering network layer attacks, you can use network spoofing attacks for Directory-based auth protocols. See Responder as an example (mainly for Windows netNTLM hashes via NBT-NS and LLMNR, but OSX can support these as well if in a Windows Enterprise environment).

  Supports NTLMv1, NTLMv2 hashes with Extended Security NTLMSSP by
  default. Successfully tested from Windows 95 to Server 2012 RC, Samba
  and Mac OSX Lion. Clear text password is supported for NT4, and LM
  hashing downgrade when the --lm option is set. This functionality is
  enabled by default when the tool is launched.


Programming languages for security? I am a computer science student interested in the field of security and just had a few questions.

What are the pros and cons for using C# for security purposes, I had assumed applications programmed in C# would be more prone to hacking etc. than C++ due to it being a higher level language and therefore being less "powerful" however I have read up online that C++ and C are not usually recommended for security reasons as buffer overflows cause a lot of security problems.

What are the "best" and "worst" programming languages to learn for security and why?
Does it just come down to preference?

Apologies for the vague questions, I am still a beginner, please correct me if I have made any mistakes.

Thanks in advance!

Lower level languages like C and C++ may be referred to as "unsafe" languages because it places a lot of responsibility on the programmer to get things right. For example, when you access and array element arr[i] the C compiler assumes that the programmer knows what he is doing and that i is a valid index for array arr.

Higher level languages such as C# and Java treat the programmer like an idiot and do runtime checks to make sure that arr points to a valid memory location, that i is a valid index for this array, etc. These runtime checks add overhead but in consumer applications where efficiency is not as paramount as keeping development cost low.

If you are interested in security then I would suggest that you study C and C++ since you will come face to face with issues like buffer overflows, heap corruptions, use after frees etc.

Higher level languages like Java are designed for people who don't know or care about security and does all it can to hide these problems from both the user and the programmer, which will not help you learn about these problems, it will just teach you to ignore them.

Many applications are written in high level languages but low level languages will always be relevant because someone needs to build the platforms that run the higher level stuff. Nearly all Java runtime environments are written in C++ and nearly all operating systems are written in C. Scripting languages such as Python Ruby and Perl are written in C. Ruby might be a safe language to program in but there could always be a bug in the underlying virtual machine.


Effective NMAP scan technique I need to scan large network which has 5000 IPs. I have limited time duration. I have done initial maths and concluded that, in a group of 4 individual has to perform 70 IP nmap scan.

Consider that I want more out of nmap. Which method will be effective for me?

Initially I thought of running top 1000 ports scan and then to perform all 65535 port scan in the range where I got some results after performing initial 1000 ports scan. Assume that rest all hosts are dead in which I have not got the result. Also I want to check those even roughly.

What would you recommend? Which scan type and methodology shall I follow to achieve my target?

NMap scan can take a long time, try a small number of ports over a large IP range first.

Select a few of the most important ports to you and try those first.

Have you considered MassScan https://github.com/robertdavidgraham/masscan instead of NMap.


Is it possible to get XSS without event handlers inside  Payload? I am pentesting a super strange website and was trying to get Stored XSS on their main website. After some hours of testing i found that it is possible to inject sucesfully without any encoding:

Cool right? the thing is i have tried +50 event handlers (some of them not even working for images) and 80% of them were blocked by the waf and the rest that were accepted (code 200 instead of 500) but were stripped from the response, even invalid ones. So

 Turns into -->

So i was wondering, is there any possible way to exploit this without event handlers?

i know that  isn't allowed for most browsers and will not trigger anything (correct me if I'm wrong here).

Did you try other payloads for XSS?

Here's the cheat-sheet: https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

You can check the Event, Compatibility, tag as well as code there.

If 80% percent were blocked by WAF, you need to bypass it, some bug bounty hunters already bypass some WAF and here's the link:

https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/xss.md

For the browser, just test in all browsers.


How to manually disable the no contact card? New payment cards in my country are now delivered with the no-contact option that allows pay without putting the card in a machine. The fact is that these cards aren't secured because you can read them easily with a phone or a tablet and retrieve information about the bank account.

Is there a way to manually disable this no-contact thing? I'm either looking for a physical solution (like scratching a part of the card or removing the chip that makes that ) or a software solution that blocks this functionality.

You will seriously decrease your security by disabling the radio or chip in your credit card.

Chip and PIN is the most secure form of payment available today, followed closely by Chip and Signature; contactless payment is almost as secure; mag stripes are completely not secure, and hand-keyed account numbers (such as on a web page) are the least secure of all.

It may help to understand the different protocols in use.  The data provided by the chip, either through electrical contacts or via the Near Field Communications (NFC) radio, follows a different payment protocol (called EMV) than the data provided by the magnetic stripe.

First, be aware that all cards, including chip, mag stripe, and contactless cards transmit data in the clear*.  The data includes card number (also called the Primary Account Number, or PAN), expiration date, and some kind of verification value.  The bank uses the PAN to look up the account, checks the expiration date, then validates the appropriate verification value.  If they match, the bank goes on to approval processing.  If they don't match, the bank declines the transaction.

Believe it or not, the account number isn't the problem.  The problem is when all of this data is copied together, including the verification value.

There are two different Cardholder Verification Values on a mag-stripe credit card.  There is the Cardholder Verification Value (CVV), which is embedded in the mag stripe's data, and the CVV2, which is the 3 or 4 digit number printed on the back of the card, and is for use in "Card Not Present" transactions (such as paying online.)

When a card is mag-stripe read, the entire track of data from the mag stripe is sent to the bank.  The bank looks at the track data and will require the CVV from the track to match their records exactly.  If a card is hand-keyed (as on a web site), the bank requires the CVV2 from the back of the card to match.  Stealing the mag stripe does not get the thief the CVV2 so he can't buy online; stealing the CVV2 from a web site does not enable a thief to recreate a mag stripe and create a counterfeit card.

However, the basic problem with the mag stripe is that all the data is static.  Because the track data can't be changed, the CVV is static. Because a credit card is printed, the CVV2 never changes either.  That means if the card data is read just once by a thief, it can be copied and replayed again and again, resulting in fraud.

That's where the contactless cards are different.  Because they have an on-board chip with a CPU and memory, they generate a single-use transaction-specific verification value.  With each subsequent transaction, they generate a different verification value.  The bank uses cryptography to validate the verification value was correctly generated on each transaction; this confirms that it was their chip that was present, and not just a copy of the number.  This means that copying all of the authorization data, including the PAN, expiration date, and verification value, does not give the thief enough information to replay the information and commit fraud with the data.  Similar protocols protect Chip-and-PIN and Chip-and-Signature transactions.

Instead of clipping the NFC antenna, you are much more secure if you use only the contactless radio for payment.  However, since many shops don't take contactless payments yet, you still need to use your mag stripe at those locations, where your data is still vulnerable and subject to skimming.  And when you use your card online and type in your CVV2, it's also potentially vulnerable to theft.

If you want to increase your security, let the merchants where you shop know that you're unhappy that they don't take contactless forms of payment, or if they don't yet take chip cards.  The more they hear from their customers, the more likely they are to upgrade their equipment to a more secure device.

If you're extremely paranoid, you can certainly buy a cheap RF-blocking envelope to keep your card in your wallet from being skimmed by the guy next to you on the bus; but even if he does read it, the data he reads can't be used to create a working clone of your card.   (At most, a very sophisticated attacker could have an accomplice paying for a diamond ring at the exact time the guy on the bus reads your card, channeling stolen payment data through him as a proxy.  And that's why you should tell your bank you would rather have Chip and PIN than Chip and Signature.)

EDIT For clarity, here’s how I rank the various payment schemes in terms of security, from best to worst:

Chip and PIN
Chip and Signature
Mobile payment systems(Apple, Samsung)
NFC (contactless with dynamic authentication data)

...

Mag stripe
Web entry with two-factor authentication
Web entry

* Some contactless technologies, such as Apple Pay, use a substitute number in place of the PAN.  While this sounds more secure than the cleartext account number found on chip cards, this means your banking information is always present inside Apple's systems, where you have to trust they won't be hacked, and that your iPhone and iWatch won't be hacked.


What is the security risk of the Macbook Pro Touchbar? The new MacBook Pro has a touch bar that has been banned for students taking the bar exam.

What is the issue that would cause this response?

Data leakage
Cheat sheets
Add in apps could alter the integrity of the software

There are a number of sensitive utilities that might need to have similar safeguards, such as password managers, Keychain access, or any other data store that needs to guard from spying.

The main point seems to be the possibility of cheating. Looking a bit further at the links provided the page you've linked you get North Carolina requires test takers disable MacBook Pro Touch Bar for bar exam [u]:

  The board didn't explain its policy, but it's presumably concerned about cheating. The Touch Bar is designed to replace physical function keys with context-sensitive touch commands —a programmer could, however, conceivably write software that would display test answers.

And similar from a vendor of exam software about Disabling the Touch Bar on MacBook Pro:

  Exam Administrators will want to ensure that the newest feature included with some MacBook Pro's is disabled before a student begins their exam. By default, the Touch Bar will show predictive text depending on what the student is typing, compromising exam integrity.

Since the specific exam software is currently unable to lock down this feature during exam the feature must be either disabled manually or the system is not allowed for exam because of possible cheating.


How can files be deleted in a HIPAA-compliant way? Any material I've come up with for data destruction standards relate to completely wiping (ATA Secure Erase) and physically destroying hard drives, but I haven't been able to find much about standards for destroying individual files. Are there such standards, and if so how can they be properly followed?

1) With modern filesystems, there is no more concept of securely deleting an individual file. It might have been copied around, snapshotted, written to a different location upon editing, etc.

2) With modern drives, there is no deletion / wipe without confirming it. Some drives have had a Secure Wipe command flat-out lies to you, returning immediately while doing nothing.

See SSD (Flash Memory) security when data is encrypted in place
Use Full Disk Encryption.
Pretty much forget about the concept of securely deleting a file and knowing it is really gone. Even with a freespace wipe, you've still got cache files, preloads, snapshots, slack space (though some utilities wipe that)...


Apache2 SSLCipherSuite - why use anything other than high? I am currently participating a lecture in my university that is called "system architecture and security". One part of this semester is to setup our own slice and hack each others. We also have to make a webservice that uses HTTPS (and lots more).

Now my question is when I configure the apache2 I want to set a high standard in the SSL encryption (SSLCipherSuite). But I cant find anything really concrete about the differences and why anyone would ever do anything else than HIGH. Dosent that just tell the browser that it have to communicate using strong encryption methods? Does it make the communication slower?

Could someone explain this to me? Or link to an article that explains it well? I haven't been able to find it...

The HIGH list is part of OpenSSL's classification. It may vary depending on the version of OpenSSL and other stacks might not have the same classification (or any high/medium/low classification at all).

In some cases, you may want "higher" than HIGH. For example, the HIGH list for OpenSSL 1.0.1 includes some non-DHE cipher suites. If Perfect-Forward Secrecy is important to you, you could be a bit more restrictive and use only a subset of these cipher suites (with DHE).

In other cases, you might just have to interact with stacks that don't support any of the HIGH cipher suites, unfortunately... It's not great, but it's a risk assessment exercise to evaluate whether you can cut off those clients or not, depending on your business or service purpose.

In addition, if certain issues appear and a different choice of cipher suite is required (e.g. the BEAST incident), you may want to set the cipher suites list explicitly. Adapting the cipher suite configuration require often less work than deploying a new version of OpenSSL on an existing system. You would certainly have to upgrade the library itself if there was a flaw in its implementation, but it often causes more problems than it's worth if you just want a new HIGH list configuration out of that upgrade, especially if for an issue that can be fixed (or at least mitigated, this depends on your own risk assessment) by changing the cipher suites list.


Determining the entropy of a string if each character has a slight bias Let's say I need to generate a 32-character secret comprised of ASCII characters from the set '0'..'9'.  Here's one way of doing it:

VALID_CHARS = '0123456789'

generate_secret_string() {
    random = get_crypto_random_bytes(32)
    secret = ''
    for (i = 0; i < 32; i++) {
        secret += VALID_CHARS[random[i] % 10]
    }
    return secret
}

My concern is that my character selection is biased.  Because 10 doesn't divide evenly into 256, the first 6 VALID_CHARS are slightly more likely to occur.

The secret space is 1032, but my generated secrets have less entropy than that.  How can I calculate precisely how much entropy I actually have?

Update: Clarifications

For this question, I just want to know how to compute the entropy of this technique.  I'm trying to compare it against other techniques for which I know how to compute the entropy.
The parameter I chose here (10 valid chars) is just an example.  I'd like to be able to evaluate the entropy for other character ranges as well.

My concern is that my character selection is biased. Because 10 doesn't divide evenly into 256, the first 6 VALID_CHARS are slightly more likely to occur.
The secret space is 10^32, but my generated secrets have less entropy than that. How can I calculate precisely how much entropy I actually have?

Because not every digit is equally likely you can not set
p(i) = 1/10

for all the digits.
Rather, you have
p(0) = p(1) = ... = p(5) = 26/256

and
p(6)=...=p(9) = 25/256

So, use the usual formula for entropy:
e = -Sum[ p(i) log(p(i)) ] = -6*(26/256)*(log2(26/256))-4*(25/256)*(log2(25/256)) = 3.32166...

to get the numerical value of "entropy" e for one digit (n.b., if p(i) were 1/10 for each digit then this would be e=log(10), but it is not)
Then the entropy for the full string of 32 characters is:
32*e = 106.293...


Are there any IoT Systematic Creation Security Checklists? Are you aware of any publicly available documents that would help IoT/Connected product creators develop a systematic/programmatic approach and/or process to securing such new age devices?

A note about the wording of the question. You've asked about IoT but this is more of a concept than a "thing". IoT might cover many subjects from industrial controls to smart cities with home automation in between.

However, the following may be of help.

The Cloud Security Alliance's "Future Proofing The Connected World" report
NIST's "Network of Things" report
The EU's emerging IoT policy
Robert Silvers, the Assistant Secretary for Cyber Policy at the U.S. Department of Homeland Security has some useful things to say.
A presentation from an ENISA workshop at least highlights some of the EU thinking that is happening
The UK Government have a competition running for research
There is an IoT Security Foundation which has some white papers at least
You might also check out the Common Criteria "Evaluated Assurance Levels". There is an overview with respect to embedded devices here.
Some recommendations on Securing Industrial Embedded Devices may be useful.

The approaches should, of course, mirror any other security driven approach. Though we have some added twists for IoT:

Embedded devices may not have sufficient power to maintain standard security protocols as they can't always cope with the encryption overheads.
Embedded devices may be difficult to upgrade making it hard or sometimes impossible to fix security issues discovered after deployment.

One area where I'm trying to make a difference is to try and get standard contracts changed to require vendors to ensure that devices can be upgraded after deployment to keep them current and to fix security issues. So we shouldn't assume that issues and fixes always have to be technical.

Just a note about this answer. Because of the question, the answer is inevitably a set of links to other information - normally frowned upon in Stack. It is likely that these links will drift over time which is why I've tried to give the titles where possible so they can be searched for.


Public Key Cryptography : Key length While symm. crypt. has around 256 bits of a key, why does public key crypt have a key that is much longer (1000's) ???

Asymmetric cryptography tries to provide some advanced features, namely the asymmetry, the property which allows the public key to be made public, without revealing the private key. This takes structure. We need mathematics. A key for signatures or asymmetric encryption cannot just be a bunch of bits; it must be a mathematical object with very special characteristics.

That mathematical structure can be leveraged for attacks, which forces us to use a lot bigger values. For instance, with RSA, the public key contains a big integer (the "modulus"): this is a composite integer, but factoring it into its prime factors allows for breaking the algorithm. We know some rather efficient factoring algorithm; the General Number Field Sieve will thus defeat a 1024-bit RSA key (a key whose modulus is an integer between 21023 and 21024) with an estimated cost around 277. If we want to achieve the same level of robustness with a symmetric key (which is just a sequence of bits, nothing made public) then we just need 78 bits.

The generic attack known as "luck", in which you try all possible bit sequences until the right one is found, has average cost 2n-1 for a n-bit key. For symmetric cryptography (with a good algorithm), we know no better attack, and any key of 100 bits or more will be safe for decades. With asymmetric cryptography, we have the public key and its structure to work with, allowing for much more efficient (but heavier in mathematics) attacks, which forces us to use much bigger objects (larger keys).


Should I store my users' certificates and private keys or not? Situation

I am doing an internship in a company and I am currently working on a web application that has the following features:

This is a private application, users can only be added by an administrator of the application
Users can add PDF files online
Those files are stored in the application server

My mission as an intern is the following:

I have to implement a feature that allows clients to sign the PDF files using this mechanism.
It has to be simple to use : one button "Sign" next to the file and the server signs it automatically using the user certificate. The basic idea is that each client would be granted a certificate when his account is created (the Certificate Authority would be trusted by the application). At some point I will have to get the private key of the user in plaintexte to sign the file on the server (I am thinking about using phpseclib library to read certificates).

Question

Should I store the users' certificates and/or private keys on the server? * Isn't there a better way to store users private keys, such as a trusted web application that has REST API or some easy way to access it?
Edit : My situation has evolved and now my question is more like the following:

Is it safe to store .pfx or p12 files on the server? I know they contain private keys but is the file as itself really secured (let's say there is one client password for each file).

Note : I am still a student and not an expert in security, please tell me if you need further information to answer.

Well, from security perspective, clients should sign PDF files on their devices. The value of the signature after PDF is uploaded is very low, because there is no guarantee that PDF wasn't tampered during transmit. In your scenario, you can't be sure that sent and signed PDFs are the same, because PDF's integrity is not guaranteed during transmit.

In other words, the procedure should be as follows: client acquires/generates PDF document -> sign -> upload to server -> register. In this scenario you can be sure that you have exact PDF created by client (if signature is valid).

The fact that server holds client certificates and their private keys makes things worse. You can impersonate legitimate client, craft signatures legitimate client never did. If the attacker hacks your server -- keys from all users are automatically compromised. Private keys should be stored at client devices, otherwise they have no control over the key, thus no liability for signatures. The outcome -- signature's zero value and failed project.


Is it secure to store a cryptographic key in a class member variable? Consider an application that runs locally on a Windows PC. The application uses a local folder for reading/storing encrypted data (i.e. images). A user logs in (authenticated from a local encrypted DB). The application needs to perform secure read/write operations to local storage based on user-UI interaction. These operations are using symmetric cryptography (AES).

Is it safe to store information such as password or a cryptographic key in memory (i.e. a private class member) for the whole session?
If not, what is the alternative way (I assume not to interrupt the user asking for password every time a crypto operation needs to take place).

It depends on your threat model. Will a potential attacker have access to the machine?  Might they be able to escalate their authority enough to either dump the process space of the application, or to attach to it as a debugger? Or if you’re concerned about the attacker downloading the entire database and being able to decrypt all the images, consider moving the decryption process or image storage to a separate machine with better security. Or you could encrypt each image with a unique key, and keep each key in a remote database, and use the user’s database to store their master decryption key.

If your concern is that a rogue or compromised client will download each decrypted image in an attempt to acquire the entire database, consider a monitoring process that alerts you to excess activity. Also, consider slowing down each key or image request (this process is known as “trust anchor dragging”) making it harder for anyone to download the entire database in a reasonable amount of time.

Rather than use a private member to store the key, use your platform’s provided cryptographic service library. On Windows, use the CryptoAPI. In Java, use the Cryptographic Service Provider. These tools are designed for secure storage of keys.

If you can’t use the cryptographic library, the key might be persisted in swap space, and end up on your hard disk. If you have the option in your language (C/C++, go, ASM) consider allocating memory using your operating system’s secure memory function, such as mlock() or VirtualAlloc().


Can TPM be used in the same way as TrustZone area? Can I program the TPM chip to execute a piece of code securely just like executing code in the TrustZone area? In particular, the application will be running in the normal world, but parts of it should be run in a secure world, so can I use TPM for this purpose?

No. A TPM offers a fixed set of functionality which does not include arbitrary code execution. The functionality set centers around using keys in the TPM for a fixed set of features, mainly authentication (proving that a value was signed on this particular computer), device-bound storage (encrypting data in such a way that it can only be decrypted on this particular computer) and platform attestation (proving that the computer memory is in a known state). The only way to extend a TPM's functionality set would be to flash a new firmware, and this ability is restricted to the manufacturer and there may only be room for a few patch points anyway.

In contrast, TrustZone is merely an isolation feature. It does not impose any constraint on what (or how much) code runs in the secure world. If the operating system of the secure world allows it, you can install applications that preform arbitrary computation with the device-bound keys. Of course, if you aren't the chip manufacturer, you often won't have the necessary keys to install code in the secure world.

Sufficiently recent Intel chips offer somewhat similar functionality (but with a very different architecture) through TXT. TXT uses the TPM to authenticate the code that runs in a TXT partition and store the partition's data securely, but the application runs on the main CPU, not on the TPM.


Does HTTPS Everywhere defend me against sslsniff-like attacks? http://www.thoughtcrime.org/software/sslsniff/

If I have a domain on my HTTPS Everywhere list, so that theoretically it could be only visited via an HTTPS connection in my Firefox, then could an sslsniff attack be successful against me? Could the attacker get information because the sslsniff degraded the connection from HTTPS to HTTP? Or I am "fully safe" from these kind of attacks when using HTTPS Everywhere?

UPDATE: and what happens if I have the domain whitelisted in HTTPS Everywhere? [xml files could be created]. So the domain would be only available via HTTPS.

The short answer is:  No,  not always.  I have studied this topic in depth and please read this entire post before forming a conclusion.

SSLSniff is a proof of concept exploitation platform to leverage flaws in the PKI,  such as vulnerabilities in OCSP or the (ingenious) null-prefix certificate attack.  If you are using a fully patched system,  and you understand what an SSL error means then you are immune to MOST (but not all) of these attacks without the need for HTTPS Everywhere. If you are not patched against the null-prefix certificate attack then the certificate will appear valid and HTTPS everywhere will be useless.   If you don't understand what an SSL error means, then HTTPS Everywhere is useless against SSLSniff.

What I think is more concerning than SSLSniff is SSLStrip,  which is also written by Moxie Marlinspike and introduced in his talk New Tricks For Defeating SSL In Practice.  This tool won't cause ssl errors.  This is exploiting, HTTP/HTTPS the application layer.   If you load a page over HTTP,  it will rewrite the page removing HTTPS links. It will go a step further and change the favicon.ico file to a picture of a lock,  to fool novice users.  Simple enough,  but absolutely devastating consequences.   In response to this attack Google introduced the Strict Transport Layer Security (STS),  which is a lot like HTTPS Everywhere but built into the browser.  It should also be noted that HTTPS Everywhere is really good an defending against the SSLStrip attack. In fact this is the EFF's solution to attacks like SSL strip as well as careless OWASP a9 - Insufficient Transport Layer Protection violations.

So when does HTTPS Everywhere AND STS fail?  How about https://stackoverflow.com.  If you notice,  they are using a self signed certificate.  Jeff Atwood himself doesn't care about this issue.  Because this website is using a self signed certificate,  HTTP Everywhere will forcibly use HTTPS,  but the attacker can still use SSLSniff to deliver their own self signed certificate and therefore HTTPS Everywhere would fail to protect someone from hijacking your StackOverflow account.

Okay, so at this point you probably are saying to yourself.  "Well that's why we have a PKI!".  Well, except the PKI isn't perfect.  One of the creators of HTTPS said "The PKI was more of a last minute handwave" (See: SSL And The Future Of Authenticity).  In this talk Moxie asked a great question, is a PKI really the best solution?  I mean we are having problems with CAs like DigiNotor being hacked.  When a CA is hacked,  then the attacker can create a valid certificate,  and then HTTPS Everywhere is totally useless,  an attacker can still use SSLSniff because he has a "valid" certificate.  The EFF's SSL observatory demonstrates what a tangled mess the PKI system is.  I mean really,  what is stopping China from creating a certificate for gmail.com?   Well the EFF is proposing the Sovereign Keys Project and I think it's a great idea.  Besides the fact that Sovereign keys don't exist as of yet, there is another problem,  Sovereign keys don't help self-signed certificates like the one being used by https://stackoverflow.com!   However Moxie thought of this situation and came up with a solution that he calls Convergence.  Convergence is relying upon the masses for trust.  The host will be contracted from multiple connections around the planet,  if any one of them sees a different self-signed certificate,  then you know a MITM attack is taking place.  Having a warning that something is wrong is a lot better than nothing.

In summation,  there are fundamental problems HTTPS Everywhere.  When there is a vulnerability in software used to validate certificates.  When the user doesn't understand the repercussions of an SSL failure.  When a self-signed certificate is used. Then finally, when our compromised PKI is used against you.  This is a serious problem and intelligent people working on fixing it, this includes the EFF and the author of SSLStrip, Moxie Marlinspike.


What are prudent security precautions to take for business travel by people with access to sensitive info? The New York Times had a front-page article today: Traveling Light in a Time of Digital Thievery, aka "Electronic Security a Worry in an Age of Digital Espionage".

Former director of US national intelligence Mike McConnell is quoted as saying

  “In looking at computer systems of consequence — in government,
  Congress, at the Department of Defense, aerospace, companies with
  valuable trade secrets — we’ve not examined one yet that has not been
  infected by an advanced persistent threat.”

It notes that many high-profile organizations require their employees to take extensive precautions when traveling to China, Russia and other countries that have been implicated in advanced attacks.  That includes, e.g.:

traveling with "loaner devices" which are wiped pre- and post- travel, rather than their own cell phones or laptops
disabling Bluetooth and Wi-Fi
never typing a password
and, in meetings, not just powering off devices, but removing batteries "for fear the microphone could be turned on remotely"

It seems that using encryption might be problematic:

  Both China and Russia prohibit travelers from entering the country with  encrypted devices unless they have government permission.

and also notes that

  When officials from those countries visit the United States, they take extra precautions to prevent the hacking of their portable devices, according to security experts.

Do these precautions make sense for people with access to info they consider highly sensitive?  (Even  the bit about removing batteries?)  What else might people do?

Which countries have this sort of capability?

Of course I know that good answers require more careful analysis of the traveler's security requirements, plans while traveling, etc. etc.  But a list of  precautions to consider would still be helpful.

As far as travel precautions, the EFF has these recommendations for travelling to the US:

Carry as little data as possible over the border.
Keep a backup of your data elsewhere.
Encrypt the data on your device.
Store the information you need somewhere else, then download it when you reach your destination.
Protect the data on your devices with passwords.

This is because of the often-discussed US Customs policy giving themselves permission and responsibility to examine all incoming devices (and data on these devices), including computers, cell phones, etc. But it's not unreasonable to assume that most other high-profile countries will follow similar procedures. Canada, for example, has a documented history of searching incoming devices specifically for pornography.

But the threat isn't limited to governments examining data on your devices. There have been a number of cases of Customs officials placing monitoring/tracking software on transiting computers, such as this example by the German government: German Governments admit spyware was theirs

Again, it is reasonable to assume that the practice is more widespread than has so far been discovered.

And with that background, we move to cell phones. Recall this case where a judge published a statement that the FBI's established practice of remotely turning on cell phone microphones to monitor conversations was indeed legal. One important paragraph from the article:

  Kaplan's opinion said that the eavesdropping technique "functioned whether the phone was powered on or off." Some handsets can't be fully powered down without removing the battery.

Therefore, if you don't want eavesdropping then remove the batteries from all nearby cell phones. This applies not only to phones that have transited a customs border, but also any phones that have operated within a potentially snoopy country (which includes pretty much all of them) as remote monitoring software can potentially be installed covertly over the cell network.

Finally, don't forget the value of Truecrypt hidden volumes. The plausible-deniability is helpful when dealing with governments. It works even better with media that you would expect to be FAT formatted, such as flash media. In fact, it wouldn't be a bad idea to put your REAL operating system on the hidden partition of your camera's memory card (put a few dozen boring pictures on the visible portion of the card for good measure). Then on the computer's real hard drive, just put a fresh OS install that you never use anyway.


Security in unofficial telegram apps(that use Telegram API) I was wondering that can developers of an unofficial Telegram apps gain access to media and files that users send over the app? (Unofficial Telegrams use the Telegram API and connect to Telegram servers).

Developers of any application can get hold of the data that passes through the application if they can find a way to transfer the information without you objecting.

This has been demonstrated time and again on all of the mobile platforms app stores with apps transferring data out.

With Telegram, as with any secure comms app, the security is really only in-transit (point-a to point-b). Once data is inside the app, the app can by definition do stuff with it, in general the data cannot remain encrypted within the app.

Cautious or paranoid users will monitor applications for unexpected network activity that might indicate data leaving their machine without permission. This is particularly hard to do on a mobile device due to the app limitations normally applied.


How likely it is that a (MySQL) client leaks credentials when VPN tunnel was not set previously? Context

I work on a very common case. I configured two servers: an OpenVPN and a MySQL (172.16.X.X) server hidden behind it.
Let’s assume everything is perfectly configured and patched server side.

Note:

MySQL server has no public network interface
MySQL has no TLS configured. It does not use PAM authentication via PAM plugin. It accepts authentications from anywhere.
It uses a NAT to access the internet (NAT is done by OpenVPN server).
OpenVPN pushes its routes (172.16.X.X) allowing connected clients to find the MySQL server.

On the client side (192.168.X.X), I have several users who will connect to MySQL server through the VPN, using their own local OpenVPN client. With the previous assumption, unless I’m a fool (which is a possibility, you tell me), no MITM attacker would be able to get the MySQL password.

Note:

Clients have no pre-configured route for the distant VPN network (172.16.X.X).

Probable scenario

Let’s imagine: as a user, I try to connect this MySQL “hidden” server and it fails, because ooops… my openVPN software failed to start the tunnel without notice.

Now a malicious machine can be somewhere in the local network - people uses laptops anywhere these days - sniffing my miserable attempt to connect to a non-existing MySQL (172.16.X.X) server.

Questions

Will any MySQL client software send cleartext credentials to the default route, even if no MySQL server is found?

Is it possible for an attacker who knows the genuine MySQL server (172.16.X.X) exists to impersonate it by setting up a rogue MySQL server on the local network (192.168.X.X)?

If yes, how can I mitigate this scenario (hint: with a few resources, I work for a very small company)?

Thank you for your help!

To answer this question you must first understand the mysql-na handshake through to authentication.

If you are using default username & password authentication where the password is stored as sha1(sha1(password) hash in mysql.users then authentication works as follows (there's more steps but to keep this brief it's roughly the following):

Client connects to server
Server sends greeting, version and the supported capabilities of the server as well as a SALT to be used for the session
Client requests authentication to begin, then sends SHA1(password) XOR(SALT + sha1(sha1(passsword)))

So first off credentials are not sent in the clear using this method, they are however if you use mysql_pam plugin as these are passed to PAM for authentication completion.

However using mysql-na you must be aware that and if an adversary can sniff a successful client-server auth handshake, then they can use the mysql-unsha vulnerability (https://github.com/cyrus-and/mysql-unsha1) to gain access without knowing the actual password.

With this clarified let's address you questions specifically

Will any MySQL client software send cleartext credentials to the default route?

This depends entirely on your mysql configuration if you are using PAM to authenticate then it is likely you will see credentials "on the wire", to be 100% on this it's worth running a packet capture on the server and inspecting the resulting pcap with wireshark / tshark.

If the network exists in my routing table?

As per above, depends on your MySQL configuration by default you should not see credentials in cleartext but this does not prevent attackers gaining access via mysql-unsha.

If the IP I try to reach exists locally?

Please clarify are you speaking about your VPN client machine LAN ? this depends on your routes and whether the VPN allows split-tunneling.

If the IP I try to reach exists locally and runs a MySQL server?

Again this needs to be clarified it's far too vague.

If yes, how can I mitigate this scenario (hint: with a few resources, I work for a very small company)?

Your questions need to be made clear, first and foremost so that you can communicate them out to third parties clearly and consistently, the take aways here for you are.

Under default configuration MySQL will use Mysql-NA for authentication which is username + password, this is not in the clear as only hashes are exchanges HOWEVER this is vulnerable to the mysql-unsha attack as outlined above which could allow an attacker to authenticate as a user which they have observed authenticating without knowing the original password only the sha1(password) hash.