How to prevent illegal connection to my router WiFi In my question, which was marked as a duplicate, I got suggested posts to refer to. I`ve read all of them; and my router options are already matching the suggested options: as using WPA2 with AES, and WPS and UPnP are turned off. If I change the username and strong password I am using, and someone has managed to bypass them, he can do this again.

I am suspecting that someone is illegally using my router WiFi. Is there a software that can be installed on my computer (running Windows XP, and connected by a cable to the router) to identify the devices connected wirelessly to my router, which does not have the feature to list devices connected to it?

Or a way to prevent devices other than those in my home (laptops, cell phones, tablets) which are connected wirelessly to my router?

I did not find the answers to these questions in the suggested posts.

I am suspecting that someone is illegally using my router WiFi.

While there might be someone doing this, nothing in your question provides any evidence. Note that it is not uncommon that users suspect hackers when strange behavior happens even if there are other and sometimes simpler explanations possible.

  Is there a software that can be installed on my computer (running Windows XP, and connected by a cable to the router) to identify the devices connected wirelessly to my router, which does not have the feature to list devices connected to it?

If your router does not provide such functionality no software can ask the router to provide these information. You could analyze your network though for suspicious activity, i.e. if systems connect to your computer which you don't expect to etc. What to do exactly here depends on what you suspect the hacker to do, which essentially boils down again to what makes you think that there is someone using your router in the first place.

"...running Windows XP..." - if the rest of your network is as secure as your long outdated and no longer supported operating system than it is not unlikely that somebody is misusing your network though.

  Or a way to prevent devices other than those in my home (laptops, cell phones, tablets) which are connected wirelessly to my router?

That's what you do exactly by following the recommendations in the questions+answers provided as duplicates to your previous questions, i.e. having a secure router (i.e. current firmware, no backdoors ...) and setting it up in a sane way (WPA2, strong passphrase, strong admin password, no access from outside ...).

And note that a strong WPA2 passphrase does not help if an insecure device is connected per cable to the router (or per WiFi but knows the password), like it seems to be the case with your Windows XP system. This is especially a problem if these insecure devices are used for administration of the router.


If a site says its API for login can't be made available for "Security Reasons" should I be worried Stack Exchange API 2.2 is finally out,
(Yay!)

Reading through the linked blog post, i notice the line:

  Login methods that don’t use OAuth can’t be made public for security reasons.

Is this something to worry about?
Seems kinda suspicious.
Sounds like Security Through Obsurity.
"If know one knows how it works they can't hack it."
Or that their are known bugs in the (nonOAuth) logon methods that leave them insecure, and they are more exploitable through the API (but that means they exist, and can, with the right tools be exploited anyway.)

It is probably more to make it more difficult to exploit via a fake login page.  If it was possible for a login to be done through the API, then a fake login could be done on another site.  OAuth provides some level of protection against this because of how the information is exchanged.


Effectiveness of flattening a PDF to remove malware I'm currently looking at ways to prevent malicious PDF files at the network boundary. This will include virus scanning - but there are known limitations to that. I see a common approach is to flatten the PDF file using something like:

gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=flattened.pdf raw.pdf

While this certainly seems to remove the usual suspects from the output of pdfid, that alone does not mean that the associated threats have been eliminated.

Hence:

Will this approach eliminate most Flash and Javascript exploits?
What threats are likely to persist?

Notes:

As this is intended for bulk scanning, suggestions such as this are not really practical at scale.

Links to authoritative sources would be much appreciated.

Update

The method above removes Flash and Javascript from the PDF. Steffen (see below) highlighted that malware embedded in image files would likely survive. To mitigate this, I am downsampling the images. I've not been able to get a clear answer to whether gs preserves or removes EXIF data, but the downsampling will likely alter the offset of any malware embedded there nullifying its exploitability, and the downsampling should also remove any malware embedded in image data. Hence:

DPI=63

gs -dBATCH -dNOPAUSE -dQUIET -sDEVICE=pdfwrite \
   -dDownsampleColorImages \
   -dColorImageDownsampleType=/Bicubic -dColorImageResolution=${DPI} \
   -dDownsampleGrayImages \
   -dGrayImageDownsampleType=/Bicubic -dGrayImageResolution=${DPI} \
   -dDownsampleMonoImages \
   -dMonoImageDownsampleType=/Bicubic -dMonoImageResolution=${DPI} \
   -sOUTPUTFILE=${TMPPDF} ${SRCFILE}

I think using gs should remove all active content (Javascript) and embedded data (Videos, Flash...). But I'm not sure if using pdfwrite directly on the PDF will really remove all active and embedded content. Thus I suggest that you first convert the PDF to Postscript using gs and then convert the Postscript back to PDF using gs with the pdfwrite backend. Since the Postscript format itself does not support active or embedded content such content should not survive the conversion process. I'm not sure if this will also help against image formats, like exploiting vulnerabilities in libjpeg, libpng or similar. In any case the call to gs itself should be done inside some kind of protected environment (i.e. sandbox or similar) so that such vulnerabilities do not affect the security of the security system itself.

Another option would be to convert the PDF to images and maybe create a new PDF with these images then. This way you could protect against exploiting vulnerabilities in image libraries too, but at the cost of loosing the ability to work with the PDF as text (i.e. search, copy...). If you want the additional protection but need the ability to handle the PDF as text you could run some OCR software afterwards to reconstruct the text from the images.


Does the bash shell function import feature inevitably give rise to privilege escalation problem? Even without the immediate code-execution problem of Shellshock trailing commands, to what extent does the feature of bash importing functions from the environment give rise to a comprehensive privilege escalation vulnerability?

To be clear, there are many setuid programs, and some of them will directly or indirectly call scripts, or use the system(3) call, which on most Linuxes goes through bash. The question is to what extent, assuming systems have such setuid binaries installed, this feature of bash allows local privilege escalation.

For example if calling a script does it allow overriding of built-ins? If so can this give rise to an escalation of privilege in combination with a setuid executable and the system(3) call, by overriding e.g. ls, cd or something innocuous?
Would such an escalation vector require a script to be called (in which case one could potentially override ls or any command used by the script which didn't use a full path)?
Are imported functions potentially used at any point by the normal execution path of /bin/sh -c ARGUMENTS even when the first argument is not a script?
Could you simply give an environment variable the same name as the first argument to system?
If so does that mean that every call to system(3) by a setuid executable, on a system where /bin/sh is bash, is a privilege escalation vector?

These tests are run on an unpatched system:

# ls='() { echo NO; }' bash -c 'ls'
NO

the * wildcard is required or perl will replace system call with a fork/exec combination

# ls='() { echo NO; }' perl -e 'system("ls *");'
NO

However ls is not a builtin:

# type ls
ls is hashed (/bin/ls)
# type echo
echo is a shell builtin

So lets try overriding built-in echo
("command" overides the built-in to avoid recursion):

# echo='() { command echo NO; }' bash -c 'echo YES'
NO

So far we showed that:

it can override a built-in
and does not require a script to be called
even when the first argument is not a script
every call to "system" is a vector, giving privileges of the caller

I think naked "system" and "popen" are rotten, I think most uses of these don't bother to escape shell meta-characters in user data.

I have this invocation when I want to have the shell produce pipelines or use shell built-ins, but it still requires fork/exec:

exec("sh", "-c", "\"$0\" \"$1\" | tee -a \"$2\"", ...);

The technique gets bash to refer to the arguments of the -c commands, $0 being the first such argument, or "--" can be used as a filler:

exec("sh", "-c", "\"$1\" \"$2\" | tee -a \"$3\"", "--", ...);

This test is run on a patched system:

$ env "BASH_FUNC_ls()=() { echo NO ; }" bash -c 'ls'
NO

showing clearly that this issue is nothing to do with shellshock.

While authors of scripts or script-using tools should know to validate user input, and should know to validate/clean the environment (as it contains user input) some parts of the environment can need to be preserved, and it can't always be easy to see which they might be;

XAUTHORITY, DBUS_SESSION_BUS_ADDRESS, XDG_SESSION_DESKTOP, SSH_AUTH_SOCK are a few and other important environment variables may not yet be invented

it is called "environment" for a reason. The PATH can maybe be sanitised, but the first command issued to system() can be surplanted

The sudoedit man page writes:

Running shell scripts via sudo can expose the same kernel bugs that make
setuid shell scripts unsafe on some operating systems (if your OS has a
/dev/fd/ directory, setuid shell scripts are generally safe).

However this will not be true for setuid bash shell scripts unless they refuse to import all bash functions


Can a properly implemented TLS connection be intercepted? Assuming a TLS connection where both the server and client perfectly adhere to the pertinent standards.

Can an transparent HTTPS proxy intercept the TLS connection? (Assuming the "mock CA" certificate used by the proxy is in Trusted Root on the client)
(Possibly out of scope not quite sure?) If not which (a) server and (b) browser are closest to having such an implementation?

This question is prompted by the following quote regarding the TLS protocol and the Squid proxy software "If [the TLS] security was actually being used properly bumping [aka interception as described in Q1] is not even possible. There are a growing number of transactions that do it in ways getting ever closer to that proper use."

Regarding your first question: The answer hinges on the definition of "transparent". To me, transparent interception would imply that no certificates or certificate authorities have to be manually added by clients to the "trust store" of their devices. As long as this condition holds and your browser correctly checks the presented certificate for its validity, an attacker will not be able to intercept your connection, unless they manage to do one of the following:

compromise one of the CAs your device trusts
somehow get a trusted CA to sign a counterfeit certificate for a site they do not actually own
manipulate the trust store on your device
or get hold of a specific server's private key.

The reason why these are the only attack vectors (again, if the validity check is properly implemented client-side) is that the server will present a certificate (including the server's public key) that is itself signed with some CA's private key. The client checks whether the signature matches with the public key it has stored for the corresponding CA, and if it does, starts a TLS/SSL handshake with the server. It is at one point of this handshake protocol that the client encrypts some connection-specific information with the server's public key. Whoever is intercepting the message will then have to decrypt the information with the server's private key and send it back to prove they are not, in fact, someone else.

Regarding your second question, I do not know what exactly is meant in the sentence you quoted. What I know is that all popular modern browsers do correctly validate certificates. There is, however, another interesting mechanism in regards to certificate security that is not adopted by all modern browsers, at least as far as I know. Public Key Pinning is a concept related to trust on first use : When you first visit a website, you "pin" the public key you were shown to that domain and check whether it is still the same on subsequent visits to the page. This protects against attack scenarios 1 and 2 outlined above - you do no longer have to worry about fake certificates being issued if only you saw the legitimate certificate once before. Public key pinning can not only be done for specific servers but for any CA in the chain of trust. To answer your actual question, Chrome and Firefox are able to do public key pinning (and there are probably others, but I do not know every single one of them).


Should the shellcode be "reversed" before beeing injected in a simple buffer overflow? I'm new to buffer overflows and I'm trying to understand exactly what I'm doing before using any premade and easy to go scripts.
My goal is to spawn a shell, so I found the asm code to do an execve("/bin/sh"). The shellcode comes from shell-storm. :

char *shellcode = "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69"
          "\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80";

Going through tutorials and stack documentation, I understood that the stack goes downward (from high addresses to low addresses when we add data on it).

For now let's say that this shellcode is stored in a local buffer starting at 0x00.

Will we have the shellcode stored like that :

0x00 31 c0 50 68
0x04 2f 2f 73 68
0x08 .....

meaning that in the stack it will looks like :

0x08 .....
0x04 2f 2f 73 68
0x00 31 c0 50 68

When a scanf("%d",myInt) is performed I understand that if we give "9" and that &myInt = 0x04
we will have 0x04 : 09 00 00 00 . Means that the "09" is at the address 0x04. Even if addresses are only accessible when they are a multiple of 4 and given that this is little endian.
Now how does the scanf works with  a %s ? Does he read chars four by four and store the first in the (little endian) lowest 0x04 address and the 4th in the 0x07?

So the real question is:

Considering that we usually reverse the address that we want to see taking the place of the stored IP. Should we do the same for our shellcode ?
When we want to overwrite the IP register in the stack by 0x01020304 we commonly write in our payload \x04\03\02\01 because we write in the stack upward, meaning that we hit the least significant bit of an address first.

No, most operating systems today are little endian, the string are reversed in memory. To see this, compile in 32 bits a code like:

    // test.c
    #include <stdio.h>

    int main(){
        char buf[8] = "ABCDEFGH";
        int n = 9;
        printf("%s\n", buf);
        printf("%d\n", n);
        return 0;
    }

with:

$ apt install gcc-multilib
$ gcc -g test.c -o test -m32

Then run the binary in gdb, break before printf execution and look at the stack:

$ gdb ./test -q
Reading symbols from ./test...done.
(gdb) disas main
Dump of assembler code for function main:
   [...]
   0x000011db <+50>:    sub    $0xc,%esp
   0x000011de <+53>:    lea    -0x14(%ebp),%eax
   0x000011e1 <+56>:    push   %eax
   0x000011e2 <+57>:    call   0x1040 <puts@plt>
   [...]
End of assembler dump.
// printf is replaced by puts system call here

(gdb) b *main+57
Breakpoint 1 at 0x11e2: file test.c, line 6.

(gdb) r
Starting program: /root/test

Breakpoint 1, 0x565561e2 in main () at test.c:6
6       printf("%s\n", buf);

(gdb) x/20x $esp
0xffffd280: 0xffffd294  0x56559000  0xffffd35c  0x565561c0
0xffffd290: 0x00000001  0x44434241  0x48474645  0x00000009
0xffffd2a0: 0xffffd2c0  0x00000000  0x00000000  0xf7deab41
0xffffd2b0: 0xf7faa000  0xf7faa000  0x00000000  0xf7deab41
0xffffd2c0: 0x00000001  0xffffd354  0xffffd35c  0xffffd2e4

ASCII code for 'A' is 0x41, 'B' 0x42, ..., so in the second line you can see that ABCDEFGH is stored as:

0x94: DCBA
0x98: HGFE
0x9B: 0x00000009

Note that the end of the string is in a higher address.

Scanf store the input string in the same way:

$ cat test.c

#include <stdio.h>

int main(){
    char input[8];
    scanf("%s\n", input);
    printf("%s\n", input);
    return 0;
}

$ gcc -g test.c -o test -m32
$ gdb ./test -q

(gdb) disas main
   [...]
   0x000011d4 <+43>:    call   0x1050 <__isoc99_scanf@plt>
   0x000011d9 <+48>:    add    $0x10,%esp
   0x000011dc <+51>:    sub    $0xc,%esp
   0x000011df <+54>:    lea    -0x10(%ebp),%eax
   0x000011e2 <+57>:    push   %eax
   0x000011e3 <+58>:    call   0x1030 <puts@plt>
   [...]

(gdb) b * main+58
Breakpoint 1 at 0x11e3: file test.c, line 6.

(gdb) r < <(echo "ABCDEFG")
Starting program: /root/test < <(echo "ABCDEFG")

Breakpoint 1, 0x565561e3 in main () at test.c:6
6       printf("%s\n", input);
(gdb) x/20x $esp
0xffffd280: 0xffffd298  0xffffd298  0xffffd35c  0x565561c0
0xffffd290: 0x00000001  0xffffd354  0x44434241  0x00474645
0xffffd2a0: 0xffffd2c0  0x00000000  0x00000000  0xf7deab41
0xffffd2b0: 0xf7faa000  0xf7faa000  0x00000000  0xf7deab41
0xffffd2c0: 0x00000001  0xffffd354  0xffffd35c  0xffffd2e4
(gdb)

Because of that you have to reverse the address you want to put in eip via an input string to have a correct address in memory (eg: 0xdeadbeef becomes "\xef\xbe\xad\de").

A shellcode is a set of assembly instruction you will store in memory, the following string is ready for an input, you don't need to modify it:

"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69"
"\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"

After input you will have a sequence of opcodes in memory like in code segment.
The stack grows down but strings "grow normally" (remember "ABCDEFGH") and eip get incremented after each instruction so it will follow the order of the instructions in the string:

Disassembly:
0:  31 c0                   xor    eax,eax
2:  50                      push   eax

String Literal:
"\x31\xC0\x50"

Don't worry about little endian, it is just the way data are stored, it just matters when you want to craft an address (overwrite of saved eip for example).


How safe are Truecrypt-file containers? I have a question regarding the security of Truecrypt-encrypted-file containers. I know that there are security leaks in the software that allow to access an encrypted drive but can this technique be used to open an encrypted file container? I am using regular (nonhidden) containers because I like how easily they can be transported.
Thank you in advance.

I spent some time seriously digging into the Truecrypt/Veracrypt source code and studying the issued audit, and I would bet one of my testicles that the container format is secure.

A simple TC reimplementation exists at https://github.com/bwalex/tc-play. It uses standard Linux kernel device mapper for mounting the TC volume. It reads the volume header, derives the encryption key from your password/keyfiles and seed stored in the volume header and uses the key and linux dev-mapper to mount the volume container. It uses standard symmetric key encryption implemented in the Linux kernel. It's the pretty same code as is used by LUKS - Linux crypto. So, if LUKS is safe than TrueCrypt is safe as well.

The only difference (as mentioned) is key derivation. However, it uses just standard crypto-primitives.

The only question is, whether the particular True/Vera-crypt implementation is safe. I would bet my second testicle that the tc-play  is safe. It's short, and I was able to read it and understand it completely.

You can find even another reimplementation in linux cryptosetup. Many people have been thinking about TC security which could be nother proof.

However...

If you look at the VeraCrypt sources, you realize it contains thousands of lines of code and 99% of the code is GUI. The possible backdoor could be hidden anywhere, and it would be complicated to find it.

If you compare VeraCrypt code and TrueCrypt code, you realize that VeraCrypt maintainer hasn't added anything interesting. He hasn't even fixed the known bugs discovered by the tc-play developer and noted in README. For instance:

"The keyfile pool is not XOR'ed with the passphrase but modulo-256 summed."

This is a documentation bug, which hasn't beend fixed in the VeraCrypt docs yet.

https://www.veracrypt.fr/en/Keyfiles.html (8.)

To implement new crypto-algoritm (which Vera does) is a simple task. Knowing how, you can put any new algo. within 1 hour of coding.


Key management for builds for embedded systems Our medical device has embedded processors and a USB port used for firmware updates and logfile transfers.  The usual USB viruses are not a concern (no mechanism to load or execute them, wouldn't run in our unique environment).  However a secure upgrade method is required by a regulatory agency, in case of malicious attack by someone with a copy of the source code, build environment and schematics.

In learning about security, our current concept is to use signing and encryption for upgrades and to embed the public key.  Then we have to keep the private key private for the product lifetime, hopefully on the order of twenty years.

Is there a standard way to do that?  Keep it on a secure build server?

The normal approach is to store your private key in a manner in which it can't be compromised by a human being. Meaning, a disgruntled employee can't just steal it and then create malicious updates which have been signed with your key.

You will want to look at Hardware Security Modules which are capable og being fed your update or install image and and outputting the signature. That hardware device is then maintained under strict physical security ("locked in a safe").


Does being multi-lingual (in the 'natural language' sense) ever come in handy at all in information or network security? I'm not professionally involved in security, so hopefully you can pardon me if I misuse any terminology or demonstrate my naivete in some other way. This question came to me as I was reading this paper on the role of language in cyber-crime. Here are some relevant excerpts from the paper:

  Figure 2 reflects the fact that, although English is the most used language, Arabic, Russian, [and] Chinese users have increased  over 1000% in just over ten years. These three language groups are significant in that the vast majority of cyber-crime incidents have originated in Russia and China, whereas Arabic has been more in use for other purposes.

...

  Well-known cyber-crime groups have established mini-communities and societies centered around language...All trusted groups use language cues to establish credibility; this is a well-established socio-linguistic principle which has been documented since the 1950's.

As a disclaimer, I'm a little skeptical of the paper. For instance, when it says that "the vast majority of cyber-crime incidents have originated in Russia and China", it seems that there are a number of factors at play here that constitute "cyber-crime incidents", e.g. rate of local infections, proportion of infected web pages, and distribution of malware, and each of these categories seems to produce different statistics. I'd also assume (without evidence, so please correct me if I'm wrong) that most of what a security practitioner would deal with is domestic rather than international, and even then, I'd assume that much of what someone does online to 'attack' others (e.g. designing malware) is somewhat independent of the 'natural' languages that they speak.

Then again, when it comes to something like cryptography and decryption, perhaps language might come into play? One example that comes to mind is how British and American cryptographers intercepted and decoded Japanese ciphers at Bletchley Park during WWII. It seems this was very high-priority work back then -- enough to incite the Inter-Services Special Intelligence School to start a 6-month crash course in Japanese that lasted until the war ended (where those who completed the course would then work on decoding Japanese naval messages) -- but I'm not sure if automatic translation capabilities and such would have rendered all of this obsolete in the modern age.

I suppose that I'm ultimately interested in whether or not it is ever worthwhile to learn other languages for the purposes of tackling problems that concern information or network security. Or is language learning generally a non-useful way for a practitioner to spend their time?

Code is written in English-based languages, and coders from any country generally know enough English not to need their native language even in comments.

The most accurate way of identifying a writer's country of origin in such a scenario is based on counting the frequency of various types of mistakes they make in English. This calls for scientific knowledge, not basic communication skills. A level of language not passable for native also won't help you much in infiltrating any group.

China and Russia are the go-to scapegoats for wrongdoings both in the cyber world and outside it, so it's likely that some attacks are misattributed to them by intent or by default. Throw a random hanzi or a cyrillic word from a dictionary in a comment and you've created a false lead to nowhere.

All in all, while learning foreign languages is certainly good for many reasons, it's hard to see how it would be more useful in IT security than elsewhere. If anything, this is one of the fields that put the most pressure on non-native speakers to learn English.


Verifying installers downloaded over HTTPS Many developers distribute software over a HTTPS connection and recommend that their users verify the integrity of the executable by comparing a hash or PGP signature. Both the executable and the hash are served over HTTPS from the same domain. What possible benefit could one achieve by verifying the executable? If an attacker has been able to replace the installer, surely they can also replace the hash displayed on the webpage, since both are served from the same domain.

I've seen this with a bunch of installers, but I'll pick Whonix as an example. They go as far as declaring downloads without verification as having "medium" security and downloads with verification as having "high" security. There is a reference link behind the claim, but the link is broken so I don't know what the explanation would have been.

An attacker with a Man-in-the-Middle position, able to silently intercept and modify HTTPS traffic (which is infeasible in practice), would indeed be able to serve one user a modified executable with a modified hash and a compromised GPG key.

But if one were to be truly paranoid, then they would not download the GPG key that created the signature via the same connection that they used to download the executable. Instead, you would download the executable, for example, at home, and then download the GPG key in an internet café.

As you can tell, this is not really done in practice, and ususally there is no need to do so. TLS, if configured correctly, is considered secure in practice by today's standards.

So what to do in practice?

In practice, you have several options:

Option 1: Disregard hashes and GPG signatures and trust that the download will be fine.
Option 2: Verify the attached checksum to make sure the download didn't have any errors. This is what I personally do with OS downloads and the likes.
Option 3: Download the GPG key, do gpg --verify and see if everything is okay.
Option 4: Download the executable on one machine, then move to a different location to download the GPG key. Then physically meet with the maintainer to verify the key fingerprint. Then proceed to verify the download.

As you can see, the examples become ever more complex, in order to mitigate ever more ridiculous risks. In the end, you have to choose your own level of paranoia.


Oauth Consumer Secret? Using OAuth you have a consumer key and consumer secret to identify your application and the user provides an OAuth access token and secret to authenticate your application access to their account, say Twitter. Lets says you are developing a desktop application in Python that has to Twitter functionality that uses OAuth how is possible to keep your consumer key secret? Is it so bad if it's not keep secret? What are the alternatives here beside asking users to registers their own Twitter applications and use their own consumer key and secret.

No matter what programming language that you use, if the consumer secret is somewhere inside the binary,  it can be retrieved.

If it is simply hardcoded in the source, a simple $ strings -a app.exe will give you a list of strings in the binary. The consumer secret will be one of them.

Obfuscation might deter the casual snoop, but given enough time and resources, it can be extracted.

  Is it so bad if it's not keep secret?

Someone in possession of your consumer key/secret pair can pose as your application, abuse whatever restrictions the twitter API has, which might result in your app being unusable for other users and eventually getting blacklisted[1]

  What are the alternatives here beside asking users to registers their own Twitter > applications and use their own consumer key and secret.

Instead of the app itself making calls to the twitter API, you can have a proxy service that you send the oauth token/secret pair to and it makes the necessary API calls, returning data to the user. (As mentioned in the relevant stackoverflow thread)

1. https://dev.twitter.com/docs/rate-limiting/1.1


Remote File Include - commands running on attack box? I think I am losing my marbles. I am doing a practice lab, and the machine has a server hosting a site with a RFI vulnerability.

I host a malicious php file in my /var/www/html and start the apache2 service, and then navigate to:

/index.php?path=/evil.php

I have already set up a listener in metasploit. The payload executes and I get a session, but when I drop into a shell on the session, the IP address given is that of the attack box?

Am I missing something super obvious? It seems the victim server is simply executing the php script on my attack box that is serving it, rather than including it and running it on the victim server?!

I am sorry, I'm fairly new to Web App stuff, and I'm sure I am just not seeing the wood for the trees.

Cheers in advance.

By hosting it as a php file your attacker server will execute the code when apache receives a web request. This is why you get a shell from the wrong IP. Try hosting it as a .txt file instead or remove the .php binding so Apache serves the php source instead of executing it.


Can an antivirus delete files inside an archive? If an Antivirus (ex:ESET) detects a virus inside an archive (ex: .RAR) will it automatically delete the infected file? Or would I need to delete the whole archive? (assuming the archive is not password protected)

Commonly AV detect only malware but not remove it from inside an archive. If this feature would be needed the AV would not only need to implement functionality to look into an archive but also to create a new archive, this way making the code more complex.
But, there are for example firewalls which remove malicious content from the traffic (i.e. drop attachment from mail) or even change the content by stripping macros from an office document before forwarding it.


What should be the ideal course of action for a compromised GPU? What should be the ideal course of action for a GPU that is suspected compromised, for example by a virtual machine using passthrough?

Are there any ways to detect such an infection?

If the computer's OS is reinstalled with the GPU still connected, will it be able to attack the OS?

Is it possible to "clean" the GPU, for example reset the firmware if it is infected?

It depends on how exactly it was compromised.

Unlike your PC, the GPU has no dedicated area to keep the user-uploaded information persistent between reboots (but see below). Thus any possible infection shall not survive the power off, after which your GPU is a clean slate again. It is possible, of course, that the malware on your PC will reinfect the GPU again once it is booted up, but in this case the source of compromise is your OS, and you shall focus on disinfecting your OS.

However some GPUs have firmware which is flashable by user - comparing to, for example, factory-only flashable firmware. Thus it is possible that a malicious actor would patch a firmware for your GPU, and flash it. This would require significant effort, and at this moment you should be only concerned about it if you think of a reason a three-letter agency would be after you. If you're concerned about it, you can reflash your GPU using the original  firmware (although in this case your ability to obtain a copy of clean firmware would also be limited).

It is also possible that the malicious code is injected into GPU on factory, and then shipped to you. In this case you'd have no means to detect this.

Saying so, GPU attack vector has its limitations. While it can read and modify the arbitrary memory data undetected (including ignoring memory protection flags), it has no access to MMU and no way to know which physical memory regions are mapped to virtual regions. Thus making the attack happen (for example granting a certain process admin privileges) would be very difficult to perform. And the lack of internal persistent storage and other means to exfiltrate the data makes it way more difficult than traditional malware.


CGI Generic Injectable Parameter In this security scan, the parameter is found to be at risk of cross-site scripting attacks. Does this mean as below under name="target" attackers can replace the value of 'target' ? What sort of risk would there be ?

Using the GET HTTP method, Nessus found that :
+ The following resources may be vulnerable to injectable parameter :
+ The 'target' parameter of the /phpMyAdmin/index.php CGI :
/phpMyAdmin/index.php?target=%00aqumwy
-------- output --------

    <input type="hidden" name="server" value="1" /></fieldset>
<fieldset class="tblFooters">
<input value="Go" type="submit" id="input_go" /><input type="hidden" nam
e="target" value=".aqumwy" /><input type="hidden" name="lang" value="en"
 /><input type="hidden" name="collation_connection" value="utf8_unicode_
ci" /><input type="hidden" name="token" value="a0bf0035955980a4e6546e545
5aab1f6" /></fieldset>
</form>

------------------------

In short - yes but it does not actually matter.

PHPMyAdmin has the target variable so it can redirect you to a specific page in the console after login.

So for example:
You are a logged in user and you left a tab open at xxx.php and after X amount of time the system logged you out and now when you log back in you want to get to the same page you were on (xxx.php) so the url will look something like index.php?target=xxx.php.

Where are the threats?

XSS - If you are able to escape the value of target in the value="XSS_HERE"
Redirecting a user to a dangerous location/website (export.php, import.php, site_with_virus.com)

How does PHPMyAdmin protect from these this?

XSS - They filter out anything that is not on their white list as well as sanitizing the parameter.
Dangerous redirects - There is a blacklist array as well as a whitelist array with all the locations that can be redirected and all the locations that cannot be redirected.

In Conclusion:

Yes you can inject code into the value but it is useless as it is sanitized and verified on login.

My answer is taken mostly from looking over PHPMyAdmin code on Github.


Disable Office 365 2FA before period of leave without phone? On enablement of 2FA in Office 365 Admin center, the only offered 2FA methods are

Text message
Call
Notification in Authenticator app
Passcode in Authenticator app

Obviously, all of them require me to have my mobile phone with me. But I want to be prepared for period of leave without the phone. Since there is no e-mail 2FA (to another e-mail account) method available, is my only option to temporarily disable the 2FA for my user?

For example for cases where I will get access to a computer to check my e-mails in browser.

You can reset your MFA method, copy your Secret code to a paper in your wallet then use this Secret to generate OTP using browser-based OTP apps (whatever support HMAC OTP).


CVE-2012-4448 pci-scan I'm currently failing a PCI scan due to CVE-2012-4448
The recommended resolution from Security Metrics is to upgrade to a wordpress version higher than 3.4.2, however currently that is the highest version. researching the CVE reveals there is no currently no vendor solution. It seems to me that this means currently a server running Wordpress can not be PCI compliant. Is my understanding of the situation correct?

I'm a developer for an open source project called WPScan, a WordPress vulnerability scanner.

Having spoken to one of the lead WordPress developers a couple of weeks ago regarding this issue, WordPress saw this particular vulnerability as low risk. However, it will be patched in the new release which should be any day now.

I've just implemented a quick 'fix' on my personal blog to prevent the exploitation of this vulnerability.

In wp-admin/includes/dashboard.php comment out lines 1065-1093. This comments out the content of the wp_dashboard_rss_control function which receives the user controllable $_POST['widget-rss'][$number] variable which is needed to exploit this vulnerability.

This did prevent the exploitation of the vulnerability. I did not notice any other adverse affects in doing this on my blog, however, doing so may affect some other parts of the system, but I did not see this.

The above is an option if you can't wait a few days to a week for WordPress to release the patched version.

If you want a more secure blog as well as passing PCI, check out WPScan.


Beside GIFAR are there any other known polyglot files? A GIFAR file is a polyglot file with a fancy name.  It can be "opened" both as a valid GIF file and a valid JAR file thus leading to security issues under certain circumstances.

Definition of a GIFAR file :

  Graphics Interchange Format Java Archives (GIFAR) is malware that
  allows an attacker to piggyback off the victim’s HTTP cookies. A GIFAR
  is a photo that can "borrow" a victim's online credentials, possibly
  taking over the web user's session.

  GIFAR is a Graphics Interchange Format (GIF) image file combined with
  a JAR file. Altered GIF files can be uploaded to Web sites that allow
  image hosting, and run code that works inside that site.

Beside "GIFAR" are there any other known polyglot files?

I did try to answer myself and I couldn't find anything else.  So I guess the answer might be no.

There are lots of examples for such polyglots, i.e. documents which are several file formats at the same time.

Some examples apart from GIFAR are combining GIF and Javascript or Flash and JavaScript but there are lots and even more variants.
A very good source for such stuff is Corcami and also the PoC||GTFO documents are known to be multiple kinds of documents at the same time, i.e. ZIP, PDF etc.


What are the pros and cons of outsourcing an organization's PKI? I am looking for the pros and cons of outsourcing an organization's Public Key Infrastructure (PKI). I understand that the answer to whether or not to actually outsource is going to depend on the environment and the organization. What are the risks associated outsourcing PKI and are there any technical gotcha's with regard to outsourced PKI?

One of the key risks I have come up against when working with banks outsourcing their PKI is the protection of the root certificate. If you are relying on your PKI to protect something which is business critical you really want your PKI provider to assure you of the security around the root certificate.

There are a few providers who really work hard at this, using many mechanisms to help persuade clients to use them. From experience, I include in this pressure plates, retina scanners, dual synchronised keys, man traps, video coverage of root access, partial access granted to the provider, and part to you - pretty much everything you'd expect from an evil genius in a James Bond film.

Another issue is around connectivity - if you use the PKI for real time services, loss of connectivity to the provider will cause a Denial of Service. Make sure they have resilient links to you, and to your customers or other users.


Can cookies carry viruses? I was wondering whether a cookie can carry a virus (or any security-threatening code). In some sense it is similar to a download.
So by simply visiting a site, could I get harmed?

You can put any text strings into a cookie, so in theory you could put some kind of code there. But for code to do any harm something needs to run it. The web browser does not interpret the content of cookies as code and does not try to run it, so cookies should not be dangerous. (If you have heard cookies being referenced in security related discussions, it is probably in relation to privacy and not viruses.)

In theory there could be a bug in the browser that makes it possible to craft a special cookie that somehow fools the browser to run it, e.g. by causing a buffer overflow. Such a bug is quite unlikely in a major browser, and if you could find one it would be considered a big deal.

So I would not worry about cookies infecting me with a virus. However it is possible to be infected by malware from just visiting a website. This is called "drive by downloads" and is nowadays a common method to spread viruses. The vector that is exploited for this is generally not cookies though, but plugins like Java or Flash.


Can an Intrusion Prevention System (e.g. Snort) prevent CSRF and XSS attacks? I am currently learning about IPS and was wondering about a query that applies to how IPS works. I have knowledge of CSRF and XSS attacks, however I am unsure if Intrusion Prevention Systems can prevent these attacks as it aims to block intrusions and is performed in-line/in-band. If someone could provide me further clarification that would be great, thanks

Intrusion Prevention System is a broad term. It basically says only that it is a system to prevent intrusions and does not imply a specific technical implementations. Therefore a variety of systems which somehow had the goal to prevent intrusion, were marketed as IPS when the term was hot. Therefore a generic statement about the capabilities of IPS to solve a specific problem cannot be made.
As for systems like Snort or Suricata: These basically try to match pattern in the network traffic using predefined fixed signatures. They are capable of parsing HTTP traffic and do basic analysis on it. These capabilities can be used to create custom pattern to detect specific and pre-known CSRF and XSS attacks. These are not enough for a more generic approach - simply because such attacks cannot be generically detected with simple string matches and regular expressions in the first place.
Additionally Suricata and Snort are not capable to analyse HTTPS traffic by their own. This means they must be strategically placed in the network so that they get the unencrypted traffic for analysis.


Firefox bug permits stealing encrypted passwords: How is this possible? It's my understanding that passwords I save in Firefox's Password Manager are encrypted and that setting a Master Password encrypts the encryption key used in this process. The Google hit for "Does firefox encrypt saved passwords?" returns this Mozilla Support forum article in which the chosen answer (posted by a moderator) states:

The passwords stored in logins.json are encrypted, but the encryption key is stored in key4.db (previously in key3.db) and without a master password you merely need to place the two files is Firefox profile folder to see the passwords in the Password Manager.

(Note that logins.json is where FF stores passwords.)
This Information Security question posted by a high rep user assumes the encryption of the passwords, even before a user has set a Master Password, as does this well-received question.
But according to the Sophos Naked Security article, Firefox fixes “master password” security bypass bug, Mozilla released a security fix to resolve an issue where an attacker can copy saved passwords to the clipboard without entering the Master Password:

It was found that locally stored passwords can be copied to the clipboard thorough the ‘copy password’ context menu item without first entering the master password, allowing for potential theft of stored passwords.

How is this possible if the passwords are encrypted?
Isn't the Master Password, needed to decrypt them before access? I'm very worried now that an attacker that gains access to my logins.json and key4.db files would have all my saved passwords!

If you have no master password set, then the login passwords are always available. If you do have a master password set, then opening the Saved Logins dialog will prompt you for the master password. Without the correct master password, the list of logins will be empty and thus there is no password to copy.

The bug only occurs in this specific condition:

A master password is set.
You have unlocked your logins by entering the master password once this browsing session.

To be clear: if you have a master password set, and have not unlocked your logins this session, your passwords will still be protected and not be available through this bug.

Passwords are stored encrypted on disk, protected by a key derived from the master password. If you start Firefox for the first time, it will usually prompt you only once for your master password when it encounters a login form, or when you open the Saved Logins section. If you dismiss this request, the logins will not be available. If you however enter the password, the decrypted passwords will be available until you quit Firefox.

Normally, when you use the Show Passwords button, or if you right-click a login and chose Copy Password, it will prompt you for the password once again. Due to the bug, the password confirmation prompt was displayed, but the password was already being copied in the background.

The impact is very low in my opinion. Someone with physical access to your unlocked session can already obtain the password in other ways:

Visit the website, for example, https://stackoverflow.com/users/login
Observe that the login is filled in.
Open Developer Tools (F12), go to Console.
Execute: document.querySelector("input[type=password]").value
Observe the password.

Alternatively, you could go to the Network tab in Developer Tools. Press Login and observe the password being recorded. There are plenty of methods to obtain the logins if it is already filled in.

As for the commit that references the bug, the code defect was that an asynchronous call (masterPasswordLogin()) was not waited for. That is why the code to copy the password is already executed before the login prompt was confirmed. The fix is to wait for the prompt to be completed.

The original security advisory from Mozilla only stated that passwords can be copied without entry of the master password. Since then, this security advisory has been updated with the above clarification, and now reads:

  When a master password is set, it is required to be entered again
  before stored passwords can be accessed in the 'Saved Logins' dialog.
  It was found that locally stored passwords can be copied to the
  clipboard thorough the 'copy password' context menu item without
  re-entering the master password if the master password had been
  previously entered in the same session, allowing for potential theft
  of stored passwords.


How strong is a simple XOR encryption with random IV? I'd like to implement some kind of simple (yet as strong as possible) encryption for my client-server application network traffic. Data to be encrypted can be both textual, and binary.

Now I'm thinking about using just a trivial XOR encryption, but with following features:

Key will be random (i.e. uniformly distributed random sequence of bytes) for each session.
CBC mode with random IV will be used for each session. That is, plaintext will be XORed with previous ciphertext (or in case of first "block" - the IV), and the result will then be XORed with (repeating sequences of) encryption key. That way the attacks mentioned in What's wrong with XOR encryption will not be possible, right?

So my question is: how strong is such encryption? Many points mentioned in the What's wrong with XOR encryption question's answers will not be valid I think, as the random IV will ensure that the plaintext patterns (e.g. spaces, NULL bytes, etc.) will not be observable, and the ciphertext will "look more random".

What are the weaknesses of such encryption? Thanks!

P.S.: I know that for ultimate security, implementing TLS with e.g. OpenSSL would be the way to go, but I don't actually need that level of "theoretically unbreakable" security, using certificates and big libs like OpenSSL is just overkill for my project. I just need simplest possible defense against somebody wiresharking my traffic.

I'd like to implement some kind of simple (yet as strong as possible) encryption > for my client-server application network traffic. Data to be encrypted can be both textual, and binary.

You're implementing a modified Vigenère cipher. That might be a problem in that any sufficiently large sequence of repetitive data (with binary zeroes being the most evident), or structured data (e.g. JSON) as pointed out by Polynomial, will reveal the key length and the algorithm that you're using, and trivially allow a decryption of a couple keylengths' worth of information.

Several cryptanalytic approach exist that can be adapted to your case. A simple distribution test will reveal that it's worthwhile to run an attack.

Apart from that, you have a standing vulnerability in the key distribution: either you have a key (or a finite set of keys) hardwired in both client and server, or you need to provide for secure key exchange.

  using certificates and big libs like OpenSSL is just overkill for my project.

Please do not take this wrong, but you're approaching this the wrong way. I agree that implementing OpenSSL would be orders of magnitude harder than going Vigenère (or Vernam/OTP which is the next logical step). But you needn't do that - you only need to use an existing library. After that you'll be safe and sound and will actually enjoy not simply more security, which may be superfluous to you, but greater simplicity of code and greater maintainability.

Depending on the setup, you could perhaps do this by simply dropping a SSL proxy such as Stunnel in front of your plain HTTP service:

                       |
HTTP service --- PROXY | === SSL channel === SSL client (browser)
                       |

and be able to both test your system in HTTP and supply your clients securely in HTTPS.

Other Web servers (both Apache and Nginx) as well as load balancers allow for SSLifying server-side services.


Can I determine which algorithm was used if I know the matching hash of a given input? If I know original text "12345" which encodes to "Tut0nlFFZ9sLVhPE5x81lQ==", how I can identify hashing algorithm?

On observation this looks like base64 encoding (note this isn't a hash, it's an encoded string). I can tell this as I know that in base64, one pads the end of the string with = as necessary to give the base64 string a predictable length. Other tell-tale signs can be from the usage of certain characters in the string. These you will learn by simply exposing yourself to existing examples and reading about the various encoding algorithms out there.

The base64 encoded string of 12345 is actually MTIzNDU=, not what you provided. Decoding your supplied string yields: NëtžQEgÛVÄç5•. The high entropy here indicates this is probably the result of some encryption algorithm. Since the point of a good encryption algorithm is the inability to determine it from random data, it is not often simple to discover which algorithm was used and you would normally have to resort to brute-force efforts.

Assuming this is some kind of exercise where you are certain your input resolves to this and you've been asked to determine the password used to encrypt it, you can brute-force using a method which after trying a password checks to see if the output is indeed 12345. This way you can actually verify you have guessed the right password. Good luck!


Is it possible to restrict portions of a web site to only allow access based on geographical region using the IP address? Disclaimer - I am not a security expert, so this may just be a dumb question.  My security knowledge is focused strictly on development.  When it comes to configuration and networking, I know only enough to get me by.  I'm trying to change that.

First, I'm not even sure if this is a good idea or even something worth giving a lot of consideration to.  If it's a bad idea, please say so in the answer (or a comment), and give an explanation of why.

We've got a publicly accessible website, and portions of it allow customers to access some sensitive data.  We've already followed all of the OWASP guidelines in our applications, we have a Web Application Firewall, and we're already taking every precaution we can think of to lock it down.  However, our site is constantly being scanned from sites overseas.  China, Germany, North Korea, you name it.

Our business is restricted to a very small geographical area.  We operate in three states in the United States.  In our shopping cart, we sell items that can only be used at our stores - gift cards, for example.  With very few exceptions there is absolutely no reason that anyone in another country would need to have access to this portion of our site.  (I can see a soldier wanting to buy gift cards for their families back home, but not much else.)

I'm just curious about whether it would be possible to lock down the portion of the website by restricting IP addresses to IP addresses that come from the United States.  To clarify, I know how to set IP restrictions in IIS, but I don't know if there are known ranges that are verifiably from the United States.

I do know about IP spoofing, and anonymizers, and I realize that we may lock out people using such tools, and that it's going to be possible for those outside the US to use such tools to bypass even this.  I haven't thought through what that would do to the feasibility.

IF you can map an incoming IP address into a geographical location, then yes you can filter out clients based on their presumed current country. However, this relies on geolocation and its associated databases, which are not necessarily very reliable. Also, whenever someone uses a proxy or VPN or IPv6-to-v4 tunnel, then the IP you see on the server is the IP of the proxy/tunnel exit point, not that of the originating computer.

Conversely, if you restrict access to only US-based IP, then it would suffice to rent a server from a US-based provider, and use that server as proxy, to connect to your server with a "US-based IP" (setting up such a proxy is a matter of a one-line command with any Linux system: ssh -D 5000 theproxyserver). Half-serious attackers will thus not be much deterred by the filter you suggest. This location-based filter will mostly block the non-intelligent automatic attempts from botnets (which try to propagate), and these are the least dangerous of the lot.

Restricting the number of potential customers who can see your Web site does not seem to be, in my opinion, a commercially optimal move. Usually, you do not want to chase customers away.


Is this "secure email" mechanism my bank wants me to use best practice? So, yesterday I needed to sign & scan some forms for my bank, a credit union.  Nothing hugely confidential, except it has some account numbers on it.  But still, I was a bit concerned, so the exchange, with my fairly senior advisor, whom I would not suspect to be IT savvy besides showing Powerpoints, went like this:

will this be secure, via email?

bank:  yes, we use secure email, as per our IT department.  My assistant will be sending you a link to a login page where you can enter your credentials.

a link?  you realize that this is precisely how phishing works?  a login URL.  No one advocates this in the IT security field.  I know I'm getting this now, so I know this one is safe, but what about next week?

bank:  (some variation of our IT dept says and what the heck do you know?, politely phrased)

OK, so I get the email, enter a password on their site and save the url so that at least I don't need to get it off the email the next time:
https://securemail.xxxyyyzzz.com/securereader/inbox.jsf
The web mail client is crappy so even though I replied with the forms, it shows nothing in the outbox.  So, replying to the original, non-secure email, I asked if they received the secure reply, as it didn't show.
The answer?  via secure email + url link, of course.
Errr, no great need to reply securely about this, but OK, I can test my login from my password manager.
As I write this, it seems to work now, but the first time it said something about an expired session, so I had to go back and actually use their second email's link:
Their plain email notifications say something like:
This is a secure message.
Click <some url here> by 2020-09-25 08:05 PDT to read your message.
After that, open the attachment.

the actual URL is something like https://securemail.xxxyyy.com/formpostdir/securereader?id=6pBzH9H9DbMMP2ALTFKr9DOXN7pcxxxx&brand=1c64710yyyy
So my question is:  are these shenanigans, and especially the apparent insistence of me using login URLs from emails, in any way best practices?  Seems to me, it would be much more secure if they made the email link accessible, still with an extra password, on their actual online banking site.  Then they could say, not email, when you login, pick the Your account/Secure email item on the top right.  Or something to that effect.
And the session expiry mechanisms, if they exist should not interfere with storing the secure URL in a password manager, as opposed to needing to pick it up from incoming emails.  I assume it's cookie-based as, even after shutting down my browser, I was able to login from my password manager after following the 2nd login URL.
I totally understand there is no risk at this point in time.  We are in an ongoing set of transactions that have a phone component and those emails are not unexpected.  I know my advisor's voice and she knows mine.
My concern is that this is training their average users to follow URL links in emails, leading to login pages for their banking with this institution.
Am I correct in finding this is not exactly best practices?

You ask about best practice.
Best practice would be to have you use your normal account login on the normal website and select a "submit forms" option from there which takes you to an upload page for submitting your scans.
For your experience
The pre-arranged link via email method is slightly less secure, but the exploit window is narrow.
Assuming your bank's domain name is represented by xxxyyy.com using the domain name securemail.xxxyyy.com submission is good form.
the poor user experience on that domain is just poor UX, not inherently insecure.
But yeah. the over-all user experience (starting with the phone conversation) trains users to trust links in emails.  and this seems to have the potential to harm the bank, and its customers.


Why is writing zeros (or random data) over a hard drive used when writing all ones is more beneficial? As far as I know, in order to securely delete the hard drive's contents, one should fill it with zeroes or, for added security and harder recoverability, random data first and then all zeroes.

In order to get rid of all the data wouldn't be simpler to fill it with all ones, thus minimizing the wear of repeated writes and being sure that all bits on the drive are now uniform and old data couldn't possibly be recovered in this state?

The reason you write '0' instead of '1' has to do with the way magnetic storage encodes the 0 and the 1. a long explanation of it can be found on Wikipedia under Run-length_limited. In short RLL is the methodology used to store the '1' and '0' and it is more complex than just to store the bit values themselves.

On a side note to make the drive more like it was when it came out of the factory we need to have it store only 0's. (factory default state)

So to securely erase anything on a magnetic storage device you first need to change the magnetic encoded values to a 'stable' state, (that means as many '0' as possible). This makes it harder for anyone to retrieve what was there, and almost impossible for the build-in magnetic Reading head. (only specialist equipment can still reliably retrieve it)
To combat 'magnetic memory' you can than write a random pattern to the same location, followed by a zeroing pass, this makes it nigh impossible for software to retrieve the values that were there.

Finally you leave the disc in a state that closely resembles the factory state.

Most of this does not apply to CMOS or SSD technology as long as they do not use magnetism to store the values.  There are other techniques to securely erase a CMOS / SSD but that involves overpowering the 'memory' cell to erase all values inside it. (also known as a reset).

Most of the time you do not care about the wear and tear when 'securely' erasing the disk because you simply do not do it that often. and the benefits of the erase outweigh the cost of having to replace your drive a little sooner.


How does Tor protect against MITM attacks between the client and relay nodes? According to robertheaton.com:

  When a Tor client constructs a circuit, it negotiates TLS sessions with each of the nodes it has chosen for its circuit using the nodes’ TLS certificates and public keys. The outcome of each TLS session negotiation is a symmetric encryption key, known only to the client and the node.

SSL/TLS alone (without a PKI) cannot protect against active MITM attacks, and thus (it seems like) someone able to intercept the client's outgoing traffic could gain the symmetric key for each Tor relay node.

How does Tor prevent this from happening? Is there some certificate authority in charge of verifying and signing relay nodes' certificates?

The Tor Project hosts some bootstrapping servers called directory servers. They contain a list (a directory) with information about all Tor relays currently online. This info about each relay includes the public key. The directory is signed with one of the directory keys[1]. Those keys are distributed along with your copy of the Tor client[2].

Therefore, the answer to your question is: by having a trusted third party (similar to a certificate authority). Tor relays (called onion routers in the paper) upload their info to the directory periodically[3]. When a client connects to their guard node, they check that the connection is encrypted with the right key, as listed in the directory. Then, when proxying traffic to the middle node (between the guard and exit node), they setup an encrypted connection to that node, proxying through the guard, and checking again that the right key is used (instead of a MITM key) using the directory. Same goes for the final (exit) node.

Source: https://www.onion-router.net/Publications/tor-design.pdf

[1] "Each onion router maintains a long-term identity key and a short-term onion key.  The identity key is used to sign TLS certificates, to sign the OR’s router descriptor (a summary of its keys, address, bandwidth, exit policy, and so on), and (by directory servers) to sign directories."

[2] "Client software is pre-loaded with a list of the directory servers and their keys, to bootstrap each client’s view of the network."

[3] "Tor uses a small group of redundant, well-known onion routers to track changes in network topology and node state,including keys and exit policies. Each such directory server acts as an HTTP server, so clients can fetch current network state and router lists, and so other ORs can upload state information."


“Keyset does not exist” when using SignData function with RSA "Keyset does not exist". I know that there are tons of question about this error, but mine is totally different.

I'm not gona use the key from windows certificate store, but load the public key & private key from 2 bare strings, using method "fromXMLString".

rsa.fromXMLString "<RSAKeyValue><Modulus>......"

then

rsa.SignData buffer, algSHA1

and Booom! : "Keyset does not exist"

Can someone please tell me that using the rsa key pair from 2 xmlStrings is innocent and it entirely does not relate to windows certificate store? I have my own approach of storing & loading certificate/keys.

PS: The other answers for questions on this error told questioner to set correct permission for private key in cert-store. But in my case, I used no private key file in that store, right ?

I met the same problem, and I find solution now.
You need use the same rsa that you used to generate the signature to generate a public key and provite key for all to use, then use this public Key & private key  for all other action: encrypt,decrypt,verify, you will not see this error.


Should Framebusting be used (not used) on an IdP login page? I'm trying to understand when Framebusting should and shouldn't be used.  At first brush I'd want to apply that to all pages in my site and generating exceptions as necessary.

On the other hand, if I were to take a minimalist approach, I would think I would want to apply this security to my login page.

Is there any reason why I shouldn't apply framebusting to a login page?
Are there any other related best practices?

From what I've seen Framebusting as a technique is becoming somewhat deprecated as a defence against click-jacking style attacks in favour of setting the X-Frame-Options header (e.g. the OWASP page here and here).  Browser support for the X-Frame-Options headers seems to go back to IE8 so unless you have a really old set of browsers to support it should work ok.

So the short answer is that I'd recommend going down that line rather than using Framebusting Javascript.


Why would you do a password audit I was thinking last night after reading an article about pen testing and security audits, why would you get a list of all the passwords for the company you are auditing and put them through a piece of software to analyse ?

You wouldn't get a list of all the passwords.  Any company that could or would produce such a thing would fail any reasonable security audit.

You might get a list of all the password hashes which could then be run through a tool that attempts to determine what the password is.  The ease with which the password hashes can be broken and the types of passwords that are broken will be a good guide to figuring out what password complexity policies need to be addressed.  If, for example, you're able to crack half of the password hashes because users are entering 6 character passwords that use all lower case letters, then you'd probably recommend increasing the minimum length and imposing some requirements about the use of uppercase letters, numbers, punctuation and other characters.


Can CA issue a certificate without CSR? My question is if the CA can generate a private/public keypair on behalf of the requestor and sign it with its own private key?

Is there any standard way or protocol to distribute such a certificate?

I know that the p12 format is used to store private key as well as the public certificate and this file is password protected. Is this a common practice of a CA to offer this service?

A server can use a self-signed certificate to identify itself.  Clients then have to trust this certificate when they connect or use the server's service.

In PKI infrastructure you normally don't have the CA generate the key-pair unless its the root certificate.  Clients and intermediate CAs will generate their own key-pair and use the CSR to have the root certificate sign it.  A CA doesn't generate certificates itself because then how can you trust that the CA hasn't kept the private key for itself.  This breaks down the PKI infrastructure.

CAs like Symantec/Verisign or GoDaddy generally don't offer services to generate the key-pair for you.  Due to reasons in the previous paragraph.  You send them a CSR with the information for your certificate to be signed.

See my answer here for more details.


Is it reasonable to use KeePassXC with YubiKey? At the moment, I am using KeePassXC with a relatively strong master password. To further improve security, I thought about buying a YubiKey to have 2-Factor-Authentication.

KeePassXC supports the so called "HMAC-SHA1 Challenge Response mode".

In the KeePassXC FAQ they say:

  Does KeePassXC support two-factor authentication (2FA) with YubiKeys?

  Yes and no. KeePassXC supports YubiKeys for securing a database, but
  strictly speaking, it's not two-factor authentication. KeePassXC
  generates a challenge and uses the YubiKey's response to this
  challenge to enhance the encryption key of your database. So in a
  sense, it makes your password stronger, but technically it doesn't
  qualify as a separate second factor, since the expected response
  doesn't change every time you try to decrypt your database. It does,
  however, change every time you save your database.

Assuming an attacker has access to my KeePassXC database and perhaps even installed a keylogger on my system, the additional YubiKey is useless in this case, am I right here?

So, is it reasonable to use a hardware security key for KeePassXC if you already use a strong master password?

Well designed password managers do not rely on authentication for their security; instead they rely on encryption. So unlocking a password manager data base doesn't even involve single factor authentication, much less multi-factor authentication.

How a password manager can use a Yubikey

What this means is that the kind of thing that is normally used to strengthen an authentication process (and YubiKeys are very good at that) play an inherently different role when it comes to something that's security is largely based on local or end-to-end encryption. There are roughly three approaches, but the details of each matter.

1. Security theater

In some cases, the apparent second factor is pure security theater. It is possible to do something that looks like 2FA to the user but is trivially evadable by any attacker worth worrying about. We (at 1Password, where I work) have resisted intense customer pressure for that over years.

Let's just ignore this option. It does nobody any good and it has a substantial harm potential if users end up using weaker master passwords or not protecting their master password as well as they otherwise might. That is, if people weaken what is already the weak point in their password manager security, because they feel protected by theatrical 2FA, they very much weaken their effective security.

2. On some authentication component

Although many password managers can be used off-line, without requiring authentication to some remote service, there is typically a required authentication component when setting up a new device to get (at least) data synchronization to work. 2FA can be added to that authentication component, even though it is a minor part of the user's security.

This, by the way, is what we do with 1Password. If you enable 2FA, then it is required when setting up a new device. The hope is that by limiting it to this, we are not leading users to believe that they can get away with weaker master passwords or that the 2FA magically protects them from an attacker who gets at their locally encrypted data.

3. As a supplier of a static key

Decrypting data requires a key, and deriving that key requires user held secrets (typically their master password and perhaps other things). The difficulty here is the the key derivation function (KDF) must be deterministic (as it must derive the same key each time).

But the beauty of something like a Yubikey is that it can prove knowledge of a secret without revealing it. They are designed to work in a challenge-response manner, where each challenge is randomized, making the responses unique each time; yet each correct response proves knowledge of a secret. This is what makes these things really good in authentication contexts. But this is useless during key derivation.

So having the Yubikey spit out a static secret is operating the device in a mode that gives up on its most important security features. It's doable (as Keepass is apparently using it and some of our users have jerry rigged something similar), but it really isn't offering the security guarantees that a Yubikey normally does.

Although this isn't purely security theater (there is some real gain), there is still distinct possibility that users will over value the security gain and thus weaken the parts of their security (master password) that should be stronger.

Is it reasonable?

So back to the original question. It is reasonable to use a Yubikey as described in (3)? Using it is not unreasonable as long as you understand what it does and doesn't protect you against (and that these are distinct from what a Yubikey typically protects you against.)

We, at 1Password, however, believe that it is unwise for a password manager to encourage (3), as the security benefits don't seem to be worth the security threats that arise from people's misunderstanding of the security properties. However, I very much understand the customer pressure for this kind of thing. I also understand that reasonable people may come to different conclusions.


UEFI and security implications for encryption After my old PC kicked the bucket I now own my first UEFI board and I am already having trust issues. I utilized Truecrypt's system encryption for years now and really got used to it. My new board has no legacy boot option but supports legacy devices so I was able to install Windows 7 into a MBR partition and encrypt it with Truecrypt.

But the UEFI seems really sophisticated and from what I hear it has a lot of memory available so I would like to know if it potentially compromises encryption used on this computer. I am aware of potential UEFI-malware and that is not what I want to know about.

What I'd like to know is wether UEFI does ANYTHING that would allow a potential attacker with physical access to this PC to decrypt the system or encrypted volumes used with it. Does it create any kind of potentially dangerous logs, does it create memory dumps, store keys created by the AES-NI extension of the CPU?

I would appreciate any kind of advice here!

If you're asking if UEFI add additional attack vectors against TrueCrypt vs. a non-UEFI BIOS, the answer is probably no. Running TrueCrypt on a UEFI-enabled computer with the UEFI code signing turned off is no less secure that a computer without UEFI.


Intercept HTTP Traffic of an android app? I was trying to test and intercept traffic from an app developed on Rhodes open source framework, I setup a proxy with burp, and of course I have installed burp certificate on my device hence I can intercept other apps on my device but I am unable to see the traffic of the app in question - its link on burp suite instead the app works fine and connects to the remote server without even appearing any error related to certificate error on the event Log of the burp suite just as like an app using certificate Pinning would complain. in reversing the app I concluded that it is using https protocol to connect to the server. additionally, I have installed the app in Genymotion emulator and the app behaves differently. when I installed the certificate in the emulator and set up burp proxy, all the traffic from other apps appears normally in the proxy except this app. all the app traffic follows to the address 127.0.0.1 which is strange to me. forexample I take an intercepted one below:
http://127.0.0.1:44895

POST /app/Settings/do_pathlogin HTTP/1.1
Host: 127.0.0.1:44895
Content-Length: 65
Accept: */*
Origin: http://127.0.0.1:44895
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Linux; Android 8.0.0; Samsung Galaxy S6 Build/OPR6.170623.017; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/58.0.3029.125 Mobile Safari/537.36
Transition-Enabled: true
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://127.0.0.1:44895/app/Settings/index_callback
Accept-Encoding: gzip, deflate
Accept-Language: en-US
Connection: close

fromPage=login&operation_key=HOME_REP&username=user&password=pass

I don't have any idea why this behaviour the app is showing, in the real device this won't show up, i.e, traffic to the address 127.0.0.1.
As other researchers would recommend, tried to sniff network traffic of the app with wireshark  and activated the capture traffic of the wireshark, I was expecting to sniff or even decide whether app is using UDP protocols, but did not appear any traffic from the app!.
I wanted some help how can I capture the traffic of this app?
what am I missing?
what other steps do I need?
I would really appreciate any help about this.
note: I don't have any bad intentions about the app.

I am sorry but I am having a hard time understanding the question fully. I will try to give some advice for further investigation.
It is my understanding that you are experimenting with a banking application, and that you found that

I have installed the app in Genymotion emulator and the app behaves differently

That's reasonable for a banking application. They often actively detect the emulator. Most banking apps will grind to halt when they detect 1) emulator, 2) su executable 3) debug mode ON

I can intercept other apps on my device but I am unable to see the traffic of the app

Unfortunately I don't know how the burp suite works (and that is bad in the first place!!), but you need to make sure that the intercepting suite acts as a transparent https proxy, as the app may try their best to bypass any system proxy setting.
From what I know in my SW engineering experience, a proxy is set in Java by setting system properties. The app may be trying to temporarily hijack the proxy properties, which is allowed within their ClassLoader, in order to bypass proxy.
Ideally, the testing should be done after removing phone's SIM card (or disabling mobile data) and connecting to a specially crafted wifi hosted by the testing suite. If burp allows that, then the app is a real challenge.


Can you identify whether a string is a RSA public key? I am generating RSA keys with the openssl library. I have heard that it is possible to recognise the method used to encrypt a string with AES or DES but is it possible to identify whether a string is a RSA public key?

Yes. RSA public keys are typically generated as ASN.1 structures as per the definition in RFC3447, encoded in DER format.

The format can be validated as correct DER / ASN.1, and then decoded to validate that the structure and contained values match what is expected from an RSA public key. The values within the structure are simply the public semiprime (n) and the exponent (e).

By validating that the value of e is prime, and that the size of n matches an expected RSA key size (e.g. 1024 bits) then you can assume that the provided data was in fact an RSA public key.

For the case of OpenSSH, public keys start with a string identifier (e.g. "ssh-rsa") which makes detection easy. You can also extract and validate the n and e values in the same way as above, albeit using the OpenSSH key format specified in RFC4253 instead of the DER / ASN.1 format.


Secure Encrypted Chat Protocol Possible Duplicate:
  Is there a way to negotiate a secret between 2 parties with no prior knowledge?

Imagine two clients who want to establish a secure connection over a server. Both clients have a trustworthy public key from the server, so they can establish a secure connection to the server. If the clients would now exchange public keys, the server could obviously do a man-in-the-middle-attack. Is there any way to prevent this? (So that, if the establishment of the connection succeeds, the clients are guaranteed to have a secure channel and the server cannot eavesdrop.)

Sounds like you could probably do a Diffie Hellman to create a temporary session key and use that to symmetrically-encrypt the communications.


Reassemble sniffed packets I am attempting to analyse my WiFi network with on Mac OS X, is there a tool to reassemble TCP stream from Wireshark capture. I would like to see the entire HTML pages that are passing through the WiFi

You should be able to just right click on any HTTP packet and select "Follow TCP Stream" which will rebuild the page. You could select the "Save As" and save it somewhere, e.g.: "captured-page.html"

Edited to add more:

Here is the walk through on Wireshark: http://www.wireshark.org/docs/wsug_html_chunked/ChAdvFollowTCPSection.html Your other option is to use tcpflow: tcpflow -r http.cap


How web services collect machine identifiers to track visitors? Many web services such as ie: google collect machine (hardware) identifiers, and they of course state this in their privacy policy.

Usually to hide/change our online identity we could clean reinstall OS, and set up new online accounts in order to completely hide our previous browsing details.

But if hardware ID's are exposed then this doesn't make much sense unless we start using new hardware (ie: buy new computer/router)

Question is:

1) what techniques do they use to collect machine ID's

2) what can we do to prevent sending machine ID's to web sites

I will disagree with John Wu.  There is a lot of information that a website you connect to can gather about your computer from the simple TCP connection performed.

p0f - the first (and still active) passive fingerprinter, analyses details of your connection including:

Order of TCP options (gives away the OS, often the version of the OS)
MTU (gives away the type of connection used: ADSL, PPoP)
TTL (gives away the OS to some extent, and can map your NAT if combined with timestamping, see below).

The README for p0f cites almost a hundred little information disclosure vectors.  But the most important one is TCP timestamping, by which a website you connect to can determine the uptime of the system.

You may think that knowing the uptime of your system is no big deal, but by the contrary.  Several OSes send the TCP timestamp based on their uptime and to the granularity of miliseconds, and, therefore, the timestamp identifies your system very well.  There are not many computers that were booted exactly on the 22nd of October, 2016 at 5PM, 32 minutes and 4.589 seconds.

Of course, the ability to track your machine through passive fingerprinting decreases significantly once you reboot it.  But companies like google are more interested about a browsing session performed, not necessarily your repeating habits day by day.

Extra references

Client Identification Mechanisms - A Janc, M Zalewski


How to extract the password hash from a password-protected container? How can you extract the hash of the password from an encrypted container, such as a KeePass file, or a LUKS, TrueCrypt or Veracrypt volume?

I tried to use keepass2john from John the Ripper, but it did not work with a KDBX file from KeePass (error message: "file version not supported") .

During my research I found some people saying that you cannot extract the hash. If so, then what are scripts like keepass2john for? Also, if you cannot extract the hash, how does the encryption software validate the key?

How can you extract the hash of the password from an encrypted
  container, such as a KeePass file, or a LUKS, TrueCrypt or Veracrypt
  volume?

It depends :-). You will need a program that can read the respective file format, and extract information about the password.

Also note that a file/container protected by a password does not usually contain a hash of the password (like for example a UNIX Shadow file would). Instead it contains data protected by an encryption key (which is computed from the password), and possibly information about how the encryption key was computed. Typically some special algorithm (a key derivation function) is used to calculate the key.

This data can be attacked in a similar fashion to brute-forcing a password hash: You can try different passwords, run them through the right key derivation function, and check whether they match the encrypted data.

Then you will need a program that performs this brute-forcing. Hashcat is one popular choice (and Hashcat happens to support the data format used by KeePass - see PR 282 on GitHub).

  I tried to use keepass2john from John the Ripper, but it did not work
  with a KDBX file from KeePass (error message: "file version not
  supported") .

That could be any number of problems, and is probably out of scope here. Try asking a more specific question on http://superuser.com .

  During my research I found some people saying that you cannot extract
  the hash. If so, then what are scripts like keepass2john for?

Well, sometimes some people are wrong :-). keepass2john is indeed for extracting information from a KeePass database that allows you to crack the password with John The Ripper.

  Also, if you cannot extract the hash, how does the encryption software
  validate the key?

They do it like the cracking programs: They try the password, and complain if it does not work.


Secure copy-paste from phone to computer Some computers on my university block the keepass application which I use as a password manager. I'm thinking of building a small web application + Android app which lets me securely copy a string from my phone to my computer. Since more people will have this problem, I'd like both the web application as the app to be available to everyone. That's why I will need to establish some kind of link between a session on the web application and an instance of the Android app. I thought of the following, inspired by Firefox Sync's system:

User goes to the web app and gets a unique pin code NA which is linked to his session id
User enters NA in the app and gets a new random pin code NB (the app sends NA to the server and receives NB)
User enters NB in the web application
The server verifies that the NB inputted in the web application is the nonce that was sent to the app that sent NA. I'm also thinking about checking that the web app and the app are using the same IP address, although this may give issues with cellular networks.

Both the app and the web app are uniquely identified by a session id which is sent together with every request.

After this authentication scheme, a link is established which is valid for so-long time. Of course also the nonces used in the scheme are kept track of by the server and have a deadline. Naturally, all communication (app - server, server - web app) is done over an encrypted channel.

Now, the app can send a string to the server, which then communicates it to the web app to which it is linked. The web app would not show the string of course, but merely copy it to the clipboard when the user asks for that. This reduces the risk of people looking over your shoulder.

Is this scheme secure? What I'm mainly worried/wondering about:

Session stealing: this would of course be more difficult when IP is checked as well, but still, it could occur. When using HTTPS, am I correct that the only way the session could be stolen would be using a man in the browser or man in the phone? This would be acceptable.
How do I choose a bit length for the nonces? It always occurred to me that Firefox uses incredibly short pin codes. Is the necessary bit length dependent on how many users the application would have (for example, with 10,000 open nonces at a time in the database, I could imagine the bit length would need to be greater than with 10 open nonces, to make brute force attacks harder).
Would using a web app on the phone as well (either making a sending and a receiving version of the web app, or making this two-way communication) introduce any additional security vulnerabilities (except for man in the browser on the phone)?
Things I didn't see, obviously.
Am I reinventing the wheel?
Note the requirement to not have to install anything on the computer; it should run in the browser. Also, I'd prefer to not have my passwords in the cloud as with LastPass. The strings that are communicated with my app would be deleted after the web app received them.

I know this isn't a direct answer, but per your request in comments, I am submitting it.

Instead of rolling your own protocol, take advantage of existing protocols to do what you need. Your spec describes a web-based protocol with encryption and limited access to data passed from phone to PC. This web service needs high availability and uptime.

Twitter can fit your bill. Set up a separate Twitter account for this purpose and compose protected tweets that contain the password that you want to pass from your phone to the end point. The only thing you need to introduce (maybe!**) is a simple symmetric encryption of the password. So, your operational task is simple:

copy the password from your phone's Keepass
process the password through encryption
send the cypher text as a protected tweet to yourself
on the PC, capture the cypher text and decrypt it
paste into final application as the password

With the Twitter API publicly available, you could accomplish all this in a few lines of Python code.

**All of this complexity depends on your need for the password to be transmitted encrypted. If you use Twitter, the channel is encrypted (TLS), and if you use protected tweets, no one else can see the text. You could simply send the password as plaintext IF you determine the risk is acceptable. If you go the unencrypted route, I might suggest that your password be as random as possible so that if the plaintext did leak, it would not be obvious that you were sending yourself passwords (e.g. not "thisIsMyBankPassword1!").


What is PKCE actually protecting? I'm trying to get my head around how PKCE works in a mobile app and there's something I don't quite understand.

So from what I can gather the client app creates a random cryptographically secure string known as the code-verifier. This is then stored. From this, the app then generates a code challenge. The code challenge is then sent in an API request to a server along with how the challenge was generated e.g S256 or plain. The server stores this challenge along with an appropriate authorization_code for the request in question.

When the client then tries to exchange the code for an access token it also sends the original code-verifier in the request. The server then retrieves the stored challenge and the method originaly used to generate it for this particular code and generates the equivalent s256/plain hash and compares them. If they match, it returns an access token.

What I don't get is how this is supposed to replace a secret in a client app? Surely if you wanted to spoof this you would just take the client_id as normal and generate your own code-verifier and challenge and you're in the same position as if PKCE wasn't required in the first place. What is PKCE actually trying to solve here if the original idea was that it is basically a 'dynamic secret'?  My assumption is it's only there if someone happens to be 'listening' into when the auth_code is returned, but if you're using SSL again is this needed? It’s billed as replacing the fact you shouldn’t store a secret in a public app but the fact the client is responsible for generating rather than a server feels like it’s not actually helping there.

The reason PKCE is important is that on mobile OS, the OS allows apps to register to handle redirect URIs so a malicious app can register and receive redirects with the authorization code for legitimate apps. This is known as an Authorization Code Interception Attack.

Authorization Code Interception Attack

This is described by WSO2 here:

  Since multiple applications can be registered as a handler for the specific redirect URI, the vulnerability of this flow, is that a malicious client could also register itself as a handler for the same URI scheme that a legitimate application handles. If this happens, it is a possibility that the operating system will parse the URI to the malicious client. The flow of this attack is illustrated in the following diagram.

  In some operating systems such as Android, in step 5 of the flow, the user is prompted to select the application to handle the redirect URI before it is parsed using a "Complete Action Using" activity. This may avoid a malicious application from handling it, as the user can identify and select the legitimate application. However, some operating systems (such as iOS) do not have any such scheme.

Ref: https://docs.wso2.com/display/IS520/Mitigating+Authorization+Code+Interception+Attacks

To understand this better, here is a diagram and discussion from OpenID. You can see that the mobile System Browser has responsibility to receive the redirect URI and route it to the correct app.

Ref: http://openid.net/2015/05/26/enhancing-oauth-security-for-mobile-applications-with-pkse/

However, because mobile OSes can allow many apps to register for the same redirect URI, a malicious app can register for and receive a legitimate authorization code as shown in this diagram, also by WSO2:

Attack Mitigation by PKCE

PKCE mitigates this by requiring shared knowledge between the app initiating the OAuth 2.0 request (request auth code) and the one exchanging the auth code for token. In the case of an Auth Code Interception Attack, the malicious app does not have the verifier to complete the token exchange.


Is it safe to do full disc encryption without ECC DRAM? Our institution requires disc encryption on laptops, but I'm uneasy about using full disc encryption without SECDED ECC DRAM.

Is it safe to use full disc encryption on laptops with unreliable memory?

While the usage of error-correcting memory is a plus in preventing data loss due to sector corruption in the event of memory errors, it is not a requirement for full disk encryption.

Considering that most people do use FDE on computers that do not have error-correcting memory, it should be safe.