How to insert custom packets into SSL handshake? I am trying to communicate with an SSL server whose protocol is non-standard.  I want to insert custom packets into the handshake.  I am using several SSL tools, so changing source code on every tool is a lot of work.  Prefer to have a network filter which will modify (insert a custom packet) into every SSL handshake.

Tried netsed.  No go.  It can modify existing packets, but not insert a new packet.

Tried ncat.  No go.  It can insert a packet, but when we launch SSL tool, a second TCP session is set up.  Tried many variations.  This is the root of the problem:  how can I insert packets into the middle of an SSL handshake session (without starting a separate TCP session)?

In a SSL handshake, the client and the server exchange handshake messages which are encoded in records. If your protocol variant consists in additional handshake messages then you have a problem: at the end of the handshake, two Finished messages are exchanged, and their contents are computed as a hash function over all previous handshake messages, therefore including your extra messages. Corollary: if you have extra handshake messages to insert, you MUST modify the SSL client tool, because that tool computes the hash and will compute a wrong value if it is not aware of your extra messages.

If your protocol variant consists in extra records of a type distinct from "record for handshake messages" (type 22 in the standard), and such that the extra records do not impact the computations of the handshake, then your filter strategy might work. You would have to:

Intercept connections; there are several ways for that, but the simplest is to change the configuration and/or DNS so that the source machine connects not to the target server, but to a server of your own, which itself connects to the rightful server, and relays data in both direction.
Parse the data so that you detect the handshake records, to know where and when your extra messages must be added in the flow (and, similarly, extra messages from the server must be analysed and removed, so that the SSL client tool does not choke on them).

So you are in for some programming. The record protocol of SSL is not complex, as long as you fiddle with the unencrypted records (those before the completion of the handshake); see the section 6 of the standard. Also, see this answer for a detailed introduction on the protocol (which I believe to be easier to read than the standard). For the relaying, the simplest implementation strategy would probably to launch two threads, each thread running in an endless loop of read-from-one-machine-write-to-the-other.


Tracing Proxy Easy or Hard for a Normal Website? I know a membership website which is getting quite popular among people day by day. Now I see people are making more than one accounts by using proxies. They should allow multiple accounts from the same person(As they have no Terms of Service against it.) and it should be ethical to create as much accounts a person wants. But they are blocking the accounts without giving a reason. So people use proxies. Now I wanted to know if there is a way the website can check if a person is using a proxy or not and also can they get his original ip?

Note:

I understand someone with authority can track an ip even if he uses a proxy as the proxy servers keep a record of the real ip but the question is for a normal website which does not have this significant authority.

It depends somewhat on the proxy. Some proxies will provide a X-Forwarded-For header which provides the IP address of the system that made the request via the proxy.

Other proxies, especially those that specifically offer anonymous browsing are unlikely to provide any direct information about the source of the request.

Beyond that basic point, there's a number of potential means that the site could use to determine users who are creating multiple accounts.  Whether they would largely depends on the type of site and how keen they are to prevent it.  Some options would be

Browser Fingerprinting.  Essentially the specific combination of version information visible to the server can sometimes be used to identify specific users.
Rich clients.  If the site downloads something like a Java applet they could use that to try and determine the Internet IP address of the user.

Of course all this depends on how they're preventing a user having multiple accounts.  From what you're saying they're basing it on source IP address, which is not a great solution as a lot of users use proxies in the general run of things (eg, browsing from a company network), so it would fail for them.


ssh-keygen: How is the seed generated? How is the seed for ssh-keygen generated?  I expect it will take information from /dev/random and request supplementation with system activity if we have insufficient random bits.

An Instructor made these claims which I find suspect.  Can you assist in linking documentation to show them either true or false?

"When local keys are built by a user for rsa/dsa/ecdsa encryption types.  It builds it using and embedding as a seed some of the key information privately from the system.  So in building the private key for rsa it will use ssh_host_rsa_key, username, MAC Address, and /dev/random as a seed for the local private key for the user."

=====

Reading the man page for ssh-keygen does not go into this detail.

Some odd things are used for seeding key-generation.  For example, the process ID was shown to be the only somewhat random element in the Debian barely random key gen scandal.  I find it odd that the process id was used at all.

LPIC Level 1 Exam2
Lecture: System RSA/DSA Keys

So in building the private key for rsa it will use ssh_host_rsa_key, username, MAC Address, and /dev/random as a seed for my local private key for the user."

No. It is not true. The private key is generated only based some bytes from /dev/random, which are formed into the private key inside OpenSSL.

Host keys are not used, because normal user who generates the keys do not have an access to them. username and hostname are stored only in a comment of the public key (default behavior, but can be changed) and MAC address is not used (at least not in the OpenSSH), as you can find out in the OpenSSH source code.

Not sure how "Debian barely random key gen scandal" is related to this. It was a bug in OpenSSL, which limited the possible keys. It affected OpenSSH, because it is using OpenSSL for crypto operations and random data source.


security implications of NULL dereference Suppose we have code like this:

struct somedata {
   int a;
   int b;
};
struct somedata *data;
/* ... */
data = malloc(sizeof(struct somedata));
data->a = something;

Now, as you can see, NULL pointer check is missing. The question is - does this have security implications in case malloc fails? Let's assume the process exiting on SEGV by itself is not a problem in this case. Is there any other way this can be trouble from security standpoint?
The application containing this code is not SUID or having any elevated privileges, but does process external input, so some parts of its memory can be user-controlled.

P.S. I am aware of CWE-476 but there the security implications are described in a very vague way ("In very rare circumstances and environments, code execution is possible" - which circumstances? which environments? How rare - meteor-hitting-you-in-the-head rare or once-a-year rare?) and I'd like to see some more specific info on what the threat is.

"The process exiting on SEGV by itself is not a problem in this case": this is already a large assumption. Whatever the process was doing will not be finished; the caller gets an error code; if the process had created temporary files then those files do not get erased. Making sure that there really is no problem is tricky.

Also, what creates the SEGV is the access to a memory area which the operating system has deliberately marked as invalid; namely, the first "page" of the address space (a page being 4096 bytes on a PC). Consider the following:

data = malloc(1000000 * sizeof(struct somedata));
data[800000].a = something;

If struct somedata has length 8 bytes, and the allocation fails, then the code will try to write something at address +6400000. Even if the OS did not map the first 4096 bytes, it is quite possible that the address 6400000 is valid and used for something else, which gets silently overwritten. At that point, anything goes. There again, knowing whether a given NULL returned by malloc() would imply immediate segfault or silent corruption can be difficult.

If the process has no special rights and the attacker already has the power to run executable files with the same privileges, then not checking the value returned by malloc() does not uncover new security issues. It is just sloppy.


What leaked mass surveillance capabilities have not been explained by vulnerabilities we have learned about since 2014? At the end of 2014, there were reports and talks about the cracking capabilities of the NSA and other Five Eyes agencies, based on documents leaked by Edward Snowden.  The analyzed data revealed that, e.g. VPNs and HTTPS connections were decrypted routinely, while OTR and PGP apparently were resistant to any attacks.

The leaked documents were sometimes a few years old. Numerous vulnerabilities have become public knowledge in the last years, the Juniper router backdoors being a prominent example. Is there any leaked data which, as today, cannot be explained using public knowledge of known vulnerabilities?

I did some more research to come up with an own (quite possibly incomplete and/or wrong) answer.  This is a community wiki answer. Edits or separate answers are more than welcome.
TL;DR: Almost all mass-decryption capabilities can easily be explained using publicly known vulnerabilities, attacks against SSH being a possible exception.
The NSA BULLRUN program is the central part behind the Five-Eyes decryption capabilities. According to this presentation by the OTP VPN Exploitation Team, cryptoanalytic attacks where available against at least IPSec, SSL, PPTP, and SSH.  The leaked documents don't always contain a date, but it seems safe to assume that none are newer than 2012.  Newly introduced vulnerabilities like Heartbeat, which was widely deployed starting autumn 2012, are therefor not a sufficient explanation.

IPSec: The Logjam authors speculate that the Diffie-Hellman key exchange may have been broken by nation-state attackers using a precomputation attack.  This would have enabled agencies to attack the majority of potential targets, as many sites used the same Oakley group 1 parameters.  The SLOTH transcript collision attack is another likely explanation, as MD5 was still widely used back then.

SSL: The mentioned transcript collision and DH-Kx attacks are also possible (and possibly even simpler) on SSL connections.  Furthermore, numerous SSL/TLS vulnerabilities have become public knowledge in the early 2010s. This includes FREAK (resembles Logjam), BEAST, BREACH, and POODLE as well as attacks against the RC4 cipher.  According to SSL Pulse by the Trustworthy Internet Movement, close to 100% of all sites supported SSLv3 in mid 2012.  Routine decryption of SSL traffic is probably the least surprising in hindsight.

PPTP: Quoting Wikipedia:

Serious security vulnerabilities have been found in the protocol. The known vulnerabilities relate to the underlying PPP authentication protocols used, the design of the MPPE protocol as well as the integration between MPPE and PPP authentication for session key establishment.

SSH: The SLOTH attack also works against SSH, though the authors consider the attack impractical due to it's still very high computational cost.  DH-Kx attacks might be possible as well or could be combined with transcript collision attacks, though I'm not aware of any work that has demonstrated the feasibility of any of this.

The cryptoanalytic capabilities may have been known to the mentioned agencies well before being published in the unclassified literature.
Non-cryptoanalytic attacks may have contributed as well, e.g. backdoors or remote code execution on networking gear serve as a perfectly fine explanation.  This would have made it simple to extract encryption keys for any protocol from the affected devices, rendering attacks on those protocols trivial.


