How can a malicious URL affect a computer? Many security experts advise not to click on malicious URLs. How can clicking a URL affect a computer's security?

If a malicious file was downloaded and executed, then a computer's security may be breached, but how can just visiting a URL do this?

You can be infected via the use of what is called a drive-by-download exploit.   This is how  malware  can download and install itself on your machine simply by loading a web page that contains it.

It works by finding vulnerabilities that allow it to escape whatever sandboxes it is supposed to be playing in, and execute arbitrary, malicious code on your machine.

Years ago, when early versions of Internet Explorer were the most popular browsers on the web, ActiveX components were the most popular vectors for drive-by-downloads.  Presently, other drive-by download vectors appeared such as with Flash Player plugins, Java applets, or PDF and images.  In all case, JavaScript is the primary vector that, if used properly by a miscreant, can lead to a drive-by download attacks such as the attack on Firefox that was used to expose personally identifying data for some Tor users.


Session Management for Private Key Passphrases in a Web Application Use Case

I would like to encrypt data in a database for a Web Application. The following requirements exist:

Decryption should only be possible when a user provides a passphrase
Encryption should always be possible

I therefore use asymmetric encryption using public and private keys. An encrypt operation can be launced by the web app at any time, but the web app can only decryption when the user provides a passphrase.

Problem

All of this works fine, but the problem I have is that everytime the user wants to decrypt data, he needs to provide a passphrase. I would like to provide the user with the option to "remain authenticated" for a session, after he enters the passphrase once.

Here is where I am having trouble. If I decide the store a hash of the passphrase in the Session, then the server would technically be able to decrypt the data without the user's Input. Remembering a passphrase hash in a Cookie is also not an option.

What common options do I have? Is it possible that my approach overall is incorrect?

Possible Solution?

After some thinking I plan to implement the following:

User sends passphrase to server
Server creates a random 128 bit key
Server hashes the passphrase and encrypts it with the new random key using AES
Encrypted hash is then stored in the session at the server
The Users stores in his cookie: Session ID and Encryption Key
Only when both are provided with a request, can the server decrypt the data
The session will become invalid after a certain time period

Is this a secure approach?

The Data can only be decrypted if:

Encrypted Data is retrieved
Private Key is retrieved
Session Data is retrieved
User Cookies are retrieved

Notes:

The data itself is not encrypted with the public key, but a random key is generated and used to encrypt the data using AES. This key is then encrypted with the public key, which allows for some form of user management.
Everything runs in HTTPS
The private key is encrypted with a hash of the passphrase, not the passphrase itself

Thanks in Advance

What you've described is very similar (almost identical) to the basics of the OpenPGP standard. It would be wise to read up on OpenPGP before attempting your own implementation of this scheme.

To answer your question posed here:

  Here is where I am having trouble. If I decide the store a hash of the passphrase in the Session, then the server would technically be able to decrypt the data without the user's Input. Remembering a passphrase hash in a Cookie is also not an option.

This is a tautology. As long as you don't maintain a ciphertext in/out paradigm for your server it will always be able to decrypt stored data at some point. The best you can do is require user input for every operation.


How to evaluate the strength of a hashing algorithm? At work the hashing algorithm we use for passwords appears to be bespoke. Obviously that's a pretty bad idea, but the management don't seem bothered.

The algorithm always produces 20 character long upper case strings. One particularly worrying aspect of its behaviour is that similar passwords produce similar hashes: Password1 and Password2 produce hashes that are different by only about 5 characters.

The other obvious issue is that it doesn't look like the algorithm is deliberately slow, which I'm told good hashing algorithms (bcrypt, scrypt) should be.

How does one go about evaluating the strength of a hashing algorithm? And what sorts of attacks should we be particularly concerned about with a fast hashing algorithm with poor uniformity?

