This one is pretty advanced.

Infection method: malicious script, macro-enabled document files, or malicious link.

Cloaking: familiar branding designed to look like a legitimate e-mail.

Persuade mode: key words like “Your Invoice”, “Payment Details”, "Upcoming Shipment".

Versioning: Early versions arrived as a malicious JavaScript file (original one was used to steal bank account details by intercepting internet traffic). Later versions evolved to use macro-enabled documents to retrieve the virus payload from command and control (C&C) servers run by the attackers.

Anti-countermeasures: detects if it’s running inside a virtual machine (VM)  - will standby if it detects a sandbox environment. Emotet is a polymorphic Trojan that can evade typical signature-based detection. It has several methods for maintaining persistence, including auto-start registry keys and services. It uses modular Dynamic Link Libraries (DLLs) to continuously evolve and update its capabilities.

Update method: C&C servers, just like "Windows update" works. Updates allow additional malware installation (this is the current version) usually focused on banking Trojans, or convert itself into a system that assimilates stolen information such as financial credentials, usernames/passwords, and e-mail addresses, after which it sends them away.

Other capabilities: it can take advantage of the Windows Eternal Blue Vulnerability, starts various keep-alive services named as random numbers.

If you suspect an infection, isolate the system from the network immediately and run a deep scan with advanced anti-malware tools like Kaspersky or Malwarebytes. An alternate method is to restart in safe mode and perform a complete system restore and then scan your system with Reimage.

Other things that should be done is secure the e-mail part better and train users not to click/open everything they receive and report suspicious e-mails.


Is it necessary to encrypt a JSON Web Token more than what is built-in?

JWTs can easily be encrypted when necessary - most libraries support it by default.
There are actually multiple kinds of JWTs.  There are two that are probably the most common:

JWS (plain text payload with a signature for validation)
JWE (everything is encrypted).

The JWS is much more common so often when people refer to a JWT they are just referring to a JWT with a signature.  Indeed, there were a few years where I always thought that a token with a signature was the only kind of JWT.
However, encrypted ones do exist, so if you did want to encrypt your JWT you wouldn't want to take your JWS and encrypt it yourself.  Rather, you'd just want to use a library that supports JWE out of the box.  Here's an example of a library that let's you choose between signatures and encryption (as well as a third kind).
Understanding their use cases
So you can encrypt your JWT, but why would you?  To answer that question is't important to keep in mind that encryption and signatures have two different purposes: a signature makes the underlying data tamper proof while encryption makes it private (and as a side effect, tamper proof).
Therefore if all you care about is making your payload tamper proof then a signature is sufficient, and has the benefit of being easier to understand and use.  As a quick example, the ability to view the payload itself may help with debugging from time-to-time.
However if you also need your data to be private, then encryption is obviously necessary. You mentioned your payload "only" containing a user id and email, and that such information is not especially sensitive, but in some jurisdiction that qualifies as PII and leaking it may result in heavy fines (aka GDPR). Therefore some organizations may choose to protect even just that, or they may store additional information in the JWT that requires privacy. It just depends on your you case, and since JWTs are so flexible they are used in a wide variety of ways, so being able to choose between just signatures or full encryption can be helpful.
Do you need your JWTs to be encrypted?  Only you can decide that.  If you are only storing a user id and an email then probably not.  However, you can store much more than that, and people often do, so it will simply depend on your use case and your own risk appetite.


Performance is more readily benchmarked than computed. Try to arrange to run this command on your systems:

openssl speed rsa2048

This supposes that you can have a Linux-like operating system on your machines. This will give you the number of private-key and public-key operations achieved by OpenSSL (a well-known and widely used cryptographic library) when using a 2048-bit RSA key. On a 3.1 GHz Xeon (E3-1220 V2), I get 27415 public-key operations per second, i.e. about 113000 clock cycles per RSA signature verification.

Of course, CPU brand and architecture will impact such figures; for instance, one may expect a slowdown by a factor of 3 or 4 on a 32-bit CPU like your ARM (my Xeon runs in 64-bit mode, and it helps quite a lot for big integer computations). Not all CPU can issue the same number of instructions per cycle either. However, one should consider that between 100000 and 1 million cycles for a RSA signature verification should be "typical" on modern CPU (for a 1024-bit RSA key, divide these figures by 4).

OpenSSL's benchmark tool is mono-threaded, and RSA computations easily fit in CPU L1 cache, so this scales very well on multicore systems; e.g. my quad-core Xeon can actually do more than 100000 RSA signature verifications per second (not that such abilities are useful on a daily basis, though).


Identifying the author(s) of a piece of malware

There are a number of different techniques, depending on the skill level of the malware author:

Embedded metadata - compiled programs can contain details about their authors. This is most commonly seen in legitimate programs, and shows in the details screen if you look in Windows properties. Attackers who are out for fame might well put identifying details in these fields
Accidental embedding - compilers will often include details on compiler flags used, which may well include paths to source files. If the source file was in /users/evilbob/malware, you can make a pretty good guess that evil bob wrote it. There are ways to turn off these inclusions, but everyone makes mistakes sometimes
Common code - malware authors are like any other programmer, and will reuse useful bits of code from previous work. It is sometimes possible to spot that a section of compiled code matches a previously discovered section of code so closely that it seems probable that the same source code was used for each. If that is the case, can deduce that the second author had access to the code from the first, or may be the same person.
Common toolchain - if a developer tends to use Visual Studio, it would be unexpected to see their code turning up compiled with GCC. If they use a specific packer, it would be strange to see them using a different packer. It's not perfect, but it could suggest a distinction.
Common techniques - similar to the above, coders often have specific patterns of coding. People are unlikely to switch patterns, so you can make a reasonable guess that if some compiled code couldn't have been generated in a particular coding style, it probably wasn't written by someone who has previously been known to use a different style. This is much easier with interpreted languages, as seeing consistent use of, say, for loops rather than while loops is easier than spotting the differences between the compiled output of each (modern compilers may well reduce them to exactly the same set of instructions).
Malware origin - where did it come from? Does it have any text in specific languages, or typos which suggest a particular background? (e.g. colour would suggest that the author wasn't American, generale might suggest someone used to writing in a Romance language such as French or Italian)

None of these are on their own enough to determine an author, but combined, they might suggest a common author with previous malware, or even with other known code (e.g. from OS projects).


What was done to gain a list of home directory accounts?

From what I can see, it seems that a hacker managed to gain access to your server - probably through a vulnerability of some sort.

The text file seems like the output of a typical information collection script that one would run after gaining access into the server.

With the information you provided, it is near impossible to determine the exact vector and impact of the attack. You should consult a security firm to determine the scale and impact of the attack, as well as the steps you can take to remedy the breach.

The attacker isn't very careful though, as he didn't erase the text file after his attack.


Yes, they would overwrite the old SSL ceritificates. By overwriting the certificates (both key and actual certificate), you replace the certificates on your website. The visitors visiting your website will not see any error by this.
Right at the moment you replace the key and certificate and restart Apache (or the webserver software you use), it will be replaced for visitors.

I would recommend testing your website against SSLlabs, to check for any errors. Don't forget to check "do not show the results on the boards."


The thing you want to guarantee here is freshness, so having the client sign some nonce - any nonce, as long as it's fresh - will work. Ideally, that signature should also be bound to the channel, but the signature and nonce are being transmitted inside the encrypted channel, so maybe that's enough.

Ideally, though, you're right, signing the TLS shared secret would accomplish both. I'm just not sure how easy that is to actually implement.

Using TLS client authentication would be better still, because TLS does all of this for you. Client certificates would be my first choice, but if you're hell-bent on using SSH keys, TLS raw public key authentication might do the trick.


problem after upgrading from GnuPG 1.4 to GnuPG 2.1

An assertion is a sanity check in code where the code checks for a condition that should always be true, and will terminate the program if it is false, indicating a bug or data corruption. The assertion you are getting is located here in the code. The comment hints at the purpose of the assertion:

/* If UID_NO is non-zero, then the keyblock better have at least
   that many UIDs.  */
log_assert (uids_seen == uid_no);

My guess is that you have a mildly corrupt key where the number of UIDs in the key differ from the number of UIDs the key claims to have. GnuPG 1.4 may not have had any problem with that and happily accepted the corrupt key (the same function in 1.4 does not have the assertion), but 2.1 added a sanity check that now rejects the corrupt key. It certainly isn't an unrecoverable error. My advice would be to export your keypair in GnuPG 1.4, and then import it in 2.1.


Two options come immediately to mind -

Exfiltration

You can learn more by Googling 'sql injection exfiltration', but generally, this involves using SQL primitives that make DNS lookups or HTTP connections.  You can build a query that selects data from a table and injects it into a host lookup to a domain that you control; then your DNS server will see the data.

This option takes advantage of the fact that while you may not have a good route to the database, it probably has some sort of route outbound.  DNS, especially, is indirect and can be used even if the DB server itself has zero Internet access.

Front End Leverage

If the database (and credentials accessible within) are backend for a front end web UI that is accessible over the network, then you can use the information to get into the app, which may be just as useful as getting into the database.


Can the wifi administrator in a shared office see mail sent through outlook?

Assuming the "WiFi administrator" only has access to the network, and isn't actively trying to attack you, I think your email is safe if properly configured.

Because they control the network, they can see all the traffic that crosses it. This would be a problem for unencrypted connections (e.g. HTTP traffic, or unencrypted POP or SMTP traffic).

However, the Google Apps Sync for Microsoft Outlook plugin specifies port 443 needs to be open for communications, and port 80 needs to be open so it can receive a certificate revocation list. This strongly indicates that TLS or some similar form of certificate based encryption is in use.

If you're using IMAP/POP/SMTP settings instead, the help page indicates that they can be configured to use encryption.

  Incoming Mail (IMAP) Server - Requires SSL

imap.gmail.com
Port: 993
Requires SSL:Yes

  Outgoing Mail (SMTP) Server - Requires TLS

smtp.gmail.com
Port: 465 or 587
Requires SSL: Yes
Requires authentication: Yes
Use same settings as incoming mail server

Therefore, if you have configured Outlook properly on your computers, the WiFi administrator won't be able to see your email content or recipients. They can only see encrypted blobs (essentially random noise).


Yep, you can do this.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowUsersToCreateEnableResyncDeleteTheirOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:ResyncMFADevice",
        "iam:DeleteVirtualMFADevice"
      ],
      "Resource": [
        "arn:aws:iam::account-id-without-hyphens:mfa/${aws:username}",
        "arn:aws:iam::account-id-without-hyphens:user/${aws:username}"
      ]
    },
    {
      "Sid": "AllowUsersToDeactivateTheirOwnVirtualMFADevice",
      "Effect": "Allow",
      "Action": [
        "iam:DeactivateMFADevice"
      ],
      "Resource": [
        "arn:aws:iam::account-id-without-hyphens:mfa/${aws:username}",
        "arn:aws:iam::account-id-without-hyphens:user/${aws:username}"
      ],
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": true
        }
      }
    },
    {
      "Sid": "AllowUsersToListMFADevicesandUsersForConsole",
      "Effect": "Allow",
      "Action": [
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ListUsers"
      ],
      "Resource": "*"
    }
  ]
}

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_delegate-permissions_examples.html#creds-policies-mfa-console


