Any flaws in this security model for a REST web service? I have designed a REST web service which requires authentication. It handles authentication in a manner similar to Amazon Web Services, namely: the user has an ACCESS_KEY (say, 'abcd') and a SECRET_KEY (say, 'aabbcc'). The SECRET_KEY is used to create a TOKEN: a SHA-1 using the request information, for example:

GET path HTTP/1.1
Date: Mon, 23 May 2005 22:38:34 GMT
ACCESS_KEY: abcd
TOKEN: SHA1(SECRET_KEY + ACCESS_KEY + Date + path)

I can check the TOKEN in the server and authenticate the request. Up to this point, I don't think there is anything wrong with the security model.

My only question, is how to provide the SECRET_KEY when using the service from a web page. I thought I could send it as a JavaScript variable (the connection is HTTPS) and simply use that variable in a JavaScript function that adds the appropriate header to every HTTPRequest. The initial authentication can be done using standard cookie-based approaches (for instance, relying on Django to handle a session).

So, the architecture looks like:

Web site session: handled by Django using standard session-based security (example.com)
The web site session receives via HTTPS the SECRET_KEY as a JavaScript global variable, which is used to add the appropriate headers to every HTTPRequest.
The HTTPRequests are made to api.example.com, which is oblivious to the Django session: it only cares about having the appropriate headers.

I believe this approach is secure, while maintaining a completely stateless REST API. I don't use standard HTTP authentication (basic or digest) because I don't want to hack the "you cannot logout" problem, and I want to keep the API strictly REST.

Do you have any comments regarding this approach? If it is flawed, how would you accomplish my goals?

Thank you!

I dont see any flaws, but I do think you're overdoing it. It seems to me - I might be missing something - that you use a token because you think you should, not because there is a legitimate reason.

The best approach would be to first identify your (security) requirements and then look for the solutions.

One of the things you should think about with stateless API's is replay attacks. THe way you describe it, your protocol sounds like vulnerable to a replay attack. Moreover, it can be abused for CSRF since there is no randomness in each request. I'm not sure if this is something the REST API can fix, because it is an inherent webapp problem, but it's worth thinking about it.

Bottom line, nobody can assess if you're security is alright if you dont have security requirements (and a threat landscape).


Saving username and password inside SQL I am currently managing a network of around 100 PCs.
Many users have different mails/usernames and passwords for different services like login to PC, mail, local applications...

When an application or service enables auto-remember usually the users forget their login credentials.
Instead of requesting a password reset every time I was thinking to store the data inside a local SQL database. I would use an encryption algorithm on the data before storing.

Would this be safe enough or should I use another approach to storing user information ?

This is a risky idea. If someone manages to get access to your database and somehow cracks the encryption, they have access to the data of all users. Add to that that users often re-use passwords, and our hypothetical cracker has a treasure trove of valuable information.

Resetting passwords may be a bit of work, but it is the safer way of doing things.

Another thing you can do, is encourage your users to use a Password Manager program.


Why is the use of TAB (%09) characters in the middle a 'javascript:' URL valid? Some context: I was assinged on a pentest and found an application that let me place my own links in an a tag's href attribute. As expected, all strange values like javascript: were correctly filtered by an XSS filter, however I discovered that you could bypass this filter by injecting a TAB character in the middle of the protocol specification like such:

Now what I would like to know is, why do browsers accept this as a valid javscript URL which will happily execute code whereas other characters like SPACE character are not allowed? Is there a historic reason for them allowing this strange format?

Note: Tested on Chrome, for those that like to test it, it also works with window.location like so:
window.location.href = 'javascr\x09ipt:alert(1)'

When an  element is clicked, the link is followed and its URL is
resolved. This causes the string to be processed by the basic URL
parser.
In your example, the parameter is processed in the path state during
which TAB (U+0009) characters, along with carriage return and line
feed characters, are ignored, and therefore do not form part of the
resolved URL.Why does anchor tag remove tab character in URL specified inside href attribute?

As per the specification of Basic URL Parser, the ASCII tab or newline will be removed from the URL (or just ignored).


How to simulate DDoS attacks from the Internet? The idea behind security tests is easy. You want to know what a hacker can do - you hire a security expert who acts like a hacker to see how far he can get. You want to know what an evil admin can do - your security experts gets admin privileges and does his job that way.

I am aware that there are other and maybe better ways to perform an audit, but these are common approaches that work. Unfortunately it gets difficult when the threat is not a single person or a team of hackers, but a distributed bot-network that spams you with more or less intelligent requests. How can you test such a scenario? Lets say I have my infrastructure ready and I am confident that my systems can withstand a certain amount of pressure from a DDoS attack. Now I want to verify my expectations and perform a DDoS test from the Internet.

Where can I legally get a DDoS simulator? I do not want to buy resources from an illegal bot-net and I only want to work with experts in this field. Are there companies who perform such tests for you or can you at least rent systems that are powerful enough to simulate a DDoS attack? I am aware of the legal issues like informing all involved parties like providers and the like - this question is focused on how such a test can be performed. I am also not looking for a list of companies that can do that, I am interested what is state of the art in this field and which services are available on the market.

I think you seek the use of a packet generator and a corresponding number of systems generating packets to match the load you seek. Use random valid IP addresses for the packet source addresses and you should find yourself quite annoyed when it comes time to filter.

You can do all of that without ever sending a bit across your ISP's link. If you get DDOS'd in such a way that bandwidth is maxed out rather than services, then your ISP will need to choke off the traffic prior to it reaching your link.


Automatic exploit searches How to automatically search and download exploits which matches for example with kernel release ?

Is there for example a public REST web service which provide data in XML or JSON format to a client program ?

Thanks in advance !

EDIT :

Solution 1 : @Lucas_Kauffman

Parse HTML search results of db-exploit or mitre.com using beautifulsoup (python lib). But we will have a problem in case where they decide to change their HTML template.

Solution 2 :  @schroede

Parse CSV archive of db-exploit using csv python lib. Here a simple script to do this.

You can have a look at http://www.exploit-db.com and http://www.cvedetails.com/. They don't have any REST service, but they do offer free searching.


PHP would this be risky (using hackable data for includes) mysql_select_db($db.'_'.$table);
include("/home/site/includes/".$type."/functions.php");

Would this be a bad idea if $table and $type are values passed via ajax from a JS script?

And this..

$function($args);

If the value for $function is passed via ajax?

Very risky.

