Is installing Debian package safe? If I understand correctly, the maintainer scripts in Debian packages are executed with root privileges.  I assume that this means that, contrary to my expectation, installing a malicious package can not only lead to compromising  the user that runs code in the package, but the whole system.

Question 0: Am I correct?

Question 1: Are there any ways to mitigate this threat? (For example, is there any tool that would install Debian packages in a chroot-like "sandbox" alerting the administrator if postinstall script attempts to use potentially problematic privileges.)

Question 2: What are the ways in which Debian team addresses this threat in the main repositories? Given the sheer number of people who contribute packages to those repositories, it must be a non-trivial task.

(Same questions apply to derivatives of Debian, such as Ubuntu. Information on how other distributions handle this issue is also welcome.)

Added on 27 July 2015: I can summarize the received answers can as follows:

0) Yes, it is a problem.

1) Read the code, and/or install software as user who intends to use it. For later, there is fakechroot tool that might ease the pain of installing manually.

2) There is no particular attention paid to this problem beyond normal screening of the Debian repositories by the many volunteers involved.

I will now accept WhiteWinterWolf's answer, but I remain interested in a good solution to this problem. Also, if other distributions handle this better/differently, it'd also be interesting.

Question 0: Am I correct?

Yes you are correct. Installing a package requires root privilege, so installing a malicious package means running malicious code as root.

Question 2: What are the ways in which Debian team addresses this threat in the main repositories?

First, you are recommended to use only Debian repository, and more precisely Debian stable repositories, this for two reasons:

The code from this repository has been screened by a lot of people before entering this stable branch which will by far limit the possibilities of a malicious application stepping through.
Then only security updates are provided, so future updates size are by far smaller than updates which would add dozens of shiny new features. Such modification being smaller, they are more easily screenable which, again, limits the possibility of anything malicious stepping through.

Then, once your root process is about to initiate the installation of the package, in order to ensure that this package is really the one provided by Debian team and has not been altered by a third party, each packages are cryptographically signed. Any change in the package will result in a bunch of warnings messages which will ask you to think twice before proceeding with this installation.

Question 1: Are there any ways to mitigate this threat?

Now for what concerns your side, it mainly depends on your actual needs and environment.

Of course as etherealflux mentioned in his comment any new installation on a production system should be carefully screened. You may want to manually unpack the package to check its content, you may want to install it in an isolated test environment to check its behaviour, etc.

However, there is also another solution, mainly addressing  your own comment "There is no reason that installing, for example, a tetris game on a communal machine should endanger accounts of users who do not play the said game.".

But for this, we need to step back a bit to understand what packages actually are.

In the early Unix/Linux days, there were no packages (or at least very few in the case of Linux): every one wanting to install an application should first download the source, then compile them. This made software installation and update take longer, but allowed each one to configure the software precisely how they wanted to.

Then packages came: pre-compiled software with most common settings for such system.

Here lies your issue with the Tetris game: these "most common settings" include, among over thing that the software will be installed system-wide, and this is this system-wide installation by default which is the reason why a user installing a Tetris could endanger the whole shared environment and all its users.

Software installation at the user level

As long as your /home partition (if it is a separate one) allows code execution (no noexec mount option in the /etc/fstab file), then your users are allowed to install their own software in their own home directory, without affecting the other user and without requiring root privileges.

However, such installation is not part of the "most common setting" mentioned above, therefore the packages do not offer this possibility. Your user therefore has to proceed as follows:

Download the Tetris game source code,
Read the INSTALL documentation file and check compilations options allowed by the configure script  (./configure --help), both provided with the source code. More specifically, they will need to set all directories to be under their home dir. For instance, the script could allow a --prefix parameter allowing to easily tell where the software will have to be installed, so you could for instance tell ./configure --prefix=/home/myuser/local. But other software may require different parameters to be set depending on their complexity and requirements. With a good and sane project, all this is clearly explained in the provided INSTALL file and configure online help and is easier than it may seem.
Afterwards, all it remains is to execute make, take a break, and once the compilation has ended make install (without sudoing to root!).

The only real issue in such process is if this software compilation requires dependencies not available on the system (this will result in an error message at the configure step, one of the roles of this script being to ensure that all dependencies required to compile and run the software are met). This becomes a recursive issue since you have the choice between installing a package to satisfy the dependency, on compile it at the user level and set the appropriate configure parameters / environment variable so the compilations tools and final binary will find all it needs.

But at last, your user will get a working Tetris fully installed on his account, without affecting the other user and without requiring any super-user privilege.


Best way to set up SSL certificates for consuming web service from Azure I need to purchase and install the correct Verisgin SSL certificate(s) (X.509) on Azure.  I have never done this before and would really appreciate some advice on how to go about it and what is considered best practice for production and testing environments.  I'l explain the scenario.

Our Site

Is hosted on Azure. We will have a development environment and a production environment running there (not sure how yet). It needs to consume an .asmx web service.

Third Part SSL Secured Web Service

We need to connect to this and they have given us a CA to install on our server.  I think we then need to give them our public certificate to install on their server.  They provide a test server that also requires this set up.  I have no influence over how they do things.

What I'd like advice on

I would like to run integration tests from our development server (or preferably my local machine, if possible to use the same certificate?) against their test server using our purchased SSL.  I would prefer not to have to publish to Azure at all during initial testing but don't see any other way without us purchasing multiple certificates, and then having to ask the third party to install all of them on their test server.

How should I be looking to develop and test in this situation with minimum hassle to third party?
Do I need multiple certificates for this from Verisign as it looks as if on certificate is for one domain only.
Does Azure see a testing server and Development environment as different domains as far as certificates are concerned?
Is Anything else that you think would help me here?

I'm sorry for the novice questions.  I have done research on this but I'm still confused and don't want to waste my client's money or set up something that's wrong and not testable.

I hope I have been clear and am very happy to elaborate if someone with experience of this is kind enough to help me.  I appreciate that I'm asking a lot of questions.

Thanks in advance

Standard DNS tables and Azure are pretty flexible when it comes to helping you test this. I'd recommend the following:

Register for a wildcard SSL certificate - this will let you apply the cert to subdomains as well. For help creating the cert check out http://www.andrewdenhertog.com/tips/creating-adding-ssl-certificates-azure/
If you want to test the cert, create a new A record in your DNS table for a "dev" subdomain and point it at your DEV machine's IP address (make sure you open up port 443 on your firewall)
Another way to test it is to create a staging version of your Azure website. Publish your site to this and then apply your cert just to this version. You can create a CNAME entry in your DNS to be http://staging.yoursite.com so that you don't interfere with production.
Lastly if your LIVE site doesn't have a cert installed, you should be right to install the cert anyway and manually navigate to https://... Your main traffic will continue to hit the http:// version until you add a rewrite to force https once you're happy with it


JohnTheRipper Advanced Mask I have problem to construct advanced mask to crack hash of 7zip file.
The password have 16 chars where are all lower, upper, decimal and !@#$%-_=+:

Main information is that any char can't duplicate and I want to know how add this to cracking rules. It will reduce time to brake the password.

Exactly don't know -1 value is correct, more precisely range [!@#$%-_=+:]

Command looks:

john --mask=?1 -1=?l?u?d[!@#$%-_=+:] -min-len=16 -max-len=16 test.ctx.hash

You'll need to repeat the '?1' 16 times - one for each position:

john --mask=?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1 -1=?l?u?d[!@#$%-_=+:] test.ctx.hash

This won't eliminate the duplicates, but I wouldn't worry about that; the keyspace is so large that eliminating those duplicates will have insignificant impact on the overall runtime.

More generally, the keyspace is so large that you will never actually crack such a password.


Where can emails be sniffed from? I understand that you should not send private information in emails due, in part, to the fact that this traffic is usually unencrypted and can therefore be sniffed while in transit.

Where would a person need to be in order to sniff this traffic?  I'm assuming that they either need to be on the same network as the sending or receiving end of the email.

Is this correct?  Could someone potentially find a way to sniff the traffic even if they are not on the same network as the sending/receiving end?

I'm assuming that they either need to be on the same network as the sending or receiving end of the email.

There are lot more possibilities:

In the sending or receiving network. This vector could be mostly eliminated when sending/receiving the mail with TLS, at least if the certificates are correctly validated (which is mostly the case in this step of delivery).
On any of the mail servers in between. Since the mail is delivered hop by hop it is available in clear on each of the hops, even if the transport is protected with TLS. This includes the receiving mail server, the final mail server which make the mail available to the recipient and any mail server on the path between.
In any position in the network between the sending and receiving mail server, where it is possible to spoof DNS. Since the path of the delivery is controlled by DNS MX records the attacker could divert the mail to its own system. TLS alone will not help here, but adding DNSSec will help. Unfortunately it is not much used yet which means that nobody will make sure that any answer is signed by DNSSec (too much could break).
In any position in the network between the sending and receiving mail server, where the attacker can sniff or even modify the traffic. Passive sniffing is enough if the transfer is not protected with TLS. In case of TLS the attacker could make sure that STARTTLS gets rejected and thus the mail gets transferred without TLS. Or it could do man in the middle for TLS, since certificates at this step of delivery are usually not properly validated (too much could break). Note that such a position could also be reached by diverting the routes, like in BGP spoofing.

Thus if you really need to protect the contents of the mail you need to use end-to-end encryption with S/MIME or PGP instead of no encryption or hop-by-hop encryption. This of course assumes that you have the correct key of the target, i.e. not spoofed and not just asking a PGP key server and fully trusting the response.


Is it common to be audited for security, but not be given access to the audit results? When does it make sense, or is it common to not be given access
to security audit resuts/reports when dealing with large companies
who use your software?
How can a case be made for the benefits of sharing documentation on
security gaps, and what are the risks of failing to disclose this
information?

Hypothetical Scenario:

  The company MediumSizedSoftwareCorp was recently approached by one
  of its customers, SuperGiantMegaCorp to conduct a security audit of
  MediumSizedSoftwareCorp's platform (which they use).

  The audit was conducted in relative secrecy by a security and
  compliance team at SuperGiantMegaCorp and managers at
  MediumSizedSoftwareCorp were informed that their software platform had "failed" the audit. Managers are both companies are in a tizzy because the security issues threaten to derail future contract growth.

  Engineers at MediumSizedSoftwareCorp desperately want to remedy the security
  issues, but SuperGiantMegaCorp will only discuss the vulnerabilities
  by phone, leaving out specifics and discussing only in vague, general
  terms. Compounding this is the fact that auditors at SuperGiantMegaCorp refuse to share detailed audit report documents because of the "sensitive" nature of the documents.

This scenario seems antithetical to closing gaps in security. Transparency and cooperation seem like better options, but how does one build an evidence-based case for this?

Indeed, the situation you describe does not lend itself to speedy resolution of any vulnerabilities found by the mega corp audit. However, beware that may not be the point. Even if the real purpose of the audit is to fix security flaws, there are some reasons that the mega corp can't share specifics.

What other purposes does a security audit have other than fixing security holes? Well, read your contract and think through everyone's motivations. As others have said there may be contractual or political motivations. Off the top of my head:

Mega Corp may want to break or renegotiate your contract, or a contract with someone else. They're using the audit as leverage.
Mega Corp is doing a risk assessment of their product, and they just want to understand what kind of risk your software poses to their business.
Mega Corp is following a rule or regulation that says they need to make regular audits and that's all they've decided to do.
Mega Corp doesn't want to start a paper trail that documents potentially damaging vulnerabilities, or they don't want the paper trail to leave their physical control.
They might be legally prohibited from (or legally concerned about) sharing information from a classified/controlled environment to an unclassified/uncontrolled environment.

They might feel they have legitimate security reasons for not sharing specific vulnerabilities as well.

They might not trust your company and giving you a list of specific test cases will tell you a lot about what kinds of issues they've had in the past, as well as issues they predict to be problems for them in the future.
They might not want you to just fix whatever bugs they found but instead do a more comprehensive review. If they tell you they can slip strings X, Y, and Z through your input validation then you'll be tempted to just fix those specific cases. If they just tell you that your input validation is a piece of crap and to fix it or else you'll lose your contract then your company is going to take a really careful look at the whole software from top to bottom.


Relationship between RSA, Diffie-Hellman Key Exchange, PKI and X.509? I am getting confused with RSA, Diffie-Hellman Key Exchange, PKI and X.509v3.

I took a look of RSA's mathematics algorithm, it seems like a encryption algorithm, right? Generating public key and private key, using for encryption and decryption...

Also, I took a look of Diffie-Hellman's mathematics algorithm, it seems just like a key exchange, right? Each side can calculate the same key by using some kinds of algorithm. It seems not a encryption, right?

I have also took a look of PKI, there are something new which is the CA and digital certificate. Public key and private key are also mentioned.

So, what is the relationship between these concepts? Are they 3 separated concepts? Or they will be used together in the reality?

Also, is X.509 the standard of PKI? So PKI itself is not a standard?

This is the questions that I have confused for a very long time. Thanks all of you.

RSA is two algorithms, one for asymmetric encryption, the other one for digital signatures. They use the same kind of keys, they share the same core operation, and they are both called "RSA".

Diffie-Hellman is a key exchange algorithm; you can view it as a kind of asymmetric encryption algorithm where you do not get to choose what you encrypt. This is fine for key exchange, where you just want to obtain an essentially random shared secret between two people. Note that most usages of RSA asymmetric encryption, in practice, are also key exchange, e.g. in SSL/TLS: the client generates a random value, encrypts it with the server's public key, and send it to the server.

PKI is a concept. It builds on the notion of certificate: a certificate is an assertion of key ownership. Basically, a certificate is an object that contains an identity (a name) and a public key, and the object is digitally signed (e.g. with RSA -- the signature algorithm -- or ECDSA). A certificate is validated by verifying this signature. The idea is that if I know the public key of whoever issued (signed) the certificate, then I can verify that signature, and thereby gain some confidence in the fact that the public key contained in the certificate really belongs to the entity designated by the identity contained in the certificate.

When you organize certificates in a way such that there is a strict hierarchy, where certificate issuers are called Certification Authorities and issue certificates to each other, with a handful of top-CA called "root CA", then that overall structure is called a Public Key Infrastructure, i.e. a PKI.

X.509 is a standard for the format and contents of certificates. X.509 is rather open about what signature algorithms will be used for signing certificates, but in practice, 99% of the time, it will be RSA.


Are there any known viruses/malware that can infect Ubuntu that come from the USB? I know that most viruses that can infect the OS from having an infected USB inserted into the PC are mostly Windows only, but is there any possibility that there is one that can affect Ubuntu as well?

Yes.

Search for "USB Rubber Ducky" or BadUSB.

The USB device introduces itself to the computer as a keyboard and can then installs malware.


How and why do people spam my website form? In have a web form on my website, and someone keeps sending annoying spam through it. I know Captcha can block this, but why do people spam my site - what's their benefit?

How do they access my web form? Is there any script?

And how can I identify who I'm up against?

They spam your (mine or everybody's) website because in the end it pays. Maybe because your visitors click on the URL, maybe because their own website gets a higher ranking on Google (because of many websites linking to theirs). It is not because it is your website, it is because they found a way to inject information easily (through a script or so).

Because their cost is extremely low (usually all systems they use are not owned by themselves, but compromised systems all around the world). They need only a handful of paying visitors in their own shop for maybe every 1000k+ spam messages they leave. Think about spam in global scale, not precisely your website. Yours just happens to be in their path.

For every more or less standard website (for example, based on phpBB, Joomla, Drupal, Scuttle, ...) if there are many installs on the Internet, it pays to develop a script to spam. Google will find the vulnerable sites for you. Browse through your webserver logs, and pay attention to referrers that mention Google. Study the query that got them to your website. You'll be surprised what search terms they've used to find your content.

The only reason why spam exists is because in the end it pays good money (at least for someone).


Encrypting files in a windows environment We have certain client data which must be encrypted at all times.  The part we have been struggling with is encrypting files on network shares.

Currently we have network folders encrypted using PGP Netshare.  This works pretty well for file encryption but it sucks for files which need to be accessed by two or more people simultaneously, i.e. Microsoft Access.  If two people access the file the file will become corrupt.

We have tried Microsoft EFS, which is pretty straight forward, but difficult to configure for multiple users.  You can't set multiple users to decrypt a file without explicitly adding their cert to the file though Windows Explorer (from what we have discovered).

Bitlocker was suggested as a clean way to encrypt files and configure across the enterprise.  From what I read it appears like it will work for us.  It states that the system drive needs to be encrypted as well and that is where issues come into play.  It is a lot of configuration to setup bitlocker properly and I am not sure if it is a good solution for what I need to do.

So I ask you, security specialists, what is the industry standard for securing, encrypting data files on a windows file server?

Ehmn, the 'industry standard' for client-side (laptop/desktop) and server-side (network share) workgroup file encryption in a Microsoft SMB environment is -- you're not going to like this -- don't do it. Seriously, very very few people do this, for many good reasons.

OK, you said "requirement", so the next best solution is Microsoft Encrypting File System together with Active Directory for management.

The good properties of EFS are:

The encryption is almost completely transparent to end users. EFS files are used just as plain un-encrypted files are; decryption permissions are inherited from the logged on Windows user account.
Pretty good performance, EFS is integrated with NTFS and decently fast.
Advanced management capabilities. Via Active Directory you can create multiple layers of admin accounts for unlocking files in an emergency; handle team / group / department permissions, etc.

Bad sides:

If you ever loose all keys, then you're in deep deep trouble.
Setting up a good, robust & safe EFS infrastructure for a company is a lot of work, and requires very careful risk assessment. You might start by reading this overview, and read the "Recovery" section twice.
A few applications, mostly client-server style apps which run on a desktop PC but use user credentials other than the logged in user, will fail to run. Or worse yet, run, but silently fail.
A few applications may have strange bugs. For example, with EFS my Google Chrome browser is frequently complaining about an unclean shutdown and looses its settings. Without EFS I do not have this issue.
EFS can be counter-intuitive. For example, the default behavior is that if you copy an EFS file to an unencrypted destination via common icon drag'n'drop, then the file is transparently de-crypted. But if you do the exact same via some command line tools, then the file remains encrypted. This has tricked more than one file backup, and caused data loss.

  You can't set multiple users to decrypt a file without explicitly adding their cert to the file though Windows Explorer (from what we have discovered)

The solution is Active Directory & Group Policies. Active Directory can be daunting. No offense intended, but if this is new to you, then maybe you should find an experienced Microsoft sysadmin to lend a hand with the design.

Regarding Truecrypt: Personally, I would never use Truecrypt for this. I love Truecrypt, and use it every day on my own PC's. But at heart it is a single-computer solution, with no group management / multi-PC deployment tools / multi-layered key management capabilities. It's not the right tool for workgroups / companies, other than perhaps full-disk laptop harddisk encryption (and even there, Bitkeeper is stronger on management capabilities).


How does ssl prevent MITM attacks My understanding of how it works :

A victim asks for the public key of a server.
The attacker just forwards this request.
The server now responds with a certificate which contains the Public key.
The attacker modifies this to its own public key and sends it to the victim.

Something happens now that I don't understand:

The browser has public keys of all major certificate authorities.
It uses this public key to verify that the web server's certificate was signed by the trusted CA? How?
An attacker can fake this request just as it did with the server?
Apparently the Browser checks if the certificate is valid?
Now how does it go by doing this.
The attacker can fake data for this so that the Browser check still result to a True.

If the server's privatekey/publickey changes how would a victims browser know that this is changed?

Then the browser generates a shared symmetric key and encrypts it with the attackers key.
Therefore the attacker can decrypt it. Get the key. Encrypt it with the servers key and send it off to the server.

I'm trying not to go into the general workings of public key cryptography as this is described very well at many places:

https://en.wikipedia.org/wiki/Public-key_cryptography
https://en.wikipedia.org/wiki/Digital_signature

I suspect the first missing point in your line of thought is that the browser doesn't have to communicate with anybody (putting aside the problem of revocation lists and time sync) to verify a certificate as long as it has the certificate and the public keys of the trusted CAs - this is why public-key crypto is great! It just has to calculate hash of the contents of the certificate and decrypt the signature using the CAs public key: if the decrypted value and the calculated hash match, the certificate is trusted (this is a highly simplified version of the operation though).

At this point the attacker faces the following hard problems:

He can't intercept/modify traffic secured via the servers keypair, because he doesn't know the servers private key.
He can't replace the servers public key contained in the certificate, because this will break the signature.
He can't just sign a certificate containing his public key because the browser doesn't know the public part of his signing key (the attacker is not trusted by the browser).
We hope that the attacker couldn't obtain a CA key.

If the servers public key changes a new certificate with the new public key has to be created - the client will receive a different certificate and that's basically it.


How is a "commonly used password" determined? When I try to create a virtual machine on Azure, and use the password P@ssw0rd I get an error message saying The password you provided is too common.

Now, from my basic understanding, a provider should be unable to determine the most common password since the hashes will be different even if the password is the same due to salting.

So, how is such a system implemented? I'm assuming Azure is not storing plaintext passwords?

One option is to use a list of well known weak passwords. Those lists are available from many breaches of the past in the internet. For example, there RockYou list contains the passwords of more 32 million accounts. One method would be to compare your password with the (let's say) 1000 most common passwords. If there exists one password which is similar to your password then your password is considered to be weak. Similarity can be computed with the edit distance (e.g. Levinshtein distance) which is the minimum number of insertions/deletions/substitutions to transform one string (i.e. in this case the password) into the other one.

Another solution is to use an approach that is described in the paper "Adaptive Password-Strength Meters from Markov Models" (http://blogs.ubc.ca/computersecurity/files/2012/01/06_3.pdf). Here only n-grams of all passwords are stored and counted to create Markov Models from the passwords. These Markov Models are used to compute the strength of passwords. The advantage of this approach is that the Markov Model adapts to the password distribution of the specific site. For example, the RockYou users often tend to use passwords which contain the string "rockyou" in some form. Therefore, for RockYou this passwords similar to this one should considered to be weak. For other web sites there are other site specific weak passwords.


Complex password rules - is there any sense? Let us assume that our system is well designed and it limits the amount of login errors so that brute force attach on the user interface is not possible. Say after 5 failed logins for an account the account is disabled for 30 mins and IP blocked if you try too many different usernames.

Now, is it at all a realistic risk that someone would be able to guess someone else's password?

It is not the user's task to prevent the hashed passwords from leaking, so don't start with 'must have entropy, so that password hash is hard to break'. If an attacker can get the password hashes to their hands, they for sure can read everything and do anything else in the system as well.

***** <--- unmasked, this a very common word, include it in your answer, if you think more entropy is needed. You have 5 guesses.

Two points to note:

It is good practice to assume that other security steps have failed. You can' say that insecure passwords should be allowed because sites shouldn't allow details to leak, or that you should assume that there are brute force protections in place. Password requirements require users to deviate from established behavior and create passwords which are further towards the edges of the bell curve of frequency. The less common the password, the harder it is to break in a dictionary attack. Increasing entropy fends off brute force.
Using the argument that "I can make a word that you cannot guess, therefore the general rule should be to allow everyone to make their own free passwords" is a fallacy. Most people do not make passwords assuming adversarial intent. They make passwords based on what they can remember, and security is a secondary concern. Password requirements force the consideration of security, or force them not to use the frequent offenders of password lists.

Password rules are one level of multiple levels intended to keep people secure, under the assumption that others fail/are not followed, the more of these we have, the more likely we'll actually make enough work to matter.

Now, the relative benefit of password complexity rules in comparison to other routes of similar effectiveness is another question entirely, but the question of whether they are better than no requirements, then the answer is yes.


Was coerced into setting up 2 Google Phone Accounts and don't know how to delete them I received a text after posting on Craigslist and putting in my iphone number for texting.  The text said "Hi i am Jacqueline..wanna buy your Wooden Organizer - $40.  Urgently.  Can I call you now?"  I said yes.  They said they only had a Google phone so can they call me now.  I said yes.  The next text said to please press [2 digit number they gave me] when receiving my call to connect with me.  I did so and the recording said "Thank you for setting up a Google Account."  I hung up and received another text saying the person made a mistake and was sorry and to please press [a different 2 digit number] when he/she called again and there would not be a problem.  I did so and received the same outgoing message.  Shocked, I hung up and realized I'd been scammed.

I blocked the number from my iphone and deleted the message text after taking a photo of it.  I'm afraid someone is going to make extraordinary expensive phone calls all over the world with these new Google Accounts I've set up.  I don't know what to do or how to delete these phone accounts and I can't seem to find out how.  Every time i try to google "How do I delete only a "google phone account" [not a google account] they only tell me how to delete my gmail accounts.  Help!

Ok, so firstly we need to understand, what they are after is your number so they can use it for google voice calls and mail most likely. You did not create two voice accounts, what you did was attempt to link your phone number to someone else's voice account twice. What i think happened here is that the first time they messed something up or google got in their way, so they opted to try a second time. They may or may not have gotten it the second time we are not sure.

This scam will almost always appear in the form:

I want to buy your item from [marketplace]
I cant wait and must call you now
I need you to input 2 digits because im using X

X being conference calling, google voice, or any other reason to input a code to connect to somone. If you input the code you linked your phone to their google voice account and they can do things on your behalf.

The solution here is to create your own google voice account and link your number to that account to stop them from being able to use it any further, since you control the phone you are the only one with the ability to do this. i.e. they cannot get it back without getting you to re-link to their account.

First go to Google Voice and start the process. Select your device:

Then you will be brought to a page with further instructions. Follow them. Eventually you will be asked perhaps to login to an existing google account, do so, or create one if you don't have one.

Once you are ready to link your number you should be able to go to your google account, get into your voice account and select the following:

At this point it will ask you to which number you wish the account to be linked. Type in your scammed number. You will get a call from the exact same number (which is, 202-455-8888, I believe) you got before asking for the exact same kind of 2 digit code, which i assume will be sent to your email or via text, or they'll give it to you over the phone and you'll input it on the site. Do that.

You may also be able to see here if you were too late in avoiding their use, but im not sure, as i don't know if account transfers preserve history.

However, any previous links to your number at this point should be unauthorized for use.

At this point it may ask you to port your number, do not do so. Porting will issue a stop on your current phone contract, not something you may want, you will create a new phone number to use with google voice.

Use the google voice number for online selling in the future (might as well), this has the benefit of not giving away your real number to anyone while selling things.


What is Credential forwarding attack? What is credential forwarding attack? Does this happen only when the client connects to two servers with same credentials?

Generally, and from what I've personally encountered in the wild / in my job, a "Credential Forwarding Attack" is form of attack that occurs when an end user attempts to connect to a legitimate service / website, but instead connects to a site owned by an attacker. The user then enters their valid credentials into the fake website, which is then both stored by the attack for future impersonation of the end user, and then "forwarded" to the real website so that the end user is able to access the website so as to not raise suspicion from the end user.

For example, say I own www.bankofammerica.com (note the typo), and I send you some phishing email asking you to review potentially unwanted purchases from your account. You click on my legitimate looking link, enter your info into my fraudulent "Bank of America" homepage and login panel, while my sites scripting forwards that info into a real BoA login in the background. Now you click "login" and I get your online banking creds, and you get forwarded to the real Bank Of America page, none the wiser.


What is the heapspray technique and how to use it as reliably as possible? Can somebody explain the different steps to produce a heapspray attack (what are the needed vulnerabilities in the targeted software, what are the limitations of such technique, how to proceed, ...) and how to render it as reliable as possible ?

Peter(corelanc0d3r) - Corelan team has one of the best Buffer Overflow tutorials on the internet


File transfer secure from a network security perspective Let's assume a simple network with a (Windows) server and a (Windows) workstation. Turns out the question of how to securely transfer files between the two isn't obvious considering:

I define secure in this context as preventing an attacker with control of any of the two devices to propagate his control to the second. Confidentiality and integrity of the data transmitted is secondary.
We want to set up a strict filtering between the two devices, using a L4 firewall. By strict I mean that we want to prevent any other use than file transfer, enforced by the firewall. Thinks of it as if I had only a firewall between 2 companies, and I was responsible for the security of the link between the two. Except, a hacker has control of one of the two companies, and try to get a hold on the second. Now, I can enforce the protocol used as the other company will comply and limit the use of the network ports that will be opened to only the agreed protocol, so that for example it will only use a HTTPS client to connect to port 443.
The protocol would be better based on open standards, and not have any internet dependency; also, bonus points if the solution has available implementation on Windows.
I am not considering the risk of vulnerability in either the client or the server.

2. prevents us from using a few classical protocols such as SMB, as this protocol is not dedicated to be a file transfer protocol but also resource sharing, control, etc. It also prevents us from using SFTP/SCP/rsync over SSH, as these are encapsulated over SSH, and we would not be able to distinguish between the two on a network level. Also, FTPS is awful in terms of firewall opening requests as it takes all the firewall unfriendliness of FTP.

I was thinking about a HTTPS server, because we could create a server that is purpose-specific so propagation of a threat would be made harder. But I would like the client to be able to remove files as well so some logic will be required and a specific app will probably need to be maintained. Would WebDAV over SSL with Digest authentication match the security requirements?

I am starting to feel like there is no easy answer except saying: we need to limit the emphasis on the network security, as there is no protocol that would allow us to ensure the level of security we want without imposing security requirements on the machines, and for example making sure a SSH server is properly configured to only allow SFTP. This is a shame as the original question is pretty simple.

From an L4 Firewall perspective, FTPS, HTTPS, and WebDAVS are indistinguishable from each other; SSH, SFTP, SCP, and RScync+SSH are also indistinguishable from each other. Additionally, from an L4 Firewall perspective, the TLS protocols are essentially the same as SSH based protocols, they're both tunneling protocol that can carry anything you put into them. In other words, yes, L4 Firewall is the wrong tool for the job.

What I would do if I were in your situation is to run a git server, over https, using Git SmartHttp/git-http-backend protocol. It ticks all the boxes:

Open protocol, open source implementation
It keeps history. You can choose to allow actual deletion, by allowing force push, or to disable force push and thus require explicit consent from both sides to actually delete from the commit history
Efficient transfer if most updates are diffable, and efficient enough even if the files are always completely different
Secured with TLS, and as it runs over HTTPS, and you can reverse proxy it with a webserver (e.g. Apache) if you want to. You can add any authentication you want that can be done over HTTPS using the webserver.
You can write a pre-receive or post-receive hooks to add any custom checking and additional behavior.

My second choices would be git over ssh, then rsync over ssh.

  for example making sure a SSH server is properly configured to only allow SFTP.

This may be easier than you think. There are a number of FTP server software that only supports SFTP without SSH shell support, so you'd reduce the chance of misconfiguring them.


Can my isp see what I legitimately download? I can't seem to find the answer for this question. Can my ISP know what I download legitimately - in other words, NOT p2p, NOT torrent based, nor anything else that could be shady.

If I go on https://www.example.com and I decided to download a PDF they offer,
or a tutorial video, or even an audio sample of theirs, can my ISP
know what it is I download?
And just as importantly, if I decide to save the files and proceed to email them to myself: Can my ISP know what I
download, once I download them from my email?

I am not asking if they know if I download something (I assume they would know), but rather what it is I download. Again, I am referring to legitimate files. I don't like the idea of my ISP knowing more about me beyond what they already know. After all, anything related to schooling, medical things etc., my business. Not theirs.

The reason it's hard to find a quick and easy answer to your question is that there really isn't one.  The closest thing to a quick and easy answer that is right is:

  Your ISP can see every byte of data you transmit on the internet, and every byte any server sends to you across the internet.

They have the physical wires you're sending bits over.  They not only can read this data, they are obliged to read it, in a sense, because they need to route it to the right places.

However, what that doesn't account for is the readability of those bits.  Some protocols, like http, send everything "in the clear," meaning anyone who can read the data on the wire can get access to everything you transmitted.  Other protocols, like https, encrypt the data so that the ISP can see bits were transferred, but they can't glean any meaning out of the data.

This is all very protocol specific, so there is no one answer.  For example, with HTTPS, the ISP can know the IP address of the server you are talking to (because it has to be sent "in the clear" for the internet to work), but they don't get to know the hostname.  In most cases, they can do a reverse IP lookup and figure out the host name, but a single server may serve many host names.  For all we know, the servers that service www.google.com also respond to https queries where the host name is yahoo.com, and provide a different (secret) API to people to access it that way.  All the ISP knows is that you accessed 216.58.219.14.

Digging deeper requires a very careful threat model.  If your adversaries are Three Letter Agencies or major nations, you may find that you leak information in timing or file sizes, and they may be able to do something with that.  Regardless, the amount of information that can be gathered is 100% dependent on the protocol you are using.

As for your email, the answer is "it depends on how you access your email."  Email goes over different protocols.  GMail, for instance, goes over https.  Many ISP provided emails use POP.  Their behaviors are very different.


Hacker used my account to place an order, but not my credit card. Why? This scam involves my HomeDepot.com account. For those not in the US, Home Depot is a chain of very large home improvement / DIY stores.

Background / how I knew my account was compromised:

Yesterday I received 3 emails from Home Depot, followed by roughly 100 spam emails that all made it through the hotmail spam filter.
The 3 emails from Home Depot were:

Shipping address change
Credit card added
Order confirmation (about $1000 worth of power tools)

I did not have a credit card of mine on file. The credit card added was not mine. The shipping address for the order was a residential address about 10 miles from my address (same zip code).

I contacted Home Depot using the customer service number on their site and explained I had not placed the order. The rep said she thought it came about through someone placing the order over the phone, giving an email address close to mine and a Home Depot rep entering that person's information into my account. She said she would cancel the order and insisted my account had not been compromised.

At this point I did not make the connection between the deluge of spam mails and the Home Depot order so I considered her explanation plausible. I deleted the address and credit card from my account.

Today the same thing happened again. Another 3 emails from Home Depot (address change, credit card added, order placed, $1000 power tools) followed by another 100 spam emails. This made me (finally) realize that my account had indeed been compromised.

This time I changed my password and enabled 2FA authentication. I contacted Home Depot again and the order was canceled (they have a very inane system where the customer cannot cancel an order from their website, they have to cancel it).

Some things to note:

Shipping address for second order was a different address, some 20 miles from my location, different zip code but fairly close
Credit card used was the same as for the first order, or at least the last 4 digits are the same. I cannot see the full credit card number, just that it was a Mastercard and the last 4 digits

Now to my question:

What is the endgame for this scam? The credit card used was not mine. Why use my account to place an order instead of creating a new account? I understand the deluge of spam emails is to try to hide the order confirmation / address change emails, but why? Why not just create a new account at Home Depot, which is free, and place the order from there?

I do not believe the residential addresses used are those of parties involved in the scam / theft. I'm guessing part of the scam is to contact the shipper once the order ships and divert the shipment to either a Home Depot store for pickup, or to a shipping center for pickup.

But I do not understand why bother to do all this through my account

This is my first time hearing about this kind of "scam", so I am guessing, but I'm pretty sure I can tell you the answer.  The key detail is here:

  Order confirmation (about $1000 worth of power tools)

When I hear that I immediately conclude that this order was placed with a stolen credit card.

Anecdotally, I used to manage an eCommerce site for a very small (3 store) chain of hardware stores.  They had frequent problems with people using their eCommerce site to purchase things with stolen credit cards, and the chargeback fees from their processor when the fraud was reported were painfully high.  This caused them to spend time manually verifying any potential fraud orders.  Fortunately, fraud orders were fairly obvious: they always involved large numbers of power tools.  Fraudsters would buy power tools for the same reason they buy phones/laptops with stolen credit cards: they are easy to resell for near retail.

Initially the company I worked with would look at the shipping address as one factor to determine the odds of fraud, but that eventually became worthless: as you mentioned, fraudsters learned to change the shipping destination en-route (UPS supports this with a myUPS account, for instance).

Therefore I suspect that the combination of a local shipping address and using your already established account had the same purpose: attempts to minimize red flags and skirt past any potential fraud screening on Home Depot's side.  I would guess that the fraudsters are working under the assumption that Home Depot will look less carefully at orders from established accounts than from new accounts or anonymous orders.  I'm sure that Home Depot does plenty of their own fraud screening (probably automatic rather than manual), so the fraudsters may even be correct.

Also, I agree with your assessment that the spam was meant to hide the order confirmation from you.

In short, your account is being used as a patsy to use stolen credit cards to place fraudulent orders.  Whether or not Home Depot might try to hold you responsible for the order when the credit card is discovered to be stolen is unclear to me (probably not), nor does the fraudster care (IMO).  I suspect the use of your account was all about trying to minimize red flags on the order, rather than trying to hide their own identity or shift blame (they could have just as easily placed an anonymous order for that).

Regardless, proactively notifying Home Depot about the fraud order was obviously the right call: then there is certainly no risk of them blaming you.  Moreover, it saves them a bunch of money.  It's a shame that they made it so hard for you to do that for them.


Why is DARPA interested in secure messaging platform using blockchain technology? DARPA (US Defense Advanced Research Projects Agency) has released a Request for Proposal for a Secure Messaging Platform using a blockchain framework.

The following is the Objective paragraph from DARPA's call for proposal:

  OBJECTIVE: Create a secure messaging and transaction platform that separates the message creation, from the transfer (transport) and reception of the message using a decentralized messaging backbone to allow anyone anywhere the ability to send a secure message or conduct other transactions across multiple channels traceable in a decentralized ledger.

The request for proposal is available in full, here:
DARPA Call for Proposal for Secure Messaging Platform.

Why are contemporary secure messaging platforms like TextSecure, Cryptocat, XMPP/OTR, Bitmessaging and so many more NOT enough?

What do these contemporary solutions lack, as the Secure Messaging Scorecard suggests many applications have all these features?

What does blockchain provide when it comes to Secure Messaging and why it is necessary?

In particular, this paragraph of the proposal is not making sense to me

The messaging platform would act as the transport for a cyptographically sound record of all transactions whether they be MIPRs, contracts, troop movements or intelligence. Troops on the ground in denied communications environments would have a way to securely communicate back to HQ and DoD back office executives could rest assured that their logistics system is efficient, timely and safe from hackers. The benefits are broad and could even be applied to domains such as space. With crowded skies it’s important to maintain situational awareness of all satellites and those concerned with space situational awareness/telemetry or air traffic control could instantly share data between nations using a separate but equivalent ledger implementation thus removing questions as to the authenticity and integrity of the data.

What does transport mean here?
How does blockchain help troops communicate in denied communication environment help?
I am also not clear about the argument on situational awareness of satellites and how does blockchain enable sharing data between nations.

Simple answers would really help me and others like me. Thanks

I see your question as having two parts:

Why blockchain?

According to ZDNet's summary of the request, the preference for a decentralised blockchain solution is rooted in an interest in moving away from legacy centralised architectures, which DARPA describes as "expensive, inefficient, brittle and subject to cyber attack" at the given link.

Why not an existing solution?

From my view, DARPA's request for proposal is justified before even assessing the advantages of using a blockchain solution in particular.

After reading the summary by ZDNet, two reasons come to mind:

Specialised requirements: The alternatives you list are for text (and basic attachments) only. By comparison, the linked article refers to planned use for Military Interdepartmental Purchase Requests (MIPR), described here in Oracle documentation. Verging towards a procurement solution, this requirement alone is beyond the capability of what you have listed. Also, without significant redesign, those solutions would not be capable of catering to military user groups and access levels.
Dependency on third parties: More generally, it makes sense for any defense organisation to own the lifecycle of such a critical platform. Hypothetically, if the listed solutions did meet DARPA's requirements, to rely on an existing third-party solution would introduce unnecessary risk (e.g. non-DoD users on the platform, limited or no authority over design decisions, existing solution architecture being unlikely to meet defense standards). Although it is unfeasible to reinvent every technical solution in-house, in this example, little would be saved by relying on the listed alternatives.


User agent information from HTTPS flow We are categorizing the network traffic, like determining if it is Facebook, Yahoo etc...

Now I have been asked also separate mobile devices (like iPad, Nexus, iPhone).
It is easy to do that in HTTP with user agent information.

But I also need to consider HTTPS protocol. Is there any way I get any information about a user device in "client hello" or "certificate" messages?

Provided they're not using something like VPN or a Proxy you should be able to check a few things with an app like WireShark:

DNS requests for different websites (before the TLS or HTTPS devices will typically look-up the server). Eg. Facebook is using Akamai so if you can capture a DNS packet bound for fb.*\.akamai\.net that will give you both IPs (and the client MAC address). Then you can track the traffic from that IP through the session.
IP Reverse Look-up (You can check an outside service's IP registrant at a directory like ARIN) - whois -h whois.arin.net 8.8.8.8
You can look-up the device manufacturer via MAC Address
Like Manishearth was saying, you can try to catch a user agent from web browsing on the same IP during that same session, then marry the user_agent to the MAC Address.


How can a gmail recipient open email in two different countries, at the same time? I sent an email to person in Russia, and tracked it with Right Inbox, when the email is opened I get notified.  The problem is I get 2 different IP addresses, one in Russia, and one in the US, both opening the email at the same time?

This usually occurs when sending email via gmail to a gmail recipient.

How can a gmail recipient open email in two different countries, at the same time?

This is usually due to caching proxies being employed either on the recipient end by its ISP or the corporation your recipient is employed at, or by some VPN providers (if that's how the email was accessed), all either trying to save on bandwidth requirements, or otherwise control access to contents.

There are many such products available and solve various aspects of accessing contents on the Internet, so I won't be boring you with details. But they can be considered man in the middle type appliances, and go from mildly annoying to disturbingly alarming in ways they're employed. So even though I can't give any opinion whether this is due to something legit or illegit (your question is rather vague, so speculating on true reasons behind this happening is rather impossible), if such caching proxies are used, that would explain double recipients at the same time but in different geographic locations.

Best course of action would be to notify the intended recipient of your email through other channels, if you have reasons to suspect the latter to be the case and see what they make of it.


What are the real-world implications of duplicate SSH fingerprints across many devices? There was a recent post on the Shodan blog showing that certain SSH fingerprints are common across thousands of devices.

For example, this fingerprint is common across over 250,000 devices worldwide:

  dc:14:de:8e:d7:c1:15:43:23:82:25:81:d2:59:e8:c0

And this fingerprint is common across over 11,000 devices across the UK:

  7c:a8:25:21:13:a2:eb:00:a6:c1:76:ca:6b:48:6e:bf

This obviously presents issues in authenticating which device you are connecting to over SSH, but what other real-world implications are there in having a common fingerprint (and hence, common public key) across so many devices?

First it means that there is no way to authenticate a given machine using this key. Since they all share the same key, signed content can come from any of them.

Second, if the private key happens to be broken, you can impersonate 250'000 devices at once.


Why double tagging attack in VLAN is unidirectional (one way)? I was reading this article about VLAN double tagging security issues, and started to wonder two things:

1) Why double tagging is a one way attack?

2) How can the adversary make a bi-directional communication?

Assuming you read the article and understand how the attack works.

1) VLANs break up broadcast domains. So with default settings, hosts on two separate vlans such as vlan 1 and vlan 10 are not going to be able to communicate with each other unless a Layer 3 device gets involved. This is the reason the double tagging is needed, so it can HOP vlans and access a vlan it's not suppose to. When the target/victim tries to respond, they are not going to be able to "hop" back over to attackers vlan because when the victim responds it will just be a normal frame instead of a malformed frame like the attacker originally built.

Note: Trunk ports are members of all VLANs by default. Frames destined for the Native VLAN do not get retagged. This is what allowed the hidden vlan tag to get across and why the Native VLAN is a requirement of this attack. Since the target/victim is probably not going to reside on the Native VLAN, it won't be able to have this kind of communication which is what makes it uni-directional

2) With this attack, you can't. As an attacker you can malform that frame for VLAN-hopping but you can't cause the target/victim to send out malformed double-tagged frames. When the target/victim receives the frame, it is just going to look like a normal frame because the other headers were stripped by the previous switches.


do we need VPN for SaaS cloud applications? If we need to connect to the corporate network from home, we need to have the VPN connection. However, what if for accessing SaaS applications like Google Doc, Salesforce, etc, do we need still need the VPN connection?

I think the underneath question is what's the use cases to use VPN?

I think there is some confusion here. The point of a VPN is to bridge a device into a LAN, so that internal resources can be (securely) accessed from an external network.

While some companies market VPNs as a kind of security or privacy tool, this is not their intended use at all, and the security benefits are questionable - ultimately you're just sending your network traffic to someone else's LAN, where it gets routed out to their ISP and back to the internet. You can safely ignore these offerings for any corporate use-case.

I think the best way to answer your question is to ask you a different question - if the SaaS offerings are available over the internet (i.e. they're not on a private LAN), do you need a VPN to talk to them?


What risks do Cookieless sessions have?  What are the mitigations? I'm debating if I should support cookieless sessions in my web app.  It would look something like this:

http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx

Since the URL is never constant, I don't think it's possible for a CSRF attack to occur.  What other attacks am I openening myself up to?

... are there mitigations to those attacks?  For example, can I set an expire header (or similar) to prevent the URL from appearing in browser history?

The basics

First, I assume you understand the most basic session ID security right:

you are using an ID with sufficient entropy, and
you use transport level security (HTTPS).

Any approach to session ID (URL, cookies, whatever) that does not get those right is vulnerable, your question is specifically about ID in URL, so I will not discuss that further.

Web-browser leaks

The most obvious risk of ID leak is with the Referer HTTP header. The simple solution to this is either:

to forbid outgoing all links (<a href and others), all external embedded content (<img>, <object>...) and other external dependencies (<script>...), or
to change all outgoing links to go to an internal redirection page (which could be another security issue, depending on how you implement this).

Many Web application have zero outgoing links, and no content (esp. HTTP resources) from other users (which often has potential security/privacy issues, like Web bugs in emails).

This issue is usually described as a serious risk, but I disagree; if well understood it is easily managed.

User-behaviour related leaks

Voluntary sharing of URL with other users

Another practical issue is that users could fail to recognise the URL as the access key to the page, and share it with others, via email or in a forum. The risk is even higher if the document is public but the user might have some privileged access to it (like in SE), so sending the URL is the most obvious things to do to share a page with a friend.

When the page is by nature private and contains sensitive personal informations, such as the interface to manage your account, the risk is lower, but still exits.

I have personally witness more than one case of non-public URL being posted on a public forum, where the URL designates a web page random users could not ever legitimately access:

link apparently to a webmail: the link was not working, I presume because the session was cookies based and not URL based;
link to the configuration page of a modem-box in the administration Web application of the ISP; the administration application is on a public Web server and requires authentication (this allows ISP clients to view or change some of their account information from anywhere). Giving others access to this interface includes: giving bank account information, ability change account password, change account email contact address, buy optional features, terminate account ... or just click the "disconnect" button to terminate the session.

The issue I am pointing out here is not the web application design, but that the behaviour of a few uneducated users is to copy URL and post it even when the account manages some serious stuff (not just a lame forum account).

In the second example, it clearly shows that some user simply to not think about what they are doing: the shared URL was either useless for people willing to help, or a security risk. This is just simple logic, and zero technical knowledge was necessary to understand that: either an information is sufficient to access some other information, or it is not, so obviously this link was useless or a serious risk.

Usually when such URL is posted in a public place, some nice guy sees the URL, copies it and if the session is still valid, clicks "disconnect"; then he explains that serious issue to the user. Most people are honest, but there is a risk.

Sharing of screen shots (revealing URL)

Another risk is when users want to share some data shown on one administrative web page (and not their access to such page), so they make screen shots of an administrative web page, failing to realise that the cryptic information in the URL bar is a secret. Making the URL very long so that it is not visible on user screen lowers this risk.

This case is very different, as the sharing of information is voluntary but the fact is contains the URL is not realised by the user.

Technical and user issues

Some technical issues exist with ID in URL; other issues exist with ID in HTTP cookies. In both cases it is up to the developer to understand the issues and fix them.

A user expectations issue exists with the "secret in URL" approach. The issue is not that the user can see the secret information, it is the fact the URL bar does not usually contain a secret.

You could think of a social engineering attack were the user is convinced to install the (very nice) Firebug plug-in, then activate it, go to the cookie panel and copy session cookies from there. But even a user willing to do everything you tell him might not be able to correctly accomplish each of these steps!

Copying the content of the URL is not just very easy (downloading malware on the Web and installing is easy enough for many users too); the user is used to copy and send URL. Some more experienced user may have explained a beginner how to send a link to a news article. The beginner might assume he can do that on any website and any webapp (even if the more experienced user never told him anything like that).

The problem here is that you can review your webapp design, you can get help from security experts and pay them to do a complete analysis of your application (complete from design to every line of code), but you cannot do a security analysis of your users (unless this webapp is only intended for your highly qualified employees and security consultants).

Combination?

You could combine both ID in cookies and ID in URL, if:

both ID are different, independent cryptographic random numbers
and each ID contains sufficient entropy for secure protection if the other ID is leaked.


Which hash/encryption type is used by Kali Linux for /etc/shadow by default? I know that the /etc/shadow file hash follows this syntax:
$id$salt$encrypted

The $id identifies the algorithm being used, e.g.:

$0 - DES
$1 - MD5
$2a - Blowfish
$5 - SHA-256
$6 - SHA-512

Here is an entry of my shadow file:

root:$6$89Zi5dxn$RvKDsJQhBiX2K3CEVUE3nQxvdBV.3vDK4Jrn11xC8jO31c43VnZeTL1OGaJWfFkl9di8nfreAXFLreCuQDshf1:16234:0:99999:7:::

I'm running the most up-to-date Kali Linux version (for 2014), which is based on Debian "wheezy", which in turn uses SHA-512, hence $6.

The problem I am having is that I went to an online service, which calculates and "reverse-calculates" SHA hashes and input my password ("root") there. The hash they showed me did not match the hash in my /etc/shadow-file, and when I entered my hash from the file to search against their database, they claimed the format was invalid.

I know that using a salt would affect the hash in some way, but as far as I can tell, my hash does not use a salt, as it follows the format $id$hash, not $id$salt$hash.

As such, I would like to ask the following:

Why does my hash not look like a "normal" SHA-512 hash?
What kind of hash is this, if it is not "normal" SHA-512?
Can I recognize the type of hash by only looking at the $id?

The site you linked to calculates plain SHAs and outputs in hex, not salted SHAs with multiple rounds output in base64, so it's basically impossible to compare them.

In your shadow entry, splitting on $ you have 6, which is type SHA512, 89Zi5dxn, which is the salt, and then RvKDsJQhBiX2K3CEVUE3nQxvdBV.3vDK4Jrn11xC8jO31c43VnZeTL1OGaJWfFkl9di8nfreAXFLreCuQDshf1, which is a base64-encoded hash.

In addition to the salting, libc applies a number of rounds of the hash, defaulting to 5000.  If you want the details on how a crypt() style SHA512 is calculated, here's a link to the source: https://github.com/lattera/glibc/blob/master/crypt/sha512-crypt.c


How do I correctly check for a secure password? I'm making an open-source web app that has login stuff in it.

I want to check on the server if the password is 'secure' (at least 8 characters, etc.).

The thing is that I'm not sure if I need something more than check for:

at least 8 characters.
uses numbers/special characters.

If not mistaken, you are asking how strong the server password(s) should be. As said in the comments, you are the only one who can answer that.
Those pages should help you out:
SEC.SE
Wikipedia
Microsoft
Nist
Not in the question range
Your password(s) policies should meet the security requirements you have wisely established after assessed the risks. Here is a basic plain scheme :
        0 security           security requirements button        super secure
                 <------------------------[]----------------------->
user super friendly                                               Not user friendly at all

Here is the general idea : you have to define the security requirements button position. It's more or less a compromise between the ease of access and the security.


Is this sufficient to verify a website's domain? I'm building a browser extension that will run some javascript, which contains some sensitive information (essentially injecting authentication info). Therefore I want to make sure it only executes it when the browser is on my trusted domain (let's say www.trusted.com). My current check is something like this:

if (url.includes('https://www.trusted.com/')  || url.includes('https://trusted.com/')) {
    // do stuff
}

Where url is definitely the correct current URL, read straight from the browser. Is this a sufficient check? Why or why not? (If not, then how might I do it properly?)

Is this a sufficient check?

No, your check is flawed.

An attacker can bypass the validation via e.g.:

https://attacker.example/?https://www.trusted.com/

This URL resolves to the origin attacker.example, but satisfies url.includes('https://www.trusted.com/').

  If not, then how might I do it properly?

E.g. use URL.origin. If url is the URL string, you can do:

(new URL(url)).origin === "https://www.trusted.com"

In practice, this is also safe, but less expressive and easier to get wrong:

url.startsWith('https://www.trusted.com/')


Is Google identity sign in product HIPAA compliant? I want to use this product to save me a month of coding.
Looking for a product that

Password expiration
forgot password system
lock after x times of wrong password
Valid passwords rules (min 8 characters etc..)
Edit users and permissions interface
HIPAA compliance

I thought about Google sign in but I need it to be HIPAA compliant.
I've looked here but it states that only Gmail, Google Calendar, Google Drive Google Sites, and Google Apps Vault service are HIPAA compliant.

edit

Tried to find whether google fit is hipaa complaint because they use google sign in - they are not  :-( -> "Google does not intend uses of Google Fit to create obligations under the Health Insurance Portability and Accountability Act, as amended (“HIPAA”)" here

HIPAA compliance is a bit tricky because it relies on the ambiguous 'industry standard.'

In this particular case, I believe that you need an https:// sign-in service.  HIPAA compliance is typically satisfied by judicious use of cryptography and other standard security measures.


Is the option to jump to blanks in password fields a security risk? Using Ctrl + ← / →, it's a common behavior across different operating systems to jump from word to word (or from blank to blank) in text input fields.

Now I've discovered that this also applies on password fields in Internet Explorer 8 and 11 (I haven't tried it on other versions yet): the actual text is masked with bullet points, nevertheless I'm able to find blanks using the mentioned keyboard combination.

At least in Chrome 38, the combination only jumps between the beginning and the end of the whole text.

Why isn't this fixed in Internet Explorer?
Can this be considered as a security risk? It's only relevant if the password is stored; I guess, this opens more serious attack vectors using external tools, like reading the password from the password store, or using unmasking tools. Still, doing the word jumping, it's possible to get a quick idea of the password using Internet Explorer's built-in "features"
Is it possible to change the word delimiter (a whitespace?) at runtime? So could I change it to 'a', and jump to every 'a' using the arrow keys?
As mentioned in the comments, it's also possible to jump to special characters like $, although here the cursor would stop both before and after the character. Is the exact "jumping algorithm" documented anywhere?
Are there any other problems with the described behavior of Internet Explorer?

No that is not a security risk.

Having stored passwords in a browser is a security risk.  Letting an attacker access your computer between when you've typed in the password and before it is submitted is a security risk (and even after you've submitted it, you need to worry about theft of valid session cookies).  Being able to jump to blanks/special characters in a typed in password is not a risk.

After a password has been typed in the password field, its in the browsers DOM and only takes the least bit of effort to extract the full value out from it.  E.g., if you go to the developer's javascript console (e.g., in chrome/linux type Ctrl-Shift-J) and type in (you can skip the comment lines that begin with //):

var inputs = document.getElementsByTagName('input');
// find all <input> elements in the page

for ( var i = 0; i < inputs.length; i++) {
// loop through all <input> elements

    if (inputs[i].getAttribute('type') === 'password') {
    // find input elements with attribute type="password"

        console.log(inputs[i].value);
        // print the values of these password elements to the screen.
    }
}

It will print to the screen whatever text is typed into any password fields.  (This code is equivalent to the jQuery $('input[type=password]').value, which will work if the webpage has loaded jQuery).

You could just type the word javascript: in the location bar and then paste

var inputs=document.getElementsByTagName('input'); for( var i=0; i < inputs.length; i++ ) { if (inputs[i].getAttribute('type') === 'password') alert(inputs[i].value) }

into the location bar and whatever text is in any password field will be alerted to you.  (Note most browsers will remove the javascript: part if you try to paste the full URL, so you will have to type it.

javascript:var inputs=document.getElementsByTagName('input'); for( var i=0; i < inputs.length; i++ ) { if (inputs[i].getAttribute('type') === 'password') alert(inputs[i].value) }


Online brute force attack which will continue in background I don't have enough bandwidth for brute force dictionary attacks so  I'm searching for a website or a way that I can do brute force attacks as a background process even if I turn my internet connection off.

Also, I'm looking to see I can use hydra on an online terminal that will continue process in the background.

Is there any website or way I can do this?

Offering such a service to the public could be abused for illegal purposes. So you won't find anyone offering such a service for free to anonymous users.

When you are penetration-testing a system with permission of the owner and you explained the side-effects of such a test to the owner (a high-bandwidth online brute-force attack can cause a denial-of-service due to resource exhaustion), then you could rent a cloud server for that purpose.


Is reseeding OpenSSL CSPRNG necessary if using RAND_bytes? I read that cryprographic secure PRNG (CSPRNG) need a random seed to provide random output. Looking at OpenSSL that seems to be archived by RAND_poll() and random data is fetched with RAND_bytes(buf, length).

But I'm quite not sure if I get everything right that is stated in the documentation here. I know that RAND_bytes will call RAND_poll() itself if it was not called before at least once.

I also read (somewhere else) that a seed should not be reused for a CSPRNG. Now my question is: Does RAND_bytes reuse any seed? Do I have to manually reseed OpenSSL for distinct RAND_bytes calls by using RAND_bytes(buf, length) again and again if i do not want reuse the seed?

Or does RAND_bytes manage this by itself?

Does RAND_bytes reuse any seed?

Kindof.
Re-using a seed is bad, because it will give you the exact same random numbers again. OpenSSL doesn't do this. However, you're allowed to use the one seed obtained by the first RAND_poll as long as you want (which is not advisable) as the PRNG will generate a steady stream of (unpredictable) bytes based on this one seed and you will just be served "later" parts in the stream if you don't reseed.

You should re-seed the PRNG as often as possible if you have entropy rich data, but it will also work (quite securely) if you don't do this.

Final answer: RAND_bytes (kindof) manages this itself.


How big window is secure and practical with TOTP? We are using Time-based One-time Password Algorithm (Google Authenticator) in our system. Since we currently don't allow any time window and code validity is just 30 seconds, we are constantly having issues with time de-synchronization on devices, which generate TOTP codes. That means that users can't login because they enter codes which are either expired or ahead of time.

It seems like it's a general practice to allow "windows", so system would allow codes which are valid at a time, which is close to precise current time. The question is - how long such windows should be? Is there some industry-wide practice? I'm looking at a generally-accepted value, which is practical, given how precise the time usually is on most phones with Google Authenticator and also is secure-enough. Is it 1 or 5 minutes or something else?

There isn't an industry standard on this that I'm aware of. It's up to your implementation and expected desyncronization. A single minute may still have synchronization problems.

If you set it to 5 minutes (in each direction) that's a total of 20 valid OTPs at any given time (assuming a 30 second expiration). This means that a guess would have a 1 in 50000 chance of being correct, or averaging about 25000 trials before a success. It would be very easy to detect when someone is trying to guess. Because of this, as long as you have a proper password system with rate limiting, 5 minutes should work fine for your case.


Workflow for changes to source code How do you make sure that in your environment, you have proper controls of your source code. For example, before deployment of any application, there must be approval from the boss and other parties. Do you have some products or solutions you can recommend to make this automatic? I also understand that sometimes, audit need to see hard copies of change control process. So in your opinion, is it still better to use hard copy change control, ie using paper signature etc? thanks

So version control is your best friend. Git is a good solution, and it allows authors to "sign" their commits digitally with a pgp key. Using a branch->commit->merge-to-master workflow keeps the code rot down. Plus, the audit team can look at the git repository and see what happened every step of the way. I don't know how hard copy change control would fit in, seeing as you could replace it with PGP signatures (much harder to forge).


Why do some sites prevent users from reusing their old passwords? I have always wondered why it is that bad to reuse old passwords; it should not be the end of the world if we happen to use an old password that we previously used.

After all, I believe most of the time that we change our passwords isn't because of real threats (it will usually be because our internal paranoia). But while it is true that at some point, one of those threats will be real, and we will succeed in saving our accounts, is not likely that the hacker will store the unsuccessful password and try again.

But as I always say, companies don't bother thousands of users for no good reason, the pros are clearly outweighing the cons for them.

However, I am involuntarily covering important details with my fingers when I take this photo, anyone that have the complete picture mind to tell me what did I miss? (I have really large fingers.)

The first question is: why do some services require passwords to be periodically changed. The answer is "Risk Mitigation".

Corporate governance requires IT security policies to be defined in accordance to a risk management plan. One of the question that risk management plans ask is how can one mitigate a risk if it occurs. In the context of passwords, the question is how can we limit the damage of a password leak.

If the system administrator is aware of the leak then users can be notified and other steps can be taken. To reduce the damage cause by a password leak of which the administrator is not aware, the lifetime of passwords is limited so that any leaked password can be used only for a short period of time.

So services require periodic changing of passwords. The problem is that users really don't like changing their passwords. So what users used to do when forced to change their password was to change it twice - once to some temporary password and then a second time back to the original password. This of course nullifies the purpose of the policy to require passwords to be changed.

So the next thing administrators did was store the last two passwords and check that the new password is different than the previous two passwords. The wily users countered that by changing the password three times - two temporary passwords and back to the original password.

You might think that users wouldn't go to all that trouble just in order to not change passwords, but this is what actually happened. A administrator friend of mine once compared the hashed passwords in his system after a year and found that almost all passwords were the same - despite the fact that that password policy forced users to change passwords every three months.

So the administrators started storing the last 10 passwords. And the users countered by using a fixed password plus a single changing digit at the end for a cycle of 10 passwords. And thus we've reached the situation today where many systems store all previous passwords.

Having said all that, the real value of these policies is dubious. Human beings have a limited capacity for remembering passwords and if it's wasted on remembering these rapidly changing passwords it can't be used to keep different passwords on different sites (which is much more important).


How to correctly handle passwords for an Android app So, some background.  I am currently working on a social media app for Android.  We are programming it in Java, and are using OKHTTP3 for a connection to the PHP backend, which will handle updating MySQL Database and storage.

My question is this: How should I handle passwords?  Once the user enters their credentials into the login form, do I hash the password (we plan on using bcrypt) and then send them over the PHP backend for immediate storage?  Or does the PHP Backend need to do more security hashing or encryption?

The way I think it will be done right now is this: 1. User enters credentials for signup 2. Password is hashed 3. Credentials are sent to the server 4. Credentials are entered into MySQL - What should be done differently?  Is this fine?

Reading making an iPhone/Android app which sends a user password to my server, how to secure? didn't answer my question well enough.

You mis-understand the purpose of a hash.

A cryptographically secure hash is a one-way function, so that the original text (the password) cannot be determined except by brute force.

In your example, it is not necessary to find the original text. If the attacker steals the hash, then they can still sign in without knowing the original password, just by altering a copy of the app to use the stolen hash instead of generating a new one.

Your server should do the hashing internally, not the app. (client-side)

For passwords, you have to use a Slow Hash such as BCrypt, with a high work factor. This should take ~100ms on your target hardware (with appropriate DoS protection), knowing that an attacker's brute-forcing hardware will be much faster.

Keep in mind that weak passwords cannot be secured, no matter how slow your hash function is.

Also be sure that you use an HTTPS connection between the app and the server, as mobile users may use shared WiFi which could easily be used to spoof plain HTTP connections.


API security where the server is also client-side I have a desktop application which creates and stores a fair amount of data (mostly on its own, not through traditional user input); mostly statistical in nature.

Currently the data is mostly accessible only to other applications that I've written myself, and isn't exposed to the user other than through these applications.

I'm considering allowing third-party access to this data via a REST API or similar, but in this case the "server" would actually be running on the same machine as the client (or another machine in the same LAN, at most).

However since this access is intended to be monetised I want to have some kind of authentication to allow specific clients access to specific subsets of the data, rather than providing blanket permissions.

(So the goal is not user authentication, but client app authentication; in the human sense all the data is for one user, but should only be accessible through authorised apps.)

Obviously since everything is running client-side I've basically already lost (a sufficiently determined user wouldn't have any trouble extracting and spoofing credentials, and AFAIK it is literally impossible to prevent this) -- but what would be the best practices for providing a reasonable level of security against insufficiently determined users?

Most of the usual recommendations for REST API authentication (SSL, OAuth, etc) don't really seem applicable since they assume a separate and secure server.  (And SSL is mostly concerned with validating the server.)

You can utilize client certificates that are generated from an external source.

When a third party service is being setup, one of the steps should be contacting an authoritative server to see what permissions it should have and if the user has paid for the content feed. In that step you can also generate a client ssl certificate and sign it with an internal certificate authority. Then when a third party client connects to the API on the desktop, all it needs to do is present its certificate and the API can check the signing authorities hash to verify its authenticity and grant the permissions stated.

The function that verifies the certificate should be as close to native code as possible, as it's trivial to edit an interpreted file to always return true for a certificate check.


Honeypot for Linux user Let's consider the following scenario:
You have a web -facing server, which runs software e.g. apache2 on separate Linux user www-data. An attacker finds a vulnerability and gets a remote shell on your system with privileges of www-data user.

Is it possible to have honeypot on commands run by the www-data user? For example, let's assume that apache2 or any other process run by www-data, never runs ls command to list directory (it would most likely use other API provided by the system, rather than start new process parse output etc). Is it possible to set-up a honeypot on such command? For example, log the commands in sys.log, or add an entry to a database with only INSERT permission?

The command should still run normally on other users (or specified) accounts, without triggering the log event.

If such honeypot is possible, how could one be set up?
Is there any reasons why such honeypot is bad and should not be used?

It sounds like you want to have a custom shell environment for this one user. Replace bash with a custom variant that only allows certain commands and logs the other commands.

Kippo/Cowrie would be a good model for you to look at for creating something like this and all the challenges and limitations, as well. Kippo/Cowrie is for faking ssh shells.


Does it matter if an average person has email encryption or not? I was thinking about using a secure email service. So, I read about it. And it feels completely useless for me personally.

Almost everyone that I exchange emails with, don't use PGP or any kind of encryption. Most of them uses Gmail. So, me having PGP encryption doesn't matter. I will have to send/receive plain text emails with everyone.

I don't think average person will be able to learn to generate key and send an email. It's not as simple as using an encrypted chat app.

Encryption is one thing, authentication is the other thing. Encryption prevents somebody else except the intended receiver to read the e-mail. Authentication prevents somebody else from impersonating you.

In regular e-mails you use neither encryption nor authentication. This means that anybody can send you an e-mail claiming to be anybody they want. This introduces two problems:

A.) Somebody can see what you write
B.) Somebody else can claim to be somebody they are not

Now, you can argue that A.) isn't really that much of a big deal for your average person. So somebody else on the internet can read your e-mails. Not a big deal. However, B.) is much a bigger deal even for an average person.

Somebody can send a nasty e-mail to your boss claiming to be you potentially resulting in you being fired. Somebody can write threats to somebody claiming to be you potentially having legal consequences for you. Basically, anybody can write any e-mail as you.

However, this issue is partially mitigated by servers checking whether the e-mail comes at least from the domain as mentioned in the From:. Such as, if you send an e-mail to a google mailserver using From: hi@me.com google will perform a reverse lookup on the IP (of the sender) and check whether this matches me.com and it will also check if you have MX records for your domain (DNS). This prevents somebody at least from impersonating someone from another domain but google can't really verify whether it was truly hi who sent that e-mail. So, this is not a complete solution to the problem, it just mitigates it somewhat.

Generating keypairs isn't actually that hard it's just that a lot of e-mail clients don't have built-in supports for doing that but you need plugins and let's be honest - plugins are usually a usability issue. If you'd tightly integrate it properly into an e-mail client it would already be somewhat easier. However, you'd still have to solve the problem of who validates/verifies you. Theoretically, you could start employing a system similar to PKI for web but for e-mails using CAs etc. but that's probably not going to happen any time soon.


Does Sweet32 work on services that do not use web sessions/cookies (such as FTP)? Saintbot PCI/vuln scanner (via Controlscan) is flagging FTP port 21 vulnerable to Sweet32, based on the existence of a 3DES "grade C" cipher.

The fix is easy -- update the available ciphers to be more secure. However Cpanel v62 has a current "issue" where their version of PureFTP does not obey ciphers set forth in pure-ftpd.conf.

This causes a PCI fail until we switch to ProFTP. We don't really want to do that....at all.

Question is, can/does Sweet32 even work with FTP or similar style "authenticated" connections? I want to attest their finding, unless it's actually possible to pull this attack off on non-web tunnels.

Sweet32 does not specifically attack authentication but it tries to extract secrets contained in kind of structured, partly known and very large data. Authentication information in the HTTP header fit this description if it is possible to send lots of HTTP requests over the same TLS connection. But depending on the kind, amount and sensivity of data you transfer with FTP this can be a problem for FTP too.


Inconsistent nmap results I have setup  a series of scripts to run regular nmap scans against our servers.

The results from day to day vary - for example one day it might report that only port 80 is open and the next day ports 21, 80 and 443 might be reported open.

The options I use are:

nmap -T4 -A -iL <ip list> -oA scan-$date

My setup is Kali 2016.1 on a hyper-v hosted virtual server, tunneling out of our DMZ to a Digital Ocean hosted Debian server using sshuttle.

I had assumed that the firewall or IDS was dropping or rejecting requests, but I've experimented with the timing and scan type options with no improvement to the consistency of the results.

Any ideas why this might be?

Your script is fine that you run on NMAP and consider the people in your company who use your servers/connected to the servers or network somehow, may be using software that open certain ports in order to run. For example, Skype uses port 80 and 443 by default. If it can't use those it will change to a different port. Make sure that you have narrowed this down completely. Try add the -sV option to see what is running from where, may give you more incentive.

Check your firewall, see if it is filtering out certain connections, make sure your applications or OS's are accepting TCP connections and check if there is anything with closed ports that are accepting packets but not being listened to by any application.


Got a paypal confirmation code when I don't even have an account? Basically just right now I got a text on my phone giving me a code that expires in 5 minutes. The scary thing is that I've never used paypal ever in my life. Is this just someone mistyping his phone number or a hacking attempt?

I wouldn't be so concerned, yet, as it's quite probable that this was merely a mistake in entering information.

Paypal sends a confirmation when you first set up 2FA (two-factor authentication), to verify that you've entered your number correctly. If you don't have a paypal account, the most likely cause of your receipt of such a text is that somebody has tried to set up 2FA for their own account, but mistyped their number as yours.

In theory, they shouldn't be able to validate using your phone number (unless they have access to your phone), and so Paypal will reprompt them for a different number.

If your email address has been used, then you might have something to worry about! As Paypal uses email address as the primary factor of authentication (you can't sign up or login using the phone/text factor alone), the only person who should have access to use Paypal with your email address is you! There's no information in this question to suggest that this is the case, as you haven't indicated that you received emails from Paypal, so I'm going to assume this is out of the scope of the question. Suffice to say, if this were your case, secure your email account and work out what to do with nefarious (or perhaps, lack of) funds...

In addition to sending a confirmation when you first set up 2FA, Paypal will send a confirmation for every login there-after (providing you managed to successfully complete the challenge during confirmation). As you haven't mentioned receiving multiple such messages, I'd suggest that your receipt wasn't one of these.

Even if someone has successfully used your phone number to authenticate (implying that they somehow obtained the verification code sent to your phone in order to successfully set up 2FA using your phone number), there's still much less to worry about than the email address compromise scenario above. It's possible that someone could have compromised your phone (in which case, you'd need to restore your phone to factory conditions and reset all associated passwords), but again, there are other  much simpler explanations to be aware of.

For a start, an attacker might not need to compromise your phone to intercept those 2FA codes; some attacks involve keeping you busy (literally; the attacker will call you while Paypal is trying to call you, as the code can be retrieved as a phone call for the visually impaired) so that the Paypal verification code goes to a message bank service. So make sure your message bank configuration is correct, and your missed calls aren't being forwarded to some nefarious message bank service.

Even still, thanks to VOIP forging attacks, attackers can retrieve such a verification code from your legitimate message bank service by making a call from your number (even though they haven't got your SIM card) to your message bank. So better yet, disable the message bank service altogether!

However, again, I note that you've not mentioned any symptoms of message bank compromisation, so I'm going to assume that's also irrelevant here. Be vigilant of Paypal confirmation messages sent to your message bank (or disable your message bank entirely)...

In summary, it's most likely that someone merely entered their own (very similar) phone number incorrectly, and you won't receive another verification text. However unlikely, it's possible that someone could have access to your phone, or your message bank service, but I wouldn't worry about that unless you see symptoms of such a compromise... Always be vigilant of such compromises!

To clarify, Paypal will send a confirmation:

when you first set up 2FA (and this could be a mistake, which would result in Paypal correcting the issue very soon)
providing you successfully set up 2FA, for each login there-after (and this would be your indication to get on the phone to Paypal, remedy the issue, and work out what else was compromised)