Wordlist generator for a specific pattern

The -t of Crunch is limited to predefined static character sets:

  -t @,%^

  Specifies a pattern, eg: @@god@@@@ where the only the @'s, ,'s, %'s, and  ^'s  will
  change.

  @ will insert lower case characters
  , will insert upper case characters
  % will insert numbers
  ^ will insert symbols

You could create own combined character sets by using the -f, instead.

  -f /path/to/charset.lst charset-name

  Specifies a character set from the charset.lst

Now, that doesn't work like -t and -l, but you can use it to create the suffixes. E.g. in Kali:

crunch 4 4 -f /usr/share/rainbowcrack/charset.txt alpha-numeric-symbol32-space -o suffix.txt

After that, you can use sed to append the prefix part (Passw):

sed -e 's/^/Passw/' suffix.txt > wordlist.txt

While this could be combined to a one-liner, it might be easier to understand in these two parts.


Signing data bigger than allowed RSA Block size?

Woah.  This is a bit of a mess.  Let's go through this a small step at a time.

First off: You should not be designing or implementing your own crypto protocol.  Please don't take this personally, but: you aren't qualified.  And, even those who are qualified try hard to avoid doing this, because it is so easy to make subtle mistakes.  Don't roll your own crypto.

Instead, you should be using TLS.  Just use it; it is well-vetted, there are many implementations widely available, and it solves your problem.  There's no good reason to implement something else, and every reason to avoid doing so.  It has taken many years, and countless person-decades of expert time, to iron out the wrinkles and security problems in TLS.  You simply cannot afford to do that for your own protocol and your own code.  You shouldn't even try: you should re-use the effort that's already been put into TLS.

Use TLS.  Problem solved.  Now you can spend your time on something more useful!

(To answer the question you actually asked, if you want to sign a long message, the standard method is to hash it first with a collision-resistant hash and sign the hash.  Indeed, this technique is already baked into every public-key signature scheme I've ever seen, so you don't actually need to do anything special: they already do the hashing.  [I certainly hope you aren't trying to do raw RSA signature without any padding; that's horribly insecure.]  I couldn't make any sense of your explanation you can't just use the standard digital signature algorithms; I suspect you may have confused yourself or gotten yourself twisted in knots or something.  But in any case, this is all irrelevant: you should not be designing or implementing crypto at this level of abstraction.  The best way to answer your question is to un-ask the question and point you in a different direction.)


Is it possible to detect packet content of encrypted wi-fi transmissions?

Is it possible [for the BBC organisation] to detect packet content of encrypted wi-fi transmissions?

The answer that question has to really be: who knows what secret capabilities they have?
But in regard to the question of

  can the BBC tell if I am using iPlayer?

In my opinion, yes definitely.
The reconciliation of your geo-location (obtained via your wifi) and your identity on websites has been around for a few years, standardised with the geolocation feature that I believe is part of HTML5 and accessed through javascript (on desktop browsers).
Its this combination of the wifi's geo-location and the fact that you were using this access point while logged into a website that allows the owners of a website to be able say
yes user "big rudy" was on our website and that he is the same person attached to the wifi access point "Toms wifi" located in the upstairs bedroom at 123 Main st, Surrey
 (or wherever it is)

Basically its the technology that enables the dominoes pizza delivery guy to know your exact geo-location after you only have visited the dominoes website.

I'm not saying for sure this is what the BBC are doing to catch unauthorised users on their service but this is to me, the easiest and already "industry standardised" method IMHO.

This is quite an interesting question because at first I thought why don't the BBC request a lookup to the location API provided by the google street view cars?
Again assuming that they have decided to use this technique, Why bother going to all the trouble of doing what google have already done and made available for free?  Then I realised, the reason for the vans, could be to bypass the do you allow this site/application to know your location? pop-over requirement the browsers impose on websites.

The popover is obviously so that you, the user, can decide if the website can know your location, it seems as though the BBC wish to deprive you of that right, but in order to do so, they will have to essentially recreate the geolocation platform that already exists and capture the wifi data themselves.
In case you weren't aware the google street view cars already have been sniffing encrypted wifi packets for a few years now.
Why do they sniff encrypted packets knowing that they will never get any info out of them? They don't want the info, they want the mac addresses and geo-location of the wifi access point. They get your wifi routers location through triangulation based on the strength of the wifi signal (i.e. the street view car is approaching your house and they see an essid of Toms wifi with a signal strength of x, they then make a note of that signal and its geo-location, they get a bit closer to your house and see the signal is now 2x they make a note of that,  then as they go past it gets weaker, they turn a corner and if Toms wifi appears again, they keep updating their data, combine using simple trigonometry (triangulation) and now they have an accurate location of your  - at this point - anonymous wifi access point.
Note: on mobile devices you generally don't need to go to all this work to get a users location, when its easier just to query the builtin GPS, but on laptops and desktops using wifi, the only other location revealing technique is ipaddress which would struggle to even predict your city with any accuracy.

