Where does Active Directory store user hashes? During a penetration test for a client, having an infrastructure with multiple (5) Active Directory Servers (Win Serv 2008 R2)... I found a nice exploit to drop a system shell in one of the servers, and stole the domain admin account with mimikatz.

But the problem is, I used quarks-pwdump to dump the hashes... And I am not able to dump all the domain user hashes (most of the LM hashes retrieved are "aad3b435b51404eeaad3b435b51404ee").

I dumped them from the main DC, and a secondary one, both showing the same result. Is there a way to locate the password hashes in the ADs? Is it possible to change the domain configuration to choose the DC on which the hashes are stored ?

The hashes are located in NTDS.dit, although some software can inject into the LSASS process and extract them in-memory. In terms of which DC to use, this data should be replicated across each controller. You may see minor differences where a password has been changed on one and not yet copied the others (more on replication timings), but it is likely that the majority will be up-to-date.

quarks-pwdump expects you to use the Volume Shadow Copy method (utilising Volume Shadow Service - VSS) to retrieve NTDS.dit manually. The tool can then be used to parse hashes from this file. This in is contrast to dumping local hashes where the tool injects into the LSASS process. Using VSS (or registry backups for local dumping) can generally be safer and quieter than using an in-memory technique. These should be preferred where possible, which may be what Quarks are trying to promote.

The VSS method is detailed here (although this is to dump the registry hives, so needs to be adapted to NTDS.dit): http://bernardodamele.blogspot.co.uk/2011/12/dump-windows-password-hashes.html

A follow up post on NTDS.dit: http://bernardodamele.blogspot.co.uk/2011/12/dump-windows-password-hashes_16.html

Once you've retrieved the file, you can use quarks-pwdump to parse it with -dhd and -nt path/to/file/NTDS.dit (which is a hell of a lot easier than using NTDSXtract).


Could a private key from JavaScript WebCrypto resist a malware attack? The recent WebCrypto API can generate private/public keys. To prevent the private key to be extractable with JavaScript, the CryptoKey object could be stored like this in IndexedDB.

I suppose if we store it like that, a malware could read it easily, it's surely why the WebCrypto API can wrap the key with another key, so that the private key can be stored in IndexedDB encrypted. The wrapping key is stored on the server side and sent to the client after a successful authentification.

So, if the browser is closed, the malware should be able to get the private key but it's encrypted and in theory useless (excepted for brute-force attack).

But if the browser is opened, and the user log in, the server send the secret key to unwrap the private key. So at this moment, is it possible for a malware to read the network trafic, RAM, files, caches, to read/extract the unencrypted private key?

About the network trafic, I assume it's all in HTTPS, TLS 1.2 minimum with robust cipher suite, with HSTS set to max age including sub-domains, and with HPKP to prevent MITM attacks.

Extremely intelligent malware with root permissions (on a *nix client) can do just about anything, including redirecting /dev/random or /dev/urandom to something they control.  If the malware can control the random number generation your computer uses to create TLS keys, then it can break the HTTPS communication.

If the browser is open and the user logged in, then malware with the ability to perform raw mem dumps would be able to find the key.

In short, if a user can do it, then a theoretical malware program can do it.

I suggest the question should not be is it possible for malware to... as malware with unrestricted power can do anything that you can do.  Instead, the question is, what would it take for malware to...?  From this perspective, we're not measuring what's possible, but what is probable.

The methodology you described sounds about as good as it can get (outside of using the user's password to lock the private key / shared secret so that the server doesn't have to receive, store, and transmit it).  There is no such thing as perfect security.


How do exploit kits enumerate or fingerprint their targets? My current understanding is that an exploit kit will fingerprint (gather information on) a system, check those details against a database of vulnerabilities and then attempt to use the relevant exploits.

I can see simple ways of checking for things like the installed version of Flash using JS but this is really easily defended against (because it's just JavaScript that can be stopped, modified or stepped over by the user).

What other techniques are used to gather information on a user when they find their way to the exploit kit's landing page?

For example, how would it discover what version of Adobe Reader you are using or what browser plugins are installed if you landed on my webpage?

I think you might be assuming that the kits are more complicated than they are.

A kit is designed to exploit specific vulnerabilities. It is not necessary to 'fingerprint' and choose the best exploit. It can just attempt to exploit what it is designed to exploit. Some kits will attempt one method after another in series until something works.

For instance, a kit can be designed to exploit Safari browsers. When a user hits it, the exploit is launched. Whether it works or not depends on whether the correct browser and version made the connection. If it did not, generally nothing happens that the user can see anyway.

For your example of Adobe Reader, the kit does not need to know that a specific version is reading the file. The kit just serves the PDF file with the exploit within it. What's the cost of failure?

On the other hand, if the kit wants to be more targetted, then yes, it looks for the specific markers it requires. But what those markers are, and subsequently how to look for them, will depend on the vulnerability. Too many to enumerate here.


Is it possible for Apple or any other company to create fully encrypted smartphone? From the latest Apple vs FBI story it's known that Apple is technically capable of changing the boot-loader of the iPhone to provide interface for brute-force finding of 4-digit password.

I'm wondering, is it theoretically possible for Apple or any other software any hardware company to create a fully-encrypted smartphone. By fully-encrypted smartphone I mean that it would have the next properties:

The device is encrypted via some key (possible implementations, but a requirement: 4-digit, x-length alphanumerical, TouchID, retinal scan, etc.
Neither manufacturer nor FBI can decrypt data is a timely manner (100+ years with currently available hardware).
It's not possible to change a part of it's software or hardware without data being lost.
The chances to recover data after data wipe are negligible.

Please think of physical access to the RAM and Flash memory. No one should be able to "connect" to RAM memory while device is working and read unencrypted user data.

Also, the smartphone itself should behave just like any other modern smartphone - it should have apps downloadable from the store, software updates, etc.

Update: Let's ignore software or hardware exploits, worms, vulnerability, etc.

It'd be a piece of cake.  All you need to do is manage the safety of the secret (i.e. the handling of the PIN) in firmware, and make it so you can't update the firmware anymore.  The ability to prevent a device from accepting additional firmware uploads has been around for decades, usually under a name like a "fuse bit."

Of course, the consequences of this is that Apple becomes incapable of updating the firmware if anything goes wrong.  Naturally this is unpopular, so companies elect to not do it.

There's also the exotic solution of a Key Ceremony.  It's a fascinating topic to read about, but the long story short is that it ends up splitting the root key into several dozen pieces, giving each person a different piece.  If each piece of software had to be signed by such a key, it would be virtually impossible to get all the keys together for a second signing.


Do docker images have the same root password? If two persons are pulling the same docker image (let's say Debian:10.4), they will obtain the same "files" (layers) from the docker repo.
So, from what I understand, launching a docker image is not exactly like a fresh install, it is more like a preinstalled OS. So I guess the two docker images debian:10.4 launched in two separate hosts should be as equivalent as possible to avoid difference in the behaviour from a host to another.
Considering this, I am asking myself if the root's password is always the same on every debian:10.4 images.
I don't know if we know the root's password of this image or only the hash. But if someone could find a preimage of this hash, he would be able to log in in every SSH server based on a debian:10.4 ?
Or is there a minimal randomness applied at the start of a instance docker to ensure the dispersion of some security constant (root password, id_rsa key, ...) ?

Docker containers don't usually let you log in as root with any password. Usually, the only way to get in is to docker exec from the host. There is no hash to find a preimage of.


Difference between secure design patterns and a generic coding guidline? Is there a difference between secure design patterns and a generic coding guideline from which you can derive a technology specific coding guidline?

Patterns like "authentication", "secure sessions" or "input validation" are secure patterns and should also be adressed within a coding guidline.

So is there a difference or is it just another definition for the same "content"?

There are multiple terminology variants around there, so there won't be an absolute answer.

I'd say that "secure design pattern" is an expression which will be used by people who believe that developers are some kind of ape who can achieve Security if made sufficiently obedient to strict formal rules. While "coding guidelines" would be employed by more realistic people who have understood that developers are best cajoled with "empowerment" (and bananas), and may achieve some decent level of security if offered guidance. A really crucial requirement for security is that people understand what they are doing.


Insert hidden link in Skype Recently I have received a link from one of my Skype contacts (infected by a computer virus).

The link looks like an Instagram one, but points to another site. How the attacker did this? How to create similar message?

Skype (version 7.7 (335)) message screenshot on Mac:

Update:

Some people think this question is not security-related. But I disagree.

This is unusual behavior of Skype. Skype users expect that link text is always equal to link target. Changed links may be used to send spam messages, malware distribution and users de-anonymization.

Currently there is a small breach in the Skype for Web. Any HTML code is escaped on the client side before it is posted to the Skype server. But you can send unescaped HTML by writing some JavaScript code.

The steps follows:

Go to Skype for Web via Chrome
Open JavaScript console and execute:

// replace standard XHR.send() with our custom implementation
XMLHttpRequest.prototype.oldSend = XMLHttpRequest.prototype.send;
var newSend = function(args) {
    try {
        // messages to the server are posted via JSON
        // in 'content' field
        var m = JSON.parse(args);
        if (m.content && m.content.indexOf('secret') === 0) { // 'secret' is our codeword
            // if the message begins with 'secret', replace it by our HTML with the link
            m.content = 'http://watch-yourself.com';
            this.oldSend(JSON.stringify(m));
        } else {
            // if no 'content' field or no 'secret' codeword, then send as is
            this.oldSend(args);
        }
    } catch (x) {
        // if not JSON, then send as is
        this.oldSend(args);
    }
}
XMLHttpRequest.prototype.send = newSend;

Type 'secret' in any chat message
The resulting message shown in the desktop version of Skype:


Android device leaks SSIDs I suspect that an android device is trying all SSIDs it was ever connected during wifi scan. 1) It alone gives enough information to identify the device 2) If a network with no encryption is saved, a MitM attack can be performed.

Is there a way to handle it? E.g. trying only networks that are in the range (listen for beacons). It will make impossible to connect to hidden SSIDs, but who uses it?

I suspect that an android device is trying all SSIDs it was ever connected during wifi scan. 1) It alone gives enough information to identify the device 2) If a network with no encryption is saved, a MitM attack can be performed.