The first could be used to perform operations on the wrong database, possibly bypassing access restrictions (I don't think it could access the MySQL internal database because of the underscore, but I could be wrong).  The second could be manipulated to access any "functions.php" file in the filesystem, and if you also permit file uploads, this could allow unrestricted code injection.  I don't know enough about PHP to know the full range of code injection permitted by the third example, but it looks highly dangerous (eg. passing a function of "system").

Edit:
The correct way to deal with user input is to develop a whitelist that describes "known safe" input.  In the case of $function, that means a list of acceptable function names; for mysql_select_db, a list of values for $table that the user is permitted to access.  If you see an invalid value for user input, reject the entire transaction with a suitably vague error message.  Anything else is just inviting problems from attackers who are cleverer than you.


When authenticating ciphertexts, what should be HMACed? Some have argued for using AES-256-CTR with HMAC-SHA-256 for authenticated encryption over AEAD-specific modes like EAX and GCM.

However, when doing, this, what should be HMAC'd? And how? Specifically:

Should a key different from the encryption key be used to sign the ciphertexts?
If so, should there be a unique signing key for each unique encryption key?
If so, is it acceptable for the two keys to be stored alongside one other (e.g., as a longer "virtual" key?
Should only the ciphertext (and optional associated data) be HMAC'd?
Should the nonce be part of the HMAC?
Should the encryption key be part of the HMAC (assuming separate encryption and signing keys)?
How should the ciphertext, associated data, and potentially other components of the HMAC be composed with one another? Append? XOR? Nested HMACs?

The MAC is there to detect alteration of the data you are interested in, i.e. the result of the decryption. So you have the following choice:

either you compute HMAC over the plaintext data (i.e. before encryption when encrypting, after decryption when decrypting);
or you compute the HMAC over the encrypted data itself (i.e. after encryption when encrypting, before decryption when decrypting).

In the second case, you have to include in the HMAC input everything that impacts the decryption process, i.e. not only the encryption result per se, but also the IV which was used for that encryption, and, if the overall protocol supports algorithm agility, you should also input the specification of the encryption algorithm (otherwise, an attacker could alter the header of your message to replace the tag which says "AES-256" with the tag which says "AES-128" and you would unknowingly decrypt with the wrong algorithm).

For security, the second choice (encrypt then MAC) is better; see this question on crypto.SE for details (to sum up, when the MAC is computed over the encrypted data, it cannot leak information about the plaintext data, and since it is verified before attempting decryption, it protects against chosen ciphertext attacks). SSL uses MAC-then-encrypt and it has been the source of a lot of issues (all the "padding oracle attacks" and also the so-called BEAST attack would have been avoided with encrypt-then-MAC).

As for the keys, ideally, the encryption key and the MAC key should be derived from a master key with a PRF. In plain words: hash your master key K with SHA-512; the first half of the result will be the encryption key, the second half will be the key for HMAC.

But, really, you should use EAX or GCM. They do everything correctly and (that's an important point) they have very light requirements on IV selection: they just need a non-repeating IV, hence can use a simple counter, whereas handmade CTR needs non-overlapping IV ranges (an IV with uniform random selection is correct, but randomness is a hard requirement)(and CBC is even worse, it needs unpredictable randomness). The only justification for not using EAX or GCM in a new system (where you are not constrained with backward compatibility) is a possibly non-availability of an EAX or GCM implementation. I would argue that, even in this case, it would be better to retrofit some AES-ECB code into an EAX implementation.


USB Token Authentication Security Issues First of all, I should mention that I read this thread and it was useful in my case, but I need more comments and reviews about this authentication method.USB Token authentication which I want to talk is :

1- User logon to server with username and password

2- server requests for some USB credentials like serial number, expiration date, etc

3- User fills the requested parameters and send them to server

4- Server generates an login token and signs it with its private key

5- User downloads the token and save it in encrypted USB Flash memory.

Now every time that user wants to login to server, server asks for username, password and token. User uploads the token from his USB to the server. Server verifies the signature with its public key and if it is verified, the user can log in.

From security point I know that the USB flash memory is not as secure as PKI smart tokens. Because the token is exportable and it has no TPM standard, however I am wondering what other security issues this mechanism has?

It doesn't seem to provide much on top of username and password authentication. Your token effectively becomes a secondary password that's at best hard to remember.

The main benefits of PKI smart tokens and client-certificate authentication are that they prevent eavesdropping and phishing attacks: the private key never leaves you, so eavesdroppers or servers you authenticate to using your private key won't be able to use the credentials you've just used to authenticate anywhere.

Here, you don't get any of these benefits. Even if you protect the connection against eavesdropping (e.g. via SSL/TLS), phishing is still possible.

I can see a few additional downsides:

Your server initially acts like a pseudo-CA which issues the token instantaneously the first time. It sounds good, but you'll certainly have to deal with lost tokens, having to re-issue them in practice, so it's likely there's going to be a weakness here. (Similar problems as PKI authentication, it's only as good as the administrative side normally done by the CA.)
Your users may lose their USB tokens. Why have it stored on a USB stick in the first place, by the way? If you use client-certificate authentication, via a hardward or software token, you can generally protect the private key with a password or PIN that you'll need to enter every time you use it. That's mainly going to cause big problems to your legitimate users, while it's going to be great for potential attackers (they can just make a copy of the USB stick, no need to steal it).

If you want something similar to hardware USB smart tokens, but they're not an option, you could use software-based client-certificates stores (e.g. PKCS#12/PFX). They're not quite as good as hardware tokens because the file can effectively be copied, but at least PKCS#12 files have password protection mechanisms. (Client-certificate authentication mechanisms generally have poor UI interactions, unfortunately.)


How does malware install itself as a service without requiring user's credential? I order to understand malware, I've tried to create a toy-example myself.

However, I don't understand how the malware install itself on the computer as a service, without the credentials of the user.

Having looked at service examples on MSDN (C++), I need to give user credentials in order to create an automatic-startup service.

What techniques does malware employ? Can someone give clarification and provide me with some links?

Malware often comes piggy-bagging on installers for other software. When the user starts the installer of a piece of software they believe to be legitimate, they expect to be prompted for granting admin rights. The installer will then use these admin rights to install both the legitimate program and the malware.

This can easily happen when you obtain software from questionable or illegal sources.

A hypothetical method I never heard about in practice but which would be possible in theory could be a malware which waits for the user to download any form of installer and then modifies that installer to also permanently install the malware. This would require that the user downloads a software installer during the same session where they got infected with a malware in user-space, so I don't think this propagation method would be very effective.


Is the _acme-challenge subdomain protected? I was looking into the DNS-01 challenge of Let's Encrypt, and I had a question about the subdomain process [1].

Let's say, the website example.com gives away free subdomains; what stops me to request a Let's Encrypt wildcard certificate for *.example.com, by claiming the _acme-challenge.example.com subdomain to process the DNS-01 challenge?

Is there anything in the ACME protocol (or anything else) that stops me from doing this?

[1] = https://letsencrypt.org/docs/challenge-types/#dns-01-challenge

Typically, sites providing free/custom subdomains are providing A records, whereas the ACME DNS-01 challenge requires adding a TXT record. This would make what you suggest very unlikely.

If a site allows adding arbitrary TXT records for subdomains and doesn't reserve the _acme-challenge, then there's nothing in the protocol that would prevent abusing such a feature, and it would be a vulnerable service. However, that's a use case so uncommon that no-one would exclusively consider that when designing protocols like this.

Luckily, if this happens, Let's Encrypt certificates will expire in three months, and it's also possible to revoke the certificate even without access to its private key, just for cases like this:

  If someone issued a certificate after compromising your host or your
  DNS, you’ll want to revoke that certificate once you regain control.
  In order to revoke the certificate, Let’s Encrypt will need to ensure
  that you control the domain names in that certificate (otherwise
  people could revoke each other’s certificates without permission)! To
  validate this control, Let’s Encrypt uses the same methods it uses to
  validate control for issuance: you can put a value in a DNS TXT
  record or put a file on an HTTP server. - -

  Once you’ve validated control of all the domain names in the
  certificate you want to revoke, you can download the certificate
  from crt.sh, then proceed to revoke the certificate as if you had
  issued it:

certbot revoke --cert-path /PATH/TO/downloaded-cert.pem


UAC or logging into admin account first before installing software? When installing software on a standard user account, is it safer to use the UAC pop up to type the admin password into, or switch user to admin then do the install in that user?

They are both essentially the same, let's think of the possible scenarios.

an attacker takes over a single user
an attacker has admin or more permissions on the machine

Since Uac runs in a restricted desktop the standard user has no access to that desktop object, meaning that any keylogging, injection or screen logging activity done in this permission set should be blocked, the same as running in a different login session.
Assuming the second scenario the attacker has full access, meaning that it doesn't matter.

If we are talking about exploiting the mechanisms both have a pretty big attack surface(assuming an exploit or bypass);

uac has anything from registry or path based side loading, the desktop object not being secure and the entire consent mechanism being broken.

Logins have the registry profile, files on disk, lsass rpc calls, gpo and many other attack vectors for exploitation.

I would go with what is easier for you, just keep your admin password cycling and the account usage to a minimum and you should be safe in that regard.


Are many rounds of SHA needed for a random veracrypt key Assume that I've used white noise from the classic "zener breakdown" circuit to produce 512 bits of random data.

If I use these as the key to a Veracrypt volume, is there any benefit to running 200,000 rounds of sha-512 on them, or is one (or even zero) going to be sufficient?

My reasoning is that there is no plain text to be guessed, an attacker is trying to recover 512 random bits.  So they might as well try and brute force the output of the sha-512 rounds, because they're just as likely to get that as they are to get the contents of the key file.  Hence those rounds don't actually make the encryption any more secure.

TL;DR
You likely won't benefit much, if at all, from key stretching with SHA-512. In fact, you should not be using your own RNG at all, even if it is based on established physical phenomena. Just use urandom. The longer answer below explains how a computer gets randomness, why using your computer's own randomness is more than sufficient.
How much entropy is present?
The answer depends on how much entropy is present in those 512 bits of random data. If there is at least 128 bits of entropy, then SHA-512 would only be necessary for whitening. You absolutely should whiten it, as a reverse-biased zener diode tends not to have uniformly random output. If there is less than 128 bits of entropy and it could be brute forced otherwise, then key stretching may increase the equivalent entropy (i.e. cracking an 80 bit key with sufficient key stretching may be computationally equivalent to brute forcing a 90 bit key, despite still having only 80 bits of entropy), but the absolute shannon entropy would be unchanged. Most likely, you would be doing nothing but wasting cycles.
Is key stretching with SHA-512 worth it?
Imagine your implementation is broken and is not only biased, but partially predictable. For sake of argument, let's say that every 512 bits of data it outputs contains only 64 bits of entropy (i.e. there are only 264 different possible 512 bit outputs), the equivalent of a 9 character alphanumeric passphrase. Imagine also that an attacker can compute 240 (about 1012) candidate 512 bit outputs per second. At this rate, it would take just a few months to search half the keyspace, which is obviously very bad. Now let's say, for simplicity, that the amount of computation required to generate a single candidate output is identical to the amount required to compute a single SHA-512 digest. By putting your output through 200k hash rounds, you have increased the amount of time it takes to check a single candidate from 1000 per nanosecond, to one every 200 nanoseconds. This would result in it taking more than 50,000 years to search half the keyspace!
Sounds like a great reason to use key stretching, right? Probably not. While it does make what would take a few months instead take longer than the entirety of modern civilization, that is only assuming your generator is broken in a very specific way. Chances are, it'll either be producing well more entropy density than necessary, or so little that no amount of key stretching will help. If the key is 15 bits of entropy lower than the previous example, at 49 bits, will 200k rounds of SHA-512 help? Not at all. It would take "only" about 2 years to search half the keyspace. Would it be necessary if the key had 15 more bits of entropy, at 79 bits? Nope, because at that amount, even with no stretching at all, it would still take 10,000 years to search half the keyspace. Now for a 512 bit output, what are the chances that the output will fall squarely within a < 30 bit range where key stretching is not totally useless, and is not excessive? Quite low. It's better to ensure that your output has sufficient entropy to start out with, which brings us to...
The proper way to generate randomness
I will be assuming you are using a Linux or similar system, as it is what I am most familiar with. This argument should also apply to Windows in a slightly modified form.
I would strongly encourage you not to use such a custom source of randomness for your header key, as they are very easy to implement incorrectly, and have many nasty failure modes, despite being based on a solid theory. If you still want to use a homebrew source, you should generate significantly more than 512 bytes of randomness. Creating a megabyte of data and hashing that with SHA-512 should be sufficient, for example. Ideally, you would use the output of a properly-seeded CSPRNG, such as the /dev/urandom interface on Linux and other Unix-like/Unix-derived operating systems.
Rather than creating your homebrew mixing scheme as well, it seems like your goal is simply to be able to utilize the randomness which can be generated by physical phenomena, either because you don't trust your computer's RNG, or you simply wish to augment it. In this case, rather than using the output of the diode directly, you should add it as a randomness source. The Linux randomness driver allows you to mix in arbitrary data with the entropy pool by writing to either of the random character devices. All it takes is writing to the file itself, and that data will be safely mixed in with the pool, which will take care of all the rest (whitening, tracking entropy estimates, sanity checks, backtracing protection, etc). After doing that, you will be able to safely use VeraCrypt normally, as the entropy produced by your reverse-biased zener diode has been used to augment your kernel's internal pool.
Just use urandom.
"But the kernel's RNG isn't 'true' randomness!"
Sure it is! The Linux kernel gathers randomness from a number of unpredictable events. Some of them are deterministic or at least not entirely non-deterministic, such as packet arrival times on the NIC, but others are truly non-deterministic. The best example is the randomness gathered from interrupts. The Linux randomness driver has a function, add_interrupt_randomness(), called every time an interrupt fires, which mixes in the precise time (in jiffies and cycles since boot) as well as other information such as the IRQ number and current register contents with the entropy pool. These interrupts come from a variety of sources, such as hard drive events, but it also comes from keystrokes. This timing is a source of great, and extremely reliable, randomness.
Extracting randomness from timing
A good timing-based RNG has two components: a fast clock and a slow clock. The fast clock ticks at a very high, precise frequency, while the slow clock ticks, of course, more slowly. If the slow clock, at every tick, samples the current tick count of the fast clock, the output, once whitened, is pretty damn random. Very quickly, the clocks get out of sync. Have you ever been at a stop light, watching two regular, in-sync turn signals slowly get out of sync, until each car seems to be blinking in a discordant pattern? This is exactly how your computer gets entropy from keystrokes. The computer is the fast clock, and the keyboard powers the slow clock. While you may feel like you are typing at a fairly constant rate, that is the perception of your own, 200 ms resolution brain. In reality, to a computer, the amount of time between pressing a key and releasing it, or releasing one key and pressing another, is very long and highly variable. Millions of cycles pass in the time it takes your neurons to wake up, charge, and fire off an action potential. And when they do so, non-deterministic phenomena such as brownian motion causes there to be tremendous variability in the latency of each impulse of a neuron, and that variability directly translates into randomness in the computer.
This is absolutely enough for your purposes. Remember, the multi-billion dollar gambling industry relies on this for a huge percentage of its income. If we did not sport terribly variable, stochastic neurons, the one-armed bandit would be a great way to get rich! The reason it's so effective is because its "fast clock" is a series of spinning cylinders rotating a few times a second, and the slow and inaccurate clock is a person trying their damnedest to accurately time their muscles. If a few cycles per second is "fast" enough to extract enough non-deterministic timing behavior from a human to hold up a massive business, why couldn't a fast clock operating at millions or billions of times per second be enough? All this comes down to the final point: implementing your own RNG is unnecessary. It will either be enough, or it will be broken. The mere act of typing is sufficient to generate just as much entropy, and is far less likely to be broken. If you still want to use your reverse-biased zener diode for fun, go for it! But use it with your system's RNG, not instead of it!


I have internet at home, need to know who visited what? Possible? I have internet at home. I wanted to keep a watch on who visited what without putting a computer on for 24 hours and running some proxy software on it. Is there a possibility to get a track of all the websites visited thru my router in 24 hours?

There are many cell phones connected to it as well.

You can run a local machine as the web proxy and point all others to use that for all http traffic. Squid is one option.

Another option is to setup one machine to be the DNS server, e.g, using bind. You can then collect all the DNS logs. You can set up your router to give this local DNS machine as the primary DNS server via DHCP.

Another way (albeit the hardest) is to collect all the traffic as pcap and run tcpdump (or wireshark) to parse it. This will require a switch with port mirroring or a machine with 2+ Ethernen NICs.

If you don't care about domains, you can probably make your router (if it supports it) to export traffic logs to syslog. You can then use Splunk or any other log manger to go through the IPs and reverse DNS them or use whois to figure what is the destination.


Is it possible to modify a support .js file in a web application by injection? Let's say there is a web application needing a JavaScript support file .js to be loaded in the head of the html document.

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <script type="text/javascript" src="file.js"></script>
    <title>example</title>
  </head>
  <body>
          [...]
  </body>
</html>

Would it be possible to modify it with an injection attack, provided of course the web application is vulnerable to injections ? I can't understand how would it be possible to modify a script needed before.

Just to ensure we use the right terminology, it should be noted that when talking about web-application vulnerabilities, injection attacks usually refer to  A1-Injection as defined in the OWASP Top Ten classification.

That being said, the answer to your question is yes. Providing the web-application is prone to injection attacks, an attack scenario could be the following:

  The attacker sends a malicious input to the web server that in turn
  passes it to an interpreter (e.g. php) which includes it in a request
  and executes it. The malicious input is then executed on the web
  server, and if the JS file permissions allows it, the code executed (the payload) could
  modify the JS file with an arbitrary content. This modified JS file would then be served to every client requesting this web page.

To simplify, an injection attack can potentially gives an attacker the ability to execute arbitrary commands on the victim server, resulting in files and/or data modification.


Why don't VPN services use TLS? In corporate environment, security examiners use filters & firewalls to block VPN connections for security purpose.

VPN traffic is distinguishable and that's also the reason why openVPN doesn't work over The Great Firewall Of China. Then why not VPN channels use TLS? It'll then become impossible to predict which traffic belong to the VPN server as most of the traffic crossing filter is HTTPS to which filter has to allow.

There are a few things to undestand.

The first is that most VPN tools were originally designed to provide private connectivity over networks that were insecure, possiblly natted or firewalled but not actively hostile to VPNs.

The second is that traditional TLS is a wrapper over TCP. TCP is a poor choice for VPNs because it suffers from "head of line blocking". If one packet gets lost then all the data behind it is blocked until it is successfully retransmitted. This used to cause big problems when running VPNs over TCP, it's less of an issue now that we have TCP fast retransmission but it's still less than ideal.

The third is that deep packet inspection is a fairly new thing. Networks that will pass legitimate TLS traffic unmolested but that will not pass other traffic on port 443 are still the exception not the rule.

While Openvpn does have a TCP option it is primerally designed to run over UDP. It uses TLS for key exchange but encrypts the actual network packets using a system designed explicitly for that purpose.

https://openvpn.net/index.php/open-source/documentation/security-overview.html

  Someone should say something about DTLS (TLS over UDP) too

DTLS is a pretty new protcol. I see no reason why you couldn't/shouldn't build a VPN soloution on top of it but I guess the VPN software vendors aren't especially in the mood to redesign their software.

In any case it wouldn't help with the scenario described in the question.


MITM Attacks with Web GUI I'm thinking of writing an application that communicates sensitive information (using Python, if that's relevant). Instead of using the standard GUI libraries (like GTK, Qt or wxWidgets), I was thinking of instead making a web interface using something like web.py to run a local server and take input this way.

This would obviously only be accessible by localhost and not public.

If I'm receiving and sending very important/private data from HTML forms that get passed to this local server, is this safe, and is it any more susceptible to MITM attacks than if I were to use something that didn't involve a local server?

I'm using this application to send and recieve, as well as encrypt and decrypt GPG messages. This is something that you don't want to do using javascript. I'm hoping to do this locally using Python and displaying the messages using this local server.

So I guess my question really boils down to:

Are messages sent from a local server to the browser as easy or easier to intercept than those from a regular native GUI application and
Are messages encrypted by python and sent to the browser or messages sent from the browser to python to be encrypted any more secure than messages encrypt client-side using javascript

It is possible to use tcpdump to read localhost-to-localhost traffic, so I would also consider other programs running locally as possibly capable of intercepting the traffic you're going to encrypt.


Should my webhost show the root filesystem over FTP? I use a commercial web host, when I log in via regular FTP this is how the directories looks like:

It seems strange that I can access system files, I thought I would be limited to access files below my user folder or web root folder (which is within "customers"). Does my webhost have a security issue or is it normal?

Calling this a security issue is probably too loud. Hiding the system files is only obfuscation, and we all know that obfuscation is not one of the best security practices.

But on the other hand, the least priviledge rule is. That means a user or a account should only have allowed accesses for what is required for its job or contract. Here clearly, you would have no reasons to be able to browse the root folder.

I still would not call it a security issue, unless you are able you look at the data of other customers (because that means that than can also access yours), but is probably a hint that the administrator is not really attentive to the best security rules. As such this is a hint that other more serious security issues could exist on this webhost.

But anyway, it is only a hint, not an evidence.


How does Android L achieve strong encryption with a low entropy passphrase? After upgrading to Android L on my Nexus 5, I was pleased to find that I can enable encryption using a pattern as the passphrase.

However, it soon got me thinking. I'm guessing the encryption key is ultimately derived from the pattern which is very low entropy. I did a back-of-the-envelope calculation and I found that the total number of unique patterns on a 3x3 grid of dots come to just under a million. Even at 0.1 guesses per second, it would take a mere 115 days to search the entire keyspace.

I started reading around and discovered a write-up detailing how Android does disk encryption. It seems to claim that Android L will use hardware-backed secure storage for storing and deriving the encryption key so it can essentially allow low entropy passphrases to still have the same amount of security.

However, I don't quite understand why. Why does using a hardware-backed secure storage device suddenly allow low entropy passphrases to acheive strong security? Am I just missing something blatantly obvious?

Chip-based banking cards typically use a 4-digit PIN. It would take at most a few hours to try them all if the card didn't protect against brute force attempts. The card protects against brute force attempts by bricking itself after 3 consecutive failures. The adversary does not have access to a hash of the PIN (there are physical protections in the card that make it extremely hard to read its memory), but only to a black box that takes 4 digits as inputs and replies “yes” or “no”. The key to security here is that the adversary can only make online attempts, not offline attempts. Each attempt requires computation on the defending device, it is not just a matter of doing the math.

An Android phone or any other computer can do the same thing with its storage encryption key. The key is not derived from the passphrase (or pattern), but stored somewhere and encrypted with the passphrase. Most storage encryption systems have this indirection so that changing the passphrase doesn't require re-encrypting the whole storage, and so that the storage can be effectively wiped by wiping the few bytes that make up encrypted key (the storage encryption key is uniformly random, so unlike a key derived from a passphrase it isn't subject to brute force: the adversary needs to obtain at least the encrypted storage key to gain a foothold).

