Why wouldn't you institute Strict-Transport-Security headers? I read recently that HSTS can cause problems with site access. Under what circumstances might that happen and what are safe HSTS settings to implement on my web server?

I read recently that HSTS can cause problems with site access.

Yes, HSTS can lock visitors out.

Note that a misconfiguration of HSTS is less likely and serious than for HTTP Pulic Key Pinning (HPKP), which it's often confused with. HPKP can be tricky to implement because it requires you to work with public keys, whereas setting up HSTS is quite straightforward.

To recap, what the HSTS header does is to instruct clients (browsers) that they may only access your site over HTTPS in the future (for a specified time) and not attempt any plain HTTP connection.

In these situations you should be careful with HSTS:

You don't know how long you will support HTTPS in the future. If you send a HSTS header with a high max-age and switch back to HTTP during that time, you risk locking out previous visitors. That's because if their browser has seen the header earlier, it will block all attempts of a plain HTTP connection until expiry.
You need to maintain some plain HTTP access, particularly on subdomains. Here you should make sure you don't set the header's includeSubDomains flag. Otherwise, you deny HTTP access for all subdomains as well.


Double Submit Cookie Implementation questions I have read up on the Double Submit Cookies vulnerabilities question and while it answers a bunch of questions I am still a bit confused.

I have taken a look at this repo: https://github.com/jeongl/express-jwt-csrf-auth

The summary of this implementation is that on the authenticated request they send a  CSRF token in cookie1 and a JWT token (which includes the CSRF token) in cookie2.

The client then takes the csrf token out of cookie1 and stores it locally (assumed) and makes a request with an x-csrf-token header with the csrf token.

The server then decodes the JWT token and extracts the csrf token from the original response and compares it against the x-csrf-token header.

My question is that if an attacker gets access to the cookies can they not extract the csrf token from the cookie1 and send the request with a x-csrf-token header in a form request along with cookie2.

CSRF protections are there to protect you from attackers making the browser automatically do things on your behalf. In this instance, the client has to include the request header manually (presumably through JavaScript). A normal browser request via form POST or linked GET will never include this header, so a CSRF attack cannot take place.

That's all this protects against. You're screwed if the attacker has a way to steal the cookies because they can just impersonate the user and do whatever they want. Or put another way, you also need to find a way to protect the cookies from being stolen.


JWT: In a server-to-server request, should I sign the entire request body? Let's set the scene with two servers:

an "auth" server which provides users with authorization tokens containing claims relevant to their account
a "paywall" server, which after receiving payment from a user, will send a request to the auth server to add the "premium" claim to the user's account (and also this server can serve out restricted content to users who have the claim)

Both servers have access to a shared secret key, so the paywall server can verify the user's claim to view restricted content.

I want to verify that any claim-altering-requests which the auth server receives are actually coming from my trusted paywall server.

My thinking is that the paywall server should simply sign every claim-altering-request in its entirety within a JSON Web Token, such that the auth server can verify the identity of the sender, and also verify that none of the requests have been tampered with.

In this case, it seems like the entire request body would simply be one big JSON Web Token (instead of a mere Authorization header) because I can't trust any data which isn't signed within the JWT.

Does this reasoning make sense, or is this overkill? is my solution redundant? perhaps HTTPS can already effectively solve this problem? I think of HTTPS as a means to secure the communications between two points, however, this might not guarantee the identity of either end?

after some research and discussion about this question, i think found the answer to move on

i've moved from symmetric (HS256) json-web-tokens to asymmetric (RS256)

now each server has its own private key, and they share each other's public keys
this means neither server can impersonate the other
this is a superior architecture for microservices, because now a third-party (untrusted) microservice can participate in the network

next, should we place the entire request body into a JWT?

sure, this will work and be secure
however, it's technically overkill — we could just use the underlying crypto to sign the whole request body, and then attach the signature as a header — which would be nicer, because then the request body isn't obfuscated as base64, which would be convenient
for my use-case i will explore the idea of attaching a signature as a header, however if it feels shaky and like i'm rolling-my-own, i might just stick to only using JWT and wrapping the entire request that way as a token, which lessens the number of ways that i'm using crypto altogether in the system, so it's a trade-off