I have access to the source (although unfortunately I can't post it on a public forum, for obvious reasons).

A strong hashing algorithm would imply that changing even one character will result in a completely different hash.

A good hashing algo has these characteristics:

The hash value is determined by the data being hashed
The hash function uses all given data
The hash distributes all possible hashes uniformly across all possible hash outcomes
If you have a string and you take a very similar string, you will get a completely different hash result (changing one single bit of input should change all output bits with a probability of 50%. Another requirement is that the hash is, to the highest extent possible, statistically independent of the input, e.g. a high hamming weight in the input does not produce an abnormal hamming weight in the output. -Polynomial)

Please tell your management

not to be Dave, and just use one of the standard hashing algorithms. If you are using the hashes to store passwords, use bcrypt. When hashing a password you are also concerned about salts, bcrypt does all that for you. Plus it's all free.


Crack Putty Private Key (PPK) I found a private key which seems to be in the putty private key format.

The key has the following header:

---- BEGIN SSH2 ENCRYPTED PRIVATE KEY ----
Subject: <sensitive>
Comment: <sensitive>
P2/56wAAA/MAAAA3a...
...Yhp
---- END SSH2 ENCRYPTED PRIVATE KEY ----

When opened in the putty keygen tool it prompts for a password which it does not do for other files so I assume some sort of validation is done on the PPK file. The same behavior with a PPK file that I generated using putty keygen.

I tried the PHRASENDRESCHER tool to guess private key passwords but this tool gives no output in case of an invalid/unknown file format. I tried generating my own PPK with a weak password and it did not crack that private key. So I assume the tool does not understand this type of private key.

Since putty keygen has no CLI, it is not possible to guess the password automatically. Does anyone have cracking tool that is able to guess the password (brute-force and/or word list) for PPK files?

Based on the comment from nbering, I created a script that uses puttygen on Kali:

apt install putty-tools

The script is very basic but tries all words from a wordlist specified as the first argument. If the correct passphrase is found, it will prompt for user input, asking for a new passphrase to use to encrypt the private key.

#!/bin/bash

echo "Wordlist: $1"
echo "PPK file: $2"
echo "New PPK file: $3"
while read -r line
do
    echo $line > old_pass.txt
    error=$((puttygen $2 -P -o $3 --old-passphrase old_pass.txt ) 2>&1)

    if [[ ! $error = *"wrong passphrase"* ]]; then
        echo "Passphrase: $line $error"
    fi
done < $1

Hope this is helpful to someone. As always, only use with approval of the target.


Is Django's approach to password reset tokens secure? I am implementing a password reset feature for a web application and am contemplating adopting an implementation similar to Django.

In a nutshell, Django creates a token who is comprised of a timestamp and a hash of the timestamp and the User ID. This hash is a HMAC and is used to verify that neither the timestamp or the user ID have been tampered with.

In addition to the timestamp, information about the user such as her password salt are hashed. This way, if the user changes her password, the token will become invalid, reducing the window of opportunity for an attacker.

The source code for the token generator can be viewed here
and here is the pseudocode:

function make_token(user)
  timestamp = current timestamp (now)
  value =  timestamp + user.id + user.password
  hash = create_hmac("some secret", value)
  return timestamp + ":" + hash

function check_token(user, token)
  timestamp = token.split(":")[0]
  hash = token.split(":")[1]

  if timestamp is after expiration date
    return false

  value =  timestamp + user.id + user.password
  comparate = create_hmac("some secret", value)

  // if the hash has changed, the token has been tampered with or the user has
  // changed their password.
  if hash != comparate
    return false

  return true

This seems like a good solution to me. Websites running Django have been doing this since 2008 or so and I cannot find any reports of a vulnerability.

I did some research and someone on Hacker News did not like this approach. There are also a couple of tickets on the subject that express concern. However, I am yet to find a specific reason as to why this is might be insecure.

Is this a secure approach to generating password reset tokens? If not, why?

As with any question of "is X secure" the answer will, to some extent, be "that depends on your exact requirements from a security standpoint, the threats you face, the type of application and the environment that you'll deploy in"

However with that caveat out of the way, I'd say that the scheme outlined above sounds relatively reasonable from a security perspective and is definitely better than a lot of password reset features I've seen in the past.

The bug report you linked descibes a very specific scenario (the attacker has read access to specific sections of the server-side code and configuration, but not other access) which wilst it does represent a risk, is a really marginal one (to me) as if they have that access there's likely other stuff they would attack before they start generating fake password reset links for users.

The comments from the HN thread are more general in nature and don't seem to descibe a specific threat to this scheme beyond Thomas' general disquiet with schemes that avoid the standard approach that he describes in his comment.  Whilst his points are reasonable, that's not to say that the Django scheme is broken, more that there are trade-offs involved.


Argon2id key derivation rate calculation question Just wanted to know if this was an accurate way of determining how long it would take someone with an 8GB GPU to derive 1 million keys using some assumed parameters below:

Time per derivation...........: 3.5 seconds
Memory required per derivation: 128MB
GPU Max Memory................: 8GB

So, 128MB = 0.125GB. Max derivations that could be happening at any given time = 8/0.125 = 64.

Each derivation takes 3.5 seconds, so derivations per second = 64/3.5 = ~18.3

So, 1 million key derivations would take (1000000/18.3)/3600 = ~15 hours.

Does this seem accurate, or am I unknowingly making too many assumptions? Thanks.

You've assumed that the derivations can happen in parallel, which might not be possible, but your calculation will give you an answer to the correct order.


Securing the backend of your web application? We are grappling with how to architect are back end for security. Some of the recommendations I've seen look like this:

Some will have another firewall between the application server and the database (which would be on the internal network).

Question being with today's highly interactive pages where a lot of the logic is in javascript how would this work? Javascript generally needs to receive json. I would guess in this structure that the web server can't communicate directly with the database server. So you would have to go through the application server. That's all fine an dandy when your pages are static and the only code that will be communicating with the app server will be the web server but generally javascript will need to communicate with the app server (which in our case will be REST services). I'm also assuming in this structure the only thing that can communicate with the application server is the web server.

That's actually correct.

Typical web page request liftime:

Javascript makes a request to the web server
Web server validates the request

If the request is bad, reject it

If the request is good, send it to the app server

App server receives the request for the data, retrieves it, send it back to the web server
Web server formats the data into a JSON and sends it back to the client
Client recieves data, validates it's what it is expecting, and does something

Of course this is something you've probably seen time and time again, but it doesn't really explain why the web server is there... or does it?

Let's look at the web server validating the request:

Here's there are three things that can happen:

Request is malicious, this server instance goes down

Because of the way you formatted this web server, that malicious request doesn't affect the database or app server, so you jsut restart hte instance

Someone intrudes onto the web server, and gets isolated in a netowrk of honeypots
DDOS attack comes through to the web server, not database or app server

basically the advantage of this is that you can have your DNS point to the web server, and keep your app server and database secret and direct IP access only, meaning any other services(like data reporting) stay up if your website goes down.


Class.forName injection and constructor invocation If a Java-based webpage takes a user-supplied parameter and instantiates an object using Class.forName(parameter)
What's the worst possible consequence?

The attacker does obtain stack traces. After the object is instantiated, it is cast to a proprietary class, so it will throw exception at that point.

Example consequence:

Enumerate classes on classpath

Edit : The attacker also can specify any number of strings passed to the constructor.

This leaves a lot of room for abuse. Basically any static initializer and any constructor which has string parameters can be executed:
This is a common vulnerability of <something> (e. g. JSON) to Java parsers, that allow the untrusted data block to specify the classnames.

JDBC drivers are supposed to register themselves in the static initializer. Classes that use native methods are supposed to load the native library in the static init block. Furthermore there is a singleton anti-pattern of creating the instance in the static block. So it is possible to use up memory, that cannot be GCed. And of course someone might have written code that does other strange things in the static init block.

There are many classes which have side effects in their constructor. For example instantiating a FileOutputStream with a filename as parameter will empty that file, assuming that java process has write permission.

Those examples came to my mind while reading the posting. I am sure there are a lot more.

Furthere more you should consider whether showing the Stacktraces to the attacker is really necessary. It is often a good idea to hand out as little information as possible in unexpected situations. In your situation for example, it does makes a differences if a FileInputStream throws an IOException or a ClassCastException. This information might make it easier to exploit another vulnerability.

At the very minimum you must check TrustedInterface.class.isAssinableFrom(loadedClass) before invoking the constructor or use loadedClass.asSubclass(TrustedInterface.class). But I strongly recommend to use a whitelist of classnames.


what is the use of stolen personal details? What can hackers do with personal information that includes this: First name, last name, snail mail address, mobile phone number and email address?

There are many groups that can be interested in such knowledge -

They can try to impersonate as YOU. Identity theft is one of the most crucial things nowadays. Impersonating can lead to credential theft to some websites etc.
Using this information to further infeltrate - maybe your e-mail password is weak?
Spammers and Direct marketing firms are looking for that kind of knowledge, too. They can use it for spam or to sell to someone that is into it.


How often should TLS Session Ticket Keys be rotated? I am configuring a non-sticky load balanced cluster of HTTPS servers. To enable TLS session resumption when a previous client reconnects to a different server in the cluster I will be configuring shared session ticket keys across all servers in the cluster as per RFC 5077.

In the RFC, section "5.5.  Ticket Protection Key Management" recommends that:

  The keys should be changed regularly.

My research so far has not revealed any consensus on what "regularly" should be. A few references mention daily but without justification. Further, it appears that ticket keys on standalone (ie non-clustered) servers in popular implementations (eg Apache, nginx) are only rotated on process restart which could be very infrequent.

So, my question is essentially:

Is there a rotation schedule for ticket keys that is considered secure? How is that schedule derived?
If there is no recommended schedule, are there at least other aspects of TLS behaviour that define sensible upper and lower bounds for rotation frequency (eg client session cache times, certificate validity period)?

RFC 4346 is the source of the "daily" recommendation:

  An upper limit of 24 hours is suggested for session ID lifetimes,
  since an attacker who obtains a master_secret may be able to
  impersonate the compromised party until the corresponding session ID
  is retired.

Lacking any better guidance, you're probably fine going with 24 hours.  I'm not aware of any research or experience suggesting that shorter times are necessary or appropriate for current traffic.

You can also go a lot lower.  Session resumption can be a big deal when a client is hammering you with hundreds of connections within a few minutes.  But having to renegotiate once an hour, say, is not onerous to the client or to the server.  You save the CPU hit of constantly renegotiating, but there's a huge gap between "every single connection" and an hour - or 30 minutes - or even 5 minutes in some cases.

To specifically answer your points:

24 hours is the upper limit because it's specified in RFC 4346.  (Obviously, "because it's in the RFC" doesn't reflect real-world pressures).
Within the 24 hour window, only your traffic can guide you.  How often do the same clients reconnect?  Do they take advantage of resumption if available?  How long do their sessions last on average?

Certificate validity periods don't come into it (as 24 hours is far below their concern horizon).  Client session cache times are interesting, but alas, probably not available to you - which goes back to what I said about seeing how often your clients take advantage of resumption when available.

My personal advice - you can play with periods from 1 to 12 hours and you'll probably find they all give you the performance boost you need with diminishing returns (on resumption use) showing up at some point.  Find a way to log resumption and new negotiations and build your case on your own traffics' statistics.


JSON Web Tokens (JWT) as user identification and authentication tokens I'm implementing a REST service that requires authentication. I cannot store any per-user state (such as a randomly-generated token) because my service does not have direct access to a database, only to another backend service.

The solution I came up with is creating a JSON Web Token (JWT) when the user authenticates. The JWT claims set contains the user ID in the Subject ("sub") field. The server then encrypts the claims set directly ("alg":"dir") using AES GCM with 256 bit key ("enc":"A256GCM") creating a JWE. The key is generated once when the service starts and stored in memory.

To authenticate, the client submits the username/password, and the server responds with the token described above. The client then sends that token with each subsequent request.

When the client submits the token with subsequent requests, the server decrypts it using the key, and assumes the user ID in the "sub" field to be the ID of the current user, without any further authentication checks. Token expiration is handled by the "exp" field in the JWT claims set.

The connection between the client and the server will use SSL/TLS, so the token will not leak.

I'm using this library to create and read JWTs as I don't trust myself to write correct cryptography code.

My questions:

Is the above approach secure? Can an attacker impersonate another user by manipulating the token?
Is the approach over-complicated? Would using MAC (in other words: JWS) instead of encryption have the same security? (or possibly more, since it's simpler and there's less chance of making a mistake). There's nothing particularly secret in the JWT claims set, and the user knowing their own ID doesn't matter.
Is my choice of JWE algorithm and encryption appropriate?

For the JWE "alg", the library I'm using supports direct encryption (using the key directly to encrypt the claims set) and RSA (generating a new key to encrypt the claims set for each token, and encrypting the generated key with an RSA public key). I chose the former because it's easier to generate a symmetric key than an RSA key.
For the JWE "enc", the library supports AES GCM and AES CBC HMAC SHA2 (with various bit lengths). I chose GCM arbitrarily.

Your basic approach is valid: generate the JWT when the user logs in, expect subsequent messages to carry the JWT, trust the subject field in the JWT in those subsequent messages if the JWT is valid. But there are several things you should be aware of:

As Daisetsu say, you could use a MAC ("alg":"HS256") as MACs are specifically designed to prevent alteration of the payload, while encryption algorithms typically (counter-intuitively) are not. However since you're specifically using AES in GCM mode, you already get tamper-resistant encryption ("authenticated encryption"), so that's not really a concern.
When validating an incoming JWT, be careful what you consider valid. For example, I could call your service with {"sub":"me","alg":"none"} and while that JWT is valid in some sense, it isn't something you want to accept.
Since JWT is a draft, not a standard yet, it might change. If it changes enough, the library you're using might have to change in ways that break compatibility with your code.
If you can't store any server-side state, you have no way to invalidate the JWT when the user logs out. In effect your service has no logout function, which may be a security problem especially if you set the expiration time too far in the future.
If you set the expiration time too soon, you may have a problem with users still being logged in but not having a valid JWT. This may lead to awkward error-handling and user workflow issues.

Since you said your server has no access to a database, I assume the actual login is handled somewhere else, perhaps the backend server you mentioned. You didn't say how your server knows that the user just logged in. Depending on user perception of the relationship between your service and the thing they know they logged into, the last two points above might be moot.


How hard it would be to infect a system with malware through a portable web browser If I use a portable web browser on a USB device like
Google Chrome Portable how hard it would be to get infected by a malware/virus in the system to which the USB device is connected?

Google Chrome brings the flash player with the browser and java can be disabled in the settings of the chrome browser. Also there is the sandbox of the chrome browser, so the virus first must break out of that sandbox.

If I get on a website with malware is it possible that the virus can leave the USB device and setup in the system to which the USB device is connected?

It doesn't matter where your run your browser from. You can run it off of your USB drive or off a network share, it still goes into system memory. Malware that would exploit that browser would have the privileges of the user that ran the browser.

Use Chrome or any other browser to browse to file:///C:/ or about:memory. The browser like any other process, has access to all of your computer, provided the user has access there.

If malware breaks through the browser sandboxes and executes code then the malware takes control of the browser and can do whatever it wishes.

This is a Chrome exploit in action https://www.youtube.com/watch?v=c8cQ0yU89sk (allegedly)


Corporate penetration testing/phishing If a company employs a security company to 'hack' into their systems and agrees to allow this security company to send fake phishing emails to employees...

...is that company (or the security company) legally liable if - in the process of falling for one of the phishing emails - an employee enters personal social network credentials which are then used (perhaps via logging into non-company systems) to gain entry to the company's (client's) systems?