I obfuscated my commercial software, i lost source I obfuscated my web software with srcProtector and I archived files, I uploaded a new version of the software on the website.
The problem is I forgot to copy files in a new path for backup.
VERY VERY BAD!
Code looks like:

I tried already unPHP.
(is there any winscp undo button (reconnect session) or any deobfuscator for this?)

Hopefully you've learned a valuable lesson about the importance of source control, and backups in general. I'm sorry it happened this way.

Obfuscators are just speed bumps. The only info that is actually lost is stuff like comments; everything else is just made hard to read. For example, all your strings got base64 encoded, which is trivial to reverse. The names of those string variables/constants appear to themselves have been encoded and stored in a lookup table; you should be able to reverse that too. Some names that were internally-scoped only are probably lost, but you should be able to figure them out from context and memory.

There may exist tools to automate some of the above steps. Alternatively, you might have to write one. A relatively short python script could recover all the $GLOBALS assignments in your screenshot, for example (you could do it in any language, python is just a convenient balance of power and ease-of-use). Assuming the obfuscator did anything worse than just hide the names of stuff, you might have to do some actual work picking apart the logic in the obfuscated functions, but unless you're implementing anything super complicated (advanced math, handling binary data formats, etc.) it should be pretty easy.

Technically off-topic and just out of curiosity, why are you obfuscating PHP source? If you're just uploading it to your own server, all you're doing is wasting CPU cycles. If you distribute the source to third parties (such as customers), I suppose you could say some obfuscation makes sense, but generally you just solve that with copyright law unless your software actually contains genuine trade secrets that others don't know how to do and would find worth the effort of reading your code to figure out. If that's the case, then obfuscation is "better" than nothing, but - as mentioned at the top - it's just a speedbump.

Also, especially if you aren't using source control, you shouldn't be obfuscating files in place. Create a new destination path for the modified files, don't overwrite the originals.


Benefits of cloud based full disk encryption Microsoft announced in May that it supported full disk encryption for VMs. They have recently merged a github branch into the Azure Powershell tools to enable this.
The basic theory is that you store encryption keys in an Azure Key Vault HSM, point the VM to it, it retrieves its keys, unlocks the disk and you're away.
However I am not entirely sure what this is protecting me from! The only case I can think of is that somebody obtains my blob storage credentials and uses them to download the VM disk (or someone infiltrates the underlying blob storage infrastructure - this seems unlikely) I can't imagine that this would offer any protection against any sort of law enforcement request as Microsoft own the hardware that contains my key and so would be able to hand over the whole thing.
What is the attack vector that cloud based full disk encryption protects me against? (what am I missing!)
*note this is not specifically an Azure question, as the answer should apply to all cloud vendors.

You aren't missing anything technically, full disk encryption protects you from disk theft, improper disk disposal, or unauthorized access to the virtual container.

The point I'd make to you is that if your data is valuable to your organization it's probably valuable to somebody else. You also have a duty of care to protect customer details any sensitive information as best you can. Infiltration or disk theft as an attack against your data may unlikely but it's not impossible, and the impact if it does happen could be catastrophic, especially if you haven't been seen to make every effort you can to prevent it. Disk encryption is part of a defense in depth strategy to protect your data. It's not going to protect you from governments, but that's probably not who you have to worry about.


Is Deluge safe to use still when it's not been updated since the first part of 2017? https://dev.deluge-torrent.org/wiki/Download
https://ftp.osuosl.org/pub/deluge/windows/?C=M;O=D
The latest version of Deluge for Windows that can actually be downloaded and installed is deluge-1.3.15-win32-py2.7.exe from 2017-05-12.
That's well over three years ago now!
They have been discussing the problems of releasing the new version for years, but nothing comes from it. Like so many slowly dying (but never quite gone) projects I've painfully witnessed in the last many years.
Doesn't this more than likely make it extremely unsafe for me to be running this software on my machine? I feel as if it's an open door to my machine, almost certainly containing unpatched exploits.
Yet the sad reality is that there are no alternatives. uTorrent is an ad-infested spyware nightmare since many years, and others... well, just like with browsers, I've given up on searching because there's just nothing out there. Nobody seems to care one bit about the entirely desktop computer anymore.
Can I still use this ancient software? If so, how much longer?

A simple test is to check exploit-db.com for vulnerabilities in this software:

In the case of deluge 1.3.15, there are two Denial of Service vulnerabilities, but no others listed.  Depending on the requirements of the server you'd like to run this on, that may be an acceptable risk.
To be clear, this is only a limitation if running on Windows or MacOS.  Packages for the newest version, 2.0.3 (2019-06), are available for multiple variants of Linux.


Reliable Sources for Software Vulnerability Patch Release dates I have searched in NVD and realized that patch release dates are not published with the specific vulnerability information of an application.

Other information like the "update date" do not necessarily map to the day a patch is released.

Can someone give me some direction on the appropriate place where I can easily get reliable information about the date of patch releases ?

After some research, I realised that the NVD does not publish all data about disclosed vulnerabilities since they opine that specific software vendors should have the most reliable information. Hence, patch release dates are available in the bug tracking repository of the vendors for example for OpenStack, such information is available in their Launchpad repositories.


Full disk encryption and remote unlocking a mail server in the hand of a possible attacker, what could go wrong? Since I cannot receive email directly from my home server, I need an external device to receive messages for me and deliver them to my MTA via another port or via VPN. Instead of renting a VPS just for this, I was thinking about purchasing an unexpensive ARM board and deploying it to one of my friend's house, which has a static IP and can receive email from the outside (no port 25 blocked by his ISP).
I would encrypt the root partition, allowing remote unlocking via VPN and SSH intramfs. I would save the SSH fingerprint locally before giving the machine to him.
Of course I trust him, but what could he possibly do?
Things that come to mind, from the easiest to the most difficult:

He could wipe the SD card, but of course I would notice it
He could forward the external port 25 of its router to his rogue mail server, but could he read my email?
E.G. by responding to STARTTLS requests saying that no encryption is available, or offering them a self-signed certificate for mail.example.org, while the official CA-issued certificate for mail.example.org is stored in the encrypted partition.
If yes, is there a way to tell external MTA to only deliver through Submissions (AKA SMTPS, usually sender->MTA on port 465), or at least veryfing the issue of the certificate (CAA record, trusted CA...) and eventually alerting me of such a spoof?
Can he read the wireguard intramfs configuration? If so he could use the peer key to connect to VPN
Can he add his SSH key to tinyssh, or they have to be added with mkinitcpio? Is it useless or he could install something that leaks the passphrase once I enter it?
Can he brute force local TTY login when the machine is powered on? How could I prevent this, either disablying local login or rate limiting login attempts? What software could he use (E.G. hydra for http-basic auth)
Is there a way to protect from cold boot attacks?
Other paranoid things I'm missing?

I'm 100% sure none of this will happen, it's just a theoretical exercise

Ten immutable Laws of Security, Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.
You are susceptible to the Evil Maid Attack.
He has the SD Card, he can clone it, change the initrd to log LUKS password, and with the LUKS password in hand it's game over. Shutdown your Pi, clone the card, replace the initrd, say there was a power outage here, and as soon as you send the key remotely, he has too. Another "power outage" and all your binaries are backdoored, or there's another root user, or a suid bash somewhere.

He could forward the external port 25 of its router to his rogue mail server, but could he read my email?

He now has the certificate, he can forward the emails to his own server, save a copy, send it back to your server. You cannot detect this, because he is using your certificate.
He can setup a proxy that does a reverse lookup on every connection to the port 25, checks if it's from a MX record, and says "TLS not implemented" and saves everything before sending data to your server. If you try to connect, he passes straight to your daemon, so if you test it from any non-MX IP, it will show you the correct certificate. He can even create a list with the largest SMTP sending services (major email providers, major list services, and so on) and sniff only those.

Can he read the wireguard initramfs configuration? If so he could use the peer key to connect to VPN

He can. He now has the LUKS key.

Is there a way to protect from cold boot attacks?

No. He has unrestricted physical access. Pull the plug, every single software protection is dead. The Pi does not have any hardware protection.

Other paranoid things I'm missing?

You cannot protect your Pi. Not even against basic attacks.


Purpose of using base64 encoded urls I have come across a website, freshbooks.com, which uses base64 encoded urls for all purposes, ranging from POSTing sensitive data to a URI or just viewing some resource.

For instance, a url to view an invoice on the website is (some part of url omitted for clarity):

  something.fresbooks.com/dmlld0ludm9pY2VGQjU1Mzc2

When the string dmlld0ludm9pY2VGQjU1Mzc2 is decoded it gives viewInvoiceFB55376

Are there any reasons from security point of view to use URL in such format or just for some programming convenience. The only reason I can think is to prevent some automated tools to extract information about website design. If so, isn't this approach be characterized as security by obscurity?

Base64 can be useful for passing data in URLs when that data includes non-url friendly characters, although even then, there are options.

The structure of what you have decoded actually seems to suggest that the encoded string is a command with parameters, which could suggest an reliance of Base64 for Injection attacks, like @Adnan said.

My best guess is that it's a misguided attempt at strengthening security.


Certificate Transparency logs: why are so many operated by same entities and how do they differ? I'm trying to understand the point of having multiple Certificate Transparency logs. While I understand that it solves the problems of reliability of trust, what baffles me is that so many are operated by the same entity: most notably, Google operates the following:
Google 'Argon2020' log
    \- Cert Count:     872098511
Google 'Argon2021' log
    \- Cert Count:     88502501
Google 'Argon2022' log
    \- Cert Count:     2790673
Google 'Argon2023' log
    \- Cert Count:     6392
Google 'Xenon2020' log
    \- Cert Count:     904142660
Google 'Xenon2021' log
    \- Cert Count:     68113254
Google 'Xenon2022' log
    \- Cert Count:     7243881
Google 'Xenon2023' log
    \- Cert Count:     6370
