Should SMS systems warn users of possible spoofing attacks? The author of this blog post Never trust SMS: iOS text spoofing says that: The sender of an SMS message may provide arbitrary sender information using low level protocol features. Furthermore the sender may set a header, to indicate, that replies should be sent to a third number.

Apple comments:

  Apple takes security very seriously. When using iMessage instead of
  SMS, addresses are verified which protects against these kinds of
  spoofing attacks. One of the limitations of SMS is that it allows
  messages to be sent with spoofed addresses to any phone, so we urge
  customers to be extremely careful if they're directed to an unknown
  Web site or address over SMS.

My understanding is that Apple is saying this is not a design flaw on their part, but one on the part of the SMS, and the way the payload is designed.

This reaction poses a number of questions:

Is it true, that the receiving phone cannot verify whether the sender information is correct?
Is the reply to header an issue that users should be warned about when the user tries to reply to an SMS message?
How do other vendors handle this situation?
Both issues (arbitrary sender information and reply-to-header) apply to plain old email, as well. How do email clients deal with it?

Apple did not create the SMS standard that was provided to them by the industry.  The industry indicated that an SMS transaction can include a reply-to field.  Apple has designed their software to use what the industry told them existed (and what industry equipment is compatible with as it relays it intact).  As long as Apple isn't using the provided standard incorrectly, they can't be to blame.  If a reply-to field is included, and is different than the from field, what exactly is the purpose of the reply-to field if not to prevent you from sending the SMS to the "from" originator?  What would everyone expect behavior to be exactly?

An example: Apple builds computers.  My Mac Book Pro (running OS X 10.8) can be fooled by a spoofed MAC address.  Is that Apples fault?  My MBP can be fooled by a spoofed IP address.  Also Apples fault?  No in both cases, the IP stack was designed long before Apple had anything to do with networking computers.  MAC control being spoofed is not something easily detectable (unless you know for sure what MAC address you should expect to see).  Apple is using provided standards.

EDIT: If customers want a secure platform, they use iMessage. If compatibility is the concern, they use SMS. SMS is not, and has never been designed to be a secure platform.

I'm of the opinion that @blunder can not compare SSL (a known secure system) to SMS (a known insecure system).  Telnet is an unsecured communications medium and would be a closer comparison.  How many computers pop up a notification that says, "Are you sure you want to use telnet, it sends passwords in cleartext?"  Is Apple liable because OS X doesn't have a popup that notifies someone trying to use telnet that it isn't secure?

My turn to ask a question.  Why are we bent on finding excuses to make Apple fix this, instead of having the cause of the problem (the SMS standard) fixed?  Why is fixing the symptom logical when you can cure it at the cause (the carriers)?


Should binary signature checked before launching from trusted locations? If need to launch/load binaries from trusted Windows locations like System32 or Windows or Program Files directories, should the binary signature be checked before using it?

Only Admin can copy/install file on trusted locations.

It depends on your goal, and the sensitivity and other defenses of the system.

If your intention is a defense-in-depth measure, either against an incompetent/compromised/malicious admin or somebody using an exploit on the system, then checking signatures makes sense. It's not a perfect protection, because of course whatever code performs that check could itself end up compromised, or an attacker who is aware (or paranoid) of the risk may bypass the signature check by tampering with code in memory or performing a similar trick. For that matter, sufficiently well-funded malware may even manage to get itself signed by a trusted but fraudulent certificate (it's happened before). Defense-in-depth measures very similar to this have saved companies from attackers before, either catching them red-handed or at least stymying them enough that they couldn't reach the real goods before their intrusion was detected and their access cut off.

On the other hand, if the system is already very well-hardened and has good perimeter security, plus nobody who logs into it as Admin except a few trusted individuals for very rare, specific, and monitored operations... well, if you've got that level of security already you probably care enough to go for the additional defense in depth anyhow, but it's less likely that you'll need it. Alternatively, if the system isn't that sensitive (say, it's some user's home computer, unlikely to be especially targeted and not holding any amazingly valuable secrets), it may simply not be worth the engineering effort to set up and perform those checks. It's also worth testing for a performance hit; verifying a signature (especially on larger files) takes some time, and may prove unacceptable.


Is it okay to keep .zip files in the public_html folder? My company website just take copies of the public html folder and keep zip files as backup in the same folder, I want to know if this is secure or not ?
Because other people don't know the name for the zip file . Is there a way that a bad guy can brute force the zip-file name and download it ?

It depends on what the file contains. If every file in the public_html directory is a file that is intended for public dissemination, in their original, plain-text content -- then yes, by all means. But for any website running a CMS or similar, there are probably files that contain information you don't want distributed -- like configuration information for a database on a WordPress or Drupal website. It would be foolish to rely only on an unlikely file name to keep your data safe.

Some backup services will keep .zip files in a public directory, but use some sort of protection within .htaccess (deny from all) to prevent these from being accessed. This is better than nothing, but still insufficient, because a minor change to the server configuration (changing the AllowOverride config) would render the .htaccess file powerless to control access to the directory, and the .zip files would be accessible.

My recommendation: keep ZIP files out of the public webroot, keep the permissions 600 for these files, and add a .htaccess with a "deny from all" directive in the folder as failsafe.


How to modify data sending by application to the server? Let's suppose that I have a simple application which is sending data to the server (placed not in my network), for example 0 1 2 3 4 5 (explicit data) in one second delay between each other. Is it possible to intercept part of this data, modify it and send like it was send by my application? How to do this? What should I know?

I know this question is kind of fatuously but I'm really curious about it.

If you don't have authentication then it is very straightforward to send spoofed data.

Luckily these this feature exists at various levels to prevent spoofing.

TCP/IP offers basic end to end connectivity, so an attacker needs to conduct a man in the middle attack. This consists of persuading A that the attacker is B and persuading B that the attacker is A. This way the data cab be altered.

In order to prevent man in the middle attacks, strong authentication is used, which is what HTTPS does - the client knows the identifier, or certificate, that the server has, and if the attacker tries to pretend to be the server it would not be able to authenticate itself unless it has the right certificate.

If we exclude man in the middle attacks, the only other way to change the data sent to the server is by compromising one of the end points, either the client or server.


How to conduct DDoS attack practically? Possible Duplicate:
  How to simulate DDoS attacks from the Internet?

I want to conduct a DDoS attack. Can anyone please tell how can i conduct it? What are the latest DDos attacks? What are the tools available for it?. I dont want to conduct any real time attack but as a part of my academics i have to show demo of it. So it would be helpful to me if anyone can help.

One has many possibilities to DDoS. I can't think of any tools that work with a click of a button.

Some possibilities:

Network congestion (just limit a server upstream to 10 Mbit and set up 10 clients that each download at 100 mbit)
Request fload for a webserver (You can use apachebenchmark for this on different clients)
TCP SYN flood (just write a simple script that opens TCP connections but never replies to the server's SYN/ACK, multi thread it)
ICMP flood (multi threaded script on lots of clients that ping your demoserver)

Another idea for a simulation might be (my friends did this one last year as a project):

Use a demo-machine with a vulnerable version of proftpd to rootkit a guest machine and install kaiten.c on it (u will need multiple guests though)
Let them join an IRC channel so you can send commands (botnet)
let them all start executing one of the previously discussed scripts


Information Security Governance - security measures We are about to sign a contract with an OCR service provider  (Scanned documents(personal information) will be sent, which will be processed OCR, data transmitted back and documents deleted.)The service provider offers an OCR service using an application developed by him available in the cloud.
We use an internally developed interface to upload photos of IDs that are sent through an API integration of the provider's OCR application.

According to the internal policies, we asked the supplier for a series of security requirements such as:
Existence of a security policy, testing from the point of view of the security of the application, code robustness analyzes - evidence that they have been carried out.
The provider refuses to meet these requirements on the grounds that they offer access to an OCR service, not software, not licenses.

Please tell me from your experience, if you know of cases in which providers offering such services must / should not meet the required security requirements.
Thank you!

"Must/should not" becomes a matter of law or regulation, which we cannot speak to. In some jurisdictions (and the number is growing) they have a responsibility to comply with requests like yours, so you could check into that.

From your description, the application was developed by them, hosted by them, and operated by them. They are the only ones to whom your questions could be asked. And your questions are not strange or unique. They are pretty basic, actually.

What it sounds like is that he is not prepared for that level of governance/auditing. Which is fair if the company is new and small. They could answer the questions, but they are not prepared to and are likely uneasy providing answers without understanding their liabilities in answering.


Is it possible to decrypt but not encrypt using the private key? The RSA key for example, can generate the public key from the private key, which is possible to encrypt a message with the private key. What I am trying to achieve is this:

A encrypts a message using B's public key,
B decrypts the message using its private key, but cannot encrypt a message and decrypt it by itself using its private key.

This is useful for validating that the message was sent by A.

This is useful for validating that the message was sent by A.

It would prove only that the message was sent by someone who has the B's public key. It's not only A, but since the key is public, it's everyone.

  B [ ] cannot encrypt a message and
  decrypt it by itself using its private key.

Yes. Technically B cannot encrypt the message using their private key and decrypt it using the same private key. But B can encrypt the message using B's public key, since it's public.


Risks of using a root container to manage Docker daemon My intention is to create/show/delete images and containers automatically with Docker.

According to Docker's security guidelines exposing Docker's daemon to a port is a high security risk, because anybody could connect and use it:

  You could set it to 0.0.0.0:2375 or a specific host IP to give access
  to everybody, but that is not recommended because then it is trivial
  for someone to gain root access to the host where the daemon is
  running.
  source 1

Other possibility is to run a container on 'privileged' mode that will be on charge of creating containers INSIDE a docker container (docker-russian-doll). But has some problems as described here.

I was thinking about a 3rd option:

Create a minimal image that will mount the socket internally, for example with docker-compose:

volumes:
  - /var/run/docker.sock:/var/run/docker.sock

Write a small client (with Java for example) that connects to the socket and exposes it with a--yet-another-although-minimal REST API
Let that container to run as a root user
Link any container that wants to create images/containers using docker-links, for example with docker-compose.

Assumptions:

The approach is for pet projects, I don't want to setup a private network or similar
The idea is to create images/containers with a minimalistic approach
No critical data will be stored nor critical applications will be running on these host

I based on the premise that that links between containers are "secure" communication.

Questions:

Is this root-container with minimal REST API layer more secure than exposing the socket as IP:PORT?
Will this approach reduce the possibilities of an attacker trying to get control over the socket?

Will this approach reduce the possibilities of an attacker trying to get control over the socket?

Maybe, but probably not much. Why bother? Opening port 2375 for everyone is not the way Docker is meant to be configured and documentation rightfully warns against it.

Follow the Protect the Docker daemon socket guide and set up the TLS port with the TLS client verification.

Or use the Docker Machine which, given the SSH credentials to the machine running the Docker Engine, will automatically set these things up.


Unknown URL shows my website I run a website at https://fastslots.co. I just discovered that I am getting requests from the URL https://canadaehtees.com/ that I have no affiliation with. When I load canadaehtees.com in my browser I get a warning about an invalid SSL certificate. If I proceed anyway, the site that is displayed looks and behaves exactly like fastslots.co and all requests made there go to my server. However, the URL stays at canadaehtees.com.

My site is written in Node.js, and I am not using a proxy. I am redirecting all requests that use HTTP or that start with www to my site using HTTPS.

I am not sure what the best thing to do is. Obviously I can just return an error page if I get a request where the URL does not match fastslots.co. Still I am worried about what is going on here. Does anyone know?

[Edit: I am now redirecting all requests to fastslots.co that have an unknown host (such as canadaehtees.com for example). Is this not a good idea?]

I've taken a quick look, and this appears to be completely benign, if somewhat annoying.  It's not an attack as Michael suggested in his answer.

What has happened is that someone purchased a domain (canadaehtees.com) and pointed the DNS records for that domain at the IP address that currently hosts your website (fastslots.co).  Why?  It could be a simple mistake, or it could be that they were in possession of that IP address before you were, given that their domain name is slightly older than yours.

This is why the site at that domain looks exactly like yours (it is yours!) and you get the invalid certificate error over https (because the certificate is also yours, and so isn't for canadaehtees.com, but for fastslots.co.)

What can you do about?  Well, redirecting as you've currently configured is one option.  I would suggest that you change the redirect from a 302 (temporary) to a 301 (permanent) if this is the solution you want to use long term.

Other status codes you could return for unknown hosts would be 404 (not found) or 410 (gone).

The more drastic solution, but the one that should permanently fix the issue without any further work on your part would be move your site to another IP.


Good Practice to Secure Computer Terminal? I am currently trying to set up a computer terminal from scratch at home. The use of it is basically as a terminal to connect to cloud servers hosted remotely in the internet.

I am trying my best to make it secure. Do you mind pointing out what I have missed to make the terminal more secure?

Thank you very much in advance.

Somethings I have thought of are:

Common security setup:

Clean OS installation (Using secure OS such as CentOS 7)
Install all necessary tools within a VM OS
OS and VM OSes hardening
Virus scanner
OS monitoring
Log summarizer and alert

Physical Infrastructure:

OS installation physically on the terminal
The terminal is connected to internet behind a physical router and firewall

To encrypt the hard-drive, e.g. via BIOS (if it's known to be strong), via LUKS (default Redhat software disk encryption). It protects against stealing of harddrives.
For the terminal you could use Fedora instead of Centos as there's much newer GTK3 so if you are using GTK3 applications they will benefit a lot. There are also plenty of tools built-in which are newer and more usable on the terminal.
Keep the SELinux and Firewall enabled

If you plan to connect to this PC from outside world then the most usable way is to use X2GO over SSH and XFCE desktop. SSH is safer to be exposed than home router VPN, Centos VPN (any kind of) or anything else. You can limit brute-force on the SSH by using strong passwords or keys or iptables connection limit.


Why is OpenID considered secure when password reuse is not? OpenID allows you to use your e.g. Google/Facebook/Microsoft account to log into a third party website.  It can be used to log into Stack Exchange.

Why is this considered an acceptable practice, while password reuse is not?  Does it not amount to the same thing if the OpenID account is compromised, in that the attacker will be able to access more than one of the users accounts?

Additionally, given that an email account is often the skeleton key for all other online accounts (in that the reset password link will send you an email to reset the password), is it not also dangerous to condition the users to enter their e.g. Gmail password on other webpages, too?

The point of OpenId or other similar mechanisms is that it allows you to select a single, highly trustworthy organisation to hold your credentials. There is an assumption that they are in some way more secure than the average site. For example:

They should offer 2 factor authentication
They should have good, proactive account misuse monitoring
They should be ISO27001 certified
Etc.

If you re-use your password, then your accounts across all the sites where you re-use are only as secure as the weakest site. Any compromise of any site would mean all your accounts are at risk.

So, partly it is a simple probability - the more places you keep your credentials, the more likely they are to be stolen.

And partly it is about quality- you should select an OpenId provider that you trust highly.

On the point about entering email credentials into other sites, the idea with OAuth etc. is that you don't do that - the site that you log into redirects your browser to your ID providers site and you enter the credentials there. Admittedly, this is somewhat subtle and many users might not realise what is happening, but that is the principle.


How should an application store its credentials Context

When developing desktop applications, you will occasionally have to store credentials somewhere to be able to authenticate your application. An example of this is a Facebook app ID + secret, another one is MySQL credentials.

Storing these plain text in the applications source code doesn't provide any true security since it isn't too much hassle to reverse engineer a program. Gathering the credentials from a server won't do the trick either since hackers easily can perform requests themselves.
Neither will encryption of the stored credentials make any difference since the application will need access to the decryption key to be able to use the credentials at all.

Question

How can one store application specific credentials securely? Preferably cross-OS.

Note:
The relevant language is Java, however, I believe (think) that this is a language agnostic question.

Never hardcode passwords or crypto keys in your program.

The general rule of thumb is: the only credentials you should store on a user's machine are credentials associated with that user, e.g., credentials that enable that user to log into his/her account.

You should not store your developer credentials on the user's machine.  That's not safe.

You have to assume that anything stored on the user's machine is known by the user, or can easily be learned by the user.  (This is the right assumption: it is not hard to reverse-engineer an application binary to learn any keys or secrets that may be embedded in it.)

Once you understand this general principle, everything becomes easy.  Basically, then you need to design the rest of your system and your authentication protocol so that client software can authenticate itself using only those credentials that are safe to store on the client.

Example 1.  Suppose you have a Facebook app ID and key, associated with your app (i.e., associated with your developer account).  Do you embed the app ID and key in the desktop software you ship to users?  No!  Absolutely not.  You definitely don't do that, because that would allow of any of your users to learn your app ID and key and submit their own requests, possibly damaging your reputation.

Instead, you find another way.  For instance, maybe you set up your own server that has the app ID and key and is responsible for making the requests to the Facebook platform (subject to appropriate limitations and rate-limiting).  Then, your client connects to your server.  Maybe you authenticate each client by having each user set up his/her own user account on your server, storing the account credentials on the client, and having the client authenticate itself using these credentials.

You can make this totally invisible to the user, by having the client app generate a new user account on first execution (generating its own login credentials, storing them locally, and sending them to the server).  The client app can use these stored credentials to connect in the future (say, over SSL) and automatically log in every subsequent time the app is executed.

Notice how the only thing stored on a user's machine are credentials that allow to log into that user's account -- but nothing that would allow logging into other people's accounts, and nothing that would expose developer app keys.

Example 2. Suppose you write an app that needs to access the user's data in their Google account.  Do you prompt them for their Google username and password and store it in the app-local storage?  You could: that would be OK, because the user's credentials are stored on the user's machine.  The user has no incentive to try to hack their own machine, because they already know their own credentials.

Even better yet: use OAuth to authorize your app.  This way your app stores an OAuth token in its app-local storage, which allows your app to access the user's Google account.  It also avoids the need to store the user's Google password (which is particularly sensitive) in the app's local storage, so it reduces the risk of compromise.

Example 3. Suppose you're writing an app that has a MySQL database backend that is shared among all users.  Do you take the MySQL database and embed it into the app binary?  No!  Any of your users could extract the password and then gain direct access to your MySQL database.

Instead, you set up a service that provides the necessary functionality.  The client app connects to the service, authenticates itself, and sends the request to the service.  The service can then execute this request on the MySQL database.  The MySQL password stays safely stored on the server's machine, and is never accessible on any user's machine.  The server can impose any restrictions or access control that you desire.

This requires your client app to be able to authenticate to the service.  One way to do that is to have the client app create a new account on the service on first run, generate a random authentication credential, and automatically log in to the service every subsequent time.  You could use SSL with a random password, or even better yet, use something like SSL with a unique client certificate for each client.

The other rule is: you don't hardcode credentials into the program.  If you are storing credentials on the user's machine, store them in some private location: maybe a configuration file or in a directory, preferably one that is only readable by this particular app or this particular user (not a world-readable file).


In C, not using 'void' if a function does not accept any argument is a potential vulnerability In CERT secure coding standard, there is a recommendation that "Always specify void even if a function accepts no arguments". A possible security vulnerability is proposed in it.

/* Compile using gcc4.3.3 */
   void foo() {
        /* Use asm code to retrieve i
         * implicitly from caller
         * and transfer it to a less privileged file */
       }

   /* Caller */
   foo(i); /* i is fed from user input */

  In this noncompliant code example, a user with high privileges feeds
  some secret input to the caller that the caller then passes to foo().
  Because of the way foo() is defined, we might assume there is no way
  for foo() to retrieve information from the caller. However, because
  the value of i is really passed into a stack (before the return
  address of the caller), a malicious programmer can change the internal
  implementation and copy the value manually into a less privileged
  file.

Is there any exploit which uses this "un-secure" coding practice. If not can someone explain or give a sample code how this can be used. Also, if this is really hard to exploit or not possible, could you please explain why?

What happens here is that the foo() function uses a so-called old-style declaration, i.e. as things were done in C before the first normalization (aka "ANSI C" from 1989). In pre-ANSI C, a function bar() which takes two arguments of types int and char * would be defined that way:

void bar()
    int i;
    char *p;
{
    /* do some stuff */
}

and it would be declared the following way (usually in a header file):

void bar();

This means that code which uses the function would include the header file, which would then convey information about the existence of the function, and about its return type (here, void), but nothing whatsoever about the number of arguments and their types. Thus, upon usage, the caller must provide the parameters and hope that it sent the appropriate number and types. If the caller code does not do things properly, then the compiler will not emit warnings.

As a security vulnerability, it is not very convincing. It makes sense only in a context of code inspection. Some auditor is reviewing a lot of source code. An evil developer is trying to do evil things which the auditor will not notice (this is the scenario which is explored in the Underhanded C Contest). Presumably, the auditor will look at the header files and also at the start of the function implementation. In your example, he will see:

void foo()
{
    /* some stuff */
}

then the auditor may just assume that foo() takes no parameter, since the opening brace immediately follows the foo(). However, the caller code (which is elsewhere) calls foo() with some parameters. The C compiler cannot warn: since the function is declared "old-style", the C compiler does not know, when compiling the caller code, that foo() does not actually use any parameter (or so it seems). The caller code will push the arguments on the stack (and remove them upon return). The evil programmer then includes in the definition of foo() some handmade assembly to retrieve the arguments from the stack, even if, at the C syntax level, they don't exist.

Thus, a semi-hidden communication channel between two evil codes (the caller code and the called function), in a way which is not visible from a cursory inspection of the function declaration and start of definition, and, crucially, not warned upon by the C compiler either.

As a vulnerability, I find it pretty weak. The scenario is quite implausible.

The issue is more about quality assurance. Old-style declarations are dangerous, not because of evil programmers, but because of human programmers, who cannot think of everything and must be helped by compiler warnings. That's all the point of function prototypes, introduced in ANSI C, which include type information for the function parameters. In our examples, here are two prototypes:

void foo(void);
void bar(int, char *);

With these declarations, the C compiler will notice that the caller code is trying to send parameters to a function which does not use any, and will abort compilation or at least emit a sternly worded warning.

A typical problem with old-style prototypes is failure to do automatic type casts. For instance, with this function:

void qux()
    char *p;
    int i;
{
    /* some stuff */
}

and this call:

qux(0, 42);

The compiler, seeing the call, will believe that the two parameters are two int values. But the function really expects a pointer and then an int. If the architecture is such that a pointer takes the same size on the stack as an int (and also such that a NULL pointer is encoded the same way as an integer of value 0, which is a rather common feature), then things appear to work. Then compile that on an architecture where pointers are twice larger than integers: the code will fail because the 42 will be interpreted as part of the pointer value.

(The details depend on the architecture, but this would be typical of 16-bit C code compiled on a 16/32-bit architecture with 16-bit alignment, e.g. a 68000 CPU. On 64-bit modern architectures, int values tend to be 64-bit aligned on the stack, which saves the skin of many careless programmers. The problem is more general, though; similar issues occur with floating-point types.)

You should use prototypes; not because old-style functions induce vulnerabilities, but because they induce bugs.

Side note: in C++, prototypes are mandatory, so the void foo(); declaration actually means "no argument whatsoever", like what void foo(void); would mean in ANSI C.


WEP keystream extraction After having captured multiple packets with repeated IVs you can perform cipher1 XOR cipher2 which is the same as having cleartext1 XOR cleartext2, and performing cipher1 XOR cleartext1 gives you the keystream... but how can you separate those XORed clear text messages (cleartext1 XOR cleartext2)?

It's not always obvious how to extract the cleartext messages from an XOR.  However, in many cases, this is quite obvious.  For example, if a message is a 40-byte packets, it's probably an ARP packet, and you already know a bunch of the message from the format of the data on the wire.  Or, if you know this is part of an HTTP request, you're already going to know the format of that request, and determining the other message will be easy.
It may also be possible to determine whether two messages differ in a certain way.  For example, if the XOR of the two values is 0, then you know they're the same byte.  Similarly, if you know one of the messaages is an ASCII-based protocol (e.g., HTTP/1.1 headers), you can determine whether the other message is as well by looking at the top bit, which may lead you to other, more interesting discoveries.
Moreover, many of the insecurities of RC4 let you recover the key in this situation, since RC4 is vulnerable to related-key attacks and WEP uses it in exactly such an insecure way.  In that situation, the XOR of the data isn't as necessary.


We were hacked and have no idea how Last Friday, 7 of our employees' office365 email accounts were hacked simultaneously. We saw successful logins from random US addresses. The virus went through emails and basically does a reply-all with a virus called request.zip.
They all have eset running and a scan shows to be clean. They do not use the same password for other things and there's no shared software they all use as there's always one person that eliminates that possibility that that's how they got hacked.
What I find most interesting, is that out of those 7 people, one is a person who hasn't worked in the company for years. His account is managed by another one of the victims. This almost certainly tells me it's malware.
Of course, because of this we enabled 2FA for everyone and made them change their passwords but everyone is super worried about not knowing how that happened and the very likely possibility that those people are still vulnerable (We started reinstalling the OS with clean installation just to be safe but for now, we still have some not reformatted for tests). To get things worse, lots of our customers downloaded the malware that the breached accounts sent but that's a different issue.
Does anyone know how that might've happened? Did anyone experience anything similar? Is there anything I should look for?

All the answers we could get would end up being guesswork of what could have been, since we don't have access to any of the server logs. This is not helpful to anyone.
What you should be doing now is to  contact a company doing incident response and forensics and have them figure out how it happened. In other words: It's time to call a professional.
Sure, it will be expensive, but most likely less expensive than yet another breach.

Full Disclosure: I work for a company which offers incident response and forensics. I offer you to contact professionals because it's good advice, not because I have any personal gain from it.


How do SED drives generate the DEK? Some newer hard drives and solid state drives are SED (Self-Encrypting Drives), which create a DEK (Data Encryption Key) and store it either unencrypted, or encrypted with a user-supplied AK (Authentication Key) if FDE is wanted. The DEK is used to encrypt all content on the drive. In the case the drive needs to be securely wiped, the DEK can simply be erased, regardless of whether or not the AK is set.

According to the TCG, the DEK is generated on the drive itself, rather than being generated on the computer and transferred over through some vendor-specific ATA command:

  A: The encryption key is generated on board the drive and NEVER LEAVES THE DRIVE. The manufacturer does NOT retain or even have access to the key.

My question is how the DEK is generated. Obviously, the AK, if used, is transferred from the computer, but the DEK is apparently generated on the drive. If each drive's own firmware generates the DEK in its own way, with the firmware developers trying to reinvent the wheel and think up their own way to generate randomness, it would in all likelihood result in a predictable DEK.

For at least one model of the HGST Ultrastar, it uses what it calls the NDRNG, the "Non-deterministic Random Number Generator that is the source of entropy for the DRBG". Is this a requirement in for all SED drives, or might some of them try to generate entropy from more deterministic sources like timing drive head movement?

Newer Self Encrypting Drives (SEDs) generally follow either the TCG OPAL or TCG Enterprise standards.  I've done a lot of digging on this issue and as best I can tell there is no specific method specified in the TCG standards for generating the DEK.

If you review the security policy documents that each manufacture submits to NIST to obtain FIPS 140-2 approval for their product it seems like they all use a DRBG that follows the SP 800-90A standard.  How they seed that DRBG though varies between manufactures.  Some use a NDRNG as you noted with the HGST.  Others like Seagate seem to have a seed that is set at the time of manufacture.  I've also seen some older Seagates that seem to indicate the user can set the DRBG seed with vendor proprietary commands.  The bottom line seems to be that the mechanism used for seeding the DRBG is vendor specific.


Hydra http-post brute force for success I'm having an issue with my syntax to brute force my own account on a server for testing and reporting purposes to protect the rest of the community at hand.

hydra -l username -P /root/Desktop/Test.txt url.zz.za http-post-form "/portal/xlogin/:ed=^USER^&pw=^PASS^:F=Invalid"

I have used "FireForce" plugin for Firefox with a successful result in getting the password from a +-20 or so word list on my Desktop. I however now would like to move to a large wordlist but I am having issues doing this. I have attached screenshots of my Hydra code, my Intercept code as well as my results for a successful login and a failed login. Can someone examine this and provide feedback on this issue?

*Notice: In FireForce where my failed message should be I have to re-reference the URL to the login page in order to pick it up as a failed attempt. It seems that the page redirects itself if it has passed the brute force test. Details on my username/password can be provided personally if need be.

It seems the form that I'm using has unlimited retries and never times out or blocks my requests when using Fireforce or manual testing.

I monitored the responses that Hydra was sending over the network with Wireshark and my syntax was working to begin with. The only issue is that the page even when successfully accessed with the username and password stayed on the same page (302 Redirect for a correct combo) I had then edited my success string to look for "302" rather than "log out" or something the user would see. This means my final answer for this issues is as follows:

hydra -l username -P /root/Desktop/Test.txt url.zz.za http-post-form "/portal/xlogin/:ed=^USER^&pw=^PASS^:S=302"


Are limited length passwords a security risk? I found a webpage where users can be registered. However, it seems that the length of the password must be between 6 to 12 characters.

Is that a security risk?

Yes. Passwords are by nature very prone to be mishandled, and most decisions taken about its management are arbitrary or have more grounds in function than in security. In particular, any measure that trim the possible password space are particularly bad.

One example is ATM PINs. They have only 4 digits (in most cases, at least), so most of their strength relies on the fact that retries are limited. So, for a normal scenario, you have 3 tries to guess a value out of 10000. That means a probability of success of 1/3333. Humans are terrible at randomness, and as a result some PINS are more likely than others: 1111, 1234, and so on. As a result, some banks introduce rules: not repeated numbers (now you have only 5040 possible PINs), not math sequences (1234, 2468... how many of those can you build?), not keyboard patterns (L shaped PIN, a straight line, etc.). After you blacklist so many options, the attacker has now a much smaller search space to guess, and the probabilities are more favorable for them.

For a more open environment (higher capabilities for the attacker), there are lower limits that make sense, since a dictionary attack is almost trivial for short passwords. Some would say 8, some would say 10, but nobody would say 6 is reasonable. If the passwords are hashed (and salted), it comes a point where longer passwords have no increase in security, but it makes little sense to put a limit on them.


Can iPhone get malware plugged into life fitness cardio machine? Plugging in iPhone allows the screen to play media from my phone so it must be getting access. Also wondering if I should be concerned plugging into car entertainment systems.

Based on my research, it seems like anything can have malware installed...

As you realized yourself there is some kind of data exchange between these devices. While the exact nature of this data exchange is unknown it would not be the first time if bugs in the interpretation of received data resulted in exploits since commonly the applications don't expect malformed data. In summary: communication path is there and all the attacker needs now is to find an exploit which works over this path.


What does this forever loading behavior tell us? I have a form with just username and password fields. Now as usual I entered this " or 1=1 -- query in username field and just gave a random password. And then the page kept loading forever until This site can't be reached error popped up.

note: This pic is random pic from google images.

Now why I ask this question is I have seen this behavior pretty often (or at least in quite a few website which I have tried to pen test). While the page kept loading on new tab the website was working as normal unlike this page.

What is the reason for this 'forever loading'? Is it because it is trying to print the database or something else? And what does this mean? (Is website vulnerable to this attack?)

sorry if this question has been asked(I didn't do much research)

Your request could automatically be getting rejected and the connection being dropped- since the data in the form was identified as being malicious by some network traffic monitoring utility (for example, a web application firewall).

Also, if you were given permission to pen test the target you should also be able to work with the owner of the website to investigate the error from their perspective.

(Copied from my comment made on the original question)


Best practices with respect to hard drive reconstruction I would like to be able to store encrypted information on my computer, that no one else is able to read without the right password, even if they have complete access to the computer.

There are of course many programs that claim to (/are claimed to) achieve this. And of course, they probably achieve this within their narrowly defined scopes.

Question: once I have decrypted an encrypted file, how do I make sure that the information is not written in plain text to hard drive somewhere?

(it seems this could happen for several reasons, for example in memory/hard drive swapping, or by human error)

If I understand correctly, hard drive content can be recovered even after several rewrites.

Related question: can one safely assume that information stored in RAM cannot be recovered once overwritten?

Related question: what other similar traps might one fall into when trying to use encryption software?

I use Ubuntu, but ideally I am looking for principles that will avoid stupid mistakes.

Question: once I have decrypted an encrypted file, how do I make sure that the information is not written in plain text to hard drive somewhere?

You use full disk encryption, so that no matter where it is written, it will be written encrypted. This includes swap and all user writeable spaces - excluding only a small boot partition that is not encrypted.

If you do not encrypt the whole disk, you have the risk of remapping sectors leaving unencrypted data around, or that it's written to the wrong location. Encryption does not provide enough overhead to negate the benefits of it.

  Related question: can one safely assume that information stored in RAM
  cannot be recovered once overwritten?

Yes, that's an safe assumption. Also it's fairly irretrievable once the computer has been powered off for >minutes.

  Related question: what other similar traps might one fall into when
  trying to use encryption software?

Leaking key material, leaking cleartext, leaking passphrases, backdoors and similar. It depends a lot on what crypto system. If you use encrypted e-mail it's fairly easy to secure against an attacker having access to only the ciphertext. It's a lot harder to secure against an attacker on your own computer.


How can you become a competent web application security expert without breaking the law? This question was asked here on Programmers Exchange, but it was suggested I ask here as well since most of the experts would likely hang out on IT Security exchange instead.

I find this to be equivalent to undercover police officers who join a gang, do drugs and break the law as a last resort in order to enforce it. To be a competent security expert, I feel hacking has to be a constant hands-on effort. Yet, that requires finding exploits, testing them on live applications, and being able to demonstrate those exploits with confidence. For those that consider themselves "experts" in Web application security, what did you do to learn the art without actually breaking the law? Or, is this the gray area that nobody likes to talk about because you have to bend the law to its limits?

I don't work as a security consultant but I've worked with them (and with the police incidentally and your analogy is more cop show than reality) and none of them to my knowledge have spent time hacking illegally.

Hacking is only illegal if you don't have permission but there is no difference on a technical level (that is to say in terms of security) between a server you've got permission to hack and one you haven't. If you're working for or with a company then attempting to access their servers (with their prior written understanding and permission) is fine and no less real world experience than picking a random system.

Failing that there is no reason you can't set up your own hosted servers and attempt to compromise them - or buddy up, two of you each set up a server and the winner is the first one to find an exploit in the others system. That has the dual advantage of seeing it from both sides.


From when does the operating systems sign the updates? Which was the year the linux distributions, windows have first used to sign their updates? Historical question that is hard to "google".

For apt package manager

  In recent releases, Debian has been using strong crypto to
  validate downloaded packages. This is commonly called
  "secure apt" (or "apt-secure") and was implemented in Apt
  version 0.6 in 2003, which Debian migrated to in 2005.

Although work for the underlying dpkg-verify had started since 2000.

From rpm change log, rpm seems to support PGP, presumably for code signing, since at least version 2.0, which was released around 1996.

Windows is a bit difficult to research. There are evidence that Windows 98 had support for signed hotfixes:

  Installing Windows 98 and Windows 98 Second Edition Hotfixes

  ... To install a Windows 98 and Windows 98 Second Edition
  hotfix on a single computer, run the self-extracting installer.
  This installer performs the following actions:

  Unpacks the files that are needed for installation into a
  temporary folder. Typically, these files include:

  ...
  A digital signature file (.cat) used to digitally sign
  the hotfix binary files (in most situations).
  ...

However, I'm not quite sure what Microsoft means by "in most situation", perhaps it doesn't always require hotfix packages to be signed?


How to prevent serious browser hijackers like this? I am using Chrome and experiencing serious hijackers problems.

After finish loading a website, the hijackers adds a full-screen transparent trap.
When I clicked on it, it pops a new tab containing one of the following URLs:
https://secure-finder.com/landing/landing-3.php
http://cpmofferconvert.com/out?zoneId=779130&htatb=1
http://exeguard.com/
http://www.tradeadexchange.com/a/display.php?r=1097336
http://92.241.171.68/r?key=1bd32a5dda458f94ce1929b6adc36365586166ce&q=error&id=3680445500
http://go.oclasrv.com/afu.php?zoneid=471151
http://www.smartnewtab.com/watch?key=0cdb16b7667982280fbb05007a35eb39

Sometimes, the hijackers add hyperlinks to words like this:

stackexchange

And the most annoying thing is that the hijackers hijack Google Search result page' s search bar.
The code is here: http://pastebin.com/Pcwe1Uts.

What I did are just surfing Net and testing softwares with Shadow Defender.
How hijackers can possibly infect my computer which is in shadow mode.
What can I do to avoid being hijacked after I restore my computer which has a clean state?

I assume that you have checked in Task Manager for any unexpected applications and terminated them? Assuming Windows 10, also check the Start-up tab of task manager and remove any suspicious entries.

You also need to remove the unwanted addons/extensions that the malware has added to Chrome and you need to reset Chrome's search engine back to a more sensible default.

It is possible that this is enough. However, it is hard to then trust the PC after an infection so a wipe/rebuild may still be wanted.

Alternatively, you could try to restore back to a previous restore point in Windows. Less to reinstall then.

UPDATE: You might need to check whether your BIOS/UEFI has been compromised too. If you clean the machine and the problems come back, this might be the problem. This is rather harder. You can download a dump of your BIOS and upload to VirusTotal or you could try a tool like Milano.

An anti-virus boot disk/usb-drive can also be very helpful when dealing with more persistent malware. It lets you boot from a known clean OS. Just make sure you get a device that can be physically set to read-only before booting from it.


Can a SSL Certificate dictate protocol? I know you can set the protocol/cipher via your web server:

Nginx:

ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers         HIGH:!aNULL:!MD5;

Apache:

SSLProtocol all -SSLv2
SSLCipherSuite HIGH:!aNULL:!MD5

But my question is can a SSL Certificate be created to only work with certain protocols?

And can a certificate be created to only work with certain ciphers?

.. to only work with certain protocols? ..  to only work with certain ciphers?

Certificates are mostly protocol independent.

But there is a slight correlation between certificate and cipher: one part of the cipher specifies the authentication algorithm and the possible algorithms depend on the kind of certificate. This means that you cannot use a RSA certificate with a *_ECDSA_* cipher and no ECDSA certificate with RSA key exchange. There are also ECDH (not ECDHE) and DH (not DHE) ciphers which require specific information in the certificate.  But the choice of symmetric encryption (i.e. AES, RC4...) and the HMAC is independent from the certificate.

Which means the type of certificate limits which ciphers can be used but you cannot restrict the possible ciphers or protocols directly with some information in the certificate.


XSS and Content Security Policy Can XSS be prevented 100% by setting the content security policy as default-src 'self'? Is there any way XSS can happen in that case? One possibility I can think of is injecting user input into one of your scripts dynamically at the server-side, do you agree? Are there any other vulnerabilities you can think of?

CSP in such a configuration should enable the following security measures:

Disable inline scripts
Disable inline styles
Disable all use of dangerous JavaScript functions (e.g. eval)
Force all content to be loaded only from the existing domain. This applies to:

JavaScript
CSS
Fonts (e.g. WOFF)
Ajax (XmlHttpRequest and similar)
WebSockets
Video
Objects (e.g. Flash, Java applets)
SVGs
WebGL assets
Frames
Images
Probably some other things I forgot...

As such, XSS should be possible only in cases where resources on the domain can be controlled by an attacker, as you mentioned.

You can lock CSP down further by setting default-src 'none', then explicitly enabling only content types which you are expecting to use on the site. This helps lower your attack surface further by disabling content types like Flash, Java applets, SVGs, canvas, etc. when you're not using them.

One additional vector you may not have considered is Path-Relative Stylesheet Overrides (PRSSI), otherwise known as Relative Path Overwrite (RPO) vulnerabilities. These work by exploiting URL handling behaviour in some CMS software, whereby path characters appear after a script are taken as parameters (e.g. example.com/wiki/index.php/Something shows the Something page). When a path-relative stylesheet is included (e.g. main.css rather than /main.css) this can be sometimes abused. In our example, because main.css is imported relative to the current path, an inclusion in the example URL above would cause the browser to try to load example.com/wiki/index.php/main.css as a stylesheet. If you can create a wiki page called main.css, this would allow you to control the content of that stylesheet, and potentially load malicious CSS (e.g. with the expression directive). You can do the same thing with path relative JavaScript imports. The fix here is to always reference content by its full canonical path.


Secure way to create encrypted file What is the secure way to encrypt a file with a key? Since it will be a small file, is using AES good enough for this assuming I keep the key in memory? So what I can do is just use AES for encryption/decryption - or am I am missing something?

What improves security is to not persist the key but rather keep it in memory only long enough to use it; then discard it. Use a key management service (KMS), backed by a hardware security module (HSM), to retrieve a key only when you need it. Once you're done with using the key for the immediate operation, you need to discard it from memory. Retrieve it later when necessary by accessing it again through the KMS.

Also, you might want to use a unique key per encrypt operation, sometimes called a data key. This key would itself be encrypted by a higher-level key and the ciphertext of it stored, until decryption is necessary. Using a unique key per encryption operation reduces your exposure in the event that the key is compromised.


How safe are copies of Firefox that are on various Mozilla mirror sites? If I end up downloading a .dmg or .exe (depending on OS) installer from some mirror site, how can I be sure that a virus or trojan or spyware has not been added?

I don't see any mechanism for ensuring that the files are not tampered with.

Mozilla downloads are always signed. On Windows you right-click the downloaded file and go to the "Digital signatures" tab. There you can see the signature (should be "Mozilla Corporation") and whether it is valid. When you try to execute this file after downloading it from the web you will get a warning anyway and you will see the signature there as well.

I'm not sure about the particular steps to do the same on OS X but I know that .dmg files are signed as well and the OS can validate the signature for you.


How do I learn Cryptographic/Mathematical notation I asked a question earlier where it was recommended that I describe my issue using standard cryptography notation.

How do I learn this notation and how to convey my approach?
How can I annotate this notation to indicate implementation specific issues?

Although the wording of the second bullet may seem strange, I do need to describe these real world factors that affect my design:

I'm deploying on Windows Azure and the only secure location for cryptographic material is located within the Certificate Store (uploaded by the management portal).  Only solutions that use x509 certificates are supported.
I need to store private keys of my customers securely on Azure Blob storage.  Since these certificates are browsable by many tech support folk @MSFT, I want to encrypt the data at rest, indirectly using an x509 certificate.
The reason I'm saying indirectly by an x509 certificate is because I may store payloads that are larger than the modulus of the cert, or may want faster performance using a symmetric key.

One approach is to read a good crypto textbook.  I highly recommend Cryptography Engineering by Ferguson, Schneier, and Kohno.  You could follow the notation they use in that book, and that'd be one reasonable way to go.  (You'll learn lots of other practical, useful stuff along the way.)


Why are apps for mobile devices more restrictive than for desktop? Application devlopement for mobile devices is generally more restrictive, i.e. the apps runs in a sandboxed environment, they have many limitations when accessing the filesystem, etc. compared to their desktop counterparts. What is the main reason for this?

I think the comment of @Luc is as giving a direction that merits to be expanded here into an answer.

Consider the following. The hardware to have a 0.5lb mobile device run at 480p resolution etc is quite recent. Consequently it is only recently that those mobile systems you mention in your question exists. Desktop system which have been able to use big/heavy hardware (not mobile) has been around for much longer. The X Windows System for instance being an basis for many so Desktop system has been around since aprox. 1984 a time at which Internet and Networking and Applications have looked quite differently. Without the "high-speed broad-band everything connected" the exposition for attacks and hence the necessity for sandboxing has been different. The novelty of the mobile systems allowed to disregard largerly backwards compatibility issues and facilitated to implement techniques to address today`s risk/security threat situation.

Sticking to the example of X Server (i.e XOrg/XFree86) the need to protect applications from each other was not initially seen as it was rare that you installed untrusted code from less known origins. The number of apps making use of libXOrg or derivates was much smaller and changes was that one could have trusted all Applications that one allows to run on your system. With more and more applications from evermore diverse unknown origins makes this trust model difficult. Unluckily for being able to stick with compatibility (in case of the example of the X Server) the model is still used today. Therefore it is even today possible for one application to keylog the input of other applications in the same XSession, something that maybe not have been considered a threat/risk back then, as few X Applications were known and trusted to be bigger extend. Just as @Luc suggests the catching up is occuring and we see for example that some replacements for X Server, like the famous Wayland is considering models that move into including sandboxing and separation and in general a more modern day trust model.

The historical reasons sketched above (i.e. different threat situation at the time of the creation of mobile vs desktop system) is of course enhanced with potential other reasons and surely not a monocausal thing. The notion that sandboxing techniques will enhance the situation of power the owner/creator of the OS/system relatively to the app creators potential coercing them to comply with the agenda of the former.


Exploit Completed, but no session was created I'm using Metasploit to exploit ms08-067_netapi targeting windows xp sp3. I'm going along with the book Penetration Testing-A Hands-on Introduction to Hacking.

This is how I'm doing it.

use windows/smb/ms08_067_netapi
set RHOST <ip for windows xp>
exploit

I get the message

Exploit Completed, but no session was created

with many payloads that I tried.

I've checked for everything that internet told me could cause this problem like network connection between attacker and target, changing the payload, checking the firewall (disabled) but I get the message every time.

Can someone tell me what this message is and how to overcome it? What am I doing wrong?

The message tells you that probably your exploit has failed. Many exploits are not 100% reliable or your target is patched so this can happen. Not always a message will tell you that your exploit has failed instead you will see this message. But it is also possible that you have configured your payload handler wrong and so the payload code can't connect back.


2-factor authentication - Who am I trusting? I'm confused about the risks of 2-factor authentication.

I'm a developer, who has to do some ops, and considering turning it on for my DigitalOcean and GitHub accounts.  Both offer TOTP(?) and indicate Google Authenticator.  Great.

Then I read some FUD about Google Authenticator and looked for an alternative.  There's Authy and a bunch of others.

Ok, now I'm wondering what level of Trust I'm giving my 2-factor provider.  I've never heard of these alternative companies.

1) I think any authenticator can't access my accounts because they don't have my username/password.  Is that true?  If they are compromised or a bad actor, what is at risk?

2) What are some simple industry best practice TOTP apps?  Is Google Authenticator in the top 3?

A TOTP (Time-based One-Time Password) authenticator app will not have your username and password.  What it will have is a secret token that is used to generate a specific pseudo-random sequence of numbers that changes based on time (typically every 30 seconds).  The app need not even have any network connectivity itself - that is just for backup purposes in case you loose your phone.  It's job is simply to compute, for the current time, what the pseudo-random number should be. The site you are logging into will have the same token stored and associated with your account, and will compute the same pseudo-random value at any given time.  Thus, when you log in, it asks for the current value being displayed by the app.

Who are you trusting?

In general, the answer is 'no one', which is good:

Edit: Of course, you are always trusting that the app you have installed on your phone does what it claims to do, doesn't have nasty security vulnerabilities, etc... You can't ever really trust "no one" when it comes to computing unless you start from scratch (as in sand) and make your own computer hardware yourself ;-)
Google Authenticator only stores the tokens locally on the phone.  If your phone got hacked, somebody would have your TOTP tokens, but other than that, you're fine.
Authy apparently encrypts the tokens locally on your phone using a password you enter, so that they are just storing an encrypted blob for you (see their blog posting on this for details).  That means that even if Authy's servers got hacked, nobody would be able to determine your TOTP tokens unless they guess the password used to encrypt them.
Even if somebody got your TOTP tokens, that only lets them defeat the second factor: it doesn't give them any information about your username/password.

** Best Practice Apps**

As to best practices, here are some thoughts:

This posting favors Authy and seems to give a clear explanation of the problems with Google Authenticator, as well as some info about features that you would want.  In screening a potential candidate, it seems that the list of desirable features would include:

A way to de-authorize a particular device if it gets lost
A way to back up your authentication tokens, in case your phone gets wiped. This backup method should encrypt the tokens locally on the phone with a key/password that the entity doing the backup never gets: otherwise your are trusting them to not give your TOTP tokens to a bad guy.  Again, this is about TOTP tokens and is completely separate from your username and password.
The ablilty to de-authorize one device using another, in case the device is lost/stolen.  This would mean that each device has it's own TOTP tokens (not the same token shared across multiple devices).


Is there any danger in subpages that can be called by url but cannot compile due to missing includes? I have a webpage that basically uses the following structure:

index.php
functions.php
pages/a.php
pages/b.php
...

When I call index.php, the user is prompted to login or is logged in automatically by a session-id. index.php calls pages/a.php etc. when clicks in the navigation are done. index.php includes functions.php, which does all the right-checking-stuff in has_rights(...).

Every pages-file is kind of like this:

if(has_rights(...)) {
    ...
}

Whenever I open $url/pages/a.php on it's own, I get a blank page and an error-message in the log that has_rights is not defined. To the outside, this message is not visible, and there's no obvious way to get the filenames in pages. Also, pages should not be called on their own because of missing header-stuff (CSS, Javascript, ...). Is it a danger and if so, how could that be exploited?

Should every pages-file include functions.php for rights-checking, and check seperately whether it's called on it's own, or is it enough to simply fail compiling and send an empty page to the browser?

It is enough to rely on the compilation error but it makes your webpage more error prone.  For example maybe sometime you will (accidentally) enable php error output and then you will have a information disclosure. You should always make it hard to do mistakes.


Sniff packets then repeating these requests? I'm new to this and have basic understand of security. I was wondering if you could sniff packets from a handheld device (e.g iPhone, iPad, tablet.) and repeat these requests. For example...

John sent a Snapchat and wireshark captured this. Could you repeat that request, so it sends thousands of Snapchat's to john's recipient? Just an example.

Thanks, ben.

While you might capture and resent the captured data it might cause the same result as the original data. For example if you just capture encrypted TLS traffic replaying it will not cause the wanted action because TLS protects against such simple replay attacks. Even if you take an unencrypted HTTP request it might include a one-time token or some other protection so that the receiver will detect a resubmission of a previous request.
In summary: it might work or it might not work, depending on the underlying protocol and on the servers and applications behavior.


The passphrase in gnupg's symmetric vs asymmetric encryption schemes This question is admittedly artificial.  Its purpose is only to help me understand aspects of gnupg that I can't figure out from reading the documentation.

One thing that puzzles me about gnupg is that the passphrase plays qualitatively very different roles in asymmetric and symmetric encryption.

In gnupg's asymmetric encryption scheme, the passphrase is used only to protect the private key.  It is not used for encryption and decryption per se; for that one uses the public and private keys, respectively.  These keys, in turn, are generated by gpg2 itself (i.e. gpg2 ... --gen-key ...), using what appear to be pretty high cryptographic standards.  In particulars, in contrast to the passphrase, these keys are not of the user's invention.

The situation is very different gnupg's symmetric encryption scheme, where the (user-invented) passphrase is used to actually carry out the encryption and decryption.  In contrast to the cryptographic-grade keys that one generates with gpg2 ... --gen-key ..., and uses for asymmetric encryption/decryption, the passphrase used for symmetric encryption/decryption can be any old silly passphrase, like "mysecret".

As I said, I find this difference really confusing.

My question is: what is the most direct way to have gpg2 generate a passphrase for symmetric encryption that is comparable in cryptographic strength to the keys that one would generate using gpg2 ... --gen-key ...?

Here's at least one way to do it: generate a a standard asymmetric encryption keypair using gpg2 ... --gen-key ..., discard the private key, dump the public key of the pair with --armor, and use this as one's passphrase for symmetric encryption.

Does gpg2 support a less convoluted approach?

gpg symmetric encryption creates a random symmetric key and encrypts that key using the passphrase along with a random salt.  The random symmetric key is used to encrypt the file or message.

Here's a simple example:

Create a symmetric encrypted message

gpg --symmetric --armor
Hello there!

-----BEGIN PGP MESSAGE-----

jA0ECQMCMvT60tBO0Hj/0kIBF8YvdNeI61L/GSib25ZU1bkeNLTvkwSMfOFUma9u
YjFN5vKzpv8xclcuUT5huIiDlVyDVwON3tbiflavACeiJg4=
=Nt35
-----END PGP MESSAGE-----

The password is 1234

View the message components

gpg --list-packets

gpg: Go ahead and type your message ...
-----BEGIN PGP MESSAGE-----

jA0ECQMCMvT60tBO0Hj/0kIBF8YvdNeI61L/GSib25ZU1bkeNLTvkwSMfOFUma9u
YjFN5vKzpv8xclcuUT5huIiDlVyDVwON3tbiflavACeiJg4=
=Nt35
-----END PGP MESSAGE-----
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
# off=0 ctb=8c tag=3 hlen=2 plen=13
:symkey enc packet: version 4, cipher 9, s2k 3, hash 2
    salt 32F4FAD2D04ED078, count 65011712 (255)
# off=15 ctb=d2 tag=18 hlen=2 plen=66 new-ctb
:encrypted data packet:
    length: 66
    mdc_method: 2
# off=36 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=1
# off=38 ctb=cb tag=11 hlen=2 plen=19 new-ctb
:literal data packet:
    mode b (62), created 1546881253, name="",
    raw data: 13 bytes

As can be seen through basic inspection of the dissected message, the symmetric passphrase is not used directly to encrypt the plain text nor even the random symmetric key.

Additional information addressing OP comments.

To decrypt the above message

gpg -d

<--- copy and paste the message in the terminal and type in 1234 for the passphrase --->

<--- to exit, press enter and then ctrl-d --->

Result:

-----BEGIN PGP MESSAGE-----

jA0ECQMCMvT60tBO0Hj/0kIBF8YvdNeI61L/GSib25ZU1bkeNLTvkwSMfOFUma9u
YjFN5vKzpv8xclcuUT5huIiDlVyDVwON3tbiflavACeiJg4=
=Nt35
-----END PGP MESSAGE-----gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
Hello there!

Encrypted Symmetric keys using Passphrase and Salt

There is no need for gpg to keep track of anything.  The message itself includes all the needed items for decryption except the passphrase.  The passphrase may not be very good, meaning having low entropy.  However, that's why salts are used.

Salts are non-secret strings that are appended or pre-pended to user passwords/passphrases or the like in order to increase the entropy of the user generated secret.  This may sound like it doesn't work very well; adding a non-secret component to a secret.  But it does work.

For further reading on salts:

Wikipedia Salt(cryptography)


How to secure a public device against abuse? What I mean by public device?

E.g. in Germany we have small stations to charge cars powered by electricity. This stations are small towers with a flap. Behind the flap are plugs to connect the tower with your car.

Process of charging:

To utilize the tower we use a smartphone app. The user can browse through a number of loading towers located in the country. By pushing a single button the flap opens and reveals the plugs.

Security issues:

The problem is that anybody even people 100 miles away can use the app to trigger the flaps. So there may be people who abuse the this service.

How can we secure such a public service against abuse? I thought about one thing:

Allow only 3 actions in e.g. 2 hours

Any other ideas?

Stick a little button on the tower itself, which also has to be pressed in order to open the flap.

Plate #1 from my pending patent application.


PCI-DSS 3 SAQ - uncertain of level We are having a debate internally about which SAQ we need to fill in for PCI - our QSA questionnaire says D (and I tend to agree) but company director says SAQ C from reading the guidelines.

The way we process card data is:

We are a B2B Saas subscription business - we don't sell "goods" but users subscribe to use our service each month
We have a web form hosted on our server
User enters payment details and submits the form
The data gets posted to our server
We then securely transmit that data to an API hosted by our payment processor
We do not actually "store" the card data

The last point is where the confusion lies - whilst we do not store the data as in put it into a database and so on the data does actually reside on our servers (in memory for example) as it is posted from the form.

Does that class as "storing" data (in which case we are SAQ-D) or is that transmitting (hence we are SAQ-C)?

The crux of this seems to come down to the definition of "storing data" and I cannot find a definitive answer!

If you are e-commerce and the user's card data touches your server (in memory or on disk) then you are SAQ-D.

You can reduce your scope to SAQ-A-EP if the payment form on your site does a post directly to the payment processor's API, but if the card data touches your server - even though it isn't stored- you are SAQ-D.

Remember that if you are level 1 or level 2 (based on transaction numbers) your QSA will have to sign this off and their interpretation is the only one that counts.


Is there any open source SDK for implementing a KMIP server? Is there any reputable open source SDK for implementing an OASIS Key Management Interoperability Protocol (KMIP) server?

Came across this old question. If you are still looking for answers, found the following

https://pykmip.readthedocs.io/en/latest/index.html : This one seems to be actively developed.
https://www.ibm.com/developerworks/library/se-kmip4j/index.html : Didn't see much activity here.


Is it expensive for ISPs to store browsing, text and call logs? I couldn't really find this answer anywhere. If an ISP was to record every browsing, call and text we make/send, would it be expensive for them log and store this? Assume an ISP has 4 million devices accessing the internet.

Where I live it's not lawful for an ISP or telecom company to store anything.

This question is highly subjective.

It depends on what you consider expensive.
It also depends on what exactly they are required to log.

If they just log texts, call times, and internet connection logs ... that is relatively trivial.

If they have to record full phone conversations and all internet traffic packets ... it could be come very expensive ... but they would just pass it off as part of the billing for there service.


How can I keep Google from tracking me? I'm using a VPN service (purevpn) and I notice that google knows
my location even when I use noscript and a firefox private window.

Is there something I can do to stop this?

Remark: I'm living in Brazil which official language is Portuguese.

I started a VPN connection using a French server:

I went to http://www.whatismyip.com/ see if the VPN connection is running ok.

Then when I access google it keeps in Portuguese language, how does it know I know portuguese?

Related questions

Is Google spying on all of us?
How does Google track a user?

EDIT

My default search engine is Startpage which is very secure, I would like to know how google track me to prevent other sites to do the same.

In my hands, both Chrome's incognito and Firefox's private browsing still send the HTTP header line HTTP_ACCEPT_LANGUAGE => 'en-US,en;q=0.5' headers, telling all and sundry that I want American English.  I haven't tried all the various plugins you mention, but I would be surprised if any of them block this header.

If you run your own web server, you can see what your browser sends out by a simple CGI script like this:

#!/usr/bin/perl
use CGI;
use Data::Dumper;
my $cgi=new CGI;
print $cgi->header(), $cgi->start_html();
print $cgi->Dump();
print $cgi->pre(Dumper(\%ENV));


Signal: Secure way to transfer images out of encrypted chat? This is about saving images sent through the Signal messaging app. I'm using latest iOS, but answers for Android users also welcome.

I have images created and sent via encrypted chat. I will put them in an encrypted container on my Macbook, but need an unexposed way to transfer them.

They aren't in the global gallery of my iPhone and I don't want them to be, to avoid any situation where they might be synced into iCloud. So I can't use the "Save" contextual menu on the image, and need to avoid iCloud sync and Dropbox.

What is the best path to get these images onto my Macbook without exposing them to a cloud system?

The app has a sharing feature you can use on images, that brings up the global dialog. Is there an obvious app that I can send the images to that will be accessible from macOS?

Thanks, figured this was a need many people would have when using Signal on a phone that otherwise isn't set up for extreme privacy (i.e. never enabling iCloud photo sync at all)

As @MiaoHatola pointed out in a comment, the obvious solution is to use the Signal Desktop Client (Chrome App) which allows you to be signed in and receive messages simultaneously on your phone and laptop.

If you have set up the desktop client as a second device (scanning QR code to set up keys) then you'll be able to see all images sent to your phone from there. When you click on an image, there is a download button and it lets you choose the location, which is ideal as you can send the image directly to an encrypted container.

Note that the other solution employing AirDrop is still needed in several common scenarios:

Desktop client was not been set up yet when images were sent, so AirDrop is needed to retrieve such older content.
Desktop client is undesirable for any reason (shared laptop, insufficiently trusted system etc.)

Using the desktop client has several important benefits:

Target location can be controlled so the file never sits unencrypted on disk.
No need to set up iOS/iCloud to enable AirDrop.
Obviously works with Android/Windows unlike AirDrop which requires a full Apple/macOS/iOS workflow.


Security precautions for beaglebone? I am currently operating a beaglebone as the control PC of a scientific instrument. In order to increase its potential, it is connected to the internet, currently without password, i.e. everyone who knows the IP and the username can directly connect to it and is admin. I know that is bad. What are the steps I can and have to do in order to make it more safe without removing it from the internet? OS is debian for beaglebone.

The default installation of debian for the Beaglebone has a user named 'debian' and password is initially set to 'temppwd'.

The first thing you should do is log in as this user, change the password and set a root password. From a terminal or shell use the passwd command and follow the prompts to change the password.

Next, use the command sudo su to run with root privileges - you'll be prompted to enter the user password - and again use the command passwd to set a password for the root account.

With your passwords changed you should thereafter not log in via the root account unless you're performing actions that require administrative privileges. All services, for example a web or file server, should run from a non-privileged user. You can even create users to run services, to isolate services from one another.

You may also wish to remove the default user account from the sudoers file, which can be done by running the visudo command, deleting the entry for that account and saving the results.


Ad-Banner Rendering Sites Serve with malicious content - how to respond? We've received a random email, which was of-course by the way it looks might be a marketing attempt - however, one always needs for a verification to be done. The email read the following:

  We have identified that the website http://example.com/ is serving up
  malicious content. Attached is our initial report. Please can you
  confirm receipt of this email by directly replying to the sender.

  When we find compromised websites, if we feel it is in the public
  interest, we inform search engine providers, Law Enforcement Agencies
  and our customers of the compromise to enable them to make appropriate
  steps. In some cases, we publish our findings within a reasonable time
  to ensure the general public are aware of any risks presented by the
  compromise.

  We may be able to provide further information on the compromise as and
  when our research identifies it.

  You have received this email because we notify sites by emailing to
  industry recognized email addresses for reporting compromised sites.
  If you have any questions then please feel free to contact us on the
  address used to send this email.

Post this email, we checked up with our Ad-Server for which I came across and inspected the domain which earlier had an open Unvalidated Redirect Vulnerability but was a business use-case and was needed at production system. The URL looks like below:

hxxp://banners.xxx.com/www/content/afr.php?zoneid=737&target=_blank&cb=1708201502

Although a Unvalidated Redirect could be used to redirect users to malicious sites but I am aware our internal servers are not sending any malicious code (we verified this from internal security inspection of all consistent & active code at production Ad-Server). It's hence sending no malicious content from insider organization servers to any external entities.

My question is, why all the Ad-severing servers are termed as CnC in most reports like they claimed in this below report and how do we respond?

Can we otherwise deploy a known tool to detect if there are any certainty on our Ad-Server for the results delivered in end-reports or treat it as a complete marketing agenda since with manual inspection, we looked down to header level & packet level data which shows false positive.

My question is, why all the Ad-severing servers are termed as CnC in most reports like they claimed in this below report and how do we respond?

Because the way advertisement is done today on the internet make it easy to use ads to serve malware or do social attacks. There is already the term Malvertisement for malware delivery through advertisements and as far as I know all of the major advertising networks were affected already. If you search for malvertisement you will find lots of examples, reports that it is rapidly increasing and that is even used in micro-targeted attacks.

Unfortunately there is no sure way to find out if a place you offer for advertisement will serve malware. The process of including the advertisement is very dynamic and lots of parties are involved and real time bidding makes it easy to include the malvertisement only at specific times, for specific browsers, specific source IP address or similar. This way it is impossible to find out with random inspection if there will be malvertisement or not.

Part of these malvertisement attacks are compromised ad-servers, like the one from Yahoo in 2014, OpenX several times or MadAdsMedia 2015.


Why not use larger cipher keys? RSA Security commonly uses keys of sizes 1024-bit, 2048-bit or even 3072-bit.  And most Symmetric algorithms only between 112-bit and 256-bit.  I do realize that the current keys are secure enough for today's hardware, but as computers get faster, should we not consider an insanely large key size like a million bits or so to protect ourselves against super computer systems that has not been invented yet?

So in other words what is the consequences of choosing a cipher key that is too large and why does everyone restrict their key sizes?

I dug out my copy of Applied Cryptography to answer this concerning symmetric crypto, 256 is plenty and probably will be for a long long time. Schneier explains;

Longer key lengths are better, but only up to a point. AES will have 128-bit, 192-bit, and 256-bit key lengths. This is far longer than needed for the foreseeable future. In fact, we cannot even imagine a world where 256-bit brute force searches are possible. It requires some fundamental breakthroughs in physics and our understanding of the universe.
One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)
Given that k = 1.38 × 10−16 erg/K, and that the ambient temperature of the universe is 3.2 Kelvin, an ideal computer running at 3.2 K would consume 4.4 × 10−16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.
Now, the annual energy output of our sun is about 1.21 × 1041 ergs. This is enough to power about 2.7 × 1056 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2192. Of course, it wouldn't have the energy left over to perform any useful calculations with this counter.
But that's just one star, and a measly one at that. A typical supernova releases something like 1051 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.
These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

The boldness is my own addition.
Remark: Note that this example assumes that there is a 'perfect' encryption algorithm. If you can exploit weaknesses in the algorithm, the key space might shrink and you'd end up with effectively less bits of your key.
It also assumes that the key generation is perfect - yielding 1 bit of entropy per bit of key. This is often difficult to achieve in a computational setting. An imperfect generation mechanism might yield 170 bits of entropy for a 256 bit key. In this case, if the key generation mechanism is known, the size of the brute-force space is reduced to 170 bits.
Assuming quantum computers are feasible, however, any RSA key will be broken using Shor's algorithm. (See https://security.stackexchange.com/a/37638/18064)


How do DoS/DDoS work? In the last days one could frequently read about attacks from anonymous and LulzSec against different platforms like Sony or HBGary etc. Yesterday for example they DDoS'ed soca.gov.uk and jhw.gov.cn. My question is: How did this work?

Since the PSN is a big network with a lot of traffic in common I'm wondering how much power their attacks must have. Do they just use their own machines and servers? Why can't anybody know who they are, the packets have to come from somewhere? Or did they first conquer a lot of public machines (of people that are not involved in these organizations having any kind of malware on their PC's) and let these machines do they job?

And what about the attacks itself? Is it always the same, something like ping floods, or is it depending on the target itself, searching for very expensive reactions on the target machines?

Can anyone please explain these techniques to someone never involved in DoS/DDoS?

Thanks in advance!

Disclaimer: I don't want to DoS/DDoS anything, but I want to understand how Anonymous or LulzSec or anyone else does it and get an idea of their power.

Anonymous tries to talk people into supporting their DDoS actions by installing a tool on their computer. It has a botnet-mode which allows the leaders to define the target for all the drowns. In other words: Anonymous uses social engineering instead of technical vulnerabilities to distribute their botnet client.

This tool just generates a lot of direct requests, so the IP-addresses will show up in the log files of the target. There has been a considerable number of arrests of people taking part in the attacks in a couple of countries in Europe according to media reports: e. g. England, Spain, France, Netherlands, Turkey. This is noteworthy because arrests normally get very little media attention in Europe compared to the USA.

In general there are roughly two types of DOS vulnerabilities:

The network connection or firewall may be too small to handle the number of packets
The application may require too many resources to handle specific requests.

Simple flooding

The first type is exploited by sending too much data for example using a botnet. Sometimes IP spoofing is used to send small requests to a large number of innocent third parties which will send a larger answer back. A commonly used example are DNS queries.

DoS vulnerabilities

The second type is more sophisticated. It exploits specific weaknesses.

On the network layer for example the attacker may send a huge number of "requests to establish a connection" (TCP SYN Flood), but never completing the handshake. This causes the target to allocate a lot of memory to stores those connections in preparation. Using SYN cookies is a countermeasure.

On the application layer there are usually some operations that take much more resources than average. For example web-servers are optimized to serve static content and they can do this really fast for many people. But a website may have a search function which is pretty slow compared to static pages. This is perfectly fine if only a few people use the search function from time to time. But an attacker can especially target it.

Another operation that is usually pretty slow are logins because they require a number of database operations: Counting the number of recently failed logins from the same ip-address, counting the number of recently failed logins for the username,  validating username and password, checking account ban status.

As countermeasure the application may support a heavy-load mode, which disables resource intensive operations. A famous example of this was Wikipedia in the early days, although the high load was caused by normal users because of it's sudden popularity.

PS: Please note that both of your examples, Sony and HBGary, suffered the most damage from targeted attacks, not flooding. It is unclear if those attacks have been done by the core anonymous group.

  I want to understand how Anonymous or LulzSec or anyone else does it and get an idea of their power.

I think their real power is based on fear.

In the German state Niedersachsen anonymous access to government websites is blocked now. According to the law it shall be possible to use online services anonymously. But the law goes on saying "as far as it is technical possible and feasible". The government claims that their desire to protect themselves is more important, pointing out that there is no right for citizen to demand access to the internet services of the state. (Source: Heise, German)


How is the WordPress nonce generated? I'm trying to reproduce the wordpress "nonce" parameter. How is it generated? How is it related to the cookies?

From codex.wordpress.com:

  Nonces are generated using a key and salt that are unique to your site
  if you have installed WordPress correctly. NONCE_KEY and NONCE_SALT
  are defined in your wp-config.php file, and the file contains comments
  that provide more information.

And so this I get out (default-constants.php):

function wp_cookie_constants() {
    /**
     * Used to guarantee unique hash cookies
     *
     * @since 1.5.0
     */
    if ( !defined( 'COOKIEHASH' ) ) {
        $siteurl = get_site_option( 'siteurl' );
        if ( $siteurl )
            define( 'COOKIEHASH', md5( $siteurl ) );
        else
            define( 'COOKIEHASH', '' );
    }

    /**
     * @since 2.0.0
     */
    if ( !defined('USER_COOKIE') )
        define('USER_COOKIE', 'wordpressuser_' . COOKIEHASH);

    /**
     * @since 2.0.0
     */
    if ( !defined('PASS_COOKIE') )
        define('PASS_COOKIE', 'wordpresspass_' . COOKIEHASH);

    /**
     * @since 2.5.0
     */
    if ( !defined('AUTH_COOKIE') )
        define('AUTH_COOKIE', 'wordpress_' . COOKIEHASH);

    /**
     * @since 2.6.0
     */
    if ( !defined('SECURE_AUTH_COOKIE') )
        define('SECURE_AUTH_COOKIE', 'wordpress_sec_' . COOKIEHASH);

    /**
     * @since 2.6.0
     */
    if ( !defined('LOGGED_IN_COOKIE') )
        define('LOGGED_IN_COOKIE', 'wordpress_logged_in_' . COOKIEHASH);

    /**
     * @since 2.3.0
     */
    if ( !defined('TEST_COOKIE') )
        define('TEST_COOKIE', 'wordpress_test_cookie');

    /**
     * @since 1.2.0
     */
    if ( !defined('COOKIEPATH') )
        define('COOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('home') . '/' ) );

    /**
     * @since 1.5.0
     */
    if ( !defined('SITECOOKIEPATH') )
        define('SITECOOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('siteurl') . '/' ) );

    /**
     * @since 2.6.0
     */
    if ( !defined('ADMIN_COOKIE_PATH') )
        define( 'ADMIN_COOKIE_PATH', SITECOOKIEPATH . 'wp-admin' );

    /**
     * @since 2.6.0
     */
    if ( !defined('PLUGINS_COOKIE_PATH') )
        define( 'PLUGINS_COOKIE_PATH', preg_replace('|https?://[^/]+|i', '', WP_PLUGIN_URL)  );

    /**
     * @since 2.0.0
     */
    if ( !defined('COOKIE_DOMAIN') )
        define('COOKIE_DOMAIN', false);
}

To find out, look at the WP source code.

Nonces are generated by the wp_create_nonce function in pluggable.php. The real deal is this:

substr( wp_hash( $i . '|' . $action . '|' . $uid . '|' . $token, 'nonce' ), -12, 10 )

Where:

$i is a form of timestamp (it increases by one at a fixed time interval, and a nonce has a lifetime of two such intervals).
$action specifies what action the nonce is for (defaults to -1).
$uid is the user ID (special rules apply if the user is logged out).
$token is the session ID for the current session.

Taking a closer look at the wp_hash function (located in the same file), we find this:

function wp_hash( $data, $scheme = 'auth' ) {
    $salt = wp_salt( $scheme );
    return hash_hmac( 'md5', $data, $salt );
}

So it's a MD5 HMAC. The hash_hmac function is a PHP core function. The variable that for some reason is called $salt is the HMAC key.

So what is the $salt? Clearly it's dependent on $scheme that is "nonce" in our case. For more info, take a look at the wp_salt function. In the comments, you'll find this:

  Salts are created using secret keys. Secret keys are located in two places: in the database and in the wp-config.php file. The secret key in the database is randomly generated and will be appended to the secret keys in wp-config.php.

For more details on exactly where it reads the keys, see the actual code. As far as I can tell, it's completely unrelated to any cookies.

TL;DR: The nonce is a MD5 HMAC of a timestamp, the action, the user id and the session id, keyed with a secrets stored in wp-config.php and the database.


What are some potential attacks that could be done to a website that doesn't manage url-encoding properly? A month or so ago I was in the middle of one of my "Distributed Applications" classes and the professor was explaining us how to """properly""" authenticate users in a server.

To demonstrate how to prevent users from accessing all files under a given directory (i.e. with name "private"), the professor showed us some JSP code that was something like the following pseudocode:

String URI = uri.getRequest();
if (URI.contains("/private/") {
  if (userIsAuthenticated()) grantAccess();
  else redirectToLogInPage();
 }

Of course, I realized what was wrong there, and what could be a security flaw. If an user requests for an URL such as mysite.com/private%2Fmypage then URI wouldn't contain the literal string "/private/" so the user would be granted access.

Yesterday I remembered that class, so as I was curious about it, I indeed found out that not only all my previous web projects in Uni actually had this vulnerability, but even some websites of serious companies also have this issue. You can access to a lot of pages where you should not be able to (basically user profile pages when you haven't logged in), just by percent encoding some character in the URL.

So, as I've realized that there are a lot of people not caring too much about this issue I'm a bit confused. Isn't it a big flaw? What could be some attacks that could be done taking advantage of this issue? I'd just like to know, from a theoretical point of view if possible, how bad could get this issue for a site that does not manage url-encoding properly.

P.S: I know that a plausible solution could be to also check if requested URL is percent-encoded and denying access to it. Or even if we'd like to go further and implement a more secure solution we could use a Key Distributed Center such as Kerberos. However I don't understand why you can find serious websites with this flaw and it doesn't seem soo much of a big deal to them.

What you want to achieve is to enforce some security to /private/ and otherwise serve content freely. Login page shall be outside private.

Servers who handle path based security know how to handle the escapes. What they look for is to bring both the path and the pattern to a "canonical" form. This way, they make sure that they compare slash with slash and not with it's URL escape.

Usually declarative security beats programmed security. This implies that testing path is done in a single place, outside the application, in a 3rd party library written with security in mind. Odds are that the ones who wrote the library were aware about the fact that an URL may contain escapes. Another advantage of declarative security is that it doesn't clutter the code so much. We will not have things like:

delete_entry() {
if (rights.check("delete"))
   actually_delete();
 else {
   log_failed_attempt();
   throw new SecurityException("Not allowed to delete, the attempt has been logged.");
 }
}

A distracted programmer may forget the check for one single action. Rather, have an annotation system of "actions" that will be checked by a caller. If the security handler is missing, fail the call at runtime, this means the programmer has forgotten to "secure" the routine. "The free for all" functions shall have a @freeForAll annotation.

In your case, the server must enforce that /private/ is only served if the visitors have a specific token, which they cannot manufacture themselves. For example, it would be wrong to check for a cookie with the content "authenticated:true", as the clients may generate such cookie without visiting the login.