This falls under the Testing Scope and all parties in a penetration test should anticipate the discovery of protected data and private credentials in the course of the test.

YOUR defined expectation as the client should be the explicit and reasonable assurance that any garnered data and social media credentials will be used within the confines of the scope and remain private and in the custody of the penetration testers for the duration and a stated period of time after the test completion and solely for the purpose of documenting the results.

If YOUR particular environment allows an employees access to corporate materials via their personal social media credentials, THEN YES you should include that within the scope of the engagement. The pentesters shouldn't do anything illegal against the social media provider themselves and hopefully they already know that !

An explicit clause of effective destruction of your garnered data, private credentials and all any "trophies" and any other of your internal materials you advance them or they capture will be destroyed no later than an agreed upon date and with a well known and industry accepted data wiping method of your approval.

There is no contractual agreement that insulates your pen tester from illegal activity, if they behave foolishly, illegally with those captured social media credentials, they'll be subject to applicable legal consequences both civil and criminal. The client (YOU) will have no say in their prosecution.... if something like that ever occurred.


Does using VPN or encryption on an Android phone do anything since Google knows who is logged into the phone? Is it worth paying for a VPN to protect myself from Google tracking since, on an Android phone, you're logged into a Google account and Google knows who you are, anyway?

Google can still track your activities depending on what Android OS reports to them. A related question would be whether encrypted messaging and email apps protect you on an Android since, once again, the OS is designed by Google and the OS can theoretically see the decrypted messages.

Specifically regarding VPNs, they are often marketed as a panacea to solve all security and privacy problems. While they can solve some problems, unfortunately much of it is just false hype and exaggerated for advertisement purposes.

VPNs protect network transit point-to-point from your device to the VPN server. They do not protect against anything outside of that. Google runs apps and services on the device that can collect data such as location (using GPS and nearby WiFi networks) and other usage data (browser history, app data backups, etc.). None of these things are affected by your network setup (e.g. VPN); as long as there is a working connection, things will be reported back to Google.

The only way to avoid Google tracking is to not use Google products. There are custom Android distributions (custom ROMs) that completely eschew Google's proprietary services, but many apps that rely on these services will break. Or, you could try to use an adblocker to block all Google related domains, but this would be very difficult.

Of course, you can't completely escape Google since they do all sorts of active and passive tracking across the internet.


Find SHA256 if I only have part of the string I need to find the SHA256 hash of s string like this: "part1-part2".
I know the SHA256 hash of part1 and I know what part2 represents, but I don't know what is the contents of part1.

Is there any chance I can compute the hash of the whole string using these two?

You may be able to compute a SHA256 of part1-part2, if you already knew SHA256(part1), and the value for part2.  This relies on a vulnerability in the underlying method of hash construction SHA256 uses (https://en.wikipedia.org/wiki/Length_extension_attack).

EDIT: To clarify the algorithm SHA256 will pad any input to a multiple of some given size.

Soo really you could think of it as SHA256(part1||padding), where 'padding' means x00 repeated till size(part1||padding) mod 512 = 0 (since SHA256 has a block size of 512 https://en.wikipedia.org/wiki/Secure_Hash_Algorithm).  This becomes a problem if any padding needs to be added to part1.


Can a student ID containing an NFC chip be cloned? The head of our IT department and Networking class in my college has given me and another student a challenge; he told us that if we could clone the  NFC tags in our student ID's used to sign in on time, he would give one of us unlimited access to the colour printers for a year. His main motto that he always talks about though is encouraging students to learn through experimentation regardless of whether the students ideas will work or not. He wants us to experience failure as well as success through our own attempts.

I'm  a bit skeptical as to whether it will work because I've read forums online that say this a futile attempt because no reputable academic institution or business would leave their NFC tags unprotected and completely vulnerable to complete cloning.

From scanning the card with my Android phone, I see that it uses a Mifare Classic 1k tag.

Does anyone have an idea how to replicate it? There are some cheap tags on eBay but I wonder if  I should bother if it's not even possible to clone it.

Many NFC enabled smartphones can write to these cards with an app like MifareClassicTool. However I've found several phones seem to be able to do it when in reality trying to write to Sector-0 bricks the card. It may be worth testing one or two cards and if it doesn't work buy a dedicated USB writer.

First of all a huge number of Mifare Classic Systems only use the ID on the card. This is stored in Sector-0 which is theoretically read only. Of course plenty of online sources will happily sell you cards where this is writable. Writing to the cards themselves is trivial.

The encryption on the cards has also been broken and again can be trivially cracked on a smartphone, as seen on Wikipedia: Security of MIFARE Classic, MIFARE DESFire and MIFARE Ultralight. My university used the same cards. As did an Oracle facility I used to work at…


electronic voting system Was looking at cryptocurrency and how, as a non techy, to get involved when I began thinking about the security of it being developed to undermine the stranglehold bankers have on economy and the unfettered misuse of currency by governments.  Very good. I applaud the theory and effort to overcome inequality.
If something as complicated as a secure currency can be developed electronically, why not voting?  As long as politics can be manipulated by bribes and rigging, it will happened, and the people will never have the government the people actually want.  Cryptovoting should be as feasible as cryptocurrency and would tackle corruption that maintains inequality.
Can someone explain why sorting the voting system is so hard compared to currency. (remember to use non techy words)

Cryptographically secure voting is difficult because voting encompasses so much. Let's take, for example, vote-buying or coercion.

Imagine a system where I can vote, and can verify that my vote was tallied correctly. Now I can provide that proof to a third party who purchased my vote to claim renumeration for that vote.

If the voter cannot verify their vote was tallied correctly, then how can the voter be sure that the authorities counting the vote are not corrupt, and deliberately mis-counting votes?

As it turns out, when you really get into the nitty-gritty of cryptographically secure voting systems, these sort of issues are found all over the place. Arriving at a consensus for a system of governance is inherently a social problem, and technical solutions almost universally fall short of helping in any large, meaningful way.

Further, there is the issue of the hardware and software platform. Many companies have attempted to produce "secure" voting platforms, but inevitably, they have shown to be weak to simple tampering attacks, or even just buggy to the point of uselessness. There's no time to deal with a batch of bad machines or fix a software bug when the election is held on a single day.


Configuring election website to prevent MITM attacks Consider an election web site that will be used for voting over the Internet.
What steps should the administrator of such a web site take to provide adequate security against man-in-the-middle attacks and spoofed web sites?  Can anyone suggest a checklist of top-priority items that should not be overlooked?  Assuming that the answer involves SSL, how should the site be using SSL and how should SSL be configured?

Motivation: Recently, some technical details about Halifax's use of web-based voting in the 2012 elections surfaced.  Based upon the publicly available information, it appears that they fell short of accepted practices for SSL configuration.  But what should they have done?  What should folks deploying web-based Internet voting make sure not to overlook, to defend against man-in-the-middle attacks and spoofing attacks?  How should they have configured SSL?

I'd prefer this to be a narrowly-scoped question that's limited to SSL configuration, MITM attacks, and spoofing attacks: other issues related to e-voting security (such as client-side malware, insider threats, voter authentication, etc.) are out of scope.

Use SSL sitewide. Enable SSL (https).  Make sure that any attempt to connect via http immediately redirects to the SSL site.
Follow accepted best practices. Refer to SSL/TLS Deployment Best Practices from SSL Labs.  Follow all of the advice there, including use of using SSL for all site traffic, marking all cookies as secure, avoiding mixed content, enabling HSTS, and other recommendations.
Avoid third-party scripts. Avoid third-party script (i.e., any Javascript downloaded from any other domain).  Avoid trusting any other sites or domains.  For instance, don't use third-party widgets or analytics; don't use ads; host all Javascript locally, on your own server.  They present an element of risk, and an elections context that sort of risk is probably unnecessary and undesirable.
Buy an EV cert. Spend the extra amount to get an extended validation (EV) certificate.  This will provide users with an extra level of assurance.
Use pre-loaded HSTS and public key pinning.  Register your domain with Google Chrome and Firefox, to request to add your domain to Google's and Mozilla's pre-loaded HSTS list.  This helps defend against SSL stripping and man-in-the-middle attacks, even for users who have never visited your domain before (and thus haven't had a chance to receive the initial HSTS information from your domain).  Enable pre-loaded public key pinning with them, as well, if you can.
Use forward-secure ciphersuites. Configure SSL on your web server to enable forward secrecy for all clients that support the corresponding ciphersuites.  See Deploying forward secrecy from SSL Labs for details on how to do this.  Generally speaking, you'll set the order of preferred ciphersuites on the server so that ECDHE is your first choice of ciphersuite; DHE is your second choice; and standard (non-forward-secure) ciphersuites are lower priorities.  Forward secrecy helps protect the confidentiality of all earlier communications (including voters' votes) if the server's private key is compromised after the election, which seems helpful in an elections context.
Support TLS 1.2. Make sure you support the latest versions of TLS, for voters with browsers that support those versions.  The latest versions of TLS are not yet supported by all browsers, but they add defenses against some recent attacks on SSL.
Check your site. After deployment, check your SSL configuration using the SSL checker at SSL Pulse (provided by SSL Labs).  Make sure you have a grade of A.  Fix any issues that the SSL checker spots.
Advertise the https URL.  When you communicate with voters to tell them what web page to visit to vote, list the full https: URL.  For instance, tell voters to enter https://www.elections.us into their browser, not http://www.elections.us or www.elections.us (the last two are treated identically by browsers, and may be vulnerable to MITM attacks).


Regarding Cross-Site Scripting attacks My application has an Upload Management Module and accepts Excel and text files to our server.

I detected invalid data inside some uploaded files (the uploader put <script>alert("XSS")</script> instead of the original data). I verified inside the database and that data was stored inside it.

I would like to know if my application is vulnerable.

We can't tell if it's vulnerable or not.

In protecting against stored XSS attacks (although the same applies to reflected attacks) there are 2 key stages where protection should be applied. When the data is presented to your system and when you present the data to other systems. If you know that you have protection in place which should reject pontential XSS attacks at upload, then it appears to be failing. If you have protection on the output channels then it's possible that this is not exploitable. But we don't know which of these you have in place.

You would need to look at how this data leaves your system to establish if this potential vulnerabilitiy can be exploited.


Is SipHash a secure alternative to HMAC-SHA256 for user authentication? After reading the Wikipedia page about SipHash I think it can be used like HMAC-SHA256 in JWT to create and verify API tokens (authenticate client devices).

In JWT the server creates this MAC to sign user identifiers (e.g. a number or email) with a private key which is then sent alongside the identifier with every request (after login).

Furthermore, the official paper states:

  Target applications include network traffic authentication

However, I can't find any pages on the web explaining this use case although it is much faster and has been out for a while.

Is HMAC-SHA256 more secure in any way or am I missing anything else? Thank you!

EDIT: SipHash output is typically only 64bit, so I am referring to SipHash double with 128bit like in the JavaScript implementation

The newer, 128-bit output version of SipHash is conjecturally appropriate for this task; i.e., if SipHash is as strong as its authors intend (if!), then yes, you can use it for that task.

An analogous remark can be said of SHA-2, but the main issue here is one of subjective confidence; cryptographers haven't examined SipHash in nearly as much detail as SHA-2, so subjectively, we have fewer reasons to believe it is as strong as it's conjectured to be, compared to HMAC-SHA-2.

So HMAC-SHA-2 is the more prudent option here.  I would only consider using SipHash if I'd conclusively shown, based on profiling data, that SHA-2 was a significant performance bottleneck for my application.


Securing a modem - computer connection I'd like to connect a pc directly to a dsl modem.
I know that routers can be hacked and e.g. DNS requests can be redirected. But what can be done to hack a modem (without a router!) and what can I do to prevent these attacks? I also read (though without any references) that a router provides more security compared to a modem because of NATing. Are there any more security benefits of a router? And does this outweigh the additional attack surface from the router firmware?
If I go without a router do I need to invest more in the security of the directly attached computer instead?

Believe it or not the modem isn't usually the attack vector because they often need physical access to be hacked. A wireless router is usually the attack vector because it opens itself up. If you're going to be the safest you can, you'd get a router(either wireless or wired) and put it between you and the computer. These extra jump steps make it harder for people t find your computer without knowing the exact configuration and often make you safer. To make it the safest you can get though I'd suggest a firewalled router, and if it is wireless and you don't need the wireless, turning off wireless. This is usually the best practice to protect a single wired connection in a residential environment.

Of course you could also go the extra mile and set up your own PF-sense box and just connect to that from your modem to your computer. But at that point you're literally building a router.


What information should I provide to a website or organization when notifying them that their domain may be sending out spam? Over the past few days, I've received several spam emails coming from the addresses of a school district. I don't know much about email message headers, but since they contain numerous references like this:

Received: from ecb-mx-out1.example.com (ecb-mx-out1.example.com. [<ip_of_example.com>])

that makes me think the address isn't just being spoofed, since it looks like the SMTP server sending out the messages is coming from the school district. I don't know that for sure, however.

If I choose to contact the district's IT department, what information would be helpful for me to provide? Or, since it's clearly possible that the address was merely spoofed, is it just a bother if I contact them and it's more beneficial to them if I just ignore it?

I can post the full message headers if necessary, but I'll probably remove the school district's name/IP address if I do.

You've hit the nail on the head - at the very least, provide the full headers from one of the spam emails.

However, I find it most useful when I get a sample of several of the spam emails (say, 3-10, if you have that many) because that allows me to see if the spammers are employing other methods, like changing the message content, subject, or format.

It's usually easiest to create a new email message, then drag and drop the spam emails into it. This adds them as an attachment, complete with headers. (Works in Outlook, Outlook Web, and Thunderbird, and many more I'm sure).

Edit: I forgot to mention; THANK YOU for asking what information would be most useful. The world would be a better place if everyone did that :)