Google 'Aviator' log
    \- Cert Count:     46466471
Google 'Icarus' log
    \- Cert Count:     762271779
Google 'Pilot' log
    \- Cert Count:     1077198088
Google 'Rocketeer' log
    \- Cert Count:     1102506143
Google 'Skydiver' log
    \- Cert Count:     297801233

Are some of them more important than others?
Why are some split into 202X series and what does the number mean?
Also, I installed axeman and it gave me an overlook on the total sum of certificates in all CT logs: it's around 7 billion.  Do the certificates repeat in different logs or are they all unique?
If they're duplicates, is there a way of deduplicating them when scraping the logs?

Why are some split into 202X series and what does the number mean?

Since certificate transparency logs can grow to include hundreds of millions of certificates, they are often split into separate physical logs (this is called temporal sharding). The number represents the year up till which the log is valid. Certificates are placed in different logs based on their expiration date.
Apart from Argon and Xenon logs, the other logs seem to be old non-sharded logs and as can be seen, have grown somewhat large. The Aviator log is now read-only and new entries to the rest have been restricted.
According to this document (which is a bit old),

Google runs three geographically diverse CT logs which accept all certificates issued by
CAs accepted by any major browser

So the difference between the Xenon and Argon logs is  probably that they are geographically located in different countries. This is probably so that interference from a single government will not render the entire CT infrastructure unreliable. Other CT log operators possibly do the same


android apk and suid binary Is it correct for me to assume that, there is no way to make an Android app (APK) to run in root privilege by itself (without an external "su" native executable), even when it is using NDK native code?

I ask because I am assuming since Android apps are not native executables, but instead run in the Dalvik runtime.
Hence, there is no way to set "suid bit" on the APK, allowing it to call NDK seteuid(0) and escalate privilege to root?

I'm trying to understand, is that the reason rooted Android device always need the presence of the "su" native executable so that the other app that needs to run some privilege operation can do so by calling something like system() or exec()?

Please feel free to point out if any of my assumption/understanding is incorrect.

Android assigns different user IDs for each installed application as a privilege separation mechanism.  This can be influenced by the certificate that is used to sign an application (https://source.android.com/security/overview/app-security.html#application-signing) in conjunction with the android:sharedUserId attribute in the application's AndroidManifest.xml file:

  When an application (APK file) is installed onto an Android device, the Package Manager verifies that the APK has been properly signed with the certificate included in that APK. If the certificate (or, more accurately, the public key in the certificate) matches the key used to sign any other APK on the device, the new APK has the option to specify in the manifest that it will share a UID with the other similarly-signed APKs.

Android applications launched by end users are all spawned from the Zygote process (this is to help speed application launch, since the Zygote can fork and load the application code and not have to reload a bunch of system libraries).  At the time of writing this, the Zygote service configuration looks like this:

  service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
    class main
    socket zygote stream 660 root system
    onrestart write /sys/android_power/request_state wake
    onrestart write /sys/power/state on
    onrestart restart media
    onrestart restart netd
    writepid /dev/cpuset/foreground/tasks

The syntax of this file is outlined here: https://android.googlesource.com/platform/system/core/+/master/init/readme.txt, which has this to say about the privilege levels assigned to services by default (so you can see that by default, Zygote runs as root):

user <username>
  Change to username before exec'ing this service.
  Currently defaults to root.  (??? probably should default to nobody)
  Currently, if your process requires linux capabilities then you cannot use
  this command. You must instead request the capabilities in-process while
  still root, and then drop to your desired uid.

Zygote uses a JNI method named forkAndSpecialize (search for "com_android_internal_os_Zygote.cpp") to handle the platform specific task of calling setuid() to the UID that the Package Manager has assigned based on the manifest and installed applications.  Failing to properly exit if that setuid call failed has been the source of Android privilege escalation vulnerabilities in the past (read up on the RageAgainstTheCage exploit if you are interested, although that was not Zygote related).

This is the main reason that you need a separate privileged/setuid binary to launch applications using root level privileges.  If you built your own custom system image, you could conceivably modify the PackageManager / Zygote to retain the root privileges, but doing so basically breaks the Android security model.


Security errors with printer I ran a security scan using the home version of Nessus by following a post on LifeHacker, and I was told that my printer had two security errors:

OpenSSL 'ChangeCipherSpec' MiTM Vulnerability
SNMP Agent Default Community Name (public)

Seeing as this is a network printer, I cannot set up advanced systems, and turning off SNMP (or changing any settings) is no longer an option in its online config menu.

I am a total security noob, so I thought I would ask this community whether this endangers my home network, and what I can do about it?

If you cannot disable SNMP protocol can you at least rename the community string and give it a strong password? If so that should suffice.
Regarding the OpenSSL vulnerability that would have to be resolved by the vendor with a firmware update. See if one is available.


Does visiting the localhost with my Tor browser reduce my security? I happen to have Tor open right now, and want to do a quick modification to my website.

Does visiting localhost with Tor reduce the security of that session?

It probably wouldn't work. If you told the Tor exit relay, "I want to go to 127.0.0.1" (that's the IP of localhost), it would try to connect to itself, because that's what that IP means. Unless the exit relay had a web server running, the connection would fail. I wouldn't be surprised if the Tor software checks for loopback IPs and rejects the connection.

