Is it possible to escalate privileges and escaping from a Docker container? I'm learning a lot about docker. I'm practicing creating docker clusters using docker-swarm, registry, shipyard, etc.

I saw how easy is to get root in a docker host machine once you entered to the host with a limited user which has docker privileges. I was wondering if could be possible instead of this, "escape" from a docker container service to the docker host machine (doesn't care if as root or not).

Can this be done?

Any proof of concept? I was googling and I haven't found anything conclusive.

A user on a Docker host who has access to the docker group or privileges to sudo docker commands is effectively root (as you can do things like use docker to run a privilieged container or mount the root filesystem inside a container), which is why it's very important to control that right.

Breaking out of a Docker container to the host is a different game and will be more or less difficult depending on a number of factors.  Possible vectors include :-

Kernel vulnerabilities.  Containers running on a host share the same kernel as the host, so if there's an exploitable issue in the kernel that may be used to break out of the container to the host
Bad configuration.  If a container that you have access to is running with --privileged you're likely to be able to get access to the underlying host.
Mounted filesystems.  If a container you have mounts a host filesystem, you can likely change items in that filesystem which could allow you to esclate privileges to the host.
Mounted Docker socket.  A relatively common (and dangerous) practice in Docker containers is to mount the docker socket inside a container, to allow the container to understand the state of the docker daemon.  This allows a trivial breakout to the host.  More information here

If you're looking for more information I'd recommend these whitepapers from NCC.  Abusing Privileged and Unprivileged Linux Containers and Understanding and Hardening Linix Containers . There's also a presentation I did which covers some of this stuff here.

If you're interested in Docker hardening I'd also recommend having a look at the CIS Security standard.


Is WannaCry Proxy Aware? I read the Article of WannaCry on malwaretech.com and as far I understand it works like this:

Try to connect via HTTP to www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com
if it got an response then exit.
if not, do the next part (encryption etc.)

As far as I know, did the register of an unregistered domain make the (first) WannaCry not operable anymore?

The reason this was that a part of the code checks if it got an answer when it opened a network connection to that domain.

So if the Request that would be sent to the (theoretical) not existing Domain and the Proxy will, instead of just try to connect and got an "Connection Refused" message, redirect the Traffic to an existing host (which mostly just say that the URL is not reachable), would the (first) WannaCry never go active?

Despite the downvotes this is actually a valuable question.
WannaCry does not play well with the system proxy settings, so if you use a proxy, you will need to do this to activate the killswitch.

  I did test the sample, it is not proxy aware. In an environment with an HTTP proxy and no direct connections to the Internet, the sample can not connect to the killswitch domain and it will infect the host.
  https://blog.didierstevens.com/2017/05/13/quickpost-wcry-killswitch-check-is-not-proxy-aware/

So on to your question

  if in some kind of network, the firewall or some kind of piece of Hardware/Software that is between you and the Internet redirects the traffic to a local server if the remote Server is not reachable, would the (first) WannaCry never go active?

Yeah that would do the trick. If the executable can reach iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com, it will halt execution and not spread further.


What is more secure practice? Hosting from CDN or Main website There has been a long Debate on CSP modelling, I have a Web application and I use JQuery in it, For that i use JQuery main site http://code.jquery.com/jquery-x.yy.z.min.js to Host it on my Site to work, I know that CDN's can be useful in cases like this, i could also put this in my script tags https://ajax.googleapis.com/ajax/libs/jquery/x.yy.z/jquery.min.js to work-out the Same process. As far as the loading time is concerned Google hosted JQuery is faster than code.jquery.com.

Now, let's say i use the second one i.e ajax.googleapis.com part to Host my JQuery site on my Website. Now, to place Defense-in-depth Mechanism to avoid XSS i use CSP (Content-Security-Policy) headers, Now first thing that i do is to White-List by script-src 'self' ajax.googleapis.com . Now, let's say i have a Portion on my Website where Input is getting reflected without filtering which can cause XSS. Now, inline scripts like <script>alert(/xss/)</script> would get Blocked and Provide me protection. But there is a Negative afterwards, as i have white-listed the ajax.googleapis.com , any attacker can use Angular JS 1.1.3 from the same and cause XSS just like
"><script src="//ajax.googleapis.com/ajax/libs/angularjs/1.1.3/angular.min.js"></script><div ng-app ng-csp id=p ng-click=$event.view.alert(1337)><script async src=//ajax.googleapis.com/jsapi?callback=p.click></script>

This will result in XSS attack, Now the point is How could i Modify my CSP Rule so that it block every other End-point of the Whitelisted site i have Or if It's not Possible than I guess than Google API CDN is surely not a better choice than code.jquery.com. Any Explanation on how to workout?

Because even if i use code.jquery.com and Whitelist it, than Attacker may use older version of Jquery from same CDN and can mis-use it's vulnerability to cause XSS. So what is the Most safest Bet i can put here? Explain

my understanding is its not possible to specify individual JS files. instead the principle is you trust the CDN provider in this case you trust google. I think it would be a nice extension to the CSP if you are allowed whitelist the domain and JS resource.


Is it bad to add a guessable password to a random password? Let's say a person has a password they used before they knew about how to make good passwords, like peter123. Let's also say that when they were thinking of a better password, they found they could only remember 8 letters in a random string. Let's say the particular random string they chose here is atwer1414.

What is a more secure password: atwer1414, or atwer1414peter123? I would assume the longer one is more secure, but I don't know enough about hashing to know if the known/guessable peter123 being in there would give away any information about atwer1414.

Certainly a longer password with comparable or higher complexity, like your example, results in a safer password.

Though we have to say what "safe" means in this context. An attacker should not be able to brute-force the login. A long and complex password also adds to the security if an attacker would ever get their hands on the password database (if they don't store them as plain-text).

There are actually two scenarios regarding password security which are affected by the complexity and length of your password. The first one is an attacker who is only able to test against a black box, e.g. the login of a website. If your password would be too trivial like "password" then an attacker can gain easy access, even with a lot of security mechanisms in place (excluding two-factor authentication). This becomes much harder for an attacker the longer the password gets, especially since most websites limit login attempts.

The second scenario is a database breach where the attack has access to the password database. The security of your password, meaning "Is the attacker able to figure out my password?", does not only depend on you, but how the website handled all passwords. If the store them in plain-text you loose, no matter how complex they are. What is insecure, but often occurs, is simple hashing with no salt or a global salt for all accounts. In this case it helps having a complex and long password, because what the attacker does, is checking the hashes from the database against pre-computed lists of common passwords or even entire dictionaries of combinations. A long and complex password means more attempts are necessary for the attack.
A properly secured website should use a per user salt (and perhaps pepper), making rainbow-tables and dictionaries pretty much useless. This would even protect fairly simple passwords, but still the longer the better (or safer).

So the reason why you should use long and complex password is the first scenario and the second scenario in case of improper security. You can see as well, that the actual security also depends on the web-developers not just on your password.


How can this web page access the USB? A friend bought a "smart" headset (working with voice commands). I had to install a software on Windows to be able to configure this headset.

After downloading the software from the page, this page redirected to an configuration wizard (still on the web page!) and informed me that the software is not yet installed; I should click at Continue when I have installed the tool.

After installation and clicking continue, I had to plug in the headset via USB. As soon as I did that, the web page recognized it and offered various configuation options and it also showed a progress bar for updating the firmware.

How can this web page access (read from and write to) hardware on the USB? Or: How can this software "inject" itself into the web page?

At first I thought it might have installed a plugin resp. add-on in Firefox, but this was not the case. Would this be possible with Flash (I didn’t check if the page used Flash, only know that it didn’t use Java)? With JavaScript this shouldn’t be possible, right? I never saw such an installation/configuration method (though I’m not using Windows, so I don’t know if this might be common). It feels kind of fishy to me. Wouldn’t it have to "manipulate" the browser somehow? Is such a way recommended resp. can it be implemented securely at all?

When you install the local tool, anything goes (and it even requires local administrator rights !). The tool can inspect the USB hardware, and just needs a way to "talk" to the Web page. A relatively simple way is to make the tool run a local Web server, and have the page reference that Web server as an iframe. Thus, the user (you) will see the "configuration wizard" as occurring "in the Web page" but it would really be just a display thing, the actual processing being done in the locally installed tool.

There are other ways to make local code interact with a Web page, but a local Web server is one of the simplest and it is easy to make compatible with all the usual Web browsers.


Known methods/techniques for thwarting credential phising attacks Is the solution to preventing credential phising attacks is really only 'educating' people about it?

For the sake of this question, let us assume that I have a web application that takes a username and a password within a login form. Currently, as far as I know and could figure out, there is no way I can avoid an attacker phishing a vulnerable user of my web application into filling up a phished version of the login form prepared by an attacker.

What you need is that the use of credentials is  bound to the accessed domain or that the actual credentials are not transferred at all.

On the client side this can be achieved by using a password manager which stores the credentials for the domain and will only fill in the credentials if it matches the stored domain.

From the perspective of the web application this can be achieved by using authentication with client certificates. In order to steal these the attacker would need to get access to the clients private key, which is only accessible on the clients system and can not be retrieved with man in the middle or credential phishing attacks. Also, modern authentication methods like WebAuthn provide a comfortable way  for the user to authenticate (no password needed) and similar to client certificates makes it impossible for an attacker to steal the credentials with a phishing attack. Another method would be the use of the Digest Authentication built into the browser instead of creating your own login form. In this case no password is transferred but instead the client proves that it knows the password with some  challenge-response method. Unfortunately the server has to store the plain password or some equivalent in order to verify the users response.


How do you detect load balancing? Scenario

You need to PenTest XYZ.com.

You expect, because it is a high traffic site, that multiple servers are being used with a load balancer.

Question

Aside from pulling the MACs (which are obviously different) of the "balanced" servers, how can you detect balancing?

Properly implemented, load balancing can be totally transparent; you may need to rely on other means (such as hunting though job ads for the company) to try guess at likely products.

However there are a few things you can check that at least imply the existance of a balancer:

The HTTP headers may reveal the presense of a proxy server or other balancer.

Check here for different timestamps as well, implying slightly different clocks.
Check the order of the headers as well.

Observe the system under load

Generate a ton of traffic; see if your requests start going somewhere else, or if the headers change, etc.

General reconnaisance

The DNS response may reveal multiple IP addresses, implying balancing.
They may give it away in the hostname (cdn.xyz.com)
You may be able to get some more info from netcraft.com that leads you in the right direction

The manual  for halberd contains a good list of concepts that it uses (Date comparison; MIME header ﬁeld names, values and their order; Generating high amounts of traﬃc; Using diﬀerent URLs; Detecting server-side caches; Obtaining public IP addresses).

Using halberd or ldb is likely your best option in a practical situation - a lot of these tests are time consuming and finicky, so you likely want to automate all the busy work.


How do small businesses handle web app security? Everything on Owasp's top 10 list, how do current small businesses (< 1000 employees) handle web application security, along with mobile security of their applications?

Do they care about info/app security? Do businesses of this size pay for static code analysis, or penetration testing? Or do they use some open-source framework/software to test?

My experience is it depends on industry, regulations, and business relationships (not necessarily company size).

Examples:

<10 person company, building a web app that retrieves credit
history, they were required by business partners to have a full
webapp pentest
<50 person company, building a web portal allowing
customers to view point of sale information, they fell under
regulatory requirements (PCI) and partner requests to have their
portal pentested
<5 person start-up trying to sell their web app
to a bigger business, they were required to get their app evaluated
for security during due diligence (code audit + pentest)
nearly all businesses building banking/financial web apps, in my experience,
have to do something to show security is evaluated and usually for
regulatory reasons (code audit + pentest)

Many smaller businesses choose pentesting over code auditing because it is typically cheaper (and they may not have access to all the source code if they utilize other commercial components).


Is it possible to get the salt if I have the hash and original password? Is it possible to get the salt if I have the hash and original password?

My gut feeling is no, but would it be impossible or will it just take very long?

Getting salt from hash(salt+password) would be just as difficult as getting password from hash(salt+password).


How does Mylar ensure encrypted data remains secure even if the live app code is compromised Because Mylar does the decryption in the browser, the key is never stored on the server. Nice. This moves the threat to the browser, where, if the attacker is able to get a malicious script to be served to the browser along with the Mylar related app/data, then the script could just harvest the decrypted data.

So, how does Mylar ensure the app code that is served to the browser isn't malicious?

I see in this document: http://www.mit.edu/~ralucap/mylar.pdf

  Verifying application code. With Mylar, code running in a web browser
  has access to the user’s decrypted data and keys, but the code itself
  comes from the untrusted server. To ensure that this code has not been
  tampered with, Mylar checks that the code is properly signed by the
  web site owner. This checking is possible because application code and
  data are separate in Mylar, so the code is static. Mylar uses two
  origins to simplify code verification for a web application. The
  primary origin hosts only the top-level HTML page of the application,
  whose signature is verified using a public key found in the server’s
  X.509 certificate. All other files come from a secondary origin, so
  that if they are loaded as a top-level page, they do not have access
  to the primary origin. Mylar verifies the hash of these files against
  an expected hash contained in the top-level page.

So an app code hash/signature is checked. Nice, assuming this hash/signature hasn't been compromised we can know the codebase is valid against a specific release. I also see that Mylar uses two origins. What if both origins are compromised? Also, could one of the origins be a specific git repo commit hash? What are the possible issues with somehow interfering with this verification step?

I'd love to understand more about how this specific security feature works and how it is secure.

Mylar requires using Meteor. Because of the separation of data and format in the Meteor framework, it can actually sign the application template. In a normal web app the browser receives the concatenation of the data and the presentation as one element; in a dynamic web app you can not sign the page because you don't know what the output will be at run time.

If the attacker doesn't also have the ability to sign the files being served, an error will happen because the signatures are not valid. If the attacker has the ability to impersonate the legitimate user for signing purposes, that's almost as bad as having the root CA keys in the PKI world, game over.


Are these Ports safe to have open? I have a netgear router I recently hooked up to my other router provided by Xfinity(It sucks ass*). And I mostly use this router for my PS4 and Raspberry Pi because it just has a better wifi signal than the Xfinity.
But I currently did a NMAP scan of my router and came up with this:

Nmap scan report for 192.168.1.1
Host is up (0.0018s latency).
Not shown: 991 closed ports
PORT      STATE SERVICE
53/tcp    open  domain
80/tcp    open  http
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
548/tcp   open  afp
631/tcp   open  ipp
5000/tcp  open  upnp
8200/tcp  open  trivnet1
20005/tcp open  btx
MAC Address: E4:F4:C6:xx:xx:xx (Netgear)
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.19 - 2.6.36

I have currently updated the routers firmware since the recent botnet attacks and the exploit of the NETGEAR routers which is suppose to cure my R7000.

Im curious if these ports alert anybody?

You are performing an NMAP scan from inside the network. Just because these ports show as being open internally, doesn't mean they show as being open outside of the network.

Grab your external IP and run an online port scan - this will give you an idea of what ports are open to the world, or a potential 'hacker'.


How to get JS content fron XSSI vulnerability? I'm learning about XSSI attacks and I'm wondering if the following dynamic JS  can be used to access the content.

Dinamic.js:

if (window.location.hostname === 'Demo.site.com' ){
    updateLoginHeader('Nick', 'IWANT-THIS-SECRET'); }

Can the attacker retrieve IWANT-THIS-SECRET using javascript tag? I was trying something like:

<script type="text/javascript">
var secrets;

Array = function() {
  secrets = this;
};
</script>

<script src="https://example.com/Dinamic.js"
  type="text/javascript"></script>

<script type="text/javascript">

  var yourData = '';
  var i = -1;
  while(secrets[++i]) {
    yourData += secrets[i] + ' ';
  }

  alert('I stole your data: ' + yourData);
</script>

Any ideas to retrieve IWANT-THIS-SECRET?

For a successful cross-site script inclusion attack you'd have to bypass this origin check:

if (window.location.hostname === 'Demo.site.com')

That isn't possible because modern browsers don't allow you to override window.location, as explained here and here. The hostname property is read-only for security reasons. This means that only Demo.site.com can access the IWANT-THIS-SECRET token by executing the JS file.

In older browsers, a redefinition of the property could have looked like this:

window.__defineGetter__("location", function(){
    return { hostname: "attacker.exmaple" }
});

But if you attempt that, you'll get an error message. E.g., for Firefox:

TypeError: can't redefine non-configurable property "location"

If you were able to bypass the origin check, a simple XSSI attack could then work like this:

<script>
function updateLoginHeader() {
    alert(arguments[1]);
}
</script>
<script src="https://targetsite.example/Dinamic.js"></script>

As you can see, you just have to define your own function that captures the "secret" function argument. (Your attempt to redefine Array looks more like an approach to JSON hijacking which isn't helpful here and would also generally be unsuccessful in any modern browser.)


Can't I forge an SSL certificate? I read What's keeping a malicious man in the middle server from forging a valid certificate?, but when the client goes to verify the certificate, can't an attacker intercept that connection and say that the certificate is a valid certificate? Therefore, an attacker can send a forged certificate that the client could not verify. I don't get what would stop an attacker from creating a MITM (Man in the middle).

Not trivially.

What you're talking about is Public Key Infrastructure (PKI). The current implementation of it for SSL/TLS works in a hierarchical trust model. Your browser (and your OS) has a set of Certificate Authority (CA) certificates baked into it, which it trusts. Each certificate contains a CA's public key.

When an SSL certificate is created for a site, their issuing CA signs that cert with their private key. So the public key and details of the site is then signed with the CA's private key.

When you receive the certificate, your browser checks the certificate's signature using the CA's public key, which it has from the pre-installed CA certificates. You can't forge this signature without stealing the CA's private key, breaking the cryptography involved, or finding a bug in the browser's certificate validation code.

The attack you suggested is precisely what tools like Burp Suite can do, but since the generated certificate isn't signed by a trusted CA, the user's browser warns them that the certificate is self-signed.


Is Node.js on Debian Jessie really insecure? As I was reading the release notes for Debian Jessie, I came upon these paragraphs:

  The Node.js platform is built on top of libv8-3.14, which experiences
  a high volume of security issues, but there are currently no
  volunteers within the project or the security team sufficiently
  interested and willing to spend the large amount of time required to
  stem those incoming issues.

  Unfortunately, this means that libv8-3.14, nodejs, and the associated
  node-* package ecosystem should not currently be used with untrusted
  content, such as unsanitized data from the Internet.

  In addition, these packages will not receive any security updates
  during the lifetime of the Jessie release.

I read that as "don't run a web-facing Node.js application on this operating system" but is it really that bad?  It seems surprising to me that something as popular as Node.js would basically be warned against because of a lack of libv8 maintainers.

Are Debian recommending that you avoid running any web-facing Node.js service on Debian Jessie, or does it only apply to some more risky kinds of service?

This is because a stable release of Debian must stick with the feature version of the time when it turns stable.

Debian team clearly states it in their Q&A:

  2.2 Are there package upgrades in `stable'?

  No new functionality is added to the stable release. Once a Debian version is released and tagged `stable' it will only get security updates. That is, only packages for which a security vulnerability has been found after the release will be upgraded. All the security updates are served through security.debian.org.

To maintain the functional stability, they backport security fix on their own as needed.

  Security updates serve one purpose: to supply a fix for a security vulnerability. They are not a method for sneaking additional changes into the stable release without going through normal point release procedure. Consequently, fixes for packages with security issues will not upgrade the software. The Debian Security Team will backport the necessary fixes to the version of the software distributed in `stable' instead.

On the other hand, v8 is known for rapid release cycle. V8 wiki on GitHub says

  Roughly every 6 weeks a new major Stable release is done.

It also says

  As soon as a new branch is promoted to Stable, we stop maintaining the previous stable branch. This happens every six weeks, so you should be prepared to update at least this often.

Because Jessie was released on April 2015, we had dozen of stable v8 get released.
Generally speaking, as time passes by and serveral stable v8 released, it becomes increasingly difficult for Debian team to fix their package.
Appearently, they are lacking volunteers to do backport.

You could use it on your risk, but you are explicitly guided not to.


Does the practice of blocking an off-site "Referer:" HTTP requests improve website security? Is there any benefit for a security-paranoid website to disallow HTTP requests that have a  Referer: from 3rd party sites?

The pitch is that if such a HTTP request were to come in, then certain XSS attacks would be prevented, and certain OpenID iFrame threats as well.

The user experience would have all users in that case be redirected to a landing page.  That landing page would then direct them to either manually type in the URL, or to click a hyperlink.

Is this a good idea?

Short answer. Yes, blocking requests with an off-site Referer: header might have some security benefits, but I do not recommend that you implement it.  The usability costs are significant and outweigh any security benefits.

I feel that, as security professionals, our job is not just to recommend defenses that people should implement -- it is also to identify defenses that people should not implement.  This is one, in my personal opinion.

Background. Based on the original question, it sounds like it might be helpful to provide a review of the relevant background and articulate more precisely the specific defenses that you are likely considering.

You seem to be considering examining the Referer: header in incoming requests.  Most modern browsers set the Referer: header on most requests to list the URL of the previous page that triggered this request or that contained this link.  Some requests do not carry a Referer: header; one example is the prior page is over HTTPS, then browsers will not set the Referer: header.

It is important to know that the Referer: header was not designed for security, and cannot be trusted.  There are many attacks to cause a browser to omit the Referer: header.  There are also attacks that can be used against some browsers to forge the Referer: header (to cause the browser to send a request with a spoofed Referer: header of the attacker's choice).  Therefore, most security folks recommend that it is not a good idea to rely upon the Referer: header as your main line of security.

It is also important to know that the Referer: header is not guaranteed to be included, and sometimes it is blocked.  The Referer: header has privacy implications: it can be used to track people on the web.  Some people feel that it is a violation of their privacy for their browser to routinely tell site B that they were just at some specific page on site A.  Therefore, some people configure their browsers to block transmission of the Referer: header.  Also, some corporate firewalls and proxies strip out the Referer: header, to avoid leaking confidential or proprietary information to external web sites.

The original RFC (RFC 2068) states that the Referer: header is not mandatory, and explicitly recommends that browsers should provide a way for users to disable transmission of Referer: headers.

For all of those reasons, some fraction of legitimate requests just don't include a Referer: header.

Now, I suspect you are proposing one of two possible defenses:

Strict Referer checking. You designate a specified landing page on your site.  If your site receives a request with a Referer: header that refers to any URL not on your site, or receives a request with no Referer: header, then the server immediately responds with a redirect to your landing page.
Loose Referer checking. Same as the above, except that requests with no Referer: header are permitted (they don't trigger the redirect).

Loose Referer checking makes no sense, from a security perspective: there are too many ways that an attacker can trigger a victim's browser to make a request and suppress the Referer:.  So I will presume that you are considering whether to implement strict Referer checking.

Security benefits. So, does strict Referer checking have potential security benefits?  Yes.  They include:

CSRF defense. Strict referer checking makes it harder to mount cross-site request forgery attacks, because other sites cannot direct the user anywhere other than the landing page.
XSS defense. Strict referer checking can make reflective XSS attacks harder, because other sites can't trick the victim's browser into visiting the vulnerable URL.
Clickjacking and framing. I don't know whether strict referer checking helps against clickjacking or being framed.  I'll have to leave that to others.

There are some caveats, though.  For each of these risks, there are better defenses known.  For instance, for CSRF defense, use anti-CSRF tokens.  For XSS defense, don't introduce XSS bugs into your software; use template systems with context-sensitive automatic escaping; etc.  For clickjacking and framing, use time-tested frame-busting techniques.

Usability costs. There are some major usability costs to enabling strict referer checking throughout your site.  These include:

It prevents deep linking. It prevents people from linking to pages on your web site.  This means you won't get traffic that others send you, because they link to something great on your site.
It prevents deep bookmarking. It prevents your users from bookmarking anything other than the landing page.  That's just annoying, from a user's standpoint.
It blocks some users. Some users won't be able to use your site, either because they use privacy mechanisms that block Referer: headers, or because they're behind a corporate firewall that strips Referer: headers, or the like.  This reduces your potential user base.  Also, some of the folks who block Referer: headers are the most tech-savvy users, who are potentially your early adopters who might evangelize your site to others; you don't want to unnecessarily block them from using your site.

Overall. So, when I look at this, I see some dubious security benefits, and major usability costs.  Moreover, all of those security benefits can be obtained in other ways that don't damage usability, simply by using standard security mechanisms.  Therefore, I don't recommend that you adopt strict referer checking.


My boss installs software using domain admin. Should I show that this is bad? At my workplace, users on most workstations (Win7 and 10 blend) do not have local admin rights. As a technical team we often need this for software installs, and so the director gets called around to enter credentials. Not only is this painful for everyone involved, but Domain Admin privileges are used 100% of the time. We recently had a disgruntled employee try to do some damage on their way out of the company, and if they had access to this account (which really would have been trivial to do) the results could have been disastrous.

I want to explain and or demonstrate why this is such bad practice, but a) I am a permanent casual employee (still at uni) and b) there is another department head who is very paranoid about a very outdated/misguided view of security, and I imagine they would take great offense. To top this all off, the IT service provider we are with is utterly incompetent, so even if this practice is not by their design, they certainly wouldn’t take any steps to prevent it.

Is it advisable to in any way approach either the director or my manager about why this is hopelessly insecure, or should I just bide my time and hope there is no incident while I am at the company.

For the record, IT support or admin is in no way shape or form a part of my job description, though I am well known in the office as the computer guy that can get things done.

Using domain admin in the current days is like totally ignoring the network security and opening up the gates to the attackers! With tons of security breaches being announced everyday, Active Directory security in an enterprise plays a key role.

Below links detail the common mistakes of Active Directory deployments and the attacks because of the malpractices!

https://blog.netwrix.com/2017/11/22/active-directory-management-top-7-common-mistakes/

https://www.peerlyst.com/posts/taking-windows-domain-lateral-movement-to-the-next-level-mimikatz-less-instant-lateral-movement-claus-cramon

Below link is an exhaustive list on various security considerations for Active Directory deployments!

https://activedirectorypro.com/active-directory-security-best-practices/

I agree that there are members of senior management who doesn't bother about security, but it's the matter of survival in the digital era. With one small loophole in your network, you might end up as a victim with irreparable damage.

Cheers!


Session cookie secure flag: best practice There are 2 ways of setting 'secure' flag on a session cookie:

In the application itself, for exemple:

<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>

In the configuration of TLS proxy like httpd.

I can't find any article telling which one is the best practice.

The most secure is likely to be 2, while the most logical is the 1, since it only works with HTTPS.

I recommend its better to use both of them together as it doesn't cause any harm. Also, it ensures philosophy of Defense in Depth.

These days people are deploying on cloud and migrations are more often done. So,I think we cannot be sure that the configuration 2 you mentioned for httpd is in place all the time.

You should consider that enabling <secure>true</secure>  in application is mandatory. Explanation given below.

Explanation:

Scenario 1(Assuming secure flag setting missed by TLS proxy/httpd)

I tested a scenario where I have only enabled  <secure>true</secure> in the application itself and not configured secure flag via TLS proxy(httpd).

Now the Response Header  has a cookie with secure flag, I observed that Firefox and Chrome process and save the cookie with secure flag.

Set-Cookie: acct=tafats; domain=localhost; Secure;expires=Thu, 16-Mar-2017 15:19:48 GMT; path=/; HttpOnly

From a Security point of view this is what is to be expected from browsers.

This protects you from session-hijacking attempts via packet sniffing.

In this case,If the attacker makes the user to click on http://example.com, the cookie is not sent because it has a secure flag.

Here, the <secure>true</secure> came to rescue.

Scenario 2(Assuming secure flag setting missed in the application but configured in TLS proxy/httpd)

Its good enough , as long as you have this secure flag set via TLS proxy. But the catch here is, you need to ensure that this TLS proxy setting is configured for all deployments you do all the time.

  To conclude, I recommend its better to use both of them together and
  ensure the philosophy of Defense in Depth.


Very strange gibberish strings with Cyrillic characters that appear in random websites and elsewhere In my work with online orders, I started noticing an extreme abnormality in a few orders. In one field that wasn't restricted there appeared a string of over 3 million characters that were totally gibberish consisting mostly of Cyrillic characters. On closer examination using Python, it turned out it was actually a list of over a thousand of such gibberish strings. I dug deeper and found more instances of that, the worst with a string of over 58 million characters consisting of over 18000 list elements.

So we have a string that consists of several lists of strings, those strings again consist of several gibberish words separated by non-breaking spaces.

An example (I added linebreaks for readability):

'Р В Р’В Р вЂ™Р’В Р В РІР‚в„ўР вЂ™Р’В Р В Р’В Р Р†Р вЂљРІвЂћСћР В РІР‚в„ўР
 вЂ™Р’В Р В Р’В Р вЂ™Р’В Р В Р вЂ Р В РІР‚С™Р Р†РІР‚С›РЎС›Р В Р’В Р Р†Р
 вЂљРІвЂћСћР В РІР‚в„ўР вЂ™Р’В Р В Р’В Р вЂ™Р’В Р В РІР‚в„ўР вЂ™Р’В Р В Р’В Р
 В РІР‚В Р В Р’В Р Р†Р вЂљРЎв„ўР В Р вЂ Р Р†Р вЂљРЎвЂєР РЋРЎвЂєР В Р’В Р
 вЂ™Р’В Р В Р вЂ Р В РІР‚С™Р Р†РІР‚С›РЎС›Р В Р’В Р Р†Р вЂљРІвЂћСћР В РІР‚в„ўР
 вЂ™Р’В Р В Р’В Р вЂ™Р’В Р В РІР‚в„ўР вЂ™Р’В Р В Р’В Р Р†Р вЂљРІвЂћСћР В
 РІР‚в„ўР вЂ™Р’В Р В Р’В Р вЂ™Р’В Р В Р’В Р Р†Р вЂљР’В Р В Р’В Р вЂ™Р’В Р В Р
 вЂ Р В РІР‚С™Р РЋРІвЂћСћР В Р’В Р В РІР‚В Р В Р вЂ Р В РІР‚С™Р РЋРІР‚С”Р В Р
 Р‹Р РЋРІР‚С”Р В Р’В Р вЂ™Р’В Р В РІР‚в„ўР вЂ™Р’В Р В Р’В Р В РІР‚В Р В Р’В Р
 Р†Р вЂљРЎв„ўР В Р вЂ Р Р†Р вЂљРЎвЂєР РЋРЎвЂєР В Р’В Р вЂ™Р’В Р В Р вЂ Р В
 РІР‚С™Р Р†РІР‚С›РЎС›Р В Р’В Р Р†Р вЂљРІвЂћСћР В РІР‚в„ўР вЂ™Р’В Р В Р’В Р вЂ

The following is a count of the 10 most common words in the 58 million character string:

Р                     2453256
В                     1926812
Р’В                    895699
вЂ™Р’В                 822674
Р†Р                    399677
РІР‚в„ўР               382349
вЂ                     235180
РІР‚С™Р                185503
вЂљРІвЂћСћР            177792
РІР‚В                  109266
Р†РІР‚С›РЎС›Р          101490

Now take e.g. the string "РІР‚в„ўР" and put it into google. I'm getting over a million seemingly random sites where those strings are inserted into the source code of the sites.

I have absolutely no idea what to make of this, does anyone know what this is?

I was looking around websites with the same problem as you.

One of them is a french website and here is the text inside:

  Mon banquier ne mР В Р вЂ Р В РІР‚С™Р Р†РІР‚С›РЎС›appelle plus pour mon dР В РІР‚СљР вЂ™Р’В©couvert, nous Р В РІР‚СљР вЂ™Р’В©changeons dorР В РІР‚СљР вЂ™Р’В©navant sur mes nouveaux projets

The non-alphanumeric characters (not a-z/A-Z) are replaced by the 'Cyrillic' characters.
In this text there are ',é ...

In this case, it looks like an ASCII encoding problem where a multi-byte character is considered multiple uni-byte characters. So a two-byte character will become two one-byte characters.

I wandered around and found out that it could be linked to database encoding databases format. But I'm not an expert in databases and maybe someone with greater knowledge can complete the explanation.

So as @james-k-polk said, the characters you're seeing are either not supposed to be displayed as characters orz in my opinionz they are just badly converted from one format to another.


CEH resources for exam prep For an upcoming contract I'm required to have the CEH certification (even though there won't be much PenTesting) so I'm working through that now. I've gone through all of the reccomended EC Council books but they seem light on the details of specific vulnerabilities and enumeration methods and are more a description of the tools (many of which are outdated).

Resources I've found: mindcert.com mindmaps interesting, the EC Council books to be useless, ethicalhacker.net is always good.

I'm wondering two things:

1.) How does this exam stack up to others I've completed such as:

CISSPSecurity+CWSPCCIE (written)

2.) What resources did you find valuable studying for the CEH and what was your feeling about the exam?

CEH as a requirement would suggest that the business area does not totally get what it is they are needing. This exam does nothing to confirm that the person holding the certification can effectively or safely deliver a test.

CEH is based on being able to retain a huge amount of detail that is not directly valuable in the real world. Examples would be around being shown a snort command with flags and being asked to remember what each flag does. Personally I find using the man snort or snort -? works just as well.

The exam was focused on tools and flags for tools - so if your aim is to understand how 200+ tools can be used rather than the best of breed then go for it. Again, 20 different ways to port scan a system rather than understanding how best to use AMAP and NMAP was a frustration, and the section on the use and deployment of real world 'Trojans and Viruses' was a worry as I would not expect a tester to be running around on an internal live network with real Trojans and Viruses!!!

In terms of comparison to CISSP and Security+ - both are focused on information retention and knowing the exam answer rather than the real world way of doing it and I would say to an extent that CEH is the same.

As an alternative and potentially more benefit to you in terms of wider progression, could be gaining the OSSTMM Professional Security Tester OPST which tests your ability to complete a number of real world exercises using the tool of your choice. The exam paper is also marked by a real person and graded rather than a multiple choice computer scored approach or the Global Information Assurance Certification GIAC route. This is a SANS based approach where you can complete training courses run by SANS or have the knowledge required and then complete the relevant GIAC exam. For Penetration testing the relevant course would be the GPEN Certification. I have not personally completed the GPEN but do hold the Certified Intrusion Analyst GCIA award and found the mix of knowledge and application to be of real value.


How to send remotely loadable CSS with an email as explained in ROPEMAKER whitepaper? I have been reading the ROPEMAKER exploit whitepaper by Mimecast. In the article they are mentioning of sending a safe HTML(which may contain evil text, but as long as it is a plain HTML its safe with respect to the protective mechanisms at the recipients end) to the recipient and do the exploit by selectively displaying the necessary fields in the HTML using remotely loadable CSS.

I don't really get the idea of remotely loadable CSS for emails. How can an attacker/user send CSS along with the email body and load it remotely at the recipient end?

Is this actually possible? If yes, how?

There are two ways of include resources inside an email HTML part: as links to external sites (i.e. <img src=http://example.com/... or <link rel=stylesheet href=http://example.com/...) or by referencing different MIME parts inside the same mail (i.e. <link rel=stylesheet href="cid:some-id-in-the-mail">). The "exploit" just uses the first way, i.e. loading the CSS from a server controlled by the attacker where he can serve different CSS on different times, thus causing changes in the rendering of the HTML.


Certificate Revocation List (CRL) checking Best Practice I have an application that uses TLS to secure communication between the two parties. The certificates involved have (Certificate Revocation List) CRL distribution points included. The CRL distribution point may or may not be contactable.

In the event that the distribution point in not contactable or is very slow, should my application refuse to make the connection until I have managed to fetch the CRL or should things proceed as per normal and action only taken when a certificate is found to be revoked?

If anyone can point me to RFCs or industry best practice in the regard, I will appreciate it.

I would go with strict certificate revocation checking and reject certificate for which revocation information is not available.

Why? If you are going to take actions (reject connection) when the certificate is revoked, you need to have this information (from CRL/OCSP). If the information is not available, you cannot determine whether the certificate is revoked or not. From the security perspective, the certificate is invalid unless opposite is proven. This means that the certificate should be considered revoked unless at least one reliable source (valid CRL and/or OCSP response) tells you that the certificate is not revoked (CRL does not contain subject's serial number in the revoked certificates list and/or OCSP explicitly says that the certificate's revocation status is good).

General rules/algorithm are described in the RFC5280 §6.3


What are the security implications of connecting to Tor through an SSH SOCKS proxy? Suppose I have a user account on a remote server run by a friend.

I create a SOCKS tunnel on my computer that forwards connections from a local port to the remote server: ssh -N -D 12345 john@10.1.1.5 (i.e. all local connections to localhost:12345 gets forwarded to the 10.1.1.5 server).

I configure the connection settings on the Tor browser to connect to the Tor network through a proxy: the SOCKS proxy on localhost:12345 that I just created.

The question: what are the security implications of this scheme? What can the remote server (10.1.1.5) see when I browse the web through the Tor browser?

Presumably, the remote server will be able to log connections and determine the sizes of the HTTP requests made through the Tor browser, but will it be able to determine the specific websites visited, or eavesdrop on POST requests?

The specific details for your proxy setup are irrelevant. It doesn't matter if it's done through SSH port forwarding or OpenVPN or IPSec or GRE. What matters is whether or not someone who can monitor the connection between your local Tor process and the Tor network can glean any useful information. The answer is no, they really can't get much. The connection is encrypted so the plaintext contents of the communication, in addition to the destination, are all opaque to the proxy. Yes, it is possible to analyze packet sizes and timing, but it is difficult and largely a theoretical risk. It is made more difficult due to some basic padding done by Tor (all transmissions occur in chunks of 514 bytes, never less). The two primary types of attacks are traffic correlation attacks and website fingerprinting attacks:

Traffic correlation attacks involve a malicious ISP, guard, or proxy that you are using to connect to the Tor network collaborating with a malicious or monitored website or exit node. In theory, the packet timings can reveal that you have connected to the website. This is not so easy in practice because there are a huge number of people using the Tor network, so it becomes difficult to tell whether or not a correlation of packet timings is just coincidence. An adversary who is able to passively monitor all connections globally may be able to mount this attack.

Website fingerprinting attacks exploit he fact that websites do not all behave identically in terms of amount of data sent. If YouTube and Stack Exchange were the only websites in the world, then it would be trivial to tell, based on packet sizes alone, which of the websites you visited even if the connection is encrypted. However there are more than two websites, and determining which website you visited amongst billions of websites and hundreds or thousands of pages per website is quite impractical. Even still, Tor Project is working on solutions to that.


Sensitive information was placed in a publicly accessible folder. Who is responsible and how to proceed? Background
We have an IT staff who manages our server and a web developer who is not on the IT staff and has no root access to the server. All involved do very high quality work and I do not consider this lapse to be particularly grievous, given the relatively small consequences of not having this information secure. I am primarily interested in learning from this experience.
Last week, our web developer sent an email to me and the IT staff:

I did not realize that [project1] and [project2] had been put directly inside of /var/www on [my-server], but thought they had been put outside of publicly accessible space. I have corrected permissions to prevent access to anything sensitive at the moment, but they should not be in /var/www as only the 'public' folders need to be linked there.
Because of this all the files in the [project1] and [project2] projects have been accessible to the web since the start of the projects. From this people would have had access to all files in the projects, even access to database dumps and logs that have been stored there. It would be worth while to know if anyone has ever accessed any files in the 'path/to/project1/db_backups', 'path/to/project1/config', 'path/to/project1/db', 'rails/project2/db', 'rails/project2/config' folders as stored passwords could be found in these folders.

Questions

Was I at fault for assuming that either the IT staff or the web developer should have dealt with this?
Who is responsible for making sure that sensitive information is properly secured?
Are there steps beyond checking logs that I should take?

I would be reluctant to parcel out blame, particularly when it is clearly an honest mistake.  Too much focus on blame on one incident can poison the well and make people more reluctant to report security incidents in the future.  Even without any blame involved, it is already embarrassing enough to have to report that you screwed up and may have contributed to a security exposure.  I like that you say "I am primarily interested in learning from this experience" -- I think that's a very healthy and constructive attitude, and I encourage you to repeat it widely so everyone involved knows it, and act in a corresponding way.

By the way, you can think of this as an opportunity to model how you react to security issues.  Culture gets set not by the words company leaders say, but by the way they act -- especially the way they act when in a tough spot.  Modeling the "this is not about blame, it's about learning from the experience" attitude seems like a nice way to make a contribution to a healthy culture that will serve you well in the future.

Back to your core question.  I think the primary answer to this question is probably: communication.  The first step is for the folks involved to talk about this, and agree on whose responsibility it is.  Is it the responsibility of the web admin to confirm that all content which is put on the public web server, really is intended to be public?  Is it the responsibility of the person who is posting the content?  How would these people know whose responsibility it is?

Perhaps one possible lesson you could consider is: be cautious about what filesystems/mount points/shared directories you mount on your public webserver.  You might want to have a rule of thumb that there is a separation: each filesystem/shared directory is either (a) public, or (b) internal, and label the filesystem/shared directory accordingly.  Under this approach, you would avoid having a filesystem that contains some public files and some non-public files -- and when you add a new filesystem/shared directory to the public webserver, you might do a quick sanity-check to see whether that filesystem is indeed marked as public.  This is just one idea, and of course, it may or may not be suitable for you.  Don't get too caught up in the details of this particular idea; if it doesn't sound helpful, ignore it.  The more important point is to think a little bit about processes that can help you avoid these errors -- without getting yourself bogged down in needless bureaucracy.  You will know best what the culture and requirements of your company are like; you should be in a good position to brainstorm some ideas and start that conversation with your co-workers.


How ATM Surveillance Camera works? I would like to know how the ATM pin hole camera works.Whether the pin hole camera works only once the card is inserted in ATM or during the cash withdrawal or it works always?

I interned at JP Morgan last summer. They said their ATM's cameras were on all the time. It may vary depending on the bank though.


Security risk of using virtual hosts for public and internal sites I have an Apache server which hosts a public website and an internal website. However, since Apache denotes virtual hosts based on the Host HTTP header, couldn't someone on the Internet request my server's IP with the Host header set to its internal name/IP?

Yes, that's possible.  In fact, if the internal name is in (global) DNS, they can request the internal site by name.

However, you can still do what you're trying to do and be (mostly) secure.  You don't say what version of Apache you're running, and things changed slightly for version 2.3.  In Apache 2.3 or 2.4, you can use mod_authz_host to restrict the internal server to specific IP addresses, namely those on your internal network.  So, you could do something like this:

Require ip 10.1
Require ip 10.2 172.20 192.168.2

Depending on the complexity of the local network, one Require ip may be enough.  The full documentation is here: http://httpd.apache.org/docs/current/mod/mod_authz_host.html

For versions prior to Apache 2.3, you would use mod_access (http://www.auburn.edu/docs/apache/mod/mod_access.html) which works slightly differently but can accomplish the same thing.

You are still running the external and internal sites on the same instance of Apache, so an error in Apache itself could potentially expose internal pages to the outside.  So could errors in setting up the access controls or errors in placing files.  Access via VPN will present an address from the VPN concentrator, so those will look like 'internal' requests, which is probably good.  Finally, requests from a proxy server will present the address of the proxy.  That probably doesn't apply; there's a note in the apache docs about this.

You can increase security somewhat by using a server with two network interfaces and assigning each virtual host to its own interface.  You'd use an internal (RFC 1918) IP address to the internal virtual server.  For best security, you need two physical machines, one on the internal network, with an internal address, and one in the DMZ with a registered (or port-forwarded) address.

Finally, you could require authentication (login) for the internal server.  Whether this is practical or necessary. depends upon the number of people who will be using the internal server and how sensitive it is.


NSA Suite A Cryptography: Security through obscurity? What is the opinion of scholars, cryptographers on NSA Suite A? Containing unpublished algorithms. Could it really be that much better than the published algorithms besides being obscure and not documented publicly?

My opinion (and I am a cryptographer -- I have a shiny diploma which says so) is that:

We cannot speculate on unknown algorithms, because they are, well, unknown.
NSA is like all secret services in the World, they really love secrecy and will practice it for the sake of it. So the fact that their algorithms are not published is in no way indicative of some particular strength or weakness of the said algorithms.
It is entirely plausible that the unpublished algorithms are indeed distinct from publicly known algorithms such as AES or RSA.
It is also entirely plausible that "Suite A" and "Suite B" are, in fact, identical. At some point, to use some algorithms, you must have implementations, and these things do not grow on trees. Having your own algorithms is thus expensive.
If I were a US taxpayer, I would be slightly dismayed at the misuse of my tax money, if it turned out that NSA spent it on developing and maintaining custom algorithms instead of reusing perfectly fine ones like the AES.
There most probably are some people with power to decide a lot of things in the NSA, who believe that not publishing algorithms increases their security. Such people exist everywhere. It does not make them right, though.
There is no better security than "cannot break it", which is what we already have with (properly used) AES, RSA, DH, ECC... The NSA could know of faster algorithms which are as secure as the public ones; however, it would be hard to beat the performance of hardware-accelerated AES, unless they have their own CPU foundry.

The danger in security by obscurity is in believing that it works well. It may induce people to feel safe with homemade algorithms, because they would assume that the obscurity will hide the weaknesses of their algorithms. However, if you use good algorithms with published and well-studied protocols (i.e. AES, SSL...) then there is no harm done in not saying that you do.


Firefox password manager and Firefox Sync I have just migrated from LastPass to default Firefox Password Manager and Firefox Sync.
I have some doubts about using Firefox Password Manager and Firefox Sync.
Let's assume I don't use a master password:

can a Firefox addon access and read my saved passwords and somehow steal them from me (so the person/people who created the addon can view my passwords)? (e.g. I use this addon)
can a Firefox addon access and read my saved passwords stored with Firefox Sync and somehow steal them from me (so the person/people who created the addon can view my passwords)?
is Firefox Sync better than LastPass when considering security? Can I trust their servers? How does Firefox Sync security work?
If I don't use a master password in Firefox Password Manager is it true that the only way for someone to steal my passwords is by accessing my filesystem, so both websites and addons can't view my passwords without my permission (refer to 1. and 2.)?

Thanks

Obviously, yes. Addons can access the saved passwords. You yourself are using an add-on that can save, read, and edit passwords. I'm not really sure why this is part of your question. Regardless, even without this ability, addons often use access to website content to do same legitimate task. It would not be hard to also scrape text from password fields.
Yes. Synchronized passwords are no different from other saved passwords. They all get saved to the same place and they all get synchronized if you turn the option on.
As far as I can tell, the security model is about the same, if you use a master password. You encrypt locally, so anyone breaking into the server will need to break your master password to read any login credentials. Without a master password, Mozilla still encrypts your passwords using your sync account password, so even if data is stolen from Mozilla's servers, your passwords should be as safe, if your Sync password is strong. Of course if the break into Mozilla they'll get a lot more information than just passwords (e.g. synchronized bookmarks, saved browsing history, etc.) I don't think anyone is really qualified to compare security practices between the two, unless they've done pen-testing with both or something. As for user security, I think LastPass supports 2-factor authentication, so they may even get the win in security, if you use that feature. That said... LastPass has had at least two breaches I've heard about, whereas Mozilla has had none I know about. So ¯\_(ツ)_/¯.
In a sense, yes, local access is needed. Considering the encryption discussed above, Mozilla never has your password data in usable form. But local access could be any program running as your user account, or any Firefox add-on, as discussed above. With a master password, Firefox must be running with your master password entered, or your master password must be stolen with a key logger. Without a master password your saved passwords can be read at any time by programs running on your device. If your full disk is not encrypted, and you don't securely erase/destroy it when you discard your device, your saved passwords can be obtained from there as well if you do not use a master password. Same story for any disk backup storage you may use. More common sources of leaks are people accidentally posting them publicly along with their other Firefox config data when trying to get support or backing up their user directory or something. So I guess the answer here depends on what you're trying to protect against.


Should diffie-hellman parameters be unique to a vhost So I'm setting up one host to serve multiple SSL sites. I've been following various guides like https://cipherli.st/ and https://wiki.mozilla.org/Security/Server_Side_TLS and they both suggest to specify diffie-hellman parameters to get forward secrecy. So my question is: should I generate a new prime number for each virtual host on the system, or is it alright to share one between all the virtual hosts.

My reading of the mozilla article says that it's not that big a deal since the key generated from the exchange is ephemeral anyways, so as long as the prime is large enough (2048 bits being recommended), it should be alright?

There is no formal problem, from a cryptographic point of view, in reuse of the same DH parameters (modulus and generators) by multiple people. What the recent Logjam attack highlights is that if the modulus is so small that it can be broken in practice, then the attacker can reuse most of the attack effort for subsequent breakages of DH instances that use the same parameters. In that sense, it can be argued that sharing the same DH parameters with the rest of the Internet increases the consequences of a successful cryptanalytic break; however, it can be equally argued (and, in my opinion, more convincingly) that the real problem is using the same weak modulus as everybody else lies in the "weak", not in the "same". If you use a properly generated 2048-bit modulus then no breakage shall occur at all, and sharing is harmless.

You may notice that elliptic curve variants of Diffie-Hellman commonly use the extremely widespread P-256 curve, so that's Internet-wide sharing, and that does not appear to be a problem. Arjen Lenstra once told me that it made that curve a "big, fat target", and I agree with him, but, right now, there is no known way to break that curve in realistic time. (Everybody uses the same curve because producing your own curve is not very easy, and also because specializing implementations for a single curve grants some extra performance.)


Two issuing CAs in a two-tier PKI (Windows Server 2012) I'm planning to setup two-tier PKI in my environment. We have two remote sites connected via a VPN. I think it is OK to set up both Root CA and Issuing CA on the 1st site.

But, for example, I have internal web server on the 2nd site.

Am I right that, if the VPN fails, clients on the 2nd site still can establish HTTPS connection to the web-server on this site?
Is it a good idea to set up second Issuing CA on the 2nd site? Also, I'm
confused how to deal with CDP in this case, because currently I'm planning to create distribution point via web-server on the 1st Issuing CA?

I've used this guide for information purposes.

Your CAs are only used to issue the certificates and revocation lists - once issued, the CAs are redundant until such time as you wish to issue more certificates or issue/renew a CRL.

Revocation information, on the other hand, needs to be available 24/7. Some (all?) clients cache the revocation information, which may give you some leeway, but even so, you should consider your CDP up time to be far more significant than your CA up time.

If you are concerned about the reliability of your VPN, then consider running a CDP at either end.  Some DNS magic (split DNS?) may allow you to have the URL of your CDP to point to the client's local site regardless of whether it is site 1 or 2.

Therefore, to answer your question:

The clients on the remote site can access a HTTPS website on that remote site only if revocation information is available to the client; assuming the client checks revocation, of course.
While you can place a 2nd CA on the remote site, managing certificates becomes a little harder then. A better plan would be to have a single issuing CA and multiple CDPs.  Of course, if your VPN is down more than it is up, then it may be better to consider them as two isolated sites and run a CA and CDP at each.


TOR security if ISP blocks TLS channel? If ISP blocks TLS channel while a user is using TOR, can he read the TOR traffic, since TOR uses TLS encryption ?

No.  Blocking a channel simply means that communication cannot take place along that channel.  In order to read the content of a TLS channel, the attacker (in this case, the ISP) would need copies of the secret keys involved.


Design for secure offline storage of key with two or more parties by key sharing Design:

People should be able to store the partial-key in a unobtrusive form but the unobtrusive form should not be used to decrypt sensitive content on its own.

The design should allow to be plausible deniable because the parts should not look like keys.

How it works

Two (or more) pieces of information like numbers are fed to the software. The software derives a password from it that is used to decrypt the real sensitive stuff.

User A has the unobtrusive key '1234'
User B has the unobtrusive key '5678'

Together they form '12345678' and the software derives a key from this string.

It's like two people come to a safe box and the safe box only opens with two keys at the same time.

Key derivation method

Secure key derivation method can be used on the final string like PBKDF2  with custom iteration count
The iteration could also be calculated from the final string (something like crc32 + 10000

Threat model:

One piece of the key can be compromised without revealing the other one
Key can be something unobtrusive, anything that translates in to a sequence where a key can be derived from (string, file & etc.)

Out of scope:

Keyloggers
Malware
Encryption algorithm

Failure:

Attacker gets hold of things and feds them in to the software

Cons:

Somewhat Security by obscurity

Pros:

Non-technical users can handle it better than a saved password
One key alone does not translate to a password. It will be derived from the whole sequence of keys
Can be stored in any form as long as it can be translated back to a sequence of data (post it note, image file & etc).
Plausible deniability - The unobtrusive key can look like a regular item

Questions:

What would be a realistic attack for this storage method?
How can it be improved?
(sarcasm) What could possibly go wrong? (/sarcasm)

To summarize your design: you combine arbitrary secret data which can be held by different people with some hash function into a secret key which is then used to protect some secret data.

  What would be a realistic attack for this storage method?

One possible attack against this method is to somehow collect all the separate parts which are needed to create the common secret key. This is the kind of "attack" which makes a good story line for movies, games or fairy tales. And while you exclude malware, keyloggers and weak encryption higher value secrets have to face also attacks like physical brute force, bribing, black mailing, hidden cameras etc - just look at typical movies for more ideas.

But instead of somehow compromising every one of the bearers of the secret parts it might be easier to attack the place where these parts get combined to form the final secret key, because then all information are there in a single place already. And, it is also hard for the participating parties to deny their involvement if they can be seen to participate in constructing the secret key.

Alternatively one can attack even later stages, i.e. the stage were the common secret key is already computed (without knowing the separate inputs) or the stage where the secret key was already used to decrypt the secret data and just grab these secret data.

None of these later stage attacks seem to be out of scope or even considered in your given threat model.


SSD erasure strategy for a secondhand laptop I recently purchased a secondhand MacBook Air for work purposes; the laptop was shipped to me with a fresh install of OS X. I do not know the prior owner or what they used the laptop for, and thus I need to verify that all software and data on the solid state drive is both erased and irrecoverable before setting up a fresh OS X install.

I plan to do the following:

Encrypt the drive currently holding the placeholder OS X system using Filevault 2 and a strong password.

Reboot to an OS X install thumb drive, and erase the hard drive using Disk Utility. I assume this will securely erasing the FileVault key, thus rendering the old data impossible to decrypt.

Reinstall Mac OS X over the old (erased) encrypted volume, and set up FileVault 2 to encrypt this new install.

Is this sufficient to ensure that no relic software or hard drive data from the old drive owner is recoverable?

Encryption makes no sense in this context. Writing an encrypted version of the data to the media will make it strictly easier to recover the data than simply writing random data.

However since you are asking about an SSD there is an even better option. Use a tool to issue a TRIM command (or a sequence of commands) to the drive instructing it to delete all data. This is the fastest way to wipe an SSD and makes it very difficult if not impossible to recover any of the data. It should also give you better performance of the clean install you are going to perform after wiping the SSD.


Can the loopback interface be hijacked? Inspired by this question I came up with this weird idea of making what that user actually wants to prevent. So, bear with me for a little bit:

Let's assume that for some reason we could make the traffic sent from a specific application to another to travel to a router/routing device because the source device cannot determine on its own where does it have to send the packet. This means, even names like "localhost" or IPs like 127.0.0.1 does not work for this source device, but it rather has to send everything to another device to send the information its "destination" device (which, we know, it's that same server).

So, simplifying and making it an actual question: is there any way, remotely as it could be, to hijack routing tables/loopback interfaces/whatever it takes to make a machine send it's traffic out when those communications are supposed to be internal?

Think in how many web server do have their databases in there and send "internal" requests for connection with data... TCP services... and how firewalls are configured to block weird traffic in but not so much for traffic out. This made me tick and come and ask this weird question.

There are lots of speculations, let's try it.

Assigning 127.0.0.1/8 to the network interface

On Debian it works as root to assign 127.0.0.1/8 to the network interface:

# ifconfig lo 10.0.0.1 netmask 255.0.0.0
# ifconfig eth0 127.0.0.2 netmask 255.0.0.0

and results in:

lo        Link encap:Lokale Schleife
          inet Adresse:10.0.0.1  Maske:255.0.0.0
...
eth0      Link encap:Ethernet  Hardware Adresse
          inet Adresse:127.0.0.2  Bcast:127.255.255.255  Maske:255.0.0.0
...

ping 127.0.0.1, however, fails with an Illegal Argument error:

 $ ping 127.0.0.2
 PING 127.0.0.2 (127.0.0.2) 56(84) bytes of data.
 64 bytes from 127.0.0.2: icmp_seq=1 ttl=64 time=0.030 ms

 $ ping 127.0.0.1
 connect: Invalid argument

So this is something that needs to be look at in more detail by analyzing the source code.

Pointing "localhost" to another ip-address

Editing /etc/hosts as root so that it points localhost to another ip-address works:

ping localhost
PING localhost (209.85.149.147) 56(84) bytes of data.
64 bytes from localhost (209.85.149.147): icmp_seq=2 ttl=57 time=165 ms

Whether this is an issue or not depends on the situation: The client may send a password without validating the server by either not using ssl or trusting any certificate (There are testing-certificates for localhost out there that are signed by trusted CAs). This password might be reused elsewhere or the server may accepting connections from other interfaces because it is password protected anyway.

In the standard configuration the host file has precedence over NIS and DNS, which requires local root access and makes this kind of attack pointless. But if the priority was changed, this is exploitable using the DNS or NIS servers.


Path traversal exploit I have an Apache server which seems to be vulnerable to path traversal, because when I test this URL: http://localhost/ati/../test.txt

it will be changed to the this: http://localhost/test.txt
and the server shows the contents of test.txt file.

However, when I test this URL:  http://localhost/ati/../../../../../../../../../../../../../../../../../../../etc/apache2/apach2.conf it will be changed to: http://localhost/etc/apache2/apache2.conf and therefore the server gives a 404 Not found response and does not show the content of apache2.conf file.

My first question is: Does it mean that I am secure against path traversal attack regarding the fact that I have not changed any default settings of the Apache on my server?

And my second question is: why the server does not allow to traverse beyond the root of the web server folder? I.e. why can't I access outer files than localhost folder on my web server? How can I exploit path traversal if my server is vulnerable?

Apache itself should not serve files outside the configured DocumentRoot.

The behavior you are describing is most likely caused by the browser, which transforms the URLs before sending them to the server.

If you use an intercepting proxy, you will notice that for http://localhost/ati/../test.txt, the browser actually requests http://localhost/test.txt and for http://localhost/ati/../../../../../../../../../../../etc/apache2/apach2.conf, http://localhost/etc/apache2/apache2.conf is sent to the server.

If you want to check the path traversal vulnerability you should use a proxy.


How can I prevent email spoofing from my domain? I recently registered a domain name, and set up an email account tied to it with Zoho mail. I'm concerned about making sure all emails from this domain are signed to prevent spoofing.

I've enabled SPF and DKIM on Zoho and my domain, but is this enough? For example, here's a phising email I received which is successfully spoofed with signature:

I'm confused by a couple of things:

How is it that the "to" address is the same as the "from" address?
How is it that the messaged is Signed by outlook.com?

How can I protect this from happening on my own domain, and how can I try sending testing-spoofs to check its security?

P.S.

I've attempted using telnet to send emails from my domain, but I receive a 553 Relaying disallowed error in reply to my RCPT TO message. The same thing happens when testing mx.zoho.com with the mxtoolbox SMPT diagnostics.

Related: Can I spoof email?

You could go beyond SPF - add DKIM to the mix, and you can use DMARC, which will not only prevent spoofed emails, but also allows you to receive reports of them.

SPF basically lets you list your legitimate servers, and DKIM signs emails to attest to their validity.
DMARC then allows you to define how receivers should deal with email that fails SPF or DKIM tests, and how they can send you reports.


Sip call Developing in android with secure data transfer I would like to make an application similar to RedPhone on android. I took a look at SipDemo from developer.android.com and at the android.net.sip package.

My question is, when you make/receive a call, how can you get the audio stream to encrypt/decrypt it before is being sent/played back to the user? Is there a tutorial about this somewhere? I am aware that I need a sip account and real devices with android 2.3. I would like to get the AudioStream before it's sent (for encryption) and to receive the AudioStream before it gets played-back to the user(for decryption).

Take a look at countertap

http://sourceforge.net/projects/countertap/


Can a virtual machine program view a host machine's connections? I don't really know anything about computers.  I need to run a virtual Windows machine inside an Ubuntu system.  My current setup uses a stripped down version of Windows XP on VirtualBox.  I intend to use RDP (Remote Desktop Protocol) regularly to connect into the Ubuntu host.

Is it possible for a program (or user RDP'ing into the virtual Windows environment) to find anything about RDP activity into the host, specifically where it's originating?

If so, are there any settings I can toggle for either Linux, Windows or VirtualBox to prevent this activity from being detected?  Or must I go with an entirely different virtualizer, choice of OS or setup altogether?

Your XP box should only be able to find out that it is a virtual machine(via hardware detection) and where the RDP connection appears to originate from. I say "appears" because this can be gotten around with technologies like Network Address Translation(NAT).

VMWare might have a bug in their code that allows code from within the virtual environment to escape and run on the physical host. I feel that, in your case, you are probably(See @D.W.'s comment below) safe from that because you are running a different operating system.

Under a default install of VMWare, it is possible for code on the virtual machine to attempt to connect to the physical host via SSH, SMB, or other similar network protocols, including RDP. The way to prevent this is to turn off networking entirely for the virtual machine. However, this will also prevent RDP from working. Short of disabling networking entirely, set the virtual machine to be in a host-only network and make sure that your Ubuntu firewall is turned on. Ubuntu should be set to reject all connection attempts from the XP machine.


Check the "security" of a password I'm trying to find a tool to validate the security of a password and I've come across cracklib or libcrack2 (on Debian), which seems to be used a lot for the task and appears to do exactly what I wanted.

However, it does not really depict the requirements I imagined. For a lot of cases it does seem to have some appropriate checks (e.g. reversed dictionary-based words, too simplistic, ...).

The following explains what I mean:

$ echo "wordpass" | cracklib-check
wordpass: OK

Now, wordpass is not what I imagine to be a secure password.

I do not have a specific password policy I'm following, nor do I have a certain value for the desired entropy of the password. Defining "secure" in terms of passwords is a complex task. Given the password is used for a Linux system using PAM, if an attacker is not able to crack it with rainbow tables or bruteforce it within a week, I'd consider it secure.

How could I simply verify the security of a given password on a Linux system?

EDIT: I've come across a more reasonable another tool, passwdqc:

$ echo "wordpass" | pwqcheck -1
Bad passphrase (not enough different characters or classes for this length)

But, as mentioned by the user @Hector the question is very vague and in this form not really answerable, so I'll vote to close the question. but won't delete it as it may be usable for someone else who's not satisfied by the cracklib approach.

$ echo "MyP@ssw0rd" | pwqcheck -1
OK

There is not a simple process that can do this. For example is an obscure English dictionary word more or less secure than "MyP@ssw0rd"?

Enforcing rules that require symbols and numbers leads to users using "password1!" etc. and forcing users to rotate passwords leads to "password1", "password2" etc.

  if an attacker is not able to crack it with rainbow tables or bruteforce it within a week

Via what mechanism? Over a network with rate limiting? Do they have access to the stored hashes? You need a lot more context for "a week" to have any relevance. For a brute force are they incrementing byte values or using a dictionary? What dictionary? - all you need is a user reusing an otherwise secure password on a site that is hacked...

  I'm trying to find a tool to validate the security of a password

Personally I would suggest a combination of character limit (>= 10 characters) combined with checking the password against lists of known to be leaked passwords. For example Have I Been Pwned maintains a list of several hundred million SHA1 hashes of leaked passwords. If the SHA1 of the user entered password is not in there the chances are it wouldn't easily be brute forced / dictionary attacked.


Is update@em.facebookmail.com legitimate? I'm having a hard time figuring out whether this email a friend of mine got is legit or a scam. The weird thing is there's only one link to facebook.com, which is the one about facebook terms. All the others are linking to em.facebookmail.com with a very long funny characters to follow. Another thing that raised suspicion was a particular grammar error and one link in Spanish. I tried searching online but all I got was opinions that are hardly believable.

What should I do to check whether it's legitimate or not?

EDIT

Example link:

http://em.facebookmail.com/pub/cc?_ri_=X0Gzc2X%3DWQpglLjHJlYQGiwzdEDAO0fUMeSfY0IMLolh6nzetzfLzezfta6mNVXtpKX%3DSRYACT&_ei_=EnIKw7ZfezfaO818iGCS8OKM3wsHi9t5aeegB28nNXF-_-Ez1lKT0ISXpmmPx__JHh89daMZ-yh6R9JdxOQ6mLdT7_9cfymEL6iQFvpa4lV1YWogx7vG--iplcrBEso.

Looks like the source domain is legit to me. Here's the whois result for the domain:

Registrant:
    Domain Administrator
    Facebook, Inc.
    1601 Willow Road
     Menlo Park CA 94025
    US
    domain@fb.com +1.6505434800 Fax: +1.6505434800

Domain Name: facebookmail.com

    Registrar Name: Markmonitor.com
    Registrar Whois: whois.markmonitor.com
    Registrar Homepage: http://www.markmonitor.com

Administrative Contact:
    Domain Administrator
    Facebook, Inc.
    1601 Willow Road
     Menlo Park CA 94025
    US
    domain@fb.com +1.6505434800 Fax: +1.6505434800
Technical Contact, Zone Contact:
    Domain Administrator
    Facebook, Inc.
    1601 Willow Road
     Menlo Park CA 94025
    US
    domain@fb.com +1.6505434800 Fax: +1.6505434800

Created on..............: 2006-01-23.
Expires on..............: 2018-01-23.
Record last updated on..: 2012-09-28.

Domain servers in listed order:

a.ns.facebook.com
b.ns.facebook.com

However, this doesn't mean the email is real. It could've had its source address spoofed. Check the headers on the email to see if the source SMTP server is legitimate, and if the return address is valid. You can also contact Facebook's security team to inquire about the potential phishing attempt, and provide them with the embedded links - they might represent an XSS or other attack on Facebook itself.


Inconsistent return address with telnet I am trying to execute a shellcode in the configuration:

No VA randomization (set to 0)
Server is listening on port 9000
Terminal listening with netcast on port 31337
Server and attacker are the same (virtual) machine, kali linux 2018.4 32-bit

The shellcode aims to do a shell_reverse_tcp. The payload was generated with the linux/x86/shell_reverse_tcp LPORT=31337 LHOST=127.0.0.1 and shikata_ga_nai encoder.

I found saved EIP and sent the payload with a nop sled, the shellcode and the address which is \x70\xee\xff\xbf
Running the server with gdb, I see that the address that arrives is \x70\xee\xff\xff

If I put "ABCD" in the address I correctly see the string in hex, but I cannot set the address (which refers to the middle of the nop sled) as it "resets" itself to \xff

Is that a problem due to encoding, or maybe telenet ?

EDIT:
It looks like 0xbfxxxxxx changes to 0xffxxxxxx when the following character is also f. I don't know why. If I change to something else, it does not change the first two characters to ff.

The problem cam from telnet.

Telnet transmits \xbf\xff as \xff\xff in the command
echo $(python -c 'print "\x90"*300 + "\x77\x77\xff\xbf"') | telnet localhost 7777

Using netcast solved the issue.


How feasible is it for a CA to be hacked? Which default trusted root certificates should I remove? This question has been revised & clarified significantly since the original version.

If we look at each trusted certificate in my Trusted Root store, how much should I trust them?

What factors should be taken into consideration when I evaluate the trust of each Root CA for potential removal from my local store?

More Information:
If a CA issues a certificate to an improperly validated party, then that causes all machines that trust that CA vulnerable to MITM attacks.  As a result all CA's stringently validate the requester of a given SSL certificate request to ensure the integrity of their CS chain.

However, a large part of this CA verification process is subject to human intervention and provides opportunities to issue a cert to the wrong party.  This may be done by CA operator error, government demands, or perhaps the coercion (bribe) of a CA operator.

I'd like to learn more about which default CA's are more likely to issue certificates to the wrong party.  I intend to use this information to advise users to remove that CA from their Trusted Cert Store

Examples:
Suppose the government controlling a particular CA wants to assume the identity of Microsoft.com, and demands an exception to the CA's verification process.  That government then also requires the secrecy of this exception be maintained.  The generated key pair would then be used in a MITM attack.

Windows Azure Default Trust

Windows Azure supports 275 CA's as shown in the following link.  Depending on the use of the particular CA, some of those CA's may increase the surface area of a particular attack.  In fact this may be technically required to make some applications work correctly.

Amazon Default Trust

(not available) Please share links to Amazon, Google, and VMWare's default CA list if you come across them.

Mozilla

A list of all certificates and audit statements is available.

Apple iOS

List of all iPhone root certificates as mentioned in this #WWDC2017. video

Update 5 The root problem (heh) with the CA model is that in general practice, any CA can issue certs for any domain, so you're vulnerable to the weakest link.  As to who you can trust, I doubt that the list is very long at all, since the stakes are high and security is hard.  I recommend Christopher Soghoian's post on the subject, which clarifies the various approaches that governments around the world have used to get access to private user data - whether by directly demanding it from companies that operate cloud services, via wiretap, or increasingly now via CA coercion or hacks: slight paranoia: The forces that led to the DigiNotar hack.

Here I provide some specifics, and end with links to some potential fixes.

In 2009, Etisalat (60% owned by the United Arab Emirates government), rolled out an innocuous looking BlackBerry patch that inserted spyware into RIM devices, enabling monitoring of e-mail, so it can hardly be considered trustworthy.  But it is in a lot of trusted CA lists:
 http://arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

Update 1 See also an example of a successful attack, allegedly by an Iranian named ComodoHacker, against Comodo: Rogue SSL certificates ("case comodogate") - F-Secure Weblog.  F-Secure notes that Mozilla includes certificates issued by CAs in China, Israel, Bermuda, South Africa, Estonia, Romania, Slovakia, Spain, Norway, Colombia, France, Taiwan, UK, The Netherlands, Turkey, USA, Hong Kong, Japan, Hungary, Germany and Switzerland.

Tunisia is another country that runs a widely-trusted CA, and there is also good documentation of the actions of their government to invade privacy: The Inside Story of How Facebook Responded to Tunisian Hacks - Alexis Madrigal - Technology - The Atlantic

Mozilla notes another questionable practice to watch out for: CAs that allow an RA partner to issue certs directly off the root, rather than via an intermediary: Comodo Certificate Issue – Follow Up at Mozilla Security Blog.
See also more detail, including speculation about the claim of responsibility by a lone Iranian hacker Web Browsers and Comodo Disclose A Successful Certificate Authority Attack, Perhaps From Iran | Freedom to Tinker

Update 3: Another successful attack seemingly also by ComodoHacker was against the DigiNotar CA.  Their website was compromised starting in 2009, but this was not noticed until after DigiNotar had also been used in 2011 by Iranians to sign false certificates for the websites of Google, Yahoo!, Mozilla, WordPress and The Tor Project.  DigiNotar did not reveal its knowledge of the intrusion into its site for over a month.  See more at DigiNotar Hack Highlights the Critical Failures of our SSL Web Security Model | Freedom to Tinker.

I'd guess that the range of vulnerability of various CAs varies pretty widely, as does their utility.  So I'd suggest refocusing your strategy.  When you can narrow it to specific assets you're trying to protect, just delete all CAs except those necessary for using those assets.  Otherwise, consider eliminating the CAs you judge to be most vulnerable to those who care about your assets, or least popular, just to reduce the attack surface.  But accept the fact that you'll remain vulnerable to sophisticated attacks even against the most popular and careful CAs.

Update 2: There is a great post on fixing our dangerous CA infrastructure at Freedom to Tinker: Building a better CA infrastructure

It talks about these innovations:

ImperialViolet - DNSSEC and TLS
Network Notary - Perspectives : Improving SSH-style Host Authentication with Multi-path Network Probing
Google Online Security Blog: Improving SSL certificate security

Update 4 One of our IT Security blog posts in August 2011 also covers the case for moving to DNSSEC:
A Risk-Based Look at Fixing the Certificate Authority Problem « Stack Exchange Security Blog

Update 6 Several Certificate Authorities have been caught violating the rules.  That includes the French cyberdefense agency (ANSSI), and Trustwave, each of which was linked to spoofing of digital certificates.

Update 7 Yet another set of "misissued certificates", via the  Indian Controller of Certifying Authorities (India CCA) in 2014: Google Online Security Blog: Maintaining digital certificate security

See also the question on Certificate Transparency which looks like a helpful approach to discovering bad certificates and policy violations earlier.


Website being open inside 3d party domain/frame, is this a possible attack? I recently had a huge increase in visits of a website I manage. On deeper check I discovered I had a new referral. When I opened the website I was quite surprised.

It's not a just a referral, basically someon bought a domain and is opening my website from inside a full page frame like this:

frame name="main" noresize framespacing="0" frameborder="no" border="0"
src="http://zzovq.voluumtrk.com/*****-*****-****-85c7-890*****?idade=35+"

Where * stands for numbers.

Through the url in src they get my website. Proxyed, apparently.

Besides the iframe they track visits on their page via Google analytics.

My question is: is this a new angle of attack? What are they trying?

I can think of a few possible attacks. They could be proxying the website and changing content (I didn't discover any evidence). Doing some JS injection (apparently not). In principle XSS is not possible like this. What's the point of this?

Note: I assumed the domain in src referred directly to your website.

Possibly clickjacking

  Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page.

An example:

  For example, imagine an attacker who builds a web site that has a button on it that says "click here for a free iPod". However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the "delete all messages" button directly on top of the "free iPod" button. The victim tries to click on the "free iPod" button but instead actually clicked on the invisible "delete all messages" button. In essence, the attacker has "hijacked" the user's click, hence the name "Clickjacking".


Do I need two firewalls or is one enough? We have a bunch of company devices (servers, desktops, laptops, company-issue phones, etc). All of these devices are company devices, every employee uses them just for business. All devices should have the same filters applied.

Do I need two firewalls (one for LAN, one for WLAN Access point) like the image shows or is it enough, if I just use the firewall before the router? Do I really need the one I marked with red?

Is that marked firewall just for setting more filters, or would there a bigger purpose for it?

This answer borrows ideas from Steffen's comment. The answer is it depends, with a sprinkling of random internet people don't know enough about your organization to give a proper answer. But we can give you some points to think about.

As Steffen said: "Firewalls are used to separate things", usually to protect a higher-security group of users and / or devices from a lower-security group.

In a diagram like that, you have servers, desktops, laptops, and mobile devices. The usual assumption is that the servers and desktops are:

where the sensitive data lives,
running all the corporate-issue endpoint protection, anti-virus, and monitoring tools,
only ever connected a clean packet-inspected network with other similarly trusted devices.

When you draw laptops and other mobiles on a diagram like this, the assumption is that these devices may or may not:

be running proper endpoint protection, anti-virus, and monitoring tools (almost always the case for phones),
get connected to random coffee-shop or hotel Wifi networks (or even employees' home networks) during which time they A) come in contact with infected machines and B) can browse to infected websites without the corporate packet inspection and monitoring tools there to protect you,
get infected USB sticks plugged in,
be easily monitorable / remotely wipable to prevent data being exfiltrated from the building,
etc.

TL;DR: You need to have a think about what your organization's security and threat models are. If you decide that the phones and laptops really truly have exactly the same security needs and risk level as the servers and desktops, then you don't need a firewall there. However, in 99% of organizations, devices that are allowed to leave the building are considered to be at higher risk of infection, so it makes sense to have that firewall and only allow through the hosts and ports that the laptop users actually need to access.

The idea is to assume the laptops and phones are infected and reduce the amount of network probing that they can do on your internal network.


Technical description of a self-signed certificate I'm having a friendly debate with a co-worker as to the meaning of "self-signed" when it comes to PKI.  We have an internal root and subordinate CA in our organization.  We import the cert chain on internal clients to allow for the trust of certificates issued from our internal/private CA.

My colleague believes that the definition of a self-signed certificate is one where there's no publicly trusted/commercial certificate authority involved.  I, however, understand a self-signed certificate to be one that's created by the host that it resides on and has no further link to any chain, private or public.

I've searched Google and found both answers being touted as correct.  I'm not great at comprehending RFC's, which is probably what I need to do to really get to the root of this argument.  Rather, can someone more knowledgeable than myself help to settle this disagreement?

RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

The end of section 3.2 states:

  This specification covers two classes of certificates: CA certificates
  and end entity certificates.  CA certificates may be further divided
  into three classes: cross-certificates, self-issued certificates, and
  self-signed certificates.

  Cross-certificates are CA certificates in which the issuer and subject are different entities.  Cross-certificates describe a
  trust relationship between the two CAs.
  Self-issued certificates are CA certificates in which the issuer and subject are the same entity.  Self-issued certificates are
  generated to support changes in policy or operations.
  Self-signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into
  the certificate.  Self-signed certificates are used to convey a
  public key for use to begin certification paths.

  End entity certificates are issued to subjects that are not authorized
  to issue certificates.


TLS encryption email I'm using TLS for my email delivery, what exactly happens to my data. Is it the data getting encrypted or a secure TLS tunnel is formed and my data goes in that tunnel in plain text?

If you use TLS to send a mail the mail gets send encrypted to the mail server you send it too. This step is similar to accessing a web site with HTTPS, i.e. the plain data get encrypted. But while with HTTPS you talk to the final server directly (end-to-end encryption) the situation is different with mail.

Mail gets delivered hop-by-hop using multiple mail servers until it finally reaches the recipients mail server. There it will be stored in the mailbox until the recipients retrieves the mail. When sending a mail with TLS you only control that the transfer to the first hop is done with TLS. You have no control over the following transfers and apart from that each mail server will be able to see the mail in plain text.

If you need to have end-to-end encryption with mail TLS does not provide this for you. PGP and S/MIME instead do but need to be supported by both sender and recipient which is usually not the case.