Will hacking (pentesting) a live website from a VM improve or hinder my hacker anonymity? Would a pentest initiated from a VM mounted on hard drive be more or less anonymous to IDS attack or forensically traceable?

Please note: I will be browsing via tor and kproxy and have all that setup. So, again, the question pertains to the relative increase/decrease in security which a VM offers.

This question is being asked as a White Hat pentester in training.

A very common and highly-modernized attack is running AntiDetect on FraudFox. Criminally-minded adversaries discuss using these tools on leakforums, among other dark corners of the Internet. Obligatory video here -- https://www.youtube.com/watch?v=ZQN7CyCXh90

FraudFox is a guest VM used to hide digital fingerprints. More information here -- http://www.infosecisland.com/blogview/24258-Can-Hackers-Use-FraudFox-VM-to-Defeat-Your-Fraud-Prevention.html


How does a reverse proxy change the security posture of a web server residing in the DMZ? How does the reverse proxy change internal and external security posture with a reverse proxy compared to not having a reverse proxy?

For example, you have a publicly accessible iis server, what is the differences with or without being behind a reverse proxy?

There are a couple of advantages.

If your host sits behind a reverse proxy, you are implementing the "defence in depth" model.

Let's say your web server has an exploitable vulnerability which you have not patched yet. If your web server was directly accessible without being behind a reverse proxy, your host's vulnerability can be exploited, resulting in a compromised web server and potentially leaving all other hosts on the same subnet at risk. Furthermore, if your web server needs to communicate with a datasource (such as a database), you will be putting your data at risk.

If on the other hand, your host is sitting behind a reverse proxy, any vulnerabilities exploited would leave your reverse proxy compromised, and not your "actual" web server. This is usually in a segregated DMZ with very restricted access.

Further more, implementing a reverse proxy allows you to add additional security controls to your website without using up resources on your web server. These include web application firewalls, HIDS and more. You can also implement additional layers of authentication easily in such a scenario, should you need to.


Approach to authorizing users and X.509 certificates I have a system where I'm using X.509 certificates to authenticate the client to the server. The certificate is sent to an HSM to be signed. When it is returned it is used as part of a TLS connection. Once the connection is established, I need to authorize the user i.e. what actions they are permitted to perform against the server.
Can I use X.509 certificates and logic on the server? If so, what field / content would I populate on the certificate and what logic would be necessary on the server?

Client certificates generally use the common name field or the subject alternative name field to identify the client.  When the client presents the client certificate, your server will check that certificate signature is valid, and that the signature was made by a trusted CA, and that the client is in possession of the private key corresponding to the public key in the certificate.  All of this happens as part of the TLS negotiation.  If all of the above are true, then your server can authenticate the user in the common name field or the subject alternative name field of the certificate.
As far as which actions the user is allowed to take once the user is authenticated - these privileges should be stored in your database for each user, and your application logic should query the database to determine which privileges the user has, once the user is authenticated.
Related:  Client certificate common name? Subject alternative name?