This would be typical of most mobile devices if you store the connection in a way where it will automatically connect again at a future time.

  Is there a way to handle it?

Yes. You can do so by doing whatever combination of the below you like. This will at least limit your exposure.

Don't store you wireless networks so you can connect automatically in the future.
Delete wireless networks when you are done.
Disable wireless on your device when you don't want to be connected.

  E.g. trying only networks that are in the range (listen for beacons).

In comments elsewhere, you seem to find "passive scanning only" as an appealing solution. This will significantly increase times for a device to connect to a wireless network (from your reported 3+ seconds to something more like 6-20+ seconds) and have the potential to create what appear to users as "outages" of similar periods every time the device scans to check for better networks to which they can roam.

Put simply, it won't happen. Why? Because it is asking for developers to add a feature that (a) decreases usability by increasing time taken to find/connect to networks and (b) impacts modern devices more significantly than legacy devices. Or put another way, how many users do you think would be pushing developers to "significantly increase the times it takes to connect to a wireless network"?

Automatically trying to connect to any configured SSID as if were hidden was a change made to simplify the user experience and make it easier for the masses. As in many such feature decisions, this does come at a cost for potential security/privacy issues. You will find little support in developer circles for going back on this decision and increase the number of [confusing] choices people [with little technical knowledge] need to make when connecting to a wireless network.

A better and more likely suggestion that you could make is an option (global or per profile) to "allow connections to hidden networks" that would be enabled by default and provide the existing behavior. Knowledgeable users could then choose to disable it if they wanted, and the active scanning for networks taking place could do so without including an SSID. No negative impact from disabling active scanning necessary.

Still a tough sell since there are many features users [in larger numbers] want for their devices and developers tend to follow the demand, but more viable than the prior suggestion.

  It will make impossible to connect to hidden SSIDs, but who uses it?

Many organizations do and some home users. Personally I find very few cases where it is used for a valid reason, but my opinion doesn't stop people from using hidden SSIDs.


Is a rand from glibc's rand secure for a login key? Same question as Is a rand from /dev/urandom secure for a login key, but with glibc's rand function instead of /dev/urandom. And what would be a sufficiently secure seed generator?

No. The PRNG in typical C libraries is designed for speed, not for security. It's usually appropriate for numerical simulations and games (in good-quality implementations — there are implementations out there, mostly old ones, where it's not appropriate for anything), but not for cryptography. A cryptographic PRNG must be unpredictable, i.e. an attacker who generates a series of numbers must not be able to make a good guess at the next number. The typical C library PRNG strives for speed and good statistical properties but not for unpredictability.

As of Glibc 2.7, rand and friends use a linear congruential PRNG or a linear feedback shift register depending on the available seed length.

To generate key material or any other random number involved in cryptography (including non-secret things like nonces that nonetheless need to be unpredictable), obtain all bits from a crypto-quality RNG. Linux's /dev/urandom (or any other unix that has /dev/urandom) is fine for that. You must use it for each byte of each key; using it as a seed of the C library PRNG is not good (there would be a strong correlation between the keys). A library such as OpenSSL is another choice; it'll probably use /dev/urandom under the hood as a seed but may be a little faster if you're generating large volumes of random data.


Is Meltdown/Spectre mitigation necessary in virtual machine as well as in hypervisor? I am running virtual machines in kvm/qemu hypervisor. The hypervisor has Meltdown/Spectre mitigation enabled in kernel.

Is it necessary that virtual machines have the Meltdown/Spectre mitigation enabled as well, or is the protection provided by the hypervisor sufficient?

In other words, do the host as well as the guest need to have Meltdown/Spectre mitigation enabled?

Q: .. do the host as well as the guest need to have Meltdown/Spectre mitigation enabled?

Yes

When these vulnerabilities announced, QEMU posted on "QEMU and the Spectre and Meltdown attacks":

  Right now, there are no public patches to KVM that expose the new CPUID bits and MSRs to the virtual machines, therefore there is no urgent need to update QEMU; remember that updating the host kernel is enough to protect the host from malicious guests. Nevertheless, updates will be posted to the qemu-devel mailing list in the next few days, and a 2.11.1 patch release will be released with the fix.

  Once updates are provided, live migration to an updated version of QEMU will not be enough to protect guest kernel from guest userspace. Because the virtual CPU has to be changed to one with the new CPUID bits, the guest will have to be restarted.

  (05/01/18 — by Paolo Bonzini and Eduardo Habkost: source)

The updates have been available, so, you should proceed with them and enable the mitigation as well on guests.

By QEMU Article "QEMU 2.11.1 and making use of Spectre/Meltdown mitigation for KVM guests":

  What is being addressed here is enabling a guest operating system to enable the same (or similar) mitigations to protect itself from unprivileged guest processes running under the guest operating system.

  Enabling mitigation features for x86 KVM guests:

  For x86 guests there are 2 additional CPU flags associated with Spectre/Meltdown mitigation: spec-ctrl, and ibpb:

  spec-ctrl: exposes Indirect Branch Restricted Speculation (IBRS)
  ibpb: exposes Indirect Branch Prediction Barriers

  Utilizing this functionality requires guest/host kernel updates, as well as microcode updates for Intel and recent AMD processors. The status of these kernel patches upstream is still in flux, but most supported distros have some form of the patches that is sufficient to make use of the functionality. The current status/availability of microcode updates depends on your CPU architecture/model. Please check with your vendor/distro to confirm these prerequisites are available/installed.

  (14/02/18 — by Michael Roth: source)


Does an Egghunter attack still make sense in a 64 bit system? Background

An Egghunter is basically a low size stub that acts as a first stage in a 2 stage exploitation attempt (whereas second stage is usually the malicious payload shellcode). In the first stage, the stub will search through the process VAS (Virtual Address Space) for the second stage payload that is input/injected elsewhere of the same process memory. Once found, transfer control to the second stage of the exploitation.

In an x86 system, the VAS is of size 4294967296 bytes or around 4Gb. It is relatively easier to scan through the entire process VAS of size 4Gb.

Now in an x86_64 system the VAS size is up to 16.8 million Tb (Terabytes). Finding an egg within such memory is indeed trying to find a needle in a haystack.

Question:

Does this make the egghunter exploitation technique irrelevant in an x86_64 system? Because it can be proved to be very difficult to find the egg label and execute the payload without actually knowing the exact real time location of the injected egg + payload

Difficulties such as:

searching through that much memory could take days/weeks
UB when system calls are repeated for [millions x (Tb)] iterations
Segfault when #2 occurs

So does an egghunter attack still make sense in a real attack on a 64 bit system, at least without knowing the exact location in memory of the injected second stage payload?

It can make sense, but you have to rely on luck. So simply put, it can work but it's not really reliable. You don't have to search through the whole adress space, as only the user-space is relevant (47 bits). If you want an in-depth explanation, this article experiments with this attack on a 64bit system.
https://pentesterslife.blog/2017/11/24/x64-egg-hunting-in-linux-systems/


Why CSRF's JS can't read token by GETting html 1) User is logged in bank.com in one tab, where everything is secured by CSRF tokens. Then he opens evil.com in another tab.

2) Javascript in evil.com might try to make a POST request to bank.com/send_money only if it knew csrf_token.

3) In order to reveal csrf_token, javascript in evil.com might try to do GET ajax call to bank.com/send_money to get the exact same html user would get by visting this page in his browser. And then read the token.

QUESTION - why the last step will fail and will it always fail?

As far as I understand, bank.com will actually respond to this request and render all the html just fine, but on the client side the browser will decide that content coming from another domain should not be accessible, therefore it fails.

If there is an iframe in evil.com to bank.com/send_money, the iframe will load all the html just fine, but again the browser will decide that this html cannot be used by javascript and it can only be viewed in iframe. Therefore JS cannot get the token and cannot make POST request.

Is it correct? Can this be fooled?

JavaScript cannot read the content of other sites due to the same-origin policy.

This is one of the most fundamental principles of web security and goes way beyond CSRF protection. Without the same-origin policy, any website could read our e-mails through our webmailer, have a look at our PayPal account, get our private information from Facebook etc. So browser vendors do put a lot of effort into preventing this.

Like with all security mechanisms, there may be bugs. And there's also a specific attack called DNS rebinding. But all in all, the same-origin policy works very well and cannot easily be defeated.


Newer techniques for Meterpreter AV bypass Is anyone willing to share techniques for creating a Windows Meterpreter payload that can bypass AV?  I've noticed that Defender does a very good job these days at detecting it.  Some of the techniques I've used and will share here.  The particular method I'm trying to use is creating an executable Meterpreter payload using msfvenom.   Transferring it to Windows 10, and then on msfconsole running exploit/multi/handler with reverse shell stager.  Double-click on Windows and establish meterpreter.

I've tried:

Used msfvenom with Shikata Ga Nai encoder.  Detected.
Created a Python Meterpreter payload.  Not Detected.  However, doesn't have the same functionality as Windows meterpreter payload.
Tried using Golang with meterpreter payload created with msfvenom, and upx.  Not detected, but exe has an exception.

One way I found that works, is to:

generate shellcode from msfvenom,
then remove bad chars from it i.e. -b '\x00',
then encrypt the shellcode,
and put it into a self-written C program, which will decrypt and execute the shellcode, via CreateProcess

You will bypass all static AV analysis. But you still probably might get caught on dynamic analysis with Windows Defender.