It's entirely possible that Tor will just connect you directly to yourself. If that happens, there's no harm done because no traffic leaves your machine. (Unless you're running a malicious deanonymizing site on your computer that sends your IP to shady people.)

If localhost is somehow magically changed into your external IP before being sent through Tor, you're still fine. Unless you've made a firewall rule, configured your web server, and set up portforwarding from your external IP to your computer, the connection will fail. If it did go through, no node on the way would have any idea that you just talked to yourself, since only the entry guard knows the source and only the exit node knows the destination.


MySQL user passwords in PHP How do I prevent exposing MySQL usernames and passwords in PHP code when establishing a connection?

Hanky 웃 Panky brings up good points. However, I'd like to add to them:

You can mitigate damage by restricting connecting accounts by roles. Let's say you only allow searching on your website. Allowing only SELECT statements for that particular account will prevent anything else from running. This doesn't work if you have an account for each: SELECT, UPDATE, INSERT, DELETE, as an attacker could combine the privileges and cause serious damage.
You can also deny anyone except those with appropriate admin access to the website, whose login will likely be independent of the webhost. IP-based deny all, allow from , for example. Note that this won't completely protect you if you've been breached, nor will it protect you if your web host is the one accessing the database.

Only those with root/admin/shell access to your website can obtain the username and passwords, unless you improperly chmodded the files. If any of those are true, you have much bigger issues than having your MySQL user/pass known.


How can a Trusted Platform Module "enhance network security"? I've recently bought a motherboard, which has support for a Trusted Platform Module. On the topic, the manual states the following:

  This connector supports Trusted Platform Module (TPM) system, which can securely store keys, digital certificates, passwords and data. A TMP system also helps enhance network security, protects digital identities and ensures platform integrity.

A copy of the manual can be found here, and the relevant section as an image below:

My question is: Do these clames have any basis in reality or is it all marketing-speak designed to sell people stuff they don't need?

Often the features of a TPM are not easy to leverage for non-programmers.  You could leverage a TPM in order to connect via SSH to a Web server; see a walkthrough guide at https://security.stackexchange.com/a/179422/68088

But average users can see an immediate benefit in encrypting their hard drive, for example with BitLocker. The private key which enables decryption of such an encrypted drive would be stored inside the TPM. The TPM has certain properties such as anti-hammering, isolation of keys and non-exportability which make it highly resistant to remote manipulation.


Is it possible to steal WPA2 key using a rogue AP? Without using a 'fishing' homepage explicitly asking for the user to retype the WPA key. Is it possible to catch the WPA key wich is sent to a rogue AP in the initial connection phase ?

No.  The "WPA key" (actually PSK) is never sent to or from the AP.  The client and server both independently generate the PSK from the passphrase and SSID.  As part of the handshake the client and server will both encrypt data with the PSK and send it to the other entity.  That data is used to create the session key for encrypting all subsequent data between a specific client and AP pair.

The client and server authenticate each other by confirming the handshake data can be decrypted with the expected key.  A rogue AP or client will not be able to do that without already knowing the PSK.  Without the handshake any data sent by an entity without the PSK will not be properly decrypted which is how the counterparty identifies it as invalid.

The behavior on the client would be no different than what happens if the client is using the wrong passphrase.  Now a rogue AP could perform a denial of service attack on the client by preventing the client from establishing a good connection with the real AP.  This is especially true if the rogue AP signal is stronger as measured from the client.


Is there a nmap command to get the top # most common ports? I understand nmap by default scans the top 1k 'most common' ports (-F reduces to 100)
I understand it gets these 'most common' ports based on the nmap-services file, specifically the frequency (3rd column)

Say you're curious or doing port-hardening, you'd be curious what those most common ports are. Short of opening the file & sorting, is there a command to show those ports? Another way that MAY please the desire is a command to show all ports scanned regardless of state (closed/filterd/etc)

Homework I did: did some googling & searching on this site. Quickly read over the nmap documentation. Tried scanning ports & it seems to start grouping (Not shown: 991 closed ports) around 29/30. Found the page below (not enough rep to post links) that seems to elude there was a function (probably in the nmap source) for gettoppts/getpts, then advises of a database sorted_services (maybe that's a file in the nmap directory)

www.bamsoftware.com/wiki/Nmap/TopPortsReview


Android L encryption vs. iOS 8 encryption Recently, the new full-disk encryption system of Apple's iOS 8 operating system has been in the news. And soon after Apple's release, Google announced that they will also enable encryption by default in the upcoming version of their Android operating system.

My question is: From the security perspective, are the two systems similar or different (assuming you use the same password or PIN code)? Precisely how does Android's encryption work under the hood?

In more concrete terms: If I use a random 8-lowercase-letter password, which supposedly takes approx. 265 years to brute-force in the case of iOS devices, how safe am I with a similar setup on an Android phone?

For background on the approach that Apple took with iOS 8, see this document. If I understood this right, the key point seems to be that there is a special piece of tamper-proof hardware that contains a device-specific secret identifier. Supposedly, the only way to retrieve the encryption key is to feed your pin code to this piece of hardware, wait for 80ms, and see what comes out. To brute-force this, you will either have to keep entering PIN codes to this single unique piece of hardware (and each attempt takes 80ms, and you cannot parallelise this, as there is just one such chip in the world), or you will have to also brute-force the identifier (which is very long).

How does this compare to what Google (and Android phone manufacturers) are doing with Android phones?

Currently, Android's device encryption uses dm-crypt and indeed seems to be susceptible to the kind of brute-force attack you mention, because the PIN/password is more or less directly used to derive the key that decrypts the AES key stored in the volume header.

To protect against such brute-force attacks, the password has to be of sufficiently high entropy (just like on desktop encryption systems). Unfortunately, Android does not allow setting a different password for disk decryption and screen lock. This is only a UI limitation, though: It is easily possible to use a strong password for boot-time disk decryption, but this requires root access.

However, this might all change with Android L – nothing is publicly known right now, but there are suggestions that Android will move to a scheme that uses a "trusted" hardware part, like iOS does.

By the way, the iOS hardware key derivation you describe seems to have been replaced by something else for devices using an A7 SoC (or newer). Apple seems to perform (and rate-limit) the PIN/password verification inside the Secure Enclave, which would theoretically be even more secure. From the document you referenced:

  On a device with an A7 or later A-series processor, the key operations are performed
  by the Secure Enclave, which also enforces a 5-second delay between repeated failed
  unlocking requests. This provides a governor against brute-force attacks in addition to
  safeguards enforced by iOS.

You will have to wait for the entire Android L souce code to be released to be sure (and even then, this might be something that will have to be implemented by the device manufacturers), but as of now, some Android devices already support hardware key stores for asymmetric keys; this mechanism seems to be based on ARMs TrustZone exection environment, and might theoretically be extended to device encryption keys, similar to Apple's Secure Enclave concept.


32bits Linux - Simple stack overflow - EIP never overwritten I'm trying to understand how simple stack overflow works (On Linux 32 bits) but I'm in front of a strange problem.

I'm using https://www.pwnerrank.com/tasks/stack-based-buffer-overflow-code-execution to test my code.
Everything works great. My shellcode is perfectly executed, so I think I understand (a little bit) what I'm doing.

BUT, when I'm trying the same thing on my own computer (same code, same GCC options, ASLR off), I'm facing a strange problem. I simply can't overwritte EIP :/

First of all, this is the code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char*argv[])
{
char buffer[256];

if(argc < 2) {
perror("Usage: ./pwnme twitt\n");
return 1;
}

strcpy(buffer,argv[1]);
printf("%s", buffer);

return 0;
}

On the challenge's server, EIP is overwritten (Good news !):

$> lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.6 (jessie)
Release:    8.6
Codename:   jessie

$> uname -a
Linux binary-challenges-pwnerrank-com 3.2.0-4-amd64 #1 SMP Debian 3.2.82-1 x86_64 GNU/Linux

$> file ./pwnme
./pwnme: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.26, BuildID[sha1]=b49c31fc047654c28f93910c8e04cecb6a19ac30, not stripped

$> gdb -q ./pwnme

(gdb) r `python -c 'print "A" * 280'`
[SEGFAULT]

(gdb) i r
eax            0x0  0
ecx            0x0  0
edx            0xf7fc9878   -134440840
ebx            0xf7fc8000   -134447104
esp            0xffffd5e0   0xffffd5e0
ebp            0x41414141   0x41414141
esi            0x0  0
edi            0x0  0
eip            0x41414141   0x41414141
eflags         0x10286  [ PF SF IF RF ]
cs             0x23 35
ss             0x2b 43
ds             0x2b 43
es             0x2b 43
fs             0x0  0
gs             0x63 99
(gdb)

=====================================================================

Now, I'll try on my own Linux (with the same C code):

$> lsb_release -a
No LSB modules are available.
Distributor ID: LinuxMint
Description:    Linux Mint 18 Sarah
Release:    18
Codename:   sarah

$> uname -a
Linux 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Compilation:

$> gcc bof.c -o pwnme -fno-stack-protector -z execstack -m32

ASLR off:

$> $ sudo cat /proc/sys/kernel/randomize_va_space
0

$> file pwnme
pwnme: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=bf0e63dc240cb7a8e72fd656677a2d03a93588ed, not stripped

$ gdb -q ./pwnme
Reading symbols from ./pwnme...(no debugging symbols found)...done.
(gdb) r `python -c 'print "A" * 280'`
Starting program: /home/n3r0x/Documents/BoF/pwnme `python -c 'print "A" * 280'`

Program received signal SIGSEGV, Segmentation fault.
0x080484db in main ()
(gdb) i r
eax            0x0  0
ecx            0x41414141   1094795585
edx            0xf7fac870   -134559632
ebx            0x0  0
esp            0x4141413d   0x4141413d
ebp            0x41414141   0x41414141
esi            0xf7fab000   -134565888
edi            0xf7fab000   -134565888
eip            0x80484db    0x80484db <main+112>
eflags         0x10286  [ PF SF IF RF ]
cs             0x23 35
ss             0x2b 43
ds             0x2b 43
es             0x2b 43
fs             0x0  0
gs             0x63 99
(gdb)

As you can see, this time, only EBP is overwritten. And I don't understand why :/ Maybe an other security feature somewhere ? Do you have an idea ? And off course, if I replace 280 'A' by 300 or more 'A', it's the same thing.

Thank a lot :)

[EDIT] - Sorry, I found the answer on this forum. It was just a question of stack alignment. Everything is here: Compiling a buffer overflow example in modern Linux?

I moved the strcpy on a different function, it works great. And the last reply gives a good explanation.

Thanks for you help !

This difference might be there due to different stack alignment used on the server side. For setting up the stack alignment, "mpreferred-stack-boundary" option is used.
More:
https://stackoverflow.com/questions/10251203/gcc-mpreferred-stack-boundary-option

Hope this helps!


Is Certification path construction algorithm needed for SSL/TLS? In the TLS Handshake a Certificate message is sent. This message contains the (chain of) certificates needed to validate the provided certificate of the communicating party.

However, I have also read some papers, and also defined in RFC5280, that the certification path process is challenging; and, an algorithm is needed to actually do the path construction.

This confused me, since during the TLS Handshake the chain of trust is provided in the Certificate message. Therefore I was wondering: Is a Certification path algorithm also needed in the TLS protocol?

If so, why is it needed? As far that I know, the Certificate message sends all the certificates in the chain of trust.
If not, is it true then that the Certificate message does not (always) provide all the certificates in the chain? Or maybe, does the certification path algorithm not apply at all for SSL/TLS; but for what kind of protocols is it needed then?

The algorithm is used on the Certificate chain in order to verify it - it would be a terrible idea to trust any received certificate [chain] without verification, wouldn't it?


What sort of mathematical background is necessary to learn ethical hacking? Do I need to be a "mathematical whiz" to be a hacker?

Do you need it to just run hacking attacks or simple social engineering?  No math is needed.

However, if you want to be an expert and really understand modern cryptography, you'll need to learn some rather advanced/obscure math like modular arithmetic, Fermat little's theorem, discrete logarithms, etc.  You don't need to understand cryptography to use it, but if you want to implement it, or search an implementation for flaws/vulnerabilities, you'll need to understand it.  Have a look at Handbook of Applied Cryptography and you'll see there's a fair amount of math, that likely is unfamiliar to you.

Say you know that all passwords in a system are comprised of 12 random characters (case-sensitive including special characters) (and some salt) and you have the salt+hash, and want to break it with a GPU that generates a billion hashes per second.  Is it worth trying to break?  What about if passwords were 6 random characters?  The answer from basic probability/counting/conversions is don't try with the first one (should take million years); but the second should be trivial to crack (done in under 5 minutes)?  Some security algorithms (like Microsoft's LM-HASH ) didn't recognize this basic fact that two N/2-length passwords could be cracked in ~10 minutes while one N-length password may take a million years.

Its hard to say a priori what you don't need to know; as sometimes understanding something can help tremendously,  see relevant (and today's) xkcd.  Math is also great at just teaching you to think very logically; sort of like how doing a push-up isn't very useful on its own -- but being in shape/strong from doing push-ups is quite useful.


Can't get rid of “Your connection to website is encrypted with obsolete cryptography” In my Nginx config I have:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

But on Chrome cert icon, I still get the "Your connection to website is encrypted with obsolete cryptography" message. Any suggestions on what to do to get rid of this message?

These ciphers are old:

DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DHE-DSS-AES256-SHA256:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DHE-DSS-AES128-SHA:DHE-DSS-CAMELLIA256-SHA:CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA

The fastest way to get rid of them is to append to ciphersuite this:

!EDH-DSS:!SRP

Also, do not forget to define your own DH parameters or all connections with DHE- ciphers are weak!

If you want to have very good security, you can use this cipher suite, as it is:

EECDH+ECDSA+AESGCM:EECDH+ECDSA+AES256:EECDH+ECDSA+AES:EECDH+AESGCM:EECDH+AES256:EECDH+AES:EDH+AESGCM:EDH+AES256:EDH+AES:EECDH+ECDSA+3DES:EECDH+3DES:EDH+3DES:RSA+AESGCM:RSA+AES256:RSA+AES:RSA+3DES:!NULL:!RC4:!EDH+DSS:!MD5