Update intervals of VPN client code I recently had to find a VPN client to connect to a preconfigured Cisco IPSec VPN. Of course there's Cisco's own client implementation AnyConnect, but I wanted to stick with a free alternative if possible. (Edit: I also just read that AnyConnect doesn't support IPSec in the first place.) Said and done I found a couple of applications, but it appears they're all rather old:

For Windows there's mostly the famous Shrewsoft client. Its most recent release 2.2.2 dates back to July 1st, 2013.
On Linux vpnc is probably the most widely known implementation. It seems like its original maintainers abandoned it after releasing version 0.5.3 on November 19th, 2008. Anyways, that version is still being taken care of by different communities, e.g. Debian most recently patched it to 0.5.3r550-3 on November 23rd, 2016.
As a system-independent candidate let's add OpenConnect. Its most recent release is from December 13th, 2016.

Now for a widely used and security critical network application, I find it likely that vulnerabilities are found regularly and that security fixes are published every so often. However, I also realise that by now all these applications have had plenty of time to go through a lot of hardening. So here's my question:

How much of an issue is long update intervals for VPN clients like the ones mentioned above?

Shrewsoft hasn't been updated in 6 years either, but from your list if you look at OpenConnect CVEs there are a few listed over the years.

There are also various issues listed in Github.  The issues normally centre around DoS for the client from certain responses, or crashes/bugs in the program when making a request.  If your question was whether the encryption offered by a VPN is compromised in older programs, since they use well-defined algorithms that's probably not an issue.  If your question is whether they can be used securely on a system without issue, that's probably not the case since they mostly require root access to create a network interface.

Running any software that is not regularly updated or well maintained increases the number of vectors available for a malicious actor for attack however, so wherever possible using software that is no longer updated should be avoided.  Merely by installing them an issue might be created.


Are SSL browser sessions kept alive across requests? When a client requests an SSL web resource via a browser (ie: a login request) and then follows up with additional requests are all the requests executed in the same SSL session?  Or does the browser create and tear down the session with each request?

And do servers track session state across these requests solely through cookies which are encrypted over the SSL protocol or is there any functionality provided through SSL where servers know that the initial request came from the same browser as the following requests?  If it's just via encrypted cookies what is to prevent someone from spoofing the cookie value somehow and making a request with that spoofed cookie thus impersonating the original user?

TL;DR: HTTP sessions and SSL sessions are different entities and there is no mapping from one to the other.

Onto the specifics...

  When a client requests an SSL web resource via a browser (ie: a login request) and then follows up with additional requests are all the requests executed in the same SSL session?

Either the server or the client can terminate an SSL connection, but, for performance reasons, existing sessions are reused when possible.

  do servers track session state across these requests solely through cookies which are encrypted over the SSL protocol or is there any functionality provided through SSL where servers know that the initial request came from the same browser as the following requests

Cookies are typically the sole mechanism of session maintenance when communicating with a browser. Alternatives can be session IDs passed as hidden fields or sessions managed by custom JavaScript existing on the page. In fact, clients can multiplex multiple sessions over a single SSL connection. The one exception to multiplexing sessions is when mutual authentication is used. When this occurs, the client is authenticated during the TLS handshake. Establishing identity isn't the same as establishing a session, but they are certainly related.

  If it's just via encrypted cookies what is to prevent someone from spoofing the cookie value somehow and making a request with that spoofed cookie thus impersonating the original user?

You are referring to session hijacking. Some strategies that are used to prevent session hijacking are choosing a difficult to guess session ID (long and random is generally best), only passing the session ID cookie via SSL to prevent network snooping, and not allowing the session ID cookie to be accessed via JavaScript. Unfortunately, despite all of those defenses, Broken Authentication and Session Management continues to be the second most common security flaw according to the OWASP 2013 Top-10.


Security increase by use of uncommon IPs? I read here: https://www.privux.de/raspberry-netzwerk-einrichten/ about an implicit increase in security by using "uncommon" IPs in your home's LAN. That means not using 192.168.0.1, but 172.26.47.240 for example.

I think, if the attacker is already in my LAN, this method would not help me. If he is not in my LAN he cannot see the IPs anyway.

Maybe it is meant to make IP-Spoofing more "difficult"?

Can you explain what the increase of security is by using "uncommon" IPs?

For me it looks like "security by obscurity".

I'm focusing on using non-reserved IPs, because using the reserved ones, even the big ranges, is still easily feasible to enumerate. Your source leaves out any explanation for his reasoning and you are correct; this only helps if your network is already breached and then only insignificantly.
What your source is trying (and failing to achieve) is called network segregation - which is a good way of hindering lateral movement in networks.

Now: why even using all of the address space is a bad idea:

So, while using IP addresses that are not reserved for private use does in fact increase security (and in fact by obscurity), it is highly discouraged. If everything is configured correctly, this at least let's you run into problems when an IP you are trying to connect to over the WAN is routed in the LAN, because it's present there, too.

This increases security marginally by hiding a few local IPs not in the tiny space of reserved private IP ranges but all of the IP address space. But this only works if the machines you are hiding do not advertise services, do not respond to ICMP, ARP or DHCP requests or the like and you are using a switched network.

So there is a tiny chance that you are making lateral movement within your network harder for an adversary, simply by obscurity.

While security by obscurity is not considered secure, it at least adds a tiny bit of security to the overall security of the system; marginally so.

Additionally, be aware that using non-reserved IP addresses internally is not RFC-conform.


Is Windows+L a secure attention sequence? Ctrl+Alt+Del is a secure attention sequence (Microsoft) (or secure attention key (Wikipedia), but it's more a Linux term).
As we can read,

A key sequence that begins the process of logging on or off. The default sequence is CTRL+ALT+DEL.

it is only the default sequence, which means that other sequences might exist. In an answer to a related question, we can read that Win+Pwr is also a SAS, at least on some devices.
I've been using Win+L to lock my desktop, since I find it easier to use, and I even recommend that to other people. For my own research, this combination cannot be registered as a hotkey either. But: I have no official documentation on it.
Why do I even care?  If it's not a SAS, the key combination could be hooked (likely by a non-privileged application) and someone could show a fake login dialog on which I would then enter my password.
So, is Win+L a secure attention sequence?
I have seen previously linked questions and

How does CTRL-ALT-DEL to log in make Windows more secure? (ServerFault)
some code from 2010 where it might have been possible to bypass the combination, but it does no longer work on Windows 10 20H2
the flag LLKHF_INJECTED in KBDLLHOOKSTRUCT, which makes me believe that Windows can distinguish between physical and simulated keypresses, explaining why the code might not work any more
I am aware of the Registry key DisableLockWorkstation in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System, but that would affect Ctrl+Alt+Del as well

Answer is quite simple Win+L is not a sas and it does not need to be. It is used for locking the device.
There is a group policy to control the sas for triggering the login. You may set it so the CTRL+ALT+DEL is required for every login independently of how the station got locked, be it via shortcut, time-out or any other way, after all locked state is locked. Assuming that you require sas upon login there is no need to verify the locking sequence. Malicious software can be written in many different ways so overengineering protection for one feature does not make much sense. Screen overlay could be used to capture the click map used for locking the station from Windows context menu as an example. This is why it is much smarter to require sas on login.
There is whole different debate about users actually noticing the difference on systems that require sas and on those that don't.
It is worth noting that the policy is disabled by default due to wide use of touchscreen devices and overall bad user experience, so it must be activated to be used.


Is taking CC info in plain HTML elements, but using a library like Stripe to tokenize PCI compliant? I am building a site which will accept payments. I will be processing payments with either Stripe or Square. Stripe now has Stripe Elements, and Square has Square Payment Form. I have tried Square Payment form but it's hard to customize and loads really slow. And I would like to have easy control over the look and feel of the form.

My question is, if I take the card information in regular input fields but don't store the information and instead immediately send it over to Stripe/Square via their libraries upon submit, is this still considered safe/PCI compliant?

By making use of Stripe or Square you reduce your PCI burden since you are “outsourcing” handling of credit card information (CHD). This could make you eligible for filling in for example only a SAQ-A that has only a few mandatory controls to meet your PCI obligations.

The moment your site does ANY processing, storage or transmission of CHD, your PCI obligations increase. You might now have to fill in a SAQ-D for example. SAQ-D has a lot more mandatory controls that has to be adhered to.

If your site grows big enough and you have a QSA or Aquirer review it, you will have a hard time convincing anyone that your site does not store, process or transmit sensitive CHD. If you want to persist in creating your own site, review the various SAQ options to see what controls you will need to consider in your design.


Hardening Linux Server We have already had questions on here about Hardening Apache, Hardening PHP and Securing SSH.

To continue this trend I am interested in what steps people take to harden Linux servers. As in what steps do people always take when setting up a new server, that are not application specific. Such as setting the tmp partition to be noexec, uninstalling / disabling certain services, e.t.c.

Identify required applications and processes and apply a checklist to either avoid installing them, or worst case uninstall them after the initial build.

Here I'm thinking those common culprits which still seem to go on to far too many distros by default!

NFS services: nfsd, lockd, mountd, statd, portmapper
telnet server and ftp server
R services: rlogin, rsh, rcp, rexec
BIND and DNS server unless needed
mail servers such as sendmail
X11 (unless desktop needed)
finger daemon etc

Next step up is go through the potential weak services and limit access to them

use at.allow and cron.allow to restrict access to crontab
Ensure all devices are unreadable and unwriteable by ordinary users (excluding those such as /dev/tty and /dev/null etc)
Key files - permissions on these should be owned by root:
/etc/fstab, /etc/password, /etc/shadow
Carefully check hosts.equiv - a great source of access here :-)
Similarly, NFS config is locked down if it is required
Disable unneeded system accounts.
Look at filesystem - sticky bits for all executables and public directories.
Check all root requirements (PATH environment variable, no remote access as root, group membership, password requirements)
Check all user requirements (membership in privileged groups, valid shells, umask, SUID, SGID requirements
and of course the SANS guide is a really good source!


Is there a bulletproof way to configure your AWS system? I am learning how to configure a multi-region AWS system. However, everything I read says "if you want/need more security then do X". Why would anyone want less security (is what I start thinking)... Is there a way to create a bullet proof AWS system? If so, what are the key pieces? If not, how can I prove that to someone who asks?

Why would anyone want less security

Nobody wants less security, but high security usually are also harder and more expensive to maintain, which can also mean having more likelihood for errors. Many companies opt to use simpler system that are less secure than possible because that's good enough for their purpose.

bullet proof AWS system

There's no such thing as bulletproof system. Security at the infrastructure level is mostly a matter of configuration. Even if the underlying software itself are bug free, you can't beat a system administrator that undermines their security by configuring their firewall to allow any traffic to all machines, and then claim that their system are secure because it has state of the art bug-free firewall.


Is there anything I can do about IDN homograph attacks? I have been reading about IDN homograph attacks, and I cannot think of any better way to deal with them than

Tell my users not to trust emails asking for passwords, etc
Buy all domains similar to mine (expensive and difficult)

Is there really nothing else I can do?

My suggestion would be to use two-factor authentication. If you chose not to use two-factor auth I would suggest getting out of the authentication game and using "login in with *" where * is facebook/google/yahoo etc, this moves the burden of preventing fishing attacks to companies that have the money and resources to do it well.

See https://stackoverflow.com/questions/5087005/google-authenticator-available-as-a-public-service for an example of an easy and cheap second factor to use.

As a last resort you can use a two password scheme, also known as password plus secret question. Where the second password you only collect certain letters of the password, and which letters you collect change on each login e.g.:

Username: ......
Password: ......
3rd, 6th and 7th letter of secret word:
          3rd .. 6th .. 7th ..

This will increase the chances of the user noticing a fishing attack before the attacker has found enough information to login as the user.


Why Malware doesn't use VPN's I have heard of malware using TLS, RC4, and XOR to encrypt command and control communications. Why is it that malware doesn't use VPN's? For example Ipsec vpn, I would think this would make end to end traffic much more secure and encrypted.

The goal of malware is to hide itself against detection, which means hiding the communication and hiding its activity on the infected system. Hiding communication can be done by blending into normal traffic by using protocols which are pretty common and which are not blocked by firewalls like HTTP, HTTPS, DNS etc.

IPSec to arbitrary endpoints isn't really common in most environments so using it would make the malware actually stand out. Apart from that IPSec is usually implemented at the kernel level and would show up as an additional network interface on the machine (which also could be used by other applications). While one could likely implement all of IPSec in user space too it is complex. But why do such efforts if there are much easier and more stealth options in the first place.

With other VPN like OpenVPN, Wireguard etc it is similar. While they might be more common for home users since they are the underlying technology for free and commercial VPN providers use of these in company environments would actually be especially suspicious. Employees are typically not supposed VPN from their own workstations in the first place so that would clearly stand out of the normal traffic. And also here the complexity is much higher than with TLS so only more effort while being less stealth, i.e. no advantages but only disadvantages.

  For example Ipsec vpn, I would think this would make end to end traffic much more secure and encrypted.

TLS is secure enough if properly used. Even RC4 might still be secure enough depending on the use case. There is no need to be "much more secure and encrypted" than this in most cases, and IPSec isn't even more secure than TLS. If you only want to transport a pizza you don't need a truck even though it is more powerful than a small car.


Questions regarding Bad USB exploit I own a Netbook and my external DVD Drive is possibly infected with Bad USB.

If I install Ubuntu using this infected DVD drive, could my system be taken over during installation process or later when the drive is already unplugged?

Suppose I am installing offline and setting a strong sudo password during installation and unplugging the DVD drive right when the installation is finished and before there is an Internet connection.

What happens during the installation of Ubuntu

Let's solve this problem first:

  don't really know what exactly happens during installation of ubuntu

Then I think you'll understand where you can be attacked.

The BIOS

The BIOS is stored on a flash chip. Typically we say rom on the motherboard but the truth is it's probably stored on an SPI flash rom and you can probably detach and flash it if you like.

Anyway, the CPU (your x86) will have its instruction pointer set to the reset vector on boot. After doing some initial magic, the code at the reset vector will load your BIOS from ROM then boot that.

What does the BIOS do?

The BIOS tries to normalize the system in an expected way such that it can provide a language for applications to speak and get things done in a platform independent way. This seems crazy at such a low level, but is actually the case.

As well as setting the system into a nice state for the rest of execution the BIOS can also talk to hardware. One of the steps it takes here is to look for option ROMs and load these.

Once it is done getting the system ready to boot, it must then decide what to boot. For hard disks, it understands how to parse the master boot record and will load a valid MBR to 0x0:7c00 and quite literally set the instruction pointer to the first instruction and say go. So the MBR is both executable code and a data structure describing the partition. Ahhhhh DOS. Thems was the days!

But you wanted to boot an ISO? No fear. Data disks are described by the el-torito specification, which allows an ISO to optionally contain a boot record with corresponding boot image code. As an aside, if you ever wondered why you can't find the [boot] file you see in 7Zip on the ISO itself, that's because it's kept outside the actual chosen file system of the disc in a different "record".

Anyway, the BIOS loads this too by it's usual put it in memory and set the eip to the start of it method.

Bootloader to kernel

The bootloader's job is to find a kernel and set the environment up in the right way for that kernel, then let the kernel get on with life. In the case of your Ubuntu ISO, this is likely grub which will search the disk for an appropriate, possibly pre-programmed-into-grub vmlinuz kernel - a compressed kernel image. I'll skip this step as it isn't very interesting but suffice to say the bootloader is likely running in protected mode with no paging and the kernel will go from here, probably switch the CPU into long mode (x64) and will certainly start talking to hardware essentially independently of the BIOS.

OK but how do I do something with my kernel?

the Linux kernel doesn't typically boot alone. You should never after all boot alone. Instead there is a ramdisk (initrd) present even on your machine which acts as a kind of temporary root file system providing basic support binaries. All of this is loaded into ram.

For the purposes of your install media, this probably also comprises the right software to set up the system or may even comprise an entire live distribution. When the kernel is ready it will find the "initial process", the first thing created in userland (you've heard of this - sysvinit, upstart, systemd are three examples) and run that. From there... you are in the land youu know.

How do installs function

Very briefly, once the system is up and running there is no reason it cannot read the CD-ROM. There's also no reason said CD-ROM cannot contain a repository of deb or rpm packages. With the right installer code you can partition the target hard disk and install each of those packages into the chroot.

Universally Sneaky Bus

So now you should have a vague feeling of knowing what your Linux install media is doing. Now let's talk USB.

USB is a host-device protocol. When you plug something in, the host plays 20 questions with the device asking it a myriad questions. Amongst the rounds of animal/vegetable/other are the questions "what device class are you?" and "who made you?"

USB device classes allow very common cases of USB hardware to talk in identical ways. You can think of USB as the transport (like say TCP/IP) and device classes as the application layer protocol (http, imap). This is just an analogy of course.

In the case of BadUSB, one of those devices, an endpoint in our network, is going to lie it's little heart out. It could do many things, but let's go back to the boot process above. At one stage the BIOS needs to do two things: parse the CD-ROM record data (ISO9660) and read the el-torito entries to get the boot code for the live cd.

Since BadUSB firmware tells lies, there is no reason that this step cannot replace the boot code with something malicious. From there, the malware simply needs to set hooks all the way up the boot process until it can run safely in the kernel. This is demonstrated in vbootkit2 (where the ISO boot image is already malicious, rather than being substituted by the firmware).

For your live CD, I'd think this is the biggest concern. Once the malware has a "bootkit" in your install, there is no reason it cannot alter the install process to persist, or otherwise drive the live install to attempt to infect your system further.

A keyboard-pretending device plugged in whilst your install took place would allow the keyboard to inject commands onto the system - I haven't looked at the Ubuntu install media for a while but there is usually a drop to terminal session. However, I'd suggest an attack like this would be even more complex than attacking the bootloader - with code you can detect and adapt to changes but with hard coded commands you are limited.

Of course, the practicality of all of this depends on storage space in the USB firmware device, since you're going to need to store sufficient binaries to at least bootstrap your malware from the network (or sufficient strings of characters to do it via a keyboard). Remember, to work you still have to do most things firmware usually does - such as drive the CD-rom in this case.

I am not personally familiar with the average space available to firmware on commodity external dvd drives... it could well be enough at the time of writing, but maybe not.

Am I at risk?

Probably not. While targeting the load address of the bootloader from CD or even hard disks is easy since it is known, knowing where to patch in the boot process versus the immeasurable number of linux distributions and kernels (and even bootloaders) out there makes this very tricky to implement except against specific, individual targets. That said it is not impossible.

The best example I know of a boot-based attack is vbootkit2(openoffice presentation link, Possibly NSFW: contains proof of concept for malware). In the downloadable code, vbootkit2 has a malicious boot sector on their live ISO that attacks the Windows kernel on your hard disk by patching each step of the boot sequence essentially as I describe above.


Pre boot authentication for Android phones is there any way to have pre boot authentication on android phones? It would be nice if it would work with YubikeyONE's one time password mode.

What would the use be of preboot authentication when Android doesn't support full disk encryption for all files and folders? none.


How To Patch LFI Vulnerability I'm pretty sure that you all are aware of this vulnerability, but i wonder how to patch this? I have seen this code in a tutorial that it is the way to patch this but still user can access all the files of the current directory:

<?php
$page = $_GET['page'];
if(@strstr($page,'../')){
    die('LFI Attempt Detected');
}
include($page);
?>

Please suggest a good way to patch this vulnerability.

The presented mitigation is absolutely insufficient. It’s not just possible to include any file from the current directory but also from any directory depending on the file system  (i. e., \.. still works on Windows) or by using an absolute path (e. g., /… on Unix-like systems, or \… on Windows) as well via different protocols/wrappers (e. g., http://…, file://…, ftp://…, etc.), allowing the execution of arbitrary PHP code.

If you don’t want this, you should validate the parameter value. For example, if you only want to allow certain values, use an array and check whether the given value is in it:

$validValues = array();
if (!in_array($page, $validValues, true)) {
    die("invalid 'page' value");
}

If you want to allow any file within a certain directory, you could check whether the resulting absolute path is still pointing to a file within that directory using the technique described in Preventing Directory Traversal in PHP but allowing paths.


Re-installing GnuPG Suit - should I keep a copy of keyring? I am currently going through PGP & GPG book.  I installed GnuPG Suit a while back but did not verify checksum nor signature.  I somehow created a key.  Obviously by playing around.  I now want to verify that the software is authentic but don't have the dmg file.  Should I delete the software and re-download?  And if so, do I copy from it my keyring?
Thank you.

You can try to export keys from your keyring and save them to a secure place.

As written here, https://gist.github.com/chrisroos/1205934 :

gpg --export-ownertrust > path/to/secure/directory/gpg.txt

And, to import it back, you could :

gpg --import-ownertrust your/ownertrust/gpg.txt


How should web app developers defend against JSON hijacking? What is the best defense against JSON hijacking?

Can anyone enumerate the standard defenses, and explain their strengths and weaknesses?  Here are some defenses that I've seen suggested:

If the JSON response contains any confidential/non-public data, only serve the response if the request is authenticated (e.g., comes with cookies that indicate an authenticated session).
If the JSON data contains anything confidential or non-public, host it at a secret unguessable URL (e.g., a URL containing a 128-bit crypto-quality random number), and only share this secret URL with users/clients authorized to see the data.
Put while(1); at the start of the JSON response, and have the client strip it off before parsing the JSON.
Have the client send requests for JSON data as a POST (not a GET), and have the server ignore GET requests for JSON data.

Are these all secure?  Are there any reasons to choose one of these over the others?  Are there any other defenses I'm missing?

The first defence is to stick to the specification by using valid JSON which requires an object as top level entity. All known attacks are based on the fact that if the top level object is an array, the response is valid Java Script code that can be parsed using a <script> tag.

  If the JSON response contains any confidential/non-public data, only serve the response if the request is authenticated (e.g., comes with cookies that indicate an authenticated session).

That's the pre requisite for the attack, not a mitigation. If the browser has a cookie for site A, it will include it in all requests to site A. This is true even if the request was triggered by a <script> tag on site B.

  If the JSON data contains anything confidential or non-public, host it at a secret unguessable URL (e.g., a URL containing a 128-bit crypto-quality random number), and only share this secret URL with users/clients authorized to see the data.

URLs are not considered a security feature. All the common search engines have browser addons/toolbars that report any visited URL back to the search engine vendor. While they might only report URLs that are explicitly visited, I wouldn't risk this for JSON URLS either.

  Have the client send requests for JSON data as a POST (not a GET), and have the server ignore GET requests for JSON data.

This will prevent the <script> include.

  Put while(1); at the start of the JSON response, and have the client strip it off before parsing the JSON.

I suggest a modified version of this approach: Add </* at the beginning. while(1) is problematic for two reasons: First it is likely to trigger  maleware scanner (on clients, proxies and search engine). Second it can be used for DoS attacks against the CPU of web surfers. Those attacks obviously originate from your server .


Metasploit & openvas error (openvas_connect) I'm using Kali 4.3.0 and trying to run openVAS plugin into the Metasploit. OpenVAS (version 8.0) works properly on port 9392, metasploit is ok too. This is log of error:

msf > openvas_connect admin admin 127.0.0.1 9392 ok
[*] Connecting to OpenVAS instance at 127.0.0.1:9392 with username admin...
[-] Error while running command openvas_connect: OpenVAS OMP: Error in OMP request/response

Call stack:
/usr/share/metasploit-framework/lib/openvas/openvas-omp.rb:110:in `rescue in sendrecv'
/usr/share/metasploit-framework/lib/openvas/openvas-omp.rb:100:in `sendrecv'
/usr/share/metasploit-framework/lib/openvas/openvas-omp.rb:178:in `auth_request_xml'
/usr/share/metasploit-framework/lib/openvas/openvas-omp.rb:251:in `login'
/usr/share/metasploit-framework/lib/openvas/openvas-omp.rb:132:in `initialize'
/usr/share/metasploit-framework/plugins/openvas.rb:192:in `new'
/usr/share/metasploit-framework/plugins/openvas.rb:192:in `cmd_openvas_connect'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:427:in `run_command'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:389:in `block in run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:383:in `each'
/usr/share/metasploit-framework/lib/rex/ui/text/dispatcher_shell.rb:383:in `run_single'
/usr/share/metasploit-framework/lib/rex/ui/text/shell.rb:203:in `run'
/usr/share/metasploit-framework/lib/metasploit/framework/command/console.rb:48:in `start'
/usr/share/metasploit-framework/lib/metasploit/framework/command/base.rb:82:in `start'
/usr/bin/msfconsole:48:in `<main>'

How can I solve this issue?

Don't Connect to 9392. Instead Connect to 9390

  openvas_connect username password localhost 9390 ok


Trouble understanding the explanation of "server certificate" message in RFC 5246? The following texts are found in the explanation of "Server Certificate" message in the RFC 5246 TLS 1.2 at page 46.

7.4.2.  Server Certificate

When this message will be sent:

  The server MUST send a Certificate message whenever the agreed-
  upon key exchange method uses certificates for authentication
  (this includes all key exchange methods defined in this document
  except DH_anon).  This message will always immediately follow the
  ServerHello message.

Meaning of this message:

  This message conveys the server's certificate chain to the client.

  The certificate MUST be appropriate for the negotiated cipher
  suite's key exchange algorithm and any negotiated extensions.

I don't understand the meaning of:

  The certificate MUST be appropriate for the negotiated cipher
    suite's key exchange algorithm and any negotiated extensions.

Can someone explain?

A certificate chain is just a list of certificates each certifying the next so that you can start at some certificate you trust and conclude that the certificate for the server is valid.

Appropriate is a little difficult to explain in detail but if you look at sample certificates you will notice that the certificate includes things like

         X509v3 Key Usage: critical
             Digital Signature, Key Agreement
[...]

Signature Algorithm: sha256WithRSAEncryption

And appropriate means that you can only use the certificate for the given protocols and with the right key format and so on.


Protect API from being tampered? I'm building an API with websocket that serializes data through JSON. The App itself is a chat application. I came up with the following structure to send my data:

{date: '2020-05-31', time: '14:28:05', text: "Hey!", to: '<id:int>', from: '<id:int>'}

The user basically sends a message through the browser and this is received in a websocket server. The from: 'id' would be from the user sending the data whereas the to: 'id' would be to the user the data is being sent.

Looking at this I have a very bad feeling. My thoughts; The user using the App would in theory authenticate and that's where he would get his id. Then the receiver would have another id, such that is not the same as the authenticated one (obviously). The server would then look for that id and send the message but I'm not sure if this is secure.

I have some aspects that I think must be dealt correctly to protect the app from any attacker:

What if the attacker decides to tamper the "from:id" such that it could send arbitrary messages to anyone from any user?
What if the attacker builds a script that spams millions of messages by taking advantage of the "to:id" field?

Is it possible there is another security issue that I'm not concerned of?

What if the attacker decides to tamper the "from:id" such that it could send arbitrary messages to anyone from any user?

Create a session, and use the session identifier as identifier, not the user ID directly. E.g. let user send credentials, and upon successful validation, return a (short lived) session handle, that can be used in future messages.

Validate that the session exists and is active, and map it back to user server-side.

  What if the attacker builds a script that spams millions of messages by taking advantage of the "to:id" field?

Rate limit users server side. For instance, disallow sending messages to more than ten different users a minute. This will probably not bother legitimate users, but will hamper spammers efforts. Tuning of the limit may obviously be needed - and it may be an idea to raise it for trusted users, based on behavior, and lower it upon receiving reports about spam from users.


Is this possible with SSLsplit? SSLsplit supports plain TCP, plain SSL, HTTP and HTTPS connections over both IPv4 and IPv6. For SSL and HTTPS connections, SSLsplit generates and signs forged X509v3 certificates on-the-fly, based on the original server certificate subject DN and subjectAltName extension. SSLsplit fully supports Server Name Indication (SNI) and is able to work with RSA, DSA and ECDSA keys and DHE and ECDHE cipher suites. Depending on the version of OpenSSL, SSLsplit supports SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2, and optionally SSL 2.0 as well. SSLsplit can also use existing certificates of which the private key is available, instead of generating forged ones. SSLsplit supports NULL-prefix CN certificates and can deny OCSP requests in a generic way. For HTTP and HTTPS connections, SSLsplit removes response headers for HPKP in order to prevent public key pinning, for HSTS to allow the user to accept untrusted certificates, and Alternate Protocols to prevent switching to QUIC/SPDY. As an experimental feature, SSLsplit supports STARTTLS mechanisms in a generic manner.

Does this mean I can copy a certificate from a client(Firefox's built in store, Android's, etc.), then run SSLsplit using the copied certificate? Then I can inspect traffic from devices and programs that use custom certs and don't allow you to upload your own?

You question of

  Does this mean I can copy a certificate from a client(Firefox's built in store, Android's, etc.)

is answered by:

  SSLsplit can also use existing certificates of which the private key is available, instead of generating forged ones.

Since you don't have the private keys for the CA certificates in the built in store you cannot use these.


OpenSSL implementation vulnerabilities vs TLS 1.0 holes I have been reading a fair bit on OpenSSL vulnerabilities and the various SSL protocols' strengths. As far as I understand it any protocols older than TLS 1.0 are to be avoided at all cost (some would argue that TLS 1.0 should be avoided too since it's only an "upgrade" from SSL 3.0). I also understand that this is due to weaknesses in the protocol and that this would affect any implementation.

To be able to make use of TLS 1.1 and newer protocols, you have to upgrade OpenSSL to at least the 1.0.1 suite. It seems that lately, the security community has done some amazing work in picking holes in the newer implementation of OpenSSL. It looks like every 2-3 months a new vulnerability is discovered and patched.

The way I see there are 3 options:

either you stay with a weak protocol but a fairly stable software implementation
or you upgrade to a less stable software (OpenSSL) implementation and risk that the protocols are not implemented correctly
or you look at different software other than OpenSSL and risk more implementation holes

What do people think of that assessment?

I guess what I'm asking is what is the least bad of the two evils?

If I understood correctly, you think that older versions of OpenSSL are more secure than to newer ones. This is simply not true.

Since the Heartbleed vulnerability the project got a lot of attention and that results in a larger number of discoveries / fixes, but those are present in older version as you can see.

All versions of the TLS protocol is vulnerable to the so-called Padding oracle attack, because it uses the MAC-then-Encrypt scheme. Newer TLS versions generally make a lot harder to exploit this vulnerability. The fix to this problem was introduced with TLS 1.2 as new ciphersuites that use authenticated encryption (AES-GCM). Using these cipher suits makes the exploitation of the padding oracle attack practically impossible. This issue is well-understood among experts so TLS 1.3 will remove support for all ciphersuites that doesn't use authenticated encryption. Because of this some experts even say that any TLS solution without AES-GCM support is broken. The important thing is that using TLS 1.2 is not enough, you also have to use an AES-GCM ciphersuite.

All in all, my advice is to use the latest available OpenSSL with modern ciphersuites and update often.


How much more secure is fingerprint compared to text passwords? Mathematically, how much more secure is fingerprint compared to textual passwords? Like is there any detailed mathematical analysis?

Fingerprints are not supposed to be used on their own for authentication. The fact that many devices are starting to do that does not mean it is a good idea. In security, you should authenticate yourself with three different factors: something you have, something you know, and something you are. You can have a smart card, or an encrypted hard disk. You can know a secret password, a pin, or a pattern. And you are a person with a fingerprint, a person with a particular typing pattern, or a person with a specific speech pattern. Often, people only use the latter two, for example a username (something you are) and a password (something you know). See these lecture notes. It explains this all very well.

A fingerprint is like a username. All a username does is allow authentication using a non-secret value so there is no issue with "error: this password is already taken". Less information is revealed when the message is "error: this username is already taken". This is the purpose of the username. But how is a fingerprint the same? A username is something easy to discover, usually it's plastered all around or simply a variation on a person's name. A fingerprint is the same. It is plastered all around. You don't need high-tech forensic equipment to pull a fingerprint off of anything. While some devices try to use slightly more advanced fingerprint scanners (e.g. using capacitance detectors to avoid being tricked by high-res photos of a fingerprint), they are still not all that good.

Finally, you asked how fingerprints compare mathematically. This cannot be answered because a fingerprint is not a mathematical value. You would have to see how the specific implementation of fingerprint reader works. How many unique points on a fingerprint does it take into account? What is the variation among different populations for these specific points? With a password, the strength is simply the equivalent of the amount of entropy present in the password. Unlike fingerprints, passwords can be made truly random.

A fingerprint is a username that you don't have to type in every time.


How and when is a MAC sent across during a TLS connection? I have been trying to get my head around the MAC part of the TLS connection as both the key exchange and cipher seem to make sense.

As far as I understand the MAC is used to ensure that the information that is received is authentic, but here are my questions:

Is a MAC sent only during the handshake (the async bit) or is one sent with each piece of transferred information (both the async and sync bits)?
When a client talks to a server, does it always send a MAC?
When a server talks to a client, does it always a send a MAC?
In regards to TLS, is a MAC created via EtM, E&M or MtE? In short, is the MAC sent as plaintext?
If a MAC doesn't match-up is the connection terminated? Does the whole handshake process have to begin again?

Is a MAC sent only during the handshake (the async bit) or is one sent with each piece of transferred information (both the async and sync bits)?

Both.

The handshake is MACed via the PRF (pseudo-random function).

Each record is MACed by the TLS-MAC. (Unless you're using one of the fancy new AEAD cipher suites like GCM, which take care of the MACing themselves.)

When a client talks to a server, does it always send a MAC?
When a server talks to a client, does it always a send a MAC?

Yes. Direction does not matter. (Only cipher suite type: One of Stream/Block/AEAD. And stream and block do have the external TLS-MAC and AEAD does the MACing itself.)

In regards to TLS, is a MAC created via EtM, E&M or MtE? In short, is the MAC sent as plaintext?

The default case is to use the MAC-then-encrypt. And this is not really regarded as hip anymore. You can switch to Encrypt-then-MAC only via a newish TLS extension

If a MAC doesn't match-up is the connection terminated? Does the whole handshake process have to begin again?

Yup. And this is quite reasonable if you are communicating over a protocol like TCP that is supposed to guarantee integrity against things like line-noise. This bad_record_MAC alert is always fatal and will abort a session.


Is it a security risk to embed a commenting service (like Disqus) into our site? Can commenting services like Disqus, IntenseDebate, etc. pose a security risk for corporations?

Edit:
What risks could arise when embedding such services into corporate websites?

Answer to the original question: No, it's not a security risk for your employees to use Disqus etc. -- at least, no more than any other form of communication.

Of course, if employees post sensitive corporate information on these systems, then that may harm the corporation's interests.  But you could say the same of any other means of communication.  Hopefully, you train employees not to do that, and can rely upon them to be sensible.

Answer to the edited question: Yes, embedding these services on your corporation's web site is a security risk.  The way you embed them is by embedding some Javascript and running it on your web domain.  Since that Javascript gets access to your website, cookies for your website, your user's passwords on your website, etc., this requires complete trust in that Javascript.  If the third-party comment provider (e.g., Disqus) is malicious or suffers from a security breach, it could use the access it has to attack your web page and your users.  For more details, see Jeremiah Grossman's Third-Party Web Widget Security FAQ.


Why does facebook php sdk (and multiple others clients) include CA bundle with a lot of CAs? This is what facebook ships with their API php client: https://github.com/facebook/facebook-php-sdk-v4/blob/master/src/Facebook/fb_ca_chain_bundle.crt

It contains dozens (hundreds?) Root CAs.

But doesn't it make the client more prone to MitM attack?

To clarify why I think: it's more chance that some of CA certificates will be compromised, than if they included a single certificate - the exact one they sign their certificates.

Am I missing something?

Like written in the File Head, this file is basicly just a copy of the CAs from Mozilla. This allows the use in cURL, to check if the Certicate is valid or not.

It is not like this would be tons of additional random CAs, it is just a copy of something the most browser will already have, just attached to use it with cURL or anything else.

An issue could be if one CA gets compromised, you had to remove it manually from the file, since it is not bound to any updater like a browser.


how to test on which TLS Version has https connection established between server and a mobile application ( Android and iOS )? Testing for Poodle attack vulnerability.

Also, I could sniff the packet from wireshark and see the TLS version. I want to find if there is any other way available by which I can test this?

Sniffing the packets with some application like Wireshark would reveal the information; the protocol version used in a connection is in the ServerHello message (take care to look at the server_version field, not the "version" in the record headers, which may not match).

If you don't want to use a packet sniffer, you may try to modify the DNS so that the connection request from the application does not go to the intended server, but to another computer that you control. On that computer, you can then run a small server software that binds to port 443 and receives the ClientHello message from the client. Looking at the message contents, you could see the maximum version supported by the client. By sending yourself the message to the intended server, you could also obtain the corresponding ServerHello and see for yourself. Using a packet sniffer would still be simpler, though.

(Altering the DNS should be doable on the WiFi access point, if the mobile connects through WiFi.)

You cannot obtain the information without connecting at some point to the true server, either from the mobile application or on your own; the reason is that the protocol version is the result of a negotiation between client and server. The client suggests, but the server chooses.

An additional issue is protocol downgrade attacks. It is improbable that your client and server using SSL 3.0 by default; it would require that either or both implementation are unaware of TLS 1.0 (published in January 1999 !). However, it is conceivable that SSL 3.0 could be forced upon them. The method is simple: the attacker simply breaks (with RST packets) any connection where the client announces anything newer than SSL 3.0 in its ClientHello. Some clients will then try again, voluntarily restricting themselves to SSL 3.0. If your application is such a client, then the protocol downgrade attack succeeds and the connections will use SSL 3.0. The problem here is that you cannot know whether a protocol downgrade attack applies without trying it: it hinges on the client behaviour under abnormal circumstances, so you have to force the abnormal circumstances. You are then back to the sniffer plan, with a vengeance.

On the other hand, you might get the information you seek by simply connecting to the server. From a computer with OpenSSL (e.g. any Linux or MacOS X system), try this:

openssl s_client -ssl3 -connect theservername:443

replacing "theservername" with the actual server name (and possibly replacing the port if the connection does not use the standard 443 port). OpenSSL will try to connect using only SSL 3.0 as supported protocol. If the server rejects the connection right away with a "protocol_version" alert message, then you know that the server does not accept to use SSL 3.0, and thus the connection between app and server will never use SSL 3.0, regardless of protocol downgrade attacks.

But if the server accepts a SSL 3.0 connection, then all options are still open, and you are back to trying the downgrade attack.