OWASP WebGoat Warning Meaning I am just starting with WebGoat. On their GitHub page [https://github.com/WebGoat/WebGoat], they have this warning posted:

WARNING 1: While running this program your machine will be
extremely vulnerable to attack. You should to disconnect
from the Internet while using this program. [sic]

What does this mean? My naive understanding says that this is run on a localhost, then where lies the vulnerability?

P.S.: It could be better if you could explain this for one just trying to get off the surface, or anyway, I am looking forward to learn, so please enlighten me. Any advice for one starting off is also most welcome. Thank you all!

WebGoat is an application that is designed to be susceptible to network attacks. Theoretically, your computer becomes vulnerable to a network attack when you're running WebGoat. Imagine if an attacker were to leverage the WebGoat vulnerability for the lesson about performing code injections, This would allow the attacker to execute commands on your computer. Very bad.

An attacker will need network access to your computer to execute the attack. You likely have a firewall on your network that will limit attackers to your local network. That said, you are still reducing the safety of your computer by running WebGoat. Especially as firewalls sometimes are misconfigured or have vulnerabilities that can cause them to let packets from the internet into the local network.

WebGoat's recommendation is to disconnect your computer from the internet which will remove the risk of a network attack. That means unplugging your network cable and/or disconnecting your WiFi connection. It seems like a reasonable protection to me.


Different performance of openssl speed on the same hardware with AES 256 (EVP and non EVP API) If I run openssl 1.0.1e like this :

$ ./openssl speed aes-256-cbc (i.e without EVP API)
Doing aes-256 cbc for 3s on 16 size blocks: 14388425 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 3861764 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 256 size blocks: 976359 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 246145 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 30766 aes-256 cbc's in 3.00s

However, if I run it like this :

$ ./openssl speed -evp AES256
Doing aes-256-cbc for 3s on 16 size blocks: 71299827 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 18742055 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 256 size blocks: 4771917 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 1024 size blocks: 1199158 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 150768 aes-256-cbc's in 2.99s

From the OpenSSL documentation, it seems that using EVP for the same cipher or not using EVP should not make any difference. Yes I see it consistently. Can anyone please provide an insight? I have googled a lot but could not find anything. I will look through code but not sure if I can understand that part.

In OpenSSL source code, the speed aes-256-cbc function calls AES_cbc_encrypt() which itself uses AES_encrypt(), a function from crypto/aes/aes_x86core.c. It is an obvious "classical" implementation with tables.

On the other hand, with EVP, you end up in the code in crypto/evp/e_aes.c which dynamically detects whether the current CPU supports the AES-NI instructions, a feature of recent x86 processors, which allow for vastly improved performance. In OpenSSL code, the AESNI_CAPABLE macro does the job (feeding on some flags which are set when the library is initialized, using CPUID).

Bottom-line: with EVP, you benefit from the automatic selection of the improved implementation, based on the current CPU model, whereas the non-EVP code directly uses the generic software implementation, which works everywhere, but is slower.


How safe is it to provide my administrator account password for a 3rd party software: EasyUS Todo Backup? I've been recently searching for a backup solution for my Windows desktop. That's when I came across this free software called EasyUS Todo Backup. (I know it's a mouthful but English doesn't seem to be their first language.) So I downloaded a copy and tried it in my VM before deploying it on the actual computer.

What immediately struck me was that the software required me to provide my Windows administrator account password when I was scheduling the backup. I was faced with the following screen and the error message if I failed to enter my admin credentials:

So I'm curious, from a security standpoint, how safe is it to provide these credentials to a third party software like this?

On the one hand, it's crazy dangerous. There's nothing more dangerous you could do on a computer than give an untrusted program administrative access to your computer. There are no limits to what the program could do; install rootkits, delete your files, add your computer to a botnet. Anything.

On the other hand, that's exactly what you do every time you run a program as administrator. So, if the program is going to do something nefarious, it doesn't need to save your password. It just needs you (the administrator) to run the program with elevated privileges. Which you probably already did before you got to this point.

As for what the additional danger is in allowing the program to save your password: Windows internally stores your password as a one-way hash. Nothing, not even Windows, can retrieve your password until you type it in yourself. But by providing the password to this program, now you're additionally storing it either plain-text or using reversible encryption. So you've decreased your level of safety by one notch. Not a ton, but it is indisputably lower now. And if they do this bit poorly, then all the worse for you.

Next, Windows actually encrypts certain key bits of your security profile using your login password. These bits are not accessible to anyone or anything until you've provided your password to log in. This is wonderful and super and all that, but it also means that nothing can impersonate you (not even this backup program) without your password. And in particular, scheduled tasks can't run as you without your password. This is just the way Windows was designed; it has nothing to do with this backup program.

And finally, since this issue with scheduling tasks to run as a user is a known problem in Windows, there's actually a core system function for storing your login credentials specifically for use running scheduled tasks. This means that the backup program doesn't have to store your password, it just has to tell Windows to do so. So it's unlikely that this backup program is directly doing anything with your password, they're probably just handing it off to Windows to use with its built-in task scheduler.

So in that case, the safety of your password would be more of a function of the safety of the Windows task scheduler, not this backup program.


hashcat - cracking a salted sha256 Given a SHA256 hash, and a salt, I am trying to crack the hash using hashcat. Every example I've found used a hashfile as input, is there way to provide salt and hash via commandline without the need to create a hashfile?
Here is an example what I am trying to crack:
Hash: 6ce9a7c73ebf0c04db026fda907210e7367f6d72225f78399a4a3fc9bfd0cce9
Salt: a3424259-9534-486a-bfe9-6a2b39aa70e5

According to hashcat's wiki, you can paste the hash directly into the command line:

Usage: hashcat [options]... *hash*|hashfile|hccapxfile [dictionary|mask|directory]...

You can also use hash mode 1710 as in:  1710 | sha512($pass.$salt)| Raw Hash, Salted and/or Iterated

Putting it all together, it would be hashcat -m 1410 -a 0 hash:salt --username test_user /usr/share/wordlists/rockyou.txt where the hash contains the password and salt (in that order).

If the hash is salt/pass instead of pass/salt, use 1420 instead.


How Can I Process Untrusted Data Sources Securely? Here is the conundrum: At my current company, we process physical discs from numerous third party sources and extract the data from them to ingest to our own system. While we can generally trust the sources, we don't want to run the risk of introducing any form of malware in to our internal networks and systems. Is there any way that we can safely process these discs without too much (or any!) additional effort?

Our current process is:

Employee receives a disc and inserts it in to their workstation.
Employee extracts data from disc
Employee uploads extracted data to our internal system

Obviously, in the current format, if a compromised disc is inserted in to an employee's workstation, the entire network could potentially be infected within minutes. Not ideal.

One proposed solution was to use an air-gapped machine to inspect the disc before processing but this poses problems as then how can we reliably detect any (or new) malware on that machine? It also adds an additional, time-intensive step to the process as the discs would have to be extracted twice.

Another solution is to have a machine connected on an isolated subnet to our network, with an AV installed, and WAN access restricted to allow AV updates only. Discs can be inserted and extracted remotely on that machine from an employee's workstation and then the data ingested (somehow; perhaps a proxy?) to the system.

What would be the most secure, most cost effective, and least time wasting method of performing this operation? If there is a recommended industry standard, what is it and where can I read up on it?

EDIT:

The discs are DICOM compatible discs so they contain multiple images (.tiff or .dcm) but also (usually) a viewer application (a .exe) to view these images. The worry here is more that one of these files could contain a Trojan, I guess. Still quite junior with CyberSec so forgive me if I'm misunderstanding some aspects!

It all depends on what you actually do with the data. A bunch of bits sitting on a disk is just that: a bunch of bits. It needs to be somehow executed in order to become malware and pose a threat to your network.

This could be done in a couple of ways:

windows allows autorun on removable media. Mitigation: change ingestion machine to Linux or carefully configure windows
manual execution: employees can do it by accident. Mitigation: restrict employees account, for example, make the files read-only by default. This doesn’t protect from malicious actions, only from accidental ones.
Data on the disk can exploit a vulnerability in file system drivers. This is pretty unlikely, file system drivers are tested pretty well and any vulnerability here is critical and would be a very expensive 0-day (so it wouldn’t be used against you).
Mitigation: you should automatically install security updates. Another way to protect against this is to use user-space file system drivers. AFAIK they are less well tested, less stable, and less performant, but any successful exploitation will give a user-level (and not kernel-level) access. You’d have to think about this trade-off by yourself.
Lastly – the data can exploit vulnerabilities in other software that you use to process the files. This is the most likely option, arbitrary code execution vulnerabilities are regularly discovered in software like pdf readers. Mitigation: keep your software updated, and configured to a high security (don’t allow macros in MS Office, etc.).

Additionally, you can contain every file processing step in a VM and reset it to the known good state after each workday. This would be pretty inconvenient but would offer some additional protection, especially if you disable networking on the VM.

I wouldn’t get my hopes up about antiviruses unless you’re actively executing supplied files they wouldn’t offer much protection.


How can I read local files from blind XSS? When I do one of these payloads, I can see /etc/passwd:

<img src="xasdasdasd" onerror="document.write('')"/>

However this I got blind XSS, so I need to send the iframe text back to me, so I need to grub the iframe text and do something like

<iframe src=file:///etc/passwd></iframe>

This displays a local file in the browser inside a separate iframe. This iframe has a different origin than the main frame. Due to same origin policy it is not possible to read the iframe content from the main frame, no matter if XSS or not.


Storing third-party auth info securely Suppose there's a multi-user web application that requires access to user's mailbox (on third-party service, like gmail, etc.). This access needs to be persistent. Which means we'd have to store user password. Which creates a vulnerability point - if somebody gained access to such system, he could steal tons of user's mailboxes. Is there any way to reduce the risk in such setup? E.g. for some websites OAuth could reduce the risk since tokens need consumer keys, can be restricted and can be easily mass-expired if something bad happens. But all this is not available for mail servers. So, any suggestions about a good way (if there's any) to store such information in a more secure fashion?

Experience shows that if a site like this is on the public Internet and gets popular enough, it becomes a big target and has a high likelihood of disastrous compromise.  Note well the responses in this extensive discussion (about a somewhat different goal):

How should I ethically approach user password storage for later plaintext retrieval? - Stack Overflow

If you choose to go ahead, make sure you warn your users of the very real risks.  Defense-in-depth is mandatory - keep the actual password storage machine off the web, accessed thru the firewall with a very simple interface, built on the most secure platform you can find, with lots of hardening and monitoring, a good IDS, etc etc.


Foxit Reader - disable JavaScript / Safely read PDF Today I disabled JavaScript in my Foxit Reader settings because I hope to gain better security against malware embedded in PDF books I read.
As some sort of simple check I tried to open a PDF with fill-in forms and see what happens when I try to fill-in some of the fields and check some checkboxes. Everytime I checked a checkbox, a window opened, saying that JS is disabled and was used for some features in the document. It then gives me the possibilities to add the file to a privileged location or to enable JS again. However, if I just click "Cancel" or simply close this window, the checkbox remains checked and I can simply save the changes.
Now this makes me wonder if disabling JS is any good against potential malware in a PDF and if I should use a different reader or an entirely different solution.
So my question(s) would be: Based on this experience, is disabling JS in Foxit doing any good and what would be other good solutions for opening PDF files safely?
I read about dedicated virtual machines or using Firefox with disabled JS. Would these be secure? The first one seems very unconvenient, since I use my laptop mainly for university and being able to open textbooks comfortably would be good. Then again, keeping my passwords, financial account etc. safe is a priority over convenience.

I studied this question a bit. I can say there is no way for a PDF to run malware by itself. The PDF is just bytes in a certain format. There is a very few amount of security risks if not none in the applications used to open PDFs. I would not use Firefox but Adobe to open PDF files. Firefox simply didn't implement the whole PDF specification. I use Firefox because it is open source but not for PDFs (unless you are on Linux).
If it was that easy to just run some JavaScript in a browser and put some malware in the computer, every website you visit would be a security risk. I think you can say that PDFs are secure.
Where it becomes a security risk is the icon. We are so used to the icons that we see that you will often launch a PDF without looking at the extension or info about the file. If the file is an executable, nothing prevents someone from specifying a PDF icon to an executable and mimick a PDF. This is how I would do it myself. So I would simply tcheck the PDF before opening it.
That is to say you should trust people enough to be sure there is no malware in a teacher's PDF and in downloadable books. Especially, if you use these books on a foxit reader which is hard to hack.
When you launch software on Windows or Linux, the OS tcheks the extension of the file and uses the default app this extension is associated to. It then puts the file path onto the stack of the new process which the app uses to parse the file. Unless there is a problem in the app used to launch the PDF or the PDF is an exe with a fake icon, I doubt it can do any harm.
I'm not saying it isn't a security risk to download stuff on Internet. But I think among the most secure files are the PDFs especially if they come from trusted sources like a teacher. I would not call a classmate a trusted source though.
If you want to be sure. You can always open documents on the cloud which is very secure because it is limited by the Internet browser which are very secure today.


Is denying login after incorrect attempts ineffective? Generally denying login attempts after X amounts of incorrect attempts for Y amount of tries is a very basic way to prevent bruteforce attempts or malicious login attempts.

Yet, surely doing this is meaningless if you allow successful login with the correct password? In which case getting an error or a warning message about a timeout period when trying an incorrect message is meaningless if the correct password will work regardless.

On Hotmail for example when I attempt to login with the wrong password I eventually get a message saying further login attempts are restricted. Trying with the correct password lets me in straight away. So I wonder if there is any point to having such a warning in the first place? Is it effective in the actual password grants access?

Preventing login without the right password is the core functionality of the login process. Just keeping on doing that is by no means an "additional" security feature.

Denying login attempts after X incorrect attempts means rejecting all attempts in that situation, regardless of the value of the password which is then presented. If you still accept the right password, then you are not denying anything, you are just managing a login process.

With online systems, disabling the account is a bit rash; it means that anybody can effectively block your account by entering junk passwords. A smoother procedure is to add delays: after X incorrect passwords, have the server block the account for, say, one minute, and reblock it for one minute after every attempt until the right password is entered. The initial X attempts should be enough to cope with users with shaky fingers, and the one-per-minute rate severely impedes a bruteforcing attacker (coupled with some safety measures such as banning IPs from which too many login request come in too little time).


Which languages are better for attacks against websites? Which languages are better for writing tools for attacking websites, through, say, a DDOS? High level, low level, and does it even make a difference?

Hmm, I would have to say Python, Bash and/or Perl. Why? Well they are installed by default on most of *NIX platforms (most of the web servers) and are easy to program for a quick hack (again I'm talking hacking code).

DISCLAIMER: I am not promoting penetration attacks :D


How to use VNC with SSH tunnel - "is this howto secure"? PC-A: the local machine, from where i want to see the remote machine [Fedora]
PC-B: the remote machine, where the vnc server will be [Ubuntu]
install a vnc client [from where you want to connect] on PC-A

yum -y install vinagre

ssh to the target machine [from PC-A to PC-B], then: [if PC-B is behind NAT, then port forward the ssh port!]
with root on PC-B
you will need the "universe" repositories [ vi /etc/apt/sources.list ]

apt-get update; apt-get -y upgrade; apt-get install -y tightvncserver
exit

with the normal user still on PC-B

tightvncserver give a very-very-very good password!!
echo 'gnome-session &' >> ~/.vnc/xstartup

if you need help with the port forwarding rule in you're OpenWrt router [tested on 10.03]
add the port forward rules

iptables -t nat -I prerouting_wan -p tcp --dport 22 -j DNAT --to REMOTE-PC-B-PRIVATE-IPADDRESS:22
iptables -I forwarding_wan -p tcp --dport 22 -d REMOTE-PC-B-PRIVATE-IPADDRESS -j ACCEPT

delete the port forward rules

iptables -t nat -D prerouting_wan -p tcp --dport 22 -j DNAT --to REMOTE-PC-B-PRIVATE-IPADDRESS:22
iptables -D forwarding_wan -p tcp --dport 22 -d REMOTE-PC-B-PRIVATE-IPADDRESS -j ACCEPT

keep in mind that the vnc traffic in unencrypted! So ssh tunnel to the target machine [from PC-A to PC-B]

ssh -f -L 5901:localhost:5901 USERNAME@REMOTE-PC-B-PUBLIC-IPADDRESS -N -p 22

then connect with vinagre: "127.0.0.1:5901" on PC-A

p.s.: if you press the "d" key, and it has an effect like "show desktop", then press "ALT+F2" then type: "gnome-keybinding-properties"

important: remove vnc on target side after you have finished!!

pkill vnc
apt-get purge -y tightvncserver

HERE comes the QUESION: is this howto secure enough? Does the VNC connection really goes through only the SSH tunnel?

If you are connecting to localhost (127.0.0.1) on an ssh forwarded port (the 5901 your forwarded), then yes your connection to the remote host is encrypted.


Nessus Denial of Service checks What's the difference between the "Denial of Service" plugin family and other plugins with "DoS" in the Plugin Name but located in different families? Can those other plugins also cause DoSs during scans?

As stated in the nessus documentation. members of the "Denial of Service" family are direct checks that in some cases attempt to exploit the DoS vulnerability they are testing for.

The Denial of Service family contains some plugins that could cause outages on a network if the Safe Checks option is not enabled, in addition to some useful checks that will not cause any harm. The Denial of Service family can be used in conjunction with Safe Checks to ensure that any potentially dangerous plugins are not run. However, it is recommended that the Denial of Service family not be used on a production network unless scheduled during a maintenance window and with staff ready to respond to any issues.

https://docs.tenable.com/nessus/Content/Plugins.htm

Nessus plugins with DoS in the name and not in the 'Denial of Service' plugin family are often simple checks that verify if the target is vulnerable to X DoS vulnerability based on the reported version.


DKIM and CNAME or DNAME As far as I understand, there should be no problems with using CNAME or DNAME records in connection with DKIM. That is, while the DKIM record for verifiying a mail from someone@example.com wants to be retrieved as a TXTRR under some.selector._domainkey.example.com, it might well be that some redirection occurs, such as

some.selector._domainkey.example.com. CNAME another-selector._domainkey.example.net. or
_domainkey.example.com. DNAME _domainkey.example.net. or
_domainkey.example.com. DNAME bar.example.net.

that is, the DNS resolving might go via a CNAME or DNAME into a completely unrelated domain and even, as the third example clarifies, lead to records that do not involve the well-known DKIM-specific _domainkey part.
Tome, this seems to be totally legit as far as DNS is concerned. And as DKIM is theoretically not restricted to retrieving keys by DNS, any Verifier should not care.
Of course, this does somewhat increase the DNS load and may slow down mail delivery by a few milliseconds. But this technique may come in handy when it is easier to change and update records under example.net than under the main domain example.com.
So my questions are:

Is this really "legal"?
Is it fully supported, i.e., do (widespread, non-obscure) implementation behave accordingly or are perhaps some known ti "deduct trust points" for such redirections? Or perhaps do some even then reject signatures altogether because they believe they are for the wrong domain?
Are there other security considerations that speak against this?

Yes, it's fully supported and widespread
DKIM doesn't implement DNS itself, but its DNS binding (RFC 6376, 3.6.2) is depending on the DNS, and it's using the namespace selector._domainkey.example.com. for TXT records. As CNAMEs and DNAMEs are specified in DNS RFCs, outside the scope of DKIM, they are followed by the DNS when querying for TXT records. DKIM simply inherits this behavior.
CNAMEs are widely in use on implementations where a third party email provider needs to be able to rotate the DKIM keys independently, e.g. Microsoft O365, AWS, SendGrid, ConvertKit & MailChimp.
There's no so much examples on DNAMEs, but it should work as well. One reason for why DNAMEs aren't used that much is that a purpose of the DKIM selectors is to enable multiple sources to send signed email for the same domain, e.g. both your mail system and your newsletter system. With a DNAME you would make an alias for every selector under _domainkey.example.com., pointing them all to a single service provider. It's simply not that useful.
There's nothing in DKIM specification that would require treating records that are fetched from external domains less trustworthy. And why would they, as it's the domain itself that delegates the trust by publishing such records.
Security considerations
First, it's worth to notice that DKIM is not even designed for strong authenticity, per RFC 6376, 8.5:

8.5.  Attacks against the DNS
Since the DNS is a required binding for key services, specific
attacks against the DNS must be considered.
While the DNS is currently insecure [RFC3833], these security
problems are the motivation behind DNS Security (DNSSEC) [RFC4033],
and all users of the DNS will reap the benefit of that work.
DKIM is only intended as a "sufficient" method of proving
authenticity.  It is not intended to provide strong cryptographic
proof about authorship or contents.  Other technologies such as
OpenPGP [RFC4880] and S/MIME [RFC5751] address those requirements.

Regarding DNSSEC, using CNAMEs or DNAMEs to other domains do decrease the security. E.g. if your example.com is a DNSSEC signed zone, but selector1._domainkey.example.com. is a CNAME to Microsoft's selector1-example-com._domainkey.contoso.onmicrosoft.com.. Currently onmicrosoft.com. is not DNSSEC signed. However, DKIM does follow these records, as full DNSSEC chains aren't required.


Is the ProtectedData class still an acceptable method to store passwords? I'm writing a piece of software which will have to store a users password to allow authentication with a 3rd Party service. Unfortunately, this service currently requires the use of a password rather than some other method. A key feature/advantage of this software will be the elimination of a sign-in prompt (after the first authentication), and so it's imperative that we store the password.

I intend to use the .NET ProtectedData class for this operation.

I'm essentially asking - is this acceptable in 2015? Is there a better and more secure method of storing this data?

Further detail as requested: The software is client side, designed to run in the users context on Windows desktops. These machines are generally going to be "managed" machines (I.e., under the control of an IT department), but I'm building on the presumption that this software could be installed on any client, by any user.

Therefore, I essentially need to presume that at any point a machine could be lost/stolen. That said, if a users account is compromised then that's already more damaging than a potential compromise of this password.

Yes, this is one of use cases that Protected Data (and the underlying DPAPI) was expressly designed for, and is generally probably the best mechanisms at your disposal.

One thing I'd add is that it's best to set the DataProtectionScope to CurrentUser, which will offer stronger protection, because the data isn't available to other users and processes on the machine as when the scope is set to LocalMachine.


Man-in-the-middle attacks in end-to-end encryption I am reading about how to implement end-to-end encryption in IMs. Then I find this question. I cannot understand how the man-in-the-middle attack happens when the author of the answer says:

  Note that this is still prone to man-in-the-middle attacks, so we will
  need an out-of-band method to verify that the two clients actually
  share the same key. This is often done by manually comparing hashed
  values of the keys (example: Signal).

Could you help me, please with more details, how the man-in-the-middle attack happens in this scenario?

Suppose the client software is trustworthy (after all, if it isn't, how do you know it doesn't send a copy of all your messages somewhere).

Everyone installs the client, it generates a new key pair each time, sends the public key to a directory service with the user's identifier (phone number, FB uid, whatever).

You want to send an encrypted message to me. You ask Signal's directory service (or Whatsapp, or whatever) for my public key. The directory service gives you a public key and says it's mine. You encrypt your message, send it to the chat service and I receive it and decrypt it using my private key. It works!

But, the directory service could have generated a new key pair, given you the public key, then when the chat service received the encrypted message, decrypted it, then encrypted it using my real public key (for which the private really only exists on my device), and sent it to me. We would not notice the small additional latency.

The way to check is to make sure the public key your client thinks is mine is the same one my client thinks is mine and to check that the public key my client thinks is yours is the same as the public key your client thinks is yours. If that is true (and the client software is itself trustworthy), you know the server does not do the MitM attack.

The way this verification is done differs between applications: Signal "verify safety numbers", Whatsapp "Verify Security Code", Wire "compare key fingerprints", etc.

There is a related attack, for example on iMessage, where I can be logged in on multiple devices, and when you encrypt your message to me, you actually encrypt it to multiple public keys, one for each of my devices. You get the list of all my public keys from the directory service. They can add a new key, as if I logged in on a new device, and your device will encrypt your messages to me to this key in addition to my other keys. But they control the new key. The way to protect would be to ensure new devices "joining the group chat" are visible to all other participants, but you can't. This is a UX tradeoff - the more secure the app is, the harder it is to use.


How to Leak Addresses with Format String Exploits By playing various wargames I noticed that I kept on getting stuck on format strings vulnerabilities, so I decided to step back and relearn them from scratch. In the process I realized that I couldn't explain to myself why we can read / write to arbitrary locations by providing a valid address.

printf (\x41\x41\x41\x41_%08x_%08x)

According to my understanding of format strings, this function call is supposed to simply print AAAA + stack value + stack value and nothing else. Instead, it leaks two addresses starting by the provided address

From https://crypto.stanford.edu/cs155old/cs155-spring08/papers/formatstring-1.2.pdf

The format function now parses the format string ‘A’, by reading a
character a time. If it is not ‘%’, the character is copied to the output. In
case it is, the character behind the ‘%’ specifies the type of parameter that
should be evaluated. The string “%%” has a special meaning, it is used to print
the escape character ‘%’ itself. Every other parameter relates to data, which
is located on the stack

If the above statement is true, and \x41\x41\x41\x41_%08x_%08x is the only argument of printf() allocated on the stack, then how can we explain reading / writing from/to memory locations ?

EDIT 1:

This answer does indeed specify that we can leak whatever address we want, but it doesn't go over how to start leaking from an arbitrary memory location.

I this other answer

So you're asking how printf can find the string because there is a
different parameter count than the % signs say? Two thought problems here: a)
Before printf can count the % at all, it has to find the string. Wrong string
content can't prevent finding this string. b) Without attacks: printf supports
variable parameter counts, and it always can find the string. Last parameter
etc. doesn't matter.

For some reason the OP assumes that the 'AAAA' part is an actual address.

@LiveOverflow helped me figuring out what I couldn't get. Both the assumptions I had were true

printf simply prints what ever isn't a '%' and treats in a special way charcters following '%'
Formatters (%x, %s, '%n, etc...) ONLY use addresses found on the stack (what I mean is that if we start popping off values using %x, those values will be popped of on the stack as long as valid addresses are available

Now in the code in the question, supplying an address as first argument is not enough, we have to somehow put on the stack the address we want to read/write from/to

example:

vuln.c (gcc -g vuln.c -m32 -o vuln):

#include <stdio.h>

int main (int argc, char ** argv) {

    buffer[32];

    fgets (buffer, sizeof(buffer), stdin);

    printf (buffer);

    return 0;
}

We can do by calling the program with an argument ./vuln AAAA. When asked for input we can insert there our format string. Here's the catch: we have to pop values off until we find our AAAA, after %s would dereference the address AAAA and read a string from there aka leaking an arbitrary address. Writing to an address works in the same exact way.

For the sake of simplicity I compiled it with -g so that I could use the *argv symbol

pwndbg> x/4s *argv
0xffffd258: "/home/ncrntn/vu"...
0xffffd267: "ln"
0xffffd26a: "AAAA"
0xffffd26f: "XDG_CONFIG_DIRS"...

At this point we know where to look at

pwndbg> x/200wx $esp
. . .
0xffffd260: 0x6e746e72  0x6c75762f  0x4141006e  0x58004141
. . .

And we indeed found our AAAA (in hex \x41\x41\x41\x41)


what happens if browser doesn't support X-FRAME-OPTIONS What happens if browser doesn't support X-FRAME-OPTIONS?

Does it render the uri referenced by the iframe OR it doesn't render anything in this case?

A browser that supports frames but not the X-Frame-Options header (or the corresponding CSP policies) will simply render any frame content, regardless of the origin. It can't implement a security mechanism that it doesn't know about.

X-Frame-Options was implemented by most major browser around 2010 (and only later specified in RFC 7034 in year 2013) - at that time, frames have already long been around. Introducing the header was a reaction to the clickjacking problem that arised due to  cross-origin frame embedding which couldn't be fully remediated with framebusting techniques.


What stops us from using an  tag to stop XSS? I am aware of various ways to prevent XSS attacks, such as escaping and encoding, which are prone to issues, and using a Content Security Policy which requires extraction of all scripts. However, what concerns prevent us from using an html tag such as <antiscript> to prevent the browser from executing any scripts under this element in the DOM tree, whether directly declared with <script> or as an tag attribute such as onmouseover, within these tags?
At first thought, it seems that would be rather easy to detect someone trying to break out of this non-scripting context because the </antiscript> tag would need to appear.

I don't think it would actually help.

If I understand correctly, you are proposing a scheme like this:

<antiscript>
    "$user-supplied-input"
</antiscript>

correct?

So what's stopping me from breaking out of it by providing the input:

"</antiscript>

so that the page source will be:

<antiscript>
    ""</antiscript>"
</antiscript>

The page is parsed, my  will not be inside the <antiscript> </antiscript> in the DOM. (the HTML that follows it will be broken, but since HTML parses top-to-bottom, my payload will make it into the DOM, so who cares?)

You address this in the question:

  It would be rather easy to detect someone trying to break out of this non-scripting context because the tag would need to appear.

But that means that under no circumstances could the string "</antiscript>" appear as text anywhere on the internet. That seems like a problem. What if, for example, you wanted to write a blog describing how to use this feature?


Instant signin links for users from trusted third party sites I'm owning web app "A" and want to work with a third party service "X". User "Alice" has accounts on both platforms. App A knows the user ID of alice on X, but X doesn't care about Alice being on A or not.

I want to provide service X with an easy to implement mechanism that would allow Alice to just click a link when logged in at X and - when not signed in already - be signed in to her account on app A, given that A knows Alice already of course.

For the most part I trust service X in this scenario. So I was thinking about giving them a secret key with which they can generate a short-lived JWT token. App A can just check that token and log Alice into her account.

Are there problems with this idea or obvious alternatives? I thought about OAuth, but that would mean service X needs to become an OAuth provider, which they are not or should not required to become. I also don't need to access any of Alice's data on X or check her name or anything.

JWT is a reasonable way to do this, as is OpenID or OAuth (With OAuth, what you are doing is creating a provider that will verify the userid).  Try to use standard libraries as much as possible - it is really easy to get Tokens wrong (enabling replay attacks and similar).  As well, all communications should be encrypted (TLS).


How can I spoof a phone call and make it appear to come from another phone? I'm performing a penetration test against a company. Part of my social engineering procedure is to contact the IT department and try to convince them to that I'm an employee in the company and get them to reveal some sensitive information including passwords.

How can I make my call more convincing by making it appear as if it came from some employee's phone number?

[This is a hypothetical question, created to preserve my deleted answer on this question]

There are many VoIP services that provide ID-spoofing functionality

Jumblo: Create an account and add some credit to it (10 Euros minimum excluding VAT), then install their Android app, login, the go to Settings and choose "Add Caller ID" then add the number. (Requires SMS verification) *

Skype: You can create an online number (15 Euros minimum) then add some credit to it (10 Euros minimum). Then go to the Caller ID page, and add the number you want. (Requires SMS verification) *

SpoofCard (10 U.S. Dollars minimum) (No SMS verification required)

SpoofTell (0.10 U.S. Dollars per call) (No SMS verification required)

* One way to acquire the SMS verification code from the target phone is by configuring the Caller ID number at the time the employee has left their phone unattended at a restaurant or a bar. Another possibility is by stopping the employee in the street and asking them to borrow their phone for an urgent call.


Possible Rogue Admin This does not involve me directly. However a friend believes her files are being tampered with and/or deleted by the only Windows domain admin there. (She has since kept backups) This started after she put in a complaint about him for misconduct (I'm being vague here as not to identify the person).

What exactly can one do to protect themselves both proactivly (in security and legal sense) and what to do if that administrator attempts to frame her for some sort of misconduct. eg surfing porn at work.

The obvious suggestion would be to bring her own laptop, and advise her workplace that she wants her domain account disabled. But it doesn't end there, all internet traffic must go through a proxy/cache cluster where the credentials are sent in the clear. (This was the case when I was at a similar place many years ago, hence why I know)

And to access other shared files on the network she would need a domain account anyway.

As tempting as it may be to try to use tools to defend herself (i.e. using personal equipment) or to catch the rogue admin in the act (logging, file integrity monitoring, etc.) many organizations have policies prohibiting these activities.

Your friend should be careful not to compromise her own integrity in response to this individual's actions.  This is not a technology problem.  In fact, it's one of the rare situations where removing the threat (the rogue admin) is easier than trying to defend against it.  Most organizations should have a policy that protects employees from retaliation when they raise a concern.

My advice for your friend would be to formally report the concern to a manager, HR, etc.  A forensic investigation should quickly reveal what the admin has been doing and would likely result in him/her being fired.


What do I need to do to secure log-in and registration for my website? What security features do I need to have in-place to ensure that my website log-in and registration forms are secure?

CSRF - You need to have protection in place to prevent cross site request forgery - or requests to login, signup, or other actions from other sites. This can be used to trick users into performing actions they didn't intend to.

CAPTCHA on signup - It's often recommended to use a CAPTCHA on your sigh-up form to reduce automated signups. How important this is depends on your threat model.

Secure login - The login needs to happen over HTTPS to reduce the risk of the user's credentials being captured via a MiTM attack.

Cookies - While login over HTTPS should be seen as a minimum, everything else really should be over SSL as well to protect the cookies (remember Firesheep?). Though just using SSL isn't enough, you need to set the Secure flag and HttpOnly flag whenever possible.

Email Confirmation - You need to make sure that you verify a user's email address as part of the sign-up process (I'd suggest not letting them login until it's confirmed). You'll need to have this for use in password resets.

Bruteforce protection - You need to protect against an attacker bruteforcing user accounts. There are various ways to do this, locking accounts (which can be used as a DoS attack by locking out large number of users), limiting failed attempts from a given IP (either via ban, or additional CAPTCHA). There are pros and cons to each method, but it's important that you have some form of protection in place.

Secure password reset - You need to make sure that you have a secure method for resetting passwords. This one is more complicated than most people think, and is easy to get wrong (as Apple recently found). The biggest risk is that an attacker finds a way to abuse the feature to reset accounts that they don't own.

I'd strongly suggest that you read the OWSAP Authentication Cheat Sheet, it goes into detail on these and many other potential issues; and as always, when building new systems, it's a good time to take another look at the OWASP Top 10 and make sure you have taken the proper precautions.


Why do we have such big keys? In Chapter 7 of Applied Cryptography, Bruce Schneier claims that, due to thermodynamic limitations, "brute-force attacks against 256-bit [symmetric] keys will be infeasible until computers are built from something other than matter and occupy something other than space." Looking at a few other questions, it seems that it hasn't somehow become possible.

As per this answer, we might lose a few bits of entropy in a real-world scenario, but I'd think that this would imply that even a really paranoid person would still be more than adequately protected by a 512-bit key.

So why do I often see keys being used that are 1024 or even 2048 bits long? Is it to protect against some other type of attack? Or are we just paranoid?

Your quote describes symmetric key strength, but your counter examples (1024, 2048 bits) reference keys used for asymmetric cryptography. The number of bits required for strength is different between the two.

Your quote is from section 7.1 of Applied Cryptography; if you move ahead to section 7.2, for example, you'll see Schneier's predictions on what lengths will be required to have secure asymmetric keys over time:

Printed in 1994, his predictions turned out reasonably sound except insofar as it is flatter across segments (e.g., individuals don't accept lesser key lengths).  (For non-historical purposes,  you should look for more up-to-date recommendations, such as NIST as summarized by KeyLength.com)


Evaluating Cloud Provider Security I am trying to make a judgement call on a cloud provider's security. This is what I know :

Provider A - PRGMR.COM (not very well known but competent and reliable)

Is very transparent - seeks feedback, honest about downtime, etc (a great plus in my experience)
provides out of band access via ssh (ssh-keys used for authentication, compromise of other users' keys doesn't necessarily mean compromise of system)
Uses open source software (Xen hypervisor)
located in the US

Provider B - Amazon EC2 (a very well known cloud provider)

Has obtained PCI level 1 certification
located in the US

What is the probability / risk associated with the provider's out of band console / infrastructure being compromised (which is more likely - amazon's infrastructure compromise or compromise of sshd on the Xen hypervisor aka provider B)

I will be contacting provider A to ask about their physical security measures...

On paper Amazon looks better than A but should transparency & honesty trump a PCI certification and popularity?

This may sound a bit of a cop-out, but at the end of the day it is down to what assurances you need from the provider so you should ask both of them the same questions - and these should be specifically on what you need to feel confidence that using the provider doesn't expose you to more risk than you can accept.

Have a look at this question about EC2 security for a bit of info.

Some more:

Amazon provide services to major corporates so have a vested interest in physical datacentre security - whether you can rely on this is up to you. Odds of you getting a guided tour are pretty slim.
Similarly, they aren't that transparent about a lot of their security features, but they do have a lot to lose and decent security budget so have put in place the features they feel are appropriate for their customers.
If you need a PCI certified provider (no matter what they are worth in the real world) then Amazon will fit the bill. If you don't need that, then you can ignore that feature as almost irrelevant - just accept that it means they have shown protection of account data sufficient to pass PCI-DSS.
Cloud services involve divesting some control around security and availability. If you have a critical uptime requirement or need to be able to carry out on the spot checking of hardware, the cloud may not be for you.


Encrypted folder with different access rights for different users With the GDPR (General Data Protection Regulation of EU) comes the necessity for many companies to store certain personal data (CVs, certificates, passport copies, etc.) centrally and encrypted. The data is available e.g. as Word or PDF files, in our case altogether 2000-3000 files distributed on 10 -15 directories.

The filing must take place encrypted, to prevent also IT administrators from  access, and centrally, so that the information or deletion request of affected persons can be followed.

That means that only a few people must be able to see/delete all data in the encrypted folder, whilst others only have access to their data stored in subfolders.

How can these requirements be fulfilled with a system, if possible with on-board means from Windows Server or a simple software?

According to my research EFS or Bitlocker are not usable, because either the rights can only be set to single files or no different rights within a container are provided.

I am very grateful for suggestions.

Solution-1 Enterprise & The Right Way
Check the steps listed below.

Prepare you information classification (public, private, internal only, etc.)
Define which type of data will be at which classification level
Define the permission strategy, define how you will identify who can do what at which doc. (object/subject/action matrix)
Deploy a file sharing software, it can be both embedded sharing solutions which are comes with OS or 3rd party tools.
Prepare users/user groups directories and set the permissions
Be sure you have logs of file actions on server / application (for example Windows does not store file action logs at default, "Audit object access" feature can give you the log)
Deploy an disk / file encryption solution, most of them encrypts all the system and only gives decryption rights to authorized users.
Deploy a DLP solution and monitor activities at clients (of course servers, network traffic, etc...)
Deploy SIEM solution, collect all of the logs of them and then correlate with each other.

Solution-2 Tageted // Just Wanna Be Compliant
Check OwnCloud (it have opensource version) tool or something similar like that. It is easy and stable which is compliant with GDPR, you can check it at https://owncloud.com/gdpr/.


Will this work? Revealing identity (facebook) of person who clicks specially crafted link There is a special Facebook link that will redirect anyone who clicks it to their own Facebook profile they are currently logged in on on their browser. The link goes like this: http://www.facebook.com/profile.php?=743264506 (the link is harmless by the way, you can Google it if you are unsure)

I had some suspicion that this could be used for revealing identity of a person just by sending them a specially crafted link. I am not a programmer, but this is what I thought:

Create a website that you link to the person you want to reveal the identity of.
The website contains some clever redirect or parsing script that sucks in the data from this special Facebook link, and then sends it back to the server (attacker).

Is this technically possible?

Contrary to the other answers, actually YES it is possible. However it is not actually so simple, and not exactly as you put it.

Instead of directing your victim to a profile, you can send him to your Facebook app. Of course, this app needs to be registered as a valid facebook app, and etc.
In the URL to your app, you can submit certain parameters - say, for example, the user's current session id on your own website.
Note that this URL is directed to Facebook, and thus your FB cookie will be sent, since it is FB's servers; they then forward the request to your app.
Your facebook app should be hosted on your own server, and this should be have some form of communication with your victimizing website, allowing a lookup between the Facebook identity and the session id.
Thus, you just used Facebook as an unintentional identity provider.
Using certain additional techniques, such as CSRF, you can send the user directly and automatically, simply by being on your site.
Note, however, that this is actually not as simple as it once was, and here is where social engineering would come into play: Facebook now requires explicit user approval before allowing an app access to your details.
On the other hand (and I admit I may be out of date on this - it is hard to keep up with Facebook's consistency) - there are some details that an app can recieve before even asking you to install it. (I'm not going in to all those technical details here, I think it's irrelevant at this point, and would probably be off topic. )

You can find more in depth details, including all the technical details, on this blog post from a few years ago; as I said, some of it may be out of date.
(Disclosure: I did assist in some of that research).


Encryption in Linux: covenience and security I was using TrueCrypt until recently, until one of two options has happened: either it was discontinued or its web-site truecrypt.org was hacked. Any option implies that I don't trust it anymore.

So I'm now looking for encryption that is both convenient (just drag and dropping a file into a container) and secure (in the sense that a Russian hacker won't break it).

No need to encrypt the whole HDD, nor individual encryption per file, but a volume encryption.

How can I tell which software is reliable, to avoid a repeat of the TrueCrypt mishap?

Use your operating system's native encryption mechanism unless you have a good reason not to. The native feature has better integration with the rest of the system, which means easier administration, less risk of misconfiguration and less risk of programming errors, all of which add to better presumptions of security.

This means: under Windows, use Bitlocker. Under Linux, use Dm-crypt via LUKS for whole-disk encryption, and Ecryptfs for home directory encryption.

This was true even before the security of Truecrypt was seriously cast in doubt by the project homepage being modified to recommend not using it.


Capability of microcode hacking? Before Spectre and Meltdown, I've never heard of users updating microcode on a chip through firmware or otherwise. I actually thought it was written into the silicon and immutable. Now I'm seeing a lot of mentions about this., things like disabling branch prediction and such.

To what degree is there any precedent for this? Has it been done officially or otherwise (through hobbyist channels). Can one for example, reprogram an Intel chip disabling everything but RISC instructions? And is there any way to verify executing Microcode has not been maliciously modified?

Intel has been releasing microcode updates for its CPUs since at least January 29, 2000.  AMD has been releasing microcode updates for a similar length of time.

In theory, it's possible to reprogram an Intel chip to do whatever you want, within the capabilities of the silicon.  In practice, as the above website notes, microcode updates appear to be signed using best-practices public-key cryptography.  As a result, only microcode updates signed by Intel will be accepted by the chip: neither tinkerers nor malicious actors can provide a valid update.


Risks of photographing sensitive information using Android devices? Sometimes I have to photograph sensitive documents such as bank checks or tax forms etc. Is it completely safe to do with a smartphone, or can there be security threats?

Notably, the legit apps in our phones seem to have a lot of AI activities, changes, and the phones consume approx 100MB to 500MB data per day even when not in use.
This makes me think of if there could be security risks or surveillance threats.

Is there any additional risk if the phone is Chinese-originated?

Is it completely safe to do with a smartphone

"Completely safe" is a myth.

  or can there be security threats?

The security threats depends upon what application you got installed on the phone and other varying factors too.

  This makes me think of if there could be security risks or surveillance threats.

You need to look into processes and connections, and examine the data in transit to affirm the claim.

  Is there any additional risk if the phone is Chinese-originated?

Most chips are manufactured in China. There are speculations that the Chinese government asked companies to embedded smartphone chips with obfuscated monitoring microchips, but some deny it. Please check your own model and make OR consider buying a trusted device examined earlier.


Are ARP attacks possible on OpenVPN and Wireguard connections? I am curious if it is possible for users connected to a VPN to perform ARP spoofing / poisoning attacks against other users on the same subnet of an OpenVPN or Wireguard server. Does OpenVPN & Wireguard provide inbuilt mitigation's against ARP attacks by default & if so can this protection be disabled by malicious or compromised servers?

ARP is a link layer 2 ethernet protocol, it does not exist at IP layer 3.

So no.

EDIT

Normally VPNs use TUN, which is layer 3. There is a TAP layer 2 which will carry ARP, but outside of businesses BRIDGING two remote networks together this is seldom used. In a TAP bridge, you probably could ARP spoof.


How does SSL/TLS PKI work? We have lots of questions that address portions of SSL/TLS as it relates to PKI, but none of them seem to bring everything together.  A canonical answer that we can point people to I think would be quite helpful.

We have How Does SSL/TLS Work? which will give a nice basis, and does contain a section on client certificates.  It should be read before trying to understand PKI.
We have A Different Approach to PKI which explains some problems with the overall ideas of PKI.
There is How does SSL client authentication work?, which is a fairly terrible question and answer.  Easy explanation of SSL client certificates for a developer is a bit better, but leaves something to be desired.
There are quite a few question and answers on actually implementing a PKI, but that's a bit out of the scope of this question.

I think the main questions to be answered that seem to be the source of some confusion among posters (All with respect to SSL/TLS):

What is the difference between Public Key Infrastructure and Public Key Cryptography?  How are they related?
What is the main use case for PKI?
How are client certificates used in PKI?
What is a Certificate Authority's role in PKI?

Public Key Cryptography designates the class of cryptographic algorithms that includes asymmetric encryption (and its cousin key exchange) and digital signatures. In these algorithms, there are two operations that correspond to each other (encrypt -> decrypt, or sign -> verify) with the characteristic that one of the operations can be done by everybody while the other is mathematically restricted to the owner of a specific secret. The public operation (encrypting a message, verifying a signature) uses a public parameter called a public key; the corresponding private operation (decrypting that which was encrypted, signing that which can be verified) uses a corresponding private parameter called a private key. The public and private key come from a common underlying mathematical object, and are called together a public/private key pair. The magic of asymmetric cryptography is that while the public and private parts of a key pair correspond to each other, the public part can be made, indeed, public, and this does not reveal the private part. A private key can be computed from a public key only through a computation that is way too expensive to be envisioned with existing technology.

To make the story short, if you know the public key of some entity (a server, a human user...) then you can establish a secured data tunnel with that entity (e.g. with SSL/TLS in a connected context, or encrypting emails with S/MIME).

The problem, now, is one of key distribution. When you want to connect to a server called www.example.com, how do you make sure that the public key you are about to use really belongs to that server ? By "belong", we mean that the corresponding private key is under control of that server (and nobody else).

Public Key Infrastructures are a solution for that problem. Basically:

The goal of a PKI is to provide to users some verifiable guarantee as to the ownership of public keys.
The means of a PKI are digital signatures.

In that sense, a PKI is a support system for usage of public key cryptography, and it itself uses public key cryptography.

The core concept of a PKI is that of a certificate. A certificate contains an identity (say, a server name) and a public key, which is purported to belong to the designated entity (that named server). The whole is signed by a Certification Authority. The CA is supposed to "make sure" in some way that the public key is really owned by the named entity, and then issues (i.e. signs) the certificate; the CA also has its own public/private key pair. That way, users (say, Web browsers) that see the certificate and know the CA public key can verify the signature on the certificate, thus gain confidence in the certificate contents, and that way learn the mapping between the designated entity (the server whose name is in the certificate) and its public key.

Take five minutes to grasp the fine details of that mechanism. A signature, by itself, does not make something trustworthy. When a message M is signed and the signature is successfully verified with public key Kp, then cryptography tells you that the message M is exactly as it was, down to the last bit, when the owner of the corresponding private key Ks computed that signature. This does not automatically tell you that the contents of M are true. What the certificate does is that it moves the key distribution problem: initially your problem was that of knowing the server's public key; now it is one of knowing the CA's public key, with the additional issue that you also have to trust that CA.

How can PKI help, then ? The important point is about numbers. A given CA may issue certificates for millions of servers. Thus, by action of the CA, the key distribution problem has been modified in two ways:

From "knowing the public keys of hundreds of millions of server certificates", it has been reduced to "knowing the public keys of a thousand or so of CA".
Conversely, an additional trust requirement has arisen: you not only need to know the CA keys, but also you need to trust them: the CA must be honest (it won't knowingly sign a certificate with a wrong name/key association) and also competent (it won't unknowingly sign a certificate with a fake name/key association).

The PKI becomes a true infrastructure when recursion is applied: the public keys of CA are themselves stored in certificates signed by some über-CA. This further reduces the number of keys that need to be known a priori by users; and this also increases the trust issue. Indeed, if CA2 signs a certificate for CA1, and CA1 signs a certificate for server S, then the end user who wants to validate that server S must trust CA2 for being honest, and competent, and also for somehow taking care not to issue a certificate to incompetent or dishonest CA. Here:

CA1 says: "the public key of server S is xxx". CA1 does not say "server S is honest and trustworthy".
CA2 says: "the public key of CA1 is yyy AND that CA is trustworthy".

If you iterate the process you end up with a handful of root CA (called "trust anchors" in X.509 terminology) that are known a priori by end users (they are included in your OS / browser), and that are considered trustworthy at all meta-levels. I.e. we trust a root CA for properly identifying intermediate CA and for being able to verify their trustworthiness, including their ability to themselves delegate such trustworthiness.

Whether the hundred or so of root CA that Microsoft found fit to include by default in Windows are that much trustworthy is an open question. The whole PKI structure holds due to the following characteristics:

PKI depth is limited. A certificate chain from a root CA down to an SSL server certificate will include 3 or 4 certificates at most.
CA are very jealous of their power and won't issue certificates to just any wannabe intermediate CA. Whether that "CA power" is delegated is specified in the certificate. When a CA issues a certificate to a sub-CA, with that specific mark, it does so only within a heavy context (contracts, insurances, audits, and lots of dollars). Ultimately, trust is ensured through fear. Offending CA are severely punished.
Nobody really has interest in breaking the system, since there is no readily available substitute.

Note that, down the chain, the server S is verified to really own a specific public key, but nobody says that the server is honest. When you connect to https://www.wewillgraballyourmoney.com/ and see the iconic green padlock, the whole PKI guarantees you that you are really talking to that specific server; it does not tell you that sending them your credit card number would be a good idea.

Moreover, all of this is association between the server name as it appears in the target URL and a public key. This does not extend to the name intended by the user, as that name lives only in the user's brain. If the user wants to connect to www.paypal.com but really follows a URL to www.paaypaal.com, then the PKI and the browser will in no way be able to notice that the user really wanted to talk to PayPal, and not another server with a roughly similar (but not identical) name.

The main use case for a PKI is distributing public keys for lots of entities. In the case of Web browsers and SSL, the browser user must be able to check that the server he tries to talk to is indeed the one he believes it to be; this must work for hundreds of millions of servers, some of which having come to existence after the browser was written and deployed. Reducing that problem to knowing a hundred root CA keys makes it manageable, since one can indeed include a hundred public keys in a Web browser (that's a million times easier than including a hundred million public keys in a Web browser).

Client certificates are a SSL-specific feature. In all of the above we talked about a SSL client (Web browser) trying to authenticate a SSL server (Web server with HTTPS). SSL additionally supports the other direction: a SSL server who wants to make sure that it talks to a specific, named client. The same mechanism can be used, with certificates.

An important point to notice is that the server certificate and the client certificate live in different worlds. The server certificate is validated by the client. The client certificate is validated by the server. Both validations are independent of each other; they are performed by distinct entities, and may use distinct root CA.

The main reason why SSL servers have certificates is because clients cannot possibly know beforehand the public keys of all servers: there are too many of them, and new ones are created with every passing minute. On the other hand, when a server wants to authenticate a client, this is because that client is a registered user. Usually, servers know all their users, which is why most can use a simpler password-based authentication mechanism. SSL client certificates are thus rather rare in practice, because the main advantage of certificates (authenticating entities without prior knowledge) is not a feature that most servers want.


Linux Rootkit / BIOS Malware: What packages are necessary to get infected? Everybody knows about the dangers of Rootkits / BIOS malware. What do you say about this countermeasure?

In order to actually get infected the malware needs to use the OS to 'patch' the BIOS chip.

Now consider running Linux OS.

What package / tool in OS is responsible for patching / updating / upgrading / writing to the BIOS chip?
Is it possible to remove these packages in order to prevent any malware from writing to any BIOS hardware?
Is it furthermore possible to hardcode a rule inside your OS that prevents any change to any BIOS software with no exceptions whatsoever? Even if the malware reaches the targeted system and manages to install these missing 'tools' mentioned above, it wouldn't work out, because the write link to BIOS hardware is forbidden in Kernel code?

The problem is that the early developers of the BIOS malware already thought of the potential for the necessary drivers not being available, so they included them.

If you can write a rule to prevent something, then you can interact with the rule and disable it, so that's not an option either.

The primary defence is not to allow kernel mode access to the malware. You do this by limiting the access of any executable (i.e. not root).

Anti-malware software often include a wrapper for the BIOS writing processes and prevent unauthorized use.

The combination of restricted access and wrapped processes are the better methods then what you suggest.


Why do we need DKIM to be used along with S/Mime? S/Mime can be used to encrypt email and it can also be used by the sender to provide his digital signature so that the recipient is able to confirm the authenticity of the sender.

Why then do we still need to have DKIM implemented on top of S/Mime in certain cases. I do understand that DKIM is used to authenticate the domain but isn't a digital signature of the user via s/mime a more stronger form of authentication?

I would also appreciate if as an answer someone can explain the flow of how DKIM can be implemented on top pf S/mime (The order in which the encryption and decryption steps happens).

S/MIME and DKIM are totally independent from each other. S/MIME signature and encryption is applied by the sender (end user) while DKIM signatures are applied by the mail server of the senders domain. Similar DKIM is usually verified by the mail server of the receiving domain while S/MIME signature and encryption are verified by the final recipient - the recipients mail server usually has not the necessary information anyway.

Additionally DKIM (in connection with DMARC) is used to detect spoofing of the senders domain only, while S/MIME signatures are used to verify the actual sender and not only the domain. And S/MIME offers encryption while DKIM does not.

It is true that a valid S/MIME signature provides a stronger proof of the sender than a DKIM signature. But there is no actual harm in using DKIM in addition to S/MIME.


How does a sandbox module know the difference between trusted and untrusted code What criteria does a sandbox use to determine whether executing code (registry read/write) can be trusted or not ?

A well-designed sandbox is simple: all code inside it is untrusted, and has to ask the sandbox if it wants access to anything outside.


What is chrome.googleechotest.com? I use chrome (dev channel) on mac osx lion and every now and then it tries to access chrome.googleechotest.com on port 80 (EDIT: and other ports!).

Anybody knows what is the deal with chrome.googleechotest.com ?

Sounds like its an google's echo test for chrome.  The whois (below) points back to Google, Inc.  It seems that it is used to send back network connectivity stats to a google server for ~0.5% of users..

An echo in this context just means whether if you send a simple message to a remote computer if you hear back.  (Similar to ping/ICMP message).

EDIT: See Graham Hill's excellent comment below to disable this feature in chrome (In Settings, Under the Hood, uncheck "Automatically send usage statistics and crash reports to Google" or similar text.)

# whois googleechotest.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: GOOGLEECHOTEST.COM
   Registrar: MARKMONITOR INC.
   Whois Server: whois.markmonitor.com
   Referral URL: http://www.markmonitor.com
   Name Server: NS1.GOOGLE.COM
   Name Server: NS2.GOOGLE.COM
   Name Server: NS3.GOOGLE.COM
   Name Server: NS4.GOOGLE.COM
   Status: clientDeleteProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Updated Date: 21-oct-2011
   Creation Date: 21-oct-2011
   Expiration Date: 21-oct-2013
...

Registrant:
        DNS Admin
        Google Inc.
        1600 Amphitheatre Parkway
         Mountain View CA 94043
        US
        dns-admin@google.com +1.6502530000 Fax: +1.6502530001

    Domain Name: googleechotest.com

        Registrar Name: Markmonitor.com
        Registrar Whois: whois.markmonitor.com
        Registrar Homepage: http://www.markmonitor.com

    Administrative Contact:
        DNS Admin
        Google Inc.
        1600 Amphitheatre Parkway
         Mountain View CA 94043
        US
        dns-admin@google.com +1.6502530000 Fax: +1.6502530001
    Technical Contact, Zone Contact:
        DNS Admin
        Google Inc.
        1600 Amphitheatre Parkway
         Mountain View CA 94043
        US
        dns-admin@google.com +1.6502530000 Fax: +1.6502530001

    Created on..............: 2011-10-21.
    Expires on..............: 2013-10-21.
    Record last updated on..: 2011-10-21.

    Domain servers in listed order:

    ns1.google.com
    ns2.google.com
    ns4.google.com
    ns3.google.com


If I connect to a website directly (by IP) over HTTPS, can a network admin seen what IP I'm accessing? I know that by connecting to a HTTPS site by accessing its url (say, https://google.com), the network admin can see the fact that I'm connecting to google because the browser will do DNS lookups in cleartext.

However, if I connect directly to the IP (say https://11.51.24.51), no DNS lookups are preformed, right? So the URL/IP wouldn't be leaked? Or am I missing something?

You're still forming a direct connection to the IP address. The network admin would be able to see you're connecting to that IP even though he can't see the contents of the connection.

Using publicly available tools such as this site, in most cases they would have a decent idea about what you're trying to access.


Does RADIUS allow for eventual, gradual adoption of 2 Factor auth in an AD Environment? We have several applications that leverage AD

SAML (via Ping Federate)
LDAP authentication from 3rd party applications
Windows workstation / Exchange auth  (Kerberos)
IIS and web components (su4user, impersonation, etc)

I have never deployed 2 factor auth in an AD environment and remember reading that RADIUS was leveraged in a way to accommodate many if not all of the scenarios above, with minimal impact to the end users.

Can anyone explain the infrastructure that is needed for a private corporation to deploy 2FA to their AD Forest, and allow 3rd parties (such as Salesforce, Dropbox, Office 365) to leverage that authentication?

A partial answer that may get you on the right path is to set up NPS as your radius server and get as many of your applications using radius.  This is simple to do for VPNs.  Your 3rd party apps will have to support radius as well as ldap.  LDAP will not proxy the credentials to a 3rd party server like radius.  IIS support radius auth.  Not sure if Ping supports radius.  Do not use radius over the internet, except in an encrypted tunnel.

Workstation login is very hard to via radius as the GINA just doesn't support it.

We have a doc on adding two-factor to NPS: https://www.wikidsystems.com/support/wikid-support-center/how-to/how-to-add-two-factor-authentication-to-nps and we have a pdf on the architecture of it here: https://www.wikidsystems.com/learn-more/white-papers.