How does the EAP-TLS handshake work, exactly? I'm trying to understand EAP-TLS authentication, but I'm struggling to understand a few bits:

Before the supplicant sends any certificates to the server, it usually verifies the server's identity.

After it does, how can it ensure that it's talking to the correct server for further communication, does it establish a tunnel after verifying the server's identity?

If the above case is correct and it does establish a tunnel, what if the supplicant doesn't verify the server's identity. Does it establish a tunnel using whatever certificate that the server presents? Does it not establish a tunnel at all and simply sends further messages using plaintext?
After the client has been authorized, what happens exactly? How is the shared symmetric key derived? How is it passed along to the Access Point so that it can receive/send data from/to the supplicant (since the RADIUS server's part ends after doing the authentication)?

In EAP-TLS, the peer (supplicant) and the authenticator do a TLS handshake. In practice, the authenticator usually relays the EAP mesages to an authentication (RADIUS) server which means that the TLS handshake is actually done between the supplicant and the authorization server.
[ TLS   ]<--------------------->[ TLS    ]
[ EAP   ]<--------------------->[ EAP    ]
[ EAPOL ]<->[ EAPOL | RADIUS]<->[ RADIUS ]
[ Wifi  ]<->[ Wifi  | ...   ]<->[  ...   ]
Supplicant    Authenticator      Authentication Server
(Wifi Client)  (Wifi AP)          (RADIUS server)

The TLS communication between the supplicant and the authorization server works as expected but usually mutual authentication is used:

server sends its certificate chain
client validate certificate chain against server name
client sends its certificate chain
server validate certificate chain
further crypto magic happens

Once the TLS handhsake is finished, the TLS session is not used anymore: it is not used to transport encrypted data.
If the handshake succeeds, the RADIUS server send a "RADIUS Access-Accept/EAP-Message/EAP-Success" message to the authenticator.
At the end of the TLS handshake, both the supplicant and the authentication server derive a "TLS master secret". This TLS master secret is used to derive a Master Session Key (MSK), see RFC5216:

In EAP-TLS, the MSK, EMSK, and Initialization Vector (IV) are derived
from the TLS master secret via a one-way function.

This MSK is sent by the authentication server to the authenticator as part of the "RADIUS Access-Accept/EAP-Message/EAP-Success" RADIUS message. As far as I know (?), the MSK is in practice sent using the following RADIUS Attributes, RFC2548:

MS-MPPE-Send-Key
MS-MPPE-Recv-Key

See the StrongSwan wiki on this topic:

For EAP methods providing an MSK, the RADIUS server must include the key within the MPPE-Send/Receive Keys [...]

See this Security StackExchange answer on this topic.
See RFC5216:
Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key
               (MS-MPPE-Recv-Key in [RFC2548]).  Also known as the
               PMK in [IEEE-802.11].
Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key
               (MS-MPPE-Send-Key in [RFC2548])

Once the authenticator has the MSK, both supplicant and authenticator can use the MSK has a PSK to secure the communication. In practice, the Wifi Pairwwise Master Key (MPK) is derived from the EAP MSK.


Is there a way to check for "hollow" processes, or malware hidden within "normal" processes I recently came across an article on the The Verge, which centers around the concept of commercial malware production and how it's used around the world. The article introduced me to a number of interesting (and worrisome) concepts such as "process hollowing", remote access to hardware that's hidden from the system/user etc..

While I have no reason to have similar worries mentioned in the article, working with IT issues and developing in Java, together with the recent major bugs (shellshock, heartbleed etc) and the ever increasing complexity of the malware makes me quite paranoid about the vulnerabilities of the systems I use and administer.

Whenever I notice a suspicious behaviour (such as unusual slowness, random wake from sleep, high cpu load while not actively running demanding software) I tend to check the running processes on my mac/*nix machines. I have so far not come across anything that caught my eye, but that doesn't mean there are no "hollow" processes.

Is there a way to investigate the an OSX or Linux system, to check whether or not there's hidden malware?

You may find a forensic tool called unhide to be of interest!

http://www.unhide-forensics.info

unhide uses a variety of techniques to find (or unhide) hidden processes and TCP/UDP ports utilized by rootkits/LKMs (Loadable Kernel Modules).  It supports both Linux/Unix & Windows...

More details on the techniques used can be found on the website:

http://www.unhide-forensics.info/?Linux


Is it really better to use port 80 or 443 for outgoing traffic in order to bypass user firewall? I recently created a reverse connection shell in C#. I tested it with some computers and I noticed that some computers connected back correctly and I established connection with them but another computer running Windows 7 doesn't seem to work or establish a connection back to me.

I was using port 3001 as a communication port, and I was trying to establish a reverse connection. Any help why this computer doesn't work ? Is using port 80 or 443 as a communication port will help or It is the same as the connectiion is reverse ! In other words, Is it really better to use port 80 or 443 for outgoing traffic in a reverse connection ?

Port 443 is for SSL. Since SSL is "opaque" to outsiders, firewalls cannot see what is going inside it, and cannot do some transparent proxying. Moreover, a lot of the Web uses port 443 (all https:// URL). Therefore, port 443 is one of the ports most likely to be open for outgoing connections, even on sites with strict rules.

Note, though, that some sites block all outgoing connections except those which go to a specific proxy. SSL cannot be proxied transparently, but it can be done explicitly (with a CONNECT call). If you want to implement a "reverse connection shell" which will work almost everywhere, then you must be able to detect and use a possible proxy for HTTPS.


How do I enable support for Cryptographic Message Syntax (CMS) in OpenSSL on OS X? I want to use the Cryptographic Message Syntax (CMS) of OpenSSL as documented on https://www.openssl.org/docs/apps/cms.html on OS X.

When I try to run openssl cms I get the following error:

$ openssl cms
openssl:Error: 'cms' is an invalid command.

Standard commands
asn1parse      ca             ciphers        crl            crl2pkcs7
(...)

How do I enable support for CMS on OS X?

Answering my own question, as I can't find this documented anywhere.

The problem here is that the OpenSSL build bundled with OS X doesn't come compiled with CMS supported. In order to enable CMS support you will have to compile your own version of OpenSSL.

First, clone the OpenSSL Github mirror:

git clone git@github.com:openssl/openssl.git

Checkout a stable version, for example 1.0.2:

cd openssl
git checkout OpenSSL_1_0_2

Configure the compiled to enable CMS support:

./Configure darwin64-x86_64-cc enable-cms

Then make and install openssl:

make
make install

If everything goes well you should now have your selected version of OpenSSL installed at /usr/local/ssl/bin/openssl. When running /usr/local/ssl/bin/openssl cms you should see the following:

/usr/local/ssl/bin/openssl cms
Usage cms [options] cert.pem ...
where options are
-encrypt       encrypt message
-decrypt       decrypt encrypted message
(...)

Note that this will not override your bundled openssl installation, so you will either need to modify your path or use the binary directly.


Strongest file encryption available I know nothing about cryptography. How does one encrypt a file in the strongest possible way, such that it can be accessed some years later?
I prefer that it should be fairly resistant from brute force and other possible ways attacks.
I need some direction only.

The strongest possible way to encrypt data is to start with a threat model.  What sort of adversary are you trying to protect your data from?  What are they willing to do to get it?  All reasonable approaches to cryptography start with one.  If you start with one, you stand a chance of finding "the strongest" for your particular situation.
I recommend this approach because, as you start thinking about threat models and researching them, you'll start to realize that security is far more about the human element.  Then you can worry about things like how you will secure your key.

source: https://xkcd.com/538/
Once you have decided whether you are trying to outwit a state actor while committing treason, or just merely trying to protect your diary from the prying eyes of your little sister, you can decide what the best algorithm is.
Failing that, go with the flow.  Rather than finding out what is the "strongest" encryption, look for what is "recommend" by the security experts for someone who knows nothing of cryptography.  Currently AES comes highly recommended.  We're quite confident that nobody short of a state actor can break it, and we are reasonably confident that no state actor can break it either.
But better yet, don't look for encryption algortihms, look for tried and true packages which are recommended.  The application of an algorithm is as important as the algorithm itself.  Highly reputable implementations are worth their weight in gold.


Teamviewer and remote logins Not sure if this has been asked before (a cursory search doesn't show anything), so I figure here is a sensible place to ask.

Say I am remotely controlling my desktop at home via Teamviewer. Now while I am connected, say I want to log in to something - e.g. switch user accounts. Now clearly that means typing my password at this end, and the key strokes being transmitted via teamviewer to the other end.

Is this actually secure? For example is there any way someone could log the keystrokes being sent and thus easily get the password.

I've been doing it for many months now, and its just dawned on me that maybe it is not that sensible. Not sure.

I haven't got any reason to think anyone has been spying on the connection (e.g. no evidence of passwords being compromised), but I'm just having one of those, what-if though moments.

Teamviewer indicates they secure their connections client to client.

If implemented properly this should mean no one can intercept the data you send over the network in plain text, i.e. find you password and username, because the connection is encrypted.

In other words, in the case you describe (you connecting to your home computer) it should be secure, assuming you don't have any malware/keylogger running on your pc (but again: that has nothing to do with Teamviewer).

The same may not be true if you connect via Teamviewer to a client his computer. Not because the connection is not secure, but because the PC you are connecting to might have monitoring software enabled.

https://www.teamviewer.com/en/products/security.aspx


What are the suggested way to protect content in mobile app I want to block the view of the images and video in web and mobile app. For the web, I have managed access with WAF and added the API server as a trusted domain. But in the Mobile App, the header referral is empty and unable to match the WAF trusted domain policy. Anyone can suggest what is better to way to protect the Mobile content since the WAF not working for mobile requests.

What you want to do is called the DRM Problem, and it can't be solved. No matter what measures you take, I can always circumvent them.

If you create an image and want to display it on my screen, I can copy it.
If you create an audio track and want it to play on my speakers, I can copy it.
If you create a piece of JavaScript code and want it to run in my browser, I can copy it.

As soon as I have access to it, I can copy it.


HMAC key value and security What effect would there be if you used the same value you were hashing as the Key in an HMAC?

For instance given the following example:

message: "my secret message"
nonce: "0BHKK9IFbdF85KrzMFNpauyxWsM="

If I combined the message and nonce (message + nonce) and use that combination for the HMAC Key and that combination is also what is being hashed what affect would that have in terms of security of the HMAC?

It would seem on the surface that this solves the issue of having to keep a contstant secrect key, because the Key itself, the message, is only known by the person who wrote the message in the first place and the nonce would simply be appended during verification.

Thoughts?

HMAC is not an encryption mechanism. It works like this: you can compute the HMAC output over a given message and another piece of data called the key. Computation is deterministic, so for the same message and key you always get the same output. However, without knowing the key, it is infeasible to compute the HMAC output on a given message, even given a bunch of other HMAC outputs computed with the same key over other messages (so, in particular, one cannot recover the key from a HMAC output, even knowing the message).

HMAC thus serves as keyed integrity: you store the HMAC output with some data, so that you can recompute the HMAC later on and see if it still matches what is stored. On mismatch, you know that either the data, or the stored HMAC output, or both, has been modified.

However you put it, HMAC uses a key which is secret. If there is no key per se, that's no longer the MAC model, that's just creatively complicated hashing.

I understand your question as being implicitly this: you have an encryption system, which, for a given message, uses a secret key K and an per-message Initialization Vector (which you can call "nonce" if you wish). The IV is adjoined (as cleartext) to the encrypted message. You want to add some integrity check, so that you can reliably detect malicious alteration. So your idea is about computing something with hash functions, over the concatenation of the plaintext message and the IV, and store the hash output as a MAC (transforming the hash into "HMAC with the same data as key and main input" does not fundamentally change things here).

Basically, this kind of scheme is weak. The attacker knows the IV (since knowledge of the IV is necessary to decrypt, it cannot be itself encrypted). If the attacker "guesses" the message, then he can recompute the hash. If he can do some targeted modifications on the message (which is especially easy if the encryption is XOR-like, like a stream cipher, or a block cipher in CTR mode), then he can simply recompute the hash value and store it there. Even if you encrypt the hash output with the message itself, then the attacker can still modify the message and the hash correspondingly if encryption is XOR-like.

Also, that hash (or sort-of-HMAC output) can be used as a test to guess the message: the attacker can hash various messages combined with the IV, until a match is found.

If you do want to do encryption with a key, and have checked integrity, you are warmly encouraged to do so with an encryption mode which has been designed for that, e.g. EAX. If there is no encryption in your system and you still want checked integrity, you will need to store a secret key for that, however you take it, and there is little point in not using HMAC as it was meant to be, i.e. with a key as the "key".


Are there any serious problems with this technique for generating symmetric keys? I'm using a technique borrowed out of a book by Bruce Schneier and Niels Ferguson called Practical Cryptography. Basically, it boils down to this:

Bob does this:

pubk_A = Alice's public key

entropy = bytes from PRNG

encrypted_entropy = RSA_Encryptpubk_A(entropy)

hashed_entropy = SHA2-512(entropy)

encrypt_keyBA = hashed_entropy[0:32]
encrypt_nonceBA = hashed_entropy[32:48]
hmac_keyBA = hashed_entropy[48:64]

Bob then sends encrypted_entropy to Alice.

Then Alice does this:

privk_A = Alice's private key

entropy = RSA_Decryptprivk_A(encrypted_entropy)

hashed_entropy = SHA2-512(entropy)

encrypt_keyBA = hashed_entropy[0:32]
encrypt_nonceBA = hashed_entropy[32:48]
hmac_keyBA = hashed_entropy[48:64]

This works great for generating keys that can be used to communicate from Bob to Alice. But I need keys I can use in both directions. I was thinking of modifying the algorithm in this way:

Bob does this with entropy:

pubk_B = Bob's public key

hashed_entropyBA = SHA2-512(SHA2-256(pubk_A) || entropy)

encrypt_keyBA = hashed_entropy[0:32]
encrypt_nonceBA = hashed_entropy[32:48]
hmac_keyBA = hashed_entropy[48:64]

hashed_entropyAB = SHA2-512(SHA2-256(pubk_B) || entropy)

encrypt_keyAB = hashed_entropy[0:32]
encrypt_nonceAB = hashed_entropy[32:48]
hmac_keyAB = hashed_entropy[48:64]

Alice can do the same thing on her side after she obtains entropy by decrypting encrypted_entropy.

As you can see, now there are two sets of keys, one used for communicating from Bob to Alice, and another for communicating from Alice to Bob.

Is there anything wrong with this? What security risks am I taking? Is the security of the system less or more than if I simply had one party tweak a bit in the nonce? Is there a better way to handle this problem without adding round-trips?

Answer to your specific question: There's an easier way to tweak their scheme to achieve what you have in mind.  Go with what's in the book, except make the following modification:

hashed_entropy = SHA2-512(0 || entropy) || SHA2-512(1 || entropy)

so that hashed_entropy now contains 128 bytes.  Now use the first 64 bytes for the Bob->Alice direction (e.g., extracting keys and nonce as in the book), and the next 64 bytes for the Alice->Bob direction (similarly, extracting keys and nonce).

(Here I write || for the concatenation of two byte-sequences.)

Important cautionary note: This scheme does not authenticate Bob.  It is not suitable for use in environments where mutual authentication is expected or required.

High-level comment: I tried to answer the specific question you asked.  However, I would be negligent if I stopped there.  Are you sure you are asking the right question?  Are you sure you need to implement your own way of building a secure (encrypted, authenticated) channel?

While Practical Cryptography is a fantastic book, I'd be pretty reluctant to use a custom design, even one taken from that book, unless I had no other choice.  If it were me, I would first make a serious attempt to reuse some well-vetted, widely-deployed design, e.g., TLS.  Only if that completely failed to meet my requirements would I then consider doing something custom.

My criticism has nothing to do with the quality of Practical Cryptography, but rather with the broad variety of things that can go wrong if you design and implement your own secure channel (including, e.g., subtle implementation flaws that can be introduced).


How does JTI prevent a JWT from being replayed? According to the JWT RFC a JWT can optionally have a JTI which I interpret to be a unique ID for a JWT. It seems like a UUID is a good value for a JTI. The RFC claims that the JTI can be used to prevent the JWT from being replayed. Two questions:

How does a JTI prevent a JWT from being replayed?
How often should the JTI field be regenerated? On every request? Or only when a new token is generated?

The "jti" (JWT ID) claim provides a unique identifier for the JWT.
The identifier value MUST be assigned in a manner that ensures that
there is a negligible probability that the same value will be
accidentally assigned to a different data object; if the application
uses multiple issuers, collisions MUST be prevented among values
produced by different issuers as well.  The "jti" claim can be used
to prevent the JWT from being replayed.  The "jti" value is a case-
sensitive string.  Use of this claim is OPTIONAL.

How does a JTI prevent a JWT from being replayed?
  How often should the JTI field be regenerated? On every request? or only when a new token is generated?

I believe the answers to these two questions will depend on the application itself.

For example, if it has been programmed to only receive messages that have a unique JTI, then a replay of the same JTI can be ignored by the application.

The JTI would be regenerated in this case when it is valid for the same message to be repeated.


What is the difference between probe and scan? I'm struggling to understand the difference between probe and scan because they seem very similar. Does NMAP tool use probes and scans?

Could you give a practical example to make the theoretical difference more clear?

A scan generally means you are using the tools of a system to return precise information about it.  A probe means that you are testing inputs into a system to make educated guesses about it based on it's output.

For example, if you want to know if a website is WordPress, the admin could use the server's file manager to do a scan for files commonly associated with WordPress.  An end user who lacks that privilege may probe your site by testing to see if the site has a login page at ./wp-admin.


RSA Signature - Why Can't Eve Alter The Public Key I understand the procedure behind RSA Signatures, so that Eve cannot make forge signatures on any message but my question is what is stopping eve from substituting everything with her own.

For example,

Bob sends public key and signature on public key to Alice
Alice gets public key and verifies
What is stopping Eve from replacing the public key with her own and then creating a signature on that?

Is the public key stored somewhere that Eve can't modify?

My guess is that Eve would also supply two certificates with that but it's impossible for Eve to generate a signature in which can be verified using the public key in the chrome's trust store.

The problem you describe is how Alice knows that the public key used for signing actually belongs to Bob. As you correctly realized it does not work if Alice receives the public key only together with the signed message and has no way to verify that the key belongs to Bob, because in this case Eve could simply replace both key and signature with their own.

A way to deal with the problem is to make sure that Alice gets Bobs public key up front in a trusted way, for example during some personal meeting. This is usually only possible in a few cases so instead of having this direct trust one can use a derived trust, i.e. Carl gets the key from Bob, Alice gets the key from Carl and Alice trusts Carl that this is really Bobs key. You can implement such trust relationships with signatures to get a more scalable trust network with more parties. This is the basis for the Web of Trust used by PGP but also for a the more centralized Public Key Infrastructure used for S/MIME and also for HTTPS.

Using such trust networks it is also possible to send the public key together with the message as long as the public key itself is signed by a trusted party. For example could Bob ask Carl to sign Bobs key using Carls key and then send a message to Alice signed with this signed key. If Alice trusts Carl, i.e. has Carls public key, then Alice can not only verify that the message was actually signed by Bobs key but also that this key actually belongs to Bob because she can verify Carls signature on it.


What is same site scripting and what are some exploit scenarios? I know it is an issue with how DNS is configured , but is it really dangerous if the attacker couldn't access your network?

Based on the link from Julian's answer, it's pretty straightforward. It does seem a little dangerous but nothing critical.

How the web works

Imagine you have a website. Browsers send HTTP traffic to that website. This traffic includes session cookies. The site should be TLS protected, or your session cookies are going over the internet in cleartext, for anyone to read. You also need to protect your session cookies (and any other sensitive cookies) with the 'secure' flag to prevent them from being sent over http traffic, or your browser will just send them to any server that intercepts your cleartext http requests. And you can use HSTS to prevent usage of http to your server.

When the browser tries to communicate with the web server, it communicates via IP -internet protocol. Internet protocol doesn't use host names, but rather uses ip addresses - 4 decimal separated values such as 127.0.0.1.  the browser uses dns* to learn the ip address for the hostname to which you want to connect. The web server has an associated dns server whose job it is to respond to 'what ip address is this host'. Every named host on the internet is supported by a dns server.  Assuming dns is secure**; the browser gets the server's real ip address from the real dns server.

The class of misconfiguration in question

But what happens if the dns server is misconfigured and returns the wrong ip address? If the desired server is www.example.com at 1.1.1.1 and the server sometimes returns 6.6.6.6, which may belong to evil.com, what does the browser do? The browser connects to 6.6.6.6, evil.com.

Now, this isn't so bad at first blush. Remember how the traffic is TLS protected? Well, TLS lets the browser detect that 6.6.6.6 is not example.com because 6.6.6.6 does not have the private key that goes with example.com's certificate. The browser rejects the connection attempt to evil.com.

Ah, but what if TLS isn't used to connect to 6.6.6.6? In that case, there is a risk. The cookies don't get sent, because you remembered to use the secure flag on your cookies. However, the same domain policy that protects pages served from one domain against pages served from another domain breaks down - these servers are both in the same domain. In theory, malicious JavaScript on 6.6.6.6 should be able to interact with the page served by 1.1.1.1. This is bad. There may be other attacks that suddenly start working as well.

Thankfully, this misconfiguration shouldn't happen in practice.  The DNS server owned by example.com has no reason to serve evil.com's IP address as though it represents example.com.  Typos causing this are unlikely. Even if a typo did occur, users would notice outages before the attacker would likely have the time to make use of the window of opportunity.

The specific misconfiguration in question

But what if there were a common misconfiguration? The security focus message lists one: forgetting to put a period at the end of the definition for localhost. Due to the way the server parses the configuration file, localhost then becomes interpreted as a hostname within the current domain instead of a fully qualified domain in and of itself.  Going back to example.com: if example.com defines localhost incorrectly, we get a resolvable ip address for localhost.example.com.

This routable address for localhost.example.com, which exists within the example.com domain, is assigned a loopback ip address. The loopback address is a special address that computers know means 'myself'. When you try to connect to the loopback address, you are always connection to the machine sending the message, by definition.  In fact, most operating systems will not even send the message to the network when the loopback address is used - then traffic stays entirely on the local machine.

Impact

Just like evil.com could attack your usage of example.com in the original misconfiguration, your computer can now attack your usage of example.com.  The main thing that really seems to lower the risk is that the attacker has to be on the same machine as you are. If they're not, they can't open a network port over which to serve HTTP traffic to your browser from the local machine.

If the attacker is not on your local machine, they cannot make use of this specific misconfiguration.

Example

Let's take an example to try and help understand how this works. Victoria, our victim, is logged with shell access to vicki.com, IP 2.2.2.2. Mallory,  our attacker, is also logged into vicki.com with shell access. Evelyn, our other attacker, controls evil.com at 6.6.6.6.

Vicki opens her web browser within her vicki.com shell,  and browses to example.com, which has a misconfigured DNS entry to include localhost in the example.com domain. Vicki clicks around and does stuff,  and eventually,  for whatever reason follows a link to localhost.example.com.

Mallory prepared for this eventuality.  He is running an HTTP server on vicki.com, with malicious JavaScript. Vicki's browser loads Mallory's malicious page and executes the JavaScript payload. Mallory's JavaScript can now access vicki's account in example.com and do anything that vicki could d,  as vicki. If vicki could read a private message that was sent just to her now so can mallory. If she could delete a user account, now so can mallory. Mallory,  quite literally, the same level of access to Vicki's account that Vicki does -  until she closes her browser*** . Mallory has,  quite literally, delivered a cross site scripting payload using a different attack vector.

Note that Evelyn didn't do anything here and that evil.com didn't come into play. Same site scripting requires the attacker to be on the exact same machine that you are on. Evelyn doesn't have that type of access to vicki.com.   evil.com doesn't have that kind of access to vicki.com.

Note, also, that Vicki had to load localhost in her browser.  Servers don't normally include links to localhost,  so there would likely have to be some social engineering to get vicki to load that malicious page.

Risk: medium

Between a misconfiguration,  the attacker already being on your system,  and the need for social engineering to accomplish the attack,  this isn't all tht serious.  If I had to score it with CVSSv2, I'd give it 6.0(AV:L/AC:H/Au:S/C:C/I:C/A:C),  assuming that vicki is an administrator of example.com,  and her web access includes full administrative access. NVD ranges for cvss would call those medium (https://nvd.nist.gov/cvss.cfm)

About the name 'same site scripting'

Like many names in the security field, this is a bit of a misnomer. It's not really the same site that's performing the xss attack. It's the same domain, but the site happens to be the local machine, not the website in question. This is also not an xss/JavaScript injection issue, but a DNS misconfiguration that bypasses the same domain policy and allows non-injected JavaScript from the local host to run in the context of pages served by the misconfigured domain.

It would have been more accurate to name it something like 'Same-Domain Policy Bypass via DNS Misconfiguration', but that's not nearly as sexy.

End notes

* I intentionally omit all details of using the system's resolver to keep this answer a reasonable length and avoid losing the reader in the details.

** We know it's not totally secure, but just pretend it is so that the answer can focus on the question asked

*** Assuming no other vulnerabilities that allow Mallory to persist his access.


Using Proxy Server, can gateway know which URL i am trying to open I am using a Proxy for example UltraSurf, if I try to open a URL in my web browser, obviously web browser is going to send this information to my Proxy, then Proxy is going to communicate my Gateway.

So my gateway or firewall will know which URL I am trying to open? if no then how proxy hides this thing?

Updatedd - More details:

To be clear I am talking about Proxy Application running on my system. For example UltraSurf. So this proxy application which is running on my PC will obviously be using the gateway which I have mentioned in my LAN Adapter. So visually,

Browser (application on my PC) -> UltraSurf (proxy application on my PC) -> internet

What UltraSurf does is, it starts listening on a port for example 4545, and it changes the Internet Explorer Proxy setting and set Proxy Server to 127.0.0.1, port 4545

Which is showing that whenever I will put a URL in internet explorer address bar, the internet explorer is going to ask Proxy Server to open this website. At this point the proxy server is an application which is running my PC, so it means browser is asking the application to open the Web page.

Now this application is going to go to the internet using my Gateway mentioned in LAN Adapter.

The question is -> is it directly communicating with the website which is mentioned in Internet Explorer browser, or is it going to communicate its own server and that server is going to open the website?

So my gateway or firewall will know which URL I am trying to open? - More or less, yes, but not "directly" per se. It will not know what your IP address is, hence the anonymity. A proxy is simply another computer that exists between your computer and the internet. For example, if you type in www.google.com in your browser while your device is connected to a proxy, this is what will occur:

The browser will make a TCP packet with an HTTP GET www.google.com request (with sender address as your IP address) and sends it to the proxy server. The proxy application running on the server looks the packet and sees that it is addressed to google. It forwards the packet to google.com, changing the sender address in the TCP packet to its own. From here google does not know that it was you who is using their service, they only see the proxy server using it.

Google receives this packet from the proxy and sends the contents of its website in another series of packets to the proxy. The proxy accepts this packet and forwards it back to you. Boom.

Visually:

Browser -> Proxy -> example.com

So, your gateway is under the impression that it is sending an HTTP request to the Proxy server, NOT example.com. Therefore, if you have example.com 'blocked' on your gateway, the connection will still be allowed to the proxy.

:update - since this appears to be a UltraSurf specific question.

Ultrasurf does not use a DNS. It takes your typical DNS queries and routes them to a static IP, instead of asking for one (much like modifying your HOSTS file or equivalent). That way you are connecting to port 80 on the unblocked IP address 74.125.224.160 (youtube.com), instead of making a disallowed DNS query.


Why do X.509 certificates have "Key Usage" attribute? I can find their values and all details in the RFC, but I cannot find why it was decided to have this attribute in certificates, instead of leaving them to be multipurposes.

Is there a reasoning behind this choice (key length?) or is it strictly business related, as they are priced very differently?

Strictly speaking, a key should not be "multipurpose". Distinct key usages call for incompatible key life cycles. The Key Usage extension is a formalism of this fact.

For instance, keys which are used for signatures and authentication could be lost with relatively low consequences: if your smart card is destroyed, you can no longer sign, but no data is lost; you just need to be issued a new smart card (this is inconvenient, but no security breach occurred). But you do not want people to begin to encrypt data with that signature-only public key, because in that case you need to make backups of the key, to avoid data loss upon key loss -- the smart card will strongly oppose to backups, by construction. The Key Usage extension documents the idea that a signature key is to be used for signatures only because it won't be backupped. Conversely, an encryption key will normally be escrowed somewhere, and thus you do not want people to consider it as binding if it is used for signatures: this would allow whoever has access to the escrow/backup system to sign "in your name". There again, the Key Usage extension protects against that.


Will my existing VoIP phone work if I install TOR? I currently don't use TOR and I have VoIP - a physical phone using a provider's VoIP service over my Internet connection. If I install TOR, will I still be able to make and receive phone calls with my VoIP phone? I am not concerned about the privacy of the phone calls, I just want to be able to use the phone. Thank you!

In most cases,  your ISP has separated your voice traffic from your data services. Your modem is still the endpoint for traffic, but likely using different addresses for data/voice.

Heavy utilization can cause breakup to separated voice services but shouldn't be negatively impacted by tor.


BAD USB attack possible while screen is locked? If i leave my screen locked and someone sticks in a thumbdrive that was manipulated using the bad USB exploit would an attack be possible?

The three most widely known ways that Bad USB affects a computer is:

  A device can emulate a keyboard and issue commands on behalf of the
  logged-in user, for example to exfiltrate files or install malware.
  Such malware, in turn, can infect the controller chips of other USB
  devices connected to the computer.
  The device can also spoof a network
  card and change the computer’s DNS setting to redirect traffic.
  A
  modified thumb drive or external hard disk can – when it detects that
  the computer is starting up – boot a small virus, which infects the
  computer’s operating system prior to boot.

If your screen was locked, then discounting a brute force attack against the lock screen only (2) would apply, affecting any currently active or scheduled process that makes outbound connections from your computer. However, if these processes authenticate the remote server by use of TLS/SSL certificates then this threat would be mitigated.


SIEM Alien Vault recommended method for muting noise I have installed Alien Vault into my environment and I am seeing a ton of logs going into the SIEM. Upon further investigation, I see that these are being generated by AlienVault itself. I think that these events are noisy and create complacency where I need to see real events. I assume that most people are ignoring these events somehow. I have read online and all I can find is this

How can i prevent alienvault logs from being shown in ossim ?

Judging from the above article , I see that this method is somewhat of a hack.

Here is what I am currently doing . I created two rules for Source of AlienVault and one for the Destination of AlienVault , then set them to No SIEM. Is this a sound practice?

Is it recommended to silence or mute AlienVault alerts?

What is a good or clean way to accomplish this?

I reached out to AlienVault via e-mail and they sent me the same workaround you described in your question:

  1.- create 2 policies.
  go to configuration -> threat intelligence -> policies.
  chose default group.

  2.- first policy will have AlienVault Appliance IP as source ip.
  click new policy.
  set a name for the policy - like ’from AV'
  on source ip select alienvault appliance asset from asset tree
  on destination field select any
  on siem consequence select no.

  3.- Second one, AlienVault Appliance IP as Destination.
  click new policy.
  set a name for the policy - like ’to AV'
  on destination ip select alienvault appliance asset from asset tree
  on source field select any
  on siem consequence select no.

  4.- Reload Policies You should have a red label/button ‘reload policies’  click it.

  This will prevent AlienVault to capture and analyse its own traffic.


Is a donate button on a http only site insecure? I want to put a PayPal donate button on my web page, at the moment it doesn't have https (I'm working on it...)

Would this be insecure for the people donating or for me?

The problem with having a link to an encrypted site (https) from an unencrypted (http) one is that if someone could "man in the middle" the cleartext (http) traffic they could change which link you go to.

More importantly in the case of your PayPal button, an attacker could send you to a fake website where they copied all the current PayPal HTML for look & feel but then use that to collect username/passwords or otherwise gain access to you clients accounts. Fake websites like this which harvest user credentials have existed for years.

In this case, the risk isn't to PayPal so much as it is to your clients and your clients PayPal accounts.

This said there are a number of easy options to encrypt the page hosting your PayPal button, or it's equivalent.


Limiting redirect parameter to specific domain Using PHP to set a Location header to redirect (e.g., upon login after being signed out) can be insecure if the redirect does not specify a domain. Here is an example:

header('Location: ' . $_GET['redirect']);

Is there a simple way (not a whitelist) to ensure that the redirect not leave the domain. Maybe something like:

header('Location: /' . $_GET['redirect']); //start forward slash guarantees domain cant change?

Your example is trivially bypassable:

http://yoursite.com/page.php?redirect=/www.google.com

results in a redirect of:

//www.google.com

Which is a valid URL.

You should parse the URL using a function like parse_url then reconstruct a sanitized URL with the path components you want.  For example, you could use just the path and query fragments to build a URL that redirects only within the current protocol, port, and host.


Does Kerberos authentication handle DNS names the same way between Windows 7 and Windows 10? Recently, we migrated from Windows 7 to Windows 10 and during that migration, we progressively ran into some issues with our NAS device. To be more precise, we progressively noticed some tcp socket flooding on it while client computers were upgraded to Windows 10. We suspect that our NAS has some difficulties with NTLM, but this is out of this question scope.

Our NAS has a FQDN : filesvr1234.prod.company

We also have a DNS alias pointing to that FQDN : prodfiles.company

Kerberos authentication is enabled on filesvr1234.prod.company, but not on the alias prodfiles.company because we have some legacy apps that need NTLM.

We investigated on those issues by running WireShark while trying to read a file from a samba share on our NAS \prodfiles.company\shared\test.txt.

We observed the following behaviour.
Both Windows 7 and Windows 10 try first to authenticate using Kerberos.

Windows 10 will try authenticate using the alias prodfiles.company (which is the expected behaviour because we access the share with \prodfiles.company\shared\test.txt). It will use NTLM. However, we noticed that Windows 7 uses the FQDN (filesvr1234.prod.company) instead of the DNS alias, even if we access the share using the alias (\prodfiles.company\shared\test.txt). It will use Kerberos.

To see this, we looked at "SNameString" in KRB5 packets (Wireshark).
To summarize :
We read a file in \prodfiles.company\shared\test.txt
Windows 7 use filesvr1234.prod.company even if we access the share using prodfiles.company.
Windows 10 use prodfiles.company

Does something changed between Windows 7 and Windows 10 that makes the authentication process to use the DNS alias instead of the FQDN ?

What you're seeing is name canonicalization during the formation of the SPN. Kerberos requires clients to resolve names to the official record in an attempt to restrict hijacking/ticket theft and Windows enforces that.

Both Windows 7 and Windows 10 will do this by default, but it's possible to configure it to not do that through registry settings like DisableStrictNameChecking. However, that's pretty drastic and dangerous.

The recommended approach is to register the appropriate SPN cifs/filesvr1234.prod.company to the service account you're using for the NAS.


SQL injection at work We have a web form that can be filled out with text fields and then they get emailed to us at work. Today we got some SQL commands it looks like in a bunch of emails. I just would like to have a bit general knowledge of what they were trying to do. I copied every command they sent through and have it below:

All I am asking is what were they trying to do?

&dir
--
or 1=1--
#
convert(varchar,0x7b5d)
bad_bad_value'
'+convert(int,convert(varchar,0x7b5d))+'
char(39)
convert(varchar,0x7b5d)
'
/*
convert(int,convert(varchar,0x7b5d))
'
9,9,9
convert(int,convert(varchar,0x7b5d))
' or 1=1--
%27
'+convert(varchar,0x7b5d)+'
tqedbt
and 1=1;--
x || ping -n 3 127.0.0.1 &
& ping -n 3 127.0.0.1 &
and 1=1
index.cfm

They were hoping the textbox submitted data to a sql server and that the data was not filtered/sanitized. 1=1' is a common method for testing for sql injection. The x || ping -n 3 127.0.0.1 & request is used for testing for shellshock vulnerability.

Answer to comment below:

By filtered/sanitized I mean using a method such as htmlspecialchars. I made 2 scripts especially for this answer. I have made a html and a php script that will demonstrate xss. Here is the html file.

  <form name="form" action="https://localhost/poc.php" method="post">

Test Form

  <input type="text" name="agentid" size="20"/>
  <input name="submit" type="submit" value="Submit">

  </form>

And here is the php file ("poc.php")

  <?php

  $test1 = htmlspecialchars($_POST['agentid'], ENT_QUOTES);

  $test2 = $_POST['agentid'];

  echo 'this is not vulnerable
';

  echo $test1 . "
";

  echo 'this is vulnerable
';

  echo $test2;

  ?>

Go to the html page and type XSS in the text box and hit submit. You will see a link on the webpage. However you will notice the link will only be under the text that says "this is vulnerable". Take a look at the webpage source code and you will see one result is sanitized and the other is not.


For attackers looking to launch arp spoof on a target, does the attack have to happen in real time? I was surfing the web at 3 in the morning and I got a warning which seems to indicate a MITM attack. Does this mean the attacker was able to passive sniff my activity in real-time in order to launch the attack?

I think Yes, it has to be in real time.

As I understand the attack, it poisons the cache of arp entries in your OS using arp replies, and due to ARP protocol standards, it updates the cache of the OS immediately even if the entries is not expired.
After the attack is finished, the OS updates the ARP cache after multiple 'futile' requests using the poisoned cache.


How To Securely Run PHP From A Mysql Database I have Mysql database with an API tied to it to call and run PHP code stored in that database. Yes, you heard right, PHP Code stored and run from a Mysql database. So, this is pretty serious from a security standpoint, and that is my dilemma. Your first suggestion might even be,"NO, Bad!". Fear not, it can be done. There are a few good reasons for doing this.

40x speed increase (no HD reads)
Automatic Dependency Injection.
Other Programming Languages.

Security.

Input sanitation would "seem" to be the most important thing here, and my filter is top notch. SQL Injection would be your worst nightmare.

My question is this: When running live code from a database, can it be defendable, can it be attacked? What attack vectors could be possible? And how could you defend?

In summary, I need expert advice, Worst-Case, Best-Case, Do this, Don't do this. You are insane, something.

UPDATE1: I will be reading all comments over and over, The Truth Matters.

I am using a percona mysql cluster, measurable speed is occurring (stored in ram)
Versioning is easy (and built in) Got a table with L(language) FunctionName Vars Deps RequiredVars VERSION# etc...etc.
I Would add for interest level, that An application could be mostly integer based, in which case input can be sanitized by casting to (int) (IE. $num = (int)$_GET['s']; )
I highly welcome ideas, suggestions, and topics. As I believe this breaches many barriers while reaching new ones and am now fully willing and pre-dedicated to figuring this out, that part is a done deal; O, The Humanity! But I believe this CAN be successfull.
Another added benefit is language neutrality, since I store my code in a database, labeling one code as PHP and one as RUBY or PYTHON, has serious uses. Nothing a little php-shellexec action cant make beautiful (again with near-perfect input sanitation in mind)

Will Continue to update (i have a busy schedule, but I will be as attentive as I possibly can.)

General Thoughts

This seems like an awful idea for production. If you just want to try stuff out, that's another matter.

I also don't see how it is an advantage. Regarding your points:

Where is your db located? Why would you assume that it doesn't require hd reads? And if you think db results are stored in ram, why not php code from files? And have you actually profiled this? For a large scale? I would assume a large speed decrease (and that is not even considering things like not being able to use php caches).
Really? How? And couldn't you just use a library for that?
What? I don't think that this really counts as language neutral

You also need to consider that debugging will be quite difficult, which is probably the biggest downside. Developing and deploying new code will likely also be more difficult.

Threats

The things you need to worry about with your approach:

Being able to write to the code database will lead to code execution. Writes could take place via injection, or by reading out or bruteforcing the database password (if an attacker is able to connect to the database).
Being able to inject into the SELECT code database queries will lead to code execution.

Mitigations

Anyways, if you still want to do this (hint: don't), there are a couple of things you can do to make it a bit more secure:

Store your PHP code in a separate database, accessible with a different user. The user that retrieves normal data from the database should have no access to this database.
Don't allow remote access to the code database, and obviously use a secure password. Don't use things like phpmyadmin, which would in effect allow remote access to the database.
Don't put user input in queries running against the code database.
Ideally don't perform queries against this database all over the place. You probably only need one or two functions which select the code you want. Use prepared statements for those.
Think about only giving the code database user read access to the code database (if this makes sense in the context of your application).

Also, the proper defense against SQL injection is not input sanitation or filtering (it will go wrong), but prepared statements. Casting input to ints is great as defense in depth, but in practice, it is miserable as only defense. I have seen many application that take that approach (plus ecaping/filtering for non-int), and it never goes well.

I assumed that you store your PHP code in the db and execute it with eval, but most of the points will likely apply with other approaches as well.


PCI DSS v3.1: clarification about usage of TLS v1.1 PCI DSS v3.1 recommends usage of TLS v1.1 or greater:
https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf

  … it is therefore strongly recommended that POI environments use TLS v1.1 or greater wherever possible. New implementations of POIs should strongly consider support for and use of TLS 1.2 or greater. If SSL/early TLS is not needed in the environment, use of and fallback to these versions should be disabled

Any case I need the clarification: should I use TLS v1.1 for any communication?

It is clear for me that if I have HTTP server that is used for user access I must use TLS v1.1.

What about an internal communication?

We use stunnel for the internal communication between our servers and we use TLS v1.

Should we configure stunnel to use TLS v1.1?
Or we can continue to use TLS v1?

What if some component (for example PostgreSQL) can not support TLS v1.1?

What should we do in this case?

Michael, my read of that guidance is that the requirement about moving to TLS 1.1 (preferably 1.2) applies beyond the POI context to your internal systems, including (as  far as I can tell from what you provided) the links between the servers you talk about. I say that because, first, of the actual PCI requirements that the guidance points to as being implicated here:

  Requirement 2.2.3  Implement additional security features for any
  required services, protocols, or daemons that are considered to be
  insecure.
  Requirement 2.3  Encrypt all non-console administrative
  access using strong cryptography.
  Requirement 4.1 Use strong cryptography and security protocols to safeguard  >  sensitive cardholder data during transmission over open, public networks.

Now, merchant-to-you encrypted connections involving POIs are clearly part of this through Req. 4.1.  But the reference to Rule 2.3 about encrypting all administrator access stuff and to Rule 2.2.3 with its wider general applicability to many systems that a PCI-covered entity possesses leads me to believe the internal processing connections you're talking about are indeed within the upgrade requirement.

Now, as is usual with PCI stuff one important thing to keep in mind is that there's often quite a lot more flexibility built into the requirements vs. what might seem the case on first blush.  For example, the linked-to guidance says that you can meet the "upgrade" mandate if you use encryption in another layer/type that's at least as strong (security-guarantee wise) as TLS 1.1.  For example, if you set up a IPsec tunnel between two servers and then run your non-upgradable TLS 1.0 flow through the guidance says that you are & will be in compliance.  For more info about flexibilities you might have under the guidance and under the actual Requirements more broadly I'd definitely seek out a PCI consultant or firm that has strong expertise in helping payment gateways & payment processors keep up with new evolutions in PCI rules that are occurring if the wake of the massive thefts of user financial info that have occurred in the last few years.  (And, while I'm on the subject of getting direct, reliable advice from an expert, I'll throw in the obligatory disclaimer that I haven't looked extensively into the particulars of your case, may or may not have sufficient expertise--from your standpoint, I'm just a guy on the Internet--to do so, and thus what I have written above is not a substitute for professional counseling.)

In other words, I think your internal networking connections are covered by the upgrade rule, at least to the extent that they convey authentication credential info needed to do administrative things (eg. user names & passwords, of course) and/or carry sensitive card data & other financial info over them.  My two cents...

PS:  Keep in mind not just the ultimate deadline for upgrading (or making redundant) TLS protections by June of 2016, but the reporting and mitigating measures that the guidance also discusses.


How are browser saved passwords vulnerable? Most browsers offer to save the password after entering it on many logon pages.  What types of vulnerabilities are there for such saved passwords.  I'm interested in what ways malware on web pages that are accessed later might be able to retrieve the passwords (or make use of them).  Are there vulnerabilities from these things (or others)?:

plain html
javascript
flash
java
pdf

I'm talking about vanilla password saving, not the (presumably) more-protected systems using things like master passwords as discussed in this other question.

Assuming that as you say you don't use a master password, and so the password database is stored in clear text:
It depends on what kind of malware you refer to.
If there is a 0day exploit (or you use an unpatched browser), which 'breaks out of', embedded in any of the things you mention, effectively causing arbitrary code execution on your host, then that malware will be able to recover the whole database (but that will be the least of your worries).

In the common case of simple javascript execution (by xss for example), the script may be able to capture the password associated with the forms of that specific page.
Again, if there is a unpatched flaw in the browser which the script takes advantage of, like breaking the Same Origin Policy protections of the browser, then it might be able recover any password from the database.

Finally, if the attacker can not 'trick the browser' (as in attacking a vulnerability), he may also in the end try to 'trick the user' - think social engineering - by using some subtle way to make it so that you send the database yourself without noticing it.


Is it secure for a user to manually reset his password on every login when OTP isn't forced? Is it secure for a user to manually reset his password every login (via email or 2 factor authentication) to a random token via email or 2 factor authentication, when OTP isn't forced ?

I mean an attacker would need to gain access to the email to login,
but if he is able to access the email,
then he could circumvent the password by reseting it anyway.

I cannot see any direct security problems, but there can be side effects.

On some systems, the user and/or the admins are warned that a password was changed. Changing a password everyday could add noise there. Another possible test is that changing very often a password could be an indicator that something weird happens with that account and here again the user and admins could be warned of that.

Some systems can use password synchronization. Ok SSO is better, but not all systems support it, that is the reason why password synchronization can be used. When a password is successfully changed in one system, a request to set the new password is sent to another system. Under abnormal conditions (network problems) the request can be queued, or lost. In the first case, the passwords become different during a variable but short period, in the second one, the passwords go out of sync until next reset. This is seldom observed in normal conditions because you need the simultaneous occurence of 2 events: a password change and a network problem. But if a password is changed everyday on such a system, you can expect to fall in that trap.


Groupon SG is Storing Customers' Credit Card Information Today I was purchasing a gift from Singapore Groupon website. And then I realized that what I have to do is simply login and hit the "submit order" button, because they store my credit card information from my previous purchase.

By credit card information here I mean: credit card number, credit card validity date, and security number behind the card (CVV2). Which are more than enough for a thief to empty your bank account (more easily if it's a Debit VISA card).

I'm sure that they've stored my credit card information because I started with a "clean browser" by using Firefox's private browsing. As you can see below at the screenshot right after I clicked "Buy" on any of the deal, I don't have to enter anything, they have it all. Even they're showing the validity date on the screen:

I somehow kind of know that it's illegal to store customers' credit card information especially for being ready to use for the next purchase (so that they don't have to re-enter the information). But I couldn't find it on Master Card or VISA agreement.

Is there any official law about this, and where can we report something like this?

If it's really illegal, I would want them to at least being fined for what they've done.

[EDIT]

Here's what they've put on the FAQ page:
http://www.groupon.sg/faq

  Is Groupon safe?

  Extremely. Your credit card number is transmitted by SSL directly to a
  secure electronic vault. At no time is your credit card information
  stored on our servers. Nonetheless, this security only applies if
  you log out of your Groupon account after use! It is your
  responsibility to keep your Groupon account secure.

The fact is, they store the credit card information, and you're even provided to register with Facebook account. One simple click "connect to FB", and you won't even need to enter any password to charge the credit card.

Even if it's legal, they have shown some careless quality in handling the payment process.
They don't provide an appropriate interface to protect our security.

[UPDATE from latest answers]
According to some answers on this post below, it turns out that it's legal to store credit card information, only that the website is supposed to follow the security standard from PCI-DSS. But it seems like there's no one who is responsible to ensure if every website is following the standard?

Not sure if this only happens on Groupon Singapore or all Groupons around the world.

https://stackoverflow.com/questions/8425707/groupon-sg-is-storing-customers-credit-card-information

I don't believe there are any actual LAWS in place to prevent storing credit card details aside from those meant to protect against fraud.  However, the PCI-DSS certainly takes a much harder stance against the storage, transmission, and processing of credit card details.  The penalties are against the merchant, and can be quite severe, so there are industry-based sanctions to deter against failing to adhere.

If you read the PCI-DSS compliance text, you'll see that a merchant -- with the proper infrastructure and security systems in place -- is allowed to store the full CC#, expiry date, and name on the card.  They CANNOT store the CAV2/CVC2/CVV2/CID under any circumstances (not even in an encrypted manner).  See section 3.2.2 of the PCI SAQ-D (which is the most general form of the PCI-DSS assessment questionaire).

Are you sure they are storing the digits on the back of the card?  This is a very blatant violation.  Both VISA and MC have methods to report merchants which do not adhere to PCI-DSS and as global brands, they are enforced in Singapore.


Creating username policies and best practices I have found a tonne of information on password policy all over the Internet and several best practices checklists.  However from a username point of view I could not find much. I thought it would be really helpful to have something like this to prevent harvesters from being able to build dictionaries or username enumeration as well as other preventive steps where the username can be used by an attacker.

Could someone link me to some relevant documents and information?

My opinion: If your security is well-designed, you don't need a policy about usernames.  You don't need to try to prevent attackers from guessing usernames if you've done the rest of your security right, because it won't do the bad guys any good to be able to guess usernames if they can't (e.g.,)  guess the corresponding password.

You might want to put some limits on what usernames your users can choose, to make sure that a random user does not create a username that implies some official position at your company.  For instance, you might want to prevent ordinary users from selecting a username like root or admin or abuse or webmaster or spam or help, just to prevent other users from being confused by them.


SSL Certificate conversion from PFX to PEM - our SP says files are wrong We have to give our Certificate - managed by one of our suppliers to another one of our supplier. from one we got PFX file, another needs PEM files.

I've ran the conversion using OpenSSL and I've uploaded the files, but they say our chain/bundle part is incorrect.

it looks like this:

Bag Attributes
Microsoft Local Key set: <No Values>
localKeyID: 01 00 00 00
friendlyName: le-4a0ecc93-da0b-4b35-964a-16469b2508cd
Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider
Key Attributes
X509v3 Key Usage: 10
-----BEGIN PRIVATE KEY-----

-----END PRIVATE KEY-----
Bag Attributes
localKeyID: 01 00 00 00
friendlyName: *.domain.com
subject=/OU=Domain Control Validated/CN=*.domain.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

And our supplier requesting certificate says it's incomplete.

Would there be difference between the above and three separate .CRT and .KEY files they ask for?

EDIT: Yes, the SP asking for certificate is hosting part of our website, which is not yet encrypted. We need to secure it as some of our customer data is being passed through it.
Follow-up question: So is it possible that we were given incomplete pfx file?
Command used to extract the data:

openssl pkcs12 -in cert.pfx -out keyStore.pem -nodes

We have to give our Certificate

May we assume you're providing the web hosting provider your SSL key and certificate?

Indeed they will need

key file - content of the PRIVATE KEY (including the -----BEGIN PRIVATE KEY----- and end tag lines)
certificate file - content of the CERTIFICATE (including the tag lines)
Issuer (Go Dady) signing certificate (can be combined in the certificate file from the point 2).

So maybe they are missing the 3rd file.

  Would there be difference between the above and three separate .CRT
  and .KEY files they ask for?

In theory - they could extract the private and public key from the text you've copied and download the issuer's certificate (publicly available). However - seems they let you do your complete homework and provider them all the correct files.


Is two phase authentication using SMS/voice dead? I'm looking at implementing a two-factor authentication system for my web site, utilizing a user's cell phone as the "something you have" part of a two-factor system.   It seems like there are two typical approaches to do this:

Send a code via SMS or voice message to the user and ask them to enter the code on a web page to complete the login.
Use an app on the phone to generate a TOTP token, and ask the users to enter the token to complete the login.

I'd like to avoid the expense and complexity of sending a code via voice or SMS, but are there any security or even usability benefits I get by supporting option #1?  Of course, one benefit is a wider range of supported phones since SMS and voice works with feature phones as well as smart phones.  However, as smart phone adoption increases, that benefit will be reduced.  Are there other benefits that SMS/voice provides?  If not, is two phase authentication using SMS/voice effectively dead?

The only benefit I'm aware of to providing SMS-based two-factor authentication, though it's potentially a big one, is that it provides a better defense against you losing any particular phone.  I.e., with TOTP, if you lose your phone, you have to use your backup codes for each site and generate a new key with your new phone.  Doing this inevitably requires locating your backup codes, which, if you're a normal person, you probably don't carry on you all the time.  Thus, the bootstrap process can be annoying.  With SMS, you'll just receive a text like usual, and go on your merry way.

In practice, several sites I use provide TOTP as their primary two-factor auth, but will fall back to SMS to cover exactly the second scenario.  That seems like a good compromise for the time being.


Cisco PIX SNMP enabled or not? On a Cisco PIX firewall, I wanted to check if SNMP is enabled:

  pix# sh snmp-server

  no snmp-server location

  no snmp-server contact

  snmp-server community public

  no snmp-server enable traps

Is SNMP enabled on this device?

Yes it is. The default configuration for the snmp server is enabled. If you do a sh run all | i snmp you should see a snmp-server enable line in your configuration. However if you'd like to actually use the snmp server you'll need to add a snmp-server host x.x.x.x command to the config.


How to encrypt database connection credentials on a web server? OWASP advise against storing DB credentials in plain text:

https://www.owasp.org/index.php/Password_in_Configuration_File

However, they don't provide suggestions of how to encrypt the DB access credentials, where to store keys, how to manage access to keys, etc.

Has anyone any real-world experience of implementing such a solution who can suggest an architecture on a LAMP stack (ubuntu 10, PHP 5.3)?

PS - I'm not looking for answers along the lines of "don't bother - if someone gains root access it's too late", etc.

The other answers here are all correct in a couple key aspects. The file containing your connection string should not be kept in a world readable location, and as you note, you can't stop someone from getting at the key if they've compromised your server. Even so, there are other reasons to encrypt the key (or the file). Part of the reason OWASP recommends against storing in plain text are to prevent accidental disclosure of credentials to those who don't need them.

While many make the point that encrypting the connection string on the running system provides little actual value (security by obscurity) this is true primarily in the context of the live system. Assuming a traditional LAMP configuration, file based permissions would prevent read from any user other than the script user that the php/apache process is running under. Having the file outside of the root location provides slightly more potential security (in case of misconfigured MIME handlers or .htaccess) but isn't strictly necessary.

The greatest value in segregating connection settings is that authentication details and data no longer needs to be handed out to developers/testers or other individuals that may have a real need to connect to the server. By keeping the connection details out of source control, and out of general distribution, you reduce the possibility of loss or leakage.

A second benefit is the distribution and backup of the source. Certainly a best practice would be to only transfer files containing sensitive connection and account information encrypted themselves, but for many reasons, this isn't always practical. Due to this if encryption is in use, separating the key from the connectionstring and separating the connectionstring from the source is an essential action. Doing this has separated the duties and protection of the encryption keys (or configuration files) and becomes a system administrator function, rather than a developer function.

That out of the way, in Apache/php you have a number of options.

1.) Don't put the connectionstring in php code at all. You can put these values in your httpd.conf or virtual hosts file. Connection then requires no parameters when using mysql_connect() ... more detailed use is available here: http://www.php.net/manual/en/class.mysqli.php

2.) Include the configfile.php configuration file as normal, but move the connection file out of webroot if you can, and encrypt the file itself. OS decryption can be set up by the SA for the process that will access the file. Alternately use If you can't move the file out of the webroot (shared hosting) secure the file with .htaccess

<files configfile>
     order allow,deny
     deny from all
</files>

For Microsoft IIS with ASP.NET, the connection string is stored in the application.config or web.config file and the encryption used can either be a static machine key, stored in either of these files, or a key generated by IIS itself - which is not stored in an accessible location. Specifics are available on MSDN, which I won't litter this answer with since your question was specific to LAMP.

I should also note, that when possible, my preference is to avoid the issue altogether by using integrated authentication. Mapping the OS user to a db user pulls the protection requirements out of this question's context almost altogether.


What are "redundant boot persistence mechanisms"? I'm trying to learn techniques used in malware development.

  Dexphot's advanced techniques, such as the use of fileless execution,
  polymorphic techniques, and smart and redundant boot persistence
  mechanisms.
  source

I was searching for the term "redundant boot persistence mechanism", but couldn't find anything useful.

Once malware infects a system, it looks to stay there even after interruptions that might cut off its access. This behavior is known as persistence. The underlying details of how the malware achieves persistence is known as the malware's persistence mechanism.

For example, without boot persistence, the malware would simply die and cease to function after a computer reboot which would kill the malware process, so the malware needs a way to automatically start up each time the computer is turned on. That way, the malware doesn't require the user to explicitly run the malicious file each time to re-infect the system.

To achieve this, malware oftentimes uses the same exact techniques that legitimate software does when it wants to automatically start up (software such as software updaters, notifiers, services, drivers, etc.). The most common technique would be to create a run key that references the malicious executable.

From https://docs.microsoft.com/en-us/windows/win32/setupapi/run-and-runonce-registry-keys?redirectedfrom=MSDN:

  Run and RunOnce registry keys cause programs to run each time that a
  user logs on. The data value for a key is a command line. Register
  programs to run by adding entries of the form
  description-string=commandline. You can write multiple entries under a
  key. If more than one program is registered under any particular key,
  the order in which those programs run is indeterminate.

  The Windows registry includes the following four keys:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

Keep in mind, there are other ways of achieving boot persistence, and there are many other run key locations, some of which require more privileges and are system-wide. With administrator privileges, the malware could register itself in the HKLM hive rather than the HKCU hive, so the malware could automatically start up each time regardless of the user logging in.

Anyway, to answer your exact question, when the source says that Dexphot utilizes "redundant boot persistence mechanisms", they most likely mean that the malware has multiple boot persistence mechanisms that act as fail-safes, so even if one of the persistence mechanisms fails or stops working for whatever reason (e.g., a run key referencing the malware is deleted), the malware can still remain persistent and automatically start up when you reboot your computer.


Does it matter if a brute force search for a password returns a collision and not the password? Assume the following very basic hashing algorithm.

h(k) = k mod 17

Let's say we create a password 12345 for a website that uses this very basic hashing algorithm.  That would yield the hash of 3.

Say a brute force attacker comes by and starts guessing numbers starting at 1 they would only have to get to 3 before they got a hash collision and obviously 3 is not the original password.

Is the problem that the password hashing space (0-16) is much smaller than the space of the allowed password, or is there something else I'm overlooking?

Steffen's answer covers this perfectly, but I just wanted to add a few more details.
Anything that gives a match is usually fine
As he says, you generally don't care about finding the actual password, because many applications will be happy to authenticate you with any string that happens to hash to the hash value stored in the database.  This is most often true for web applications, but may be less often the case in other contexts.  This means that if you perform a brute force search and find something with the same hash, you can login to the account even if it isn't actually the same password.  This, as implied in the question, is the nature of hashing and is a direct result of the pigeonhole principle.
Until you need the actual password
However, there may be some cases where you do want to find the original password.  This would be the case if for instance a hacker stole a username/password from a valueless service and wanted to try to login as the user on a more valuable service (Facebook, banks, etc...).  Since people often use the same password everywhere, then in this case you really do want the original password - not just something that hashes to the same value for a given hashing algorithm (after all, different services may use different hashing methods, and most also use cryptographic salts - h/t @Taemyr).
But the difference doesn't matter
Fortunately (for our attacker), this doesn't really matter.  The reason is because an exhaustive brute force is effectively impossible.  Instead a hacker will try things that are likely to be passwords (word lists, common passwords, etc...).  As a counter example imagine that despite the impossibility of it you have a hash from a web service and manage to perform a brute force search on all possible 256 bit ASCII strings.  You find three inputs that hash to the same value as the user's password hash:

BD3EDF42F6D3AF2DAAE93313EB534
7AF7B8B8F84443872C48EC372DBD1
password

Which would you guess is the actual password?  The answer is clearly #3.  I mean, there is technically a chance that the user just happened to pick an extremely strong password (i.e. BD3EDF42F6D3AF2DAAE93313EB534) that just happened to hash to the same value as password, but the odds of that are effectively zero.
In this sense the attacker has a nice advantage.  They would prefer to find the actual password, and it turns out that because people are bad at picking random passwords, the best way to do that isn't by checking everything anyway - it's by checking things that look like passwords.  This makes brute forcing searching much, much, much, much more effective, and also gives the attacker a much more useful result (the actual password, rather than some random string that happens to have the same hash).


Is it possible for someone to location spoof (such as a VPN or other) to not be flagged when logging into personal accounts (for example Facebook)? I just logged into my FB account from a different location as usual and received a message that my account was locked down due to that attempt from an unknown location. This spiked my curiosity, and I'm wondering, if I was able to change my location to my home address using a VPN (not even sure you can be that specific or not,) would I then be able to log into my account with no issue? I'm sure this is something that's been thought of, but I'm just curious how they would determine that I'm not actually there?

The exact mechanism for this check is not publicly known (as far as I know) and might also change over time. Specifically it is not clear if it is actually (only) based on the physical location or if there are other factors. Since this mechanism is part of an anomaly detection to detect account misuse (like stolen credentials) it is based on the user profile (learned or heuristics) and might take the following in account:

Huge and sudden changes to the physical location are likely suspicious. How this physical location is determined can vary, i.e. from just looking at the IP address to using the GPS of a smartphone. In order to reduce false positives when traveling one might also track recent activity to find out if the person currently travels.
Use of a VPN from some well-known VPN provider (can in many cases be detected by IP address) itself might not be suspicious, since it is not that uncommon. But it might be suspicious if the user has never used a VPN before or if suddenly a different VPN provider is used.
Use of a private VPN with a VPN exit "at home" (like offered by some routers) is likely not suspicious, both since the  IP-based location did not change but also because it is unlikely that the account is compromised in this case.

How much these heuristics are used in the first place might also depend on how well the account is protected. All heuristics have false positives which might tag something as suspicious even if it is just uncommon but innocent. The same way these heuristics have false negatives which might lead to suspicious activity not being detected. Less false negatives (wanted) usually lead to more false positives (not wanted) so the right balance is needed. Since a simple password based authentication is easier to compromise with credential phishing or keyloggers than a multi factor authentication, it might make sense to temporarily lock a weakly protected account on potentially suspicious activity while keeping a MFA protected account accessible.


Fingerprints of a RSA keys - GitHub not matching? I am wondering how those RSA fingerprints work. I have a GitHub account and created an RSA key pair to set up an ssh connection. Then followed the instruction...
First time I connect to my GitHub it gives me and RSA fingerprint SHA256:nThbkt6JwfF............
Ok, I am doing this for the learning process so I google what this means and try to generate a fingerprint from my RSA key - and it should match to the one from my GitHub account, right?
But it does not, what I get after using :
ssh-keygen -lf ~/.ssh/id_rsa  is not the same its like
SHA256: t6Rjff8djE........
Am I doing something wrong here in my approach to see if the fingerprint given is legitimate?

SSH requires two public-private keypairs. One on server side and one on the client side. In simple therms, when you want to encrypt something going to the server you are using server public key (it is decrypted on the server side using server private key). When server sends something to you it is using your public key (you are decrypting it using your private key stored on your machine).
Server is presenting its fingerprint (not the fingerprint of your certificate). So you can validate the public key presented by the server. Usually fingerprints are cached so the ssh will not prompt you next time.
When you configure your public key on the github, you are basically telling github what key you'll be using for authentication and key exchange. Github “trust” that this key is coming from you cause you are authenticating yourself with your password to upload it. In theory only you can decrypt your data cause only you have the corresponding private key. By uploading the key you're establishing a trust relationship between your machine and the GitHub server.
If the fingerprint of the key that you have uploaded is different than the fingerprint of the key on your machine is most probably caused by:

Fingerprinting wrong keys.
Original key was overwritten by running generation command multiple times.
Confusing fingerprint coming from the server (server fingerprint) with your own certificate fingerprint.


Is there any way to tell if CCTV is on or not? Is there any way that an attacker can identify if a CCTV camera is on/operational without direct physical access to the cable/camera?

If it is on, is there any way an attacker can tell if its being viewed/recorded or not with access to the camera/cables but no access to the recording/viewing rooms?

This would really depend on whether you care or not of being detected in the process and how much you're willing to invest into equipment, but sure. Provided there aren't some other, obvious signs the camera is on, such as the pan and tilt motors working

Low-tech approach: This is actually really similar to how doctors test patients for involuntary reflex reaction with a light source directed in patients' eyes and observing dilation (or lack thereof) of their pupils.Most well designed CCTV cameras would have what is called an Auto Iris (AI). Basically an automatic method of varying the size of a lens aperture, to allow the correct amount of light to fall on the imaging device. The lens would include a tiny motor and an amplifier, which are used to maintain a desired voltage video signal as produced by varying levels of light falling on its image sensor.By changing the level of light this camera's AI sensor receives, you could visually inspect the camera's iris movement even from an angle it can not record you (depending on its depth of field), or even audibly inspect the presence of such AI motor. Since these would be precision step (or stepper) motors, you would hear either a distinct buzz of it rotating, or the faint click when it's adjusted its step. Beware though, some ultra silent stepper motors have been developed already, tho I have yet to see CCTV cameras actually using them.Similar testing could be applied to other camera's components (e.g. auto-focus), with varying degree of how stealthy the tester could remain during this testing.
High-tech approach: This is easy and rather obvious - electronic bug detectors are capable of detecting compromising emanations (basically EMI: RF -> microwave -> IR fields in their descending wavelength / increasing frequency). Obviously they would all have some way of telling you which direction the compromising emanations are originating from, and most also at what specific frequencies and their exact strength.Such devices are getting fairly cheap nowadays, and you can buy pretty decently capable ones off local resellers for up to a few hundred dollars, or even a second-hand one for roughly a quarter of that price off online resellers. Since the choice is fairly good, I won't give you any links to specific products, not wanting to endorse any specific manufacturer.This detection would work both for wired, as well as wireless CCTV cameras. Wired CCTV systems would produce what is called a ballanced signal when on, which is a video signal that has been converted to enable it to be transmitted along 'twisted pair' cables, while the wireless (RF, or less common IR that require direct line of sight from the camera to the receiver) CCTV systems are even more apparent and would transmit higher energy radiation in their specified range (on top of compromising emanations from its internal circuitry).

Now, the other part of your question - detecting, if the video/audio feed is actually being recorded - is a bit more tricky to answer and would greatly depend on what system we're talking of here:

Analogue recording systems (rare nowadays) would actually add a bit more latency to the EM field emanating closed-loop when switched on (producing feedback spike in sine wave oscillation), basically moving the signal termination point a bit further on the power line (or separate signal cable, if not combined). This might, or might not be detectable by your equipment. Mind you, I do mean here only the exact moment when the recording device is switched on or off, and you would have a lot harder time detecting which state it's on, if it's in continuous mode of operation. Knowing the system beforehand and actually measuring its signal levels when on/off would obviously help.
Digital CCTV systems are a fair bit trickier to detect, if they're actually recording or not. In fact, you wouldn't be able to tell the difference between merely a receiver being on, or the recording system also doing its job that's connected to the receiver. With a bit of luck, you'd be dealing with direct-controllable IP cameras that would have a variable bit-rate (VBR) A/V feed encoder chip. This change in required bit-rate can be detected by better electronic bug detectors, but knowing the change in detectable EMI for the exact CCTV system beforehand would be of great help. With CBR/ABR (constant or average bit-rate) encoders, you'd most probably be out of luck though.

Now, I didn't write anything about disabling them, since you're not really inquiring about that, but maybe just a quick note that it's actually getting easier the more advanced they get, and with most new ones all you need is a decent pocket/torch size green laser (532 nm) directed for a few seconds directly into their CCD/CMOS sensor. The higher their resolution, the faster they will give up, depending also on laser's Watt rating, how much light diffraction are we talking of due to lens elements arrangement, their focal point, e.t.c. On wireless systems, you could actually detect their sensor's death by observing a sudden drop in compromising emanations intensity (camera's onboard video compression would be at its best with all the images of some framerate being the same, thus lowering the wireless frequency transmissions, i.e. lowering bandwidth).

Just mind, that CCTV cameras might be a whole lot more than cameras only, and pack audible and/or activity (movement / proximity / pressure change / presence of other  compromising emanations / ...) detection sensors as well. And the most funny of all (to me, as I wouldn't really care of being detected or not) is being highly equipped for any eventuality, but then unwittingly manage to disturb some wildlife (bats, birds, rodents,...) with your presence, that would fright and trigger the CCTV system's response for you.