How do FIDO keys prevent MITM reflection attacks? FIDO keys, used for 2 factor authentication are based on a challenge-response mechanism.

Besides generating a common 1-time-key using diffie-hellman, or transferring all data over TLS, how can they prevent reflection attacks?

Challenge: Alice -> Eve -> Bob

Response (even if encrypted): Bob -> Eve -> Alice

Eve <-> Alice initiates a secure connection.

If you're not using TLS, FIDO keys (WebAuthn or U2F) aren't going to do you much good. In fact, the spec requires that browsers only expose the API in secure contexts:

  The client facilitates these security measures by providing the Relying Party's origin and RP ID to the authenticator for each operation. Since this is an integral part of the WebAuthn security model, user agents only expose this API to callers in secure contexts.

WebAuthn and U2F are authentication protocols, establishing a secure connection is outside their scope. If the user's connection isn't encrypted, if the cipher suite being used is broken, or if the user trusts a MitM's certificate, it's game over.


How to disable email for a subdomain without using SPF I am working on a tool that checks SPF records, and would like a way to be able to disable email from a testing subdomain, and its children, so that my test domains are not easy targets for spammers to send from.

I was planning on setting up the domains like this:

example.com - My personal domain
badspf.example.com - A subdomain that should never send emails
*.badspf.example.com - Different broken / dangerous SPF records

I was thinking of using DMARC to block any unsigned emails at badspf.example.com, and then add no DKIM keys, but I do not know how well this would work in the real world.

Is there a better way to do this, and are there any issues with the way suggested above?

I have a possible solution for you. As RFC 7208, Section 4.6.4 states:

  Some mechanisms and modifiers (collectively, "terms") cause DNS
  queries at the time of evaluation, and some do not.  The following
  terms cause DNS queries: the "include", "a", "mx", "ptr", and
  "exists" mechanisms, and the "redirect" modifier.  SPF
  implementations MUST limit the total number of those terms to 10
  during SPF evaluation, to avoid unreasonable load on the DNS.  If
  this limit is exceeded, the implementation MUST return "permerror".
  The other terms -- the "all", "ip4", and "ip6" mechanisms, and the
  "exp" modifier -- do not cause DNS queries at the time of SPF
  evaluation (the "exp" modifier only causes a lookup at a later time),
  and their use is not subject to this limit.

  When evaluating the "mx" mechanism, the number of "MX" resource
  records queried is included in the overall limit of 10 mechanisms/
  modifiers that cause DNS lookups as described above.  In addition to
  that limit, the evaluation of each "MX" record MUST NOT result in...

You could make sure you put enough includes and other DNS overhead in your dangerous SPF record to make sure it fails the 10 DNS lookup standard. add the MX directive and throw in the includes for services (Google, Salesforce) until your SPF record fails SPF Survey for exceeding 10 DNS lookups. Your dangerous SPF record will then look valid but it will fail for a reason that most people don't know about, thus both SPF and DKIM will fail.

Providing I understood your question correctly, this should yield the result you want. Is this the sort of solution you were looking for or did I misunderstand something?


Is it a security defect to display the secure api_key in travis.yml file of source code of a web application in Github I have been working on a code review of a project. The source code is publicly available on Github.

I came across a file "travis.yml". In that file, I am able to see the secure api_key as shown in the screenshot.

I strongly believe that it is a security defect. However, I cannot prove that because I am not sure how an attacker can use that api_key.

Hence please let me know if it is a security defect and necessary justification to prove that. I have blurred few details in the screenshot because of security reasons.

By publicly announcing your API keys - including the associated email address! - you give (ab)users the chance to pose as the legit developer and misuse the API in question. This might lead to you being banned from using the API, damage your reputation or other more serious problems depending on the API in question.

GitHub themselves wrote a blog post about that issue in 2013.


Is it possible to securely store passwords using reversible encryption? Everyone says that you need to use a non-reversible hash when you store passwords so that even if your database is leaked, the passwords themselves are still safe. I'm wondering if there is anyway to use reversible encryption to store passwords.

At the very least, you would need to require that any exploit that leaks the database (SQL injection, server shell access, etc.) doesn't leak the encryption key and that it would not reasonably be possible to figure out the encryption key using a known plaintext password if you have the leaked database.

I'm not seriously considering doing this because it seems like even if it's technically possible it would be hard to do correctly, but it seems like an interesting problem.

Reversible encryption is not commonly used for passwords because the specific requirements and parameters of password authentication are incompatible with the weakness of reversible encryption.

The primary weakness of reversible encryption is simple: if the key is compromised, the encrypted data is compromised, period.

Passwords are used all the time, whenever users log in.  Therefore, the authenticating process must be able to access the users' credentials all the time, in an automated fashion, without obstructive controls.  That means that the key for reversible encryption needs to be on disk or in memory all the time.  If that program, disk, or memory are somehow compromised, then all those reversibly encrypted passwords are all compromised in one fell swoop.

In contrast, consider the use of non-reversible hashes.  If the program, disk, or memory are compromised then the attacker gets the "locked" hashes, and there is no key.  They can then attack further - known ciphertext attack, brute force, etc - but they haven't "won" yet.

We do use reversible (let me say keyed) encryption all the time - disks, files, email attachments.  What these uses all have in common, though, is that they encourage (if not require) human intervention to provide the key.

I'm not sure why you're asking about this, but what about a hybrid model?  Consider that it might be reasonable to store both reversible and non-reversible ciphertext for user passwords.  When passwords are created, store two enciphered versions: One created with a one-way hashing function, and the other created with an asymmetric encryption algorithm ("public key cryptography"). All automated authentication processes use the non-reversible hashes for authentication purposes.  Keep the "public key" half of the pair on the system for use generating the enciphered passwords, and store the "private key" half of the pair offline.  In the event the password plaintext is needed, take the encrypted password offline and decrypt it with the appropriate key.  As long as the decrypting key is not accessible to the authentication system, then an attacker cannot take advantage of the fact that you used "reversible" encryption to store plaintext passwords.

That'll only help if your need for accessing the plaintext passwords is not an automated need, of course.  But it seems like a nifty idea to me.


Before visiting Facebook two cookies got created(fr and sb) I have cleared all the cookies on my Chrome browser, closed the browser and opened Chrome, navigated to chrome://settings/siteData
I see two new Facebook fr and sb cookies created right away, before visiting Facebook. How did these two cookies get created?

Take a look at chrome://settings/content/notifications. If notifications from Facebook are allowed (you find https://www.facebook.com:443 on the Allow list), your browser will connect Facebook in the background to get new notifications. This feature may add some cookies even before you have (wittingly) accessed any pages.


List of social engineering hacks and defenses Sorry if this question is absolutely stupid or irrelevant, but I can't help but ask.

I am just curious about different approaches hackers take in social engineering attacks, and clever examples of each one of the approaches that one can take. And what kind of defenses and strategies that companies might employ in order to prevent such attacks.

If someone can at least suggest a book where to read about the attacks that would suffice too. I recently got very interested in techniques just because it seems like social engineering attacks sometimes require higher level of creativity than actual software hacks.

Thanks to anyone for their input :)

EDIT:
I simply would like to know about different strategies employed. Like for example would someone try calling? And if so calling and saying what? Or will someone go to the company in person to try to get access? And if so what will they do to try to get in?
I know the answer might be big, that is why I just want to know about very basic parts of human conscience hackers might try to exploit in order to get what they want. And what companies might do in order to prevent such attacks.

The book and methods mentioned in This Thread cover a lot of social engineering techniques. The book is written by Kevin Mitnick, a renowned hacker who now shares his expertise.

The book is pretty dated now, but because social engineering relies on human nature a lot of it is still relevant. This Book is also worth reading, and is more up-to-date, but the basic ideas remain the same.


Public key distribution through a file sharing service Would you trust a reputedly secure file sharing service for public key distribution? In my context, I cannot use certificates. Key servers seem to require PGP/GPG formats yet I'm using Microsoft CngKey format in my app, hence this question.

Yes and No

You could print your public key on a billboard in the middle of New York and it would not cause you any problems, however, no one would be able to verify that the billboard in question was actually your doing. Further, if someone had write access to that billboard and changed the public key it would cause you headaches.

Something that you might consider is to stash the key in a Github repo owned by you ... this, while not 100% secure, would be far more reputable than a public dropbox link.


How can clicking on a URI infect a host? I watched a generic information security awareness presentation earlier, in which all that was required for the presenter to penetrate an organisation (with a meterpreter/reverse shell), was for someone on the inside to click, or type (or otherwise GET / HTTP/1.1), and access his public URI.

Is this realistic? Surely whatever exploit and payload was used, must require more manual execution than that, right?

was for someone on the inside to click, or type (or otherwise GET / HTTP/1.1), and access his public URI.
Is this realistic? Surely whatever exploit and payload was used, must require more manual execution than that, right?

There is a phrasing ambiguity in this. "Is a GET enough"? -- no, of course. But is clicking a link, with a vulnerable browser, enough? It is.
It is not the act of GETting a payload that infects the system per se, the problem lies in what is used to do the GETting. That is why you want defense in depth:

proxy "guard" software to stop navigation to unsafe shores (the GET never starts),
firewall/antivirus to recognize the payload and possibly prevent it from calling home and downloading a bigger brother (the GET does not succeed),
continuous system update to ensure vulnerabilities are kept to a minimum (the GET succeeds but has no effects),
IDS to detect suspicious behaviour inside the network (the effects are detected and blocked)
backups.

