How to properly validate HTTP redirects? I'm reading OWASP's Secure Coding Practices Checklist and under their "Input Validation" section they have an item that reads:

  Validate data from redirects (An attacker may submit malicious content directly to the target of the redirect, thus circumventing application logic and any validation performed before the redirect).

I'm drawing a total blank on what they mean here!

Are they saying that an attacker could put a redirect request inside an HTTP request and just have the webserver execute the redirect, bypassing the normal URL the request would go to (and any server-side validation accompanying it)? If so, what would such an embedded redirect look like and how to I detect it? What does it mean to validate against it (as they say)?

And, if I'm totally wrong in my interpretation, what is it that they're talking about, and can someone give me a concrete example? Thanks in advance!

Good answer from alexwen, although I think his answer is more of a generic parameter sanitization problem, not exactly what OWASP is referring to. I think OWASP may be referring to any of the following concepts.

Revalidating Data From Redirect

OWASP is talking about a different kind of scheme where one URL does some processing (i.e. validation), then redirects to another URL to complete. For example, imagine two URLs, one is /checkout and the other is /ship. The /checkout URL checks the credit card information, checks that the parts are in stock, etc. then redirects to /ship. The /ship URL actually creates a work ticket to pull the parts and ship them.

If the attacker knows this setup, then attacker can just POST the relevant shipping data directly to the /ship URL, bypassing all of the validation performed in the first URL, and getting some products for free.

I've personally never seen a validation scheme this dumb, but it seems to be what OWASP is referring to.

Post-Redirect-Get Pattern

The PRG pattern means redirecting to a GET request after successfully processing a POST. This is used to avoid the horrendous usability problem of a user clicking the back button in a browser and the browser asking the user an obscure question about whether or not to "repost form data". (I've seen this trip up so many users that it's not even funny.)

I've never seen this used in such a way as to be vulnerable to attack, but in theory a poor authentication scheme might use PRG to process authentication credentials, then redirect to a "members-only" page or something stupid like that. Again, I've never personally seen in this in the wild, so I'm not 100% sure that's what OWASP is talking about, either.

Blind Redirect

I'm not sure that this is what OWASP is talking about, but this is actually a common vulnerability. Unlike the previous two vulnerabilities that I described, I have actually seen this in the wild many times. This common mistake is that the URL to redirect to is specified in the original URL query and is not validated, e.g.:

http://my.badsite.com/redirect.php?destination=http://google.com

If redirect.php unconditionally redirects to whatever URL is passed in (e.g. in PHP, header("Location:$location")), then an attacker can construct a URL that looks safe but actually leads to a dangerous site. For example, if the blind redirect script is at http://nytimes.com/redirect.php, then the attacker sends the victim a link like http://nytimes.com/redirect.php?destination=http://spyware.malware.xxx/get_pwned and a naive user looks at the link and thinks he is going to the NYT website. (Depending on the exact nature of the script, the attacker might be able to URL encode part or all of the destination URL in order to further obfuscate it.)

A redirect script should inspect the destination URL to make sure that it is appropriate, probably through some kind of whitelisting.


Has anyone used a file hash to prove authenticity of a file during legal proceedings? I've had a client come to me with a request for a feature to prove that a file uploaded to a cloud service we run is the same as the one that they subsequently stored in their document management system. They would need to do this well after the originally uploaded file was deleted. They would need to provide this proof as evidence during legal proceedings.

My knee-jerk reaction is to implement a feature to md5 hash the file on upload to the cloud service and store the result as an audit record. This would allow for later comparison with a hash of the file from their document management system.

I'm also wondering whether basic (non-computed) metadata about the file and then compare that to the downloaded file could be enough - filename, file size etc.

This is really a digital forensics question. Does anyone have any experience in this area? How strong does the proof need to be? What could we implement to prove that the two files are the same under the assumption that one would be deleted? Any sources of guidance would be amazing.

Has anyone used a file hash to prove authenticity of a file during legal proceedings?

Yes, it's a routine step in Computer Forensics.  But you really should read Law Is Not A Science: Admissibility of Computer Evidence and MD5 Hashes by Rob Lee.  In short, don't expect waving a hash in court to prove anything - you need to present the story of the hash in a way that the court is comfortable trusting it.

If you're implementing a solution, think not in terms of the technology but in terms of what the court would need to know.  That means logging the introduction of the file into your system, and then being able to prove tie a later-in-time copy of the file back to that original provenance.  The hash is how you prove they are the same.  Make sure the proper logging is in place to show who (user ID, IP address) uploaded the file (hash) when.

If "when" is important to your legal concerns, you should look into a Trusted Timestamping service - you provide the log entry with hash, someone timestamps and signs it, you can later get that verified to show that yes, really, you had hash adef01....42fc in hand on 7 June 2018.


SSL/TLS handshake fail rate I would like to know some numbers regarding to SSL/TLS handshake fail rate, i.e. what is the percentage of (failed SSL/TLS handshake)/(total SSL/TLS handshake) across the internet. By failure it means that all kinds of possible causes are all included.

I'm looking into related problems so I need data. Is there any sources that imply related statistics? I can't find them.

Hard to say.

The most common cause for SSL/TLS handshake failure is an inability to agree upon a common protocol and cipher.  Because the protocol/cipher suite presented by the client is going to vary widely from client to client, and the suite supported by the server is going to vary widely from server to server, there's no way to do a real statistical analysis.

There are real numbers available for things like supported protocols and ciphers.  Those can be used to infer things like failure rates for older browsers (IE6, Java 6).  And then there's actual breakage like Microsoft's ServerKeyExchange problem - quantifiable as the result of an intersection between two pieces of software, but how often to they intersect in the real world?  Hard to say, and not measured.


What "MySQL (unauthorized; French)" means when perfoming nmap in port 3306? I'm a student in computer security, and I often see this when performing an nmap scan on the training lab I'm using:

3306/tcp open MySQL (unauthorized; French)

I'm wondering what unauthorized means, what is unauthorized and why? Also, what is the meaning of French aside unauthorized?
Finally, are there possible consequences in term of security (and what are they)?

When nmap tries to identify a service it tries to read the banner that the service presents to a connecting client.

In this case, the banner shows the string "unauthorized" and might be in French. You can confirm this with nc or telnet and performing a banner grab manually.

There's no specific security issue here. It's just banner contents.


Are these "Urgent Firefox Update" popups bogus? I've gotten, over the past couple of weeks, at least three screens popping up saying "Urgent Firefox Update".  These are from URL https://eexowdlzyjx.net/.  At least once they have been preceded by "request to load" security popups from unknown (and equally obscure) URLs.  All this while browsing the BBC news site.

Am I correct in assuming that these are bogus?

I'm running Mozilla Firefox, version 47.0, and I have Flashblock 1.5.20 installed.  My AV software is Norton Internet Security version 22.6.0.142.

Update 7/23/2016:

For some reason today Norton "caught" this, since right after the bogus screens popped up it came up with a warning that it had stopped a virus.  It labels it pf06aivz.js.part and calls it a "JS.Downloader".

The bogus screens came up just after I closed a BBC screen, and the bogus web screen loaded over ("pushed down") a CNN screen.  Not sure what that suggests.

Always, always use ad-blockers.  Browsing the web without an ad-blocker is like sex without a condom.  Always use one unless you are 100% sure the site you are browsing has malware-free ads.

I would refrain from clicking on any pop-up, especially in this case, as Firefox auto-updates in the background and requires no user input, unless a browser restart is required.


UNIX Servers: Possible intrusions or attacks that do not use any of the open listen sockets What type of attacks are there that do not use open TCP or open UDP ports?

Is it safe to assume that no open ports means no remote access?

(Excluding the possibility that there is a badware already on the machine that makes outgoing connections to send/receive data/instructions)

Edit: Looks like we also would have to disable ICMP to (help) prevent Denial Of Service type attacks and the possibility of buffer overflow or other undiscovered attacks. Also the possibility that the server would receive a spoofed ping that then sends the response to a third party victim for Denial Of Service

Edit: Looks like one should also look at good-ware "that makes outgoing connections to send/receive data/instructions" such as DNS. The DNS server instructs the UNIX machine what other machines to connect to and send/receive data for. One has to make sure that the DNS server is not hacked and the routers on the way are not hacked.

Edit: I am specifically referring to network attacks in this question. As far as client-side attacks (cookies, social engineering, XSS, etc.) that is not for this question.

Edit: I am attempting to (hopefully fully) secure the servers so that they (theoretically) will not need a firewall. Firewalls are intended but not part of this question.

  Related: What security risks does IP spoofing bring?

Regardless of whether this should apply specifically to Unix, I would say that it is not safe to assume no access just because there are no open ports.

To wit, ICMP is usually listened to, even if no TCP or UDP ports are available.
And before you say, "But ICMP is just a simple Ping! It's irrelevant to attack using that!" check these out:

Ping of Death
Smurf attack
and of course, Ping flood

And while these are all pretty much historical (with the exception of the last), I wouldn't rule out additional, future attacks.

In addition, there are the indirect attacks, such as those that attack the infrastructure that the closed-off system would itself access - e.g. DNS poisoning...


