How to validate the confirmation link received when publishing a new PGP key?

I think the key misunderstanding you have is that you think public-private key pairs are somehow tied to a machine. They are not. You can generate a key pair on any machine and export/import it to any other.

The only critical component of PGP you need to worry about is keeping the private key private.

You have two options:

Generate a key-pair on your local machine and export/import the private key for all machines you want to perform decrypt/signing operations on
Generate different key-pairs for every machine and access them remotely to perform your decrypt/signing operations - this option means the private keys don't need to move around, so it's less prone to mistakes that could expose your private key (very bad).

So If you don't want to manage receiving e-mails on the Ubuntu machine itself (for example by remotely controlling it with X over SSH or VNC), you need to export the private key from the Ubuntu server so you can import it to your local keychain. That's done as follows:

gpg --export-secret-key -a "User Name" > private.key

This key is unprotected so you must be careful about how you move it (use something secure like scp).

Or, do what you already know how to do and generate the key-pair on the machines themselves. If you don't have an e-mail address for every machine, just upload it to a key server that doesn't require e-mail verification, such as http://pgp.mit.edu.

E-mail verification isn't necessary, using a key server at all is unnecessary - you only need to share the public key with those who are sending you encrypted data.


After formulating a question, I've noticed solution myself. In case this might be useful for someone else:

CMS_get0_type - converts CMS_ContentInfo into ASN1_object pointer

OBJ_obj2nid - gets one of the following NID values from ASN1_object pointer:

NID_pkcs7_data

NID_pkcs7_signed

NID_pkcs7_digest

NID_id_smime_ct_compressedData:

NID_pkcs7_encrypted

NID_pkcs7_enveloped

For details see:
http://wiki.openssl.org/index.php/Manual:CMS_get0_type(3)


TACACS authentication: is it possible to get the user groups or other attributes?

No,

nothing in the RFC about user Groups https://tools.ietf.org/html/rfc1492

P.S: You should upgrade to RADIUS or DIAMETER. TACACS is just so old.


What was behind the surge of Adobe Flash Player vulnerabilities/patches in 2015?

I think that the answers you get here are mostly speculations. But the question is interesting nevertheless. I see the following main reasons:

Other usual attack vectors like Java or ActiveX were harder to exploit because the relevant functionality was either switched off or layers of interaction were added (i.e. click to play, warnings with unsigned code and similar). Thus other attack vectors need to be found. Since flash is almost everywhere and known to be buggy it makes a good attack vector.
Adobe fixed known exploits faster and browsers like Firefox or Chrome made sure that you don't use a known vulnerable version any longer. Because of the smaller  time frame in which an exploit could be used in public (sometimes a few days only now) more exploits were needed. And it looks like there were always enough new exploits available because lots of money can be made today by developing and selling new exploits.
Creating botnets, sending spam, injecting advertisements is a business where lots of money can be made. On the other side the basic protection from operating system and antivirus got better. This means that more new and unknown exploits  need to be used to keep a high infection rate, that is more zero-day or half-day exploits where used. Money earned this way then will be used to develop or buy new exploits. There is actually a real industry now where some sell or rent exploit kits and keep them up-to-date, others use these kits to transport their own malware and more just using the services of established botnets to send spam or do DDOS attacks.


Can a network vulnerability be exploited locally?

"Local access" means that you need to be on the machine.

"Local network access" means that you need to be on the same network segment. This level of network access allows for specific access to the traffic and exposes different vulnerabilities.

"Remote network access" means that it is exploitable even if you are not on the same network segment. But you also could be.

The classification means the minimum level of access, not the only means of access.


Prevent javascript cross-origin redirect by window.location.href

Sadly, it's not possible.

You can check that with the following HTML snippet where the default CSP directive is set to none (except script-src):

<meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'unsafe-inline'">
<script>window.location = '?' + Math.random();</script>

Since window.location is a non-configurable property, it's not possible to rewrite / proxy it to match your needs.

Note: it's possible to listen for the beforeunload event and trying to prevent it, but the user will most likely ignore the warning message that will show up.


Should I allow browsers to remember my passwords and synchronize them?

To expand on what @d1str0 said: if the creator of your browser wanted to steal your passwords, it would be trivial to send them to a manufacturer controlled server whenever you entered them - they don't need to bother with the hassle of telling you about sync procedures, or offering to remember passwords. All browsers by default send a certain level of usage data back, usually crash reports and update checks, which could easily conceal password and username data.

However, if any browser was found to be doing this, there would be outcry against that manufacturer - look at the rage directed at Microsoft following the release of Windows 10 with the reporting back enabled there.