If the system is not updated and a browser is vulnerable, the targeted URL might recognize the browser and send a tailored payload (which it wouldn't send to, say, a content-detection system or a site scanning service, in order to appear clean). If the vulnerability allows it, the downloaded content might be able to run itself and take control, and possibly download further, less specific malicious code.


Privileged access management vs named accounts What are the relative merits / deficiencies of a Privileged Access Management (PAM) service compared with a strict policy of named users (no account sharing)?

By PAM, I'm specifically referring to devices which act as proxies, identifying the end-user and substituting shared credentials to access a target account, e.g. CyberArk, and NOT applications which merely provide managed access to a set of usernames and passwords.

More specifically, how do the approaches compare for

auditability
resistance to external threat
long term costs (PAM is an obvious quick fix if you're migrating away from using shared accounts)

I don't think it's reasonable to limit the response to a single commercial
product.  Looking at the question more generally:

There are a few basic strategies to control access to high-privileged
access (root, Administrator and the like) on systems:

Create a personal admin account for every human that may ever
need one.  Users may know the passwords to these or they may
be asked to sign into these via a PAM solution.
Have one or a few shared high-privilege accounts and control
access to those with a product such as Cyber-Ark, Hitachi ID
PAM or similar.
Create accounts dynamically and delete them after each use.
Have users sign in with normally unprivileged accounts but
at runtime assign them additional group memberships / privileges.

Personal, named accounts with elevated privileges make sense if:

You only have a limited number of systems and people who need
elevated access.  Imagine a larger IT team with 100 administrators
who need access to 10,000 systems, where systems are onboarded
and retired at a rate of hundreds per day and staff come and go
at least weekly.  The pace of creating/deleting high privilege
personal accounts and managing passwords to those would be cost
prohibitive.
You are OK with password-only authentication.  Most systems either
do not support 2FA or require very complex and possibly fragile
configuration to support login with more than just a password.
Built-in audit logs are adequate.  You don't need to play back
a video of user interaction with a privileged login, for example.

PAM systems can secure personal, named admin accounts by removing
user knowledge of passwords, by randomizing and vaulting passwords,
by introducing 2FA and with good authorization models and audit logs.
They don't eliminate the administrative burden of personal admin
accounts, however.

Some people talk about "Privileged Identity Management" but this
is a really dumb label because these products don't generally
create or delete accounts, they control access to existing
accounts, hence PAM not PIM.
Some PAM products let users request temporary group membership
or temporary SSH trust.  This is true of Hitachi ID PAM, for
example.  This is a nice alternative to password randomization/vaulting
but is mutually exclusive with mandatory session recording.
All PAM products should support some form of 2FA.  The nice thing
here is that you can configure 2FA once - into the PAM system
itself, and from there just launch user logins into the end
system.  Which 2FA technologies are supported should matter less
to any given organization than whether the PAM system supports
the 2FA system that they use or plan on.  Some PAM systems also
bundle a 2FA, in case you don't already have one (again, Hitachi ID
comes to mind, but this is likely going to be increasingly common).
All PAM products should support some form of session recording.
With some, this will be an extra cost item, and with others it's
built-in.  Figure out whether you need this, what kinds of
data streams you care about (keylogging?  video capture?  copy buffer
integration?  etc.) and what it will cost before investing in a
PAM product.
How PAM products launch logins to privileged sessions varies.  There
are a few approaches, each with its own pros and cons, which can
be combined to suit your needs:

Launch an admin tool (MSTSC, PuTTY, vSphere, whatever) on the
authenticated+authorized user's PC, and inject target address and
credentials into it.  This is most flexible and scalable, but it
implies a certain client OS, a network path from the user's device
to the managed endopint and the temporary existence of target
account credentials on the user's device.  Users gain single
sign-on across multiple privileged sessions (just sign into the
PAM portal once) and runtime performance.
VDI to a proxy and then do the above.  This eliminates many
connectivity and OS compatibility problems.
Proxy the connection protocol, and authenticate in-line.  This
means that the range of both authentication options and session
protocols is limited to what the proxy can handle.  Usually you
can support PIN-type authentication with things like RSA tokens
and protocols such as SSH and RDP.  You also tend to concentrate
connections in a few choke-point proxy servers, which can create
performance problems (reduced per-session bandwidth, in some cases
high latency for the full network path).  You also force users
to re-authenticate for every session - a major nuisance.  The
upside is that users continue to sign in with whatever tools they
are used to and credentials never exist on the user's PC.  Caution:
some PAM products only support this model, which is quite
restrictive (Cyber-Ark may be limited in this way).
Proxy the display, not the connection protocol.  Basically launch
an SSH or RDP session from a proxy server to the managed system and
display the session in a browser tab for the user.  Very convenient
for remote access or vendor access scenarios, but has similar
limitations to protocol proxies as above.
Never mind proxies or single sign-on -- either tell the user
the current password value (display or copy buffer integration)
or assign temporary entitlements to the user's existing account.
Note that if the session is not launched by PAM, it may not be
possible to enforce session recording.

The previous poster correctly pointed out that PAM systems offer
additional benefits, including:

Replacing static passwords with regularly changing ones.
Replacing weak password storage (paper, spreadsheets) with something
encrypted, replicated, access controlled, etc.
Replacing embedded passwords used to launch programs or connect to
services with regularly changing passwords, hopefully no longer
stored in plaintext anywhere.


What is the security impact of changing PowerShell's PSLanguageMode? A vendor is asking me to change the PSLanguageMode from within IIS on my Exchange server(s).

What potential vulnerabilities am I opening myself up to?

I'm surprised to see this option present within IIS.  What other locations can I set PSLanguageMode?  (Machine.config, etc)

I would look on MsDN and support.microsoft.com for any IIS vulnerabilities first  since IIS is usually the target du jour for hackers.

Then look for the PS module specifics to check if they are screwed up after a recent update or something esoteric -- I would be wary of Unicode and any of the larger character sets -- have him point you to the KB suggesting the changes and do your due diligence first.


How to route all traffic through Tor? I have Tor setup on my MacBook and I configured my WiFi connection to use Tor's SOCKS Proxy that is running on port 9050.  When I check my connection it confirms I am browsing through Tor.

However, if I try to hit the same URL through my command line using CURL:

curl https://check.torproject.org/

I am informed that my connection is not using Tor.

I had assumed that setting the SOCKS proxy at the system settings level would handle all traffic but this does not appear to be the case.

How can I force all traffic on my machine through Tor?

You need to supply the proxy switch when using curl:

$ curl --proxy [PROTOCOL://]HOST[:PORT]

For system wide proxy usage:

System preferences -> Network -> Proxies

Please be aware that using Tor as a system wide proxy will most likely identify you as a person and is not a good idea if you want to be anonymous.

When for example you start your email client, it is known that you're using Tor by the end point (possibly your ISP or worse: GMail)


Why java.sql.ResultSet.getString is an Information Leakage vulnerability Recently I started using LAPSE+ for static code analysis and it kept on pointing java.sql.ResultSet.getString as an Information Leakage. The ResultSet is properly closed after its usage.

LAPSE+ does this only for ResultSet.getString() and ResultSet.getObject(). For example, ResultSet.getDate() is not taken as a vulnerability. This behavior confirms to this OWASP page, which indicates only those two getters in ResultSet as vulnerable.

I'm trying to figure out the reason behind this. Does it have something to do with Strings being immutable?

Though not the exact thing (due to confidentiality reasons), following is a sample code block that I'm concerned about:

ResultSet rs = null;

try {
 dbConnection = dataSource.getConnection();
 prepStmt = dbConnection.prepareStatement("SELECT NAME, DOB FROM CUSTOMERS WHERE ID=?");
 prepStmt.setInt(1, customerId);
 rs = prepStmt.executeQuery();
 //do something

 while (rs.next()) {
  String name = rs.getString(1);
  Date dob = rs.getDate(2);
  //do something
 }
} catch (SQLException e) {
 //do something
} finally {
 if (rs != null) {
  try {
   rs.close();
  } catch (SQLException e) {
   log.error("Database error. Could not close result set  - " + e.getMessage(), e);
  }
 }
}

The reasoning might have been that ResultSet.getString and RestulSet.getObject should return a valid result no matter what the underlying value is for the column you specify. So if there was an SQLi attack and column 1 is usually a string but is now some secret number you'll get still a valid result and thus leak information about that result. Whereas ResultSet.getDate will throw an exception if it can't parse the column as a date so no information would be leaked, other than it's an invalid value.


Is MITM possible for Google services (TLS/SSL) as of today? I personally trust Google in terms of security but I'm not sure whether   man-in-the-middle (MITM) attacks against Google services AS OF TODAY possible or not. As far as I know, Google uses some protections against  (MITM) regarding certificates in Chrome browser.
Is MITM possible for Google services (TLS/SSL) as of today?

MITM is still possible if the attacker has sufficient control over the endpoint or in some cases if there is already SSL interception going on (not uncommon just by using AV).

If the attacker is able to either install a new CA on the endpoint or can use an existing custom CA already installed on the endpoint (as in case of the Superfish CA which was installed on Lenovo Systems) then he can do MITM. No HSTS or certificate pinning or certificate transparency will help in this case since these are deliberately disabled when a custom CA is used.

Similar MITM could be done in some cases if SSL interception is already in place. This is for example the case with many desktop AV software (Kaspersky, ESET, Avira ... all can do it and will often do it by default) and it is also common in companies. The necessary CA certificates for interception are automatically put into the trust stores and the client never sees the original certificate but must trust the SSL interception device/software to do a proper job. Unfortunately SSL interception systems commonly don't check for certificate pinning and certificate transparency in the first place, which makes it possible to use a different and compromised CA for the Google certificates then usually used. Moreover some SSL interception systems are of such a shoddy quality or configuration that they don't properly check certificates at all and can thus be fooled with certificates created by an attacker.

And of course SSL interception could be done if the attacker is able to compromise the device or software which does the SSL interception. Unfortunately systems like firewalls are not as hardened as one might hope and it is not uncommon that bugs surface which allow an attacker sufficient control over such devices.


Is possible to eavesdrop on mobile data from cellphones/dongles? It is possible to to crack WiFi either WPA2/PSK or WPA. But is it possible to somehow eavedrop/observe the signal from dongles or internet that is there on the phones ? Sort of a packet capture but for cellular internet. And if capture of that traffic is possible, can we somehow use impersonate someone and use their internet ?

If I were to run a Wifi Dongle in promiscuous mode near a phone that use mobile internet, would I pick up anything ? If not why ?

it possible to somehow hack the signal from dongles or internet that is there on the phones

Yes, definitely. The most economically feasible attack would be a man-in-the-middle with an open source SDR transciever

This paper has an excellent implementation with a USRP, attacking 4G with commercially available open-source tools.

Here is a video of this attack on GSM

You'll need hardware in the order of hundreds of dollars.

And no, WiFi dongles will not work for this


TLS WG Charter and Security Goals I was looking at the TLS Working Group Charter. I noticed that confidentiality and integrity of messages for those who desire it are not goals for the group.

Naively, I believe confidentiality and integrity are probably the predominant use cases. There are even folks who [incorrectly] state you get "end-to-end" security with them. Authentication-only (i.e., eNULL) and Encryption-only (i.e., aNULL) are likely not as popular.

Why do the goals lack confidentiality and integrity requirements for parties who want them?

Here's the context: Encryption of TLS 1.3 content type. In the thread, an argument was made to avoid changes that break middleware boxes. Effectively, I think that means don't break interception proxies, don't hinder traffic analysis, and facilitate other methods of attack (cynicism by me).

I thought, boy, that can't be the case. Surely the charter states confidentiality and integrity are security goals, and designing a protocol that subverts them would be a violation of the charter.

That "charter" is rather down-to-earth; it does not specify that "TLS should provide confidentiality and integrity" because this is taken to be obvious; instead, the charter is a roadmap to the future TLS 1.3 and thus documents the desirable changes from TLS 1.2.

As for the mailing-list messages you are pointing to, I think you are over-interpreting them. The kind of "middleware boxes" can be, for instance, a load-balancer system that needs to inspect ClientHello messages so that it redirects session resumption attempts to the server which last handled that session. Or a RADIUS server using EAP-TLS as authentication protocol: in EAP-TLS, the EAP layer must recognize the record boundaries in order to wrap them into EAP messages. These are very legitimate, non-evil reasons for systems residing in-between the TLS client and server to inspect the packets and actually understand the unencrypted parts of the protocol.

The dialogue in the mailing-list goes mostly the following way:

We must encrypt all the things ! Our Charter demands it ! Let's change the record header format.
This will break systems which rely on the record format; this may break compatibility with middleware boxes (that I will allude to only in the vaguest terms). Is it really required ? Or is it a Gratuitous Change, that is explicitly forbidden by Our Charter ?
This is needed because content-type field in the header allows for evil traffic analysis attacks (that I won't describe because I don't actually know of such an attack). Traffic Analysis is Very Serious ! Encrypt all the things !
But Our Charter does not talk about Traffic Analysis ! And Traffic Analysis is much harder to defeat than simply encrypting the record content-type headers. Traffic Analysis is Out Of Scope !

and so on, ad nauseam. Interspersed in the exchange are actual bits of information, from which we can conclude that the WG members do not seem to have reached (yet) a consensus as to the level of backward compatibility that TLS 1.3 should have with previous protocol versions. Especially since that compatibility is defined relative to existing, deployed system that interact with the on-the-wire format in various way that are not necessarily well-documented.

However, reading these emails as if the WG was trying to promote some generalized NSA-like spying would be erroneous. This is a classic case of "committee reasoning" when the actual goals and constraints have been insufficiently specified. It can be predicted that the definition of TLS 1.3 will take some time (years) to come to fruition.


Forensic Question Invisible User I was able to create an invisible user in windows 7 and 8.1.

The user is not visible at the login Screen, I added it to the SYSTEM account group and Remote desktop Users Group, The Administrator can know about this user via Computer management > Users and Groups option and using Net User Command in the shell, This user could not gain SYSTEM privliges though I am trying.

But the question is when I RDP into some host, The Local User does not know it is being RDP'ed.

How will the Administrator know when this invisible user does some malicious activity like deleting a file etc. as it is invisible in event log?

You can also use PsExec using -u and -p option for username "sys" and password "007" to log into invisible user through command shell via your other account, and you can RDP using invisible user that's it.
Why do they exist?

Please delete this question if I am wrong and I don't know enough, I want to know from experts like you.

You are wrong.  It still shows up in the event logs and the computer knows if it is an RDP session.  You can see that there is an active RDP connection if you have the right tools up as well.  What you are talking about isn't an "invisible user", it's a service user, and it is an intentionally designed feature of Windows, not a security hole.  You just aren't familiar enough about working with them and where they are logged.  Service users actually make Windows more secure because they allow automated processes to be configured with the least permissions they need without compromising the account credentials and access of the user account.  They also allow for services to be configured to run on a users behalf without having to give the user deeper levels of access to the system.

Additionally, if a user could access your computer well enough to establish a user like that, there is no reason they would need to create a user.  Loading a rootkit or a remote access trojan would allow for control of the user's computer without leaving a user account behind.  Some activity would possibly still end up in event logs for a simple remote access trojan, but a decent root kit could even subvert the system logging.

The attack scenario you describe is not a particularly viable attack scenario and isn't a security flaw, but rather a designed feature of Windows, implemented to improve security.


3DES is used as symmetric or asymmetric encryption? checked couple of online options which says 3DES is symmetric encryption(which means a single key is shared between two to encryption and decryption)

but I have seen many EDI production system(AS2 setups) which uses 3DES encryption though we use the public key of the receiver to encrypt (asymmetric encryption - public key and private key pair). How 3DES is used for these set ups ? or there is some misnomer with the term "symmetric" in 3DES?

3DES is symmetric encryption, always. This means that the same key is used for encryption and decryption and that thus both sender and recipient need to know this key. But it might be used together with asymmetric encryption.

Asymmetric encryption is often used to share the common key then used for the symmetric encryption in a secure way. A typical example is PGP, where (simplified) a random key gets generated, this key gets encrypted with the public key of the recipient (asymmetric) and then the message gets encrypted with the generated key (symmetric). The recipient then can extract the symmetric key using its private key and then decrypt the message using this symmetric key.


AWS KMS Getting Data Key using AWS Encyption SDK I am exploring the AWS KMS as a vault for storing the encryption keys. Now I am trying to encrypt the database fields like email.
So, issue whenever there is a read/write for email, I don't want to hit the AWS APIs(using SDK) to encrypt/decrypt.
What I am thinking is that, is there a way I can get the plaintext data key using SDK and store it in memory for some time and uses it for encryption/decryption.
I am playing with SDK but I am not seeing anything to get the data keys.
I need this for two reasons a) Throughput/performance b) Costing reduction
I have my data in in-house physical machines not in AWS

