Secret Santa and Windows Security When i turned on my pc at the office this morning i found a file (text document) on my desktop saying that my secret santa salutes me and gave me a clue for where to find my gift.
The weird thing was, when i opened the file details (using the file properties) i found that i was the owner of that file, 2 seconds later the file was deleted automatically.
If we put the probability of that person being a system/windows admin aside, was my PC breached ?

My Pc is always locked when I'm not using it and No one has my password.

The hint given in that file was very helpful for me to find the gift so I'd say it was a friendly hack.

My main concern is, if someone can put files on my desktop (without accessing my pc using my username and password) then what's stopping him/her from viewing my files or even copying them.

Anytime you find content that you didn't create and that looks dubious and unfamiliar, it's worth while to suspect a breach.  Socially, when you think about it, even in a non-computer environment, Secret Santas are a bit of a security hack - hiding things in places that are yours (to some extent) and yet that you didn't give explicit permission to enter is a typical pattern in much of Secret Santa gift giving.  The difference, at least in the real world, is that Secret Santa gifts are intentionally non-destructive, non-malicious and hopefully well intentioned if not beneficial.

When it comes to computers - if you aren't a forensics expert, it's pretty hard to tell what's happened to your system.  Worse yet, doing a lot of research can destroy any evidence that would be useful if law enforcement is needed.

A self destructing file that appears saying something cute and social is generally a decently typical pattern for malicious software, so it's fair to be concerned.

So... for a next step:

can you think of an explainable case for someone to have been pranking you or being an honest Secret Santa?  If so, talk to them an ask.  These days, tampering with computers is a bit creepy and it's worth it to point that this isn't such a great way of delivering what was hopefully meant in the spirit of fun.
if you can't find or think of a friendly culprit - report the issue to whatever security group you have available - when in doubt, an IT help desk is a fine place to start, or an information security group.  This is a do not pass go, do not mess with your computer type scenario - leaving your computer running, and untouched while asking for help is really the best approach - even for a semi technical user.
if this is a personal system, check into common hacks that match the behavior you've seen with google, and ponder the idea of well-reputed anti-virus software.  Also, it may be worth a trip to tech support if you see odd behavior.


How does LastPass know that I used the same passphrase with another service? So today I switched from Lastpass (chrome extension and iOS app) to bitwarden.
So far so good, it was really easy to export my lastpass data and import it in bitwarden however what I am wondering is how LastPass knew I used the same passphrase with bitwarden !
Let's say my lastpass passphrase was "CorrectHorseBatteryStaple" and I used the same password on bitwarden (both same email), I after then received a lastpass notification (just after creating my bitwarden account) informing me that my passphrase was used on bitwarden and in case of a breach coming from bitwarden they can't do anything...
How could they know that I used the same passphrase, and are my passwords safe or should I change them all (I already changed my passphrase) ?

This is locally verified by the Lastpass extension so that you don't reuse password manager's master password itself somewhere else. Password managers use credential management API to capture credentials from the webpage.
To derive an encryption key from master password, Lastpass feeds master password into PBKDF2 with 100,100 iterations of SHA-256. One more iteration (that is 100,101) gives login hash for the Lastpass web service.
For every credential that it captures, it feeds entered password to the same key derivation function. After 100,101 iterations, if it produces the same hash as the login hash, that means you have reused the master password. It works locally and also at offline.

Why did my LastPass extension just warn me that I was reusing my Master Password elsewhere?


Apache naming for TLS_RSA_WITH_3DES_EDE_CBC_SHA According to NIST and HIPAA guidance, I miss one cipher on a new web server:

TLS_RSA_WITH_3DES_EDE_CBC_SHA

Despite I read this one is discouraged, I am curious as to how do I add it?

I am on Linux Debian 9 with Apache.

Currently I have set up these ciphers:

SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:DES-CBC3-SHA:!aNULL:!MD5:!DSS:!eNULL:!ADH:!EXP:!LOW:!DES:!PSK:!SRP:!DSS:!RC4

I tried hard to find a naming for this suite here for example, unsuccessfully.

Does anyone know its naming?

The "Apache naming" is actually the syntax used by OpenSSL. According to https://testssl.sh/openssl-rfc.mappping.html the OpenSSL name for TLS_RSA_WITH_3DES_EDE_CBC_SHA
 is DES-CBC3-SHA.


What are the implications of publicizing a consumer secret for sharing between developers doing local website development? In relation to this GitHub issue on the Gittip project (which turned out to be a false alarm), what are the security implications, if any, of hardcoding into the git repo a test app's OAuth consumer key and secret for each provider that we use.

The intention is to make it as simple as possible for a new developer to spin up a working development environment, and asking them to create a bunch of OAuth apps seemed undesirable.

For what it's worth, the details are as follows:

assume local site development only (no remote data stores)
providers include Twitter, GitHub, OpenStreetMaps, Bitbucket, Venmo, among others
publicized secrets are only for testing apps

Could you make the configuration file local only and not check that in?

Or just share the configuration file / API keys to a limited audience?

Sharing a key makes it a single point of failure as well. If it's a limited test account you can remove if needed, you have much better control. You need to be aware of the terms of those accounts as well (Twitter, Github, OpenStreetMaps, etc...) to make sure you aren't violating their terms of service by hosting API ids as freely downloadable content.

Agree that it's not the best from a developer usability perspective, but your developers should use their own API keys to achieve account isolation and protect you and others. This does effect startup time, maybe there is a project out there to simplify this for developers? C'mon interwebs, get on it.


Two Phases of Secure Socket Tunneling Protocol (SSTP) According to http://en.wikipedia.org/wiki/Secure_Socket_Tunneling_Protocol there are two phases, SSL phase and PPP phase.

SSL phase establishes a session

and PPP also creates a link (which I understand to be a session)

I am unable to find the difference between the two phases. It seems these phases are one and the same. Please clarify

The first phase is to establish a secure session.  This is what the SSL session is for.  Once the SSL channel is established all data passed through it is encrypted.  The POP session is established through the SSL session.  Which means that all of its messages for establishing a PPP session are encrypted using the SSL encryption keys.

PPP allows for authenticating users.  So any user names, passwords, or other means of user  authentication is encrypted.   SSH does the same sort of process.  Establish a secure channel first, then allow for secure user authentication and data transfer.


Why use "App Secret" in mobile applications? I see some SaaS require to import "App Secret" into your application also with "Application Key". I understand the "Applicaton Key", but can not understand the "App Secret". Here is why:

I can decompile the application and get app secret easily.
If you are encrypting the traffic between you and server with it, and your OS doesn't allow me to decompile your application, I can still mess with your data by replicating the traffic request and send it million times.

Why use "App Secret" in mobile applications? Can't we say actually it is public because it's easily accessible from outside? Application key is also accessible, what is the difference, is it because of experience lack of that SaaS?

App secrets are related to the "Web Server Auth Flow" (notably OAuth2), which is how one server authenticates to the other that is is allowed to access the resources that server provides. You can think of it as an "authorization password," where the password allows the calling service access to the service being called.

Mobile clients must not be trusted, and should never use an app secret; this is an inherent security risk, as it can allow a malicious app access to the service. Once an app secret is out in the wild, the service needs to have it changed to prevent malicious apps from abusing the service on behalf of users.

Note that you can't use replay attacks with OAuth2 because it uses a random number to salt each transaction, although the decompilation issue is still very much a factor. In fact, there have been articles written about the extreme number of Android apps that are vulnerable because of app secrets being leaked.

Once you have an app secret, you can emulate the app that the secret key corresponds to, and you can't tell the difference between an authorized, published app, and a malicious clone. Many developers don't understand that the app secret is the equivalent of a password or a private encryption key, and should be treated as such.

Mobile clients and other untrusted apps (web browser-based apps) should use the "user client auth flow", in which only the app key is used.


Why has Convergence stalled out? Convergence is a well-thought out system to replace certificate authorities built by Marlin Moxiespike back in 2011.

Since it's debut, it seems to have largely stalled out, with no additional major notaries since the original pair and a total lack of adoption by the major browser vendors.

The most critical piece of the web's encryption infrastructure is fundamentally broken.  Not only is it trivial for script kiddies to perform MITM attacks, the lack of web encryption has enabled global dragnet surveillance.

Why has this stalled out and why aren't the major browser vendors competing on this point?

Convergence does not solve a security issue that needed fixing. In practice, evil people who run fake sites for phishing purposes will not bother crafting a fake certificate; rather, they make a non-SSL site, or try to convince the gullible victim that the browser security warning is meaningless. (The same point can be made, and has actually been made, about EV certificates.)

What Convergence tries to fix is a political issue: it is mostly about kicking the established, commercial CA out of the Web business; it is an attempt at replacing traditional business concentration with a somewhat anarchic decentralized system. Unsurprisingly, this is not a powerful enough reason to drive adoption of a new system. Moreover, commercial CA and browser vendors are actually in good terms, and are more inclined to team up against their respective competitors rather than go to war against each other.


How do I remove or anonymize file names and path that are stored in compiled .NET exe output? When an exception occurs in a .NET application, the exception output also includes the path and file name of the code file that resided on the developer's machine.   This shares some information that is useful in debugging, but also may present a security issue as shown in the following example:

In the above image the directory D:\talks comes from the developers machine and not the end user's.

Suppose I have a Visual Studio Solution file that has a PFX file with the password part of the name:

Example:  d:\my secret project\Obscure FOSS project\Signer-PW-Is-test123.pfx

Of course test123 isn't the real pfx password, but what if it was a more sensitive password that was used for other purposes (say domain admin).

Question:

Where is this string "Signer-PW-Is-test123.pfx" stored in the .NET DLL or exe?

Is it stored in the OBJ file?

How can I purge this data, or anonymize the information so that I don't leak  what's unnecessary but still make it possible for engineers to debug the application.

I'm a little confused as to how you have this set up.

What makes you think that file path is stored in either assemblies at all? Are you using that PFX to sign the assemblies? If so, there's a pointer in the assembly attributes.

There is no way to obscure the filename at that level because the compiler needs to know the full path. You could possibly run it through obfuscation software, but that would still likely result in the string being present.

Another option is to make sure you compile in RELEASE so the debug bits aren't added. This will remove the pdb files and remove most of the entries to code file paths.

The only other option really is to compile the thing from a non-sensitive path, e.g.: d:\builds\1, and to remove all sensitive information from the file paths. Simply put: don't store the password in the filename.


Can cookies with a complicated secret be manipulated? Im currently working on a personal full stack application using cookies with the express-session middleware. Theyre secured with some sort of secret. Im not really too sure how that works but I think it jumbles/hashes up the cookie (let me know if I'm incorrect). So if I store some data in my cookie like for instance the auto incrementing primary Id column in my database Is it possible for someone to "crack the cookie and change there information from say:
{ #user1id
  userId: 1
}

to
{ #user2id
  userId: 2
}

and gain user2's private information?
So in the case this is possible and I were (I'm not, but hypothetically) making a social media platform with a large userbase, should I use something like uuids so its basically impossible to spoof or not use cookies at all and opt for something "more secure"?
Thanks

It depends on the implementation. Insecure methods exist, such as only encrypting the data with AES-CBC, where the contents can often be modified even if they can't be decrypted.
The secure method is to use a cryptographic algorithm to verify integrity of the data. For example, HMAC can be used to verify the contents are unmodified. JWTs are a common example of doing this in practice. As long as the secret key is safe, the tokens cannot be modified.


What are the risks of uploading and downloading data in binary (non-encoded) format to servers and browsers? I admit up-front that this question may be the result of unfounded paranoia.  But I am concerned that uploading and downloading data in binary form opens the door to exploits that might not be possible if the data were encoded during transfer and decoded at the destination.

I will stipulate definitions because I see the term "binary" thrown around a lot and I am not sure if everyone means the same thing when using it.  When I say "binary" in the context of this question, I mean a stream of bytes that may have the high order bits set in at least some of those bytes.  I don't mean a stream of bytes merely representing binary data, such as base64 encoding.

I am imagining that in the lowest levels of some possible network protocol used for Internet data transfers, there might be various "handshakes" using bytes with high-order bits set.  If this were true, then a web server or browser that accepted arbitrary 8 bit streams of data could become vulnerable to some forms of attacks that employ some kind of "handshake doping" or the like.

I might agree that at the web server/web browser "level" of the data transmission hierarchy, perhaps this issue is irrelevant.  That is what I want to know:  Is a web "connection" (handshake and associated data transfers) immune from manipulation this way?

The scenario I am thinking of might result if a browser or server has been running for some time and its internal data page tables have become cluttered and possibly corrupted, maybe by some minor flaw in javascript or perl (how dare I insinuate that!).  At that point, it seems like browsers and servers could become particularly vulnerable.  (And I would agree that using a reliable operating system and reliable software will help a lot to prevent this and other horror shows.)

I'm not asking for advice on safeguards and recovery; I am only asking if there is a possibility of the kind of scenario I am suggesting.

On the network, bytes are sent and received. What these bytes represent is a matter of convention between client and server. However, if the client and server use some sort of open encoding (e.g. Base64) that everybody knows, then it is easy for any attacker in-between to apply and unapply that encoding at will. So this will have zero benefit for security.

If the encoding used a secret convention between client and server, then we enter the realm of cryptography, and then "it depends".

There is nothing inherently toxic in "binary data"; conversely, there is nothing tame in "characters". Bytes are bytes. If some code has trouble with arbitrary bytes, that it would not have with "characters", then this means that the code in question is interpreting raw bytes as characters, and that's a bug all right. You can call it "corrupted data page tables" if you like; it does not change things in any way: a bug is a bug. It does not occur through accumulation of time; it occurs through programming mistakes or hardware errors. There is no byte value which makes such issues more probable than any other.

What makes bugs more probable are unwarranted assumptions from careless programmers. E.g. a programmer who expects, in his code, some bytes representing characters, and not putting in any code to deal with null bytes or other "invalid" incoming data. That's the deal with attackers: they do not always follow encoding rules. There is no encoding thingy which will protect a careless programmer against carelessness. There are tools which will mitigate consequences, e.g. programming languages which check for array bounds and enforce strong typing; but these operate at another level.


Does client certificate authentication demand more server-side entropy? We have a secure web service running Apache that requires client certificates for access. This service has a problem with running out of entropy. We have several other sites that use TLS that get similar amounts of traffic but have never had any problem with a lack of entropy.

I am wondering if requiring a client certificate requires more entropy. Looking at the TLS specification I don't see where the client providing a certificate places more demand on the server-side entropy source. Maybe our problem has nothing to do with client certificates, but I would like to eliminate that as a problem source.

If you "run out of entropy", then you are using /dev/random, and you should not. You should use /dev/urandom. The whole concept of "running out of entropy" is based on a flawed metaphor in which randomness is viewed as a kind of gasoline. That's just wrong. Recent versions of the man page of /dev/random (on Linux) are less terrible than what they used to be, and now recommend the right thing, which is to use /dev/urandom.

(When I say "you" it might be "the software you use". Regardless, someone is doing a stupid thing, and that stupid thing probably involves /dev/random.)

In any case, certificate validation entails verifying digital signatures, and there is no need of any kind of randomness for that (at least with "normal" signature algorithms like RSA, DSA or ECDSA).

Edit: actually, while the basic certificate validation uses no randomness at all, the checks for revocation status entail contacting external servers to download CRL or OCSP responses, so that's network traffic which may stall and thus display symptoms similar to a blocked read on /dev/random. And the protocol to obtain an OCSP response may include a random nonce included by the requester (here, the server), so it is conceivable that a read on /dev/random still lurks in that code. That's a bit far fetched.


I started to learn about MITM attacks, and I can't figure out few things I just started to learn about MITM attacks, and I can't figure out few things.
I have few questions and appreciate all the answers.

If the attacker is already in my LAN why does he need to trp to arp spoof or dhcp spoof, can he just sniff all the traffic on the network, or is it true only if there's a hub involved? if it isn't is it only in order to deal with the encryption?
why does the arp chart is able to change so quickly without any confirmation is there some kind of protection we can do?
I'm not expecting a full technical explaination of this but how does the attacker even gets into the network and gets to be part of the subnetwork? is that mean that he needs to hack into the router and make himself part of the lan? and does it means that he is part of 2 lans? one his and one the victims one?

Sorry in advance if some of the questions are vogue or weird , just trying to understand.

Passive sniffing is not a MiTM attack. Depending on the network setup, sniffing may be able to view all communication, but it can't change any of it. A MiTM is when an attacker controls one of the nodes directly in the connection path between the client and the server. As shown in this diagram from Wikimedia, you think that you are talking to the server, either directly or through a series of trusted nodes, but you are really talking through an evil intermediary.

There are many ways to get a computer to use the incorrect route through the attacker's machine. Spoofing various network settings (eg: ARP spoofing or evil twin attack) is one common strategy. Another might be to infiltrate a network provider's machine.

How the attacker achieves the MiTM status is highly-situational. It's not like you can go to MiTM.com to attack any computer in the world. You need a foothold that you obtain by leveraging a vulnerability or other security weakness (eg: evil twin relies on insecure access points).

As to why ARP caches are subject to poisoning, it's a combination of the need to be dynamic and performant in a large network and weak security design. That said, ARP poisoning isn't trivial to execute. OS's come with defenses, but sometimes they can be bypassed.


Bluetooth Low Energy - Relationship between PINs and man-in-the-middle attacks In the Bluetooth core document, there are various Association Models, I'm trying to understand Numeric Comparison, where both devices are capable of showing a six-digit number (which I will call the PIN, although apparently they don't like that terminology).

The paragraph in section 5.2.4.1 of v4.2 says this:

  The numeric comparison serves two purposes. First, since many devices do not have unique names, it provides confirmation to the user that the correct devices are connected with each other. Second, the numeric comparison provides protection against MITM attacks

I definitely understand the user confirmation part, but how does the PIN help guard against MitM?

I think the answer lies in this paragraph:

  In the Numeric Comparison
  association model, the six digit number is an artifact of the security algorithm
  and not an input to it, as is the case in the Bluetooth security model

but I have no idea what that means.

This is for BT pre-4.0:

It meas that the conversation between the 2 devices when generating the initialization key does not contain the PIN in clear text, the PIN is used in a function like this (pseudo-code):

GenerateKey(PIN, sizeof(PIN), RAND, D_ADDR)

Where:

RAND: A 128-bit ~random number generated by the device (by software).

D_ADDR: Device address, it is a unique 48 bit sequence. (IEEE).

It returns:

A 128 bit initialization key via shifting and xors (Linear feedback shift registers, the output is combined by a state machine)

Both devices will share this initialization key, which they use as their temporary link key and will be discarded after the success of the interchange.

For more technical details, check this presentation from the course CSE446 (Software for Embedded Systems, University of Washington), it goes from higher to lower level explaining all this.


What is the difference between the different wiping methods used by DBAN? I was wondering what is the difference between the various wiping methodologies that DBAN offers

DBAN Website

Once you start the program, there are a few methods available for wiping the disk.

1.- DoD 5220.22-M : I know that with this there are 7 passes, but not if it writes random data, or zeros or uses some other approach.

2.- Short DoD 5220.22-M : I know that this there are 3 passes,but not if it writes random data, or zeros or uses some other approach.

3.- RCMP TSSIT OPS-II : No idea of how this one works

4.- Gutmann : I know that this one are 35 passes, white blank and random write.

5.- PRNG : No idea of how this one works

For modern hard drives, the main difference is how long it takes -- the quality of the wipe is effectively constant between them.  A three-letter agency may be able to recover data from a zero-wiped drive, but if your opposition is a three-letter agency, you really should be looking into physical destruction instead.

DoD 5220.22-M seven-pass: I haven't been able to find a description of this, but I suspect it's a variation of the three-pass wipe, only with three values and their inverses.
DoD 5220.22-M three-pass: Overwrite the data with a value, then with the inverse of that value, then with a random value, verifying the write after each step.  The first two wipes theoretically pull the magnetic field fully one direction, then fully the other, eliminating any residue of the original value.  The problem with this is that the on-disk encoding is not simple binary data; the encodings of a value and its inverse may not themselves be inverses.
RCMP TSSIT OPS-II: Overwrite the data with zeroes, ones, zeroes, ones, zeroes, ones, and random data, and verify the final write.  The same basic idea as DoD 5220.22-M, but with only a single verification step.
Gutmann 35-pass: This writes a series of patterns that would randomize the residual magnetic fields of all hard drive technologies in common use 25 years ago.  It is totally useless on a modern hard drive, first, because low-level storage techniques have changed wildly since then, and second, because modern drives store data in such small areas that there's essentially no remnant magnetic field after even a single write.
PRNG: This over-writes the contents of the disk with pseudo-random data.  It's theoretically better than a zero-wipe, and is just as fast.


Should I assign my various passwords to my keyboard's macro keys? I had an idea to assign my keyboard's macro keys to various passwords so I can just hit the key and it will paste in (the passwords are long and random so I won't remember them). This is on a home desktop PC. Are there any reasons this is a bad idea security wise?

This is a bad idea.

As user mentioned in a comment, anyone with physical access can just press the assigned macro key and the password will be revealed.

You also have a high chance of accidentally pressing the macro key, thus typing in your password in places where you didn't mean to.

The macro data also needs to be stored somewhere, and is likely stored in plain text. As such, storing your password in a macro is akin to storing it in a plain text file.

Instead, use a password manager. An offline password manager allows you to store your passwords in an encrypted form, protected by a master password. Many offline password managers also include functionality to write your password for you, just like a macro, except that this is much safer.


Is it dangerous to publicly share ciphertext? Alice wants to share a message with Bob, but Alice and Bob can never be in the same place at the same time. We can assume they both know each others public keys (or agreed on a shared key, if that makes a difference).

Is it safe for Alice to broadcast the ciphertext over the TV/radio/public internet/etc, or should she send Bob the ciphertext over video chat/phone/email?

I understand that modern algorithms are resistant to ciphertext-only attacks, but is the layer of obscuring the email from the public practically beneficial?

That is exactly what encryption is designed to safely enable.  If Bob and Alice could safely share the message without allowing attackers and eavesdroppers access to it, they would not, in fact, need encryption at all.   So, yes, it is safe to allow any and everyone access to the ciphertext.  You do want to authenticate it so that it cannot be tampered with in transit, but done correctly, we don't believe there is any non-negligible risk of compromising the confidentiality of the message.


How to fully mask my computer without using tor? I want to mask myself and therefore I configured a proxy server. I use debian and squid 2.7.

It actually works fine, however, I visited the site whatismyip.com and I can still see that I'm accessing via a proxy. However, I would like to mask myself completely as if the request came from the other machine. I know that I could also use Tor, however, in my case this is not possible.

Any suggestions how I can mask myself such that I cannot be tracked back to my orginal machine?

Tor is probably your best bet, but if that isn't an option consider finding a reputable VPN you think you can trust.

Ultimately it depends who your adversary is. If you're living in a despotic regime with access to the VPN or the ability to strongarm them you're probably not going to do very well.

But if you pay a reputable company outside your country that hopefully wouldn't sell you out then you should be okay.

Tor is better though. You don't have to trust a company to keep you safe(r). There are still problems with Tor too (correlation attacks by people who own entry and exit nodes or monitor large portions of the internet.

There are way to many risks to say you wont get tracked back to your machine, but these methods will make it harder.


Does a continuously freshly installed proxy server increase security? If a small number of physical servers are used to run an OS and reverse proxy purely in RAM and have no storage, and they are rebooted/re-initiated in relay every X minutes - so that changes to the system while in RAM are wiped - does this provide a real security benefit over more standard always on servers?

The specific proposed approach of rebooting full server instances every n minutes would in practice be far too operationally expensive and fragile to entertain in a production environment, but the ideas of:

automatically refreshing one's plant on a regular basis
disallowing durable writes on edge services (except perhaps for logging)

are good ones for security and other reasons and are common threads in DevOps practices going back decades.

Most recently, container technologies now embody these and related practices:

containers are quick to "boot" and can be efficiently used for applications whose lifespans are measured in high tens of seconds to low numbers of minutes
containers are immutable after creation, so file system writes are not durably retained
containers provide additional sandbox capabilities for constraining application access to sensitive resources
platform dependencies used in containers can be inspected and new container templates cut when needed, an improvement over the fragile practice of deploying patches

Take a look at Docker, "cattle vs pets" and "immutable infrastructure" to learn more.


What is the Plundervolt attack? CVE-2019-11157 exposes a vulnerability in the undervolting API from Intel processors, that became known as the Plundervolt attack.

What is the Plundervolt attack?
Should domestic users be afraid of undervolting their CPUs because of it? Or does it require a sophisticated hacker to exploit it, which would make it only worrisome for governmental, servers, and enterprise-level computers?

What is Plundervolt?
Plundervolt is a vulnerability in Intel CPUs. These CPUs allow users to use privileged software interfaces to undervolt their CPU. Undervolting is the process of supplying the CPU with less power than specified, usually in order to conserve power. In this case, undervolting is used to induce faults into calculations.
By doing so, attackers can for example cause the SGX to write secret data to user memory.
Should the average home user worry about this? Is undervolting insecure?
No, for multiple reasons.
First of all, the flaw doesn't come from undervolting the CPU, but rather from the fact that Intel offers a software interface to undervolt. As a result, not undervolting doesn't stop an attacker from exploiting the vulnerability.
Secondly, the attacker requires administrative privileges on the machine. While this matters in the context of cloud computing applications, domestic users on their own machine usually don't need to worry - if an attacker has administrative privileges, they're f___ed either way.
Finally, Intel has released a security advisory and an accompanying microcode update to mitigate this issue.
Who should worry about this?
Anyone who relies on SGX to provide confidentiality and integrity, in scenarios in which potentially malicious actors have gained root privileges. In this case, it is possible that this attack has been used to extract secrets from SGX.


what is the best algorithm for hashing stored users info on client-side on a web app I have this scenario in a web app which I'm working on its client-side code(I'm building it with ReactJS):

I obtain user's info
hash 'em
send it to the server for being authenticated
and when I get the result back
I have to store the password and username locally in the LocalStorage for the further request to other APIs-you see it would be really inconvenient to ask for user's credentials each time while they had logged in before so I have to store 'em- (it is an obligation made by the back-end programmers to ask for the password and username for each request).

So, I'm asking if anyone knows what would be the best solution for this situation? Should I hash 'em or do something completely different? If hashing is the answer, what would be the best hashing algorithm for this matter?

Firstly, My recommendation is to never stored some sensitive information at a client side.(i.e Password).
Best Solution for your situation is to use the Auth0. They provide the Authentication-as-service platform.
Basically they use the JWT token based mechanism. JWT token provide encryption mechanism to stored and transmit your data. In which you can set your expiration time as well.
Some of the links are given below.
I hope this information may help you.

https://davidwalsh.name/react-authentication

https://jwt.io/introduction/


Someone used my router to set up their own network This may be a stupid question.     My router was unsecured for a while.   We think the neighbors set up their own network using our router, creating a new network name, new wifi and router password.

We have since secured (WPA2) our network, changed the network name, changed the password for the router and the wifi.

Here's the stupid question......can the neighbors still connect to the internet using their network that they've set up on our router?

Okay answer: If you changed the router password and the wifi password they shouldn't be able to get in.

Better answer: I'd recommend a configuration reset on the router by using a paperclip on the tiny hole in the back (depending on your model) check for the latest firmware and set your own passwords complex passwords.

Best of luck, let me know if you have any questions!


What is inside a Kerberos TGT ticket? I would like to know what makes up a TGT ticket?
The reason is that we've noticed the more Windows AD groups the account is in, the larger the size of the ticket. We've also noticed that when we clear Internet Explorer cookies, the ticket size drops (ever so slightly).

Brief example: If the account is in 543 AD groups, then the ticket size is 12,960. We have found the approximate ratio is 21.7.

So, 543 x 21.7 ~ 13K as ticket size.

Due to these behaviors, I started wondering what is really inside the ticket?
My goal: To help identify the biggest offender that's causing the TGT ticket to be larger than the max limit ticket size set in our Apache server.

Any help would be appreciated.

Thanks

Kerberos is essentially just for authentication, not authorization; however the ticket data structure has a field for authorization info, in case an implementer wants to encode such information in a credential. Unix implementations of Kerberos have mostly just left this field unused, but Microsoft chose to use it, and embeds a “privilege attribute certificate” (PAC) in tickets it issues containing security information about the AD account to which the client Kerberos principal corresponds: group memberships etc. This goes not just in the TGT, but in any ticket issued by AD. The advantage of this is that servers which receive these tickets immediately know these user attributes in a trustworthy fashion, and do not have to then query AD separately to discover them. A down side is that if things like group memberships change, a user needs to get a new ticket for that to be reflected (and are usually told to “log out and log in again” to accomplish that). And of course, if you remove someone from a group, that is not fully effective until all the user's tickets have expired.

  My goal: To help identify the biggest offender that's causing the TGT ticket to be larger than the max limit ticket size set in our Apache server.

Apache doesn't have a “max ticket size.” Kerberos authentication happens in HTTP headers exchanged by the client and server, and the service ticket is encoded in them and so grows as the count of a user’s group memberships increase. Apache has a default size limit on headers which is low compared to possible AD ticket sizes (8K). You can just increase it with the Apache LimitRequestFieldSize directive.


Protecting web site with nginx 301 redirect and HTTP firewall I am setting up a hobby web site and trying to make it as secure as possible. The backend is nginx + uwsgi. I have set up the HTTPS connection. For non-SSL requests, I have the following rules in nginx.conf:

server {
    listen 80;
    server_name xxx.net;
    return 301 https://xxx.net$request_uri;
}

server {
    listen 80;
    server_name www.xxx.net;
    return 301 https://xxx.net$request_uri;
}

So all http:// requests are 301-redirected to https://. The site is also configured to use HSTS, so browsers will do 306-redirect after the first visit.

In parallel, following some other security-oriented reading, I also set up the UFW firewall to deny access to port 80 (HTTP default). I wonder if that extra step actually adds anything security-wise and doesn't instead introduce confusion?

Will firewall block any HTTP-traffic before nginx has a chance to take over and redirect, or does the redirect happen first? If the redirect does happen, does this rule add anything? Is it a good practice (as an extra security layer) or completely redundant?

You can either redirect http (80) to https (443) or block port 80.

You can't do both

redirect http (80) to https (443):

Helps users by redirecting them
May leak the first request

block port 80:

Doesn't leak the first request
But the user will not be redirected

Blocking port 80 have a (very little) security advantage, and a huge negative impact in term of usability.

If you really wants to improve security, you should use HSTS and HSTS preload.

See also https://community.letsencrypt.org/t/support-for-https-only-with-http-01-challenge/15134


What mail applications use crypto? I just read that everyone in the world can ready my mails (if intercepted in traffic by eavesdropping?). Also, it reads that current versions (book's from 2004 so I assume that new versions adopt encryption policies) of Outlook and Eudora have built-in crypto. Is it sufficient or should I use PGP on every mail I send? How about my favorite gmail? Does it include end-to-end encryption? If so, is it sufficient?

Sorry for being a newbie.

Gmail does not include native encryption features that can be used via webmail.  Broadly speaking, webmail services that provide encryption are doomed to failure, and this for a very simple reason: the only encryption that you can trust is end-to-end i.e. from your machine to your correspondent's machine.

You can achieve this by installing a plugin for email encryption on your mailclient.  The most used standard is probably OpenPGP, which is implemented on the open source and free software GnuPG (cross-platform) or GPG4Win (for Windows).  However, your correspondent must do the same.  Note that in this way you can encrypt/decrypt messages no matter the email service you use, provided that it gives you access to email via POP or IMAP and not only webmail.


Is there a way to save a file from the network printer queue? Recently I printed something using secure print with an ID card. When I checked my printer queue, I saw the total queue of all documents of colleagues who are using the same printer.

First of all, I would like to know if this is standard or common use.
I mean I do see the size of the document and the time it has been sent to the printer.

I could click on these documents and see some minor details, like login name...
Since I am interested, I asked my colleague to send a file to the printer and I tried to modify something. This was not possible which is good.

But is there a way to extract that printer queue? Or asked the other way around, am I sure that my colleagues don't see my printed files?

It's a very new system for us and the project is still going, so in case there might be a security issue I would like to report it.

The printer administrators can see the content of your files in the queue because it is their job and they have been authorised to have that access.

A secured print queue is supposed to block other people's access to other people's files. If it works or not depends on how it is implemented.

It is normal for the queue to list the username, file size and file name in the queue so that if a file is causing a problem, then the users can track down the file owner to fix things. The common scenario is that someone sends a huge file that fills the queue and blocks everyone else. I can then look at the queue, see that Ray has sent a massive file, and I can contact Ray to remove the specific file from the queue.

So, as you have described it, there is no security issue, but you are correct that the owner, file name, and file size discloses a lot of information to potentially unauthorised people. This is a training issue in the use of printers.


What security measures to have before openly allowing security researchers to hack your site As some kind of a follow-up from my previous question - which was asked from the security researcher/penetration tester point of view:

(Thanks to Rory McCune for pointing this out) There seem to be a number of high profile sites like facebook and google who appear to openly allow security researchers to try to hack their site, as long as those disclose the findings responsibly. On the face of it, this seems like a generally good idea. Why hire people to do your penetration testing if some are willing to do it for free? (and the bad guys will do it whether you ask it or not).

However, what measures should a site already have in place before embarking on such seemingly risky endeavor? (or perhaps I am mistaken and it's not more risky than if you don't actively make such invitation). I am not particularly concerned with the legal aspects or how to deal with those reports, but rather the technical side of things. Could the same logic apply to smaller applications or websites as it does to the big guys? i.e. could publishing such a statement put your site at more risk than leaving it out?

You should keep in mind sites like Google, Yahoo, Amazon have a couple (of thousand) of servers. They can afford to "open the doors" to everybody because, as M15K pointed, their resources are not limited.

There are a couple of reasons they might do be "open":
 1. You can gather performance statistics.
 2. You can test the system for stability (if server X goes down, server Y has to take over, etc)
 3. Probably many more reasons I can't think of.

In small/medium/large companies you usually end up using Linux/Unix server, Apache, Nginx, LigHTTP, Jetty, MySQL, PostgreSQL, Oracle and etc. Sites like Google(giant) create their own platform and their own software solutions - web servers, databases, proxy forwarders and etc. So leaving "the door open" for the public actually helps them to constantly improve their security and platforms because every "hacker" in the world will try bringing them down. A few of them will succeed and usually they end up working for the company or receive a satisfying number in their bank accounts :)

In my opinion it's not safe for you to "open" everything if the company you're working for is not creating most of the software solutions from scratch (web servers, databases and whatever else your company needs). Even then it's a bit risky especially if you're managing sensitive data.

i.e. could publishing such a statement put your site at more risk than leaving it out?
It doesn't matter if you say "We'll not sue you if you tell us where the breach is".
If somebody wants to hack you - he'll try doing it whether the statement is there or not. But if it's there it may sound more like you're inviting them in. So probably you'll get more hackers trying to hack your server.

However, what measures should a site already have in place before embarking on such seemingly risky endeavor?
You will need to figure out a logging mechanism, or monitor the actions that are being made on the site and server. Also a full backup of the site/server is a must.

Generally I wouldn't recommend leaving the server "open" especially if it handles sensitive information like credit cards, payments, medical information for patients and etc. It's better for you to hire a team of hackers with a proper contract. Otherwise you're risking all that information going in public.

I can't go in more details as this topic is HUGE and there are many things you need to consider before going "public":

Do you have the money to do that?
Do you have the resources? (servers, security teams and etc)
How far can you limit the damages a hacker can make to your system? I.E. If a hacker  hacks into your server what access will he have ? Will he be able to connect to your database and retrieve/store/update data? Is your data encrypted ? Will he be able to decrypt it? (and so on)
Can your security team find how a hacker exploited your system?
Does your security team have the skills to fix problems that may occur ?
Probably many more questions that you need to ask and answer before you decide.


Does Java anti-decompiler software really work as claimed? BIS Guard's Java Antidecompiler is an application that you can purchase that claims:

  Java Antidecompiler protects java byte-code against decompilers, any binary viewers/editors, prevents reverse engineering, and plagiarism of your software. It combines an obfuscation technique, java cryptography, and the original BIS Guard & Co. technology. The high protection level allows you to hard-code passwords, dates and other private data secure enough to protect your java applications from stealing. The new sonar algorithm prevents class loading interception, class dumping and all other existing to the moment hacker attacks. Code is completely encrypted and hidden both from hackers and from customers.

They vaguely explain how it works here,
though, I tend to not be able to believe all that. Is it really possible to do all that? Also, is it possible to really "prevent class loading interception, class dumping and all other existing to the moment hacker attacks"
The last thing is, this software is on a shoddy website and is barely found anywhere else on the web; is anyone able to vouch for its validity?

No, these do not work in the way claimed. They do not and cannot prevent reverse engineering and decompiling. The most they can possibly do is obfuscate Java to make it more difficult to understand, but it will still always be possible to analyze manually. Any software that claims it prevents "all other existing hacker attacks" is snake oil, pure and simple. If code is running on someone's computer, they can see anything the code does, did, could do, and will do, and can influence it for testing at will.
See Link and Link, which mention techniques and tools used for obfuscating Java, and why it is often futile (or actively harmful) to do so for security or intellectual property reasons. If you absolutely want to obfuscate your Java in spite of the answers here, you should at least use a less sketchy product. The ProGuard software mentioned in the linked answer is free and open source.


Can a revoked certificate be re-instated? If a certificate is revoked, can it be re-instated, or is the only option to generate a new one?

The only option to unrevoke is when certificate is revoked with certificateHold reason (§5.3.1 in RFC5280). In all other cases the certificate (and the key) must be re-created.


Why are GPUs so good at cracking passwords? What is it about GPUs that lets them crack passwords so quickly?

It seems like the driving force behind adopting good key-derivation functions for passwords (bcrpyt, PBKDF2, scrypt) instead of yesterday's cryptographic hash (MD*, SHA*) is that the later are vulnerable to programs that run on GPUs and guess huge numbers of passwords extremely quickly. Why should GPUs happen to be so much better at evaluating those hash functions than CPUs?

To complete @Terry's answer: a GPU has a lot of cores (hundreds). Each core is basically able to compute one 32-bit arithmetic operation per clock cycle -- as a pipeline. Indeed, GPU work well with extreme parallelism: when there are many identical work units to perform, actually many more than actual cores ("identical" meaning "same instructions", but not "same data").

Some details, for a somewhat old NVidia card (a GTX 9800+, from early 2009): there are 128 cores, split into 16 "multicore units". Each multicore can initiate 8 operations per cycle (hence the idea of 128 cores: that's 16 times 8). The multicore handles work units ("threads") by groups of 32, so that when a multicore has an instruction to run, it actually issues that instruction to its 8 cores over 4 clock cycles. This is operation initiation: each individual operation takes up to 22 clock cycles to run. You can imagine the instruction and its operands walking into the circuit as an advancing front line, like a wave in a pool: a given wave will take some time to reach the other end of the pool, but you can send several waves sequentially.

So you can maintain the rhythm of "128 32-bit operations per cycle" only as long as you have at least 22 times as many "threads" to run (i.e. a minimum of 22·128 = 2816), such that threads can be grouped by packs of 32 "identical" threads which execute the same instructions at the same time, like hip-hop dancers. In practice, there are some internal thresholds and constraints which require more threads to achieve the optimal bandwidth, up to about 4096.

I could achieve close to 99% of the optimal bandwidth with a SHA-1 implementation. SHA-1 uses a bit more than 1100 32-bit operations (that would be around 900 on a CPU, but a GTX 9800+ has no rotation opcode, so rotations must be split into two shifts and a logical or), and the GPU ran at 1450 MHz, for a grand total of about 160 million SHA-1 computations per second. This can be achieved only as long as you have millions of SHA-1 instances to compute in parallel, as is the case for password cracking (at any time, you need 4096 parallel SHA-1 to feed the GPU cores, but you also have to deal with I/O costs for input of potential passwords, and these costs will dominate if you do not have a lot of SHA-1 instances to process).

The host PC, on its CPU (a quad-core 2.4 GHz Intel Core2), could achieve about 48 million SHA-1 per second, and that was with thoroughly optimized SSE2 code. A single SHA-1 will use about 500 clock cycles on such a CPU (the CPU can compute several instructions in a single cycle, provided they don't compete for resources and don't depend on each other), but, for password cracking, it is worthwhile to use SSE2 with its 128-bit registers, and able to compute 4 instructions in parallel. With SSE2 constraints, it takes about 800 clock cycles to run four parallel SHA-1, so that's 200 clock cycles per SHA-1 instance. There are four cores in that CPU and the whole thing runs at 2400 MHz, hence 48 million per second.

More recent hardware will be faster, but GPU more so. A GTX 680 sports a whooping 1536 cores, and there are two such GPU in a GTX 690. We are talking billions of SHA-1 instances per second here.

(For comparison, I also did an implementation of SHA-1 on the Cell processor, i.e. the CPU in a PS3 console, with its 8 "SPU" coprocessors. One SPU was not available. With the 7 others, I reached about 100 million SHA-1 per second, i.e. better than a contemporary big PC CPU, but not as good as a good GPU of the same era.)

Summary: GPU achieve great performance by using heavy parallelism, with hundreds (if not thousands) of cores. This is made possible by pipelining (each individual operation takes many cycles to run, but successive operations can be launched like trucks on a highway) and sharing instruction decoding (since many cores will run the same instructions at the same time).


Does the BeEF framework still work for lastest versions of browsers? I have searched forums and found posts dating back to '13 and '12 asking how the BeEF framework exists, how it is able to hook the browser to execute malicious code. Though, I have not, however, found any posts about that lately and wondered if, as a penetration testing tool, BeEF is still as versatile as it was years before? I would of imagined browser manufacturers, Google, Mozilla, would have released fixes for bugs like these. If this still works, how can javascript be so flawed?

BeEF as the name suggests is the The Browser Exploitation Framework. That being said it only makes sense that it comes with lots of exploits for lots browsers. While it does still work in the sense that some of the exploits are not patched or that lots of the exploits are not patched in older browsers it is not as powerful as it once was. It used to be very powerful but you can still execute some attacks. Another reason it is less powerful is that it was developed primarily in a time where SSL/TLS was much less common and it was much more easy to intercept and replace traffic. So in short, it does still work however it is not as powerful as it once was but is still a nice framework.


Is all metadata necessary for decryption included in a symmetrically encrypted GNU Privacy Guard message? Suppose I symmetrically encrypt a file with a passphrase using GNU Privacy Guard and send it to a friend. I use the latest version and all the defaults, so AES-128 encryption is used, with the salt and s2k_count used for the password derivation function automatically generated.

I then tell my friend the passphrase and ask them to open it.

Are the salt, S2K type, s2k_count, and so on included in the file somehow, so that my friend can decrypt the file knowing only the password?

I suspect the answer is affirmative but I have not been able to find it in the documentation.

Yes, it is.

You can verify this easily by yourself by encrypting a file with gpg -c filename and then decrypting that file with the password you have specified. No further parameters are required.


How to check if your computer has a backdoor installed on it? Just some time ago I had this unusual popup from Malwarebytes Anti-Malware (MBAM):

I did a quick Google of the IP address and found this thread where the OP is complaining of MBAM blocking svchost.exe from this same IP.
I am wondering why is vmware-hostd.exe` connecting to that IP?

Earlier today I had this:

after which I did a full scan (no malicious items detected) and uninstalled uTorrent.

Am I being hacked?

Considering you have been downloading torrents there is a chance that you downloaded some malicious code (which was spotted by your MBAM) through the torrent network.

vmware-hostd.exe is a process used to share virtual machines over the network. It's quite possible that the a scanner was running on the listed remote IP (the IP address is one from China) and that it picked up the VMWare service and tried to log in several times or do something malicious with it (which MBAM picked up and blocked).

If you are directly connected with your computer to the internet I would suggest running your services on non-standard ports, this will reduce the internet background noise. This means that I doubt you are specifically being targeted but more a victim of scanners which scan the whole internet in the hopes of finding an exploitable machine.

EDIT

After a chat on the DMZ it was confirmed that the host is running a machine with a public IP address.


Is ExpressVPN using hidden trackers or spyware? I have ExpressVPN installed and keep getting strange warnings from Malwarebytes anti-malware.

First odd fact is that XVPND.exe is always running, even after a reboot. I have set ExpressVPN to not auto start at boot. There is no systray icon whatsoever. So first of all, does anyone have any clue why that file is running and listening on port 2015 (TCP)?

Second I keep getting warnings from Malwarebytes anti-malware that XVPND.exe connects to malicious IP-adresses (e.g. 199.19.94.101). When looking up that IP it seems to belong to a Canadian e-commerce service: Yesup Ecommerce Solutions Inc.

I would like to monitor the .exe to see what other connections it makes, any suggestions on how to (on Windows)?

I work for ExpressVPN. No, this is not malware. Here’s what’s happening:

The ExpressVPN app for Windows is composed of two parts: the UI and
the “engine”. The UI runs as a regular Windows app. The engine
(xvpnd.exe) runs as a Windows service and is responsible for
controlling the VPN. One benefit of this design is that the VPN is
not affected if the app crashes, and that the VPN killswitch can
start as early as possible on boot.
The app and engine communicate with each other using http. That’s why you see the engine listening on port 2015. Important: the engine binds to the local network only. No outside traffic can reach that port.
When the user connects to the VPN, the engine is responsible for testing which of our VPN endpoints is likely to give the most reliable and fastest VPN connection. It does that by sending UDP packets to various VPN server IP addresses. The IP you mentioned (199.19.94.101) belongs to our “Canada - Toronto” VPN server location.
It’s possible you encountered a bug here. The engine is only supposed to test VPN servers when you’re about to connect to a location, and it seems what you’ve reproduced is a case where the engine was testing VPN servers regardless. Our team is investigating and will fix once we determine the root cause. Thanks for raising the issue.
We ourselves haven't been able to reproduce the warning yet in Malwarebytes, however we will contact them for further information. In the meantime you can add an exclusion for ExpressVPN by following these steps: https://support.malwarebytes.org/customer/portal/articles/1835329-how-do-i-stop-malwarebytes-anti-malware-from-blocking-scanning-a-file-or-program-that-i-trust-?b_id=6438


Standard for Generating Multiple WEP Keys From a Passphrase I've been reading a lot about WEP recently and why it was bad. To make sure I understand it, I've been writing scripts to show how it works and highlight its vulnerabilities. But I want to have a full understanding from start to finish, and I can't find what I need for the very beginning.

Since WEP can operate on four keys, something needs to be able to generate four keys. My router can do this based off a passphrase. If I put 'badpw' as the passphrase, I get the keys:

1: 02CB778981
2: C27236DFB1
3: C90C104FA2
4: A804571CC0

If I enter the same passphrase on http://www.wepkey.com/, I get the same four keys. So its clear that the same algorithm is used in both cases, but I can't for the life of me find it.

So, what would the psudocode be to derive those four WEP keys from a passphrase?

Shamelessly stolen from the client-side JavaScript code of http://www.wepkey.com:

function wepkey64(val)
{
    var pseed  = new Array(4);
        pseed[0] = 0; pseed[1] = 0; pseed[2] = 0; pseed[3] = 0;
    var randNumber;
    var k64 = new Array(4);
        k64[0] = ""; k64[1] = ""; k64[2] = ""; k64[3] = "";
    var i, j, tmp;
    for (i = 0; i < val.length; i++)
    {
        pseed[i%4] ^= val.charCodeAt(i);
    };
    randNumber = pseed[0] | (pseed[1] << 8) | (pseed[2] << 16) | (pseed[3] << 24);
    for (i = 0; i < 4; i++)
    {
        for (j = 0; j < 5; j++)
        {
            randNumber = (randNumber * 0x343fd + 0x269ec3) & 0xffffffff;
            tmp = (randNumber >> 16) & 0xff;
            k64[i] += bin2hex(tmp);
        };
    };
    return k64;
};

// converts one byte to a 2 chars hex string
function bin2hex(val)
{
    var hex = "0123456789ABCDEF";
    var result = "";
    var index;
    index = (val >> 4) & 0x0f;
    result = result + hex.substring(index, index+1);
    index = val & 0x0f;
    result = result + hex.substring(index, index+1);
    return result;
}

Call wepkey64("your key") to calculate the four 64-bit keys. They will be returned as an array.


Storage of API authentication token in single-page-applications I'm building a JSON API. For authentication I plan to use a random-token based approach, with the random token having 256 bits of entropy and generated using a CSRNG. A hash of the token will be stored in server-side in the database. For most clients, I will send the authentication token to them in an Authorization header. All communction will be over HTTPS.

The general pattern that I plan to implement is described in the first part of this SO answer.

My question is about clients of the API which happen to be single-page-applications running in a web browser. My understanding is that it is not safe for them to store the authentication token in local storage or in memory due to the risk of XSS attacks and compromised JavaScript dependencies. It's also not safe to have them store the authentication token in a HttpOnly cookie due to the risk of CRSF.

The solution seems to be to send the authentication token to the client in a HttpOnly cookie, AND also implement a Synchronizer Token Pattern where we generate an additional token that is sent to the client in a header when they first authenticate. The client can store this additional token in local storage, and pass it back to the API in a header with subsequent requests.

Reasonable enough. But what I would like to understand is whether there is any risk in not generating a new additional token to implement the Synchronizer Token Pattern, and instead just splitting the original 256-bit authentication token so that the client receives half of it in a HttpOnly cookie, and half of it in an header that they can keep in local storage? The API server then reconstructs the full authentication token when receiving the request.

Granted, if one of the halves was exposed, there would only be 128-bits of entropy remaining for an attacker to guess (but I think that is probably still sufficiently difficult).

Otherwise, does this achieve essentially the same thing from a security point of view? Are there any subtleties that I'm missing here?

Here's the simplest example possible to show how to store values securely in JS code:

var api = (function(){

    let secret = prompt("enter a secret phrase"); // Only the api object can reach this

    return { // a method to compare guesses to the secret
     auth: phrase=> phrase == secret
    };

}()); // end privacy wrapper

// test it in console by entering bingo at the prompt:
[api.auth("one"), api.auth("bingo"), api.auth("cheese")];
// evaluates as [false, true, false]

In a real application, the secret is fetch()ed by ajax, a cookie, or whatever else you use. The crux is just that the only access to the secret is via the methods defined within the wrapping function that defines the "private" variable. This pattern is called a "privileged method" in JS, being made available to code outside only through the terms and conditions that your "api" object stipulates.


How many security-related websites/sofware/system/human brain will break when we get more than 10000 CVEs a year? The last time such a question was asked, there weren't even an official solution. Now we are supposedly on 5 digit CVE numbers for a whole year now, I've never seen then in the wild (apart from on MITRE website).

Will the security industry crumble and fall when the number go over?

The industry will not fall apart, because such an outcome would mean that the industry at large minds CVE numbers and acknowledges their existence; the day this will become true will be a glorious day indeed.


Attack WPA password with hashcat - Settings and resources for "german" passwords? I'd like to prove to a friend of mine that his wifi is insecure and learn something about password cracking on the way. The guy I am talking about does not believe in strong passwords but in SSID hiding and mac address filtering. As you know this is bad.

What I can already do is logging in with a known password after discovering the SSID and spoofing a valid MAC address. But to really show him a good password is needed I'd like to crack an unknown one.

So here is my actual question:
I'd like to use hashcat (for the first time) to do the heavy liftig. Are there any settings or rulesets that will optimize cracking a password created by a German? I know of course that I should use German (pass-)wordlists and dictionaries. But apart from that?

I googled and checked the hashcat forum. The results I found were about German Umlauts. I think this won't be a problem as a PSK is saved by the router which will - most likely UTF-8. Is that correct? Are there other things I need to consider like special rulesets or something?

Thanks for your help! Any hint is appreciated.
Dirk

(This thread is cross-posted on the hashcat forums here. My answer there was too simplistic, so I'll try to do a better job here.)

The basics

For wordlists and rules, it sounds like you've already got the basics down. As long as the wordlists are in UTF-8, and the input method used to set the password is also UTF-8, then they should work well. I would definitely pursue wordlists and rules first, because raw bruteforce will take more time than the basic attacks, and WPA/WPA2 is such a "slow" (hard to crack) hash.

The basics of password cracking are already well covered elswhere. Here are some useful howtos (but note that if your target password contains at least one German character, only the wordlist and rule-based techniques will apply to your situation):

adeptus-mechanicus' Cracking Passwords 101
How I Cracked Over 122 Million SHA1 and MD5 Hashed Passwords by m3g9tr0n
Introduction to GPU Password Cracking: Owning the LinkedIn Password Dump
Advanced password guessing - Hashcat techniques for the last 20% (PDF, by hashcat's primary developer, atom)

These overviews should help to fill in any gaps in your basic techniques.

Bruteforce of UTF-8 (mixed single-byte and multibyte), part 1 - simple proof of concept

If you do want to pursue bruteforce, you will need to do a little more work, because of how hashcat works under the hood. For cracking purposes, hashcat treats everything as a series of bytes. The German-specific UTF-8 characters are multibyte - represented in UTF-8 with more than one byte.

To bruteforce multibyte, you can specify character sets using the --hex-charset parameter, and use the technique described in this related post from the hashcat forums, which uses masks to simulate bruteforce for multibyte characters.

However, the technique in that post assumes that the charsets are entirely multibyte. German is different, in that only some of the characters are multibyte. Any German word that uses German-specific characters is actually a mix of one-byte-wide and two-byte-wide characters, and hashcat does not distinguish between the two.

So that technique has to be adapted somewhat. I'll briefly cover how here. I use MD5 for simplicity; WPA/WPA2 should work exactly the same (just much slower).

First, we must determine the hex values that will be used in the password mask. An easy way to do this is to create a file that lists the UTF-8 form of all non-ASCII characters that are likely to appear in your passwords, and then show their hex equivalents:

$ for item in `cat german.list`; do echo -e "$item: "; echo -n "$item" | xxd -p; done
Ä: c384
ä: c3a4
É: c389
é: c3a9
Ö: c396
ö: c3b6
Ü: c39c
ü: c3bc
ß: c39f

I'm not familiar with German, but these characters clearly have 'c3' as their first byte. (This is because they are all in the same Unicode block - specifically, the Latin-1 Supplement block). So since all expected multibyte characters will have this byte as a "prefix", we will start with that, and then append all of the "second bytes" using hashcat's custom mask parameters.

Here's a simple walkthrough.

First, we capture our plaintext (using '-n' to ensure that no line breaks are at the end of the string):

$ echo -n 'schön5' >german.plain

Next, we show that the string actually contains the expected two-byte sequence 'c3b6' where we expect it:

$ cat german.plain | xxd -p
736368c3b66e35

Next, we get the MD5 hash of that plain:

$ cat german.plain | md5sum | awk '{print $1}' | tee german.hash
bbf9ee923fe21c044838865c7acf530d

Finally, we run hashcat:

$ ./hashcat -m 0 -a 3 --hex-charset -1 c3 -2 8489969c9fa4a9b6bc german.hash ?a?a?a?1?2?a?a

... with flags explained as follows:

-m 0 (hash mode 0 - MD5)
-a 3 (attack mode 3 - bruteforce)
--hex-charset, to allow specifying hex charsets
-1, the first custom character set (the 'c3' prefix)
-2, the second custom character set (all of the second bytes from our German characters, "8489969c9fa4a9b6bc")
german.hash (our target hash)
a?a?a?1?2?a?a (a simple mask containing all printable 7-bit ASCII (?a) in most positions, and '?1?2' in the "fourth" position)

The command produces this output, showing that we have successfully cracked our target hash:

hashcat (v3.40-73-g99fbaa8) starting...

[informational hashcat output snipped]

INFO: approaching final keyspace, workload adjusted

bbf9ee923fe21c044838865c7acf530d:schön5

Session..........: hashtest
Status...........: Cracked
Hash.Type........: MD5
Hash.Target......: bbf9ee923fe21c044838865c7acf530d
Time.Started.....: Sun Mar 26 08:46:08 2017 (0 secs)
Time.Estimated...: Sun Mar 26 08:46:08 2017 (0 secs)
Guess.Mask.......: ?a?a?a?1?2?a?a [7]
Guess.Charset....: -1 c3, -2 8489969c9fa4a9b6bc, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:  9411.3 MH/s (0.18ms)
Speed.Dev.#2.....:  9896.7 MH/s (0.18ms)
Speed.Dev.#3.....:  4829.7 MH/s (0.27ms)
Speed.Dev.#4.....:  5154.5 MH/s (0.27ms)
Speed.Dev.#5.....:  4555.7 MH/s (0.27ms)
Speed.Dev.#6.....:  4747.7 MH/s (0.27ms)
Speed.Dev.#*.....: 38595.5 MH/s
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 902162052/69640284375 (1.30%)
Rejected.........: 0/902162052 (0.00%)
Restore.Point....: 0/81225 (0.00%)
Candidates.#1....: "yaÄ 1 -> }baü]a
Candidates.#2....: w!cÜ'p -> JWAÖe&
Candidates.#3....: {kaÄ^) -> psaÖ'p
Candidates.#4....: FUSÜe& -> Q!cä.+
Candidates.#5....: @loé.+ -> &11üV<
Candidates.#6....: /11ÄW~ -> :enü~}
HWMon.Dev.#1.....: Temp: 51c Fan: 34% Util: 63% Core:1898MHz Mem:4513MHz Bus:8
HWMon.Dev.#2.....: Temp: 49c Fan: 32% Util: 50% Core:1860MHz Mem:4513MHz Bus:4
HWMon.Dev.#3.....: Temp: 63c Fan:  3% Util: 96% Core:1354MHz Mem:3004MHz Bus:16
HWMon.Dev.#4.....: Temp: 62c Fan:  1% Util:100% Core:1366MHz Mem:3004MHz Bus:4
HWMon.Dev.#5.....: Temp: 65c Fan:  2% Util:100% Core:1379MHz Mem:3004MHz Bus:1
HWMon.Dev.#6.....: Temp: 66c Fan:  3% Util: 97% Core:1366MHz Mem:3004MHz Bus:1

Started: Sun Mar 26 08:45:52 2017
Stopped: Sun Mar 26 08:46:10 2017

Bruteforce of UTF-8, part 2 - with mask coverage

The simple demonstration above shows that the '?1?2' technique works ... but it also presumes that you know exactly which characters are German. In the real world, we usually do not know this.

Instead, rather than using a single mask, you'll need to supply a file that contains a list of all of the masks that cover the length of password that you want to try. Here's an example of a mask file that covers all six-character words that contain at least one 7-bit ASCII equivalent character (?a) and other characters from German using our multibyte mask pairs (?1?2), in all positions:

$ cat utf8.hcmask.6char
?a?a?a?a?a?1?2
?a?a?a?a?1?2?a
?a?a?a?a?1?2?1?2
?a?a?a?1?2?a?a
?a?a?a?1?2?a?1?2
?a?a?a?1?2?1?2?a
?a?a?a?1?2?1?2?1?2
?a?a?1?2?a?a?a
?a?a?1?2?a?a?1?2
?a?a?1?2?a?1?2?a
?a?a?1?2?a?1?2?1?2
?a?a?1?2?1?2?a?a
?a?a?1?2?1?2?a?1?2
?a?a?1?2?1?2?1?2?a
?a?a?1?2?1?2?1?2?1?2
?a?1?2?a?a?a?a
?a?1?2?a?a?a?1?2
?a?1?2?a?a?1?2?a
?a?1?2?a?a?1?2?1?2
?a?1?2?a?1?2?a?a
?a?1?2?a?1?2?a?1?2
?a?1?2?a?1?2?1?2?a
?a?1?2?a?1?2?1?2?1?2
?a?1?2?1?2?a?a?a
?a?1?2?1?2?a?a?1?2
?a?1?2?1?2?a?1?2?a
?a?1?2?1?2?a?1?2?1?2
?a?1?2?1?2?1?2?a?a
?a?1?2?1?2?1?2?a?1?2
?a?1?2?1?2?1?2?1?2?a
?a?1?2?1?2?1?2?1?2?1?2
?1?2?a?a?a?a?a
?1?2?a?a?a?a?1?2
?1?2?a?a?a?1?2?a
?1?2?a?a?a?1?2?1?2
?1?2?a?a?1?2?a?a
?1?2?a?a?1?2?a?1?2
?1?2?a?a?1?2?1?2?a
?1?2?a?a?1?2?1?2?1?2
?1?2?a?1?2?a?a?a
?1?2?a?1?2?a?a?1?2
?1?2?a?1?2?a?1?2?a
?1?2?a?1?2?a?1?2?1?2
?1?2?a?1?2?1?2?a?a
?1?2?a?1?2?1?2?a?1?2
?1?2?a?1?2?1?2?1?2?a
?1?2?a?1?2?1?2?1?2?1?2
?1?2?1?2?a?a?a?a
?1?2?1?2?a?a?a?1?2
?1?2?1?2?a?a?1?2?a
?1?2?1?2?a?a?1?2?1?2
?1?2?1?2?a?1?2?a?a
?1?2?1?2?a?1?2?a?1?2
?1?2?1?2?a?1?2?1?2?a
?1?2?1?2?a?1?2?1?2?1?2
?1?2?1?2?1?2?a?a?a
?1?2?1?2?1?2?a?a?1?2
?1?2?1?2?1?2?a?1?2?a
?1?2?1?2?1?2?a?1?2?1?2
?1?2?1?2?1?2?1?2?a?a
?1?2?1?2?1?2?1?2?a?1?2
?1?2?1?2?1?2?1?2?1?2?a
?1?2?1?2?1?2?1?2?1?2?1?2

To generate the rest of the masks that you need, policygen from the PACK toolkit (Python) can help. It doesn't recognize how to make all permutations of '?1?2', but you can create masks that use a different character set (like ?u), and then replace all '?u' with '?1?2'.

As I said above, it's not for the faint of heart! But once you get the hang of it, it's not hard.

Non-UTF-8 character sets (rare for WPA/WPA2?)

If the characters are not UTF-8, the charsets that hashcat ships with can be used directly. They are in the ./charsets/ directory of the hashcat distribution, and their use is straightforward and common for non-Latin character sets.

That being said, I would expect non-UTF-8 character sets to be rare for WPA/WPA2 passphrases.


Can one find the value of a "constant salt" if they can set the password and get the hash? Saying we have an oracle that an attacker can use as many time as they want. The attacker can send a non-empty password to this Oracle. The Oracle hashes the password using sha256(password + pepper), and sends this to the attacker.

The pepper value never changes (it's a bad constant salt).

Is there a way an attacker can guess the pepper? How would the attacker call the Oracle to get that pepper?

Do the same attack applies if the Oracle uses a hash_hmac('sha256', password, pepper) method instead of simple sha256(password + pepper)? Do this applies for sha256(pepper + password) instead of sha256(password + pepper)?

I've seen the question Is it possible to get the salt if I have the hash and original password? but there, we have one more condition: attacker can get as many hash; original password couple as they want to recover the constant pepper, so this condition might change a lot?

My guess is that one can do retrieve the pepper, but I'm not sure how it would be done. The process to retrieve it is not that much important, but I want to get a proof that such process exists and is do-able.

An attacker that knows the password and the hash but not the pepper is in the same position as the attacker that knows the salt and hash, but not the password.

Putting in another way: hashedValue = hashFunction('thing attacker have', 'thing attacker does not have').

On the classic leaked database attack, the attacker knows the salt and the hash, not the password. On your case, he knows the password and the hash. Looks different, but it's exact the same. Nothing different at all.

Difficulty? It depends on the length of the pepper. If it's a 128 byte random string, is as difficult as bruteforcing a 128 byte random password.


Application communication monitoring I am seeking a way to monitor communication between Android applications in order to detect their suspicious behaviour but I am not sure where to start the development process from.

As far I have found such tool like http://www.comdroid.org/ but its functionality in not what I am looking for. I would like to have app on my mobile that could inform e.g. that app A communicates with apps: B, C and D. I am guessing that kernel programming might be involved.

I would appreciate any hints, directions, literature etc.

TaintDroid is a modification of android to provide realtime privacy monitoring.

ProxyDroid forces all communication though a proxy such that it can be intercepted.


It's not scanning for the "shellshock" exploit.  It's scanning for an older exploit where a poorly-configured server leaves a copy of the PHP interpreter in the CGI directory, permitting remote execution of arbitrary code.


Does it make sense to keep RC4? I know that the RC4 cipher when used with SSL is vulnerable to certain attacks, which in the worst case scenario could result in authentication tokens being stolen. But RC4 is also recommended as a cipher to mitigate the BEAST attack.

Is it a better strategic decision, to disable RC4 and perhaps be vulnerable to BEAST, or protect against BEAST and protect against the attack RC4 is vulnerable to?

In any case, the client suggests but the server chooses. On the client side, you can specify that you prefer to use AES if possible, but if the client supports RC4 and the server wants to use RC4 if possible, then RC4 it will be. This implies that you cannot really "use RC4 as a last resort" (unless the client code does some trickery, which I don't believe mainstream SSL clients implement; namely not announcing RC4 support, unless previous connection attempts with other cipher suites have failed).

One way to look at it is that RC4-protected SSL is way better than no SSL at all. Another way is that whatever you do on the client, the server cannot be abstracted away; you are entrusting the server with your confidential data. The choice of the cipher suite is the server's responsibility, and if the server does not apply appropriate cipher suites (from your point of view) then maybe you should not send the data at all to such a careless server...

Known weaknesses of AES-CBC (the BEAST attack) don't work anymore if your client (Web browser) is up-to-date (and it really should !). Known weaknesses of RC4 don't seem to work in a Web context (because weakness exploitation requires millions of connections, and that takes time -- moreover, the first few hundred bytes of each request contain HTTP headers which are mostly uninteresting to the attacker). So it can be said that: RC4 or not RC4, that is not the question. Whether you disable or enable RC4, this is very unlikely to be the biggest security vulnerability, or even a significant vulnerability.

However, it may make sense to disable RC4, or to disable AES-CBC, in order to comply with some inflexible regulations, or to increase some (very artificial) "security mark" that some auditors seem very fond of, for reasons which have more to do with psychology than cryptography.


How do I know if I can trust a DNS service How can I decide if I could trust a given DNS service as a user?

For example I have just seen DNS-Watch which tells me that it is
secure and that they don't log anything.

How can I decide if the claims about security and privacy are reliable?

Trust is a tricky issue. How does one trust a person in real-life: Either one has already positive experiences with this person or because one trusts others which say that this person is trust-worthy too. Sometimes one also trust a person because of their appearance, like being dressed in a suite and a tie vs. a t-shirt and ripped jeans. But appearance alone can easily be faked.

As for DNS-Watch: they seem to try looking trustworthy by appearance. There are many nice buzzwords like Net Neutrality, Privacy or Uncensored on the page but there is nothing which makes verifying such claims possible. There are no well known and trusted references. Even quite contrary: the impress shows that the service is provided by a company which does among others social media management and movie based advertisement, areas which are not typically associated with privacy.

That said, I have not enough information to actually decide if the service is trust-worthy or not. But currently it looks more suspicious than trustworthy to me. If the provider really offers all these nice things it might be a good idea to make it possible for others to verify these claims. Or being publicly and verifiable endorsed by some well-known privacy focused organization might also help to establish trust.


Can we get rid of CAs with CT? There seems to be a consensus on the fact that CAs are bad, because we can not really trust them.

Smart people tried to find alternatives, like convergence and perspectives, but they somehow failed to catch on.

Now we have Certificate Transparency, but CAs are still here.
Can we get rid of them?

Say for example browsers start to just check if a certificate is logged on a CT log, and stop checking if it is signed by a trusted CA. The domain owner could use a protocol like ACME to log a self signed certificate, and the browser could handle it as trusted.

Could this work?

Could CT logs be enough for the TLS PKI infrastructure of the internet and to establish trust?

EDIT IN LIGHT OF COMMENTS:

It sounds like the question you are trying to ask is:

  I don't like the all-eggs-in-one-basket nature of CAs, so can we design a new TLS system where each cert needs to be signed by multiple CAs? Can we use CT for this?

Yes, you could design such a system so that multiple CAs would have to work together to issue a fake cert, this raising the bar. It wouldn't change the fundamental nature of needing CAs and needing to trust them, but at least you wouldn't have to trust them individually.

Current TLS implementations can't do this because an X.509 certificate object only has a single CA signature field. Current CT implementations are also not designed for this because CT logs are meant to monitor CAs to make sure they are doing their jobs properly, not to themselves be CAs.

So yes, it's possible to get Let's Encrypt-like functionality with a system like this, but would not be compatible with current technologies. CAs are not ideal, but (for now at least) the world seems happy enough with putting them under a lot of public scrutiny and pulling them from browsers if Google or Mozilla catches them doing something they are not supposed to be.

There are, however, a few trickier points about TLS certificates that I think would be hard to handle:

Revocation

One of the core features of PKI is the ability to contact the CA that issued your certificate and ask them to revoke your certificate. This may be because you had a security breach (hack) and your private key might have been stolen. It might be because you are decommissioning your server and you won't need the cert anymore. Whatever the reason, you want the next time that a browser tries to validate your cert, for the CA to return "NO! Cert Revoked!".

CT logs currently don't track this (it's the job of the CA / OCSP responder). If you went to a multi-CA model, then I guess revoking it on any one CA would do (but then we're back to a single point of failure model where one rogue admin could cause a DOS) so this would need very careful thought.

OV / EV certs

From your question, I take it you only have experience with Domain Validated (DV) certs, these are the ones that Let's Encrypt offers where ownership can be verified by automation. There are two other categories - Organizational Validation and Extended Validation where humans at the CA do extensive record checking, phone calls, and potentially face-to-face meetings before issuing them a cert because with those levels it's not just the website that's being validated, but the entire company that owns it. That's where you see a green bar with the company name embedded in it:

OV / EV certs are expensive (several hundred to several thousand dollars per year) but, I assure you, many companies buy them because of the extra assurance. This would be very hard to accomplish in any non-CA PKI model.

PREVIOUS ANSWER

  There seems to be a consensus on the fact that CAs are bad, because we can not really trust them.

Fine, but do you have an alternative? CT only? So what's stopping me from CT logging a self-signed cert for google.com and being able to MitM Google?

From your comment:

  we could guarantee that only the domain owner can write to a CT log

... so I need to submit a proof that I own the domain, and the CT log server needs to verify this proof before adding it to the CT log? But what if the CT log admins are not trustworthy and slip in one that didn't actually pass the verification? You've just invented CAs again, but now the CA and the person who watches the CA to keep them honest (CT logs) are the same person.

Trustworthy or not, CAs are a necessary part of the PKI system.


Metasploit Search Multiple Keywords I am having an issue with Metasploit's search commands. When trying to search multiple keywords, the output displays only the first keyword. For example, if I use the command search platform:windows type:exploit, I will only receive the output of for Windows platforms, and include payloads, exploits, and post.

The only time this seems to work is when I disconnect the database, which isn't an acceptable answer as that removes all of the database command abilities. I have also tried rebuilding the database but this problem persists.

Does anyone have a solution to this? I am running Metasploit Version 4.13.1-dev.

TL;DR - upgrade, it works like you expect now.

In versions before 4.13.8, search used a union instead of an intersection of results. Thus your example ("search platform:windows type:exploit") would show you all modules that target Windows (including payloads, auxiliary, and post modules) and all modules that are exploits (regardless of the platform they target).

After that release (early December 2016), search now does what you expect.