The next piece is to reconcile your  online identity with the wifi access point, I believe this is done by by using an "agent" i.e. a browser - which is already inside your otherwise private network, to query the MAC address of your access point (I suspect this is how its done, but I'm not sure - perhaps someone more knowledgeable could confirm/deny this?) a external service on the internet otherwise couldn't initiate a query/scan of your internal network - your network config wouldn't allow it)

At this point the "agent" (browser) is now capable of performing a lookup to google street view data API - which will then tell it the location of the wifi access point the computer/browser is connected to, then the browser avails this information to the web application via javascript.

Again, this is just my theory, but it seems to me this could be how BBC are tracking their users and why they need the vans.


Securely retrieving and exposing configuration within Docker

Generally the best approach to secrets management in containerized environments is to make use of some form of secrets management software.  In essence most of these solutions comprise an encrypted database and a mechanism for containers to be provided with specific secrets at run time based on a provided identity.

In Docker this can be leveraged in swarm mode using the docker secret command.  Another alternative to this would be to use Hashicorp Vault or one of the other secrets management tools that are available.

Also within an AWS environment it's possible to use something like their CloudHSM feature from within Docker containers (more information here)


Intrusions attempt monitoring (on MacOS X)

I'd advise you to start searching for "log analysis" on this forum.
(Then refine your initial question to get better answers.)

Most of the discussions on this topic and on any different Unix will build
on top of Mac OS X.

You could start by this one which is focusing a larger target than your one: How do you handle log analysis?

I advise you to install logwatch, which you can do with either MacPorts, or the traditionnal way: tar, configure, make….

To be more on the active side, I advise you to install fail2ban,
which you can also do the same 2 ways and Brew.


How can I protect my internet-connected devices from discovery by Shodan?

Shodan references publicly available machines which work like this:

Just don't do it.

Edit: analogy is relevant ! Shodan connects to machines and asks for their "banner", a publicly available text which may simply say: "to enter, use this default password: 1234". You might want to avoid people knocking at the door by the simple expedient of installing a giant squid as a guard before the door (metaphorically, a firewall), but, really, it would be much safer to configure a non-default password.


How does a client know an SSL cert has been signed by a CA if the client doesn't have the CA's public key?

When the client is verifying a certificate, there are three possibilities:

The certificate is signed by a CA that the client already trusts (and for which it knows the public key). In this case the client treats the certificate as valid.
The certificate is signed by a CA about which the client has no knowledge at all. In this case the client treats the certificate as invalid (and the browser will likely display a warning message instead of loading the page).
The certificate is signed by a CA that the client doesn't know, but which has a certificate that is signed by a CA that the client does know. (In this case the server must usually send both its own certificate, and the certificate of the CA - called the "intermediate CA" - that signed its certificate). Since the intermediate CA's certificate is signed by a CA that the client already trusts, it knows can trust it, and since the server's certificate is signed by the intermediate CA, the client knows it can trust it too.

Note that CA certificates are "special" - just because you have a certificate signed by a trusted CA, that doesn't mean you can then sign other certificates and have clients trust them - unless your certificate is marked as being valid for signing other certificates.


For the average user in a western country who buys from an established vendor the risk is likely low. Vendors typically set up all systems the same way with a common image and thus any compromise would affect a larger user base and thus gets probably quickly noticed.

But if the government is interested in messing with you then the risk is much higher.  It is known that government agencies might divert shipments in order to manipulate the content. If there is such a targeted attack against you it is likely that you will not be able to figure it out by running some common scans or doing common checks since they would make sure that the attack is not that obvious.


a single ip adress host multiple domain at the same time, how do i scan it using nmap or other tools?

...  i wanted to scan it port

Port scanning essentially checks if a port is open on a specific IP address or not. For this port scanning it does not matter if there are multiple hostnames for the same IP address: the scan result will not change since the hostname is not relevant for the scanning in the first place but only the IP address.
The situation is different if one wants to get application level information though, like the contents of a website on a specific domain, the certificate returned etc. Here the hostname can make a difference, depending on the protocol. Notably for HTTP the hostname is given in the HTTP Host header, for TLS it can be given as SNI in the TLS handshake and for HTTPS both TLS and HTTP information are relevant.
For scanning at this level one first needs to know the relevant hostnames for this domain, i.e. there is no automatic mapping from IP address to all available hostnames. And the choice of tool then depends on what one want to extract as information - there is no generic tool to extract everything. A simple wget or curl is sufficient to get the contents of a website and openssl s_client can be used to get the certificate for example.
But again, all of this is not about port scanning anymore since if a port is open or closed does not depend on the actual hostname, only on the IP address and port.


Security risks replying to emails using a personal account

There are a number of reasons that replying to an email from someone you don't know may be a bad idea in a business context:

In some situations you may see a "from" email address that is spoofed, with a different reply email address. In such a situation you may reply to the "from" email address under some assumption of who they are, when in reality you're talking to someone completely different.
If the sender is a spammer, you're revealing that your email address is active.
If the sender is gathering intelligence, your email signature may reveal your name, phone number, job title, department name, or other internal details.
If the sender is trying to phish you, replying allows them to better tailor their phish and determine if you saw through the pretext.

Ultimately it's down to you to think about the context of the situation when you're replying. Check that the email your sending is going to the same address the original was from (when you click reply it'll fill the reply-to email in the 'to' field) and think about whether you might be unintentionally revealing information about yourself.


How do we know if the hard disk we just bought is "clean"?

Given a sufficiently smart adversary with significant resources, you can't.

There are five potential attack vectors:

Malware on the disk within a partition.
Malware within the boot sector.
Malformed partition or filesystem structures that exploit bugs in your OS (example)
Malware within disk firmware.
Modified hardware (e.g. replace the firmware PROM with mask ROM containing malware)

Malware on a filesystem on the drive is easily defeated by formatting the disk when you get it.

Boot sector malware is a little trickier. Whilst an OS install would overwrite the boot sector anyway, this doesn't apply to drives that are going to just be used for data. This kind of thing can be fixed by doing a low-level wipe of the disk with dd or a similar tool, or by re-writing the boot sector with a disk maintenance tool.

Malformed partitions or filesystems can be killed with dd, but then you still have to get into an OS to run the command. It's a good idea to do the first format operation from a Live CD with no other persistent storage attached.

The modified firmware issue is a very tricky one. We know that hard disk firmware can be modified, and there are surely patch vectors from the OS level. Detecting malicious firmware is a tricky task, and you can only really get assurance of firmware integrity by manually (i.e. at the electrical interface level) overwriting the firmware with a manufacturer-supplied and digitally signed firmware image. Since you'd be interfacing directly with the EEPROM, and would be able to read the image back and verify its integrity, you'd have strong assurance that the "safe" firmware was written. This doesn't fix the problem of backdoors at the manufacturer's end, though.

Finally, there's the potential for modified hardware. In such a case, the firmware EEPROM could be ignored in favour of a mask ROM, stored either externally or inside the controller IC package, so that flashing the firmware seems to work but does not actually succeed in changing the firmware code that is actually executed by the device.

At the end of the day, though, does it even matter? Most of the time you're going to get a clean hard disk, and things have to be going very wrong somewhere in the world if you end up with boot sector malware on a signed-and-sealed disk. If an adversary can find out that you've got a hard disk on order from Amazon, get another of that exact drive, backdoor its firmware or hardware in a useful way, break into the delivery truck, and replace the disk with a modified one without anyone noticing, then you are screwed no matter what.

In summary, I'd like to quote from an excellent paper by James Mickens:

  If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https://. If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that’s shaped like a cellphone, and when you die of tumors filled with tumors, they’re going to hold a press conference and say “It wasn’t us” as they wear t-shirts that say “IT WAS DEFINITELY US,” and then they’re going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them.


What are the weaknesses of WPA with TKIP?

Here's a relevant excerpt from a blogpost I did on here a few months ago:

WPA generally uses Temporal Key Integrity Protocol (TKIP). TKIP was designed by the IEEE 802.11i task group and the Wi-Fi Alliance as a solution to replace WEP without requiring the replacement of legacy hardware. This was necessary because the breaking of WEP had left WiFi networks without viable link-layer security, and a solution was required for already deployed hardware. TKIP is not an encryption algorithm, but it's used to make sure that every data packet is sent with a unique encryption key.

An excerpt from the aircrack-ng paper, Practical attacks against WEP and WPA:

  TKIP implements a more sophisticated key mixing function for mixing a
  session key with an initialization vector for each packet. This
  prevents all currently known related key attacks because every byte of
  the per packet key depends on every byte of the session key and the
  initialization vector. Additionally, a 64 bit Message Integrity Check
  (MIC) named MICHAEL is included in every packet to prevent attacks on
  the weak CRC32 integrity protection mechanism known from WEP. To
  prevent simple replay attacks, a sequence counter (TSC) is used which
  allows packets only to arrive in order at the receiver.

There are two attacks known against TKIP:

Beck-Tews attack
Ohigashi-Morii attack (which is an improvement on
the Beck-Tews attack)

Both of these attacks only could decrypt small portions of data, compromising confidentiality. What they can't give you is access to the network. To give you an idea of how much data can be recovered, a single ARP frame would take around 14-17 minutes to get the plain text. Getting useful information with this type of attack is very improbable (but not impossible) considering the rate of recovery.


HPKP-based persistent denial-of-service attack on web sites

Reading through this memo, a link is given to the un-pin draft of Perrin here. I see two countermeasures against the scenario which you describe in this draft:

Let's start with the first one, which can be interpreted in different ways:

  Whenever a client performing "pin activation" sees a hostname and TSK combination not represented in the "pin activation" pin store, an inactive pin is created. Every subsequent time the client sees the same pin, the pin is "activated" for a period equal to the timespan between the first time the pin was seen and the most recent time, up to a maximum period of 30 days.

In my interpretation, the implementation of the above paragraph would mean that an attacker can only activate new pins for a very limited timespan. However, the attacker could still revoke older pins, it seems. Therefore, we move on to the second countermeasure described:

  Nonrevokable tacks:
  A tack with generation 255 cannot be revoked. Such tacks MAY be used to minimize the risk that a compromised TSK private key could be used to affect site availability.

Thus, a server that has issued a non-revokable tack, could in fact keep using this tack forever. How I read that is that a server could create a key pair which is does NOT use, but for which it creates a non-revokable tack. (In Perrin's implementation, this would become one of the maximum of two PINs which cannot be deleted). In case the server is compromised, this key can be retrieved and used to undo the attacker's changes.

Whether or not this is implemented in current browsers, I don't know.

Edit:
As @StackzOfZtuff pointed out in one of the comments, there is actually a transcript of an email conversation between IETF:WEBSEC and Perrin, pointing out to implement a TACK-like mechanism for HSTS.


Youtube.com trying to extract HTML5 canvas data: is Youtube trying to fingerprint users' browser?

Likely not, but you can never be sure.

First, why does a website "attempted to extract HTML5 canvas image data"? The HTML5 canvas element allows manipulations of 2d images with Javascript. Among many other operations, it can draw images or videos to the canvas and then manipulate them on a pixel-by-pixel level. While there are lots of legitimate uses for this, it can also be used to detect subtle differences in how different web browsers render images, videos and text to gain information about the users web browser. That information can then be sent back to the server.

Youtube includes quite a lot of Javascript code, and most of it is heavily minified. That makes auditing it next to impossible. But I found 4 cases of the .getImageData function which is used to extract canvas data in the file base.js.

a=a.o.getImageData(c,d,e,f).data;for(b=0;b<a.length;+=4)if(255<a[b]+a[b+1]+a[b+2]+a[b+3])return!0;return!1

This appears to check the overall brightness level of a part of the image and detects if it is "bright" or "dark".

f=e.getImageData(0,0,b,c),k=b*c,l=0;l<k;l++){var m=4*l;f.data[m]=f.data[m+1]=f.data[m+2]=Math.floor(35*Math.random());f.data[m+3]=255}e.putImageData(f,0,0);

This replaces the whole image with random gray noise and writes it back to the canvas. I suspect it's part of the code which creates the background for the "this video can not be displayed" error message.

b=b.getImageData(0,0,1,1).data;return b[0]==b[2]&&b[1]==b[3]

This part of code appears twice. It checks if the first pixel of the canvas is a greyscale color.

None of these snippets looks suspicious and appears to be plausible use of this feature in the context of a video player. But taking a glance at the minified mess this is and how much code there is, it is hard to be sure that there is no situation in which it leaks any information to a server. Also, just because I got Javascript with just these 4 cases, it doesn't mean that you will get the same. They could sent different javascript to different users depending on a million of variables.


Blacklist IP addresses based on number of 404s in Apache

Fail2ban does exactly what you ask.

It monitors your log files looking for certain patterns and then executes whatever action you specify. You can block an IP for a length of time.

It does require some skill in regex, but it comes packaged with regex testers.


Is it possibel to inject php code to roundcube errors log file via LFI vulnerability?

The short answer is: no. Stored code injection and LFI vulnerabilities are 2 different kinds of vulnerabilities.


what is the usage of extendedkeyusage in a CA certificate?

CA certificate itself is never used during authentication, instead it is used for chain validation (I'm not talking about signing). In most cases, applications check particular EKU presence in end-entity certificate only. Thus, EKU presence in CA certificate has no effect.

There are known vendor-specific implementations when EKU in CA certificate has effect. This is called "constrained EKU", when application verifies whether particular EKU is valid for entire certificate chain and reject the certificate if particular EKU is presented in end entity certificate, but not specified on CA level in non-empty EKU extension.

For more details, please read my blog post about constrained EKU implementation in Microsoft certificate chaining engine: https://www.sysadmins.lv/blog-en/constraining-extended-key-usages-in-microsoft-windows.aspx

very brief explanation, in this thread: Root CA with Extended Key Usage fields


Is it normal for a website to show an API key in plain text that allows full access to your personal information?

"Normal" may be the wrong choice of words for your question. The real question is... "Is it secure?"

Breaking the question into different parts, here's my take at an answer:

1. Is it secure for a site to provide me with an API key?

Providing you with your own API key isn't a problem, since it's your key. This is true as long as the page is served using https. Serving the page unencrypted would allow anyone between you and the web server to also see your API key.

2. Can an API key be passed via URL and still be kept secret?

No. Passing an API key via the URL means that key is stored in the server's logs, in a browser's history, visible to browser extensions, accidentally copied / pasted by a user, etc. It is no longer a secret. This is true even if the page is served via https.

3. Does an API key need to be kept secret?

This question may be a good one to explore. Maybe the service you're referring to provides an API key and a Secret key. The API key can be exposed via URL but the Secret key must be used to calculate a certain header that must also accompany the request.

Another example might be an API that's expected to be called via JavaScript. In this case, anything in code will be exposed to the client. Again, the service provider may expect a key that is derived from your secret key to be passed via the service.

Alternatively, maybe none of the keys are secret but the service employs IP address whitelisting to ensure that the keys can only be used by your server. They could also do hostname checking and allow you to specify valid hostnames in your account that the key is allowed to be used for.

Summary

Ultimately, the technique that a service chooses to use to protect its keys and secret keys should match the need to keep them secret, or the need to protect unauthorized users from calling the service. In some cases it doesn't matter if someone uses your keys to call the service.


Now comes the HTTP_PROXY. How does HTTP_PROXY environment variable will cause an attack?

It does not by itself cause an attack. But, the environment variable HTTP_PROXY is used by many applications to configure the proxy used for HTTP requests. And, since it is an environment variable it will be propagated to child processes too. This means that an external attacker can control the HTTP proxy to be used by internal code, i.e. the CGI script, PHP code itself or applications executed from within this code.

This can lead both to potential information leakage where sensitive data destined for internal applications are sent to the proxy controlled by the attacker. This can also cause the application to trust content fully controlled by the attacker (i.e. returned by the proxy) which then depending on the application can have various effects, for example executing code controlled by the remote attacker.


Why fingerprint a browser if a fingerprint can be replayed?

Passive fingerprinting can easily be faked, and it is trivial to code responses that can pass passive fingerprinting. And yet, it can still work because not every bot includes this feature because not every target fingerprints. It's a pure cost/benefit scenario.

Active fingerprinting takes more complex coding to spoof, and not all bots have the facility (or space) to include this level of deception and do it effectively.

Security controls are based on a concept of risk. You employ a control to bring the risks down to an acceptable level (risks cannot be eliminated entirely). So, given the threats you face and the impact you want to prevent, can the given control reduce the risk? That's the question.

Since the threats (bots, in your case) at this point in time do not often include fingerprint deception, then passive fingerprinting can have a positive effect on your risks. It doesn't matter what the threats could do in the future or what they could be doing now but aren't.

"But what if bots get really good at deception?" Then you need to re-assess the risk at that point. But you cannot then make the leap to conclude that the control has no value now. Controls are effective against specific risks in a threat scenario. Just because they might not be effective in other risk contexts does not make them poor controls. There is no silver bullet.


Multiple Versions of SSL Signing Certificate

So are there actually two different legitimate versions of the VeriSign certificate which can be used to sign the same child certificate?

Signing is done by the public key in the certificate. Both certificates have the same  public key, so both can be used to verify the signature. The difference is that  18:da:d1:9e:26:7d:... is issued by itself while 25:0c:e8:e0:30:61:2e:... is signed by C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority.

Such setup is common if one wants to introduce a new root CA, like when switching the quality of the public key, i.e. 1024 bit to 2048 bit. Since it takes some time to get this new CA trusted everywhere one first signs the new root CA by an existing trusted root CA so that browsers can verify the trust path. Once this new CA is established one can abandon the old root CA.


The keys can be either stored on the device, or encrypted and returned in the key handle. Both are allowed (and mentioned) by the spec.
From the implementation considerations:

U2F tokens might not store private key material, and instead might
export a wrapped private key as part of the key handle.

Also in the raw message format specification:

A key handle [length specified in previous field]. This a handle that
allows the U2F token to identify the generated key pair. U2F tokens
may wrap the generated private key and the application id it was
generated for, and output that as the key handle.

This leaves the decision to the manufacturer of the U2F device.
Yubico chose to return the encrypted private key as the key handle, allowing an unlimited number of credentials.
If a device manufacturer chooses to store the private key on the device itself, the number of possible keys will be limited by the amount of storage available. You'd have to look at the specs for a specific device.


Implementing Secure Remote Password: Constructing the verifier

SHA-1 is not an ideal hash function (actually, neither are the SHA-2 functions). The double hash invocation hides a few of the internal shortcomings of SHA-1. This is similar to HMAC, which also uses a double hash invocation for pretty much the same reasons. In more details, we want the function which maps the username-and-password to x (function selected by the salt among a family of functions) to behave like a random oracle, and the normal security properties of hash functions (collision resistance, preimage resistance) are not enough to guarantee such behavior.

The username is involved so as to make security proofs easier: it allows the security analysis to concentrate on a single user, without having to account for what happens when a given server accepts several users, each with his own password. The separator participates to the same goal: otherwise, "john" with the password "ny67dtzo" and "johnny" with the password "67dtzo" would live in the same world, security wise.


I understand that during boot, each boot stage passes "something" to TPM

That "something" is the SHA-1 hash of the component being measured. The first thing sent is the hash of the BIOS. Subsequent hashes cause a register to "update" its hash. The TPM only unseals if the final hash matches what it expects. That final hash will only match if all hashes sent to it prior were correct.

This is typically how it goes for a traditional x86 system with a TPM. A BeagleBone is similar.

The CRTM, which is read-only, sends the hash of the BIOS itself to the TPM.
The BIOS sends the hash of the option ROMs, MBR, and bootloader to the TPM.
The bootloader sends a hash of the kernel and boot parameters to the TPM.

If all the hashes were correct, then the final hash will match what the TPM expects. The TPM is then free to unseal, which means decrypt an arbitrary blob of data passed to it. This blob of data, when decrypted, proves to the sysadmin that nothing in the boot chain has been compromised. As long as the attacker does not know the contents of the decrypted blob, they cannot spoof it, even if they have tampered with the BIOS and have full control over how the system is to behave. This decrypted blob can either be used as a disk encryption key, or displayed to the sysadmin, indicating that it is safe to trust the firmware.

  I believe there is a flaw in my logic or I failed to grasp some crucial detail, because AFAIK BIOS (first stage in aforementioned chain) can be overwritten with new image, which means that attacker with physical access to the machine could circumvent any security measures taken by machine owner.

There is a part of the BIOS called the boot block, or CRTM (Core Root-of-Trust for Measurement), which is not writable by software. An attacker would need to have physical access to replace the chip which holds the firmware. The CRTM is in charge of sending a hash of the rest of the BIOS to the TPM. This prevents a privileged local (not physical) attacker from bypassing the root of trust by writing the BIOS.

See also How does the TPM perform integrity measurements on a system?.


MitM attempt resulting in ICMP redirects

In my experience this

sysctl -w net.ipv4.conf.all.send_redirects=0

will not work properly on some systems what works for me is

echo 0 | tee /proc/sys/net/ipv4/conf/*/send_redirects


Why is it possible for all programs / apps to see all network traffic?

Sniffing network traffic is typically a privileged action. An unprivileged user does not have the ability to perform a packet capture by default.

You have outlined two scenarios (HTTP Canary and Wireshark) that require special privileges. In the first case, HTTP Canary must be explicitly enabled as a VPN by the device owner. An app cannot obtain this privilege on its own, and a user should not grant this privilege to an app that they do not trust to view all of their traffic.

In the second case, an unprivileged user cannot sniff using Wireshark without extra privileges. On Linux, this means being a member of the system "wireshark" group, or running it as root. On Windows, I believe this requires a driver installation that needs administrator privileges.

Since it requires extra privileges anyway, I don't think it really is a concern related to sandboxing. To conclude, packet sniffing is not something trivial that any application can do without acquiring special privileges. Even then, lots of traffic will not be visible since HTTPS is used almost universally.


Are there actually any advantages to Android full-disk encryption?

The advantages are limited, but there are nonetheless scenarios where encryption helps.

In any scenario where the attacker obtains the password¹ (with lead pipe cryptography, or far more realistically by reading the unlock pattern on the screen or brute force on the PIN), there is clearly no advantage to full disk encryption. So how could the attacker obtain the data without obtaining the password?

The attacker might use a software vulnerability to bypass the login screen. A buffer overflow in adbd, say.

The attacker may be able to access the built-in flash memory without booting the device. Perhaps through a software attack (can the device be tricked into booting from the SD card? Is a debug port left open?); perhaps through a hardware attack (you postulate a thief with a lead pipe, I postulate a thief with a soldering iron).

Another use case for full-disk encryption is when the attacker does not have the password yet. The password serves to unlock a unique key which can't be brute-forced. If the thief unwittingly lets the device connect to the network before unlocking it, and you have noticed the theft, you may be able to trigger a fast remote wipe — just wipe the key, no need to wipe the whole device. (I know this feature exists on recent iPhones and Blackberries; presumably it also exists or will soon exist on Android devices with full-disk encryption.)

If you're paranoid, you might even trigger a key wipe after too many authencation failures. If that was you fumbling, you'd just restore the key from backup (you back up your key, right? That's availability 101). But the thief is a lot less likely to have access to your backup than to your phone.

¹  Password, passphrase, PIN, passgesture, whatever.


If you own/trust the Reverse Proxy, Load Balancer, and Intended Server(s) then:

Your client mobile phone has the client certificate (through some secure means) which it uses to authenticate to the Reverse Proxy.
The Reverse Proxy handles the SSL/TLS decryption, then forwards the traffic onto the Load Balancer and the intended server (unencrypted).
Load Balancer and Intended Server are hidden from the internet behind routers/firewalls.

The Reverse proxy is configured to only allow connections from the allowed client certificates.

Alternatively all the SSL traffic could be passed through the Reverse Proxy and decrypted on the Load Balancer or Intended Servers, but that only allows IP based load balancing.

Unless I am misunderstanding some part of your protocol, I am assuming here that the Certificate you are talking about is for Authentication to the SSL/TLS website and not some other certificate.

Edited to add:

You added a comment above to explain that it is the initial certificate creation (CSR being signed) that needs to be encrypted.

In this scenario you need to determine what initial authentication you require.

Are you tying the certificate to a real world or prior identity? Then apply some authentication such as username/password through the SSL tunnel to initially create it.
But if you are just creating a random certificate to hang a new identity on, then SSL/TLS from mobile app to server should be OK, verifying the server certificate first is probably a good additional security measure.


The QR code contains the key used for HOTP or TOTP, so it must be kept secret. If someone gets a picture of your QR code when you're setting up your authenticator, they'll have the key and will be able to generate valid 2FA codes.

The reason this is more secure than SMS is because it's encrypted in-transit by TLS, whereas with SMS it's been publicized many times how it can be intercepted. This prevents remote attackers from getting the QR code, but you are still responsible for keeping it secret from anyone around you (ie you shouldn't set up your authenticator in a public area).

You can read a bit more about how HOTP/TOTP apps work here.


How does a CSRF logout pose a potential threat to a website?

The only threat I see there is someone logging a user out by CSRF to force the victim to enter his credentials again. But this would only be useful if the attacker had a way to capture the credentials. This would require one of these possibilities:

The attacker has found a XSS weakness in the targeted website that allows extraction of credentials by changing the action attribute of the form for example
The attacker is able to perform a MITM attack on the victim and the targeted website does not support SSL so the credentials can be captured in cleartext
The attacker has direct access to the clients PC and has installed a keylogger which will then capture the credentials

In most cases CSRF logout won't be a serious threat at least not compared to other vulnerablities that can be found in many webapplications.


IP addresses readily available on black market?

Is it feasible to find a list of user IPs used by an account? The answer to that is a "It depends on the user" answer.

The Effort Required

In a simple DB dump(those most common lists you mentioned with email,password) that list was often generated by an insecure page with an injection vulnerability. Often at that point the attacker doesn't have any console, file system, or other access. They merely obtained a copy of the table itself and that table more than likely doesn't store that information since it could be a many to many relationship, and usually exist on a separate intranet server if they do have that regional fraud detection in place at all.

A much more in depth, risky, and difficult attack would then be needed just to LOCATE the data. Then you need to attack to try and get the data. Often it isn't worth the risk unless you're expecting a huge payoff or have found horrible security practices in the first place. If the security is that horrible though it probably wouldn't be a system that even stores that information or has regional fraud detection systems in place.

The Alternative

A much more simple way to do it is to email each user a spear phishing email with something to make them make a request to your server to collect this information. This is a much simpler attack with a smaller payoff, but still a payoff nonetheless. It's easy enough to do on your own with just a simple email/password list and well designed enough phishing server with convincing enough pages/links.

At this point since it's so simple it's kind of a "If we have it we got lucky" situation, or a "DIY" situation. These systems are often complex, and sometimes offloaded entirely making the attacks to find that information hard to near impossible.


Is there any security benefit to separating an RFID chip from an ID badge?

Yes, because if you have them together and lose them anyone could walk in with your credentials. Security guards rarely match faces to cards, chances are anyone looking remotely like you would have free access.

Here's a scenario:
Employee A is going on vacation for 2 weeks. During his celebratory drinks he drops his ID+tag dongle, which he also has his unencrypted company issued USB memory stick also conveniently connected to. Unsavory character 1 picks up this handy combo, and seeing that his friend, unsavory character 2, looks a lot like this drunken idiot, and overhearing that he's going away for 2 weeks, decides to give it to UC2, who uses it to steal all sorts of company property. That's why having both together is a very bad idea.


Yes, these locks can have repeated first and third digits, which occur about one in 10 times.  See Samy Kamkar's page on Master locks to learn more about them.


Basically you would need to prevent any packet from internet reaching switch CPU, except for the allowed hosts, so basically this can be done with policy, which works on the hardware level, before reaching the switch. Such policy would work the way, that you need to collect the public ip numbers of the switch, let's say 192.168.0.1/30 VLAN 10 connects you to the internet and 10.0.0.0/24 VLAN 20 is with servers, so this way you can apply the following policy. Best is to deny everything, and allow only specific hosts you need, than you will be seriously stable and secure.

This is simplified policy with one chain for ingress and egress:

# 192.168.0.2/30 - other router (VLAN10)
# 192.168.0.1/30 - your router  (VLAN10)
# 10.0.0.0/24    - servers      (VLAN20)
# 10.0.0.10/24   - you          (VLAN20)

#Allow Broadcast only on VLAN20, so you dont have malicious broadcast from other router
From Any To ff:ff:ff:ff:ff:ff VLAN 20 Permit

#Allow Multicast only on VLAN20, if you need it for VRRP you can add the rule for VLAN10
From Any To 224.0.0.0/4 VLAN 20 Permit

#Anti-spoofing rules for your servers
From 10.0.0.0/24 to 0.0.0.0/0 VLAN20 Permit
From 0.0.0.0/0 to 10.0.0.0/24 VLAN20 Permit

#Allow accessing (e.g. pinging the other router) for your admin
From 10.0.0.10/32 to 192.168.0.0/30 Permit
From 192.168.0.0/30 to 10.0.0.10/32 Permit

#Block any other VLAN to VLAN communication
From 10.0.0.0/8 to 10.0.0.0/8 Deny
From 192.168.0.0/16 to 192.168.0.0/16 Deny
From 10.0.0.0/8 to 192.168.0.0/16 Deny
From 192.168.0.0/16 to 10.0.0.0/8 Deny

#Allow internet for 10.0.0.0/24, this allows packets from and to internet go thru VLAN10
From 10.0.0.0/24 to 0.0.0.0/0 Permit
From 0.0.0.0/0 to 10.0.0.0/24 Permit

#Deny them all, this includes access to VLAN10
From 0.0.0.0/0 to 0.0.0.0/0 Deny

With this, others wont be able to tranceroute or ping your switch. But at the same time, you are way much better protected with potential denial of services, as your Switch OS is isolated. This is good in some scenarios.

Also, some switches do have hardware counters, so they allow only limited number of packets from specified host to reach the CPU. This way the rule could be to count ALL packets reaching from Internet (except your admin machine) and to limit them ALL (from any host) to e.g. 10 packets per second. This would be useful for ICMP, so you can still traceroute.

From Any to 192.168.0.1/32 Protocol ICMP Limit 10 packets / second
From Any to 192.168.0.1/32 Protocol ICMP Allow
From 192.168.0.1/32 to Any Protocol ICMP Allow


Does a leaked pre-shared key make the initial IKE phase 1 negotiation of Diffie Hellman vulnerable?

Yes, which is why people employ an attack called "Aggressive Mode IKE PSK Cracking".


I take it you have a situation like this:

That is what OWASP calls inserting "into HTML element content" in their cheat sheet. To get anything done in thet context you will need to open a tag, so you will need a <. Without that, you are toast at that specific location.

The protection they are using seem to be some weird sort of homebrew that does multiple things at once without any real strategy. But it does look like it replaces all < with &lt;. You should try the usual stuff like mixing case, throwing in whitespace at unexpected places, or using different tags (e.g. an image with onload). But if you cant get a < in there, you are not going to get anywhere.

I wouldn't be very hopeful to get anywhere at that specific injection point. But since the defence looks a bit haphazard I would keep looking for other injection points. Perhaps inside a HTML attribute, or maybe in a comment or a script tag or something like that.


How To Track Down Who Initiated A Remote File Transfer Via TeamViewer If I Have Log File

Firstly, if you used the password save function in chrome, your in trouble. Essentially, chrome has no security wrt the password save feature. Immediately change all your passwords! I would recommend also enabling 2-factor authenticaiton on any sites which support it i.e. google, itunes, dropbox etc.

I'm not sure what the number in {} is, the last part might be a MAC address. HOwever, as it is trivial to spoof both MAC addresses and IP addresses, you are unlikely to be able to track down the source. Even if you could, more than likely they are in a different country and trying to do anything legally will be near impossible. Certainly report this to your IT area (if you have one) and you can report the incident to the police, but don't expect much action. They are generally either under resourced or just overwhelmed with such cases to really do much other than record the incident for stats etc (which is important for things like getting more resources).

I would also be rather concerned about how they gained initial access. While you cought them in the act of downloading files, you can't be sure they haven't done other things or for how long they have had access to your system. In general, once a system has been compromised, the best thing to do is re-image it and start with a fresh known good system, though be careful restoring data from any backups you make as you don't know when you were first compromised and you may have backed up compromised files etc.

To be on the safe side, you should also report the incident to your bank. They may be able to put a watch on your accounts or may decide to change your account details etc. As you also lost a copy of your CV, watch out for any signs of identity theft. This could include unusual/unexpected contact from banking and other financial institutions, unknown bank or credit card transactions etc. One reason to report such incidents is to ensure it is on the record in case you run into identity theft issues at a later date.


iDevAffiliate vulnerable to a file upload, how can we limit the damage?

It shouldn't really matter if a user is able to upload a PHP shell; you shouldn't ever be executing user-uploaded files. That is, separate them out into an entirely different area than your code so that the webserver won't interpret them. You can do this with scoped config rules, depending on your webserver, but an even better approach is to put them directly onto a separate datastore (say, S3) and use a separate domain to serve them, either directly from that service or via a CDN as intermediary.


Does turning off an iPhone make it safe from "juice jacking"?

Not really — depending on your phone

"Juice Jacking" works by offering a malicious user an approach vector to gain access to your phone during the charging process by leveraging the USB data/power cable to illegitimately access the phone’s data and/or inject malicious code onto the device.

Only a few devices don’t expose the data if you power them off completely. Some phones will, despite being powered down, still power on the entire USB circuit and allow access to the flash storage in the device.

The problem is that most smartphones are configured to just connect and dump off data, so anyone who has malicious intends could put a system inside of one of these kiosks that when someone connects their phone can suck down all of the photos and data, or write malware to the device. Some phones are even accessible even though you configure the USB transfer to be "off". As soon as you plug them in, they might instantly switch into USB transfer mode.

Tips

The safest route for charging your device is to use the supplied power cord that plugs into a regular electrical outlet.  If you must use a random charging kiosk, the safest option may be to completely power off the device before plugging it in. Yet, depending on your phone, that's no guarantee that you won't be leaking data.

To add security, you should lock your phone. When your phone is locked (truly locked, meaning "inaccessible without the input of a PIN or equivalent passcode") your phone should not pair with the device it is connected to. iOS devices will only pair when unlocked.

Another option would be to jailbreak your iOS device to lock and unlock the device’s pairing capabilities with tools like "pairlock" (http://www.zdziarski.com/blog/?p=2307).


Any open port is susceptible to probes/attacks, it all depends on what service/application is running on it and how vulnerable is that service/application itself.

For VPN:

If using application, you need to find out how vulnerable is your VPN application.
What cipher suits are used.
Implement strong authentication measures.
Keep log of connections.


SSL certificate issued in my company's name instead of twitter.com

If for some or all SSL sites you're seeing the certificates as being issued by your employer, it's likely that they are using an SSL intercepting proxy (e.g. BlueCoat).

These systems are designed to allow the company to inspect traffic going over their Internet connection even when it is SSL encrypted.  This can be done for purposes of malware scanning and/or content checking for things like content which breaches the company's Acceptable Use Policy.

Depending on your country of operation there may be restrictions on what they are allowed to legally intercept and you should also have been notified (likely when signing your employment documentation) that this connection would be monitored.

If you want to access Internet based resources without this risk, the best bet is to use a device that you own and operate yourself.


Is not installing skype a better option than installing skype with a special group & user?

As always in computer security, not installing something is more secure than installing something.

Whether or not you choose to install skype is a cost-benefit exercise: do you believe that skype is doing something dangerous - and how much are you prepared to accept that it might, versus the benefit of using the service?

This is a decision only you can make - my only comment would be that just because Skype is obfuscated, doesn't mean it is malware. Moreover, you're trusting a huge number of other packages on the system as it is.

Now, onto some technical observations. Whilst it is certainly possible for an engineer to obfuscate the machine code in their executable, it is much harder to compensate for the fact that the binary must make system calls to the kernel to get things done. This means that you can analyse these calls, and look into them. As I understand it, skype resists ptrace (and so strace), but you could easily build a LKM hooking the system calls you wish to dump - that Skype cannot stop. From there, you could audit exactly which files skype open()'d, and so on. I've never done it - and there'd be a fair amount of coding involved (you'd get all open calls and need to filter for a given set of PIDs), but it isn't impossible.

The next technical observation to make is that the Vanilla skype presentations attached to your first link have documented the process of attempting to remove the copy protection from Skype - so I think it's unfair to say "nobody knows what it does". We have a reasonable understanding, albeit with gaps.

To answer your question - running Skype as a separate user will provide you a level of security against skype evesdropping on your documents under the following caveats:

You never hand it elevated privileges.
There are no known or unknown security vulnerabilities present anywhere in any executable on your system that skype may run to escalate its privileges or obtain your privileges.

The reason for these should be straightforward - if you run Skype as root, it can do anything. If you have a vulnerability, Skype may be able to exploit it, assuming Skype is malicious.

I've looked at this myself, and personally I suspect that the high level of obfuscation in Skype is used primarily to protect the intellectual property used in Skype - making it difficult to reverse engineer it - rather than to hide anything nefarious. After all, a reputable software vendor distributing nefarious code who is detected risks damaging their reputation considerably.


Just like piracy, you can't really stop it. Use legal means like the DMCA and C&D letters to stop the other person, or report it to Google once you find out.

Google might have features that check the hash of an app to see if it's a copy of another person's app, but they might not. Understand that there's nothing that you can do if you don't know a fradulent app exists - if you find one than do whatever it takes to get his app off the market.


Can I generate a random 32 bit key by using the Java hashCode and random English words?

In short words: it won't work well.

In longer words: Java's String.hashCode() method has biases; it works by repeatedly multiplying a running state by 31, then adding the numerical value of the next character. Letter usage in English is biased, groups of letters are biased, and these will show up. In other words, you lose some entropy.

Arguably, going through a list of words is a very weird thing to do. To choose a random word in a list of 100000 words, you must have a way to uniformly obtain a number in the 0 to 99999 range. Why, oh why, would you not use that value directly ? Why turn numbers into words, then hope that the hashCode() method will turn them back to numbers without losing too much entropy in the process, instead of just using the numbers directly ?

If you can generate a uniform integer in the 0..65535 range, then... that's it. You have a perfectly fine random 16-bit integer. Generate two of them, shift one of them by 16 bits, combine with bitwise OR (or with an addition), and you're done.

Also, a 32-bit key is atrociously weak, by nature, since it can have only 232 possible values, whose exhaustive enumeration is a piece of cake for a not-so-powerful PC. These beasts count time in gigahertz.


Bank forces me to use six character alphanumeric password

This means they are almost definately storing passwords in plaintext in a 6-character database field. If they were only storing a (salted) hash - as they should - then they wouldn't care about the password length since the hash function would produce a value of a fixed size regardless of the length of the input (password).

Your bank is probably still using systems from the 70s (or from before the industry standardised on salted hashing) and they don't take password security seriously enough to sort this out. This is the case with a lot of banks. You should start by complaining.


Have there been any proposals for automation of EV certificate granting and renewal?

EV and normal certificate have a very different goal in mind. On the one hand, certificates are for everyone. Everyone can and should get a certificate for their domain the only requirement is to own the domain.

EV on the other hand is a real proof of identity, not just the domain but that this domain is indeed the domain of this company that your are indeed a representative of this company, etc. It doesn't verify just the domain ownership but the real physical identity. That's a higher level of identity verification and thus a higher level of trust and it obviously can't be automated. And even if it could it shouldn't, the human verification is exactly what makes it more valuable.

The point of let's encrypt is that it is easy to get, so that every single website on the internet get https.

The point of EV is that it is hard to get. So that phishing gets harder. You probably can get a certificate for a domain trying to imitate a well known domain but you can't get an EV certificate for such a domain, because no human would allow that.

So making EV certificate free and automated by bots is completely missing the point of EV and it would lower the trust we get in all other EV protected domains. There is no point in having EV, if everyone can get one for free automatically. The extra price and verification is what make EV...  EV.


Is MS-CHAPv2 incompatible with securely stored passwords?

Yes

As a challenge-response protocol, MS-CHAP2 restricts how you can store the password server-side. And it is somewhat weaker than bcrypt.

You could provide a configuration option like: Support MS-CHAP2? (warning: enabling this stores passwords insecurely)


Encrypted file system in a hosted linux system

No, this would likely not be a safe assumption. Generally speaking, if you are running software on systems outside your own physical control, you must place near full or at least a significant level of trust in whoever does have physical control of the system.

Something that would likely be trivial for a cloud provider is to take a full dump of your virtual system's memory (RAM). Since your VM will be in a decrypted state while it is running, there will likely be decryption keys or other sensitive data that can be extracted from the RAM dump. This may be enough for Linode to decrypt the full contents of the filesystem.

See this related question for further reading.


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

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

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

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

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

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


Can access blocked site using lynx but not cURL nor browser

Your government has probably blocked connections to wikipedia.org by looking at the Server Name Indication (SNI) on the https handshake and forcing an error if the domain is on their blacklist.

Your version of lynx is probably not providing the domain server in the TLS SNI extension, while both Safari and curl do. Wikipedia works fine without an explicit server name at TLS layer (it will have provided a wildcard cert *.wikipedia.org, with wikipedia.org as alternative name, so it doesn't need to present a different cert to your client). If your government filters didn't cater that case (or simply didn't want to block everything for which they didn't have a full hostname), such connection would be allowed, with most other clients failing.

According to the lynx changelog I would expect your lynx version to support SNI, though (added on 2.8.7pre.2 for openssl, on 2.8.8dev.15 for GNUTLS). You can easily confirm if it is being provided with a packet dump.


That's quite a lot of questions! Honestly though, I think your biggest issue is that you have not defined a threat model. You need to understand your adversary, their capabilities, the value of your assets, etc. It's far more likely that someone will simply plug in a hardware keylogger than it is that they will physically open your computer and replace your BIOS. Attackers will always choose the simpler attacks over the more sophisticated ones, and your adversaries are no exception.

Encryption cannot protect against an attacker who has unrestricted physical access to the device doing the encryption. This is not a limitation of encryption itself, but a limitation with how it can be used. VeraCrypt and similar encryption utilities can only provide data-at-rest security which means that, when the system is powered off and all an attacker has is the raw encrypted data, they will not be able to decrypt it without the key. Make sure your system is attended and physically secure.

  I don't want the VeraCrypt hidden volume I created to be damaged. If I mount the hidden volume and transfer files there'd no damage, and if I enable the option 'Protect hidden volume against damage caused by writing to outer volume ' In the Mount Options dialog window, and write to the outer volume, there is no damage to the hidden volume, is that correct?

That is correct. If you enable "protect hidden volume", then you can write to the outer volume safely. If you are forced to give up your key under duress, you would only provide the outer volume key and not both, which would cause any writes to corrupt the hidden volume. This is unavoidable.

  if someone has access to a Veracrypt encrypted flash drive, they wouldn't be able to mount or write information to it, and BadUSB, flashing malware into the firmware wouldn't be possible?

Encryption does not block writing, but it does mean that the data that is written will appear as gibberish when you decrypt it. As for flashing firmware, encryption does not prevent that. Firmware is kept separately on the flash drive and is not and cannot be encrypted by VeraCrypt.

  The only possibility would be to physically open up the flash drive and insert something into it? How likely is that to happen by someone who isn't the government and how much it would cost?

It would be far easier to modify the firmware, but if the drive does correctly disable writing to firmware, then it would be possible to physically modify the firmware chip. No one can tell you the likelihood of this happening, but the cost would be extremely low. Note that modifying the flash drive alone is incapable of circumventing encryption.

  I assume that it would be different for a PC with an encrypted hard drive as they would be able to flash malware into the firmware if the BIOS isn't password protected, but what if the BIOS is password protected but you can still use the multi device boot option and boot a Linux operating system from a flash drive? (I know that PC does that). Does that mean that they could flash something into the firmware? How do I test if it's possible on that PC?

The BIOS password does not protect against firmware modification. See this answer.

  If four isn't possible, the only possibility would be again to open up the PC and insert something into the hardware, is that correct? How likely is that to happen by someone who isn't the government and how much would it cost?

It would be easier to modify a PC because it is larger and has more components. It would be very cheap, but again, no one can tell you how likely that scenario is for your particular threat model.

  Is there really no way to check if they inserted something into the firmware or to check if they inserted something into the hardware? How do you keep your information safe if your PC or flash drive could be compromised with no way to check if it has been compromised, aside from getting a new machine?

It is possible to verify firmware, but it can be complicated to set up. I explained how this can be done on an answer to another question. At the bottom of the answer are a list of further resources.


Certificate validation is done against the hostname given in the URL, which means you'll need a certificate for any hostname which you expect to be used inside a URL.

Thus, if you want to use both www.a.com and www.b.com in the URL you need a certificate for each, even if they are the same host and if one redirects to the other. DNS settings like same IP address or alias (CNAME) do not matter at all, all that matters is the name given in the URL.


Nmap http-brute - Supplying arguments for bruting via GET

The http-brute script documentation states that it performs "brute force password auditing against http basic, digest and ntlm authentication." These are HTTP authentication methods, but what you are looking for is form-based authentication.

The http-form-brute script does what you want. You can use the uservar and passvar script-args to tell it which variables to send, but if you are using a version of the script since r35542 (2015-12-31), then it should be able to auto-detect the form on the page you want to brute-force. Read the docs carefully, since you may need some of the other arguments like http-form-brute.method. The online docs always refer to the current development snapshot, but you can get the docs for the version of the script you have by running nmap --script-help http-form-brute.


Heartbleed: hackers have already used the vulnerability?

What's your question?  Yes, its been widely described and the attack is trivial to do once it was disclosed that heartbeats were flawed and you looked at the patched section of OpenSSL.  You change the payload_length of a heartbeats request to something like ffff to get 64K back; or something else bigger than the payload.
More interesting is that the heartbleed attack was apparently used in the wild last year from IP addresses associated with a botnet that appears to systematically log IRC:

The second log seems much more troubling. We have spoken to Ars Technica's second source, Terrence Koeman, who reports finding some inbound packets, immediately following the setup and termination of a normal handshake, containing another Client Hello message followed by the TCP payload bytes 18 03 02 00 03 01 40 00 in ingress packet logs from November 2013. These bytes are a TLS Heartbeat with contradictory length fields, and are the same as those in the widely circulated proof-of-concept exploit.
Koeman's logs had been stored on magnetic tape in a vault. The source IP addresses for the attack were 193.104.110.12 and 193.104.110.20. Interestingly, those two IP addresses appear to be part of a larger botnet that has been systematically attempting to record most or all of the conversations on Freenode and a number of other IRC networks. This is an activity that makes a little more sense for intelligence agencies than for commercial or lifestyle malware developers.


There is no notion of "key refresh", in either DTLS or even TLS, which would be independent of the handshake. If you want to refresh your keys for some reason, then you do so by requiring a new handshake. Both client and server can trigger a new handshake at any time (the client does so by sending a ClientHello, while the server sends an HelloRequest).

There are two types of keys in TLS (and DTLS):

The master secret is established through asymmetric cryptography (RSA, Diffie-Hellman) as part of a "full handshake".
The actual encryption and MAC keys are produced from the master secret and the "random values" sent by client and server. When a client and server do an "abbreviated handshake", a previously shared "master secret" is reused, but new encryption/MAC keys are produced.

There is no intrinsic reason in TLS or DTLS which would force a new handshake, except possibly running out of distinct sequence numbers; but since that number is a 64-bit counter, running out does not actually happen in practice (by a very long shot). Any specific application may wish to do a "refresh" at any time, and can do so by triggering a new handshake (abbreviated or full: an abbreviated handshake occurs only if both client and server agree to it).

It must be noted that there are very few rational reasons for "refreshing" the keys. People who do the refresh actually do so for the sake of formal compliance to regulatory requirements whose basis has been lost in the mists of Time (usually remnants of procedures which were needed for security with cryptosystems from before the invention of the computer). The unspoken myth at work in those cases is an assumption that keys somehow degrade upon usage, like bearings for a wheel, and must be replaced on a regular basis. This myth is, well, a myth, but a strong one, which still powers many standards and "best practice" documents.

(The one rational reason I have seen for a "refresh" was not about refreshing at all; it was a TLS server used in a context where the client also has a certificate, whose private key was in a smart card. The server regularly forced a new full handshake to make sure that the smart card was still there.)


Are my letsencrypt ssl ciphers strong enough?

Please don't make up your own configuration and ask if it is secure for some unknown purpose and unknown security requirements but instead follow established recommendations.

If you feel that it is better to create your own config please don't just dump the config. Instead explain why do you think the specific configuration options make sense in your (unknown) use case.

But in short:

3DES should not be longer used unless you have clients which still require it.
If possible (depending on clients) disable all protocols except TLS 1.2 or better.
DHE/ECDHE should be preferred since it provides forward security but you still allow RSA key exchange.
Even if DH(E) provides forward security it should not be used for performance reasons unless you have clients which still don't support ECDHE.

Apart from that: it does not matter for the configuration you've shown if you use a certificate from LetsEncrypt or some other CA.


Best practices for implementation of role-based access control in healthcare applications

Several of the PHP-based Open Source EHR systems have used PHP GACL for access control. I am not sure how often it is used any more, it is a good place to start to look at how role-based ACL can be implemented and controlled. PHP GACL provides a three-teir access model, so that you can split things up into access triads. Like role:doctor power:modify data:patient records can be made and intelligently exempted, such as role:doctor power:read data:patient except where doctor=Dr. Smith power=read and patient=Dr. Smiths daughter.

I am not sure how VistA does access control, but I believe that it does have the power to do both the general rules and to create these more subtle exceptions.

The combinations of healthcare IT regulations in the U.S. have given further structure to the access control issue. First, of course, is HIPAA, which insists that access control enforce the "minimum necessary" access control. 164.312 and 164.308(a)(4) 45 CFR 164.502(b) 45 CFR 164.514(d) of the security rule require this access control. But rather than read those standards, HHS has a nice summary of the notion of minimum necessary.

So an EHR must be configured so that each user has access to the minimum necessary to do their job. Which means that access control in healthcare is largely job dependent. Practically speaking that means that the best practice is simply to ask "does this type of user need access to this type of patient data to do their job?" If the answer is no, then a role-based access control restriction should prevent access, and probably automatically log access attempts for that combination of role to data object access.

Meaningful use also has a core requirement (#15) (protect electronic health information) that requires access control. Mostly just by requiring audit enforcement of the 45 CFR 164.308(a)(1) portion of HIPAA. So you have to do access control, and you need to do have audited compliance with that access control.

Notice that none of these regulations have said "Doctors should be able to do X and not Y" or "Schedulers should be able to see B but not C". This is quite intentional. There are too many naturally occurring variations of workflows in hospitals and clinics that there is no one-size-fits-most advice that really works, much less one-size-fits-all. So the only thing that is required is that

Every employee should not be able to access everything and
What they do have access to should be related to what they do for
their job and
You actually have to enforce it.

There are two general caveats to those details. "1." may not apply if your practice is small enough. If a practice is composed of one other person besides a doctor who does scheduling, nursing, billing, office management and takes out the garbage, then that person will probably need to have access to just about everything in the EHR. If you have all of the jobs, then you get the access of all of the jobs. Be sure to document this fact, however, to show that you considered the possibility of more stringent access controls, but rejected it for practical reasons.

Second, while PHP GACL etc can do tremendously complex things, many EHR systems will have simplistic or backward access control implementations. You may be very limited by what your EHR can do or what it can be configured easily to do. Again, if your EHR design does not allow you to handle access control in a way that is compatible with your workflow needs (forcing you to grant more generous access then you would prefer) be sure to formally document that too. Also file a bug with your vendor.

In general, I think the target should probably be generally be "compliance" unless your particular EHR has a "best practice" regarding how to set things up. VistA, for instance, has a kind of "zen of VistA" for all configuration decisions. A documented or informal rule about the right way to handle a particular configuration.

O'Reilly has released a guide to meaningful use called 'Meaningful Use and Beyond' (shameless plug... I wrote it) This issue is discussed in chapter 8 meaningful use overview and chapter 12 on HIPAA.


How to protect my ubuntu linux computer from screen capture programs or keystroke loggers?

If the device is compromised to the level where the attacker can record your screen, the attacker can replace whatever they want on your screen as well. You simply cannot trust that device at all at that point. Almost all scenarios assumes that the end user device is somewhat trustworthy.

However, two factor authentication may assist a bit. It may stop an attacker from authenticating using your password - but if they have screen recording access, they can probably just steal your session cookies anyway.


Multi-factor authentication - email link

This is not multi-factor authentication, as it's just "something you know" twice (the password to your service, and the password to the user's mailbox -- and knowing user habits, they will be exactly the same). Further, the email from your system to the user's mailbox is not likely to travel over a secure connection, as we still live in the world of opportunistic encryption for mail delivery. So, the "secret token" is being sent over not-so-secret channels.

This is marginally better than just asking users for a simple password, but this is definitely not multi-factor authentication (which is supposed to prove that the user has in their possession a specific hardware device).


Which format is used for distribution of signed certificates by real CA

Different CA does this differently.

One CA I've used out as a downloadable zip file containing your certificate and the intermediate certificate in various formats. Others provide a preconcatenated certificate and intermediate certificates as a single pem file. Some just points you to another page where you can download the intermediate certificates.

Personally, I find downloading them as a single downloadable zip is the easiest, and most convenient way to receive certificates.

Recently, some CA like Let's Encrypt also provide automated issuance. In this manner, you install an acme script on your server, and then that script automatically detects your web server, orders a certificate, automatically configure your webserver to do domain validation, downloads the signed certificate in the right format for your particular server, and automatically installs the certificate for you on the web server. The script can also be installed as a cronjob that automatically renews the certificate when it is close to expiry. If you're just configuring a domain validated certificate, this can be the most convenient for users, but it's also the most difficult to implement for CAs.


Do serial numbers for X.509 certs need to be strictly sequential or can they be timestamps?

They do not have to be sequential. Furthermore, there are some issues with using predictable serial numbers, as described in this post:

https://crypto.stackexchange.com/questions/257/unpredictability-of-x-509-serial-numbers


When should a password cipher be used and when should a normal password be used?

It seems unlikely this hasn't been asked here before, but I couldn't find a good duplicate.

Password managers, when combined with long, randomly-generated passwords, operate on an approach I like to call "put all your eggs in one basket, and guard that basket really really well".  The length and randomness of the passwords protect against brute force and dictionary attacks, and the randomness also prevents password-sharing attacks where one site stores your password insecurely.  The primary attack vector, of course, is an attacker gaining access to your password manager database, at which point they gain access to every account of yours.

If you can remember all of these long, randomly-generated passwords, then there is no database to breach, and you're better off.  However, most people can't do this.

As an alternative, you can use an algorithm to reproducibly generate a password on-demand for a site (a number of options are described in What is your way to create good passwords that can actually be remembered?).  These retain the benefit of not having a breachable database.  The question, then, is to whether or not the benefit of avoiding the database of passwords outweighs the downsides of moving from randomly generated passwords to a reproducible scheme.

If the scheme is obvious upon looking at a plaintext (e.g. siteName + accountName), then one breach at an insecure site opens up your entire set of accounts to any attacker who happens to look at your password.  This is obviously pretty awful from a security perspective.  Most schemes aren't that obvious, but you're betting on the attacker to not be able to reverse-engineer it - whether that's a good bet or not is up for debate, and depends on your specific scheme as well.  It's worth noting that the chances of successful reverse engineering go drastically up as an attacker gains access to plaintext passwords from multiple sites.

Another issue with reproducible password schemes is that they don't provide an easy way to change your password for a site - they are reproducible, and to generate a new password, you would need to integrate an additional piece of information (some sort of "round"), which you then need to either store or memorize.

Both password manager use and reproducible password schemes are security downgrades from the ideal password memorization option.  They are also both much better than what most people do, which is to use the same insecure password across many accounts.  Which one is "better" depends a lot on the specifics of your password manager and the scheme you're comparing it against, and which attacks you're worried about.


how do optional device certificates work?

The basic work flow is that you don't make client certificates mandatory but optional, i.e. ssl_verify_client optional instead of ssl_verify_client on in nginx. Then the server will ask the client to provide a certificate. If the clients sends none the server will not fail. If a certificate was send by the client the content of the certificate can be checked from your web application.

How exactly the configuration of the server and the integration with the web application is done depends on the specific environment and framework you use (i.e. nginx vs Apache vs IIS vs ..., PHP vs ASP vs Django ...) and the necessary details should be available in the related documentation. Any questions regarding specific configuration and access from your program would be more a question for stackoverflow.com.