The entire point of KMS is to securely store encryption keys.  As a result, you aren't finding any options to extract the key because such an option does not exist by design.  This question is like saying, "I need a bank with a secure vault that I can store my driver's license in so it never gets stolen, but I also want to keep it in my wallet for when I go to the store".  These needs are, quite simply, completely contradictory.
If for some reason you did want to do that, then you can use a KMS with a customer managed key.  This will allow you to generate your own key, hand it to AWS, and they will place it in the KMS for you.  At that point in time you can have a copy of the key yourself and AWS will also have a copy of they key that you can use via KMS.
A more common use case would be to use KMS to encrypt the actual encryption key for your data.  This way the key can be stored in encrypted form.  When your application starts it takes the encrypted key, calls KMS to decrypt it, stores the decrypted key in memory, and then can operate normally.


Should I be concerned about the WordPress REST API's user enumeration vulnerability? With the current WordPress API you can get a list of usernames and email addresses of all users in the system with almost no effort:

<url>/wp-json/wp/v2/users

Outputs something like:

[{
  "id":1,
  "name":"admin",
  "url":"",
  "description":"",
  "link":"http:\/\/...\/author\/admin\/",
  "slug":"admin",
  "avatar_urls":{
     "24":"http:\/\/1.gravatar.com\/avatar\/...",
     "48":"http:\/\/1.gravatar.com\/avatar\/...",
     "96":"http:\/\/1.gravatar.com\/avatar\/..."
  },
  "meta":[

  ],
  "_links":{
     "self":[
        {
           "href":"http:\/\/.../wp-json\/wp\/v2\/users\/1"
        }
     ],
     "collection":[
        {
           "href":"http:\/\/..."
        }
     ]
  }
  },...

The username and ID are immediately visible. I don't see how this is anything other than a clear user enumeration vulnerability.

It's difficult to reliably prevent the enumeration of Wordpress users as there are multiple different ways they can be leaked. Besides the REST API approach, an attacker can  also loop through author IDs to discover accounts or simply collect the authors of all published posts. Wordpress usernames simply weren't designed to be kept secret.

The biggest risk through username enumeration is that it reveals old guest or test accounts with weak passwords. As a Wordpress administrator I'd enforce strong passwords for all accounts, deactivate legacy accounts and wouldn't worry about the enumeration problem as there are much bigger threats to Wordpress installations (such as poorly written plugins).

Yet, if leaking usernames makes you feel uncomfortable, there are plugins like Stop User Enumeration that also take care of the REST API leak you described.

Also see: Can I Prevent Enumeration of Usernames?


How does TLS work with another protocol (example SIP)? I already read this post. But I only understand about how does handshake work, the problem is I don't know how TLS work with another protocol like SIP. I'm confusing about two points:

TLS keep communicating with TLS's header and the payload is whole another protocol package (example SIP package).
Or they will communicate with another protocol header with the payload is encrypted by the key of TLS?

It's very similar to how we use TLS with websites. Just like we have clear-text http on (TCP/port 80) and http over TLS, also referred to as https running on (TCP/port 443) we do something very similar with SIP. SIP uses (TCP/port 5060) for cleartext and SIPS uses (TCP port 5061) for SIP over TLS.

That said to answer your question in a little more detail the two servers would externally be seen to just have a TLS connection with a client connecting to a server on (TCP port 5061) and inside of that "encrypted communication tunnel of sorts" the SIP traffic is sent from one system to another.

Useful references:

https://www.ietf.org/rfc/rfc3261.txt

https://en.wikipedia.org/wiki/Session_Initiation_Protocol


Best practices for implementation of role-based access control in healthcare applications Amongst the open source EMRs, which ones may be good to learn from? Any references I can go to as a starting point?

Several of the PHP-based Open Source EHR systems have used PHP GACL for access control. I am not sure how often it is used any more, it is a good place to start to look at how role-based ACL can be implemented and controlled. PHP GACL provides a three-teir access model, so that you can split things up into access triads. Like role:doctor power:modify data:patient records can be made and intelligently exempted, such as role:doctor power:read data:patient except where doctor=Dr. Smith power=read and patient=Dr. Smiths daughter.

I am not sure how VistA does access control, but I believe that it does have the power to do both the general rules and to create these more subtle exceptions.

The combinations of healthcare IT regulations in the U.S. have given further structure to the access control issue. First, of course, is HIPAA, which insists that access control enforce the "minimum necessary" access control. 164.312 and 164.308(a)(4) 45 CFR 164.502(b) 45 CFR 164.514(d) of the security rule require this access control. But rather than read those standards, HHS has a nice summary of the notion of minimum necessary.

So an EHR must be configured so that each user has access to the minimum necessary to do their job. Which means that access control in healthcare is largely job dependent. Practically speaking that means that the best practice is simply to ask "does this type of user need access to this type of patient data to do their job?" If the answer is no, then a role-based access control restriction should prevent access, and probably automatically log access attempts for that combination of role to data object access.

Meaningful use also has a core requirement (#15) (protect electronic health information) that requires access control. Mostly just by requiring audit enforcement of the 45 CFR 164.308(a)(1) portion of HIPAA. So you have to do access control, and you need to do have audited compliance with that access control.

Notice that none of these regulations have said "Doctors should be able to do X and not Y" or "Schedulers should be able to see B but not C". This is quite intentional. There are too many naturally occurring variations of workflows in hospitals and clinics that there is no one-size-fits-most advice that really works, much less one-size-fits-all. So the only thing that is required is that

Every employee should not be able to access everything and
What they do have access to should be related to what they do for
their job and
You actually have to enforce it.

There are two general caveats to those details. "1." may not apply if your practice is small enough. If a practice is composed of one other person besides a doctor who does scheduling, nursing, billing, office management and takes out the garbage, then that person will probably need to have access to just about everything in the EHR. If you have all of the jobs, then you get the access of all of the jobs. Be sure to document this fact, however, to show that you considered the possibility of more stringent access controls, but rejected it for practical reasons.

Second, while PHP GACL etc can do tremendously complex things, many EHR systems will have simplistic or backward access control implementations. You may be very limited by what your EHR can do or what it can be configured easily to do. Again, if your EHR design does not allow you to handle access control in a way that is compatible with your workflow needs (forcing you to grant more generous access then you would prefer) be sure to formally document that too. Also file a bug with your vendor.

In general, I think the target should probably be generally be "compliance" unless your particular EHR has a "best practice" regarding how to set things up. VistA, for instance, has a kind of "zen of VistA" for all configuration decisions. A documented or informal rule about the right way to handle a particular configuration.

O'Reilly has released a guide to meaningful use called 'Meaningful Use and Beyond' (shameless plug... I wrote it) This issue is discussed in chapter 8 meaningful use overview and chapter 12 on HIPAA.


Statistics about webservers and browsers SSLv3.0 support Since I'm working on a little historical document about the SSLv3.0 protocol and it's most important attacks, it would be lovely to add some statistics about how many webservers and browsers still support SSLv3.0 nowadays, even after the POODLE bite event.

Sadly I've not been able to find such updated statistics. So, are there any statistics after the POODLE attack about this? If not, what would be the most recent ones?

I'm seeking after something similar to  Ivan Ristic's survey on page 37, but newer.

Thanks in advanced!

SSLPulse, a monthly scan of SSL amongst the 200,000 biggest websites, has statistics on SSL 3.0 support: https://www.trustworthyinternet.org/ssl-pulse/

They publish at the beginning of each month, so any day now there should be new data. Already you can see SSL 3.0 support dropped from 98% to 60% from October to November.

(You can use the "Previous" and "Next" buttons at the top right to view the data for each month.)

Coincidentally, Ivan Ristic is also involved in this project.

EDIT: Also see:

https://zmap.io/sslv3/


John the Ripper Character Lists How is it possible to use or prioritize umlauted characters - ä ö ü ß Ä Ö Ü - whilst brute forcing.

I'm not using any wordlist, only dozens of CPU threads via the following command :

./john --fork=64 --format=NT hash.txt

Using john-1.8.0-jumbo-1.

When you look at the documentation, you are looking for the terms "character set" and "charset"

  By default, the [Incremental:All] parameters are set to use the full
  printable US-ASCII character set (95 characters)

The 95 characters do not include umlauts.

But later, the documentation reads:

  If you've got a password file for which you already have a lot of
  passwords cracked or obtained by other means, and the passwords are
  unusual, then you may want to generate a new charset file, based on
  character frequencies from that password file only:

  john --make-charset=custom.chr mypasswd

What you do is create a .pot file with the characters you want to include, update your .conf file for a new character set file, then run

john --make-charset=custom.chr


Storing lots of passwords that different levels of employees need access to I am wondering what other people do for storing passwords. Our current model at my employer is fundamentally flawed in my opinion, so I am trying to see what other people do so I can select the best method.

Right now all of the passwords for everything are stored in an excel file that is in a password protected Dropbox folder. Only a couple people have access to it.

Certain employees need access to different passwords and some of them are near impossible to remember while others are simple dictionary words with some punctuation and numbers attached for easy remembering. So the marketing department needs access to certain passwords that the accounting department does not need access to and vice versa, this goes for several departments as well.

Some problems I see are that the passwords are not encrypted, there are a couple gatekeepers that have access to all the passwords, not only is it an inconvenience for those people everytime someone needs a password but its also another security risk. I could keep going on about the flaws in the current setup. I am curious what other people do in this type of situation?

A solution I was thinking of is creating an internal intranet database that is encrypted and each time a person needs a password they login and can select the password they need. The CEO or person in charge can change the passwords, decide who gets access to what passwords, etc.

First off, for as much as possible you need to switch over to something like Windows Active Directory or using LDAP* for internal permissions.  That way, users get permissions based on a central repository, don't know other users passwords, and you can audit who is able to - and who did - access what.

I'll assume you aren't in a regulated industry (if you are, you're in real trouble).  Even then, your company's current setup shares all the passwords with Dropbox, anyone who has access to Dropbox data or backups, and potentially with any company that later merges with or acquires Dropbox.  This may or may not be an argument anyone cares about.

Changing passwords is a big deal, and any time anyone leaves, you SHOULD be changing passwords - why does someone not employed or under contract have access to corporate resources?  It's even worse if they left under less than amicable circumstances.

After you're done with the AD or LDAP integration, there will still be systems that aren't integrated.  For those, I'm a big KeePass** fan.  Employees can have a "personal" KeePass file, which is their primary, and holds person-specific accounts - which should be used as much as possible, so they can be disabled when people leave and so actions can be audited

You SHOULD monitor for, and take serious action when you see employees sharing passwords.  This is a very common practice in small unregulated companies, and it causes problems later (audits failed, clients asking hard questions on their own audits, future regulation, and again the cost of changing every password any ex-employee knows).
If your employer really loves Dropbox, there is KeePass integration available, as well as FTP, SFTP, etc. integration.

Ask them what their plan is for times Dropbox is inaccessible (being DDoS'd) or suddenly goes out of business (if Enron, Lehmen Brothers, and Lavabit can vanish overnight, so can Dropbox)

Employees may also have shared KeePass files if absolutely required - it does a good job of handling a few people opening and modifying the same .kbdx file simultaneously, merging the updates, or you can use the Synchronize command.  The passwords and keyfiles used to open these shared KeePass files should be kept to as few people as possible, the contents should be kept as minimal as possible, and you again change passwords and keyfiles whenever someone that knows them leaves.

Again, set up individual accounts at every point that can be done.  When you have to investigate something (call it a production problem, or maybe fraud), this is critical.
For any shared KeePass databases, use both a randomly generated keyfile if management agrees to it, but also long (35 character or more) passwords generated randomly by KeePass itself; employees keep the shared passwords in their personal KeePass database, and the passwords MUST be so long and random that it's honestly burdensome for employees to hand-type them.

That way, there's no incentive to write it down; it takes forever and it's a pain to type anyway.
High ASCII characters can also be used, like the copyright symbol or accented characters, making it even more difficult for employees to get in the habit of using shared superuser accounts without going through their own KeePass document.

*For a linux example, see the question "how do I configure my RHEL5 or RHEL6 system to use ldap for authentication?"

** When you set up your KeePass database, or afterwards if someone else does, make sure to go into File, Database Settings, and click the button for the "one second" number of rounds.  Increase it from there as you see fit, but just doing that even on a very slow machine increases your security significantly - I usually use millions to tens of millions of rounds, since a second or five doesn't matter compared to the speed savings of the auto-type feature.