If the adversary can read the encrypted storage key, then they can make fast brute force attempts on the key on a cluster of PCs. But if the storage key is stored in tamper-resistant storage, then the adversary is unable to read it and can only submit passphrase attempts to the device, so the device can apply policies like “limit the rate of attempts to 3 per minute” or “require a second, longer passphrase after 10 failed attempts”.

The new feature in Android L is upstream support for an encrypted storage key that isn't stored on the flash memory (from which it can be dumped with a bit of soldering or with root access), but instead in some protected memory (which may be accessible to TrustZone secure mode only). Not all phones running Android L have such protected memory however, and even if it's present, there's no guarantee that it's used for the encryption. All Android L changes is providing the requisite code as part of the basic Android image, making it easier for phone vendors to integrate.

Android provides an API to check whether the application keychain storage is in protected memory). I don't know if there's a corresponding API to check the protection of the storage encryption key.


How does the EternalBlue Exploit Work? I've casually googled for explanations on how exactly the EternalBlue exploit works but, I suppose given the media storm about WannaCry, I've only been able to find resources that at best say it's an SMB exploit. I get that there was a bug in Microsoft's implementation of the SMB protocol, but what I'd like to know is exactly what kind of payload had to be crafted in order to exploit Microsoft's security flaw, and what did Microsoft do wrong that left Windows vulnerable to such an attack? Even a (reputable) link to some source code would be more than I've been able to find thus far.