Keepass and Password Safe are both open source (so, given sufficient programming knowledge, and a trusted compiler, you can be sure they're doing what they say they are, and nothing else - sufficient programming knowledge may well be a very high level though). In both cases, the encrypted password files should be safe to sync, even to third party sources, as long as the safe password is not provided. Breaking AES (Keepass) or TwoFish (Password Safe) without the appropriate key (the safe password) comes down, as far as we know, to brute force.

Lastpass and 1Password both require you to trust the developers, and sync by default to a remote location. Theoretically, they are safe, but there wouldn't be any obvious way to detect a vulnerability in them relating to storage. If you're concerned about Chrome or Firefox stealing passwords, logically, the same arguments apply to these apps.

Personally, I use one of the cloud based password services mentioned - I've considered the risks and benefits, and balanced the amount of security I'm willing to accept against the ease of use for the service, and decided that for my use cases, it's acceptable. Your acceptable risk might well be different - if you consider AES as vulnerable, for example, keeping a Keepass safe on an encrypted USB key which uses a different encryption algorithm might be a viable option, but uploading the file to a third party service might be "too risky" for you.

It comes down to what you consider safe, having evaluated the options. Many security professionals have considered this problem though, and generally advise using password safe type software over allowing browsers to remember passwords, simply because browsers used to be terrible at it - they allowed access without a master password, and used poor encryption methods. Some of these issues have been addressed now, but old habits die hard!


Are there attacks which are specific to Linux?

The attacks you talk about are on services which might be running on mswindows, linux, bsd, vms, os9, qnx...any operating system.

You seem to be confused as to the nature of a kernel (such as linux) an operating system and a configured machine. Although linux is a kernel, the term is commonly (although incorrectly) is applied to operating systems. Indeed linux usually comes bundled with a lot of applcations/servers.

If you are really only interested in kernel related vulnerabilities, then  you should be focussing your research on tcp/ip vulnerabilities and privilege escalation attacks.


Protecting a PGP private keyring on host?

Security is often applied in layers, so that if one layer is compromised the other layers will still provide protection.  Host level security refers to the layer of security applicable to hosts - primarily related to the operating system, but also to the BIOS and other systems.  Other layers include Network and Application security.

Some examples of the vulnerability categories for hosts are provided here:

https://cs.uwlax.edu/~riley/CS555Sum10/readings/3.1.pdf

where they list:

  The computer must be secured physically.
  The O.S. most likely needs to support multiple users and manage their authorizations.
  The O.S. most likely must manage process authorization in a multi-tasking environment.
  Some O.S. provide users remote log-in, which introduces unique vulnerabilities.
  The O.S. must manage memory as an asset to be used by processes.
  The O.S. must provide a secure file system.
  The O.S. often provides for certain forms of security related to traffic to its network interfaces.
  The O.S. must manage permissions that are granted to application software.

So host level security is more than just file access permissions, and considers the security of the host overall.


Will prepending random data (of random length) result in more secure communication?

No, this won't provide any improvement for encryption with any decent cipher. If a cipher is so bad that a known-plaintext attack is capable of fatally breaking it, then the cipher is worthless. A known-plaintext attack is one where an attacker has knowledge of plaintext/ciphertext pairs and, from that knowledge, is able to either calculate the key or otherwise perform decryption operations on arbitrary ciphertext.

If you want to make decryption via brute force or dictionary attacks harder, you should use a KDF like Argon2 that runs the user-specified password through a computation-intensive and memory-intensive calculation before it is fed to the cipher. If you want to make cryptanalysis of the cipher more difficult, all you need to do is use a cryptography library that selects a secure cipher for you, like AES or ChaCha.


Is using a WebServer as a proxy a secure solution

Assuming that you're running a relatively modern version of windows server (2008 or 2012) I think you can do this with inbuilt server functionality.

The netsh interface portproxy command allows you to setup proxying/port forwarding on a windows server.  If possible I'd say go with a solution that uses OS functionality as it reduces the complexity and doesn't give you another piece of software to maintain/patch .

As to the approach of using a webserver as the proxy, that could work ok.  If you go that way it would be a case of locking down the server as much as possible and then making sure it was added to the patching process to make sure it gets updated.


Are There Best Practice Standards for Username & Password

The NIST guidelines contain excellent and modern recommendations. For example, it recommends checking the password against a blacklist instead of enforcing it contains character classes (uppercase, numbers, punctuation characters).

However, it may be that other parties that are specific to your industry enforce other guidelines, for example if you are subject to HIPAA or PCI-DSS.

A more scientific approach would be to calculate the entropy of a password. However, calculating entropy assumes totally random passwords, and users prefer using their cat's name instead of a randomly generated password.


Why people say that salt helps to prevent rainbow table attack?

Creation of rainbow table requires much resources to compute it and a lot of space to store the table. The main idea is that despite it costs much resources, it needs to be computed only once, then can be used many times. For instance, some web site or some application has 1 000 000 users. Suppose the password database contains "simple" password hashes without salt. Suppose the hacker has got this database with hashes. For using the system a real password needs to be obtained from the hash.
Knowing their algorithm, the attacker creates a rainbow table. Suppose the attacker has chosen such rainbow table parameters, that it took one day, 24h, on a single PC to compute it. But now the attacker can use this table for breaking any of the hashed 1 000 000 passwords in the database.
But if every password hash uses a separate random salt, then the attacker has to create a rainbow table for every password. This will cost essentially more time and resources, and makes no sense for the attacker.
The length of the salt is chosen usually so that the number of possible salt values is relatively big and the attacker cannot create a rainbow table for all possible values of salts.
The article that you refer describes usage of bcrypt. This hashing algorithm has 2 means against brute-forcing: It uses salt and it is computationally relatively expensive: it works much slower than fast algorithms like MD5 or SHA-512. Usage of salt makes creation of rainbow tables useless. Usage of expensive algorithm requires much more time and not only makes creation of rainbow tables even more expensive, but prevents also from the brute-forcing of separate passwords, because to test all possible passwords the attacker will need the computer power of the whole world for millions of years, which makes brute-forcing useless.


These are very good starting points

Linux

Gotm1lk's basic privilege escalation guide
Kernel exploits
searchsploit linux/local (can slim down results: searchsploit kernel linux/local
VulnHub

Windows

searchsploit windows/local, searchsploit win_x86/local (can slim down results: searchsploit Microsoft Windows VERSION local, etc.
Fuzzy Security guide

Both

www.google.com
Learning how to use the operating system(s) in question.


What's the difference between "Due Care" and "Due Diligence"?

The issue is somewhat complicated by the fact that "due diligence"  has a distinct, legal meaning in contract law, but since OP added the CISSP tag, I'll confine this answer to the usual meaning in that context.

Simply put "due diligence" is what you know, and "due care" is what you do.  Absence of "due care" might open you or your company to legal consequences (e.g. not following the law about data protection) while absence of "due diligence" would be more likely to open you up to making a bad decision or business deal.

"Due diligence" can also cover the verification (knowing) that "due care" actions have been carried out.  This is where most folks get confused.  The point is, "diligence" is about knowledge.  Knowledge of right- or wrong- doing (care).  Have you done your research? Do you know where your assets are?  Are your policies being followed?  Answering those questions are all "due diligence."

"Due care" covers activities like following the policies, applying the patches, encrypting the data as required by law.

Frequently the data custodians are more concerned with exercising "due care" in handling data.  Data owners, and management, are frequently more concerned with "due diligence" (e.g. are the policies being followed, and has 'due care' been exercised when handling data).

With these ideas in mind, you can re-read the examples cited above, and perhaps they will make a bit more sense together.

It can be a subtle distinction, but its an important one.

Full disclosure: I've only had my CISSP for about five months. I don't claim my answer is perfect.


How can the data in a computer system become corrupted when it is copied across a network?

If the received data is corrupted, it wasn't really "copied," was it?

Data packets sometimes become altered between the time they are transmitted and the time they are received. This occurs for a variety of reasons, and modern network protocols support "error checking and correction" (please search). Typically the numeric values of all the bytes of data in the packet are added up, and the result is then used to determine whether the packet was or was not received correctly (search "checksum"). Typically if the receiving node detects a "bad" packet (i.e. the received checksum doesn't match the sum of all the received bytes) a message is sent requesting another copy of the packet.


Detecting Malcode in Excel and Word Documents

Detecting malware in Office documents works like everywhere else too: You might use a pattern-based approach for known malware and you shall use heuristic to detect potentially malicious behavior.

There is no “common pattern“ for malware. Some might write text files, some might download binaries, some might delete registry settings, some might copy themselves onto network shares.

Detecting such malicious actions require you to understand what is legitimate within a macro. Everything else is potentially harmful. Keep in mind: Running macros from untrusted sources is like executing a binary.


There's no right or wrong answer to this, it all depends on what information you have to protect. If you are storing people's personal information or sensitive intellectual property on your intranet then using facebook logins are a bad idea because FB has no interest in security. FB does not enforce strong passwords. They allow very simple passwords and people are never required to change them. FB is written to make it easy for people to use so FB can profit from selling people's identities, they have no motivation to make it secure.

Ask yourself if you would rather have your salary details, address, ssn, employment history, plus the sum total of all the effort your company has ever produced to be protected by passwords that are likely to be your boss' birth date or kids name on a system that's ripe with identity theft. Or would you rather it be protected by a username/password scheme that enforces some level of complexity and the occasional change? hmmm, let me think....

In other words, if you have absolutely nothing to protect and don't care losing your job due to gross negligence then go for it!


Where I am going wrong with Veil? Cannot get a reverse shell?

I've had this problem before, and my issue was that the veil payload was a 32bit version of the generated backdoor. I had to use the x64 version of the backdoor. If you don't have the 64 bit version of the payload, you'll need to update your veil and try again.


How can I detect if someone is sniffing network packets on the LAN?

There has been some work done that I've heard of like anti-sniff, which looks to detect machines in promiscuous mode using timing information.

The idea being that machines in promiscuous mode will have to process all packets that they see so if there are large amounts of traffic that need processed the system will be busy and slower to respond to directed traffic.

This sort of approach, if it's still practical, wouldn't work in every scenario.  For example if a host doesn't have an IP address it can still potentially sniff traffic and it wouldn't be possible to detect it using this approach.

However it's one possible approach that could be explored.


Is it safe to reuse a tab in a browser for different websites?

I'm not aware of any security issue of reusing the same tab for different web sites, i.e. I don't think it is better or worse to reuse a tab vs. close and open a new tab.

But apart from reusing only a single tab it can be a security issue if you use the same browser application or the same browser profile or even the same operating system for sensitive and non-sensitive tasks. If the sensitive web site uses session cookies or similar mechanisms to keep you authorized and if this sensitive site is vulnerable to (very common) CSRF attacks then an attacker might misuse your identity from another tab or window within the same browser or even from a different browser on the same system. With simple session cookies it must be the same browser instance, but if persistent storage from flash or silverlight is used for identifying the user this identity token might be shared over multiple browser profiles or even between different browsers on the same system (see https://www.chromium.org/Home/chromium-security/client-identification-mechanisms for more details).

Thus for sensitive stuff like online banking you better take at least a different browser profile which gets only used for this purpose. Or you might even dedicate a different computer (or virtual machine) for this purpose.


Certification by accreditation bodies only occurs if you are indeed compliant within the scope you have set for your company. You can request ISO27001 auditors to perform a gap assessment and current state and they can do low or high level recommendations to improve your ISMS or assist with implementation. Note that depending on the amount of advise given to you, they may not be allowed anymore to perform the audit (you aren't allowed to audit your own work).
Your certificate states what you are complying with and what the scope is of your certification. Therefore if you can't state to your clients that you are compliant with ISO27001 for your whole company. You are only compliant for that particular business unit within your organization.

They can certify certain parts of your company depending on your scope. Let's say you want to for instance only certify your datacenters then you can, but it will also clearly be stated with regard to your certificate.


I'm not sure if this Website is SQL Injectable

Your error message is not really conclusive. It just states (if my french isn't as bad as I think it is) that the site encountered some kind of error. This may mean literally everything from "SQL returned an error" to "The backend's gone because a plane crashed into it".

Also you were trying to inject this:

  " UNION SELECT SLEEP(30) --

What behaviour would you expect from a vulnerable site? In case your statement is sytactically correct, most likely you would expect an errorless return of the server after 30 seconds. So: Did you measure the time?

Also: How did you conclude this is the correct syntax for whatever used backend? There are multiple different SQL-based languages and interpreters and choosing the wrong syntax will most likely produce errors independent of applied filtering.

So you questions might be answered with:

  Could someone experienced tell me if this is an SQL error message and if an exploit is possible?

No it's most likely impossible on basis of the information provided.

  If yes, how can someone exploit this?

It most likely doesn't matter. If you manage to prove that SQL-Injection is possible (bei either producing an actual SQL error or conclude from timing or error-basis), there will probably be no reason to exploit.

Just tell the owner ;)


What security resources should a white-hat *developer* follow these days?

For conciseness, I'll only add two:

OWASP's moderated blog - they aggregate quality posts from a lot of diverse security feeds, mostly around new attacks, vectors, etc.
Microsoft's SDL blog, mostly focusing on remediation strategies, mitigation, threat modeling etc, and also once in a while a very open, honest analysis of discovered security flaws and the effect (or lack thereof) of the SDL.
(Soon I hope that http://security.stackexchange.com will be considered a top offering... :) )


response when sent emailed links to personal information

Simply contacting both companies to register your concerns is a first step.

Secondly, there are likely personal data protection laws/regulations that cover either company that you can reference and appeal to if you are not satisfied with the responses from the companies.

You can't force anyone to do anything to change how they process information. You can inform, encourage, and bring in regulators when applicable.


Can a 'fingerprint' file be used to track a stolen device?

You mean, like say, a MAC address, computer serial number, Windows license key, CPU serial number, hard drive serial numbers, etc, etc, etc.  The problem is, an intelligent thief will either mask, block or change most of these and most of them, while able to be verified when you have a device in your possession are not easy to remotely discover, even if the thief is oblivious to possible technical measures and leaves it on and plugged directly in to the internet 24 hours a day.

This is the basic concept behind how much of the phone home software to prevent laptop theft works, but it still requires that the software go undetected and be connected to a network in order to be able to call home and the first thing any knowledgeable thieves will do is format the computer to be safe, thus wiping out any file or software on it that could help find the thief.

If you didn't have software that calls home installed, there may still be other ways to track it though.  Login cookies, for example, may report themselves to service providers when the thief accesses that website.  If you had your Gmail login saved and they go to Gmail, it will let Google know what IP your laptop is connecting from.  These are pretty hit or miss though since you don't know which services they may access.


Checking SSL/TLS servers for NULL encryption support

openssl s_client -connect www.example.com:443 -cipher NULL

You might also want to have a look at this blog which details how to test for different ciphers.

To test for 64-bit ciphers or lower you can use:

openssl s_client -connect www.example.com:443 -cipher LOW

To test for 128-bit ciphers:

openssl s_client -connect www.example.com:443 -cipher MEDIUM

To test for anything more than 128-bit:

openssl s_client -connect www.example.com:443 -cipher HIGH


How to find name of file to include in local file inclusion attack?

No, there's no other way to know if the file exists or not.

However, if you can find out what OS is running on the system, then often you will be able to find the right path to certain files quite easily.

In rare cases websites have a script or page which iterates through files in a folder specified by a POST or GET parameter which you could manipulate to display all files in a specific folder. I haven't seen this vulnerability in a while though.


Security concerns around sharing secret on a website

Shoulder surfing may be a problem. Malware on the client's device could screen scrape. Remote desktop session administrators may be looking at the desktop. SSL breaking proxies may store the data in transit (on the client's side where you might not know what their local proxying setup is). What is a user leaves the web page tab open and walks away from their device/computer?

Not that any of these are any riskier than other methods of communication, you just need to asses the risk vs cost of any credentials sharing system and make an informed decision on what level of risk to accept.


Stop an in-progress passive scan in OWASP ZAP 2.9

If your session is already persisted then just exit. ZAP will tell you there's still a bunch of stuff to passive scan but you can say you don't care and exit anyway.

There's also this long standing enhancement ticket: https://github.com/zaproxy/zaproxy/issues/3813 if you feel up for contributing and making things even better.


What is the impact of the OAuth 2 flaw on my social account and on my connected devices?

This is an fact not a flaw in OAuth 2 but in the implicit trust some developers have put into the data supplied by an Identity Provider (IDp).

The attack mentioned in the Original research is based on manipulating data intransit between 2 apps on your device or between a client and a server (either the Oauth Provider or a 3rd party service).

It boils down to a failure to recognize that you simply can not trust an end-user device (or any device outside of your control) so app developers should treat the data as 'evil' (as all user input should be treated) and assume it will be tampered with.

the attack leverages this mistake by supplying a correct access token but incorrect user details (such as using my own access token and your email address) which than will travel down to the 3rd party server and will be used as means of identifying me (so I will in fact be Identified as you as your email was supplied). In order for me to do this all I would need is your email address (easy to obtain). These servers should have been programmed in a different way. namely they should retrieve there own state of the user details utilizing the access token retrieved by the app. and validate that these are the same as provided.

Now how does this all translate to your question of impact on your devices.
 I am afraid the awnser is and will almost certainly always be "we do not know" Since the flow is a misunderstanding of the protocols use and risks. Since there are to many Apps we simply can not test them all if threre vulnerable for this abuse all. Since the exploit does not require anything from the victim but 'public' data you could be at risk without using oauth 2 logins at all. This is something the developers of these apps and services need to fix. and all wecan do is ask them to prove there not vulnerable (a.e. ask them to do a pen-test)


Verifying that the CRTM is read-only for the purpose of trusted computing

As the name implies, a CRTM is the Core Root of Trust for Measurement. By definition, a Root of Trust of a given system is trusted because its correct operation cannot be verified by that system. In general, for a CRTM to operate correctly it must be immutable for the system that relies on it.

So, by principle, it doesn't make sense to try to verify the immutability of a Root of Trust from within the given system ("in-band"), especially if the trustworthiness of the verification relies on the very assumption you try to verify.

Nevertheless, verifying the immutability of a CRTM would depend on the particular CRTM implementation and on the level of assurance that you are trying to obtain, with approaches ranging from attempting to write to the given CRTM code location to hardware design review and physically invasive methods.


Is Bluetooth's "advertising" mode more secure than "discoverable" mode?

Discoverable is trying to bind connections, while advertising is broadcasting with only partial access to BLE protocol stack. Because it never connects, advertising should be more secure wherever applicable. The article below gives a very complete description of advertising.

    "A non-connectable undirected advertising type signals to scanning
    devices that the advertising device will not support a data connection
    - only broadcast information."

  Bluetooth LE Advertising Mode


Is it a good idea to store Email addresses as hash only?

In the end, there are two questions: what you should store, and what you should share.

What you should store

Storing the email address has the advantage that you can contact users. A lot of sites do want to be able to contact users who are not currently logged in. For example, merchant sites want to be able to notify users that their order has been dispatched or that their payment bounced. A lot of sites have configurable email notifications. Sites may want to inform users of a privacy or security breach — people tend to prefer being notified privately than learning it in the news. And that's not counting all the nefarious purposes (sendind ---spam--- “promotional offers”).

If you decide that you never need to contact users, store (slow and salted! Not MD5 or SHA-2, but PBKDF2 or bcrypt or scrypt.) hashes of emails. But be aware of the limitations.

I assume that you'll be using email addresses as user unique identifiers. This has a downside: sometimes people change emails. For example, in the academic world (which a lot of users are likely to belong to), people often use their email from their current institution, and then the next year this email becomes unusable. This can cut them off from accounts that are too strongly tied to an email address. Be sure to allow a way to transition (which can be tricky if you require access to the old email address to add a new one).

What you should share

Brute-forcing a salting hash requires enumerating all the possibilities. The time it takes to try one possibility is a configuration parameter of a slow hash — you should make it as slow as your server supports, but no slower. So the answer to “How long would it take to "unhash" one Email” is literally “whatever you choose”.

How long it takes to brute-force your email database is not really the decisive question anyway. Verifying that an email is in your database is obviously practical — your server will be doing it all the time — and this allows someone who knows the hashes to answer the question “does Bob have an account?”. This is already a privacy breach.

The same goes for the password: even allowing third parties to check their guesses of Bob's password is bad. Not as bad as revealing Bob's password, but still bad.

So the simple answer is: do not communicate email addresses or passwords, nor hashes of them, to third parties. If you accidentally leak even hashes, this is a privacy breach. When you share data, use meaningless identifiers for user accounts, for example sequential IDs or random UUIDs.

Also beware of scope creep in your database. If you store too much information about a user, this can allow identification and making connections. This is a common problem with medical databases — if you happen to know that Alice was at Riverside Hospital from 1997-02-25 to 1997-03-03 and from 2001-07-21 to 2001-07-28, and there is a single patient record who was admitted Riverside Hospital in February 1997, left in March, and was admitted again in July 2001 — Alice has been identified even if her name was never exposed. This isn't likely to be a concern with the information you're planning to store now, but keep it in mind.


Is automatic E2E encryption possible for chat apps with a backend DB?

It is possible, but with downsides.
As always, the security of this depends on your threat model. A possible way to implement it is to generate an asymmetric key pair upon first install of the app, then encrypt the key with a password chosen by the user (which must be different from their normal authentication password). Finally, the encrypted private key and the public key are sent to the server.
This allows users to re-install the application or install the application on multiple devices, since they have access to the private key by decrypting what they receive from the server. Furthermore, the messages sent to other users can be stored on the server in encrypted form.
What are the downsides?
If you don't trust the application developers, then generating a private key using their application or importing a self-generated private key into their application means potential key compromise. In other words, you cannot be certain that their app does not send the private key to the developers for malicious purposes. In fact, it is incredibly difficult next to impossible for developers to write an application which they can prove without a shred of a doubt to not be malicious.
If you are worried about third-parties (hackers, nation state actors, etc.) accessing the server with the encrypted messages, then this approach has downsides in comparison to "plain E2E" as described above. Namely, the attacker has access to all private keys, albeit encrypted, and can work on decrypting each of them. At least some of them are bound to have weak passwords.


Honey-pot. Attractive nuisance server that can be used to monitor attacks.

And a decoy/honeypot is a public server if it's accessible by the public as opposed to being an internal tool in an IPS (Intrusion Prevention System).

All servers accessible by the public are public servers, not all decoy servers are accessible by the public.

More definitive explanation from SANS.


Difference between SSH Tunnel / Proxy and VPN in terms of security

People often speak of SSH tunneling as a poor man's VPN. It is exactly the same on a feature and security point of view: you establish a secure tunnel between the client and a relay host and let a communication go unencrypted past the relay. The way the tunnel is established and secured may vary per VPN system but all serious ones can use standard up to date protocols, as can do SSH (and all can be equally configured with some work to use unsecure protocols).

The main difference is in usability. SSH goal is to establish a secure connection between a client and a host, and it does a nice job for it with clean and neat human interfaces. It can transport additional communications inside its tunnel, but as it is not its main goal, the commands are not really straightforward. Whereas a VPN goal is to provide transparent relaying of various protocols so it is much easier to use for that goal.


This does mean some part is signed using SHA1 as hashing algorithm. If you view the full output of gpg --export-options export-minimal --export <keyid> | gpg --list-packets, you may find which part.


These are the valid range for standard encoding of track 2, which is the ABA standard: 0x30 to 0x3f in the ASCII character set

0 1 2 3 4 5 6 7 8 9 : ; < = > ?

Sources:

http://blog.tehinterweb.com/?p=60

With enough control over the reader/writer, you can encode bits in anyway you choose though, could make up any system you like.


What are the risks of still using a 1024-bit certificate in a private network?

If I understand your scenario correctly:

You're talking about a security mechanism that relies on signatures made by 1024-bit RSA keys.
You have a relatively easy way of deploying updated certificates and revoking the old ones. It's a matter of days, maybe months, but certainly not years.

The public record for breaking RSA is a 768-bit key. Nation-states might be willing to expend more effort to go further, but 1024-bit keys still are out of reach by publicly known methods.

Under these assumptions, there is no meaningful security risk of using 1024-bit certificates (except maybe if you're worried about nation-state attackers, but even then RSA key size are not your biggest worry). There is a risk of non-compliance, because compliance rules tend to address scenarios that are not as favorable as yours (deployments to third parties that you can't realistically force to update, embedded devices that simply can't be updated, etc.).


KASLR and SMEP are kernel-mode protections, applying ASLR to kernel space and enforcing privilege ring boundaries on execution respectively. EMET is solely a user-space protection tool, and as such is not involved with KASLR or SMEP.

You should also be aware that EMET is not a magic bullet. It is designed with two goals: to raise the cost of exploit development, and to reduce or eliminate the efficacy of existing pre-written shellcode.

So, to answer your question regarding EMET and Windows 8.1, the answer is yes, there are plenty of protections that EMET offers:

SEHOP

SEHOP is a mechanism designed to prevent stack buffer overflow exploitation via SEH handler overwrites. EMET hooks the OS functionality which provides exception handling and inserts a check to ensure that the handler has not become corrupted, primarily by verifying that the handler address is one which came predefined in the application.

Dynamic DEP

Data Execution Prevention allows for hardware enforcement of execution access flags on memory pages. The normal configuration for an OS is to have DEP enabled for services, and then have applications opt-in based on a compiler flag (which is stored in the PE header, under the Characteristics field). EMET allows you to specify a policy that forces DEP on for a process, even if it wasn't compiled with this flag. It also has an additional benefit: it specifies the DEP policy for the process such that calls to SetProcessDEPPolicy from within the application cannot override this flag, so ROP chaining to that API won't disable DEP and allow for trivial stack execution.

Heapspray Protection

This protection is just designed to protect against stock shellcode pulled from frameworks like Metasploit. It pre-allocates common page addresses used in heap spray attacks and sets the memory to be inaccessible. This is useful because a lot of existing drive-by attacks use these addresses, and you can essentially prevent all of those attacks from working by allocating the pages they're looking for. Of course, someone who knows what they're doing can just re-write the shellcode, but it raises the bar to make it more difficult for script kiddies who only know how to use Metasploit or PoC scripts.

Null page allocation

Same as heapspray protection, except that it allocates a block of read-only memory at the null page address. The goal is to prevent null page dereferences from doing anything funky, though they freely admit that this is just a defense-in-depth measure as null page derefs aren't really exploitable bugs.

Mandatory ASLR

Like DEP, ASLR has to be compiled in with a flag, which again is set inside the PE header. The problem with ASLR is that even if your main program executable is marked as ASLR, it only has to load a single non-ASLR DLL into its memory space to result in a potential ASLR bypass - once there are known blocks of code in predictable locations, an attacker can build a ROP chain. Mandatory ASLR forces all loaded modules to be marked as ASLR-enabled, even if they're not compiled as such.

However, in Windows 8 (and 8.1) this feature does nothing if the native enforced ASLR implementation is enabled, because it does the same thing at the OS level.

Export Address Filtering

EAF monitors read operations on the Export Address Table (EAT) to ensure that reads are only coming from areas of application code, rather than shellcode. This is intended to make it difficult for shellcode to scan a module's EAT to find an API, where the module address is leaked in some way to facilitate such a trick. This is another mechanism where they use heuristics to guess whether the caller is shellcode or not, and isn't foolproof. It's just designed to catch out the low-hanging fruit.

EAF+

This is an extension of EAF, but it can be used in conjunction with or independent of EAF. It checks whether the stack pointer is within an allowed range, and whether the stack and frame pointers are mismatched. EMET 5.0 introduces a "valid modules" list for processes, and when it is populated EAF+ also detects if a read is to the EAT pointer for those modules, and monitors reads of the MZ and PE headers for the executable in memory to prevent EAT / IAT scanning.

Bottom-up Randomisation

Also known as bottom-up ASLR, this randomises the location of bottom-up allocations such as the stack and heaps. It's an additional countermeasure to ROP that just increases the amount of entropy in the layout.

Anti-ROP

This is a whole suite of protections that help prevent ROP from being successful. It monitors LoadLibrary calls to prevent loading DLLs from UNC paths, prevents memory protection APIs from making the stack executable, checks that APIs are properly called (i.e. with a CALL, not a RET), tries to follow back the call chain to check for ROP-like behaviour, and attempts to detect stack pivoting (incl. checking ESP / EBP against values stored in context snapshots used in certain APIs). All of these together create a headache for anyone trying to build a working ROP chain.

Attack Surface Reduction

ASR allows you to whitelist which DLLs an application is allowed to load. This is useful for a large number of reasons, including blocking malware from doing DLL injection, preventing unsafe plugins from loading (e.g. Flash), and stopping exploits from utilising LoadLibrary for nefarious purposes.

Advanced Anti-ROP

This feature adds more anti-ROP features. It hooks deeper functions, e.g. ntdll's memory allocation functions, so that it becomes more difficult to bypass the anti-ROP checks. It also tries to catch out shellcode that contains a copy of a function prolog, executes it, and then jumps past the real prolog to get to the real function, as a form of hook bypass. Finally, it bans the ntdll!LdrHotPatchRoutine function to prevent abuse of the hotpatch functionality.

Certificate Pinning

This isn't a mitigation in the same sense of the others, but it enforces certificates in IE so that they can't be easily replaced.

The point I'm trying to make, here, is that EMET has a whole host of protections which, when enabled in tandem, make the exploitation process significantly more difficult. EMET is not trying to prevent APTs and nation states from breaking stuff. They're trying to make it more expensive (in terms of time / money / skills) to build working exploits, so that it's less profitable for bad people to try. They're also rendering most shellcode which isn't specifically designed to avoid EMET inoperable, which is a large percentage of the market. It's absolutely worth enabling it.

With your concerns about stability with certain applications, you just have to work out compatibility with different protections. EMET 5.0 has reporting features which log detections, so you can go through and attempt to identify problems. Start with all the major protections enabled and turn others on or off as you go, until you reach a balance.

As for certificate pinning, it's largely browser specific. There are, of course, plugins for Firefox and Chrome that do this, though I've been underwhelmed by some. Certificate Patrol is popular, but I find it way too noisy to be useful - you just learn to click OK blindly. Chrome does have the --hsts-hosts command line option, which looks great, though you'll need to do some manual work to get it set up right. Firefox now pins several sites by default, as does Chrome, which means you're already protected to some extent. Unfortunately, it appears that there's no simple way to manage your own pinning across all browsers in your environment, and you'll have to do the manual work.

Sources:

EMET 5.0 User Guide
Announcing EMET 5.0
SEHOP - TechNet / MSEC
Certificate Patrol
Manually enforcing HSTS in Chrome


It seems like what you need is a healthy dose of magic unicorn dust.

What you are looking for is impossible to accomplish. Period. Especially since your machine needs to be on and logged in to be actually useful.

If you are looking to prevent your developers from taking the source code they write off your machine, get new developers. You obviously don't trust them enough to not steal the code they write for you so how can you trust them enough to actually write code worth stealing for you?

If you are looking to prevent thieves from accessing your source code, why even let thieves get anywhere near your machines in the first place?


EAPoL is an authentication protocol which is also used in WPA/WPA2. Its utility is to authenticate a user and establish a shared data from which the future encryption key will be derived.

EAPoL payload (i think you meant the handshake messages) are transmitted via Wi-Fi (in our case). The details of the actual payload content can be found here. So in order to get it, you need to:

Ensure your wi-fi card supports monitor mode (e.g. listen to all the traffic nearby).
Start to sniff that traffic (e.g. with help of WireShark and aircrack-ng tools)
Deauthenticate a connected user to force him in re-authentication. That's when that handshake will occur and since you are listening to traffic, you'll be able to see and save it.

Here is a step-by-step guide into cracking WPA2 through EAPoL handshake. You should also know that in order to perform the crack you'll have to brute-force password which means you might succeed only if your password dictionary will contain a right one.


There is no such law, and the claim itself is false.

In a cryptography, there are irreversible operations such as XOR, which destroys information by taking two inputs but having only one output. There are also reversible operations, such as NOT, which takes one input and gives one output. It would be necessary to design a special, reversible version of otherwise irreversible operations. An example is CCNOT, which takes three inputs and has three outputs. If this is done, and all the outputs are preserved, then indeed secret cryptography would become impossible.

  This is a computer science law that states for the purposes of encryption that all operations on a computer can be reversed which means that in theory all codes can be cracked.

Counterexample: I have chosen two secret numbers a and b such that a + b = 37. Try to reverse it.

For a cryptographic counterexample, consider the one-time pad (OTP). It is perfectly secret because, given some ciphertext, the probability that it is the encryption of a given plaintext message is exactly equal to the probability that it is the encryption of another plaintext message. This statement holds true for all possible plaintexts and ciphertexts, without exception, when using a uniformly random key. The OTP theorem states that, if plaintext p is a variable with any distribution over {0,1}n and k is a uniform random variable over {0,1}n, then the ciphertext c = p ⊕ k is a uniform random variable over {0,1}n.

This answer only describes logical reversibility and not thermodynamic reversibility, which is another subject entirely.


Receiving Junk Email that is related to Skype conversations

When you search on Google or Bing you have an advertising identity associated with you. Any terms that you search for then become part of that profile. Your keywords of interest are then sold to third party advertisers who can then target you for future adverts. These advertisers then share the data between each other in data markets, each adding in whatever information they know about you in order to build a more rich profile. They want to know things like your age, your gender, marital status, what car you drive, what sports you're into, etc. so they can show you ads that you're more likely to click on. This is often called "tailored advertising" or "customised advertising".

Now, technically those advertisers shouldn't get your email address. My guess is they've correlated it from another advertising platform that didn't properly redact your identity. This is common practice for shady advertisers and there are hundreds of them out there, so it's hard to track.

If your concern is that advertisers are snooping on your Skype conversations, I'd say it's unlikely. That kind of advert metadata extraction is done on some platforms (e.g. Facebook messenger conversations on the web client) but as far as I know it isn't done on Skype.


How do experienced users test stateful firewall?

NAT Traversal

A method for two clients, each isolated behind separate firewalls working in NAT, can establish communication with each other, even if the connection is explicitly allowed.

UDP packets does not contain any state. When an initial UDP packet leaves the firewall with NAT, it will allow UDP traffic to be returned through the same "session".

When to clients starts mass-sending udp packets at each other (same source/dest port tuple), at some point, both firewalls will believe that they initiated the traffic, and allow traffic between the two clients, each isolated by a NAT firewall.

http://en.wikipedia.org/wiki/UDP_hole_punching

Connection Tracking

Some firewalls does not only track connections based on tcp connection state, but also the application protocol's request to i.e. send a file over irc or ftp. While this is a feature when it works as intended, it can also be used to make the firewall open up for unintended connections.

An example of this is the XSS IRC DCC attack: http://encyclopediadramatica.ch/Firefox_XPS_IRC_Attack


What recommended precautions should one take when using internet provided by a Landlord?

I do believe VPNs would be the best (and easies solution) in this case, since all you need to do is get your own VPS server and VPN through it. You wouldn't even need to check modems/routers of your landlord.
If you don't want to VPN, just make sure all your connections are using SSL protocols (example: HTTPS, SFTP, SCP, SSH, etc), nowadays the chances of getting compromised by MITM attacks in SSL connections is low if you have all your applications updated and if you always check the site certificate.


I might be not as good in explaining the concept of an hash collision as good as this external doc so if it becomes not clear you can have a look at it.

In principle the POST and GET data is using a key-value structure. When receiving the data in a request and when accessing $_POST then php will need to convert the list given as a string which could look like this

EzEzEzEzEzEzEzEz=&EzEzEzEzEzEzEzFY=&EzEzEzEzEzEzEzG8=&EzEzEzEzEzEzEzH%17=&EzEzEzEzEzEzFYEz=&EzEzEzEzEzEzFYFY=&EzEzEzEzEzEzFYG8=&EzEzEzEzEzEzFYH%17=&EzEzEzEzEzEzG8Ez=&EzEzEzEzEzEzG8FY=&EzEzEzEzEzEzG8G8=&

into a form so taht you can do for instance this:

echo $_POST["EzEzEzEzEzEzEzEz"];

the string is not ideal to access the value, so that internally a hash-function is used to transform it to a resulting hash value.
The problem and potential attack that max_input_vars could prevent is that
related to the case that two keys generate the same hash-value hence a hash_collision, which causes extra time to care for such a coallision and would allow to use up lots of CPU with a rather simple HTTP request.


Solution for store sensitive data without having access to it

From your description, I assume you (A) don't actually need access to the users (B) data at any point of time? Ie. A stores B's data, nothing more.

If so, your whole idea sounds pretty bad.

Something about normal asymmetric encryption first:

The public key is used to encrypt. The public key, not the private key. The idea is that decrypting is hard. It won't be hard if you need the public key for it.
There's not something like a public-ish/semi-private key. One of the two key holders always can calculate the other key too (but not vice-versa), namely the private key can be used to calculate the public key.
There's no (single) asymmetric encryption scheme where decrypting needs both keys. You could use two kay pairs, ie. 4 keys, to make something like that, but not a single public/private pair.

Said that, the next problem is your definition of "storage without access". If A wants to store data without having access, why B should send the plain data to A? Because that's exactly what you're proposing: B sends data to A so that A can encrypt it then. Before encrypting, A has plenty access. Same story later when it is decrypted on A's side again before the data is sent back to B.

Third, A gives B a key, and later B sends the key back to A? How are you sure A won't keep the key to have access all the time? And why keys are sent around at all?

What you could do (and it's much easier): A stores the data, like you said, and nothing more. Don't make up nonsenical encryption strategies involving both sides. If B wants the data to be private, B can encrypt the data alone, with own keys and own methods, before sending it to A. A won't ever get any key.

And if you have that, you should think of integrity+authenticity too.


Using this path traversal security issue

It was a false positive. So here is what happened. I had an inline html comment, which looked like that:

<!-- enemies, boulders, etc. -->

I noticed that zap has marked (grey color) the word etc. I assume because its usually part of an important file system path in unix-based systems.

After removing the word etc there were no more path traversal issues in the report.


Improving stateless REST API authentication token - or ditch it for database persistence?

I think you misunderstood the "stateless" constraint from REST. From what was written in Dr. Fielding's dissertation, one can get a wrong impression that stateless means not to keep (server-side) any information about the client, which is wrong. What was meant was that the server shouldn't keep anything related to the client's session (state of the client, that can change during its servicing), which is a different thing.

For example, if your web service should support multiple users you should keep the information about your users, along with their credentials, so that you can validate each request and confirm that it comes from a valid user from your system.

What you shouldn't keep is the state a user is in, while using your service. Take a look at this sentence from the dissertation:

  Scalability is improved because not having to store state between
  requests allows the server component to quickly free resources, and
  further simplifies implementation because the server doesn't have to
  manage resource usage across requests.

So, if you store the state of your clients on your service machine, your storage limits might be reached quickly, with each new user added to the system, not to mention the scenario where a single user can have multiple concurrent requests and you have to manage resources across each of those requests. Also, if one of your service machines go down, any other available service machine won't be able to just take over that client and continue servicing him, because the state of that client, that was being kept on the failed service machine is lost.

Long story short, you don't really need sessions for REST services. Just make sure that your communication is secured (HTTPS) and you can send the basic auth info with each request. If you are really concerned with security, try using hmac or oauth or even per-client certificate. But make sure that you don't store any sessions on your service machines.

Do note that this doesn't mean you can't use external authentication services, which don't need to be RESTful, like single-sign-on servers.


Modifying SSL Certificate once created, Multi domain

Certificates cannot be edited; they are signed and the signature becomes invalid if you changes the slightest bit in them (literally: there is not a single bit that you can flip without breaking the signature). If you want to "modify" a certificate, then you actually want to obtain a new certificate, with contents that please you more.

Certificates are obtained from a Certification Authority. Since commercial CA make money by selling certificates, I am quite sure that your CA will be thrilled to sell you another one.


Is the MSWord password protection vulnerable?

You could go right back to the source, MS-OFFCRYPTO, which details how the container (usually: the zip archive that a .docx is) is to be encrypted.

It'll tell you that you should use an embedded encrypted stream using one of the supported CryptoProviders. At this point, it's probably easiest to check which one your Word uses – you can still open the .docx as zip file and look inside, but aside from a bit of document structure, the main content will be in an encrypted stream but described by rather readable XML attributes that specify how it was encrypted.

I'd expect crypto used to be no weaker than what was used before – AES with a 128 bit key length.


can a power bank be used to plant malware?

A pure power bank likely cannot - most of them have the data lines not connected to any chips, but rather to resistor networks.  However, someone could easily make something that appears to be a power bank but has nasty firmware on it.

You can get data disconnected (power only) USB cables that you could use to plug into a suspect power bank.  However, since phones use the data lines to decide how much power they can draw, in disconnected lines they draw the minimum and will charge slower.

You could make up a cable to match your phone, but it gets complicated.


A keylogger can use literally any form of communication to send its data back to the attacker.

Common methods:

FTP upload
Email
IRC
HTTP POST
Connect-back (i.e. attacker connects to a service listening on your machine)
P2P network (e.g. Gnutella or BitTorrent)
Custom protocol running over TCP or UDP, directly to the attacker.

Note that any of these services can be set up on any port, since the standard port is just for ease-of-use. As such, you might find an IRC server operating on port 50321 rather than 6667, or an FTP server operating on port 80 rather than 21.


IPSEC will work for multiple concurrent desktops.

Your scenario needs some consideration though. VPNs are used when the networks between endpoints are considered public/untrusted. LANs, in general (even after considering VXLANs) are considered already private in the sense that eavesdropping is not considered a big enough threat.

However, if you still consider it a threat, you might consider "detecting and isolating eavesdroppers" using Network Access Control solutions. Do keep in mind that in modern switched LANs, it is not easy for one node on a LAN to listen-in on traffic between any other nodes (barring broadcast traffic). If you consider the network administrator as a threat (they could set up SPAN ports to sniff traffic), that's an exception with its own implications.

So you might want to carefully check whether your threats are real or imaginary - since managing a large multi-node VPN is not a trivial effort. VPNs need both Authentication and Encryption to stay secure. Encryption relatively simpler in the sense that you can set it one time and leave it alone for a long time. Authentication on the other hand, means that you need your endpoint identities to be managed regularly.


MITM: tools for intercepting and modifying traffic?

Look into SSLStrip. It strips off the HTTPS request headers during MITM attack. If web server uses HSTS and browser supports it, then this tool won't be able to strip HTTPS. The code may give you some ideas.

Another option is scapy, which is a packet manipulation program that may be able to do what you are asking.


Are passwords for Windows accounts always stored in cleartext in memory, while the account is logged on?

Not always; as usual there are a few measures to take that provide a defence in depth against Mimikatz.

In Win 2012 R2, you can (and should) utilise the new group in the 2012R2 schema called 'Protected Users', described in this TechNet article: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn466518(v=ws.11)

You already practice the principle of least privilege, another, more general defence.

If you have older Windows machines in your domain, install KB2871997 which should backport the 'Protected Users' group into Windows versions still under support.

Finally, and this might be the most effective and easiest to push out via GP, there is a registry setting that you may set to prevent passwords being stored in plain text in RAM:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest, Key Value 'UseLogonCredential' and set to '0'.


Why is it important to apply security best practices when the risk they protect against is very low?

The potential impact of this is not low, regardless of how much information the thin client stores.

Specifically the risk is that an attacker installs something like a rootkit or software keylogger in the operating system of the thin client, which you are unlikely to be able to discover by inspection. (This is a variant of the Evil Maid attack).

Should any administrator ever use that client in the future, it will be game over for the network. The thin client can also be used as a beachhead to launch further attacks against the network, or to conduct reconnaisance.

Protecting the BIOS prevents this from happening, by protecting the integrity of the thin client OS.

The wider lesson here: Best practice saves you the expense and difficulty of assessing every risk, which as this question demonstrates, is hard to do.


stdin does not wait for next input after ROP chain

A note on fgets(): This is what I observed stepping through the debugger.  When piped data is sent to fgets() it's buffered on the heap, then it's transferred to the stack one by one until

A compare instruction returns true on a counter and the value that's passed in the RSI register to the fgets() function; which is the string length specified by the programmer.
Or receipt of an 0x0a byte ("\n")

Once either of those are met, the function exits and STDIN is torn down. So it's buffered I/O and not actual I/O to a file descriptor that's used to communicate with the OS.

Anyways, to manage stdin like you're doing there with bash in Python, you can use Subprocess's Popen function to connect directly to the service, but there's a catch.  Python blocks SIGPIPE by default, which prevents keeping the fd open for writing.  You can overcome this using the signals module and creating a patch function that overrides Subprocesses configuration to allow SIGPIP:

import signals
def restore_signals():
    signals = ('SIGPIPE', 'SIGXFZ', 'SIGXFSZ')
    for sig in signals:
        if hasattr(signal, sig):
            signal.signal(getattr(signal, sig), signal.SIG_DFL)

Then, call your program directly (without piping) via a Subproccess shell passing the SIGPIP patch through preexec_fn arg.  I also specified bash as the shell I wanted to use, but it's not required:

myproc = Popen("./test",
                stdin=PIPE,
                stdout=PIPE,
                shell=True,
                executable='/bin/bash',
                preexec_fn=**restore_signals()**)

This will keep a pipe open and you'll just have to manually close it.  I assume from an exploit dev standpoint, it won't really matter for you.

To send data, don't use the .communicate() method.  You'll have to manually manage the connection sending your shellcode bytes like so:

#prep the receive buffer by clearing it first
myproc.stdout.flush()

#Send your shellcode where shellcode is a var holding your shellcode
myproc.stdin.write(shellcode+"\n")

Note the "\n" to simulate enter so fgets() knows to end the buffer.

Then, to read output, you probably won't want to use the .readline() method unless you know the output (like a banner) will end with a newline byte (0x0a / '\n').  You'll have to manually manage it using the .read() method.

The thing with .read() is you'll need to have some sense of the data that is returned.  So if you're expecting a return of something like a memory leak or string and know the size, you're going to want to specify that so your script doesn't block while waiting for more data. I can't remember what the default buffer size on read is, but it won't return until that buffer is filled. .readline() will return on a 0x0a byte.  So, if you're expecting a 10 byte string:

 #sleep 1 second after your shellcode send to give the process time
time.sleep(1)
output = myproc.stdout.read(10)

Keep in mind that if you're sending multiple lines, you're going to want to flush() the stdout buffer each time, or your response will read 10 bytes from the previously received data.

Repeat as necessary. Hope that helps.


One method I've seen used at larger companies is products like Cyber-Ark that essentially take control of the passwords for the boxes and then have a set-up where you can request a password for a specific host for a time period.  The application then gives you the password and changes it after the time period is up.  An additional advantage to this approach is that you have a log of who had access to the server and when.

That way when a team member leaves they won't actually know any of the passwords. Obviously you need to combine this with monitoring tools to stop people adding unauthorised accounts or back-doors but if you've got enough accounts to manage it can be a good approach.


Is connecting to an open WiFi router with DHCP in Linux susceptible to Shellshock?

Yes.

The dhclient-script network-configuration shell script is run during the DHCP process, and a number of parameters from the server (such as domain-name) are passed to it in environment variables.  The script is set to be interpreted by /bin/sh, so if your system has that symlinked to /bin/bash (which is quite common), you're vulnerable.

What's more, on Debian (and possibly many of its myriads of offsprings like Ubuntu), which uses dash as /bin/sh, dhclient-script is explicitely shebanged to /bin/bash, and it does seem to contain a bashism, too.


I've had a short look around, but can't seem to find anything alleging that only a single key is used to encrypt data. Their security overview page does use the word "keys" (plural). The question is also tricky to answer, because Dropbox doesn't go into much detail about their security arrangements.

But key management is really only one link in the chain. For example, even if every file had its own unique key, your files would not be secure if Dropbox happily handed copies of the key and data to anyone who asked.

Briefly:

Dropbox's systems have access to the content of your files (this is how they detect duplicate files, which saves storage space and increases responsiveness).
Dropbox encrypts your files at rest and in transit.
Therefore, Dropbox must have access to (and copies of) the encryption keys.

Also, while Dropbox staff are prohibited by company policy from viewing file content, they still can access it (e.g. if law enforcement compels Dropbox to provide copies).

Therefore, this must mean that the real way Dropbox keeps your files secure is by:

Having internal controls, checks, balances, and audits. (e.g. Logging all unusual file access and following up).
Having a talented legal team to challenge any law enforcement requests that are inappropriate, overly broad, or otherwise harmful to their reputation.

So:

Dropbox keeps your files secure against its own staff by having good internal controls.
Dropbox keeps your files secure against eavesdropping by encrypting it in transit and at rest
Dropbox keeps your files secure against government agencies by having a good legal team

If you trust Dropbox, great. If you would prefer to not have to trust Dropbox, use Spideroak or Wuala, or encrypt your files yourself before uploading them.


Why is Multifactor Authentation Presented in Two Steps Instead of One

It prevents the attacker from knowing if you implement multifactor authentication, thus reducing the attack surface.

Edit: it also will allow you to be alerted if your password is compromised without allowing someone into your account. This will allow for user's who don't implement the security practice of unique passwords to resolve the issue before a breach occurs elsewhere.


I'm having a DDoS attack, my hosting company is not giving me a solution, and I need to know what is hapening

Have a good look at this question on DDoS mitigation - it is not something you will be able to solve by buying a faster switch, as an attacker can always get more traffic sources than your network can cope with.

All the workable solutions manage it with routing or dropping packets within the ISP - if your ISP doesn't offer a solution you should consider looking around for one which will.


But taking into account that the client may trust an untrusted certificate he will still send his certificate to the hacker, right?

yes, if client ignores invalid server certificate error during connection.

  then the hacker could use the certificate to login into the real network, right?

no, because only public part of client certificate is sent to RADIUS. Public certificate without private key (which is not sent to server and never leaves client computer) is useless in terms of hacking/impersonation of legal user.


Centralized key management for IOS and Android Code Signing

For iOS and OSX there are 'developer' certificates, needed to provision on up to 100 devices; and 'distribution' certificates, needed to upload to the appstores. The first is personal and is bound by a developer license. The latter could be reserved for your corporate build Mac. The 'team agent' can use it and upload, and delegate  rights. The distribution is the one to watch.


To identify if a server is running, you only need to determine if the port is open for requests.  Using netcat, you can query a server like this:

nc -z www.example.com 80

This will tell you if it's listening on port 80, the web port, but it won't tell you anything else about the server.

To use netcat to learn more, you need to pass it the correct data to elicit a valid response.  That means you have to understand http if you want to find out if it's running a web server, smtp if it's running a mail sender, etc.  You have to know what port a web server runs on, the name of the server, the protocol, everything.

Here's a simple example of how I'd determine if www.example.com was hosting a live web server using netcat.

echo -e "GET http://www.example.com HTTP/1.0\n\n" | nc www.example.com 80 | less

If this comes back with a response containing HTTP/1.0 200 OK, it's running a web server on port 80.  If not, it may not be running a typical web server.

You'll have to discover and understand the protocols of mail servers and ssh servers if you want to query them in a similar fashion.

Netcat is really the wrong tool for this job, however.  If you want to identify the kinds of servers a host is running, nmap is a much better tool as it's kept current with the various fingerprints of common servers you're likely to encounter.


Does HTTP redirect to HTTPS automatically?

No, at the moment no major browsers would redirect to HTTPS automatically.

The website can set HSTS header to tell browsers that they should redirect to HTTPS automatically for future requests, or they can register themselves into HSTS preload list, and users can install browser plugins to always load HTTPS based on a white list or even to always try HTTPS first. All of these are opt-in, either the website or the user has to do something to make the browser do this. In its default configuration, without explicit action by the user or the web site, no major browsers would automatically use HTTPS.


What should be header response of XSS vulnerability upon form submission?

The HTTP response code is unrelated to the existence of an XSS. If you get a 200 (status ok) while trying an XSS then it could be that the XSS was actually successful or that the XSS does not work because the server has sufficiently sanitized the data.

Similar a code of 4xx, 5xx etc could happen without a successful XSS, for example if a web application firewall in front of the server has detected something which seems to look like an XSS and has blocked it before it even reaches the server. But this does not mean that the XSS attempt would have actually been successful against the web application.


Ways to authenticate client with a server

From the cryptographic point of view, if one user A must be able to do something that another user B cannot (e.g. sending a message with "A" as sender's name), then there must be some value that A knows but B does not. That kind of secret value is called a key, although there are other terminologies (e.g. "password" when the secret is stored in a human brain).

Hiding keys within application code has two major drawbacks:

They can be recovered through reverse-engineering.
They are not user-specific.

However, in your case, you want a user-specific secret value: each user has his own key, with which his messages are authenticated. Therefore, the user's key cannot be hard-coded in the compiled application code; however, it may be stored as a file on the user's device. Reverse-engineering is here a non-issue: by reverse-engineering his own app installation, the user may learn his own key, not the key of somebody else.

The important point here: such a key authenticates the user, not the device. Making sure that a given message comes from a specific device, and sent by "your unmodified app" and not other code, is nigh impossible, since the said device is physically in the hands of the user, and is not tamper-resistant. To get such kind of guarantee, you need a device which is able to fight back against its owner, e.g. a smart card. Mobile phone billing works, both practically and legally, because the user cannot break into his own SIM card. You cannot have this model with an app which is software-only on non-shielded hardware (the phone itself).

However, as long as you want to authenticate users, not devices, then a user-specific key is fine.

Then comes the tricky part: authentication is good, but who is doing it ?

If you just want your server to make sure of the identity of A, then a shared secret between A and the server S can be fine. The underlying cryptographic tool would be a MAC. However, in that case, when user A sends a message to user B through your server, the server is certain that it indeed talks to A, but B knows nothing. An evil user E, who wants to forge a fake message purportedly coming from A, may send the said message directly to B, without going through your server at all !

One solution, in that case, is to make the communication from S to B equally authenticated with the B key: this time, that's B who makes sure that what he receives from S is indeed from S. With MAC applied in both directions, for all communications between the server and any user, then you can have a reasonably secure messaging network. Of course, S is trusted: your server can betray everybody at will. But maybe this is not a problem for you.

(For end-to-end authentication, without trusting a central server, you would have to resort to asymmetric cryptography and digital signatures, and things become a good deal more complex.)

Storing a user-specific key in a file on the user device sure seems simple enough. However, sometimes, users switch devices (e.g. they buy a new phone, or they are Apple-addicts who have an iPhone and an iPad) and still want to retain their identity. This implies that the user-specific key somehow travels from one device to the user.

The scheme that you envision (storing the key on the server itself, with automatic download after password-based authentication) is valid. Be sure to do that over SSL, of course. You may combine it with a caching mechanism: the app downloads the key when it does not already has it, but then it stores it on the device.


Decrypting keys wrapped by the Storage Root Key (SRK) of a TPM

TrustZone and TPM (with its SRK) are two very different things. I'll try to deferenciate both of those before explaining how they can be used to achieve what you explained.

TrustZone is an ARM platform environment. It provides a second environment which is meant to be secure. By this I mean, many features are available to obtain security.

In your example, the normal environment (the rich world in TrustZone terms) would be running Android and a so-called trusted/secure kernel (the TEE) would be on TrustZone side (the secure world). Those protections are defined by the TEE itself and depends on its actual goals. What's running in the secure world use protected memory that cannot be write/read by the normal world (Android) and some device might be mediated or reserved exclusively by the TrustZone kernel too.

You are right when you say a symmetric key wrapped by the TPM's SRK would normally be exposed directly in memory once unwrapped. The TPM does not offer anything at that point. The assumption is that you are only doing this from a trusted environment. However, if we join both a TPM and TrustZone, we can encrypt/decrypt data with the SRK (e.g. a symmetric key) and only expose the plain text to the secure world hence protecting it from the normal word, Android.

This is basically how Apple protects sensible information/processes (obviously heavily simplified).


Why does changing physical router not warn of possible man in the middle attack?

WiFi access points have no secret. They use a SSID, but they otherwise offer or know nothing that the client can validate. Every time a device (say, a laptop) connects to a WiFi router, it uses it as if it was a new router and expects nothing in particular from that router. Secrets are more on the client side: the router will require the device to demonstrate knowledge of the WiFi password.

With a SSH server, the server has a private/public key pair, and shows the public key, and the client records that public key. If the client reconnects, then it will require that the server uses the same public key as previously; otherwise, it will complain loudly (as you observe).

There is no such public key in a WiFi router. Clients are not actually interesting in knowing whether the router has changed or not, because the router is only meant to route data to the Internet, not to provide access to some sensitive data or receive sensitive data.

When you talk to your banker, you want to be sure that you have a genuine banker with you, because you will give him your money. When you talk to the cashier at a supermarket you don't care whether he is a real cashier or not, as long as you get to exit the supermarket with the food and security guards don't begin to shout at you.


Mainly it's all about isolation of secret keys to prevent unauthorized use.

I think the better general term to be used is crypto token like used in PKCS#11 specification.

There are several ways to protect secret keys, ranging from file ownership / permissions and/or key passphrases on the low-end to tamper-proof hardware which automatically deletes the stored keys in case someone is attacking the device with a drilling machine.

Real tamper-proof hardware is pretty expensive and therefore one cannot give a good recommendation without knowing your security requirements and budget.

Taking your term "HSM software" literally I'd recommend to have a look at software implementing PKCS#11 proxy functionality. This allows you to store secret keys on different commodity hardware running with standard OS and then use the key remotely over network. It gives better protection than storing and using secret keys on the same system but is not as secure as real HSMs.


To what extent is FREE 3rd party antivirus software better than Windows 8 defender (if any)?

From the reviews I've seen of Windows 8 defender (which includes what was security essentials in Windows 7 and earlier), it's a pretty solid middle of the road A-V suite with some anti-spyware features.

I don't think that it's as fully featured as the paid for security suites, but then it is free.

From a personal perspective I use it as it seems fairly unobtrusive in general running and doesn't cause too many problems but does catch viruses that hit the system.


How safe is it to edit PHP files in Web browser via CPanel?

HTTPS is as safe as SFTP if handled properly (reasonable algorithms and parameters). And of course if you use reasonable authentication method (which is not discussed here), but on this level, none of the protocols have serious flaw that it would make insecure.


Is there a law against one email containing both a login and a password?

If there is, it would be industry-specific. For example, the laws regulating nuclear reactors may be different from the ones regulating flower shops. As far as I know, there is no general federal law in the United States prohibiting you from sending credentials over email, even in the same message.


Are algorithmically-generated personal passwords a security risk?

The main issue with a "password generation algorithm" is that the passwords are fixed. You cannot change a single leaked password without changing the algorithm, thus changing every password.
To avoid that, you had to record somewhere the sites using the first version, the ones using the second one (because the password generated by the first leaked), the sites using another one because the algorithm generated a password unacceptable by some site, and so on.
And some sites require you to change your password from time to time. So you would have to take that into account, and record more and more information just to keep in pace with the state of the passwords. And for that, you would need a secure data storage, with encryption, a backup process, something easy to use and easy to be integrated on your online routine.
Losing any of those records would lock you out, and create an Availability Compromise. Leaking it in plaintext would create a Confidentiality Compromise. Corrupting (or forgetting) any of it would create an Integrity Compromise. You need some software specially created for secure storage.
Something like... a password manager.


I think you are misunderstanding some important details.  Most importantly, any attempt to trace the facebook message will not trace the user: just Facebook.  Facebook is not a peer-to-peer chat network.  Both of you communicate with a central Facebook server, which means you have no way to track the end-user.

As a result, they don't have to use a VPN to hide from you.  Facebook is already hiding them.  Facebook might be able to track the user (in fact, I'm sure they are commonly requested to do so by law enforcement), but in the event that a VPN is using, Facebook would likely just track the user back to said VPN.

So, without delving into the realm of the probably-illegal, there is nothing you can do to track someone contacting you through Facebook messenger, and Facebook certainly won't do it for you (nor can they necessarily do it if the person is behind a VPN).

There are other questions on this site asking about tracking people behind VPNs, which would be applicable in this case.  You could start here, keeping in mind that this is venturing into the probably-illegal and also not-for-your-average user:

Can you still be tracked when using a VPN?


Would a difficult to access "Key" be an option to securely solve the Apple vs. FBI problem?

Your proposal seems to be a device-specific key which is somehow placed on the device with the intention that only "authorized" law agencies can read. Only, this does not actually solve the problem since it is not that much a technical problem in the first place. It is easy to create a backdoor nobody can access. The problem starts then to make sure that only the right people can access it (whoever these are) and only for the right purpose (whatever this means).

It is not an FBI problem but a world-wide issue - most governments want to have access to the encrypted data in case of severe crimes although definition of what is considered a severe crime differ. Thus who should get access to this backdoor then: the secret services of every country where a phone gets sold? Or do you want country specific backdoors And how a customer can be sure which country has access to the specific backdoor on your phone? And how can be guaranteed that the knowledge on how to access the (country specific?) backdoor keys stays only with the agency which is supposed to have the keys while still being flexibel enough to be usable in multiple places where the agency has offices?

The main problem is not how to securely implement a backdoor so that the average criminal has no access to it. The problem is more how to make sure that only the legally allowed agencies get access to the key and will only use it for legally allowed purposes.


tl;dr

  Use TLS_DHE_PSK_WITH_AES_256_CBC_SHA with a large Pre-Shared Key. Send over Seed.

Objective

Create a secure network session over which we can send some entropy.

Preconditions

Assumption: /dev/urandom is foul. (I agree with @SteveSether, this is a kernel bug.)

Assumption: Any protocol you try to create between client and server will, in the end, rediscover TLS or Kerberos (Public Key or Symmetric Key), therefore, you should just use one of these or one like these.

Caveat: It is impossible to preserve Perfect Forward Secrecy without good entropy on both the server and the client. Although it helps to get entropy to the client, in the end this is a fool's errand. See discussion at the end.

With that caveat, let's dive in.

Requirements

To fetch entropy from server, we require:

Secrecy of the entropy
Server Authentication
#1 & #2 imply: Secure Network Protocol with Perfect Forward Secrecy

Candidate Protocols

TLS w/ DHE and Mutual RSA
TLS w/ DHE and PSK
TLS non-standard extension

TLS with DHE and Mutual Authentication

I had to study TLSv1.2 to figure out this wouldn't work. As noted in the question, the client isn't random, so its ephemeral can be known and Eve can compute the Master Secret. I had hoped TLS used the Client's RSA Key to protect the secrecy of the ephemeral(s). It doesn't.

Rejected.

TLS with DHE and Pre-Shared Key

Some people don't like this class of cipher suites. However, those arguments apply to humans as the holder of the PSK, not a computer. This works just fine for large PSKs. There are some security considerations, the most interesting one worth noting is a dictionary/brute-force attack. From RFC 4279:

  For the DHE_PSK ciphersuites, an attacker can obtain the information
  by getting a valid client to attempt connection with the attacker.
  Passive eavesdropping alone is not sufficient.

In our case, this could be done as an observation attack due to lack of entropy on client. A sufficiently large PSK should eliminate brute forcing the Master Secret, in any event.

Use this one.

TLS Non-Standard Extension

For fun, I was thinking what if we could extend TLS somehow?

During TLS's mutual authentication step, the client and the server exchange their certificates and proofs. If the client could use an Encryption Cert instead of a Signing Cert (this is easily done, Sign and Decrypt are isomorphic), it would tell the server to modify the DHE exchange. During the DHE exchange, server sends its ephemeral as Sign(Encrypt(B,Key_C),Key_S). Only the client can decrypt the server's ephemeral, only the server could have sent it. This keeps the server's ephemeral secret, which normally doesn't need to be. However, because we are trying to create a secure channel that Eve cannot penetrate and client doesn't have entropy for its ephemeral (a,A), hiding B will do the trick.

In summary, modify TLS_DHE_RSA with Mutual Authentication

client uses Encryption Cert
client authenticates by Decrypting some Nonce
Server hides its DHE ephemeral using Client's Encryption Key.

Know anyone on the IETF committee for TLSv1.3?

Other Options?

As suggested above, any other solution (RSA or Secret key provisioning with Nonces, etc.) recreates TLS or Kerberos, so why bother? You'll be taking on all of the challenges of rolling your own network authentication protocol without the vast analysis these protocols have endured.

Conclusion

Just use TLS with DHE and a Pre-Shared Key and send the Seed over that secure channel. It's a standard protocol, it has all of the properties you require, it's easy to set up and it doesn't suffer from too many problems. See below, however.

Discussion: A Fool's Errand and Broken Promises

We need entropy to make good on the promise of Perfect Forward Secrecy (PFS). The client doesn't have it and can't make it, so we are trying to get it from the server. We can use regular old cryptography (RSA or symmetric) to send the entropy. However, if the RSA Private Key or the Symmetric Key are exposed, Eve can use that Key to decrypt the server packet containing the Seed. How bad is this?

Assume after the client received its entropy, it only ran TLS+DHE+RSA for all communications. That has PFS, right? The problem is that once PRNG(Seed) is exposed, Eve, who was eavesdropping and recorded every network session in and out of the client, knows the secret part of the DH ephemeral produced by the client (B=g^b%P) and can rebuild Master Key from every (g,P,A) by doing K=A^b%P. Boom! PFS is gone.

We can't use PFS to send the Seed to client, because client's first DH exchange has the same exact problem. Once a secret key (RSA or PSK) is exposed, Eve can recompute the DH Master Key protecting the session with the Seed. Any other attempt at creating a secure channel or secret message suffers the same fate.

So, without client entropy we can have Current Secrecy for all algorithms. However, exposing any Key used to protect the transfer of the Seed exposes all sessions built using PRNG(Seed).

Basically, /dev/urandom has to work in a client VM to get Perfect Forward Secrecy.


blocking direct access to files via url input while still allowing a script on server to access files

It is not possible to do what you want to do, for fundamental reasons.  The user controls the client.  From the server side, the server has no way to distinguish a legitimate browser that happens to be making a request for an image on the page (a case where you want to serve the image) from a malicious user who is trying to directly access the image (a case where you don't want to serve the image).  These two situations are indistinguishable from the server's point of view, so the server has to behave the same way in both cases: either serve the image in both cases, or don't serve it.

You might want to revisit what you are actually trying to accomplish, and see if there is some other way to achieve it.  What are you trying to prevent?  What threat are you trying to protect against?

If you are trying to prevent scraping, one thing you could consider doing is making the images available only to logged-in users.  You will have to decide whether that is appropriate for your site, or if it is not a good match (maybe you want the web pages and images viewable by everyone).  Another option is to set up your robots.txt file to kindly request that bots not download the images.  You will be forced to rely upon the good will of the bots.  Well-behaved bots and scrapers will usually obey the instructions in robots.txt.  A malicious user can always ignore the robots.txt file and scrape your site anyway, but unfortunately, there is no way to prevent that: a malicious user will always be able to download any content that you've decided to make available to unauthenticated users.  So robots.txt is in some ways arguably about the best you can reasonably do, in most situations.

See also How do I prevent people from stealing photos from my website? and how can I prevent people from using my images from my website.


Zero day vulnerability appropriate corrective action

Often this is done because the fix used might have an impact on functionality. Remember they acted quickly so it might be that some functions are broken. If they would push it in their updates, it might result in a lot of users being unhappy because their webapplication is broken or doesn't work properly. So that's why they leave the choice at the moment.

I believe that once it has been tested properly, it will be pushed into the patch tuesday cycle.


How can sms messages recieved be identified without senders details?

Your carrier may be able to tell you what provider was used to send them the SMS, but I'm afraid the sender/caller ID field is just a text field and can be either spoofed or simply not included.

There are a number of carriers happy to charge someone to send an anonymous SMS, making it near impossible without Law Enforcement assistance to track the sender.  Spoofed (and I believe anonymous) SMS was a feature in the Social Engineering Toolkit (SET) and there are Android and iOS apps that will facilitate it as well.


What is the difference between Promiscuous and Monitor Mode in Wireless Networks?

Monitor mode: Sniffing the packets in the air without connecting (associating) with any access point.
Think of it like listening to people's conversations while you walk down the street.

Promiscuous mode: Sniffing the packets after connecting to an access point. This is possible because the wireless-enabled devices send the data in the air but only "mark" them to be processed by the intended receiver. They cannot send the packets and make sure they only reach a specific device, unlike with switched LANs.
Think of it like joining a group of people in a conversation, but at the same time being able to hear when someone says "Hey, Mike, I have a new laptop". Even though you're not Mike, and that sentence was intended to be heard by Mike, but you're still able to hear it.


I don't have any documented examples or statistics, but I can say that while difficult and expensive, it is certainly possible to educate users. It's easy enough to have security awareness training and whatnot, but the real problem lies in enforcing the policies and auditing their effectiveness. The most successful compromise controls are technical because it doesn't give people a choice. Not letting someone log in until they change their password is much more effective than having someone sign a sheet of paper saying they'll change their password every 90 days. Many other vulnerabilities stem from things you can't control through technical means. Such as phishing.

In order for education of users to be truly successful the results have to be observed and policies need to be enforced, regular reviews need to take place and there needs to be repercussions for not following policy/training. Just because it's hard or expensive doesn't mean it shouldn't be done at all though. Doing nothing in the way of educating your users will almost certainly be worse than at least making sure employees are aware of the risks involved with their various behaviors.


What are the new security features in Windows 10?

I am aware of the following features:

Windows Hello - A new authentication system, which will replace passwords with a combination of biometrics and public key crypto. This will eliminate "pass the hash" attacks. Private keys will be stored on the TPM. Biometric authentication to the local device can use fingerprint or facial scanning. The facial scanning will use a new 3D infra-red technique, which is supposedly greatly improved.

Device Guard - Anti-malware features. This includes a hypervisor, so even if the kernel is compromised, the hypervisor should stay secure. There will also be "mobile like" application segregation.

Enterprise Data Protection - Allows separate data containers in a system, with the ability to restrict apps to certain containers, and features like per-app VPN. Similar to Good Technologies, but integrated with OS.

Windows Update for Business - A new update system, making it easier to keep all systems patched. This includes "deployment rings" allowing you to test patches on a subset of users before full roll-out. Also has peer-to-peer patch downloads.

Just Enough Administration - A mechanism to restrict admin access to the minimum required to do the job.