Trusted CA SSL certificates and embedded devices There is an embedded device which should connect to the server over HTTPS and MQTTS. A server certificate is issued by a trusted CA (for example, Let's Encrypt). But there is a problem with server certificate verification on the client side because the device doesn't know about trusted CA's.

So I have a few options:

Put a DST Root CA X3 root certificate (LE root cert) into the device and check against it;
Make a self-signed root certificate and put it into the device;
Public key pinning.

The first approach doesn't work because the DST Root CA X3 will expire next year. Furthermore, Let's encrypt may change their root certificate at any time and we can't guarantee that newly issued certificates will be signed by the same one.

The second way makes my HTTPS server not trusted for other clients like web browsers.

What about using multiple certificates at the same time? Is it possible? If I'm not mistaken Nginx server supports it, but I'm not sure it works in the way I guess: if the first certificate (e.g. Let's Encrypt) verification fails a server would give a fallback certificate (e.g. self-signed) to the client. Even if so not all servers support this.

The third way is to put my server public key hash into the firmware. In this case I can use any CA in future (am I right?). The only thing I should be careful about is always using the same keys when generating CSR.

Which way is better? Or are there any other solutions for my problem?

It actually does not matter for the question if the trust anchor is a publicly trust root CA, a locally trusted root CA or a locally trusted server certificate. What matters instead how to deal with the situation when the trust anchor should not be trusted anymore.

A simple approach would be to have a trust anchor which is valid forever. This is the way you are trying to go and it could be implemented the following way: let an arbitrary public CA issue and later renew the server certificates but use the same fixed key pair for each of the server certificates. Then pin to the servers fixed public key in your device. This way the device will be happy with verification since it only checks the expected public key. Browsers will be happy too since the certificate was issued by a CA they trust.

Only, what happens if the servers key gets compromised? This is a similar situation you face if your trust is based on a public root CA and the CA expired. In both cases your trust anchor should no longer be trusted. Thus you need to somehow switch to a new trust anchor.

If you've pinned against the servers key you might have an alternative key pre-created and put into the device which is used in case first key was compromised. On certificate verification you then check against this alternative key if verification fails with the primary key. If this succeeds you know that the primary key is considered obsolete and should never be used again for verification. You could also have multiple alternative keys so that you could obsolete more keys over time.

Still, no key should be trusted forever since with the time the chance increases that the key got compromised or got too weak. So you very likely need to have some way to update the software in your device. This is usually needed for bug fixes anyway but could also be used to bring new trust anchors to the device, no matter if these trust anchors are new trusted root CA's or trusted server keys.


Why do browsers allow JavaScript of external web pages to connect to localhost? I am reading http://blog.saynotolinux.com/blog/2016/08/15/jetbrains-ide-remote-code-execution-and-local-file-disclosure-vulnerability-analysis/

In that article a (now patched) vulnerability is described, in which a desktop program listens to HTTP requests from localhost. That server essentially trusts its input and it can be used to compromise the system.

All that is needed is a malicious web page with JavaScript that opens a HTTP POST to 127.0.0.1:63342 with some data.

So, why do browsers allow JavaScript of remote pages to connect to localhost? Local web servers are used for a lot of things (test servers, Jupyter noteboos etc.).

EDIT: When I was playing around, I got this error (No
'Access-Control-Allow-Origin' header is present on the requested
resource). It looks like this should have prevented the attack in the blog post as well?

Well, localhost itself is just a hostname, other hostnames could be used similarly be setting up an A record for 127.0.0.1. The real potential problem is that browsers can be manipulated to load content from the local network, like 127.0.0.1 (localhost), 192.168.1.1 (routers), etc.

Browsers do have a feature in place to globally limit such access across hosts, called Same-Origin Policy, however CSRF attacks against poorly designed systems are still possible.

Assuming the application developers are competent enough to not blindly assume data being sent is safe, and validate it properly, they should be fine. The real problem is developers failing to understand such basic web security are all too common. For this reason we have recently seen a surge in attacks against people's routers, where CSRF attacks can reconfigure the router without any user interaction, because it blindly assumes any local traffic is safe.

As for out-right blocking local network requests from non-local pages in the browser, I'm not aware of any browsers presently doing this, but it is something NoScript's ABE feature does by default. I've never noticed any real downsides to using it, so I can't really speculate on why browsers do not already do this.


Are short messages hashed with a HMAC insecure? Imagine I were to provide a person with a single letter "A" and the HMAC-SHA256 hash of this message, keyed with my secret key.

Would this person be able to derive any information about my secret key? Furthermore, would this person have a way of being able to forge a valid HMAC for a similar message (e.g. the letter "B")?

No, they would not be.
At least, to this date[Feb. 2020], there are no known vulnerabilities relating to short messages with sufficiently sized keys. If this is all you cared about, feel free to stop reading here. The rest of the answer just go into details as to why it's not a problem.

According to RFC 2104, a HMAC is defined as follows:

As you can see, the key is XOR'd with a known constant, then concatenated with the message. This data is hashed, then concatenated to other data and finally hashed again. If the message m were just all zero's, it would still not give you any information about the key.
This can be demonstrated by a simpler construct, where all that happens is that the key itself is being hashed. One would not have any information about the key, and the best way of recovering it is brute force.


Requesting webpage as DOS Is it possible to launch a DOS by repeatedly requesting a webpage (refreshing)? Like holding down F5 on your browser?

If the page you are refreshing is sufficiently resource intensive. In most cases it will not result in a denial of service as the latency in the network connection far exceeds the page load/cpu time. If you found a page that did significant background work, such as creating a database backup you could in theory repeatedly refresh the page and consume all available CPU/memory/etc.


Metasploit: Executables are not working after Reverse Shell I tried connecting to a windows box and create a reverse shell back to my Kali Linux machine. Reverse shell is created and I get the meterpreter prompt. Commands Used:

Payload: windows/shell/reverse_tcp
Encryption: x86/shikata_ga_nai
Handler: exploit/multi/handler

Once the session is created I'm able to run commands like "pwd", "ls" etc. but not able to run commands like "python" or "nmap.exe". These commands cannot be used even when the corresponding executables are in the same working directory. Trying these commands end in "Unknown Command:"
Will I be able to run these applications using rever shell, or should I use some other payload to achieve this?

Meterpreter session allows you to perform a wide range of post exploitation activities. Those activities are either performed through the built-in commands or through post exploitation modules. Type help on the meterpreter session and you can see all the built-in commands in the stdapi plugin that is loaded by default. If you want to load another plugin, you can use the load <plugin name> command such as load kiwi and it will load the mimikatz plugin of meterpreter.

In other to perform port scan of the target network on which you have got the session, first create a route through the session and then use a module which has the capability to tunnel the traffic through the connected session. e.g.

meterpreter > route add 10.10.1.0 255.255.255.0 1
meterpreter > use auxiliary/scanner/portscan/tcp
meterpreter (tcp) > set RHOSTS 10.10.1.0/24
meterpreter (tcp) > set THREADS 15
meterpreter (tcp) > run

If will scan the target network while route all the traffic through the session ID 1 that is specified in the route command at the end.

Take a look at https://www.sans.org/reading-room/whitepapers/testing/post-exploitation-metasploit-pivot-port-33909 for further details.


Is it acceptable "allowed by default, disallowed for specific data/actions"? A friend told me that in the agile paradigm it is said that users are allowed by default to do anything but then they are blocked or disallowed to access or do certain identified actions. Just the contrary of minimum/least privilege.

That is a complete different paradigm where for a new application you identify what generic users cannot do and implement that security, not the contrary.

The result may be the same: everyone access what is allowed to access, but the implementation is completely different.

In which scenarios is this approach acceptable?
May it be secure?

That is a complete different paradigm where for a new application you
  identify what generic users cannot do and implement that security, not
  the contrary.

That sounds like an awful and insecure paradigm, too! What a huge design and development burden!

The secure paradigm is to block everyone from everything at the start, then add the privileges they need. This is called Security and Privacy By Design and Default.

If you do not know what the user needs to access when you are building something, then sure, you need to give the users access to everything and bar them from what you discover that you don't want them to have access to. Is this a secure method?

Um, no.

Over the past several years, developers have not been shown to be trustworthy in developing security with that paradigm. That's why regulations, design frameworks, and best practice says to not do that.

Could you end up with a secure result by bolting on restrictions after the fact? Sure. Could you do that consistently and reliably over time? History says 'no'.


Preventing unauthorized key-listings I just noticed that anyone who has root access to my computer can list the keys in my keyring. He would not be able to use any of my private keys without knowing the passphrase, but he could

examine the stored public keys and conclude who I communicate with
examine
the private keys and conclude which identities belong to me

I tried to use an EncFS encrypted folder as my .gnupg folder, but the gpa frontend no longer works then.

What is the best way to avoid these issues?

Someone with root access could do any of these things anyways.  You cannot hide from root in unix-like OSes.  They have full control of the kernel, meaning they could, if they like, look at everything on any virtual terminal (ie, anything you type or see), examine any network traffic, examine process spaces - any OS level blocks can be bypassed by them - by patching the kernel, if by no other method.

Do not host your private keys anywhere you do not trust root.  If you do not trust root, you cannot trust the hardware, the OS, the shell, the applications...


Is gmail-to-gmail still insecure? Why? I have always heard that email is an insecure method of communication; I assume this has something to do with the email protocol itself.
But when sending an email from one Gmail account to another, Google has complete control over how the email is transmitted, and Google seems decently concerned about information security. So it seems that they could, if they wanted, turn Gmail-to-Gmail messages into a secure communication channel and that this would probably be in their best interest.
So have they done this? If not, why not? Is Gmail-to-Gmail communication still insecure (for the purpose of, say, sending a credit card or social security number to a trusted recipient)?

Email is historically considered insecure for two reasons:

The SMTP network protocol is unencrypted unless STARTTLS is negotiated, which is effectively optional
The mail messages sit unencrypted on the disk of the source, destination, and any intermediate mail servers

Google mail servers all speak STARTTLS if possible, so for gmail-to-gmail the transmission step shouldn't be a concern.  However, the sending server stores an unencrypted copy of the email in your Sent folder.  The receiving server stores an unencrypted copy in the recipient's Inbox.  This leaves them open to various threats:

Rogue Google employees reading that email
Google choosing to read that email despite their assurances to the contrary
Governments forcing Google to hand over that email
Hackers breaking into Google and accessing that email

If you can trust everything to go right, then gmail-to-gmail is perfectly secure.  But you can't always expect everything to go right.

For these reasons, the security and privacy community long ago reached the stance that only end-to-end email encryption is secure.  That means the email remains encrypted on server disks and is decrypted when you're reading it, and never stored decrypted.

There have been an enormous number of comments, so let me expand/clarify a few things.

End-to-end encryption - in the context of email, when I say end-to-end encryption I mean something like PGP, where the message is encrypted until it reaches the recipient's email client, and only decrypted to be read.  Yes, this means it can't be searched on the server, and often also means it doesn't remain "backed up" on the server either.  This is a case where security and functionality are at odds; pick one.

Security and privacy community - unlike many Information Security topics, email security is one that extends out to other communities.  The question of what stateful inspection in a firewall means is not something often extended out to interest others, for example.  But email security is of direct, significant interest to

Human rights workers
Whistleblowers
Insurgents

Forget about credit card data, there are people trying to communicate with email whose lives, and the lives of their families, depend upon the security of the email.  So as there are phrases in the comments below like "depends upon what your standards are for 'secure'", "sufficiently motivated adversary", "there is an illusion of security at the email-level" - am I being too strong to say the server can't be trusted?  Not for people whose lives are at stake.  That's why the phrase "email is insecure" has been the mantra of the privacy movement for 20 years.

Trusting the server - In the US, "your cap for liability for unauthorized charges on a credit card is $50" so you may well be happy trusting the server with your credit card.  If you're cheating, on the other hand, you might lose a lot more as the result of leaving unencrypted email on the server.  And will your service provider shut their doors to protect your privacy?  Probably not.

STARTTLS - STARTTLS is SSL for email; it uses the same SSL/TLS cryptographic protocol to encrypt email in transit.  However, it is decidedly less secure than HTTPS for several reasons:

STARTTLS is almost always "opportunistic", meaning that if the client asks and the server supports it, they'll encrypt; if either of those things are not true, the email will quietly go through unencrypted.
Self-signed, expired, and otherwise bogus certificates are generally accepted by email senders, so STARTTLS provides confidentiality but almost none of the authentication.  It's relatively trivial to Man-In-The-Middle email if you can get in between servers on the network.


How to securely store users API keys submitted through client I am developing a web application which will require users to provide 3rd party API keys through the client, which will then be used to make requests to the 3rd party API from the backend of my app.
After researching, I believe the best way, and standard practice, is to store these API keys as plain text in my database.
However, my question lies in the security of these keys while they are in the process of being sent from the client to the database.
To further clarify, the 3rd party API keys will be entered by users client-side through a standard HTML form, and upon being submitted, the client will make a post request to my backend, which will in turn store the keys in mongodb.
Would bad actors be able to access these keys via dev tools or some other malicious means while they are in the process of being sent from the client to the backend?
If so, what actions can I take in order to secure them further while they are being sent from client to db?

An API key is basically a password. The usual protections like transport with TLS (i.e. use HTTPS) should therefore be sufficient.


Why local links are disabled by default in modern browsers? I'm having a hard time trying to make my local files accessible to javascript (for opening in a new window) from Chrome, and already found a workaround in Firefox. My question is: why javascript cannot open a file in a new browser window (with window.open) by default? I cannot see any security issues with this.

The only thing I'm reading everywhere on this topic is: "Web sites should not have access to my disk for reading files." But javascript actually can't possibly read the content of the files because of the Same-origin policy. You can test it as below.

For example, in the settings of NoScript you can choose Advanced->Trusted and mark "Allow local links". Now open Firefox console and execute (you should allow pop ups for this):

x = window.open('file:///%some_path_to_text_file%')
x.document

I'm getting 'Error: Permission denied to access property "document" [Learn More]'. So, what's the deal? Is it safe to keep option "Allow local links" in NoScript all the time?

This is a reasonable question to ask, because it's not immediately apparent why merely opening arbitrary file URLs is bad in the same way that reading arbitrary file URLs is bad. Here's the short answer:

  These are the holes caused by letting sites link to local files:

  A1. If the browser or any helper app (e.g. RealPlayer) puts untrusted files
  in a predictable location, any page can link to that file and thus read every
  file on your hard drive.

  A2. Holes in same-origin policy (cross-domain) become
  read-any-file-on-your-hard-drive holes.

  But same-origin holes are already considered serious enough to block releases
  (they let sites steal cookies, passwords, and info on intranet web servers).

  A3. DoS attacks against the browser or even the OS using file:///con/con or
  /dev/stuff.

https://bugzilla.mozilla.org/show_bug.cgi?id=84128#c190

These issues are still relevant today with e.g. the 2017 exploit in Firefox for Android that allowed a malicious website to read files from /sdcard/Download/ (CVE-2017-7759).

  Android intent URLs given to Firefox for Android can be used to navigate from
  HTTP or HTTPS URLs to local "file:" URLs, allowing for the reading of local
  data through a violation of same-origin policy.

https://nvd.nist.gov/vuln/detail/CVE-2017-7759

  Steps to reproduce:

  Visit an remote (http) webpage:

  Actual results:

  The JS code above redirects the user to file: URL.

  The redirection allows remote pages to exfiltrate files in /sdcard/Download/.

https://bugzilla.mozilla.org/show_bug.cgi?id=1356893

The browser security handbook gives a good explanation of the more general rationale:

  In the case of file:, web sites are generally prevented from navigating to
  local resources at all. The three explanations given for this decision are as
  follows:

  Many browsers and browser plugins keep their temporary files and cache data
  in predictable locations on the disk. The attacker could first plant a HTML
  file in one these spots during normal browsing activities, and then attempt
  to open it by invoking a carefully crafted file:/// URL.  As noted
  earlier, many implementations of same-origin policies are eager to bestow
  special privileges on local HTML documents (more), and so this led to
  frequent trouble.
  Users were uncomfortable with random, untrusted sites opening local,
  sensitive files, directories, or applications within  containers,
  even if the web page embedding them technically had no way to read back the
  data - a property that a casual user could not verify.
  Lastly, tags such as


DeAuth all AP's in range In a few days, we are going to be many friends that will gather together and play all night long using 6-7 APs.

How can I DeAuth/Disconnect everyone's connection, without being connected to their network?

Use mdk3 by typing mdk3 --help.

Then look for the selection for deauthing. I think the command is mdk3 wlan0mon -d. I'm not on Kali right now so I'm not sure, but this command should deauth every device within a range regardless of APs. Mdk3 deauths devices by channel.


In NTFS EFS how is the symmetric key (FEK) generated? I have some old backups that are encrypted using windows EFS and I no longer have access to the certificate used to encrypt the FEK symmetric key included in the files but I do have the password, user name and as well large portion of the actual binaries before encryption. I do know that AES used by EFS is not vulnerable to known plain text attack but I was hoping that with the above information I can figure out how windows generated the FEK symmetric key that are used to encrypt the file. Any help would be appreciated. Thanks.

FEK is random
Sorry. (But if it were any different, this would be terrible for EFS.)
Microsoft Corporation, TechNet, How EFS Works:

When you save a file to be encrypted, a random cryptographic generator supplies a unique file encryption key (FEK), which is a fast symmetric key designed for bulk encryption. The FEK encrypts the data in blocks.


New to IRC specifically BitchX, what is the best way to remain anonymous when getting a list of users in a channel I can see all of my personal details. First question is this what everyone else sees, and second how can I make sure my full name is never visible.

I finally answered my own question:

Using *nix in your local directory if the file .bitchxrc does not currently exist then go ahead and create it

touch .bitchxrc

then inside that add your irc commands for these 2 environment variables

/ircname Phrase you would like or name
/ircuser username

save file
relaunch bitchx
type /whois

bam -> you're no longer showing your personal info


How useful are CVE entries? Most of the CVE entries are not supplemented by complete explanation of the bug itself, even a proof-of-concept demonstrating the bug. All they have is some very high-level, abstract description of possible side effect, e.g. CVE-2016-8412 states,

  An elevation of privilege vulnerability in the Qualcomm camera could
  enable a local malicious application to execute arbitrary code within
  the context of the kernel. This issue is rated as High because it
  first requires compromising a privileged process. Product: Android.
  Versions: Kernel-3.10, Kernel-3.18. Android ID: A-31225246.
  References: QC-CR#1071891.

The description is devoid of any useful information, e.g. the vulnerable block of source (because it's Android), relevant analysis, possible patch (optional) etc. Are these sort of CVEs useful at all from the perspective of security research? Do they serve any real purpose apart from possibly being an index of how buggy a software is?

They're useful, they're just not useful for building exploits.   They're not useful for determining how buggy a software is for that matter either...The number of CVEs has no strong correlation with code quality.

What they are useful for, is determining, as an administrator, if the versions of a given software package you're using has been patched for specific known exploits, and the potential impacts of exploits that have been discovered. In this way, they can feed directly into a vulnerability management process as one of the many tools that you can use to ensure that your organization is properly managing software security risk.


Does appending data from a form to a URL with encodeURIComponent safely sanitize user input? In my web app, I want to send a cross-domain AJAX request to another site. I want to take the text that the user enters in a form and append that text to the query string in the URL I send the request to, so I escape the user's text using encodeURIComponent() first, like so:

function sendAJAXRequext(textThatUserEntered) {
  const hopefullyThisStringIsSafe = encodeURIComponent(textThatUserEntered);
  const xhr = new XMLHttpRequest();
  xhr.open('GET', `https://www.example.com/api?query=${hopefullyThisStringIsSafe}`);
  // snip...
  xhr.send();
}

Is using encodeURIComponent() good enough to ensure there aren't any ways to inject something evil into the URL I request, or is there something additional I need to do to sanitize textThatUserEntered?

Yes, encodeURIComponent() is the correct way to safely fill a query parameter with untrusted data.

  The encodeURIComponent() function encodes a URI component.
  This function encodes special characters. In addition, it encodes the following characters: , / ? : @ & = + $ #

(from w3schools)

  is there something additional I need to do to sanitize textThatUserEntered?

No, if you just use it to encode a query parameter value as in your example, you don't have to take additional measures. An attacker will have no way of introducing a new parameter or change the URL in a way that directly creates an XSS vulnerability or similar.

But that does in no way mean that the parameter is safe for processing on the target site. It just means that it's safe for the requesting script. The parameter could still trigger an injection vulnerability on the target server.

Also note that some characters are excluded from escaping (!'()*). That's why Mozilla proposes a wrapper function that also escapes these characters although they don't pose any immediate threat as they don't have an assigned meaning in the query syntax:

function fixedEncodeURIComponent (str) {
  return encodeURIComponent(str).replace(/[!'()*]/g, function(c) {
    return '%' + c.charCodeAt(0).toString(16);
  });
}


Virus (or Trojan) in Android Definition of virus is (from Wikipedia):

  A computer virus is a malware program that, when executed, replicates by inserting copies of itself (possibly modified) into other computer programs, data files, or the boot sector of the hard drive; when this replication succeeds, the affected areas are then said to be "infected"

And the main difference with Trojan is that virus can replicates itself by inserting copies of itself.

Thus, if we assume  that after user installs it, the application does malicious activities without interaction with user in a unrooted Android system:

Should it be classified as virus or as trojan?
When should such malware classified as virus or trojan?
Is it possible to create a virus according to this definition in unrooted Android system?

If the app's malicious payload copies itself to other apps or
documents on the device, it is a virus.
If the app spreads itself to other devices, but does not do so by "infecting" legitimate apps or documents, it is a worm
If the app relies on a human to install it, and then does some nasty stuff besides simply replicating itself, it is a trojan

Since Android apps are signed, it should probably be a little trickier to create a virus (though not a worm or trojan). Of course if the user enables "unknown sources", this won't help.


Detecting malware hidden in P2P traffic Consider a network situation involving  (only) Peer to Peer traffic in medium sized network.

For the sake of convenience, a simple P2P application like DC++ may be assumed, although I am aiming at a broader set involving torrents etc. too.

Peer A does a search for file qwerty.mp3, and then starts pulling the file, in pieces, from different Peers- B, C, D and E.

Now say Mr. C is the one who has shared this file amongst Peers, and he is a malicious peer and the file  contains a malware/trojan etc.

Since the file is being downloaded in pieces from different Peers, it is unlikely that a standard Intrusion Detection system will be able to detect it since most of them involve signature-based detection techniques.
And most likely when the pieces are re-assembled at the system of Mr. A, his anti-virus will flag off a warning about the malicious content.

So, my question:
              At the network level, what approach an admin may take so that innocent peers like A are protected from such situations?

Kindly do not suggest actions or measures relating to the end user. Whatever has to be done, must be done at the network level.

Please note that I am looking at this more from a research point of view and it is perfectly alright to not to point me towards existing techniques used in production environments but share links for research papers and give answers which tell of an open-ended techniques.

Many P2P software will create hashes of each piece to prevent a malicious entity from modifying the pieces in-flight. When your P2P client gets a piece, it verifies it's hash. This will prevent one malicious entity modifying a piece of a valid file, but it won't help you if the file itself (qwerty.mp3) is malicious.

If the file itself is malicious, a simple solution is to just run an anti-virus scan against the final file, and see if there are any problems. This will satisfy your signature/anomaly based detection (depending on what the Anti-virus does)


Is it necessary to understand Linux kernel internals to do binary exploitation? I am second-year CS student, I know C, OOP concepts, x86 architecture, reverse engineering basics, TCP/IP stack and OS concepts, also I love Linux OS.
I have just one question:
Is it a mandatory to learn in depth a Linux kernel and develop some low-level stuff like kernel drivers before I dive into a binary exploitation in ARM? I'm not a total newbie, I've developed some very basic exploits for x86 arch, but I want to build a career in ARM exploitation.
Can I learn it AFTER the ARM binary exploitation and get my first job when I'm really good at binary exploitation without knowing a Linux kernel in REAL depth

Binary exploitation does not require you understand the Linux kernel in depth, unless you are exploiting the kernel itself. You only need to know the basics such as how signal handlers are registered, how syscalls work, and how Linux manages process-specific attributes that can be relevant to exploitation. A solid understanding of Linux is very useful, but this does not mean that you need to understand Linux kernel internals, however. You don't need to grok the kernel's internal API to exploit userspace binaries.
Understanding Linux in general is quite useful though, assuming your exploitation is being done under Linux. For example, understanding SROP (SigReturn-Oriented Programming) exploitation, a ROP-like attack that bypasses NX protections, requires knowing how the sigreturn() syscall works. Likewise an exploit might attack the vDSO, a shared library that the kernel provides to all processes.


How do I minimize the number of passwords leaked when a PC gets compromized? For customer support reasons, we need to store passwords to some of our customers' systems (with their explicit, written permission, of course), as well as, obviously, passwords to some of our own systems. Customer support agents and administrators need to be able to access those passwords.
I am aware that - despite all our efforts to the contrary - it might only be a matter of time before one of the PCs in my company's network gets infected with malware.¹ When that happens, I want to minimize the damage. In particular, I want to minimize the number of passwords that gets leaked.
Classic password managers don't help here. They help against password reuse and other dangers, but they are not designed to mitigate that kind of threat. On the contrary: The customer support guy's PC is compromised, they enter the master password to their password manager and... bang... the bad guys have won the jackpot.
I am looking for a solution to ensure that only as few passwords as possible (ideally, only the passwords actively used during the time period between the PC being compromised and the attack being detected) are leaked.
Obviously, storing the passwords on paper² instead of a password manager would solve this, but I would also like for the solution to be practical (the paper solution won't work if the users are in pandemic-induced home office, for example). Another option might be an online password manager which "rate limits" the number of passwords that can be accessed per hour (and sends out e-mail alerts when too many password are requested).
I don't want to reinvent the wheel, and I'm sure that other companies have the same issue. Is there any "canonical" or at least widely-used and established solution to this issue?

¹ If you google for "percentage of companies having been hacked" or "percentage of companies having been infected with malware", you get various news articles on the first page claiming various two-digit percentage rates. I don't want to get hung up on a particular number, I just want want to illustrate that the risk is real and much, much more likely than "rubber hosing" or something similar.
² To clarify the threat model: I am concerned about hackers on the other side of the world having a "lucky day" (i.e., an employee starting a malicious file which somehow managed to get through all our filters), getting into our network and then seeing what they can harvest before doing their usual ransomware stuff (yes, we do have backups). I am not concerned about targeted and/or physical attacks by state actors (fortunately, we are not important enough, and neither are our customers).

This is exactly the threat that standards such as FIDO and WebAuthn aim to mitigate.  These standards use public key authentication to authenticate with web sites and other services, using a private key that is stored on a device (such as YubiKey).
The private key never leaves the device, so even if the computer is compromised, the attacker is not able to access the private key.
Adoption has been gradual, but a fair number of sites support these standards now.  Some of them are listed at https://www.yubico.com/about/reference-customers/.


Why is finding a strong collision only half the work of a weak collision? Regarding hash collisions, an attacker only has to do half of the work to find a collision when they can control both messages compared to when they are trying to find a weak collision. This can be explained with the birthday paradox.

I understand the birthday paradox, but can't quite see how it relates fully to strong collisions and why it shows they only take half the work of weak collisions. With the birthday paradox, each person already knows their own birthday in advance, so when the first person 'says' their birthday, everyone else can compare that with their own, and so on and so on.

If an attacker is trying to find two message that hash to the same value, the hashes of the newly modified messages aren't already known (unlike people's birthdays), so wouldn't an attacker have to create a load of hashes for one of the messages, store them, and then do the same for the other message and start comparing, how is this quicker than finding a weak collision?

My question is, how would an attacker try and find two messages that hash to the same value, so that it only takes half the work as if they were trying to find a weak collision?

Thanks.

To find a collision, the attacker generates a large number of unique messages and their corresponding hashes.  The attack succeeds when any two hashes match.  This is just like the birthday paradox, which speaks of the probability of any two people having the same birth date.

  it only takes half the work

Careful, 2^128 isn't half of 2^256.  2^128 is the square root of 2^256.  2^128 is one "2^128th" of 2^256.

  the attacker has 2 messages 'place 10$ in my account' and 'place $1000 in my account' and they want them to hash to the same value [...] the attacker would continually keep changing both message until they hash to the same value

In this situation, the attacker is given m1 and m2, and wants to find an x1 and x2 such that H(m1 + x1) = H(m2 + x2).  Let's suppose that H is a 256-bit hash function, like SHA-256.  The attacker tries 2^128 different values for x1, computing and storing 2^128 hashes H(m1 + x1).  The attacker now tries different values for x2, computing hashes H(m2 + x2), looking for one that matches one of the x1 hashes.  Eventually, this will succeed, but after how many attempts?

There are 2^256 possible hash values, so the probability of each attempt succeeding is 2^128/2^256 = 1/2^128.  Therefore, we can expect this step to require about 2^128 attempts.  Adding the two steps together, this attack would require, on average, about 2^128 + 2^128 = 2^129 evaluations of the hash function.

I don't think this usually goes by the name "birthday attack", since the probability math is quite different.  Both attacks do have a similar complexity, however (about a square root of the search space, or 2^(n/2) for an n-bit hash function).


Are OBD-II "Connected Car" products (Automatic Pro, Hum) secure? There is an emerging class of vehicle data devices known as "Connected Car" products. Two examples are Automatic Pro and Hum, which both plug into your car's OBD-II port and are able to log info such as one's location, or even the state of the engine.

The armchair security researcher in me is horrified to see an embedded computing device such as a vehicle ECU, with virtually no security in its design, connected to the Internet. It seems that all one needs to do to cause a major accident is compromise the device and issue any type of malicious "kill" command impacting anything in the vehicle that is controlled by the ECU. Which, in most vehicles made since 1996, is nearly everything.

Are these devices actually safe to use? Are manufacturers taking the potential compromise of these units seriously? In my evaluation, this would mean disabling any way to send data to the OBD-II port, by omitting a pin or whatever else. If these devices are physically unable to send data to the vehicle's computer, I would feel more confident in their safety (absent the obvious issue of being able to spy on your location). Is such a thing even possible given the features they have?

Are these devices actually safe to use?

No. These devices have access to the "low speed CAN bus" and actually send out messages on the CAN-BUS. Anyone compromising your OBD-II device can send out fake messages to trick different ECU's attached to the CAN bus.

  Are manufacturers taking the potential compromise of these units seriously?

Yes, but there are a few issues. Although the big manufacturers understand that there is a potential security risk, there is not much they can do about it, due to  the inherent limitations of the CAN bus protocol.

In order for them to implement security without changing the CAN bus protocol the correct way would be one of the following:

Manufacture each ECU with a AV in the ECU from the beginning (already being done by Karamba Security)
Have another ECU connected to the CAN bus listening and performing DPI (being done by Argus Sec)
Performing statistical analytics on the CAN bus behavior and being able to differentiate between normal activity and abnormal activity (being done by Cycuro)

So you are probably asking yourself, why you are not seeing any of this being implanted?

Manufacturing companies are scared to insert new devices onto the CAN bus without proper mass testing. In order for small companies to prove their product works they need to first test it on a massive amount of cars which is not available to them because the are manufacturers scared. So it's a whole loop.

Although this may be the case, there may also be a way out of this loop, as companies like Xee and Carvoyant are providing testing kits to be given out to drivers by developers. These dev-drivers have their data collected and sent to the developers "server", and at this point the data can be used offline/off-road to perform the necessary tests.

  Is such a thing even possible given the features they have?

As I mentioned above, currently that is not possible, due to the way the ODB-II protocol is set up.

Conclusion:

Manufacturers want to adopt cyber security prevention, but the market is not ready yet (but closer than ever!) and it is all up to you to make sure you secure the OBD-II enviorment with your awareness.

The attack vectors will just grow and attacks have the potential to start getting a little crazy (what about a mechanic's computer being compromised and then used to spread malware to cars through the mechanic's OBD-II device?) and we need to wait and hope for the best from the manufacturers.

You can read more about the OBD-II and CAN bus here - CAN Bus and OBD II Explained For Dummies, with Examples of how CAN Bus and OBD II Work


WPA2 Enterprise Authentication Certificate Security While reading up about WPA2-Enterprise, it states that it is more preferred over WPA2-Personal as it allows authentication via digital certificates which prevents over-the-air attacks.
However, I am unsure of the following implications about this implementation. If WPA2-Enterprise was to be implemented:

Can the authentication cert on machine A be dumped out, installed on machine B and use to authenticate to the network?
If user A uses a domain user account to login to machine A, and connects to the network using an authentication cert. user A also has a local admin account on machine A.
Is it possible for the local admin account to obtain the authentication cert of the domain user account on machine A and install it onto machine B and login using the same domain user account?
Can I issue unique certificates to each machine for authentication or do they have to request one during the authentication process?

Apologies in advance for the weird question, have no previous experience with WPA2-Enterprise at all!

Can the authentication cert on machine A be dumped out, installed on machine B and use to authenticate to the network?

technically, yes.

If machine A was a domain user, but has local admin privileges is the above scenario still possible?

I didn't get the first part: how machine can become a user?

Can I issue unique certificates to each machine for authentication or do they have to request one during the authentication process?

yes.


How well the OpenVPN router defend against mitm I'm not an expert in VPN, so I'm curious about how well does a router with installed vpn defend against an mitm attack. Since ARP Spoofing can decrypt https, I'm concerned if it's able to decrypt a vpn too.

Also will the hacker be able to DOS your internet connection?

Then, what if let's say one of the device using the vpn is compromised? Will the hacker be able to use it to hack the rest of your devices?

I'm not an expert in VPN, so I'm curious about how well does a router
  with installed vpn defend against an mitm attack. Since ARP Spoofing
  can decrypt https, I'm concerned if it's able to decrypt a vpn too.

ARP spoofing cannot decrypt HTTPS traffic. HTTPS 'sits higher' in the network stack and therefore layer 2 cannot 'see into' the packet. It can though do things to the packet, such as change the physical machine address of whom sent it or where it is going. But it definitely cannot decrypt the packet

  Also will the hacker be able to DOS your internet connection?

An attacker could cause a denial of service to any service sitting publically on the internet if they have enough bandwidth to overcome your ingress bandwidth. I do not see though that DOS is a concern within the context of your router being ARP spoofed.

  Then, what if let's say one of the device using the vpn is
  compromised? Will the hacker be able to use it to hack the rest of
  your devices?

Yes - If the VPN is not segregated from the rest of the network via say a Firewall and the other hosts do not have suitable host based firewalls.


Can an OCSP response be issued by a subca of the Root CA that has issued the certificate? Is this Public Key Infraestructure possible according with the RFC 6960 Online Certificate Status Protocol - OCSP, Authorized Responders?

OCSP response for Cert is signed with a certificate issued by Sub CA 2.

Reading the specification for the signature of an Authorized Responder

  Matches a local configuration of OCSP signing authority for the certificate in question, or
  Is the certificate of the CA that issued the certificate in question, or
  Includes a value of id-kp-OCSPSigning in an extended key usage extension and is issued by the CA that issued the certificate in question as stated above.

I am not sure if this case is allowed. My own answer will be NO, but also is present

  Note: For backwards compatibility with RFC 2560 [RFC2560], it is not
           prohibited to issue a certificate for an Authorized Responder
           using a different issuing key than the key used to issue the
           certificate being checked for revocation.  However, such a
           practice is strongly discouraged, since clients are not
           required to recognize a responder with such a certificate as an
           Authorized Responder

You just answered your question, it is possible (though, strongly discouraged). Even RFC6960-conformant clients should support this scenario.

For example, Microsoft CryptoAPI allows this scenario even when OCSP signing certificate chains up to different root (which must be trusted) by default. Source: What’s New in Certificate Revocation in Windows Vista and Windows Server 2008

  Windows Vista SP1 and Windows Server 2008 enable the OCSP signing certificate implemented by the OCSP responder to use a certificate that terminates in a different root CA than the CA whose revocation information is reported in the OCSP responses. This feature enables an organization with a diverse PKI to limit sources of revocation information and the CAs that can issue OCSP signing certificates.

Microsoft do not fully support RFC2560 nor RFC6960, because they rely on their own RFC5019 in reagrds to OCSP.

This means that you should take into consideration deployment environments and their specifics.


Uses of same origin policy I am trying to understand what use cases exist for the use of Same Origin Policy (SOP).

SOP prevents a document or script loaded from one origin to interact with a resource from another origin.

But in what scenarios is this really used? From this answer, if I include scripts from different websites in my webpage, the scripts won't be subject to SOP as they belong to my website's origin. If they try to include other scripts, then those scripts will be subject to SOP (won't be able to access my page's resources: DOM, cookies etc.).

SOP is also used to prevent cross-domain AJAX requests.

Other than the above, is there any other scenario where SOP is applicable ?

But in what scenarios is this really used ?

Everywhere. Otherwise if you visited my website example.com I would be able to read your Gmail if you were logged in at the time from the same browser.

  the scripts won't be subject to SOP as they belong to my website's origin.

Correct: They won't be subject to any restrictions by the SOP.

  If they try to include other scripts, then those scripts will be subject to SOP (won't be able to access my page's resources: DOM, cookies etc.).

Not true. If those scripts include other scripts (e.g. a document.write of a script tag - <script src="https://example.edu/foo.js"></script>) then those scripts will be under your website's origin too. If you include another domain's scripts under your own site, then you are giving full access to your origin to that domain.

  SOP is also used to prevent cross-domain AJAX requests.

Not true. The SOP does not stop a cross-domain AJAX request from being made - it simply stops it from being read.

  Other than the above, is there any other scenario where SOP is applicable ?

Yes, for example the SOP prevents frames, IFrames and windows from cross communicating across domains. Check out MDN for a full explanation of the SOP.


How to make people report incidents? I would like to know how you make employees report incidents. Incident reports are a key element of an ISMS. No reports = No discovery of the incident = High chance things go out of control.

We have a kind of game: people can give red cards to each other for small incidents. The cards tell them to report the incident, but people don't want to.
I can imagine we have to use a reward system (focus on positive) to make people report and do their best to limit incidents, but how?

The reporting system currently works like this: Person B.A. sees Person A.B is not locking his computer. He then (should) give(s) a red card to the person, takes a picture and send it to the incident@company email with the name of the person in the mail. The mail goes to InfoSec team (not only IT guys btw) who then put it in the system.

Now, no-one sends those emails. I am checking to get enough reports for the audit, but that means people will not report because I will. I did stop checking for a month, then the number dropped to 1/4 of the previous month. I started checking again and it immediately rose...

What to do?

-Edit-important note:

I am a student, doing this as internship. I am an engineering management student, new to this area when I started 3months ago, no IT knowledge. The company is an IT company in Bulgaria. Now 200 employees, last year 100. Now everything is changing very fast of course. That is not the way it should be but the way it is. Please take those things into consideration when you reply. Feedback is welcome, but please tell me How

Of course no one wants to report, they are "turning in" their peers. Also, the time and complexity it takes to go through the reporting process you described is another negative reinforcement. You are only going to get low compliance if everything is a negative.

And ... YOU CANNOT FORCE PEOPLE TO DO ANYTHING!!

You are approaching the problem backwards. You need to:

use technical controls so that people do not have to think (set an auto-lockout time on idle workstations)
reward people for doing the right thing (and no, reporting their peers is not the right thing)

Instead of punishing non-locked stations, reward people who locked their stations! Praise them publicly, offer them a chocolate. Whatever works for that office/local culture.

Your focus, at the moment, is to collect metrics for your incident reports. I suggest that this is also backwards. Locking a station is a behaviour. Not locking a station is not an incident (it's an event, at best). You are never going to get accurate metrics, so I'm not sure why this would be a focus.

I know that it is a huge mental shift, but there is a big difference between an intentional act of omission or commision (to not do or to do something) to violate policy (an incident) and inattention and inertia that results in non-compliance. You cannot confuse the two. Non-compliance is a behaviour issue, which needs to be handled (and tracked) differently.

To answer your question directly, in order to get people to do things, you need to address 3 factors:

motivation
ability
trigger

They have to want to do it, it needs to be easy to do, and the trigger for when they are supposed to do it needs to be clear (the Fogg Model).

Scratching an itchy nose has high motivation, it's easy to do, and the itch is its own trigger. So, everyone does it reliably.

Reporting your peer for not locking a workstation has low motivation (even if you rewarded them for reporting), the process is complex, and the trigger is also not that clear. When does one deem that there is non-compliance? Does one have to be watching all the time? What if the other user stepped away and was within view of their workstation? What if the user is "looking out" for the workstation to ensure there is no unauthorised access?

You simply are on the wrong side of the Fogg Model. Address these 3 factors, and you can experience high compliance.


Does secure boot protects against firmware rootkits and GPT bootkits? This question is related but only partialy answers my question.

I know firmware (most notably UEFI firmware) rootkits or bootkits are rare and possiblity to introduce one into system is very low, but in practice if such thing happens:

to be infected by firmware rootkit without knowing it, is impossible with secure boot enabled?
does secure boot protects against GPT bootkits (if such malware even exist as oposed to well known MBR bootkits)?
is there known scenario that could bypass secure boot when speaking about bootkits and rootkits?

It does indeed protect against GPT bootkits, and that's exactly what its job is. It doesn't protect against rootkits in the UEFI firmware itself though, as it's that very firmware that's responsible for enforcing Secure Boot.


Questions about ddosing? Suppose a website is hit by a 500 Mbps DDos, and then the DDos stops for a second or so; does the website recuperate?

It depends.

A DoS attack, stereotypically, is an excessive flood of network packets that causes a system to become unavailable or unusable to legitimate users. They are, in essence, exhaustion attacks. Not every DoS aims to exhaust the same resource - a system has many resource types and a DoS condition may be caused by exhausting one or more.

The most prolific type of DoS, at least in terms of media representation, is a massive flood of network traffic designed to starve the target system's connection to the internet. These can be achieved in a number of ways, but in general it's just about blocking the incoming pipe with too much data. If this flood stops for a few seconds, the server may recover, depending on the configuration of the network.

There are a few cases where it might not:

A system in the network path (either the target itself, a load balancer, firewall, router, etc.) runs out of space in its state table and fails.
A system in the network path exhausts its RAM, CPU, disk, or overheats, causing an outage.
A system in the network path caches the incoming traffic into a queue, causing the DoS to continue internally after the external attack stops.

Of course, this assumes that the attack is purely aimed at "clogging the pipes". Many other DoS conditions are possible:

CPU / memory exhaustion due to expensive requests.
Disk exhaustion (either space or IO) through excessive logs or database writes.
On limited hosting, exhausting the periodical bandwidth limit.
Triggering a crash in the server software stack (e.g. null pointer dereference)

These may take time or manual intervention to recover.


Does ssh-keyscan tell you if a server supports RSA or DSA keys? A question came up on the Unix & Linux SE site: Checking if passwordless ssh authorization is possible without permission for sshd_config?.

I immediately thought you could possibly infer this using the commands: ssh-keyscan -t rsa <server> and ssh-keyscan -t dsa <server>.

My logic is that if a server is returning either key, then it must support that type of key for users' use as well.

Is this assumption incorrect?

There are details... but, basically, early in the connection establishment, both client and server send to each other the list of algorithms (and thus key types) that they support. See section 7.1 of RFC 4253.

Try ssh -vvv the.ssh.server.name. The debug messages will show you a lot of information of what the server returned, including the full lists of algorithms.


Sniffing external networks from a public network (place) There is something that I can not understand. If you are preparing, building up an attack from a
public place (coffee shop, restaurant ect.). How can you be tracked by law enforcement? I'm asking
this because the public IP address will be the one from the public place (sub-network) from where you are performing
the attack. Once you are done with the attack. The law enforcement can only find out that the attack
came from the public place(after gathering the required info.). After you come to your home
get another IP address by the DHCP server which has no correlation to the public place network IP you were.

My question
is, how would the attacked person get to you (reveal your identity)?

Theoretically speaking, public WiFi networks do provide some level of anonymity. You are right in that since tons of people are behind a single public IP address, it is harder to trace malicious activity to an individual.

Practically though, a public network alone really doesn't provide enough anonymity to hide someone from law enforcement - mostly because unless you're really, really careful and know exactly what you're doing, you're probably going to leak information that allows the malicious activity to be traced back to you. It may help you get away with some run-of-the-mill illegal stuff (copyright violations, illegal torrents, that kind of thing), but if it's something serious that prompts a full-fledged law enforcement investigation, you're pretty much screwed if all you're relying on for anonymity is the fact that the network is public.

Most public networks will (or at least should!) keep some logs of network activity. Usually they record pretty basic information such as MAC addresses (essentially hardware ID numbers) of computers that connect, IP addresses that users communicate with, and possibly URLS that are visited, along with timestamps. This information is generally not enough to identify someone, but it can provide law enforcement with a starting point in an investigation.

So how might this work? Well, let's say your computer has a MAC address of A1:B1:C1:D1:E1:F1, and you decide to use the public WiFi network at a coffee shop to hack a website located at IP address 123.123.123.123. At this point, the website admin would of course look at the website logs and see that the attacks are coming from the coffee shop's IP. Law enforcement would then visit the coffee shop and request to see the logs of the public access point. They might see something like this:

02/21/2015 11:20:05 AM - Client A1:B1:C1:D1:E1:F1 connected to network
02/21/2015 11:23:31 AM - Client A1:B1:C1:D1:E1:F1 sent data to 123.123.123.123.

It provides some key information - they now know that the attack was definitely performed by someone who used the coffee shop's wifi, that the MAC address of the attacker is A1:B1:C1:D1:E1:F1, and that the attack occurred at around 11:23 AM on Feb 21. But it's still not enough to identify you.

But let's say you get a bit careless, and you decide to check your Gmail from the same computer. Now, the logs will look something like this:

02/21/2015 11:20:05 AM - Client A1:B1:C1:D1:E1:F1 connected to network
02/21/2015 11:23:31 AM - Client A1:B1:C1:D1:E1:F1 sent data to 123.123.123.123.
02/21/2015 11:25:01 AM - Client A1:B1:C1:D1:E1:F1 sent data to 216.58.217.133 (google).

It may seem like a pretty harmless action, but now there's enough information to identify you. At this point, law enforcement would probably get a court warrant and ask Google, "We are trying to trace some malicious activity from [coffee shop's IP]. Did anyone log in to their account from [coffee shop's IP] at 11:25 on Feb 21?" Of course, Google would then check their logs and say, "Yep, someone logged in to an account belonging to [your name]," and your identity would be revealed.

Even if you were careful and didn't log in to your Gmail account manually, programs running on your computer could do essentially the same thing. Email clients, cloud storage sync clients, chat clients, and even your browser could automatically log you in to something that reveals your identity in this manner.

There's also browser fingerprinting. When you visit websites, your browser provides a string of text (called a user agent) to the site that identifies the browser and operating system version. This is mostly so that websites can improve user experience by providing different versions of the site for different browsers. In addition to the user agent, websites can request additional information such as the types of compression supported, plugins that are installed, etc. etc. Together, a website can gather so much information that your browser is essentially unique. If you want to see this for yourself, you can visit this site to see the information that your own browser is providing.

Browser fingerprinting could be used for tracking in various ways, but let's say that the website you hacked fingerprinted your browser. Then you go home, and at some later point in time (maybe months later), you decide to visit the website you hacked from your home connection, using the same computer/browser. The website admin would notice that your browser's fingerprint matches the earlier attacker's exactly, and now they have your home IP address.

Finally there's the physical aspect - chances are, the coffee shop's customers are pretty much limited to people who live close to it. If law enforcement can't find the attacker with digital evidence, they can always revert to old school forensics and check transaction records, narrow down suspects, interview people in the area, etc.

Obviously there are other ways beyond the one's I've mentioned, but hopefully this gives you an idea of how it might be done. Mostly, it comes down to linking the various traces that you leave on the Internet combined with diligent old-fashioned forensics work.


Amazon AWS and PCI DSS Does using AWS dedicated-hosts or dedicated instance will be compliant with PCI DSS requirement?
Please refer to the comparison section:
https://aws.amazon.com/ec2/dedicated-hosts/

Thanks.

Yes you can use a dedicated ec2 host, but you don’t need to, you can just use the standard ec2 service as part of your architecture. There’s a list of all the services that AWS provides PCI compliance for, helping you reduce your burden, here.

I would look at using a fully managed service like Lambda if you’re building something new, it’ll save you some effort. Also you can check out a suggested architecture here.

If you go into the AWS console then to Artifact manager, you can download the PCI document describing what AWS takes care of for you.

If you’re creating a payment gateway then you have a very steep PCI learning curve ahead of you I’m afraid. It’s worth speaking with a QSA, it’ll save you a lot of time.


Storing credit card numbers for enterprise payments There is a business requirement to store credit card numbers on behalf of end users in the enterprise for the use cases below.

Currently these users store credit card numbers in insecure locations such as Microsoft Sticky Notes, Microsoft Outlook tasks, etc.

There are enterprise policies that disallow the storage of credit card numbers including holding printed copies.

To support the end users in the organization in the use cases below, what are the options to store the credit cards securely without compromising PCI-DSS compliance?

For example, are there services that are PCI-DSS compliant that enable the storage of credit cards? Additional features such as the ability to auto-complete a payment page would be a bonus.

An earlier post had suggested the use of online password managers however these services are not PCI-DSS compliant.

First use case

As a personal administrator of a collection of Executives, i am required to book venues, flights, accommodation and events. These services require me to use a credit card for payment. Since i am a personal administrator of several Executives, i am also the custodian of their credit cards. I currently use Microsoft Sticky Notes.

Second use case

As a business owner within the organization, i am issued with a company credit card. I use the credit card to make payments online for cloud services. I currently store the credit card number in a Microsoft Word document that is saved in OneDrive. This is to enable me to access the card details if i don't have access to the physical card.

Third use case

I am a senior manager. I organize payments for commercial services using a shared organizational credit card. The details of the credit card are stored in Microsoft Outlook tasks. This enables me to purchase services once approval has been confirmed. I am not issued with an individual credit card.

In my PCI work, I have not dealt with this question, but my understanding is that it depends on the issuer, brand and corporate context.

Visa and MC in the past have considered PCI at the enterprise level to apply to all PANs the enterprise has visibility into as part of its business, including issued corporate cards. Amex sometimes has not.

I would advise reaching out to your counsel and your issuer to understand what your issuing agreement says, and what their practice opinions are.

Independent of whether or not PCI applies, I would also advise reaching out to your security team to arrange a solution that allows for segregated storage of PANs outside of their reference in common corporate data systems like email, tasks, and calendar to satisfy the use cases that you have carefully, clearly, and helpfully outlined.

This may take the shape of a corporate-level secret management solution, which does not specifically apply to credit cards but which does support segregating the storage and transmission of sensitive information so that, for instance, emails/tasks/calendars can say "use card #25 for this" rather than "use PAN 5555... expiration xx/yy for this."


Is it impossible for an ISP to block access to a site that has a dynamic IP? I was reading on how ISPs in many countries block access to many sites. This got me wondering -- How do ISPs block sites in the first place? I found answers here, and reading through, it became evident that ISPs usually drop connections going to these blocked domains on their DNS servers, which can be easily circumvented by using a different DNS (optionally also using DoH to a non-compromised server).

I then read on to find that ISPs also block domains by their known IPs, so using another DNS wouldn't fix this issue. This led me to think -- what if the server was on a dynamic IP?

The devil's advocate of my mind quickly told me that all the ISP had to do was to run a dns lookup on the domain itself to find the current IP and block that. But then again, what do you guys say?

all the ISP had to do was to run a dns lookup on the domain itself to find the current IP and block that.

Definitely not impossible. In fact it is the way Russian ISPs are required by RKN to censor websites. The requirements are enforced by RKN-owned boxes inside ISPs networks, trying to get access to censored websites and reporting about it to RKN. It is supposed that an ISP is fined for each non-blocked website from the blacklist, though there are rumours that it is not always the case. Some people protest against censorship by buying expired domains still present in the statewide blacklist and making them point to government and big business websites, so ISPs must block them for their clients. There were some rumours about a whitelist of websites that should never be blocked sent to ISPs, though using this whitelist may be illegal for an ISP, so if an ISP wants to play safe, it must block the sites disrespect to the whitelist.

There more sophisticated methods of detection are also used.


SQL injection vulnerability to CodeIgniter Hello I want to know why this kind of example question never been asked before.
I got this code from my college that they say this kind of code is able to prevent SQL injection.
We use CodeIgniter to build a website and here is the code to prevent SQL injection.

Controller:

$usr = $this->input->post('userid');
$pwd = $this->input->post('passwd');

if($usr && $pwd) {
                $ack = $this->mAuth->get_user($usr);
$pwx = $ack['passwd'];
                    if($ack && $pwd == $pwx) {
                        //redirect code
}

Model:

public function get_user($user_id='', $status=1) {
        $user_id = $this->db->escape(trim($user_id));
        $status  = $status ? 'and user_status_uid = 1' : '';

        $sql = "select * from users where user_id = lower($user_id)"

        return rst2Array($sql, 'row');
    }

I tried to login with 1' or 1 = 1 and etc, I found and it did prevent SQL injection even though it's only a plain text and password.

Is there any vulnerability to this code?
thanks

This sort of question has likely never been asked here before because it is more suitable for StackOverflow.

There are easier and better ways to protect against SQL injection in Codeigniter - I strongly suggest you look at Query Binding (at the bottom of the linked page) or Active Records. Both of these will escape queries for you in a way that is much easier to do and harder to accidentally forget. I have developed and mantained several Codeigniter websites, and Query Binding & Active Record are much better ways to protect your database, as you're less likely to miss escaping a parameter.

What you have is safe from SQL injection (provided Codeigniter's db->escape function works properly, which to the best of my knowledge it does), but if at any point you forget to escape even one thing that goes into your query, then you'll be vulnerable to SQL injection.

If this is for a college assignment then this remark isn't terribly applicable, but outside of academia, storing passwords in plain text is considered terrible security practice. It is much better to use crypt with a per user salt, or password_hash if your PHP installation is recent enough.


Are Self-Encrypting Drives (SEDs) used in cloud environments? I was wondering if SEDs are used in cloud environments, for example in data centers of CSPs like Azure or AWS?

And if so, what additional protection do they offer beside from physical theft of the drive?

I haven't been able to find information on the specific providers you named, but you may be interested in these two articles.

Self-encrypting Drives in Datacentres

Self-encrypting Drives vs software-based encryption

In terms of security benefits, the encryption key is stored on the disk as opposed to the OS, which makes it harder to extract. By erasing the encryption key, they you can render the data practically irrecoverable, allowing you to securely dispose of an SSD in a relatively convenient manner. Plus, it is a lot quicker and cheaper to wipe in this way than pretty much any other safe method.

Not that they're a magic bullet to all problems. The second article I linked details how, with physical access, a powered-on SED is still vulnerable to some of the same attacks as software-encryption, and potentially other methods as well.

Finally, not a security point, but SEDs have dedicated crypto processors, meaning the data encryption and decryption functions aren't vying for CPU usage, so you do see some performance related benefits from that.


How does the anchor tag () lets you do an Reflected XSS? I was going through the OWASP XSS Filter Evasion Cheat Sheet and and I came across this section where there is an anchor tag used to do an XSS in the following forms:

XSS
XSS
XSS

I can imagine its use in a stored XSS attacks (like some forum post saying "Click me") but I cannot imagine its use in a Reflected XSS attack. Can anyone tell if it's possible to do a reflected XSS using the anchor tag? If yes, how?

Sure it's possible as long as a site uses non-persistant data to construct an anchor tag without properly sanitizing the data.  A contrived example:

{or maybe here?}

That being said, the link that you posted has to do with URL string evasion and not reflected XSS.  Is it possible you are confused on what reflected XSS is?  Or possibly I just misunderstood your question :)


Have hardware trojans been seen in the wild? Military and intelligence organizations have spent a lot of resources guarding against the possibility of hardware trojans, unauthorized modifications to hardware circuits that leak information or impair device functionality. However, I'm not aware of a single confirmed case appearing in the wild.

I've found one reference to radar failure in Syria, but I don't know if that was actually a hardware trojan.

Does anyone know of any cases?

Perhaps this one about a Siberian pipeline, but I'm sure it fits in the "hardware trojan" you're asking for.

Edit:

Does hardware backdoors also fits your search? If so, some more few examples:

HP storage hardware with a backdoor
Cisco and other routers backdoors to allow judicial interception of data
FBI afraid of backdoors in counterfeit cisco products
virus inside a USB picture frame
some political discussion about having trojans in components manufactured "overseas"

And I was unable to find links to the information I gave below, so I'm leaving it as it is, but I can't remember the source or find it again.

Onde I read something about US selling a faulty DEC chip, which would give wrong math, to the Russians, using some canadian company. I'm unable to find any page about it, I'll keep searching.


Best practice for https Private Key Generation I am working with a security person that baffles me a bit with the practices he performs.  Besides the issue of this person insisting on bypassing every security measure in place we have got into it about handling private keys and certificates.

So this is my perspective of best practices in regards to web servers:  When generating private keys it is best to generate them where they will be used and never move them to any other system, if at all possible.  From this point generate a CSR from the server with it, to get a signed certificate.  At this point the private key is never exposed to anything but the server that originally generated it, therefore there is no chance a hacked laptop or share might expose it.

This makes sense to me, however this security person seems to prefer generating the private key on a system he controls, then transfer this to whatever system needs it.  This seems to extend the risk by having the private key in more then one spot as well as a lot more work with no benefit that I can see.

Am I missing anything with this?  Other than common practice, is there a reason I am not seeing for this to be done?

As long as the machine in question has enough entropy to generate strongly random keys and nonces, that's totally correct. The key must never leave that server. Even more, if I were working on a critical application, I wouldn't even trust that machine and keep the key in a HSM. It might cost a lost, but it significantly enhances the security.

There is a broad spectrum of security practices, going from the best case above, to the worst possible situation, which appears to be your case. Either your colleague has a specific reason for doing so or he/she is putting the security of your applications at risk. Immediately confront him/her. If I were in charge, I would fire that "security" person at once.


SSLSPLIT not working with WSS Is there a way in SSLsplit through which we can bypass WSS over 443? Slack and a lot of other websites are not working correctly.

Currently, WebSockets are suppressed deliberately.  This will be addressed eventually by implementing this feature request:

https://github.com/droe/sslsplit/issues/216


Why is the first line of http message unreadable after decryption I have a TLS Record containing HTTPs application data.

I extracted the encrypted plain text with mac from the application data, then, when I decrypted the extracted data using AES CBC mode, I am expecting that It will return something like this:

POST /ImeiTracki
ng?msg=010908391
1841060249765020
A984108000001540
F7F9D00DFBF00001
7000160005100000
0000800060200020
7022502080300010
30A0E07918184026
284F8FFFFFFFFFFF
0000000000083083
A758909259672050
B00 HTTP/1.1..HO
ST: h..X-Admin-P
rotocol: globalp
latform-remote-a
dmin/1.0..
....

but instead, it returned:

³Y%þ&É?eÄºìr8%
ng?msg=010908391
1841060249765020
A984108000001540
F7F9D00DFBF00001
7000160005100000
0000800060200020
7022502080300010
30A0E07918184026
284F8FFFFFFFFFFF
0000000000083083
A758909259672050
B00 HTTP/1.1..HO
ST: h..X-Admin-P
rotocol: globalp
latform-remote-a
dmin/1.0..
....

The only weird thing here is the first line (³Y%þ&É?eÄºìr8%), it should be POST /ImeiTracki. The lines after the first line are all okay.

My input to the aes decryptor:

encrypted text = encrypted text + mac
key
iv

I also tried other https messages from the same session and same result was observed - the first line is unreadable and the latter is okay.

I also tried to use an online aes decryptor and still- same result was observed.

I would like to have a result just like my expectation.

Any ideas on why is the first line unreadable?

In CBC mode the IV is applied after the decryption algorithm with the key is applied to the ciphertext.  Which means that if your key is correct, but your IV is wrong then the first block will come out garbled.  The rest of the decryption will happen correctly since the each IV afterwards is the previous ciphertext (hence the name Cipher Block Chaining).

Here's a picture of the CBC decryption operation from the Wiki page:

Somehow you are incorrectly calculating the IV.


Is it a security risk to have 'Control + j' functionality enabled in a production instance of PeopleSoft? The control + j feature within PeopleSoft outputs a list of potentially interesting data for a potential attacker. The feature is generally used to aid in debugging. Here is a the [censored] output from a control + j:

Is it a security risk to have control + j functionality enabled in a production (live/public) instance of PeopleSoft? I imagine it is a risk (albeit perhaps small) because it simply saves time for the potential attacker in giving them the specific platform knowledge to go lookup known attacks for that platform flavour.

Is my assessment correct? What other risks (if any) does it impose?

I would say a lot depends on if the users are remote, or are on the local machine.  I would disable the feature if you do not need it.

Local user / attacker:

If the users are local, an attacker can find out most (but not all) of this information fairly easily, although this report would certainly make it easier for the attacker.  Even locally, there are a couple pieces of data that would probably be hard to obtain by other methods that could be useful to attackers.

I see component buffer size as being troublesome because it could aid in buffer overflow attacks.
Depending on the implementation of the database, database name or possibly component could aid in a SQL injection attack as well (if PeopleSoft is vulnerable to this, which I do not know).  Most of the other information can aid in an attack, but is generally available at the local machine anyway.

Remote user / attacker:

If the users are remote, this report is far more problematic.  It reveals many details that would be useful to attackers, which would be harder for them to obtain through other means. For example, the OS, browser, service pack, etc... would let the attacker know what they are attacking and if it is out of date (so they know what vulnerabilities there are).

I would highly recommend disabling this feature if you do not need it and there are remote users.


How to pen-test RAP applications Has any of the readers here got experience with pen-testing RAP (Remote Application Platform) applications? I am particularly interested in testing on input validation. A cursory research at google etc. yields nothing. Any hints on how to attack RAP are highly appreciated.

Addendum

The application under consideration is remote; there's no way to observe the internal processing of application. All I can see is the exchange of messages as defined by the RAP protocol.

RCP and RAP applications are typically built using the Eclipse E4 Tool package. There may be test cases unique to the target underlying operating system -- Eclipse runs on OS X, Linux, Windows, and a few other OSes. First, get the Delta Pack -- http://download.eclipse.org/eclipse/downloads/drops4/R-4.4.2-201502041700/#DeltaPack

The Delta Pack contains all the platform specific resources from the SDK and is used for cross-platform exports of RCP applications. If you know how to install new software to Eclipse ("Help", "Install New Software", "Add"), then put the following into the Location field:

  http://download.eclipse.org/e4/updates/0.17

After you have a stable platform and know how to create and modify RCP and RAP applications using E4 and the surrounding technology tooltips, you are on the way to know how to pentest these apps. Many will affect Eclipse only and few will call out to a file on the operating system or a network. If they do, you can leverage many existing Java-friendly pen-test tools such as Javasnoop, JDB, JSwat, DSer, untidy (for XML), et al.

The closest thing I can find to a RAP application would be something like Oracle Forms. Here is a blog post describing three ways to target an Oracle Forms app that uses HTTP or TLS. The blog does recommend Javasnoop for other more-flexible tasks. Here are additional use cases for Javasnoop:

http://streetburnerbux.blogspot.com/2013/08/intercepting-traffic-from-java-based.html
http://streetburnerbux.blogspot.com/2013/08/hacking-java-apps-by-javasnoop.html
http://fixulate.blogspot.com/2012/09/java-attach-instrumentation-api-for.html
http://fixulate.blogspot.com/2012/10/java-instrumentation-agent.html

For the non-Java portions of a RAP pen test, such as Javascript, you may want to look at retire.js (a tool similar to OWASP Dependency Check that can be used to analyze third-party Javascript components for well-known vulnerabilities) or Fortify SCA (a good securtiy-focsued static-analysis engine that works on Javascript code).


isn't it a security gap if TLD hostname doesn't send the strict-transport-security header? If you connect to https://google.com (without www.) you get a HTTP 301 redirect to https://www.google.com/ .  Then if you connect to https://www.google.com/ the response includes the strict-transport-security header.

I contend this is a (small) security gap, because the strict-transport-security attribute never gets set for the top-level hostname, google.com.  This means that no matter how many times the user has connected to google.com or www.google.com, if an attacker manages to send them to http://google.com/ , and the attacker is a man-in-the-middle who can redirect google.com to a site the attacker controls, they can eavesdrop on the connection.  (Also, Google's entry on the HSTS preload list only applies to www.google.com, not google.com.)

However, Google is rejecting all reports of "security holes" regarding HSTS:
https://sites.google.com/site/bughunteruniversity/nonvuln/lack-of-hsts
with the statement "Migrating all the domains to HTTPS, and deprecating all clients that can only talk over plaintext HTTP takes time."

I contend these objections makes no sense.  If a client only speaks http, then the way to continue supporting that client is to continue serving http.  But if you serve the STS header over https connections, you're telling the client, "Hey client, since you obviously speak https, this host promises it will always serve you https in the future and you should always make https requests to me."  The only valid reason not to serve the STS header would be if you think the hostname might some day not support https any more, which is hopefully not the case for google.com!

Perhaps there are subdomains of google.com that don't support https.  But then google.com can just serve the STS header without the "includeSubDomains" attribute, so it won't be applied to subdomains.

So I maintain that:
1) Not serving the STS header for the hostname google.com is a security gap.  While it's a small gap, there is no offsetting legitimate reason not to serve the header.
2) It is not a valid objection that they "want to keep supporting clients that only talk over plaintext HTTP".
3) It is not a valid objection that they have not migrated other subdomains to https yet.

Am I missing something?

First off, it is apparently more complicated: A bit of testing reveals www.google.com will, apparently, only send the HSTS header if it sees a user agent string that indicates a modern browser. Without a user agent string, e.g. with curl -H https://www.google.com, you will not receive a HSTS header at all. In fact, the google search page will still work via http if it doesn't see a modern browser's user agent string.

Google obviously still wants to support plain http access to that page, and not force certain browsers to https. I'm not sure why, but they might want to support some old, broken clients which would actually recognise the HSTS header but would fail to connect due to a broken SSL/TLS implementation.

The security risk to google itself is actually zero (as there is no confidential data on the search page), though there is a small risk to the user that a search term is exposed.

Other google domains like mail. that are on the browser preload lists and therefore always secured in practice.

The reason that Google is rejecting reports for missing HSTS? That has nothing to do with wether Google thinks that it should be fixed. Bluntly put: They are working on HSTS and they already know that it is not there. It doesn't help them if people report what they already know, so they aren't going to hand out rewards for that.

They may still fix the problem in the future, but until then they don't want to deal with a lot of folks reporting the same thing over and over again (and demanding a reward).


How to encode a public key in PKCS#8? RFC5958 defines a set of enhancements to the PKCS#8 key serialization format, bumping the version field up to 1 and additionally permitting serialization of public keys for arbitrary asymmetric cryptographic algorithms.
OneAsymmetricKey ::= SEQUENCE {
  version                   Version,
  privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
  privateKey                PrivateKey,
  attributes            [0] Attributes OPTIONAL,
  ...,
  [[2: publicKey        [1] PublicKey OPTIONAL ]],
  ...
}

PrivateKeyInfo ::= OneAsymmetricKey -- Overwriting the definition in RFC5208 which only supports private keys

However, I'm unclear on the following:

What belongs in the third field of the OneAsymmetricKey sequence when one is encoding only a public key?

I'm writing an implementation of some current research/experimental cryptographic algorithms, and I'm currently trying to write the serialization and deserialization capabilities.

You misunderstand RFC5958.
PKCS#8 remains a private key serialization format. There is no exception made for that field in the v2 which may contain a public key, because such is now allowed to be included in addition to the private key, not instead of it.

What you should be producing, instead, when you only intend to serialize a public key for transfer, is merely and exactly a SubjectPublicKeyInfo object as defined in RFC5280:
AlgorithmIdentifier  ::=  SEQUENCE  {
     algorithm               OBJECT IDENTIFIER,
     parameters              ANY DEFINED BY algorithm OPTIONAL  }

SubjectPublicKeyInfo  ::=  SEQUENCE  {
     algorithm            AlgorithmIdentifier,
     subjectPublicKey     BIT STRING -- DEFINED BY algorithm --  }

(with, of course, ASCII armoring when appropriate.)
This is how other standardized public cryptographic keys (with the sole exception of RSA's PKCS#1 encoding) are serialized for transfer, such as Ed25519/X25519 and Ed448/X448 as well as the various NIST ECC curves.


Explanation of SSL handshake with certificate I've read a lot of articles.

  The client uses the information sent by the server to authenticate the
  server. If the server cannot be authenticated, the user is warned of
  the problem that an encrypted and authenticated connection cannot be
  established. If the server can be successfully authenticated, the
  client proceeds.

However, I haven't found an answer to my following question.

When a client's browser goes to a bank website, and gets the bank certificate, what does the operating system do in order to approve that this is the bank?

I think it is as follows, but please correct me if I'm wrong:

The bank sends its certificate and its public key to the client. This certificate also has a hashed info which was encrypted with the server's certificate private key.
The client searches to see if it is a valid CA + decrypts the hashed info with the CA public key.
The client encrypts the server's PK and also gets a hashed value to see if both hashes are the same.

Is this right?

Firstly, a reminder, in public key cryptography:

The private key is used for signing and deciphering/decrypting.
The public key is used for verifying signatures and enciphering/encrypting.

See the glossary of the TLS specification:

  public key cryptography:
        A class of cryptographic techniques employing two-key ciphers.
        Messages encrypted with the public key can only be decrypted with
        the associated private key.  Conversely, messages signed with the
        private key can be verified with the public key.

In your question:

  1) the bank sends it's certificate and its public key to the client.

  this certificate has also a hashed info which was encrypted with
  servers certificate private key

This doesn't make sense (you don't encrypt with a private key).

The server certificate is signed using a private key (and yes, it's a hash of the certificate content that is effectively signed). However, it's not done using the server's private key (unless the certificate is self-signed). This is done using the private keys of the certificate issuer (the CA): the one named in the certificate Issuer DN.

Your browser or OS comes with a pre-defined set of CA certificates. These CAs are those able to issue certificate, that is sign their content with their private keys (and put their own Subject DN as the Issuer DN of the certificate they issue). When verifying a given (a priori unknown) certificate, you look for one of your known CA certificates whose Subject DN matches the Issuer DN of that server certificate. If the public key of that CA certificate allows you to verify the server certificate (i.e. if the CA did indeed sign the content of that certificate), it's a match.

(It's also possible to build a chain when there are intermediate CA certificates: the server can send a chain, which you may have to link to your known CA certificates.)

There is no encryption involved in all this: it's all digital signature.


Fritz!Box default WPA2 security I was wondering, how safe the default configuration of a Fritz!Box really is.
By default, there is a 16 digit WPA2 key, which contains only numbers.
My first though was, that bruteforcing is right easy, because it only containes numbers.

I could find out, it'll take up to 65 years with my Geforce 780 to bruteforce.

Now I am wondering, if it's possible to have rainbow tables, in order to crack it?  I don't understand rainbow tables that well to imagine the time to create them, or the size.

Maybe somebody can help me understand it some more.

Thanks.

As for rainbow tables regarding the 16 lenght number default password on FritzBox , YES, if somebody had them already made, you could calculate for your FritzBox if it has a default password or no (all possibilities, 16 numbers).
But as regarding to MAKE a rainbow-table for 16lenght numbers for FritzBox, it would take 63 years (same time as dictionary attack or even a bit slower) and some PB , thousnds and thausends of TB of space. But yes, if anyone would make a rainbowtable with some super-computer and store it on his super-drive, it would work for all future probes (ofcourse only with same ESSID (wlan NAME) , for example only for "Fritz!Box FON Wlan 7390". For EVERY ESSID you would have to make a new rainbow table.
In practice, I higlhly doubt that anyone has a rainbow table for any of Fritz!Box which include all default WPA's (16 lenght numeric key).

If I were you, I would try to calculate the algorithm, with which they (the factory) calculate the default WPA key. You can find at least a dozen of FORUMs, WIKIs etc (most in German) ,where they are trying to calulate the secret, from which the factory calculates the default WPA keys for their boxes. As I understood , the calculate them from the MAC (every box has more than 1 MAC, one for WLAN, one for ETH, itd. , from serial number, and from default ESSID.
 Good luck decrypting the alghoritm.