There's an exploit for EternalBlue in Metasploit explained here:

  There is a buffer overflow memmove operation in Srv!SrvOs2FeaToNt. The size is calculated in Srv!SrvOs2FeaListSizeToNt, with mathematical error where a DWORD is subtracted into a WORD. The kernel pool is groomed so that overflow is well laid-out to overwrite an SMBv1 buffer. Actual RIP hijack is later completed in srvnet!SrvNetWskReceiveComplete.

I'm not an expert and don't understand ruby too well, but from what I understand DWORD is twice as long as WORD, which would let you write to memory by sending a large buffer. The kernel memory is organized (groomed) while the data is being written, so that the payload being transmitted makes sense once the RIP pointer is hijacked and pointed to the overwritten memory, which will then be read and executed.

You can see the source code here.

As far as what was done wrong, there should have been a subtraction from DWORD to DWORD or from WORD to WORD. Having the difference in sizes is what allowed memory to be overwritten.

EDIT: Checkpoint did an amazing write-up explaining all 3 bugs related to this exploit, what I understood from the ruby code I read is only bug 1/3 (bug A in Checkpoint's write-up), if you want to go a lot deeper, check it out.


How much money does it take to equip a fully funded black hat team? How much money to defend against such a team? Richard Bejtlich wrote in July 2009 the following:

  "I submit that for $1 million per year an adversary could fund a Western-salaried black hat team that could penetrate and persist in roughly any target it chose to attack."
  (from http://taosecurity.blogspot.com/2009/06/black-hat-budgeting.html)

Questions:

  Have the costs changed significantly?  Why?
  Are the costs going down or up?  Why?
  What are the costs to defend against a well-funded black hat team targeting your business? Is requesting government assistance the last line of defense against a well-funded team?

$2500 is all it takes to get a black-hat operation started

In 2009, it was reported that US banks lost more than $140M from Internet heists, as quickly as $10M in one 24-hour period.

I believe it is possible to start a criminal operation with as little as 2500 US dollars.

Cloud servers: 300 US dollars for 3 months
LAMP stack: 0 US dollars
Malware that can steal money from banks: 700 US dollars (ZeuS, although sub Meterpreter)
Web exploit delivery/management system: 800 US dollars (Fragus, although sub Drivesploit)
An affiliate system using advertising to drive traffic/eyeballs: 700 US dollars (or a nice SQLi or RFI botnet)

Total: 2500 US dollars

My proof

Brian Krebs runs articles on Security Fix focused on fraud. There are countless examples, but let me pick on this one regarding the county of Kentucky, who lost 415000 US dollars in 2009 to the exact situation I created above. This particular one involved 45 or so wire transfers in amounts just under 10000 US dollars. Considering mules were paid about 500 dollars each, and the whole operation involved 2-4 UKR scammers, you are still looking at a 391k score split 2-4 ways, with almost no investment other than the time to babysit the money mules and grease over the affiliates (oh and that initial 2500, lest I forget that!).

The skills of these scammers can also be very, very low. This isn't even college level system administration. Anyone with a summer interest in Linux could get this operation going. Yes, there is also the money mule piece, which perhaps takes a good scammer with some experience and way above average charisma -- but we assume that at least one of out every 3 criminals already has these skills.

Go back to any of those articles and reverse engineer what you think it took the criminals/scammers to get their job done.

The Cost of Defense: 6-7 percent of IT budget

You've seen the cost of PCI DSS compliance numbers no doubt; ignore those for a second. Gartner says that the security budget should be in between 6 and 7 percent of the total IT budget. UMD professors Lawrence Gordon and Martin Loeb say not to spend more than 37 percent of the asset you are trying to protect.

Staff your org with incident handlers to the number of incidents

I say that we need to hire to the incidents. If you have 1-400 incidents a year, you are going to need somewhere in between 1-400 security incident handlers. Calculate the time involved in handling the incidents and hire accordingly. I am perfectly fine with staffing taking up the entire information security budget and so should your IT finance decision-makers. People play the most important role in an information security management program.

If you haven't had any incidents, perhaps now is a good time to hire an incident response and forensics / malware research company to come in and determine if you have actually had an incident or not (let's say this is a 20k one-time assessment). While that's going on, stay on the safe side and hire at least one FTE incident response manager (100k/year) -- especially assuming you have at least 250k worth of stuff to steal, or brand damage to be done.

Monitor your apps, systems, and networks

Hand your new incident response manager an OSSIM CDROM to install in an AMI instance or whatever. Email can be sent to his or her GMail/GApps account for all I care. The point is that most companies overspend on firewalls, VPNs, and "security server hardware". I think most companies would be better served with an open firewall and access-list policy, but using the bogon filters and FATF Blacklist as null routes on every router or system with a public IP (or NAT/PAT'd to one). Give the manager at least enough budget to cover the cost of TruArx for the year if there is no other risk management portal in place already.

Give risky job roles safe tools and awareness training

Finally, equip any worker that is handling financial, banking, or payment card information (or anything else with a severe data classification) with a freaking iMac or Mac Pro and training to go with it. Make sure they have to complete some sort of SaaS-based security policy and awareness training with providers such as Cornerstone OnDemand. This may in fact be the cheapest answer to the problem, but this is the TRUST not the VERIFY. The incident manager/team provides the verification. There have been reports of targeted malware inside large-installation Mac-centric companies, although they are not hit quite as bad on the drive-by-download frontal assault. If Win7 is required, then implement a rollback-before-every-transaction VM-guest strategy.

The Cost of Application Security Defense

The real expense comes if your company or organization doesn't buy COTS, but instead rolls their own code (or outsources app development). In this situation, things can get really expensive in the long-term if the org doesn't start a very thorough appsec program before the design and coding starts. Even then, most co-ordination with application security consulting companies costs at least 1-4 million dollars over 2-3 years. If you have 10M US dollars worth of applications to protect, this should be a no-brainer -- it's going to also increase the quality of the apps and your business intelligence. It is also where the Gartner IT spending strategy tends to fall down for information security management programs, especially considering that firewalls still take up over 50 percent (and some as high as 90 percent) of Fortune/Global 2000 security budgets.


Is every hash format that nginx accepts for HTTP Basic Auth weak against brute force? According to http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html nginx can read password hashes of these types:
crypt(), apr1, SHA1 & SSHA.
This is how I understand how these hashes work and what the problem with them is:
crypt() discards everything after the 8th character, so if my password is 12345678UltraSecurePa$$w0rd I can successfully login with typing 12345678. Doesn't that defeat the purpose of a strong (lengthy) password? Brute forcing through 8 any character password seems to be trivial these days. I don't understand why crypt should be more secure than plaintext.
apr1 is MD5 but slowed down a thousand times. Which is still very weak these days. One can find reports of brute forcing through > 300.000.000.000 (300 billion) hashes per second with a couple of GPUs.
SHA1 is not very much better than MD5. It is a hashing algorithm optimized to be fast and thus is vulnerable to brute force attacks. Also, it is not salted in this case.
And the last method is salted SHA1. This seems to be the least weak method for hashing http basic auth passwords in nginx. But when someone steals the hash, he also has the salt (the salt is just base64 encoded), so SSHA still has the weakness of using fast hashing algorithms for "encrypting" passwords.
nginx can't use bcrypt, or PBKDF2.
To conclude: If I want that my HTTP basic auth hashes are "secure" (secure means that it is too time expensive to crack the hashes) I have to follow these rules:

never use crypt.
enforce passwords with at least 16 characters because this seems to be long enough against brute force attacks (let's just ignore dictionary attacks here for a moment).

And: convince the nginx guys that they should implement better hashing methods for HTTP basic auth.
Is there an error in my conclusion?

I haven't tested this myself, but reading Nginx's source code, it seems to use libc's crypt() function directly. Depending on your OS, you may have a sane crypt() implementation available, either bcrypt or glibc's SHA-256/SHA-512 scheme. It's worth a shot to see if you can use it with Nginx.


Is Intel i3 CPU affected by the Intel ME vulnerability? Hello I have an Intel® Core™ i3-2328M CPU @ 2.20GHz computer processor (I think Sandy Bridge).
https://ark.intel.com/products/70927/Intel-Core-i3-2328M-Processor-3M-Cache-2_20-GHz

I have heard about the recent problems surrounding Intel ME, the recent discoveries of the PT team:
http://blog.ptsecurity.com/2017/08/disabling-intel-me.html

But they are basically talking about the vulnerabilities of the vPro technology, specifically the AMT bug (sorry I can't link more here, search for CVE-2017-5689), where a lot of people have panicked to disable the AMT system due to the massive bug that has been discovered earlier this year. There were also concerns about the TXT (Trusted Execution Technology) detailed in other studies and researches available on the internet.

Luckily my processor doesn't have:

TXT
Boot Guard
vPro
AMT

However there were also concerns about:

Anti-Theft Technology, which can basically lock your computer, even via remote access (huge security vulnerability)
Execute Disable Bit, I am not sure what this does, but it sounds kind of invasive
Identity Protection Technology, sounds like a huge privacy invasion
Intel VT-x, which creates a subsystem that does have full privileges, but allegedly doesn't have access to the main system
and others

I would like to hear security expert's opinion about my processor, and would it make sense to disable ME in my situation if I would like to maximize the security of my computer?

EDIT:

I have checked my chipset. It's Intel® C216 Chipset and there it says that both TXT and vPRO is enabled. I am confused now. I don't know what this means.

Let's go through all of this.

  But they are basically talking about the vulnerabilities of the vPro technology, specifically the AMT bug (sorry I can't link more here, search for CVE-2017-5689), where a lot of people have panicked to disable the AMT system due to the massive bug that has been discovered earlier this year

You likely don't have AMT as this is usually only available on Xeon architecture chips, but there have been reports that it might be exploitable on some desktop architectures too. Disabling it is possible, see this thread on Intel's forums for details. If your system doesn't offer this option in the UEFI/BIOS, you'll either need a custom one (see later in this answer) or you'll need to clean your IME firmware to remove the functionality entirely (also discussed later).

  Anti-Theft Technology, which can basically lock your computer, even via remote access (huge security vulnerability)

Sort of. You need to register your device with a provider (e.g. Intel, McAffee, or your organisation's administrators) in order to make it functional. At this point the provider can then lock the BIOS remotely if you report it stolen.  The thread linked above also explains how to turn this off, but the enable/disable toggle is easily found in most UEFI/BIOS menus.

  Execute Disable Bit, I am not sure what this does, but it sounds kind of invasive

Don't be scared by things you don't understand! Be curious. Execute Disable Bit is a really important security feature - it's the hardware feature that underpins No-Execute (NX), otherwise known as Data Execution Prevention (DEP) on Windows.

  Identity Protection Technology, sounds like a huge privacy invasion

Nope. IPT is designed for use in enterprise environments where you want hardware-supported 2FA or PKI integration. It doesn't do anything unless you configure and enrol it.

  Intel VT-x, which creates a subsystem that does have full privileges, but allegedly doesn't have access to the main system

I don't know where you've read this, but it's nonsense. VT-x is hardware virtualisation support. It includes special instructions which help speed up the process of virtualising a secondary operating system (a VM) on your host system. Software such as Hyper-V, VMWare, and VirtualBox use these extensions for performance and security improvements.

Disabling IME is probably a good idea in general if you value the openness of your hardware stack. Unfortunately you can't fully disable it at the moment. There are, however, efforts to help you heavily reduce the amount of code running under ME. The me_cleaner tool allows you to strip most sections of the firmware from the management engine without triggering a signature validation failure or 30 minute shutdown timer. A new trick released fairly recently (actually only a few days before writing this) allows you to disable ME very early and strip out even more code, using an undocumented feature called HAP. The me_cleaner developers are in the process of implementing support for this. Note that both of these tricks generally require hardware modification (reprogramming the 8-pin EEPROM IC which contains the firmware) and are entirely unsupported - you may brick your hardware, although you can always restore the original firmware using an EEPROM programmer.

You can also look into coreboot and libreboot if you want to replace your UEFI/BIOS with an open source option. Unfortunately these projects are generally limited to a small number of old laptops and motherboards.


What patterns or practices exist to protect users from site admins deleting the user's information? Here's my situation: Say you run a service online that stores information that users of the service would want to keep for a long time. This information could be notes, files, etc. but it is information that the user should be able to trust will be there when they come back.

What patterns, method, techniques, etc. exist that could be put in place on the website/service to ensure that even the administrator would be unable to delete any of this data (with malicious intent, not by accident which could be fixed through backups or using rollback in a database). Something that reassures to the users that their data couldn't even be deleted by the guy running the service essentially securing the user of the service from attacks of availability from the administration.

My current thought is that since, for all intents and purposes, this administrator has root privileges to everything there is nothing that could be done to prevent the information being deleted from the service. One potential idea I had would to allow the user the option to export the data locally so that they could keep copies of their data.

I tried searching for something like this but I guess not a lot of people are thinking about this from the user's point of view.

The primary solution is exactly what you mentioned. Export or essentially a backup. If you want to retain data you must do it yourself. You might also have to have several methods of backup. Such as a cloud solution and a local solution to ensure if one is tempered with the other remains available.

Of course, if data is tampered or removed you will need a way to import your backed up data. Without the import you can't truly restore the service, only retain what it was.

Alternatively you could run your own storage/DB solution that only allows the service to connect but only be limited to insert and read entries. Most databases allow you to have access schemes that allow just this but prevent update, deletes, truncates, drops, etc. This however would require the user to run their own database. As well as them setting it up correctly. Which might not be ideal if you are looking for a regular end user friendly service. This can be complicated more so with firewalls, NATs, permissions, etc.

Otherwise if someone controls the service and controls the data there is absolutely nothing an end user can do to prevent them from editing/deleting data from it.


Dealing with an insider threat in an insecure environment I'm not a security expert by training but I know enough to deal with the occasional breach and how to set up basic practices around SSH keys, passwords, and configuration management in general. I recently had to clean up a bitcoin miner from one of our hosts. The way I discovered it was that the miner was hogging all the CPU and running strings on the binary showed upx packer and other malicious looking strings. The whole thing smelled fishy from the start in terms of how the miner got there. I have very strong suspicion it was an inside job.

Now, the security profile at this place is very lackadaisical and I'd like to lock things down without tipping off whoever installed the miner because the obvious follow up is to fire the person and I want to mitigate the inevitable damage that someone with their current level of access can do. I doubt they're competent enough to do further damage because they already played their trump card and it was dealt with so they're less likely to pull the same thing but they might get other ideas and sneak in less visible exploits onto the servers.

What is the standard protocol for dealing with such situations and what is the checklist I should go through to weed out all potential insecure access paths without tipping off the insider?

There is no IT or security team. I'm it as far as security teams are concerned. I'm not looking for political cover games. I need a list of technical things I need to do to lock things down. I'm not looking for answers about politics and chains of command.

If IT security is not your job, stop right now. Report on the official channels and move on. This is the standard procedure. Messing with the miner or doing your own investigation may create evidence against you.

Report and have IT lock down the affected machine to start an official investigation. Or you risk being accused by the attacker of installing the miner yourself and trying to frame him.

If you company is a small startup, you need permission from someone. Call the owners or the ones in charge, show them what you found and ask permission to investigate.

Shutdown the server in front of them, boot a live distro, and take a image of the disk. Hash it, and send them the hash (to prove you haven't tampered with it) along with the image size, and a list of files on the disk before you start working. Mount the image read only on your computer, and create a detailed report.

With this, you have witness backed evidence.


Possibility of SQL injection on table name that filters backticks? I am reviewing an application that has something like this:

table_name = table_name.replace('`', '')
c.execute('SELECT * FROM `' + table_name + '`')

Is this actually exploitable if the attacker controls the table_name field?
The language is python and the database is sqlite fwiw

There's a few things an attacker could do with that code that you might not want.

If their input is SQLITE_MASTER then they could retrieve metadata.
If their input is databasename.tablename, then they could retrieve data from another database.
If their input is (select load_extension(...) from tablename) they might be able to load an extension.

Or they could run any select query they wanted by wrapping it in parentheses.


SSL certificate mismatch does not show warning in browser Visiting ifttt.com shows a green padlock in my Firefox browser (version 45.7.0 ESR).

When I view the certificate, it is issued to a Common Name (CN) of ssl001.insnw.net which does not match ifttt.com

Why does the browser not display a warning that the issued certificate does not match the domain name?

ifttt.com is in the Subject Alternative Names extension in the certificate.

Each certificate has a primary name, but it can also have multiple alternative names.  Hosting providers and content distribution networks that host multiple websites but wish to provide SSL Certificates (which is good) often use this method to create certificates that are valid for multiple sites that are hosted by the same service.

This is typically considered safe because the people who own the sites that share a certificate don't actually control the certificate - their hosting provider does.  The individual site owners don't have the private key.  This means they can't use the fact that they are Subject Alternative Names on a cert to man in the middle sites they share with.  The host could, of course, but the host already truly controls those sites - they don't need to man in the middle.  You ultimately need to trust them.


Are SSL certs auto-revoked if their Not-Valid-After date is reached without renewing? I'm learning about X509 certs used in client-cert authentication to https endpoints. If I have an OCSP checker (Python script that creates, submits, decodes OCSP responses), do I need to check the not-valid-after date on a client cert?
Example:

Client makes request to my https endpoint
I check the client's certificate CA's OCSP endpoint to see if the cert has been revoked
Do I also need to check the client cert dates or does an OCSP revocation occur immediately if the not-valid-after date has been reached?

No. Revocation is an active event, not something that passively or automatically happens. Expiration is passive, though. An expired cert is no longer valid, so there's no need to stick it in a CRL or update OCSP.
If the purpose of your checker is only to parse OCSP, then no, you don't need to check the dates on the cert, because that's not part of OCSP. If the purpose of your checker is to answer the question "is this cert valid?", then you absolutely need to check the validity dates (both start and end).
EDIT: As eckes points out, for your typical client-identification or server-identification cert (or any other kind not used for long-term signatures), once it's expired you can actually take it off revocation lists, which helps keep their size down.


What is the difference between authorized_keys and known_hosts file for SSH? I am learning the basics of SSH protocol. I am confused between the contents of the following 2 files:

~/.ssh/authorized_keys: Holds a list of authorized public keys for servers. When the client connects to a server, the server authenticates the client by checking its signed public key stored within this file
~/.ssh/known_hosts: Contains DSA host keys of SSH servers accessed by the user. This file is very important for ensuring that the SSH client is connecting the correct SSH server.

I am not sure what this means. Please help.

The known_hosts file lets the client authenticate the server, to check that it isn't connecting to an impersonator. The authorized_keys file lets the server authenticate the user.

Server authentication

One of the first things that happens when the SSH connection is being established is that the server sends its public key to the client, and proves (thanks to public-key cryptography) to the client that it knows the associated private key. This authenticates the server: if this part of the protocol is successful, the client knows that the server is who it claims it is.

The client may check that the server is a known one, and not some rogue server trying to pass off as the right one. SSH provides only a simple mechanism to verify the server's legitimacy: it remembers servers you've already connected to, in the ~/.ssh/known_hosts file on the client machine (there's also a system-wide file /etc/ssh/known_hosts). The first time you connect to a server, you need to check by some other means that the public key presented by the server is really the public key of the server you wanted to connect to. If you have the public key of the server you're about to connect to, you can add it to ~/.ssh/known_hosts on the client manually.

By the way, known_hosts can contain any type of public key supported by the SSH implementation, not just DSA (also RSA and ECDSA).

Authenticating the server has to be done before you send any confidential data to it. In particular, if the user authentication involves a password, the password must not be sent to an unauthenticated server.

User authentication

The server only lets a remote user log in if that user can prove that they have the right to access that account. Depending on the server's configuration and the user's choice, the user may present one of several forms of credentials (the list below is not exhaustive).

The user may present the password for the account that he is trying to log into; the server then verifies that the password is correct.
The user may present a public key and prove that he possesses the private key associated with that public key. This is exactly the same method that is used to authenticate the server, but now the user is trying to prove its identity and the server is verifying it. The login attempt is accepted if the user proves that he knows the private key and the public key is in the account's authorization list (~/.ssh/authorized_keys on the server).
Another type of method involves delegating part of the work of authenticating the user to the client machine. This happens in controlled environments such as enterprises, when many machines share the same accounts. The server authenticates the client machine by the same mechanism that is used the other way round, then relies on the client to authenticate the user.


Is Docker Desktop safe to use on a unsecured network? I use Docker Desktop for Windows. I noticed it adds to my OS's host file <ip> host.docker.internal, where <ip> is the private machine IP for the connected local network. (This DNS name is used to communicate from containers to the host machine.) What are the implications of this? Does this mean that a machine connected to the same network can access Docker on my machine? Is Docker safe to use on a unsecured network?

Does this mean that a machine connected to the same network can access Docker on my machine?

Just like regular Docker, containers aren't directly exposed to the network unless you manually expose specific ports on them. host.docker.internal is a special value used to ensure the host is reachable from containers, even if its address changes.

Is Docker safe to use on a unsecured network?

In general, probably, but you'd need to be careful if you are exposing ports to the unsecured network, or if your containers are connecting to outside services using non-secure protocols.
See the docs for more details.


Client hacked via ssh session I was using my Mac's terminal for a ssh connection to a server from a hosting service provider. Sometime right after I finished the session and closed the terminal, my Mac stopped responding and showing the beach ball. After waiting for 2-3 minutes, I decided to unplug the network cable. I noticed that my Mac behaved differently and still not responding to mouse or keyboard. Another 2-4 minutes, I decided to force a shutdown by holding down the power switch until it is off.

After that my Mac would not boot up and indicated there is no disk. If I went into the discovery mode, it only shows the recovery partition. All other partitions were gone.

Could my Mac being hacked and partitions were deleted? I remembered when my first time setting up ssh connection with this hosting provider, I did get a warning something about the encryption version .99 needed to be updated, etc. But I have not done so.

Can a ssh client be hacked when using a ssh connection?

This looks like a coincidence. It looks like your hard drive broke while you happened to have an SSH session open.

SSH is a point-to-point protocol. As the client, the only one you are communicating with is the server. It is also a very secure protocol specifically designed to not allow any 3rd party to eavesdrop or manipulate data. Maybe if your SSH client has a vulnerability, a malicious server could exploit it. But that would assume that:

The server you connected to is malicious. When it is a professional hosting provider, that's unlikely. Hacking your customers is bad for business.
They had nothing better to do than randomly destroy your data. That's really unlikely, because there is no benefit in doing that. There is a million better things to do when you have a remote execution vulnerability, and most of them work best when the user doesn't notice anything at all.


Sending temp password when users first registered - is that good for anything? One of our clients has sent us a list of security requirements. One of them was that registration does not including setting a password - once complete, a temp password is sent to the user, and the user must change the temp password on the first login.

I think I have come across this flow as a user, but I can't figure out what is it good for. If it's to force the user to use a real email, the common practice is to send a validation link to email used, and make the account inactive until the link's url is accessed.

So, is there a real security benefit in assigning temporary passwords to newly registered users, or is it just some IT manager who tries to be clever?

The procedure you describe seems to be the conflation of two distinct procedures which apply to distinct contexts.

1. Registration for a targeted individual

There are some contexts in which the registration is for a specific individual, with a defined physical identity, and occurs in a process which does not allow the setting of a user-chosen password. An example is when you "register" someone who you met at some trade show, and who gave you his business card. You know his email address, but when registration takes place, the user is not there. In such a situation, you have to send him a way to initially log in to your system (with at least some level of authentication -- you do not want to create an account for everybody, just for that guy) so that he could complete the procedure by choosing his own password.

An initial password, sent by email, and which must be changed upon first usage (enforced by the application), is one way to cope with that context. Sending him a "unique registration link" which brings him to a page where he can choose his password is, from a security point of view, exactly the same thing.

This is a non-ideal situation, in that the initial credentials must travel unprotected. Forcing password change upon first usage is a mitigation measure: yes, an attacker could intercept the initial password / validation link, but then he would have to choose a password himself, and at least the intended user will notice the problem (by not receiving the email or not being able to log in).

2. Registration for "anybody"

Most deployed Web apps which use registration work in a different context. Consider a Web-based vendor of some goods (think Amazon). Here, you accept anybody as new user. You need to "register" users because you want users to be able to keep track of their commands, and they should not be able to see the commands of other people.

In such a context, the user is available during the initial registration: he initiated it, he is right behind his keyboard at that time, and he can type in his chosen password under the cover of HTTPS. The Web app can accept this kind of registration because it is not picky: by design, anybody is entitled to register.

You still need a "validation link" sent by email, but for a very distinct purpose: the validation link is used to make sure that the email address is genuine. An attacker intercepting that communication could fool you (i.e. register under an email address which he does not "own" -- although he can intercept emails sent to that address, so he really owns it, to some extent), but such an attacker would not attack the same thing than in the first context. In the first context, the attacker impersonates the user who is entitled to log in; in the second context, the attacker is entitled to log in anyway, but he succeeds in doing so while providing the email address of someone else.

Summary

Sending a one-time initial password through email is a good or bad thing, depending on what kind of registration you are running. For a classical Web-based account creation that anybody can do, this is bad. For registration of a specific individual, the enforcement of a password change from the initial password is good, because in that case you already had to sent it by email, which is a security hazard (you just had no choice, and you must mitigate risks).


TLS/SSL design and OSI model TLS should be, at least in a broad and theoretical sense, a transport layer protocol.
But TLS provide authentication through X.509 certificates which are based on a hostname, server name, or whatever kind of "name" that should only exist at application level (Unless we only authenticate ip addresses). So in practice TLS span largely between the application and transport layer.
Now I was wondering, are there technical and practical reasons why TLS was not designed to simply provide key exchange methods, and the establishment of a encrypted statefull channel leaving certificates verification to the application layer, creating a smoother transport layer protocol with a more linear interface?

Transport layer protocols like UDP, TCP, SCTP ... are traditionally implemented at the operating system kernel. While it would probably be possible to design a protocol which does encryption at the transport layer (or network layer like IPSec), adoption of the protocol would thus require changes to all relevant OS. This means adoption of the protocol would probably be very slow.

At the time SSL was invented Netscape not only created the major browser but also major server software. It was thus much easier and faster to add the protected transport directly into the application software (both client and server) instead of trying to get a maybe more academically clean approach into the various OS.

Apart from that OSI model and TCP/IP model are just abstract views to how networking worked at the time these models were created. While at this time the complexity was largely at the lower layers, the complexity today is at the higher layers and the OSI and TCP/IP model do not address today's complexity any more. Just take QUIC, HTTP/2 or even WebSockets which implement transport layer tasks inside the application layer.


What are the downsides to having PostgreSQL database available directly from public network? When auditing a machine for one of my clients I noticed that they have PostgreSQL listening and accessible from public network. This is not necessary for their application, seems they simply neglected to set up the firewall properly.
PostgreSQL seems to be running default pg_hba.conf file from the distribution package, and it does not accept connections without valid credentials.
I still feel that it is wrong to unnecessarily expose the database to the outside world. What arguments are for/against such approach?

I can see a couple downsides:

Remote access

This is the most basic one. If the attacker gets the credentials for any user of the database, it will have remote access. Not as improbable as you think. Remember that config.php.bak, vars.php.old, and so on, that someone left over? Guess what happens when the attacker uses dirbuster and grabs those...

Bruteforce attacks

Your IP is scanned all the time (the so-called internet background noise), and bots will find your Postgres installation. They will try to bruteforce credentials all the time.

Unknown exploits

If any time there's an exploit on Postgres that allows remote access (like this one), attackers can gain access to the database. Chaining it to any file write capability and the attackers can gain a shell.

Information disclosure

Depending on version and sub-version, the attackers can guess the distribution and kernel version your server is using. This can lead to more effective exploits.


Challenge: How to find the secret key in homebrew MAC/keyed hash: sha1(key + cookie)? I am trying to solve a security challenge on a website.

Basically, the website computes sha1(key + cookie) to sign a cookie so that the user can't change it himself, and to accomplish the goal you have to find the key value.

I have two (not really good) ideas to find the secret key value :

1: Online (way too slow) try all combinations of the authentication hash with an empty (0 bytes) cookie: this way the website will compute sha1(key) only and will stop displaying an error when I find the correct secret key value.
2: Offline (still very slow but better since you don't need any network requests) go on the website and get {cookie, cookie_hash}. Try to hash xxx + cookie for every possible value of xxx : when sha1(xxx + cookie) == cookie_hash, I know that xxx == secret key.

The thing is, as you noticed, that even the second method is brute forcing and therefore very slow.

Do you think there is a faster method?

and to accomplish the goal you have to find the key value.

Do you really need to recover the key to accomplish the goal?

The scheme you have described is vulnerable to the classic length extension attack where a hash function is misused as a message authentication code. The attack is described very well in the Wikepedia article so I shall avoid replicating the example here.

With the length extension attack, you can generate a valid signature without knowing the actual key value, which is presumably enough to solve the challenge.


Prevent Text Spoofing - Best methods In an enterprise environment we have been inundated with spoof texts appearing to be from the corporate office.

After much research it appears Verizon isn't able to assist. Just wondering if anyone has experienced this and best methods for reducing the risk and re-occurrence to my staff?

Sadly, there isn't really a way to prevent it. It's an inherent weakness of the SS7 system. However, you can try to educate your users to not fall for these scams. Maybe you can even hack back and try to play their game and trick them.


Smart cards and firewalls are what type of access control? Specifically for the CISSP, trying to figure out what type of access control these would be considered.

Short answer: Both smart cards and firewalls would be considered technical access controls.

There are three types of access control as defined by ISC2, technical, administrative, and physical. Physical includes badge readers, physical locks, etc. Administrative would be policies or procedures about access. Technical includes hardware or software systems which provide access control.


Is it possible to gain RCE from Arbitrary file write by an unprivileged user? I am pentesting a PHP website running on Apache in a Ubuntu server.

I found a vulnerability that allows me to write files to the target system.
I know it's possible to write a php shell to the HTTP root directory and get RCE this way, but in my case It does not seem possible. The web server is running as the www-data user, who does not have permissions to write anywhere inside the HTTP root directory. I did successfully write files only to /tmp/ and /dev/shm/ .

Is there any technique that may help me get a RCE out of this vulnerability? Or is this the most I can do with it?

Is there any technique that may help me get a RCE out of this
  vulnerability? Or is this the most I can do with it?

No,in and of itself you cant exploit this for an RCE.You will simply be able to smuggle shells using this way and wont be able to execute them.You will have to chain this vulnerability with another one to gain RCE.A vulnerability like directory traversal could help you gain RCE in this case.

ALTHOUGH
There have been cases where web application use vulnerable libraries which takes what the user uploaded and preform actions on it.If the application uses such a vulnerable upload then that could also be leveraged to perform other actions,sometimes ever RCE or Sql injection.


Canvas fingerprinting identifies the OS? I recently read this article, about how a journalist was hacked. She describes how they used a 'fingerprinting' technique to identify her OS. The way they use a one pixel image, it sounds like the canvas fingerprinting technique.

My understanding from what I have read about this is that canvas fingerprinting gives your OS a unique fingerprint from you can be identified, and followed around the web. I don't even recall it being able to identify your OS. Or have I missed this important detail? +

The two other answers are good but don't explicitly address a (what I find to be) critical point: What the article mentions is not canvas fingerprinting (nor does the author state that it is canvas fingerprinting)!

Canvas fingerprinting is described in this paper. From the abstract:

  We exhibit a new system fingerprint based on browser font
  and WebGL rendering. To obtain this fingerprint, a website
  renders text and WebGL scenes to a <canvas> element, then
  examines the pixels produced. Different systems produce
  different output, and therefore different fingerprints. Even
  very simple tests — such as rendering a single sentence in a
  widely distributed system font — produce surprising variation.

I think you have a misconception about canvas fingerprinting given your statement:

  My understanding from what I have read about this is that canvas fingerprinting gives your OS a unique fingerprint from you can be identified, and followed around the web.

The OS does play a factor in determining the a canvas fingerprint, but with so many other factors, including graphics card, graphics drivers, display, etc. it would probably not be possible to infer the OS from the canvas fingerprint (nor is that the point).

The technique used in the article, as stated is:

  Normally, when an email contains an image, the receiver's email client has to contact the sender's email server in order to 'fetch' the image.

A 'fetch' being a GET request, which has useragent as a header, and useragent does indicate the operating system of the client.


Is "Fingerprint Check" enough to verify HTTPS certificates? So I'm at place A, see this sign:

and I'm writing the fingerprints to a piece of paper (this website is just an example):

Ok. Then, I go to place B (other country, etc.) then I check this site. The sign (for the self-signed cert) shows up again, OK. But: I get my paper out, and check the fingerprint of the site. It's the same.

QUESTION: With checking the fingerprint of the website, could I be 100% sure that:

I'm visiting the same site (server) on the two places (so no one can produce this fingerprint on other server?, MiTM?)
I'm secure because the content of the HTTPS connection cannot be sniffed.

p.s.: I'm using private browsing with Firefox on my notebook. The server side is mine too, I generated the self-signed certs. The notebook side were rebooted in the meantime, so I have to click again that: "I accept the risk, proceed anyway"

Yes. There is a small possibility of creating another cert with the same MD5 hash (an MD5 collision), there is basically no chance of 2 inputs having both the same MD5 and the same SHA1 hashes. This dual hash fingerprinting is used as evidence in court. You want to prove a file is the same file, or a HDD's contents didn't change while it was in Law Enforcement's hands, etc. this is how it is done.


What is the attack scenario against which encrypted files provide protection? There are a couple of files / tools which provide file-level encryption. I guess PDF and ZIP are probably the most commonly known ones.

I wonder what scenario they actually help with or if it just is a bad solution.

For example, if I want to be sure that no man in the middle gets information when I transfer a file over the internet, I think TLS is the solution to go with.

If I want to get some security that attackers who get data on my laptop when I loose the device, I would think of full disk encryption.

The only point I can see is a low-skill attacker which has access to the machine with the encrypted file. Essentially if a friend / family member has access and does not accidentally see something. Do I miss a scenario?

File-level encryption can be useful in several cases, here's a few examples:

Sending data over insecure channels. You mentioned TLS, and that's enough when you have it. But what if you aren't sure every node actually uses TLS? And do you really trust every node? Think about emails, for example.
Storing data in untrusted places. You might trust your encrypted external HDD, but what about Google Drive? What about your hosting provider? If you want to be sure that nobody else is able to access your files (Google, employees at your hosting provider, cyber criminals who manage to breach those service, etc.), you will need to encrypt your files.
Defense in depth. Full-disk encryption will protect your data when your machine is turned off, but what if an attacker grabs your laptop while it's on? What if your machine gets infected and before you notice all your sensitive files are sent to the attacker? With file-level encryption, the attacker won't have access to the content of your sensitive files right away, so such attacks might fail.


Cannot execute shellcode using buffer overflow As a home exercise I'm trying to achieve buffer overflow attack by running a simple char array program that stores the input argument in the program stack and then overflowing that stack with long enough input so that EIP gets overwritten with one of the NOP instructions and then it would slide to the shellcode and execute it.

I'm currently running Ubuntu 16.04 32-bit in Virtualbox, with kernel ASLR set to disabled.

My C code:

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

int main(int argc, char **argv)
{
  char buffer[500];
  strcpy(buffer, argv[1]);
  printf("%s\n", buffer);
  return 0;
}

I compiled the code with options: -z execstack -fno-stack-protector

When I'm trying to execute the code in gdb using some bash code to generate the input, I manage to change  the register value to the one containing the NOPs but the code just throws segmentation fault and I am unable to execute the shellcode.

I started with 504 byte input, 476 NOPs + 24 shellcode + 4x 0x45 bytes.

I was able to find my input in the memory. I took the address somewhere between the NOPs (0xbfffed60).

To overwrite the ESP register, I grew the total input length to 508 bytes, which consisted of: 476 NOPs + 24 shellcode + 2x memory address (0xbfffed60, with bytes in inverted order \x60\xed\xff\xbf).

When I run the code with that input, I'm just receiving segmentation fault and not getting the shellcode to execute.

It seems to go in the exact spot where I'm telling it to go but it does not execute the NOPs nor the shellcode.

The EIP is pointing to the address 0x90909090, which is an invalid memory address.
Essentially, your raw data (NOPs) are being interpreted as an address that points to the next instructions to execute. You need to fill EIP with the address of your NOPs.

If you find out exactly which four NOPs are ending up in the EIP, then you can place the address of your shellcode at that location.

Next steps:
Try finding out exactly what the offset is that ends up controlling EIP. The pattern create tool from peda (https://github.com/longld/peda) can help here. Insert the pattern (of length 476) in your payload instead of the NOPS, and see what address ends up in EIP. Then use pattern search to find out what offset that is.


How to reverse engineer WannaCry? I was reading an article today about a Google researcher linking the WannaCry malware to the earlier malware Cantopee.

I had two primary questions based on the contents of the article.

What do the numbers/addresses represent in this image?

Can someone explain to me what is going on here? Which tools are they using, and how would I do this myself?

Check out reverseengineering.SE for all your RE questions.

The name of the tool being used is Hiew.

From WannaCry — Links to Lazarus Group:

Some code in WannaCry (9c7c7149387a1c79679a87dd1ba755bc) beginning at address 0x402560 is the same as some code in Contopee (ac21c8ad899727137c4b94458d7aa8d8) beginning at address 0x10004ba0. Same story for the next pair of addresses. In essence, both pieces of software share code.

This is what is depicted in picture 2 in the question, it is just a little hard to see. A bigger picture can be found in Dan Goodin's article Virulent WCry ransomware worm may have North Korea’s fingerprints on it (click to enlarge):


How is "" or "selselectect" used to avoid filtering? A technique for avoid filtering of common words is the one I described in the title.

However, why does this technique work? SELECT isn't the same as SELSELECTECT for example.

Let's say I blacklisted the word <script> and replace it with nothing.  Then <scr<script>ipt> becomes <script>.

This is why well-written html sanitizers/purifiers apply the rules recursively.  That is only when the last sanitation step made no changes to the content will it stop/not apply another round of the processing rules.  (It also likely will fail and return no content if too many processing rounds are necessary).


Security of PIN that spells out words? Description

PayPal suggests that generating a PIN by spelling words (on a numeric pad, e.g., [ABC] = 2) is a good method for security and memorability, e.g., B-L-U-E-C-O-W = 2583269.

My knowledge about password security is limited and I have not found any information about this. While these PINs are not completely random it seems to me that they should be (depending on words) quite secure†, at least for what PINs usually protect (just 4--8 numbers) and with other measures such limited attempts.

† I just realized that 0 and 1 are not mapped to letters, so those might have to be interspersed at random.

Questions

Can anything be said directly about the security of PINs that spell
out words?
Has any research or attacks been made regarding these kinds of PINs?

The concept you are looking for is "entropy" and the selection process for passwords.

For PINs, people tend to use well-known numbers or patterns (1111, 1066 (very common in the UK), 1337 (popular with gamer males), etc). These have very low entropy and are easy to guess. These are the equivalent of password1. If you leave the selection process up to humans, they will default to something very easy to remember and likely something that many other people will use, too.

Getting people to think about another PIN selection process helps to increase entropy. Random is best, of course, but translating the process to words widens the scope of selection options.

The number set is the same (8 characters 0-9), so a plain brute-force is the same, but known patterns make the process so much faster.

So, given that random PIN selection is likely not going to happen in practice, and recognizing that people need a nudge towards better PIN selection processes, nudging people towards words is a generally good thing. Far better than meaningful dates or re-used PINs.


SMS Encryption with Hashing I need help, I want to send a encrypted SMS from Alice to Bob, where does hashing comes in here? How do I use the hashing??

Hashing, or really a Message Authentication Code (MAC) in this instance, would not be used in encrypting the message per se, but would be used to verify that the message had not been tampered with while in transit.

A traditional hashing function is a one-way function which takes an input (the text of your SMS message, in this case) give a unique output for that input.  The same hashing function applied to the same input will always product the same output.  A good hashing function is one that is mathematically easy to go from input to output, but is mathematically difficult to go from output back to the orginal input.

A Message Authentication Code is similar to a traditional hash in that it's difficult to go from output back to input, but it also takes a private key.  This means that two users can take the same MAC function, put in the same data, but get two completely different results if the private keys do not match.  The recipient of the message can then use the senders public key to validate that the sender was indeed the person that sent the message.

Building crypto systems is very hard to do correctly.  If you need to communicate securely by phone, I would recommend that you use an existing, peer-reviewed app such as Signal.


PayPal encrypted with obsolete cryptography My Chrome just complained from PayPal's security, similarly to this issue:

Google Chrome "Your connection to website is encrypted with obsolete cryptography"

The identity is verified, but it complains the cryptography is obsolete.

Says it uses RC4_128 with SHA1.

Should I be worried? Should PayPal be ashamed? Should Chrome stop scaring me?

UPDATE: Chrome was v 42 and after the update to v 43 the message stopped and now the certificate shows AES_256_CBC -- which, according to some of the comments, makes me believe that choice of using "RC4_128 with SHA1" was made by Chrome 42, not PayPal.

Bad Google: making people think the server is in the wrong, while it was your browser making the decision...

This message is Google trying to push people nilly-willy into the 21st century of cryptography. So they point and mock when they see "RC4" or "SHA-1". This does not mean that such algorithms can be broken immediately. Only that Google would find the world a better place (or possibly a googler place) if everybody were using algorithms more to their liking, i.e. TLS 1.2 with AES/GCM.

In practice, there are a few "worries" about RC4 and SHA-1, though neither should prove fatal to your communications:

RC4 has known biases. These biases could theoretically be exploited to recover secret data, provided that the attacker can observe lots of connections (millions), all containing the same secret data at the same predictable place in the stream, provided that the secret appears early enough in that stream (because these biases get lower the further you go down the stream). The last condition is the one which is the biggest problem for an attacker trying to break through HTTPS; the interesting secret (HTTP cookie) appears relatively far in the HTTP header. To my knowledge, there has been no application of such attacks spotted in the wild so far.
SHA-1 has theoretical weaknesses with regards to resistance to collisions. No actual collision was produced yet; the theory (which is considered rather solid) is that building a collision would imply a computing cost of 261 function evaluations or so, i.e. substantially less than the expected 280 (for a function with a 160-bit output), but still too much to be casually contemplated even by academics with a lot of budget. Moreover, use of SHA-1 within TLS is through HMAC, which would not be impacted by collisions. There is no known weakness, theoretical or otherwise, in SHA-1 as it is used in SSL/TLS.

Paypal enforces RC4 because they want to avoid the perceived weakness induced by AES in CBC mode (so-called "BEAST attack" that no longer works in practice). They sure would prefer if Chrome was not claiming that they are "obsolete" because that may scare away customers; for a bank, security is important, but projecting an image of security even more. Customers must feel safe, or they will bring their money elsewhere (this is why most 19th-century banks were opening offices with very massive architecture, with granite columns and steel doors: to instill an inconscious feeling of solidity).


Why don't fingerprint authentication systems don't store 'hashes'? Usual password authentication systems do not store passwords directly on the server, but only hashes of those passwords.
Why do fingerprint authentication systems not offer this possibility?

Password authentication systems check for full equality. If you make a typo in your password, you will not be authenticated*.
You cannot check a fingerprint for full equality; it's a 'scan' and there will always be some minor differences: perhaps you have a small cut in your finger, or you put your finger slightly rotated on the device and the digitalization process displaces a few pixels.
A hash is designed to implement the avalanche effect; a small change in the input causes a large difference in the output. That means that two slightly different passwords or two slightly different fingerprints produce two completely different hashes. If you have the hash of a fingerprint, there's no way of verifying whether it matches a slightly different fingerprint.
*: such a verification system would work by verifying the hash with not only the hash of the actually entered password, but also the hash of all possible typos.