Vendor Mutual SSL required on behalf of different organisations I'm a software designer (former IT SysAdmin) trying to wrap my head around some authentication requirements in an API Specification document.
Let's say government department (abc.gov) has created a new online web portal to receive 'incident reports' electronically via a RESTful JSON (Swagger) API secured with Mutual SSL (TLS).
Various Service Providers (we'll call one xyz.org) are to ask their software vendors to provide an updated system that can connect to the abc.gov API.
Our software is cloud-based (ASP.NET, IIS8, - let's say jkl.net). Various organisations would log into our web system (username + password), then our software would have to connect to abc.gov and impersonate (for lack of a better word) xyz.org.
abc.gov provides the following information along with the API specifications:

Client certificates will need to be issued by a Trusted Certificate Authority
Client certificates cannot be shared across different organisations.
This client certificate needs to be shared only with the certificate's public key.
If the same vendor is submitting incidents on behalf of multiple service providers, the vendor must use a different client certificate for each service provider.
When client certificates expire, new client certificates will need to be issued by the Service Provider and provided to abc.gov, without the private keys.

From the research that I have done so far, I roughly know that we can:

store multiple certificates,
assign the certificate name to an organisation in our database,
and then select the right one to present when establishing a connection.  (https://support.microsoft.com/en-us/help/901183/how-to-call-a-web-service-by-using-a-client-certificate-for-authentication-in-an-asp-net-web-application)

Questions

What I am not sure on, is where are these client certificates from?
What type of certificate is required, and how would it work given that the domain names will not match?  (i.e. xyz.org requests a new certificate, gives it to jkl.net, to authenticate with abc.gov).
Would IT staff from service providers conclude that this practice is unsafe?

Thanks in advance - looking forward to learning more about this.

What type of certificate is required

A certificate suitable for authentication as a client. As for the exact requirements which CA's are trusted by abc.gov check the documentation you got from abc.gov.

  how would it work given that the domain names will not match

Client certificates are usually not checked against domain names since there is usually not a specific domain associated with the client. There is no standard on what the subject should contain so you would need to check again the provided documentation what is expected. One option would for example the email address of the client.

  Would IT staff from service providers conclude that this practice is unsafe?

I assume they would. Giving somebody a client certificate so that he can impersonate the client is similar to giving somebody the username and password, i.e. abandoning any control what can be done by impersonating the client. Therefore it is usually forbidden by various security guidelines. And I doubt that abc.gov will like that practice too.


Is Session Fixation a tough one to resolve? Just found session fixation vulnerability in couple of tech giants. Giving the steps I have done:

1. Login to your account in a browser (Browser 1).
 2. Extract cookie using cookie extractor.
 3. Import the cookie to different browser (Browser 2).
 4. You logged into your account without password.

Note: In some cases, I am able to login into second browser even after logout from first browser (Both browser is having same cookies to connect as I imported the cookie from first browser to second browser).

Question 1: Why this is happening?

Question 2: Probable way's for resolve this issue.

Question 3: Is this even a session fixation vulnerability?

Question 4: Should I report it to their bug bounty program?

Question 1: Why this is happening?

Your session is only bound to a session cookie, not to the IP or any browser details. This is entirely common - even Github does that. (Using additional properties to bind the session can have undesired consequences, e.g. it could lead to random logouts when a user updates their browser or changes their IP.)

  Question 2: Probable way's for resolve this issue.

It's not a major security issue. Copying cookies from one browser to another requires access to a browser's cookie storage which an ordinary attacker doesn't have. If you still want to ensure that a user can't reuse their session in a different browser you could bind additional properties, e.g. invalidate a session as soon as the User-Agent header changes.

  Question 3: Is this even a session fixation vulnerability?

No, it's not. In a session fixation attack you force a known session ID on an (unauthenticated) victim. This ID remains valid after the victim logs in so that you can reuse it to be authenticated as the victim yourself. But without an additional vulnerability there is no way to inject the session cookie into the victim's browser in the first place. The OWASP page on it has some examples that show which possible preconditions can lead to a session fixation vulnerability.

  Question 4: Should I report it to their bug bounty program?

Most likely it's out of scope. With the hordes of bug bounty hunters you have to expect that issues like these are already covered on high-profile sites and if they persist it's by design.

  In some cases, I am able to login into second browser even after logout from first browser.

A logout should invalidate the current session but not necessarily terminate all other active sessions. Just because you log out from Github on your phone, you don't necessarily want to be logged out in your browser, too.

This demo shows on the example of Github that copying the same session cookie from one client to another is often permitted:

Login on Github.
Copy user session cookie user_session from the browser's cookie jar. (You can't do it with JS because the cookie is HttpOnly.)
$ curl -b "user_session=[your session id]" https://github.com/
You will find that the HTML response is still authenticated. (You should see your own username and your repositories in the code.)


Decrypt a file by knowing the original content We had some ransomware get into our system a couple of weeks ago, and it has encrypted a large amount of our files.

I am wondering, is it possible to figure out an encryption key if I know the decrypted content of a file. We have a couple of .txt files that only held a serial number for a specific software product. If I know the original content (the serial) and have the encrypted file, can that be used to find the encryption key and theoretically decrypt all our other files?

Thanks

No, that is not how encryption works. Where it then you could defeat any Full Disk Encryption by knowing the contents of say some default icon file.


How secure is WiFi roaming if clients connect automatically to access points with the same SSID and security? After reading a bit about WiFi roaming where multiple access points are set up with the same SSID and WPA/WPA2 shared key, I'm wondering how secure the concept of WiFi roaming is.

If clients connect to access points with the same SSID (and usually without the user's knowledge), what's to stop someone setting up a rogue access point to get the shared key or do something malicious with users' traffic?

Rogue access points can certainly be dangerous, but there is a caveat:

If the "real" network is encrypted, you cannot set up a rogue access point without knowing the key. Rogue access points must have exactly the same security settings as the original access points, including the same key.  If they do not have the same key, clients will try to connect but fail.  Fortunately, it is not possible to see what key the clients attempted to use, as the key is never actually transmitted during the authentication process.

Thus, the only people who can cause any real damage with rogue access points are people who already know the key to the original network.  People who don't know the key can still set up a rogue access point, but all they'll be able to do is make people unable to connect when their devices fail to authenticate with the rogue ap.

For networks with large numbers of users and public networks though, they become a more serious concern.  There's no way for a users to tell that they may be connected to a rogue ap, and pretty much anything could happen (data theft, malware injection, eavesdropping...) if they are.  That's part of the reason why VPNs are always recommended when using public wifi.


How important is CAPTCHA on registration pages? I am working on a site and I would like to add CAPTCHA to the user registration page to prevent user name enumeration.

I am working with a front end developer who feels pretty strongly that we should not add CAPTCHA to the registration page because it's a pain for users and will reduce our conversion rate.

I know that there is sometimes an inverse relationship between the security of a site and the usability of the site and that some security vulnerabilities are worse than others.

If there was something like a SQL Injection vulnerability I would insist that we fix it, but I'm not sure if a user enumeration vulnerability is serious enough to justify me fighting for this particular fix.

How important is it to have CAPTCHA on a registration page and how seriously should user enumeration attacks be taken?

My personal experience with ReCAPTCHA (widely regarded as being one of the best) is that it took about a week after we added it before the spammers we were trying to prevent figured out how to solve them.

They don't solve 100% of the presented images correctly but they don't have to.  Even getting one in every ten correct would be fine for them and they are doing better than that.  They are probably doing better than our customers.

There are some alternative styles of CAPTCHA that involve playing games or selecting the picture of a kitten out of several images.  These types of CAPTCHA have not yet seen any serious attention from dedicated spammers.

User enumeration may not be a solvable problem, depending on the design of your site.  In the case of a forum, an attacker simply needs to visit the forum and note down the usernames he sees attached to every post.

If anyone can register to the site, the registration process will have to notify the potential user that the name they have chosen is already taken.  A CAPTCHA will probably change the equation for an attacker here because the cost of solving it and the failure rate compared to the potential value of the enumerated credential would probably mean that it's not worth the effort.

Since usernames are generally the non-secret part of the credential pair, even figuring them out usually doesn't have much value for an attacker.


Ways to secure administrative pages of a portable site I made a CMS (using PHP) that is basically drag and drop to be live (under linux/apache hosts), now I need the communications between the administrative/login pages of said CMS and the client (recent firefox/chrome) to be safe.

I wanted to use a basic auth system working under TLS. That would be great but the certificates usually have to be installed on the server which basically kills the portability aspect.

Is there a way to use TLS that doesn't involve having to install it in the server?
If not, are there any alternatives to it that fit the requirements?

I concede that due to the constraints presented I may have to find alternatives to an encryption protocol to improve security in the above mentioned pages, like an authentication system that manages to build a secure connection after a clever "handshake".

What such systems do you know of that would respect the project constraints?

Keep in mind that I'm looking for something that was made and used, I have ideas of how I could make my own but I won't if I can avoid it, which would be ideal.

Certificates may be generated automatically on the server upon first launch. The EFF is even building a project, Let's Encrypt, precisely targeting automated generation, configuration and update of browser-trusted certificates.


In setting up a VM, does the Bridged or NAT configuration provide more separation security? I am setting up a few VM's (assume VirtualBox w/ Linux). They will all be on the same PC host (assume Linux) and the intent is to have all the VM's handle separate functions (business, personal finance, and personal) and have no connection to each other through the network or otherwise. I want to set them up in a way that creates the best security as far as separation from each other and the host. The host will function only to host the VM's. I would prefer to use one VPN subscription, which has been purchased anonymously. However, if this compromises the separation of these VM's, then I would consider changing the approach.
Given this setup, which method (Bridged or NAT) would work better as far as providing the least amount of leaked information between the VM's/Host?
Additional information:
The plan is to set up software firewalls allowing only outgoing connections for the VM's and the host. I am still looking into whether this is the best approach (secure and user-friendly approach).

I was going to post this as a comment but anyway. I've mentioned QubeOS earlier, sounds like something you may be interested in.
I thought I would mention something else: to isolate traffic on a physical network we have VLANs too. AFAIK QubeOS - like other virtualization solutions - uses Linux namespaces to achieve isolation. Although this is somewhat beyond the scope of your question you might be interested in these two concepts.
On Linux you have sandboxing tools like Firejail or nsjail that help you isolate applications by limiting what they can see and access. They work by taking advantage of the Linux containerization functions. If you choose to use a Linux distro other than QubeOS, you can use those tools. Be aware that some applications may malfunction and need a bit of tuning. Example: an app wants to access some data on the file system but it cannot see beyond your home directory. One thing I noticed with Firejail on my system is that VLC was not able to download subtitles (I have not yet bothered to fix this).
The reason why I am posting this is, is that the scope of your question goes beyond bridged or NAT networking, or firewalls. I would even say this is a moot point really. While network design is important there is a lot more that can be done to achieve your goal.
Strong security comes with a number of constraints. You have to find the right balance between security and convenience. If you implement any of the solutions proposed here, you should expect to run into some problems and sort them out on your own, which can be a daunting task for an "average" Linux user.
Regarding QubeOS, I don't have experience with it but I have a colleague using it. Seems that there are still stability issues or routing problems happening, so it is one distro for experienced Linux users. But it doesn't hurt to try.


Anonymous web browser. Is it real? Do anonymous browsers work? What principles do they use? Can I use them to test access to my web site? Can I detect if a visitor is using one? What is the different between traditional and anonymous browsing?

While I am getting answers I have found something new:

some additional information about Tor and its weaknesses.
a "nice" security issue: css hack :) and Plugging the CSS History Leak
evercookie (javascript API available that produces
extremely persistent cookies in a browser)

There are a lot of ways how to identify who you are, here are some of them:

get information about user from HTTP headers (not reliable, can be modified);
detect browser by CSS/JS specifics by using hacks;
get information by using JavaScript (can be switched off);
by detecting and using plugins;
possibly other methods I forgot;

As a proof of all above, you can check Metasploit Decloaking Engine: http://decloak.net/. Some basic information and further links you can get here: http://0x416d73.name/ws and this one: http://panopticlick.eff.org/. Also, a lot of information you can get by Googling "browser sniffing".

It is important for yourself to understand which level of anonymity you want to get. This is relied upon other question - why do you need it? I believe that it is nearly impossible to hide yourself in internet, at least, if you are connecting from your PC.


What are the security risks to have admin rights for a user account on Windows 10? I am considering the security risks to have a standard user added to the Administrators group on an enterprise Windows 10 machine that is dedicated to that user. This is related to security only, so breaking the OS of a wrong manipulation, installing unlicensed programs or similar administrative tasks is out of scope of my question.
The only one I found so far is that such rights allow for that user account to dump the authentication hash of someone having had interactively connected to that machine (via mimikatz for instance). This can be prevented via Credential Guard or other mesures limiting the use of wider admin accounts.
All the other risks I can think of are applicable to a normal user anyway:

execution of programs that will extract data (with the user rights - so data the user has access to anyway).
attempts to map the surroundings of the machine looking for lateral moves
persistence through scheduled tasks
communication to a C2

Are there other security concerns to be an administrator of one's machne as part of one's normal, everyday account?
EDIT: following up on a comment - I do assume that the user can be compromised. What I am trying to understand is what the fact that they are an administrator of their own machine changes in the risk landscape
Note: a similar question discussed the ability to add admin rights to users but I could not find anything related to additional risks beyond the ones a normal user introduces anyway (besides "best practices" and legal constraints which do not apply in my case).
There is of course an xkcd strip about that, which I add for completeness

Credential Guard does not protect against theft of domain cached credentials or the local SAM database containing password hashes of local users, because these things are stored on the hard drive. The latter is not a problem if you are using LAPS. The former is not a problem if all accounts are using secure passwords (or if you set the maximum number of cached credentials to zero, which may not be advisable depending on your requirements).
However, best practices are best practices for a reason. It's the principle of least of privileges and the concept of defense in depth that can prevent damage in case another vulnerability arises. New techniques could come to light, or a bypass against Credential Guard could be found in the future. After all, Mimikatz is just one exploit of the fundamental problem that whoever controls the computer also controls the users that are logged onto it. For example, I'm not sure if Credential Guard protects against token impersonation.


PBKDF2 strong salt for client-side hashing What should I use as a secure/strong salt for PBKDF2 hashing when salt is not available to use before login as it will be client-side javascript to hash user+pass with PBKDF2 ? I'm going to use sha(user+pass) as salt for pbkdf2.

If I use a random generated salt, I should store it in DB, but when user wants to login, user won't have salt to encrypt his password with salt before sending it to server for verification.

So what's good/safe/secure solution here?
P.S. I'm trying to achieve "zero knowledge" protocol. Also I am already using SSL.

First, make sure you read this answer to the question "Client side password hashing", paying particular attention to the last paragraph.

Also, please realize that client side javascript is going to be incredibly slow at PBKDF2 compared to good server side code.  At least try to find a PBKDF2 implementation that uses HMAC-SHA-512 as a base.

That said, if you want to give the user peace of mind, that's fine; do the following:

Client side PBKDF2 hashing for a known, "high" iteration count.

Double bonus points if the user is allowed to select the iteration count themselves!
I put high in quotes because I doubt your javascript code's going to be fast enough to do tens or hundreds of thousands of iterations in the time you can get enough of your user base to accept, particularly on cheaper mobile devices.
A good hash of the username and password as a salt isn't great, though it's better if your code pads the username out to the maximum possible length and puts it first.

That way, "user1" and "password" don't make the same salt as "user" and "1password"!
There is, of course, no maximum length on the password except what's caused by your back end software; SQL Server, for instance, has an 8000 byte maximum on "less inefficient" string work.

Send that hash by itself to the server

which then DOES generate a cryptographically random salt of 12-16 bytes
and then uses PBKDF2 with a much higher iteration count to hash the hash passed in

again hopefully HMAC-SHA-512 for the 64 bit operations to lessen the proportionate advantage of offline GPU attacks.
because then someone who gets your leaked password database still has to do the work of an attack against a password hashing function to log in, rather than simply sending the client-generated hash they stole and having it be accepted as-is.

Remember with PBKDF2 password hashing in particular, never ask for an output size larger than the native base hash's output size.  Smaller is all right if you're really, really concerned about storage; for instance, requesting only 32 bytes of  PBKDF2-HMAC-SHA-512's native 64 byte output.

20 bytes for SHA-1
32 bytes for SHA-256
64 bytes for SHA-512


Digital time capsule system I want to create a system for sensitive information that is only accessible if you have a specific tablet and a specific USB thumb drive. I want to setup such a system for my daughter when she is a certain age, the system will contain certain information I want to pass on.

Is that possible in some way? I have no idea where to start on such a thing.

So, you want to hide information until a certain date, for your daughter. This must resist her attempts to retrieve this data too early.

Just use any encryption software (GnuPG, VeraCrypt, even 7-zip, etc), encrypt your documents (the data) and put them on a external hard drive or a tablet, then put the encryption key or the randomly-generated password (the secret) on the USB thumb drive.

Make sure to put the drive containing the encrypted data in an hazard-free location (you  don't want it to be destroyed by fire, flood or extreme changes in temperature and air pressure). Make sure your daughter knows how to find it. Give your secret (the thumb drive or the password) to a notary to be released on your daughter birthday. Add it to your testament too, bad luck happens. I would recommend to print on paper a long randomly-generated password (use a password generator) instead of an encryption key on a thumb drive as it will be more resilient to time than any electronics. Also, the notary will prefer a piece of paper. You can add a description of the location of the hard drive next to the password.

If you're looking for a way to ensure the data cannot be retrieved before a certain date by means of software or hardware only, I'm afraid this cannot be done. Whatever the chosen "solution", it would be very easy to fool its date and make it believe the day has come to release the data.

For added peace of mind, I would recommend saving your encrypted data on two hard drives and storing them in two different locations. You can also look up Parchive: apply it to your encrypted data to generate redundant data. This will be useful to recover from the corrupted bits likely to occur when time will take it's toll. Also, prefer a "classic" HDD over an SSD to hold you data, as HDD have a proven record to be able to sustain data for a long time without power.


How do people keep track of their employee's privileged accounts? I am curious how the community here keeps track of a user's accounts. For instance, in the event of an employee transitioning from the company, how does security make sure that all user accounts the user had access to are in fact revoked. Active Directory is pretty simple, but what about all of the cloud accounts, such as Dropbox, Salesforce, etc?  Do people use spreadsheets to track when access is granted or some other method?

Some clarification: For cases like Dropbox, these would be corporate accounts that utilize dropbox. For instance, sales may choose to utilize dropbox for sharing.  Or for instance Marketing may have access to the company's Facebook page.

If you are allowing people to use personal accounts for external services like dropbox, you really have no control and you do not own those. Most services that offer a corporate or business version have the ability to set one or more administrators, and can disable the accounts through this interface.

From a process standpoint, some organizations do this by hand, others have checklists built into the HR management systems with workflows. Ultimately, if the credentials are not tied to AD, LDAP, Shibboleth or some centralized/federated system, you will need to manage these individually. You could use any type of database to track this.

Your organization should develop some type of service management inventory/database. In an ideal world, no third party service is used without management's authorization and these should all be tracked as part of the vendor management process (ITIL, CMMI, etc can provide guidance on the vendor or third party service provider management). From this list you should be able to make a checklist and you could check each checklist.

As part of normal user management processes, you should be doing regular access reviews/certifications to check that all current users should still be granted access. In a more mature organization, you will have processes and a paper trail or database which tracks all access authorizations, changes, and revocations. In this case, you should have a paper trail showing all grants instead of checking the list of all possible systems.

As part of a layered approach, in some cases, you can work with the third party vendor to restrict access to the application from outside of your network. In this way, the ex-employee would have to break back into your network to then access the service. Since in most cases you are likely to have at least revoked their remote access and local network access, this can help to partially mitigate the risk if you do not immediately remove access (but hopefully catch it during the periodic access review/certification).

I am not going to recommend any specific product, but you may want to google for something like "access management software for third party services" or "identity access management enterprise tool".

Partially related to this are tools dubbed "privileged identity management", but this are more generally geared towards managing shared administrator credentials.

tl;dr It's more about developing robust access management and access review policies and procedures so that way you have accountability. You should pick a system that has a strong audit trail and is backed up, a spreadsheet can easily be modified, lost, poorly version controlled, or exposed to unauthorized individuals.


WordPress 4.7.2 Authentication Cookie Brute-force I recently came across a WordPress (v 4.7.2) site with an exposed wp-config.php file, within which plain text server authorisation key secrets were accessible.
Having read Mike Czumak's article on generating WordPress cookie, I understand on a high level how the generation of WP auth session cookies may work:
http://www.securitysift.com/understanding-wordpress-auth-cookies/

The pertinent host dependent inputs required for the brute-force process are a valid WordPress user ID, server name and the server AUTH secrets from wp-config.php.

The article however applies to WordPress 3.9. I'm wondering if the brute force attack described in the article is possible in newer versions. I tried the POC and found that the version 3.9 auth cookies generated were in a shorter format than those required for 4.7.2.
Comparison of the WordPress source code reveals an additional $token parameter that is used to when generating $auth_cookie.

3.9

$auth_cookie = wp_generate_auth_cookie($user_id, $expiration, $scheme);
$logged_in_cookie = wp_generate_auth_cookie($user_id, $expiration, 'logged_in');

4.7.2

if ( '' === $token ) {
    $manager = WP_Session_Tokens::get_instance( $user_id );
    $token   = $manager->create( $expiration );
}

$auth_cookie = wp_generate_auth_cookie( $user_id, $expiration, $scheme, $token );
$logged_in_cookie = wp_generate_auth_cookie( $user_id, $expiration, 'logged_in', $token );

I am in the process of reporting the issue to the site owners. I have not been able to completely follow the newer (>3.9) PHP code and so would like some pointers as to whether the same type of cookie generation brute force attack is feasible on version 4.7.2?

Your question is about WP 4.7.2, but the current version is 4.8.1. Use the current version, always. My answer is for 4.8.1.

Simply put, the old hashing algorithm was md5 and the new algorithm uses sha256 (preferred) and sha1 if sha256 is not available.The updated code has increased the search space for brute forcing, which increases the time required to find a match. But, they are still generating these hashes based on predictable criteria.

So, yeah, brute forcing will now take longer (orders of magnitude longer), and under current computing power, it's probably computationally infeasible even though we are using predictable inputs.

I'm not a fan of them using predictable material to generate this hash or the cookie, because it significantly reduces the search space. But, it's certainly better than it was. And, since the site is Wordpress, the only thing you can really do is keep it updated.

In looking at this code, by the way, it seems that they did not update the use of MD5 hashes elsewhere. Granted, hmac with salt is significantly more secure than just an MD5, but MD5 is very broken, and it seems to me that the computational cost of using SHA1 over MD5 is negligible. Not sure why they didn't update all hashes to at least SHA1 if not SHA256.


How are websites actually mititating BREACH? (HTTPS + compression) After reading some popular questions and answer on this website about BREACH, the only advice seems to be: don't compress anything that might contain secrets (including CSRF tokens). However, that doesn't sound like great advice. Most websites are actually compressing everything, so I wonder what they are doing exactly to prevent BREACH. I just checked the page with the form for changing your password here on StackExchange, and it's compressed. It looks like everything is compressed on Google too, and a lot of other important websites that are supposed to care about security. So what are they doing to prevent BREACH?

Here's a list of possible solutions I've been able to gather:

Disable compression completely. This means wasting bandwidth and no one seems to be doing this,
Only compress static resources like CSS and JS. Good idea, that's the quickest solution to implement, and that's what I plan to do on a few websites that I need to optimize.
Checking referrers and avoid compression whenever the requests from unauthorized websites. Interesting idea, but it almost sounds like a "dirty trick" and it's far from perfect (some clients suppress referrers, all traffic coming from other websites and search engines will end up loading uncompressed pages, etc.)
Rate limiting the requests. This it definitely implemented by Google, since if you click on too many links too fast you might see a CAPTCHA (it happened to me sometimes, while checking a website's position in the SERP, I was literally behaving like a bot). But are websites really relying on this to mitigate BREACH? And is it even reliable? What is a sensible and effective limit to set, for example?
Use CRSF tokens in HTTP headers instead of the body of the page. I haven't noticed something like this on StackExchange, but Google seems to have interesting HTTP headers that look like tokens. I guess this will really mitigate the issue, provided the tokens are always checked (even just to display information, not only to change it). I guess this is the perfect solution, but it's the hardest to implement unless you do it from scratch (it would require rewriting several parts of your application).

So the questions are: are the above points valid? Are there any other options? And what are the websites that follow best practices actually doing?

There are several ways to mitigate BREACH effectively, but all of them have trade-offs. In order to understand how these mitigations work, we need to look at how BREACH exactly works:

How do I BREACH TLS security?

The secret ingredients, according to p. 10 of this presentation on BREACH, are as follows:

Compression of the response body
A stable page
A secret in the response body
Attacker-supplied data
A known prefix

What sticks out the most is that both attacker-supplied data and the client secret need to be in the same response. Furthermore, the attacker needs to be able to cause the client to receive a lot of responses, and all of them need to contain the modified input from the attacker.

So, for instance, if I wanted to use BREACH to extract your session cookie, I can't just write my payload (e.g. 4bf8dfc73...) into this answer body and update it continuously. You actually need to receive the response for every single update.

As you see, this is quite a convoluted setup. Sure, it is possible to do all of this with some <iframe>-magic, but those have fallen largely out-of-favour, to the point where some sites refuse to be loaded via <iframe> or instruct browsers not to open <iframe>'s within the document.

Knowing all that, what do sites do to mitigate BREACH?

They just ignore it

This is one of the most common approaches. It may seem insecure at first, but given how many things need to align for BREACH to become viable, it certainly seems like just not caring about it is quite a viable strategy.

It certainly is viable if:
 - No client-secrets are in any response
 - The site is purely static

Just compress static resources

This is another very common alternative. All static compressible resources, such as stylesheets or scripts, will be compressed, while all dynamic resources will be delivered as-is.

It should be noted however that many such resources are already minified, meaning that further compression will not yield much better results.

However, with this approach you get at least some compression done, while you can make sure that you are not vulnerable to BREACH.

Disable compression altogether

Another viable strategy. As I mentioned above, many static resources are somewhat compressed anyways, so further compression will yield diminishing returns anyways. Just disabling compression can be just fine too, especially when your network resources are good anyways.

Load secrets separately

Another mitigation is to load client-secrets separately, where no attacker-controlled data can be injected. This way, compression can be enabled for all requests, and attacker-controlled data is always separated from client-secrets.

I'm sure that there are other ways that people have attempted to mitigate BREACH, all with varying degrees of success. But these are methods I've seen and that I would personally agree with (yes, even not caring).


Limited Buffer Size for shellcode on 64 bits machine I have a code snippet which has the classic strcpy vulnerability

int main(int argc, char argv[][]){
    char buffer[8];
    strcpy(buffer, argv[1]);
}

By disassembling the binary file, we can see rsp is decreased by 0x10 bytes (=16)

So we can actually overwrite the rbp after 16 bytes and return address after 24 bytes. Before the function returns, rax is pointing to the beginning of our shellcode.

Here is my approach to attacking the program.
Our shellcode will be in the following format

"A"*16 + "B"*8 + "C"*8

As ASLR is enabled, I replaced return address to an address of jmpq *%rax, so the payload will now become

"A"*16 + "B"*8 + "\x77\x04\x40"

and by stepping through in gdb, I can see execution is being directed to the beginning of "A"s. However, the buffer is too small to put in a (system(/bin/sh)) shellcode. What am I supposed to do here?

Here is what I am thinking:

Use egghunter approach. However, I am not able to send more than 24 bytes data to the application, as the return address include null bytes, it terminates my shellcode.
Find a shellcode that is smaller than 24 bytes for 64 bits Linux. (I guess this is not possible)
ROP approach, however, ASLR is enabled, I can't figure out the base address of libc

I have read through many tutorials and most of them have a big buffer like char buffer[500] instead char buffer[8]. It will be great if someone can guide me to the right place.

There are multiple possible ways around this, it's just a matter of being creative.
Here are some things you could try:

If you know your current libc's version, you could find a one-gadget with constrains meeting your register values.

Also, if you know your current libc's version, there should be enough size for a small shellcode that overwrites the least significant bytes for the strcpy()'s GOT entry to point to system() instead.

There is a nice 23 bytes long 64 bits Linux shellcode you could use here: https://www.exploit-db.com/exploits/46907.

Depending on the way this binary was compiled, there might be just enough gadgets for you to build a 1st stage ROP chain that increases your buffer size before jumping back to strcpy() to get the rest of the payload from the stack.

I hope this few examples shed some light on the endless possibilities you have here.


DAST Scanner for Post Authentication I am wondering if anyone know's of a DAST Scanner than can either take in an authenticated request from somewhere like burp, OR some DAST software that takes username and password  and then run DAST scans against the target.

I've used a ton of DAST tools like nessus, openvas, etc but they all take in a target UNAUTHENTICATED, not AUTHENTICATED and then run DAST scans against the target.

Instead of saying go hit ip 1.2.3.4 i want to say, go to 1.2.3.4/user/account for example.

Anyone have any programs that can run DAST as an authenticated user? e.g. run sqli, xss, dir traversal, etc.

Thanks

Let's start with that Nessus and Openvas are not DAST tools.

Burp is a very good option, you might go with, OWASP ZAP is similar, but it is 100% free.
Than there are other vendors like Rapid7 Insight AppSec (not InsightVM/Nexpose), Tenable Web Application Security (not Nessus), Synopsis, etc., a simple search on Google will give you a bunch of results with vendors.

All of the major vendors can hold a session active whilst doing the scan, that's one of the basics. I would suggest looking at the report quality, ability to integrate and ease of use.


header injection + codeigniter I'm reading through Mozilla's Secure Coding Guidelines, and found this statement:

Don't trust any user data (input, headers, cookies etc). Validate it before using it

I'm using the codeigniter framework, and am using the following (mostly built-in functions) for inputs and cookies:

Inputs

global xss filtering is set to TRUE
CSRF protection is set to enabled

Cookies

cookies are flagged as secure
cookies are flagged HTTPOnly
cookies are encrypted

Headers. This is where I'm running into an issue. How do I protect my site against header injection? Haven't been able to figure this out.

Also, while I am validating user inputs like passwords, etc., am wondering if there is some other type of validation that needs to be done?

I use HTTP response header splitting as an example below, but the solution at the end works equally well when the injection is into the response content body.

For example, an attacker supplies an input

/
Access-Control-Allow-Origin: evil.org

and then the server uses that input to generate headers

response.setHeader("Location", input)

which results in the headers

 Location: /
 Access-Control-Allow-Origin: evil.org

One solution is to carefully check all code that specifies headers and make sure it does not use unfiltered/untrusted inputs to generate the headers.  This is error-prone, time consuming, and is not guaranteed to hold under maintenance.

A more robust solution is to use library methods like response.setHeader that refuse inputs that contain newlines.  If response.setHeader did

 void setHeader(String name, String value) {
   if (!(match(name,  "^[A-Za-z\\-]*\\z") &&
         match(value, "[^\u0020\u0021-\u0023-\u007f]*"))) {
     throw ...;
   }
   ...
 }

then an attacker might be able to deny service, but would not be able to split headers, and your logs would contain traces pointing to the problematic setHeader call.

If you're using a framework, often you can wrap your response objects so that the header methods do this.


How do I check if a gmail/gtalk SSL certificate is valid? Pidgin started prompting me to accept/reject new gtalk SSL certificate a few days ago and I am not able at the moment to tunnel the traffic to check if it would continue to happen or if it wouldn't (which would mean an attempt of SSL MITM attack).

How (and where) can I check if the new SSL certificate is valid? Can I even do that? Is there a place with a list of certificates where I could compare them?

I found this question, but I am not sure if that is the answer I am looking for. Answers to that question say that it is clients job to validate the certificate, but what happens to me is that pidgin (in my case the client) tells me "The certificate for talk.google.com could not be validated. The certificate claims to be from "gmail.com" instead. This could mean that you are not connecting to the service you believe you are.". Now, I may be overparanoid but I would still really like to know how and if I can manually check this. Thank you.

The message you quote means: "I wanted to talk to a server called talk.google.com, but what responded there seems to use a certificate which has the name gmail.com in it, and not talk.google.com". This means that either of these is true:

some ill-intentioned third party is actively redirecting your connection to the wrong server, possibly by DNS poisoning;
some mishap at your ISP implied a bad DNS configuration which emulates the effect of DNS poisoning, redirecting your connection attempt to the wrong server;
Google does not know how to do SSL;
there is something fishy in your Pidgin configuration.

From here, connecting to port 443 on talk.google.com results in a server certificate which includes the name: subject=/C=US/ST=California/L=Mountain View/O=Google Inc./CN=talk.google.com, which is correct.

Note that Google is known to play tricks with the DNS. From my home machine, talk.google.com is resolved to an alias to talk.l.google.com, which has IP 74.125.113.125. From another machine on another continent, talk.google.com is resolved to an alias to talk.l.google.com, which this time has IP 209.85.147.125. There is obviously some sort of worldwide load-balancing in action here.

Bottom-line: you cannot check "by yourself" whether a certificate is good or not, save perhaps by phoning the Google headquarters and having them spell out the certificate fingerprint (which they might agree to; they are rumoured to value such kind of humour). Actually, the message you get is a rather definite indication that you do not get the right certificate, so you'd better use the message as a symptom and investigate if you indeed connect to the right server. I suggest trying Wireshark to see what server Pidgin is actually contacting, and what happens at the SSL level.


Using and creating a custom 2 way encryption function I am trying to create a 2 way encryption function using PHP.

As yet I do not have a very good system at all, it is severely flawed and highly insecure, it is using a substitute cipher running from the periodic table of elements (this is not what want, but what I am working on making better).

My question is as follows:

What is the best way to create a symmetric key algorithm that both creates a salt for a string to be encrypted with and a decrypt function using the same salt and algorithm that is safe, secure and maintainable? What do I have to look out for that creates a weakness/vulnerability within the code/crypto function?

For what I have now, please see this question on codereview.stackexchange.

Notes:

This is not going to be used as a "rolled out" product, it is purely for training and development purposes
I understand that this may very well be off topic, if so please say and I'll remove this question

You should not attempt to create your own crypto algorithm for production use. Creating crypto systems is work for highly specialised teams of cryptographers, but everybody needs to start somewhere off course. ^_^

Instead, use a well known cryptographic algorithm. If at all possible (and it is possible), use a class that encapsulates all the configuration options for you and provides dummy proof methods.

Take a look at:

Pixelfck/SymmetricEncryption For an easy 'drop-in' solution (their words, not mine).
Libsodium For a more elaborate (hence a bit complex) library.

Normally, I would say: whatever you do, don't go editing the source code provided: a tiny seemingly insignificant edit can jeopardize the whole library, and you won't even know it.

BUT: since you indicate that you want to learn from it, studying and toying around those two solutions may give you a nice start.


NTLMv2 Hash harvesting remotely I'm experimenting with ways to harvest NTLMv2 hashes remotely. Responder.py is perhaps the most widely used mechanism (these days) to perform the task, but I'm unsure if it's even possible to utilize it remotely.

Ideally what I'd like to do is run Responder on my attacking box and proxy the information through a compromised machine via a Meterpreter shell (or similar mechanism).

Is this something that's possible? I've been able to find no real documentation on it.

If not, is there a mechanism that could accomplish this that does not involve privilege escalation to harvest passwords from lsass?

Responder.py and MultiRelay are recompiled for win32, but I've used the Python scripts in Win10's Linux subsystem and they also appeared to work fine from there. I prefer purpleteam/snarf for NTLM Relay, but if all you want is hashes off-the wire then any pcap library/utility will be fine.

If you are PowerShell-fluent you can use Inveigh.

If you want to focus on what you can do without escalating privs then you can use NetRipper, net-creds, PCredz, or similar. Depending on the version of Windows and other factors (protected processes 1, protected processes 2, protected processes 3), lsass may or may not be able to provide passwords.


FP vs FN for Malware detection I have been working on Random Forest Classifier to detect .exe files as Malware and benign. According to me False Negative in my model should be low because they are more harmful but in some blogs online, it is mentioned that False positive are more harmful in malware detection than a false negative. I was wondering what is the reason behind this.

If your malware detection software/anti-virus produces too many false positives, it will flag many useful applications as malware and users will, rightfully, get annoyed. Sooner or later, the users will either turn off or remove the malware protection completely or get used to ignoring and blindly clicking through any warning that the antivirus raises. The result will inevitably be that in the end, even blatantly malicious files will end up being executed by the users.
Yes, false negatives are harmful too, but having a few false negatives is better than detecting every malicious file (which isn't even really possible) but still having every single malware get through just because the user simply ignores the anti-virus. Additionally, in case a file is borderline suspicious, it can be sent to the anti-virus firm for further analysis and so new malware will be detected and its signatures added to the malware detection engine. However, if false positives lead to users turning off the protection, many malicious files will never be detected or will take a much longer time to get detected, confirmed as malicious and added to the signature database.


Powershell and cached credentials In my environment we have powershell remoting off- I get around this using 2 hop scripts, packages(exe -no creds are stored in code- local privs only), and iwmi. I never pass creds to the endpoint, only use it to auth to the endpoint. I use heightened accounts to parse logs, manage configs, etc on endpoints. Since my account technically logs in every WMI hit it makes (visible in the event log) does this also mean that creds passed with WMI and powershell are stored in lsass and potentially visible to procdump or mimikatz like module/framework?

Thanks so much for any insight or thoughts into this!

My new found understanding:
Two types of logons for this- one stores and one doesn't:

Interactive logon occurs when a user enters their logon creds at boot, RDP, or other interface on the local machine. This logon type injects user’s credentials into memory as Kerberos tickets TGT, NTLM, LM, or plain text. This logon type is the primary security concern when dealing with mimikatz, TGT spoofing, procdump, and PTH attacks. In other words interactive logins need to be kept to LEAST privilage.

Network logons user’s credentials are authed to the destination system in order to access or remotely admin. These credentials types are not passsed to the service/system and therefore not stored on the remote system in memory as any of the above mentioned string types.


Need help with decrypting the "client key exchange" captured in Wireshark I am trying to understand how the SSL handshake happens for HTTPS.

I did the following:

Captured the packets for a HTTPS connection using Wireshark.
examined the Client Hello for cipher suites supported (not important)
Examined the Server Hello for the cipher suite decided by the server. It is TLS_RSA_WITH_RC4_128_MD5. Which means
Handshake algorithm is RSA. which means the master key is encrypted using the public key of the server and sent to server.
The next message Client key exchange is where I am facing the challenge. Exported the "Handshake protocol: Client Key exchange" encrypted byte stream. The byte stream in hex is:

10 00 01 00 8e 1b d9 49 6f 9e 15 8f b9 b6 8a 2e
e0 90 f1 54 3b 54 7d d3 d5 2e 64 b5 37 cc ae 74
ec 3f 38 59 1a 42 78 98 3f e1 4e 7b 8b 84 74 a9
17 95 c0 b7 07 d9 b1 a1 d0 1f 5a a1 2e 71 b6 98
ea 4b 6c 62 f3 b3 8c 8e d7 20 9a 4b 6a a7 d7 4c
f8 69 c9 6c d6 0b 8b d0 9f 59 28 f5 52 60 fa e9
72 52 4c 87 98 30 fe 6f ef a6 5b 11 fd 6b 0e 0d
db 60 d5 d4 d8 a6 0e 6d 9f 02 58 01 a4 21 d5 aa
17 80 5f 42 ec 84 78 a8 41 ed bc 94 c5 83 ab 74
09 b9 91 9d bf 6d c1 4b 85 95 90 d8 b4 22 fb 00
a4 76 af 54 e2 c3 1e 84 6f 5e 02 18 05 f5 6c 83
7f dc a7 44 85 24 06 b6 89 6f 13 4e 25 f0 ce 59
23 8c 50 4d c2 56 11 b9 0d 63 b5 28 b8 ad e7 9c
f2 16 96 f8 dd 4a f9 b5 72 8c 6f 6a 6c 8b 40 d7
03 c7 a8 d6 8e 88 38 00 d2 d3 9b 4a 04 3a 16 55
1f c9 58 c8 3f d3 7a 33 9a 3f 98 1c 74 83 3c 45
5a b2 9c da

I stripped off the first four bytes (message type and size)
Tried decrypting the client key using the server's private key using the command:

openssl rsautl -decrypt -inkey /etc/apache2/ssl/apache.key -in Clientkeyexchange_enc -out Clientkeyexchange_dec

The hex value of the result is:

03 00 E1 B9  2F 27 4F 85   46 AF 54 CC  5D 55 5E 92
71 CD 14 60  02 96 08 BA   8D E0 65 B7  A5 27 EF E4
F7 4E 4A 02  55 47 80 4E   36 FF 49 75  D2 B6 AB 83

I am unable to decrypt the application data using this value.
I know I have misunderstood something. But unable to find out what.

First, before actually answering, I hope you do know that Wireshark can do all the hard work for you in this case (plain-RSA key-exchange and server privatekey available). Just go to Preferences / Protocols / SSL and give it the (clear) privatekey file and it will do the key computations and decryption.

If you want to understand a protocol, looking at the specification of that protocol (when available and IETF ones are) is usually a good idea. Note that SSLv3 is showing its age, most recently with POODLE (see several dozen recent questions), and you really should use TLSv1.1 or better (also addressing BEAST).
Under ClientKeyExchange we find:

5.6.7.1. RSA Encrypted Premaster Secret Message

   If RSA is being used for key agreement and authentication, the client
   generates a 48-byte premaster secret, encrypts it under the public
   key from the server's certificate or temporary RSA key from a server
   key exchange message, and sends the result in an encrypted premaster
   secret message.

        struct {
            ProtocolVersion client_version;
            opaque random[46];
        } PreMasterSecret;

   client_version:  The latest (newest) version supported by the client.
      This is used to detect version roll-back attacks.

   random:  46 securely-generated random bytes.

So your RSA-decrypted value is the premaster secret, and is for SSLv3 although you didn't say so. For any key-exchange once the premaster secret is established, you use it along with both Hello.random values to derive (compute) a master secret as described in 6.1. Asymmetric Cryptographic Computations
and then use the master secret with the nonces (which will be new nonces in the case of session resumption) to derive the working keys and if applicable IVs, plural, as described in 6.2.2. Converting the Master Secret into Keys and MAC Secrets.

Note in TLSv1(.0) and 1.1 the key derivation functions are changed to better mix MD5 and SHA1, the first more clearly named 8.1. Computing the Master Secret and the second moved forward to 6.3. Key calculation but both share a PRF moved to 5. HMAC and the Pseudorandom Function. Further in TLSv1.2 the KDFs are changed to use SHA-2.
Also note the "export" ciphersuites used a modified KDF in SSLv3 and TLSv1(.0); in 1.1 and 1.2 these suites are officially deleted and the modified KDF with them, but some implementations may still allow them (but if they do you shouldn't use them).


Is it safe to reuse a tab in a browser for different websites? A friend of mine recently asserted that it is unsafe to reuse the same tab in a browser for different websites. In other words, if the user:

Visits a sensitive website (for example logs in his bank account),
Goes to the address bar while the sensitive website is still opened,
Enters an URI of a different website which appears to be hacked,

then his bank account can be compromised. On the other hand, if the user:

Visits a sensitive website (for example logs in his bank account),
Closes the tab,
Opens a new tab,
Enters an URI of a different website which appears to be hacked,

then he's safer than in the first case.

The person asserting this couldn't explain concretely why is the second approach safer or show an example of such attack. He guesses that “is has something to do with memory management, in the second case, the memory being safely cleared”.

Without knowing the internals of browsers, this still seems weird to me. If there was a risk, I would expect it to be related to the browser's history (could the hacker's website benefit from accessing the history of my visit of the banking website?) and not memory management per se.

Is there an actual risk? Should I close tabs while going from a sensitive website to any other website?

I'm not aware of any security issue of reusing the same tab for different web sites, i.e. I don't think it is better or worse to reuse a tab vs. close and open a new tab.

But apart from reusing only a single tab it can be a security issue if you use the same browser application or the same browser profile or even the same operating system for sensitive and non-sensitive tasks. If the sensitive web site uses session cookies or similar mechanisms to keep you authorized and if this sensitive site is vulnerable to (very common) CSRF attacks then an attacker might misuse your identity from another tab or window within the same browser or even from a different browser on the same system. With simple session cookies it must be the same browser instance, but if persistent storage from flash or silverlight is used for identifying the user this identity token might be shared over multiple browser profiles or even between different browsers on the same system (see https://www.chromium.org/Home/chromium-security/client-identification-mechanisms for more details).

Thus for sensitive stuff like online banking you better take at least a different browser profile which gets only used for this purpose. Or you might even dedicate a different computer (or virtual machine) for this purpose.


How does this site decrypt SHA256 hashes? I thought sha256 is impossible to crack (so far).
But I saw a website, that could decrypt my hash.
So is this because they store known hastes in a database or
do they really decrypt hashes?
Here's an image:

You are correct, the hash functions SHA256, SHA384 and SHA512 are (currently) unbroken, so it is not possible to easily reverse them. MD5 and SHA1 are considered broken because researchers have found pairs of strings that produce the same hash value, but even these require weeks or months of computation.

(note: I don't like that the site uses "decrypt" because that's a word you use for encryption; you can't "decrypt" a hash)

What they are probably doing is a dictionary attack in which they have pre-computed the hashes for all common dictionary words. This would give them a lookup table which would take in a hash and return the word that produces it.

Just to give an idea of scale, there are 171,476 English words and a SHA256 hash takes 32 bytes, so storing the SHA256 hashes of all English words would only take about 5 mb.


IPSec sequence number I was going through a study of IPsec and I found that there are redundant sequence numbers: one in the AH or ESP header, and the other is in the TCP header for a communication.

Is it not an inefficient use of sequence numbers as we are using the same number again and again? What is the need of this redundancy of sequence numbers?

Two numbers are needed because there is a many-to-one relationship between TCP streams (with separate TCP sequence numbers) and an IPsec tunnel (with its own sequence.)

Imagine a host with an IPsec VPN. It has two programs using the network: a web browser and a mail client. If there were only one sequence number, then either they would have to take turns making TCP connections through the tunnel, or they would each need a separately-configured IPsec tunnel for each TCP stream they establish.

The existing architecture ensures that multiple TCP, UDP, and other IP protocols can be multiplexed through a single IPsec tunnel.


How can VPN providers end violating accounts when "they don't log any data"? VPN providers can end accounts which violate their terms of use. If you look at https://nordvpn.com/terms-of-service/ for example, you see that they will terminate accounts violating their ToS. The same is for other providers.

How do they know you are violating their ToS when "nothing is logged"? That's contradicting as hell. According to a well known comparison chart, some providers which are serious about privacy are Nordvpn, IVPN and BlackVPN.

I am not planning to violate their ToS, but I am very sceptical about privacy in general.

Claim to "not log" is not the same as "not monitor connections". First is saving traces, second is analyzing activity when it happens, that does not necessary generates logs.

However, while not totally clear, I understand they claim to not monitor too:

  NordVPN does not monitor, store or record logs for any VPN user.

They do not monitor logs (since this is written in their Logging Policy) or connections? Maybe depends on who is asking :)?


Which Wifi encryption method is secure? Apple just removed the ethernet port from new MacBooks which means we have to use Wifi! But I think WEP encryption is broken, and WPA encryption which I can't see on Mac is also broken. So Wifi means no security, right?

WPA2 is the only secure method. WEP and WPA are "broken". Also, WEP is easier to crack than WPA. However, any security, even WEP, is better than no security as it will effectively prevent opportunistic connections to your network.

I just checked and indeed the new Mac Books Pro don't have an Ethernet port. All I can say is WTF?!?


Are the SS64.com password generators a good approach? There are two password generators on ss64.com:

The standard one
The strong one

How they work

I made standalone versions of them, plus copy of the original HTML/Javascript versions, if you want to study them, but here is how they work:

This section explains how the passwords generator work, such that it is possible to roll out a standalone version that does not depend on relying on a third party web site.

You have a master password, let's say foo
You generate a password for a specific site or service, let's say stackexchange
You compute the SHA1 sum (standard version) or SHA256 sum (strong version) of the string foo:stackexchange.

$ echo -n "foo:stackexchange" | sha1sum      #standard version
b99341502484edbc43ec35a5f94be8e5de7ca53a *-

$ echo -n "foo:stackexchange" | sha256sum    #strong version
c6ac66fdb639821bcc322f186fb1214d241f35ba2a91cb660daf0a284ac19a47 *-

You apply Base64-transformation on the sequence of bytes of which the hexadecimal representation is the previously generated checksum:

$ printf "\xb9\x93\x41\x50\x24\x84\xed\xbc\x43\xec\x35\xa5\xf9\x4b\xe8\xe5\xde\x7c\xa5\x3a" | base64
uZNBUCSE7bxD7DWl+Uvo5d58pTo=

$ printf "\xc6\xac\x66\xfd\xb6\x39\x82\x1b\xcc\x32\x2f\x18\x6f\xb1\x21\x4d\x24\x1f\x35\xba\x2a\x91\xcb\x66\x0d\xaf\x0a\x28\x4a\xc1\x9a\x47" | base64
xqxm/bY5ghvMMi8Yb7EhTSQfNboqkctmDa8KKErBmkc=

(strong version) you replace + with E and / with a, and take first 20 characters
(standard version) you take first 8 characters and then add 1a at the end of the password to ensure there is at least one digit and one letter

Therefore, with master password foo, and for specific site stackexchange, the standard generated password is uZNBACSE1a and the strong generated password is xqxmabY5ghvMMi8Yb7Eh.

Now the questions

Is the strong version really stronger than the standard version? Would it still be stronger if the standard version also used SHA256?
provided that I choose a good master key (not foo, rather more than 10 random characters), am I rather safe with these generated passwords?
What can be other drawbacks of this approach towards creating passwords?

There are two levels of strength here:

Whether the provided password will be, by itself, strong (against brute force).
Whether someone learning one of your passwords on one site will gain leverage for guessing your passwords on other sites (e.g. by guessing the "master password").

The "standard" version produces passwords with 48 bits of entropy: Base64 encoding is 6 bits per character, and the generator uses 8 characters (the "1a" suffix is fixed, so it does not change security at all). 48 bits of entropy are not bad, especially in the context of online attacks, where the attacker must talk to the server for each try. If the server gets hacked (database dump through SQL injection) and the server did not use proper password hashing, the an industrious and motivated attacker may break through it; in that sense the "strong" version is a bit stronger than the standard version. However, in that specific case, I'd say that the weakness is in the server, not the password (not using proper password hashing is the bad point here).

Note that switching from SHA-1 to SHA-256 does not improve security. It is not bad, but it offers a practical gain only insofar as SHA-1 does not provide good preimage resistance, and, right now, SHA-1 is still as good as new in that respect.

For the second level (escalating from site password to master password), both versions are weak because they are way too fast. Given a site-specific password, enumerating potential master passwords can be done at a rate of a few billions per second (with a couple good GPU). Moreover, since the transformation is not salted except by the site name, if several people use the same method for their passwords on the same site then their master passwords can be brute-forced in parallel. The "strong" version is not much stronger at that level than the "standard" version, except for the fact that SHA-256 is about twice slower than SHA-1, thus doubling the attacker's cost.

The approach also suffers from a few usability issues:

If the server requests that a user changes his password, the user cannot comply, because the method produces one password for a given master password and site name.
If the site name changes, then the password generation breaks.
Some servers have special requirements which are not necessarily fulfilled by the generated password (e.g. some servers mandate that passwords shall contain at least one punctuation sign -- a misguided requirement, but it happens).
Others have pointed out the problem of entering your master password on a page served by a third party Web site -- page whose contents may be changed without notice and without any visible warning. A stand-alone version avoids this problem, but if stand-alone applications are allowed, then this opens the possibility of using a better system.

Indeed, more flexible solutions (e.g. KeePass) use a storage system. There is one indirection: the master password is used to encrypt a bundle which contains the actual passwords. This allows for changing passwords and fulfilling other requirements.


How long should a password reset token remain valid? What is the recommended lifetime of a password reset token?

Too short will degrade user experience and too long would compromise security.

Microsoft identity default to one day but this very long.

The answer depends really on the complexity of your reset token. The aim should be that a reset token is not guessable in the given valid time.

So for instance if your reset token is 5 characters long, only digits and your server is capable of answering to 100 requests per second without rate limiting, 15 minutes is likely too long. Just think about the possible attack:

An attacker resets his own password to see how the links work
The attacker resets the account of his victim, knowing he has n minutes time
The attacker calls the password-reset page with more or less random keys until he finds the correct one.

This - especially step 3 - should not be possible in the given amount of time. That means if you have a great enough universe to draw reset-keys from (like 32 chars, alphanumeric) as well as rate limiting in your application, even one day won't affect your security much. Also you can (and should) choose to inform your user with a second email/message on the performed password change. Also note that your application may support very long reset-tokens without compromising the user experience as they never have to type it.

Edit: Of course you should calculate in a way that only a very small percentage of keys can be tested in the given amount of time. For example a 0.000001% chance of guessing the right key in the given timeslot might be an acceptable risk. A small amount of risk is something that you will have to accept in any way.


encode der with openssl When you issue openssl dgst -sign key <file it follows the PKCS#1 standard to generate a digital signature.

hash file with some hash digest function
encode the hashed value in DER format, specifying the hash function used, and the hash function used.
sign the actual binary DER data with RSA PKCS#1, which pads it if needed.

I want to do these actions step by step with the openssl command line.

I can use openssl dgst <file to generate a hash.

I can use openssl rsautl -sign -inkey key -in file to generate RSA signature for file, and pad it correctly.

But I don't know how to take the hash, and encode it with the appropriate DER format. Is that possible?

The ASN.1 structure we are talking about here is:

DigestInfo ::= SEQUENCE {
    digestAlgorithm  AlgorithmIdentifier,
    digest           OCTET STRING
}

AlgorithmIdentifier ::= SEQUENCE {
    algorithm        OBJECT IDENTIFIER,
    parameters       ANY DEFINED BY algorithm OPTIONAL
}

When encoded in DER, the actual hash value (the raw bytes) will be located at the very end of the encoded structure. So the DER encoding of the structure, for a given hash function, is equivalent to concatenating a fixed string of bytes with the hash value. The string of bytes for various hash functions are given in extenso in PKCS#1 (section 9.2, page 38 of version 2.1 of the standard).

So, on a Unix-like system, to get from hash value contained in file hash-value.bin to the DER-encoded structure specifying SHA-256, you would do this:

(printf '\x30\x31\x30\x0d\x06\x09\x60\x86\x48\x01\x65\x03\x04\x02\x01\x05\x00\x04\x20' ; cat hash-value.bin) > encoded-hash.der

The Devil hides in the details, and ASN.1 is so much full of details that it should rightfully be burnt at the stake. In this case, notice how the parameters field is marked OPTIONAL. In a much older version of another standard, a typographic error resulted in the omission of that keyword; hence, some implementers found it that they had to include some parameters, even so the OID was enough to designate the hash function. Hence, they added an ASN.1 NULL value as parameters (it shows as the 0x05 0x00 bytes in the encoded headers). However, some later implementers found it fit to "correct" the issue and omit the unneeded parameters altogether, as is permitted by the OPTIONAL keyword. The bottom-line is the following: for a given hash function, there are two versions of the "fixed header string" to be concatenated with the hash value. For instance, for SHA-256, PKCS#1 says that the header is:

30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20

but one may also encounter this alternate header:

30 2f 30 0b 06 09 60 86 48 01 65 03 04 02 01 04 20

which some implementation use. According to PKCS#1, you shall use the first one when producing signature, but you also shall accept both when verifying signatures.


How to guarantee privacy on files that I store I want to create an Android app where users from an office (typical use) can upload scanned documents to the app backend service for later use.

e.g. A lawyer want to upload a sentence sensitiveDocument.png.

The guaranteed privacy for the user is a important sale point for the product. From the previous example, the lawyer wants that he is the only person who can read the document, neither myself as a S3 administrator (I plan to use Amazon S3 for the storage), and not to mention other users.

Also, I want to assure to my users that I can't read their files.

Idea

A user key controlled by the user: the user symmetrically encrypts the file with its key, uploads the file encrypted and when he want to read the file, he retrieves the encrypted file and decrypts it on the Android app.

Cons

The user has to remember another bit of information besides the password.
Alternative to the previous one, the app can automatically generate and store the key but...
Either way the user can lose the key, for the first case e.g. if he forgot the key, and in the app side e.g. if the key is accidentally deleted or the phone is stolen, etc.

Is there a way to do this properly?

One further step is to use a key derivation function to derive a key from the user's password.  You can then encrypt the data key used for encrypting each file with the user's derived key and you can store the encrypted form of the data key on your server with the file.  Without the user's password the key can't be used, but it also lets the user access it from multiple devices without having to deal with key management.


Preventing Ethernet over power I'm an electrician doing a job at a secure site. The client is concerned that someone could plug an Ethernet over power (EOP) connection into the switch and then connect elsewhere in the building. Is this possible and if so, how can I prevent it?

The room is secure with a dedicated three-phase supply and no power circuits extend out of the room.

This is relatively simple if the two ends of the network path are either:

On two different phases of the building's 3-phase supply
From different power supply cabinets

It is possible to filter out the high frequency components that the signal uses, leaving only the 50 (or 60) Hz mains supply - in fact many power smoothing components do this by default. It is cheap and simple.
In this instance, because you have a dedicated phase, it becomes very easy. In reality very little signal crosses between phases. There could be some, but it will be miniscule. Filter high frequencies from either phase, and the likelihood of getting any signal on one of the other two is effectively zero. See my other answer at https://security.stackexchange.com/a/9728/485
The wider solution, however, is to define in policy or contract that this is not allowed, and then track down breaches of policy and do whatever is necessary - this may be disciplinary action. Detection of signal is relatively easy, as the frequency hopping signal is obvious to spot on a spectrum analysis - although as most Powerline uses encryption you may not be able to identify what the traffic is.


How to identify coded content in a phishing page First of all, I'm a completely dummy in information security. Today morning I've received an email that make me curious. It was a kind of phishing page which was not detected by the Gmail's spam filter. So I've downloaded the content to take a look into its code. What I found was simple HTML/JavaScript page with something like this at the footer:

function XF(){return new Array('0cd0a85cd81679c246c5a0bb377e5f3b789d0612531b507f4a9dd98ba372219feb0d35d42db5970a21c95428a46ddb18bd664c405e1dd9074f6e0ffdda0cd7f9365337e1baca81c9d73803789c0192093adef61debca1f9525309693700fe45464d57327a2fb449f05b4c0736a71bcf1ffcc66a09e439358cf0d1abf9763f1548ac13a8aed69a52e8a3f15d0d5294f41877d4b5408e95c1286f390bb1bf19c6581b3c17075ebf4733b7224bf275cc8911fc15b359bd195d4f2220ad2ca3991f096f22e32d0ae0a749d921f7bb331a7a07fa31e98f2ea6edf4c996bf82e2eea6664033f1e890023d1bb2fc8b3dbf9ca70bfb9b9063f583d2927f2eeb82c08d130e7c04c2ea8a388750694fbef8a3257944f838446cbfbdd827275e20938288fcb5876608d8d444931c5b03c441e6086aee1111ed0a8366a64e75c38afddf4a6bf70f3583ca7bdf5402f281e62405899c38bcdf51c497cdfdc5951850f5a53d0d0fa7373fa458df3f63ebfff78a2b2a159ad48e1575f55f2adf8a3fc3202dfd15a7c1efe0efec1ceaa69406b3db509bbe596d3ee97e2c365ba7f48fd01ad3035beba46ae443aee287739033c9c9fcf8ec0daf8247931d667a6ab8d8c60cbe627f4b37a5a6ee7bf5de687cdb15c3b6778e6b9af28af9b2306c3f93ffd5588347e293fc61a75263317e3ef10e59f7798a936625d98dae2904186de3aefa1e877af65', ...}

UPDATED 1: Here's the whole code in PasteBin.

I've just past the first element of the array in order to minimize the code. I can figure that's a hexadecimal array, but I'd like to know how I could decode its content to see what's doing.

Any help will be appreciated.

UPDATED 2: I was able to convert part of the code back to String and I realized that it's really a ofusqued script. Check: https://jsfiddle.net/g9hsaj3o/

Just a few small things, haven't figured out the thing entirely. Feel free to expand and comment on this.

After we beautify the code, we get: http://pastebin.com/CdZ5BTfj

We see:

var C4 = new Array(0x3c, 0x73, 0x63, 0x72, 0x69, 0x70, 0x74...

And then a function

function DC() {
    var Wb = C4.length,
        _yu = new Array(Wb),
        i;
    for (i = 0; i < Wb; i++) _yu[i] = String.fromCharCode(C4[i]);
    document.open();
    document.clear();
    document.write(_yu.join(""));
    document.close();
};

So, this just performs HEX --> ASCII conversion and writes the decoded string into the document. This in turn evaluates to

<script>
    function _ii(Cc) {
        var Dc, yx, _099, _ln, o, _x02, _jh;
        Dc = new Array(4);
        _jh = XF();
        _ln = _jh.length;
        yx = _r0(Cc, _s88n(_jh[_ln - (0x4c ^ 0x4e)]), 0x03e8);
        _099 = ZZ(_xsii(_jh[_ln - (0x2b ^ 0x2f)]), yx);
        _x02 = ZZ(_xsii(_jh[_ln - (0x98 ^ 0x9B)]), yx);
        o = JJ(_jh, _099, _x02, Dc);
        if ((Dc.join("")) == _jh[_ln - 1]) {
            document.write(o.join(""));
            document.close();
        } else {
            msg.innerHTML = "&nbsp;";
            alert('Senha inválida!');
        };
        _ip = false;
    };
</script>

This is where it gets interesting, because other obfuscated functions are called. This is where the magical array returned by "XF()" is being used:

function XF() {
    return new Array('0cd0a85cd816....6ec24dde78ca48', 'd6860accfa237d675ba73acc5e486168', 'f81845c6e66b62e5fc758da50dc73d68', 'a96751384baa020ef306acaed4e7851683989674', 'eb3494af236b53ec970b830e308ff41d');
};

Since we just need to grab the decrypted string that is again written in the document, we can easily modify the code to output the string instead.

But, for that we need the "cc" Object that is used within _ii(). We see that there is a function calling _ii():

function A0(Cc) {
    if (!_ip) {
        msg.innerHTML = ms2;
        window.setTimeout(function() {
            _ii(Cc);
        }, 0);
        _ip = true;
    };
};

But then, who calls A0 instead and with what argument? We look at the HTML and see

<form name="F1" onsubmit="A0(document.F1.P1.value)" action="javascript:A0(document.F1.P1.value)">

And also

<a href="javascript: A0(document.F1.P1.value);">

So, we need the value of the form F1 and the subobject P1 for that

However, I haven't figured out the right argument for that right now. Maybe a hardcoded value somwhere inside. When I execute the modified version of the function with argument "abc" sothat it ouputs string that is written to the document, I only get garbage right now

If we figure out the right argument, this will probably decrypt correctly to a new piece of malware. The code I've seen until now is just Hashing (MD5 or SHA1) and encryption stuff. The real malware must be inside the array at the XF() function.

(Modified function: )

function _ii(Cc) {
    console.log("inside");
    var Dc, yx, _099, _ln, o, _x02, _jh;
    Dc = new Array(4);
    console.log("good");
    _jh = XF();
    console.log("outside");

    _ln = _jh.length;
    console.log("good");
    yx = _r0(Cc, _s88n(_jh[_ln - (0x4c ^ 0x4e)]), 0x03e8);
    _099 = ZZ(_xsii(_jh[_ln - (0x2b ^ 0x2f)]), yx);
    _x02 = ZZ(_xsii(_jh[_ln - (0x98 ^ 0x9B)]), yx);
    o = JJ(_jh, _099, _x02, Dc);
    console.log(o.join(""));
    /*if ((Dc.join("")) == _jh[_ln - 1]) {
        document.write(o.join(""));
        document.close();
    } else {
        msg.innerHTML = "&nbsp;";
        alert('Senha inválida!');
    };*/
    _ip = false;
};

The form is safe to open, none of the linked pictures exist anymore. We have the following page:

The text left to the textbox seems to say "Please enter your password". So, this seems like we really have to know the password to decrypt the text. But what is the password? I thought this was a scam? Until know, the password doesn't seem to get sent to some 3rd-party server. Only the right password decrypts something else (or I'm failing to decrypt the code and it does something else)


AVG detects Kaspersky update files as infected (trojan, infected, malware) (Note: update at end of Q)

On a Mac, I am using AVG as the primary AV. In addition to this, I have a few scanners (Bitdefender and Malwarebytes) that I update and use periodically. Recently I decided to add Kaspersky's free scanner (from the App Store) to this list as well.

Oddly enough, when I was updating the recently installed Kaspersky, AVG complained about a couple of items:

/Users/UN/Library/Containers/com.kaspersky.kvs.agent/Data/Library/Application
Support/KVS/Data/temp/temporaryFolder/updates/kdb/i386/base008.kdc
/Users/UN/Library/Containers/com.kaspersky.kvs.agent/Data/Library/ApplicationSupport/KVS/Data/temp/temporaryFolder/updates/kdb/i386/base005.kdc
/Users/UN/Library/Containers/com.kaspersky.kvs.agent/Data/Library/Application
Support/KVS/Data/temp/temporaryFolder/updates/kdb/i386/base004.kdc

Looking into it quickly, one seems to be a trojan and the other an infected iframe and the third seems to be, as described by Microsoft, a malware that attaches itself to other programs

Not surprisingly I am rather concerned. Is Kaspersky unreliable (keeping in mind recent rumors)? Are these false positives? Is my computer already compromised? And most importantly, what do you knowledgeable folks suggest I do now? The KDC file types that were caught by AVG do not seem amenable to inspection by a non-specialist user.

Update:

So, I uninstalled Kaspersky, just to be sure there's only one resident AV, and avoid these conflicts. And I also replaced AVG with Avast (I'm well aware the former is owned by the latter). A full system scan by the new Avast also popped up a nasty courtesy of Kaspersky. It seems this was somehow missed/skipped by AVG:

/Users/yc/Library/Containers/com.kaspersky.kvs.agent/Data/Library/Application Support/KVS/Bases/Cache/kavbase.21d72e24d923846c.kmc

Disregarding the issue of one AV complaining about the other, seems very odd there are lingering base files even after uninstalling Kaspersky and rebooting the system.

Even more interesting oddities:
The file caught by Avast seems to exist in the Mac Finder (on right clicking in the AV window and doing show in Finder) but not when I try to find it in the terminal. Doing >file /path/to/directory/of/infected/file/ says there's no such file or directory. But doing "Go to the folder" with the same pathname works just fine.

(I'm also very curious how one can achieve this - get a directory invisible in Terminal even with sudo ls but visible in Finder!! But that's probably a Q for a different site.)

They are false positives. Usually, is not a good idea to have two different AV software installed. One can block other as is your case.

In your case, concretely, it seems it's blocking database files. Maybe it has some known virus pattern. Of course, any AV has itself and its files as exception on detection but it is not know for other AV software and that's the reason why is detected as malware.


Where does the WPS Pin fit into the 4-way-handshake? So I found a diagram online, that shows the 4-way-handshake:

The way I understand it, when a station (STA) is trying to authenticate to an access point (AP), the AP sends the ANonce (authentication number, once). Then the handshake continues..

What I'm struggling to see, is where WPS comes into play? When you enter a WPS pin into your cell phone or laptop, where does that kick in? Does that kick off the 4-way-handshake? Or does this skip the 4-way handshake?

Thanks.

WPS is used only once, to exchange the actual PSK key.  The 4-way handshake you've posted is used for key exchange at the beginning of each connection, while WPS is only used to transfer the configuration.

WPS uses a series of 8 packets that are sent under a separate DH key exchange, and are not encrypted under WPA.  There's a great description inside this paper by Viehbock on attacking WPA.


Is it possible to bypass USB access restriction placed by the Active Directory? I've been tasked with an onsite engagement to see what I can find from one of their laptops. They have a policy in place to block USB access through the Active Directory, e.g. When you try to access the USB drive, you will get an access denied, see here for more information.

Is there any way to bypass this? Will tools like Bash Bunny still execute the payload, regardless if I can access it or not?

If you can plug a keyboard in and it works, you can use a tool like a Rubber Ducky (I'm assuming the bash bunny is similar, but I haven't played with it.) The Rubber Ducky appears to the computer as a Human Interface Device (HID). Keyboards announce themselves to computers as HID devices and are in turn automatically recognized and accepted.


Confusion over a firewall and proxy A proxy usually controls HTTP(S) traffic going outbound. IE it can be blocked, and so forth. How is this different to a firewall working on port 80/443?

Also, if a firewall is to control outbound http(s) traffic, how can it block ads? Would that not be a reverse proxy?

I would recommend doing a little reading on the OSI model. It might help shed a little light on this, but I will give you a brief overview so this makes more sense. Remember that these concepts can blend together and a firewall could have all of these features.

A traditional network firewall operates at layer 3 and layer 4 of the OSI model, which is IP addressing/ICMP and TCP/UDP. In its simplest sense, it's a hierarchical rule chain that blocks or allows specific packets which match a specific criteria. This type of firewall implementation has little to no awareness of "higher" layers of the OSI model.

An application proxy is typically said to exist at layer 7 of the OSI model, the application layer. These proxies must understand the protocols that they proxy, such as HTTP. A firewall can often have these features as well. A web proxy, with its awareness of web protocols, can have content filtering features which could filter ads. A device or software package described as a firewall could have these features. These are typically called application firewalls or layer 7 firewalls.