What approaches are used to discover zero-day vulnerabilities? As a developer of multiple standalone apps (Web-/Native apps) I am wondering, what things I should keep in mind / what are typical approaches of a blackhat (besides of these scriptkiddies checking for sql injection etc.) to identify such vulnerabilities.

During my web research I only found very broad information and no detail on how a blackhat actually finds a zero day vulnerability.

Regardless network/phishing/social engineering vulnerabilities.

I'd like to know what is the approach to find a zero day exploit/vulnerability and how can I, as a developer, make my software more consistent?

I'd like to know what is the approach to find a zero day exploit/vulnerability and how can I, as a developer, make my software more consistent?

Learn and understand fuzzing techniques if your goal is to develop your skills in finding zero day vulnerabilities in your software (and other software)

From Wikipedia:

  Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, or failing built-in code assertions or for finding potential memory leaks -https://en.wikipedia.org/wiki/Fuzzing

Metasploit Unleashed created an excellent starter tutorial on Fuzzing:
Writing a Simple Fuzzer

Google Project Zero is known to conduct Fuzzing at scale (Maybe the entire Internet?)  Learn more about their fuzzing approach here:
Google Fuzzing at Scale

Remember to have fun, be safe, and always practice responsible disclosure.


Example of attack trees in the web application security analysis Here I am again asking for some informations about attack trees usage in web application analysis.

For my master thesis I decided to study the usage of this formalism in order to reppresent attacks to a web applications. I need a lot of use cases from which to start learning common attacks which can help building a proper tree.

From where can I start?

I've already read the OWASP top 10 vulnerabilities an I'm familiar with XSS, SQLi, ecc. however I've no clue on how to combine them together in order to perform the steps needed to attack a system.
I'm looking for some examples and maybe to some famous attacks from which I can understand which steps are performed and how commons vulnerabilities can being combined together.
Any help is really appreciated.

As you are familiar with OWASP, you might have a look at the WebGoat project - "a deliberately insecure J2EE web application maintained by OWASP designed to teach web application security lessons".  There are other tools and resources out there, such as DETERLab for learning about common attacks.

These should provide you with plenty of examples.  The formalisms themselves are not hard to apply - I suggest using pen and paper or a whiteboard to start having a go.  In my experience the best thing about attack trees is that they make you think harder about the problem, rather than being important artefacts in and of themselves.


What is the motivation behind supporting both `none` and `self` attestation in WebAuthN? WebAuthN seems to provide essentially two different ways of not performing verifiable attestation: Either by the Relying Party requesting none or by the authenticator choosing self attestation.

Is this purely a protocol design choice for the sake of symmetry (allowing the invariant of "if attestation is requested, it is always supplied"), is it to support specific legacy use cases (if so, what are they?), or are there any security implications/differences between self and none?

This is most likely for backwards compatibility. Chrome 67 started using self attestation for U2F (the U2F spec doesn't allow for "none") for specific keys that were discovered to not meet the 100,000 batch requirement to preserve privacy.


Tools for Verifying Secure Deletion It is recommended to verify the zeroing-out was done properly when you try to secure delete a HDD. From this post, some drives with firmware bugs prevent secure erase from working properly.

What are the recommended software tools to accomplish this? Either Windows / Mac / Linux is fine.

Ideally, tools that could verify for files that we just recently (secure) deleted. For example, after we deleted 1 file securely, we'd then use the tool to verify that the storage in which the file previously lived is now completely zeroed-out.

Any hex editor that can read disk sectors directly can handle this.  One such is HxD for Windows.

Note, however, that checking the sectors where the file most recently lived does NOT tell you whether there is any data from the file remaining.  Merely deleting at the file level does nothing at all to deal with, for instance, a file that was recently defragmented - the old sectors are now "free", but still contain that file's data.

If you really want to securely delete, wipe the entire drive, verify it, and then shred it or wrap it carefully and hit it with a hammer until little tiny glass shards are visible.

If you must do only a partial secure delete, you can try deleting that file, verifying the most recent location, and then doing a full free space delete.  Piriform's CCleaner does have secure erase options, and free space erase options that at least once were reasonable.

If you go that route, you're going to want to wipe your free space + cluster tips once, and then build a few huge files of, say, all 0's that take up most of the remaining drive space so the next free space delete is easier.
You'll also need to do a free space + cluster tips erase after every defragging.

And probably routinely, for that matter.


Stateless AEAD (AES-GCM) based tokens I want to generate secure data tokens which can be shared with the client for uses like password reset, etc. which involves low storage overhead at server end. Ideally I am interested only in managing the secret key.

From what I understand, AES-GCM needs a Key and a Nonce along with Data (and optionally Additional Data). It generates a Tag and Cipher Text after encryption.

To decrypt, same Nonce, Key, and Tag are needed along with Cipher Text.

Key of course needs to be kept secret but I want to avoid the overhead of storing the Nonce and Tag which I understand would be unique to each such token.

Is it safe to share the Nonce and Tag along with CipherText with the client?

The client is just suppose to return the token and not read/temper it. Its for web apps and you can assume that all communication is happening over TLS.

JSON Web Encryption essentially does this. Additionally it lets you select different Content Encryption Key (CEK) for each token.

BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' ||
BASE64URL(JWE Initialization Vector) || '.' ||
BASE64URL(JWE Ciphertext) || '.' ||
BASE64URL(JWE Authentication Tag)

For my case, I could select the alg as dir so that CEK essentially is the symmetric key I specify and it would precisely be what I wanted.


control flow (buffer overflow) (introductory question) I'm looking at the following code and am trying to figure out how this bug would be helpful for something like launching a shell.

int func(int i, double *data1, double data2)
{

double  *p = data1;
double  *vec[10];

if ((i<0) || (i>10)) return;

vec[i] = data1;
*p = data2;

}

There is an answer on the linked pdf below (Send i = 10 and data1 = RetAddr) but I'm looking for a more elaborate explanation.

The question comes from Dan Boneh's CS 155 class and is #3 here:

https://crypto.stanford.edu/cs155old/cs155-spring07/final06-with-answers.pdf


Predicting the Entropy of the entire Password Database Suppose that the passwords created under some specific composition rule "C" is to be tested for the security. One of the way could be to conduct survey on x number of people and measure the average entropy of the passwords created by them.
What should be the least value of x so that approximate entropy of the password database created by 6 billion users under the same composition rule "C" can be predicted?

I want to evaluate which composition rules create more secure passwords, assuming that I can collect the survey based password data.

I have the impression this is an invalid line of questioning the problem.

Rule C * number of people does not define the entropy, the algorithm used for encrypting the password does. Unless the passwords are kept in clear text the password database as such will only show entropy against the algorithm.


How can you spoof a TCP connection to a device that uses the same initial sequence number for each run of a TCP handshake? So supposing the TCP implementation on a device always uses the same initial sequence number how could you as an off path attacker exploit this to spoof a connection to this device?

So in order to do this you would need the device to set up a TCP handshake with you. To ensure that a RST message is not sent by the device I assume you would need to spoof both the SYN and ACK message (this would require knowledge of the device's IP address then? As an off path attacker how could you get that?).

Or...

Would you only need to spoof the SYN message, send a SYN/ACK with what the device will believe to be valid given that it has a valid sequence number? Would the device not simply sent a RST message in response to a SYN/ACK message?

Any ideas?

"Spoofing" is normally about using a fake source address. You want to connect to the target, without revealing your actual IP address, instead using another IP address. In your case, you (the attacker) perfectly know the device's IP address; what you do not want to reveal is your own IP address. You want to open a connection with the device such that the device believes that it talks to a client with a completely distinct IP address.

The main problem with spoofing is that while you can send arbitrary packets with a fake source IP address, you won't receive any response, because responses will be sent to the fake address, not yours. This, in particular, makes it very difficult to complete the TCP handshake because each party must send s+1 as an acknowledgement of the sequence number s sent by the peer. If you are the client and are trying to spoof, you won't receive the SYN+ACK packet from the server, and thus won't know what value to put in your own ACK. You might "get lucky" but since these are 32-bit integers, the probability of success is only 1 in 4294967296.

Now, if the target server uses a poor random generator, then your probability of guessing the sequence number chosen by the target may go up. In particular, if the target server always uses the same value (a very poor generator indeed), then you can guess it with probability 1, i.e. succeed each time. You can thus send a SYN, not receive the SYN+ACK (because it is sent at the fake address), but still send your ACK with the right value, based on your "guess" of the sequence number chosen by the server. The server will be content with that ACK. At that point, you can send arbitrary data through the connection. Of course you still won't see any answer, but if the point is to issue commands, then this is sufficient (example situation: you want to send spam through a SMTP server that refuses email sending except from a few specific client IP addresses).

In all of this, all your packets must bear the fake (spoofed) IP address.


File exchange over DNS Tunneling I want to demonstrate an attacking scenario in which DNS tunneling is used to get information out of a protected network. There is the compromised host behind the firewall, at which the client is installed and it needs to send a file over the DNS tunneled connection to a server controlled by the attacker.

I have set up the DNS tunneling using DNSCat2. I can connect the client to the server and interact, I even have shell.

What I want is to transfer a file from the victim host to the server using the DNS tunnel only. I cannot seem to find this functionality*, is there any way to accomplish it?

* EDIT: RTFM!

There are literally tons of ways to do this, but the simplest is to transfer them over text.

For example, you can base64 encode the file and echo it out to the remote host (or vice versa) then decode the base64 on the other side.
There's also this technique demonstrated by SANS.
Be creative!


PGP-encrypted Email or SSL/TLS Webform for Responsible Disclosure Communication? So it's a fairly simple question. When offering an avenue to security researchers for communication with us regarding disclosure of security vulnerabilities, what's the best way to do so?

Assume we have a responsible disclosure policy page that's secured under a properly configured SSL/TLS connection:

Offer a security@ email address to contact with a PGP with an established Web of Trust consisting of developers and open source community. The PGP fingerprint is published on the page and the key is available on one of the many key servers.
Offer a HTTPS submission form that, under the hood, dispatches an email from the webserver to the office's internal mail system. STARTTLS would be used so the email is encrypted in-transit
Offer both, letting the researcher decide.

It would seem to me that Option 3 is the best, but I've heard researchers complain about all 3 options both for & against.

When we are working with Responsible Disclosure Communication, we need balance security and convenience.

Convenience for whom?

For security researchers.

You need to think a few things before choose:

Do you need the reports so safe that you can wait to receive them?

Sometimes the security researcher finds a security bug, but he is not with his PGP keys. And if he is traveling? You will wait a few days (or more) to receive the reports. Is it expected? Sometimes it is not.

What is best, address a bug quickly, even receiving the report through insecure channels, or take slightly longer to address the bugs but be sure that the reports are send and stored in the safest way?

Just you can answer this question.

I worked managing a Bug Bounty Program recently, and I can say to you that a few researchers will choose send the bug through the HTTPS form (fast), others will e-mail you in plain-text (faster) and others will never talk with you without exchanging PGP keys.

And you never can say that one type of security researcher will send better reports than others (the PGP guy, the HTTPS form guy or the plain-text e-mail guy).

So be careful with your choice, I would choose the option 3.

In my opinion is better receive a report than not receive it, independent of how I received it.


What are the demerits of a derived salt for password storage? The general method used for storing passwords securely involves generating a salt, feeding the salt and password to the password hashing function, and then storing the salt and the output of the password hashing function in the database.

However, instead of generating a random string of characters as a salt, why isn't a salt derived from the user's properties be used?

A "derived salt" could be obtained as follows:

Calculate some property of the user's password, such as the sum of the ASCII values of each character. (Example: "Pa$$word!" => 80 + 97 + 36 + 36 + 119 + 111 + 114 + 100 + 33 = 726).
Combine this with some other property known about the user, such as the email address of the user. (In our case, "someuser@example.invalid" + "_" + toString(726) => "someuser@example.invalid_726").
Use this as the salt for hashing passwords.

Of course, there could be multiple variations on the above described scheme, by varying the function of the password taken, and the properties taken for combination.

What are the disadvantages of using a "derived salt" scheme for password storage, over randomly generated salts?

Additionally: if both of these are nearly equivalent in their security properties, why are derived salts not used for password hashing?

The reason for adding a little salt to a password before hashing it, is to make it much harder to reverse the hashing. Therefore a completely random number is the best solution.

Having to come up with a "derived salt" number which is unique enough so as most of your user passwords have a different hash is going to be difficult. When generating a large enough salt number (16 bytes, for example) will likely be unique for all the users who will ever create an account on your system without much hard work on your part to determine the uniqueness.

Also, using a parameter such as the email address of the user can be tricky. If they want to change their email address, you lose your "derived salt" unless you force the user to change their password at the same time they change their email address (or any other user parameter used in the computation of your "derived salt".) So either way you would certainly want to save the salt in the database to make sure you can always compare passwords on future user log ins.


How does SSLstrip work? I've been reading up on SSLstrip and I'm not 100% sure on my understanding of how it works.

A lot of documentation seems to indicate that it simply replaces occurrences of "https" with "http" in traffic that it has access to. So a URL passing through such as "https://twitter.com" would be passed on the to victim as "http://twitter.com".

At this point does SSLstrip continue to communicate with Twitter via HTTPS on our behalf? Something like this:

Victim  <== HTTP ==>  Attacker  <== HTTPS ==>  Twitter

Or is it just the fact that the client is now communicating with Twitter over HTTP that gives us access to the traffic?

Victim  <== HTTP ==>  Attacker  <== HTTP ==>  Twitter

My guess is it would be the first option where the Attacker continues to communicate with Twitter via HTTPS as it is enforced by Twitter but I would just like some clarification, thanks.

You should watch Moxie Marlinspike's talk Defeating SSL using SSLStrip.  In short SSLStrip is a type of MITM attack that forces a victim's browser into communicating with an adversary in plain-text over HTTP, and the adversary proxies the modified content from an HTTPS server.  To do this,  SSLStrip is "stripping"  https:// URLs and turning them into http:// URLs.

HSTS is a proposed solution to this problem.


Key size difference between AES and RSA Can I say that 128 bit using AES provide more security than 1024 using RSA?

They're not really directly comparable. The number commonly bandied about is 2048-bit RSA is about equivalent to 128-bit AES. But that number shouldn't be relied on without understanding the caveats.

Currently the most effective way of breaking AES crypto (and any other unbroken symmetric cipher, for that matter) is brute-force. You simply try every possibility until you reach the correct result.

This means that it is possible, and well within today's technology, to encrypt data that (assuming no better attack is ever found--not a horrible assumption), can never be broken, ever, by anyone. Simply use enough bits in your key such that there isn't enough energy in the universe to try enough candidate keys. The numbers are smaller than you'd think:

Indeed, with AES, 128-bit is secure against modern technology, 256 is secure against any likely future technology, and 512 is probably secure against even never-imagined hypothetical alien technology.

Symmetric encryption, if not broken, doesn't leave you with a math problem to solve. The numbers are truly and literally scrambled, and the system is devised such the brute-force is by far the most efficient solution.

Breaking RSA, on the other hand, is not so hard. Instead of brute-forcing the keys, you factor the modulus into primes and derive the keys yourself. This is dramatically simpler to do. It's a math problem, and we can do math.

Specifically, the speed at which primes can be factored is increasing FASTER than the speed at which symmetric keys can be brute-forced. And that's with today's technology.

But going forward, assuming quantum computers can be improved such that qbit operations are a cheap as bit operations (which many people thinks is fairly close; this century at most, possibly decades), then no matter how large you make your RSA key, breaking the key is as fast as encrypting.

So the moral of the story is this:

The "equivalent security" of RSA key length versus AES key length changes over time. Every so often, you have to increase your RSA key size relative to your AES key size to account for technological advances. And even then, it's an estimate at best.

And while a 256-bit symmetric key should be secure for hundreds, thousands, or perhaps hundreds of thousands of years, no RSA key of any length should be assumed to be secure more than a few dozen years out, since RSA is expected to be completely and utterly broken by Shor's algorithm.


Can a Windows 10 Local Account password be retrieved I have heard that Windows (10) local accounts are not that secure. I am however particularly wondering whether the password can be retrieved using any tools.

So I am not talking about resetting it using whatever means necessary. I am talking about retrieving the password in plain form.

By default, Windows hashes all passwords with what Microsoft calls NThash (sometimes called NTLM hash), which is just MD4 of the UTF-16-LE (little-endian) representation of the password.

Technically, MD4 is a one-way hash, so no, it is not possible to retrieve the password from this. However, the way it's used is very weak, so it's usually possible in practice to reverse the hash.

Rainbow tables: The passwords are not salted before hashing, so a given password will always product the same NThash on any system. This means they can be pre-computed in giant lookup tables (sorted by hash digest to enable binary search) called "Rainbow Tables". There are many rainbow tables on the web, or you can build your own if you've got a bunch of time to kill. While a rainbow table can never store every possible hash value - MD4 digests are 128 bits long, which means 2^128 possible values, which is quite beyond the capacity of all data storage currently in existence or likely to exist - they can certainly store billions of likely passwords and that makes all but the longest/most obscure passwords crackable in practice.
Hash brute-forcing programs: Hash algorithms like MD4 are designed to run quickly, and MD4 in particular is nearly 30 years old so you can get tens of thousands of times as much computing power for the same amount of money as you could back then. That means it is possible to compute hashes extremely quickly, especially if you have a processor that is capable of quickly executing the same instructions (the steps of MD4) on multiple data (candidate passwords) in parallel, and collecting the results into one organized output. This (single-instruction-multiple-data or SIMD operation) turns out to be how GPUs work. A single high-end GPU can compute billions of hashes per second, and there are programs that you can run which will use your GPU to try to brute-force a password hash. Even without a rainbow table, you can brute-force most passwords very quickly if you have a good graphics card.

Windows can also be configured in two non-default ways, which would make this task even easier:

The legacy "LM" or "LANMAN" / "LAN Manager" hashing algorithm makes MD4 look modern and secure. LM hashes can only be used on passwords up to 14 characters in length, and only because the actual operation is performed on pairs of 7-character chunks with the results concatenated. It also only supports a limited set of input characters (notably, it upper-cases the password before hashing). As a result, you can brute-force each half of an LM hash separately and extremely quickly; your typical CPU can brute-force any LM hash in under a minute. LM hashes are disabled by default on all recent versions of Windows (and not used even on older versions like XP if you used a password at least 15 characters long) so you're extremely unlikely to find one on Win10, but I think it's still possible to enable them.
Windows supports the ability to store passwords under reversible encryption, rather than hashing. This allows any Administrator user to retrieve any user's password, because apparently some of MSFT's customers wanted this ability really badly. It's a terrible idea and should never be enabled, because in addition to letting admins see user passwords, it lets anybody who can access the hard disk and knows how to retrieve the machine key and the encrypted passwords also see the user passwords (and there are tools for this). It's very unlikely that the passwords on any given Windows machine are stored this way, but if they are, then it is in fact possible to directly retrieve them if you have admin-level access to the system or physical access to its system volume.

EDIT: As HackneyB points out in the comments, Microsoft couldn't pass up an opportunity to add some useless obfuscation on top of their antiquated password hash, so they wrap it in multiple layers of futile encryption (futile because the keys are either stored in plain text or derivable from plain text values, so it doesn't matter in the least which ciphers or how many layers are used). Stripping away the obfuscation, though, the only actual cryptographic protection against reversing the passwords is that single-round unsalted MD4 hash.


Is it neccessary to use X-FRAME-OPTIONS to prevent ClickJacking attacks? I use this Javascript Code, and it works perfectly:

  if (top.location != location) top.location.href = location.href

Many researchers told me to not use this.

Can any one bypass it?

Are there any risks in using this,if yes what?

One of them told me that an attacker can redefine location variable:

  var location = 'foo';

But in Google Chrome, this doesn't seems to work

You are talking about ClickJacking attacks. (The title was different before my edit)

  Can any one bypass it?

Yes, this can be bypassed when loading the page in an iframe. Unfortunately I do not have the code at the moment. However, what can be done is disable javascript while loading the iframe. This will bypass your frame busting code. (There's no such thing as frame busting code in my humble opinion)

  Is it neccessary to use X-FRAME-OPTIONS to prevent ClickJacking
  attacks?

For newer browsers it is the standard to prevent ClickJacking attacks. I do not see a reason not to use it, as it is quite simple to add the extra header for each response.

  One of them told me that an attacker can redefine the location variable:

  var location = 'foo';

As not all code is displayed, it's hard to say if this is exploitable or not. The only thing I can see from this one line of code is that the attacker could attack his own browser by modifying the variable location, which is useless.


What stops a developer from accessing credit card details and other secret data from a company First of all, I'm sorry if this has been discussed many times. I read many posts about PCI compliance but there are some small things I'm not quite sure about.

Suppose there is Mr. GoodGuy, an honest software developer. He develops the main software architecture, and the company trusts him and gives all the access he reasonably need. This software stores credit card numbers for recurring payment management, and software uses a credit card gateway to charge the renewal amount.

Mr. GoodGuy could write some code that would decrypt the card for a user, no matter what level of security the software has (encryption key in a secured server location, per-user keys, or anything), the software itself can somehow decrypt the card data. That means, even though the developer is honest, he could access card data.

What are the possible solutions that other companies have implemented that prevents someone from using the software to access card details?

This is not really about card details. It can be anything like online file storage services, medical data, or anything. How can a developer can make sure he won't be able to access the data as he wants, but make it possible for software to to access them (without user participation)

PS: I'm Mr. GoodGuy here and I have no intention do anything bad. I'm wondering how other companies deal with this. Do they trust the developers? Even if he's resigning, he can take the key file with him. Flushing all stored cards is not an option here either since it can send many existing sales off.

PCI DSS sections 6, 7, and 8 all bear on this question.
For example, part of 6.3.2 which requires code review:

Code changes are reviewed by  individuals other than the originating
code author, and by individuals  knowledgeable about code-review
techniques and secure coding  practices.

6.4 with change control:

A separation of duties between personnel assigned to  the
development/test environments and those assigned  to the production
environment.

7.1 controlling access... in many environments the developer who writes code never accesses the operational systems where it's used with live data:

Limit access to system  components and cardholder data to  only those
individuals whose job  requires such access.

And a touch of 8.7 to put restraints on those people with access:

Examine database and application configuration settings to  verify
that all user access to, user queries of, and user actions on  (for
example, move, copy, delete), the database are through  programmatic
methods only (for example, through stored  procedures).

Now, that all said, can a trusted insider every be perfectly defended against?    No, because of the very definition of "trusted".  This is true in all places (how many spies have been "trusted"?  John Anthony Walker comes to mind.)  But there are best practices for defending against such a threat , for mitigating them, and the PCI DSS formalizes as requirements a number of these practices (for credit cards... other secrets are on their own!)
(And @Stephen-Touset points out, 3.5.2 requires:

Store secret and private keys  used to encrypt/decrypt cardholder
data in one (or more) of the following  forms at all times:

And one of those ways is:

Within a secure cryptographic  device (such as a host security  module
(HSM) or PTS-approved  point-of-interaction device)

Which has the advantage of escrowing the actual key material away from day-to-day users and administrators.)


Protecting an IIS web site hosted at home My case is

I just registered at dyndns.com to get a domain for a website I am staging on my home computer (I know it's not considered good to do so). But the website is not big, and I don't expect to have much traffic; about a maximum of 50-80 per day. My website is served by IIS 7.5, on a system with Windows 7 installed.

My question is:

As people say it's not good to have a web-server on a home computer because of security reasons. What security measures should I take to secure my computer from intelligent but bad guys? ( Also, how should they be configured?).

Edit

I just want something like a checklist and a link to some sort of website that tells me how to configure it.

As jweyrich said - the more specific you can be about requirements, the better. Having said that, there are some simple industry good practices you should follow:

Have the web site hosted on an entirely separate computer - you should expect a server open to the Internet to be a likely point of compromise, and I'm guessing you don't also want a successful attacker to have all your online banking details, passwords, emails etc.

Separate your web server from your home network with a firewall - a layer of defence to help with the above point :-) Do not allow anything through the firewall except just those connections your application requires. Also use an external firewall to limit the connections from the internet to your web server.

Keep your web server up to date with patches, security fixes, versions etc. Do not use deprecated versions of software, or languages known to be vulnerable.

I'll try and pop up a couple of useful links to online guides, but for now I'm opening presents so it'll have to wait :-)


City Government Emailing User Name and Password My city has online billing for utilities. When you set up an account they email your user name and password to you. You can't change your password without them emailing it to you again. Isn't this insecure? Doesn't that mean my user name and password is being sent in the clear and someone can log on to my account?

Yes this is correct. Security principles dictate that you should be able to set your own password.


Data sniffing on a WEP 128-bit encryption I am relatively new to cybersecurity and hacking and I aim to learn ethical hacking as a passion alongside my mainstream education(Electrical Engineering).

My setup: I have set up my very own WEP WiFi network(intentionally made vulnerable by setting up WEP encryption). I have also set up a microcontroller(NodeMCU, in case you were wondering) to transmit some sensor data(DHT11's temperature and humidity data) over this WEP network. It would post the data over some URI (eg. 192.168.1.100/data).

Goal: To break into the network that the microcontroller is connected to(the WEP network) and sniff the data that is being transmitted. The communication is assumed to be by HTTP and is also assumed to happen by GET method. However, the exact URI is not known. So, GOAL 1 is to Find the exact URI and hence, get the data being transmitted. After accomplishing this, the next GOAL 2 is to try to spoof some data i.e send some garbage data and keep the actual data to ourselves.

Progress so far:

Easily cracked the 128 bit WEP encrypted password using Kali Linux (Aircrack-ng tools). Tons of information available readily
Got access to the gateway, i.e the modem's settings page(assuming the password is not changed from the default admin, admin User ID and password.
Thus, obtained the IP address of the microcontroller

THE PROBLEM: I tried sniffing data off the network(I am still unaware of the exact URI over which the microcontroller is transmitting data). I tried using Wireshark for this. it seemed to match the needs. But, I could not see any traffic on Wireshark from the IP address of the microcontroller. No matter how many times I try refreshing the page on my mobile phone, no traffic was shown. But, however, my phone did display the data. What am I missing? I tried sniffing on the same WiFi adapter that was simultaneously connected to the WEP network. I even tried putting up an external WiFi adapter on monitor(promiscuous) mode and then try sniffing data. All in vain. I need some help.

Wireshark Problem

See? No traffic is shown from the esp8266's IP address

Now, tried using an external USB adapter. This showed up the ESP as ESPressi_ac, not it's IP. The Motorola.. is my phone. When I first connect it to the network, it sends out an ARP for the IP. You can see it in the 2nd screenshot. But, it gets no response. Still, I am able to view the ESP's web page (knowing the URI beforehand).There is no HTTP traffic at all. What am I missing?

From what I can see, your setup is something like this:

NodeMCU Microcontroller <----> Phone
                          ^
                          |
                          |
              Sniff packets with Kali

Although you have tried sniffing with promiscuous mode, using promiscuous mode to capture wireless traffic might not work:

  Promiscuous mode is, in theory, possible on many 802.11 adapters, but
  often does not work in practice; if you specify promiscuous mode, the
  attempt to enable promiscuous mode may fail, the adapter might only
  capture traffic to and from your machine, or the adapter might not
  capture any packets.

A workaround to this problem is to use monitor mode. Monitor mode is different from promiscuous mode in that monitor mode captures packets without associating with an access point, and promiscuous mode allows you to view all packets on the network you are associated with, even if the packets aren't addressed to you.

You could use monitor mode by passively sniffing packets from networks around you while not connected to an access point.

If the network you are sniffing uses encryption, provided you know the WiFi key, Wireshark can decrypt the packets for you.

TL; DR: Use monitor mode.


Is it possible to block non-PyPI requests during pip install? In 2017 and 2018 there were these infamous stories about malicious packages being uploaded to the PyPI (Python Package Index) which tried to do all sorts of things (collecting and sending data, reverse shells etc) during installation as pip and setuptools would execute setup.py install automatically when setting up a new package.

Would it be possible to block or at least warn about any network requests going to non-PyPI servers that happen during a package installation? Is it a good counter-measure for this kind of a situation?

Is it a good counter-measure for this kind of a situation?

No. Unfortunately what you're planning to do won't address this specific threat. Here, the attackers compromised the package on PyPI itself, hence it was downloaded from the original source, so limiting downloads only to PyPI would have no effect.

In most cases, these compromised packages come in two flavours:

Attackers gain control of a legitimate package and inject malicious code into it. e.g. NPM event-stream
Attackers create a malicious package that looks similar to the legitimate package (jeIlyfish vs. jellyfish) -- the form uses the upper-case 'i' instead of 'l'.

It's hard to address this without some tooling, ultimately it's nice to be able to build everything yourself, but sooner or later you're going to need external packages -- and sometimes those external packages get compromised. Even without attackers, legitimate CVEs are found in commonly used package and require upgrades on your part to protect your application.

For this you need a tool, that scans your requirements.txt file and validates against a list of known vulnerable packages (either through this type of compromise or something else). Of course this is more post-build rather than pre-build, but you can incorporate into your build pipeline if required (validate requirements.txt before building).

If you publish your code on Github, it automatically is scanned by Github against known vulnerable packages and warns you via email and on the repo homepage. There are other tools like pyup, synk, etc that do exactly the same thing.


How to attract traffic to a honeypot I have set up a honeypot, but I am not happy with the low traffic load and I would like to trigger much higher traffic levels.

What methods would attract high bot activity? These are the ideas I have right now:

incorporate Google Dorks into the honeypot
add multiple entries of the honeypot IP on Pastebin (I know there are scripts that scrape Pastebin for IPs)
add the IP to various public forums (like the methods used by spammers use to advertise sites)
create multiple free websites (Blogger, etc.) that cross-link to each other and the honeypot
use SEO to gain attention by search engines
advertise the honeypot IP on social networks (twitter, google+, facebook)

What else should I look at? What of the above will have low success?

I know that this is a duplicate of Setting up a honeypot but I am focused on just the 'traffic' facet of that user's question.

Thank you.

If anything, there are several different types 'prey' you can attract.  First, there are tons of bots out there automatically running port scan on different ip ranges to enumerate vulnerable services.  So, to attract bots and such, it's important to look like a "old and injured prey."  Run as many vulnerable services as possible to attract attacks from those bots.  One caveat is some providers to upstream blocking.  So, if you're running your honeypot on such a provider network, you may not see these scans.

If you want to be subject to "script kiddie" type attacks, then posting your IP on boards as well as a massive flaming campaign on boards/IRC rooms will help you attract attention.


Can my ISP see which VPN protocol I am using? I know that my ISP can detect when I am using a VPN, but can it see which protocol I am using?

Yes, probably. Most VPN protocols are not designed to hide the fact that they're VPN protocols, nor what kind of protocol they are. See for instance this paper which details fingerprinting OpenVPN.
If you run all your traffic through a VPN, the fact that you're using a VPN is quite easily visible - as all traffic will be destined for a single destination - which is quite unlike normal usage patterns.
If you're interested in hiding the fact that you're using a VPN, and what VPN, you should probably look into what's used in totalitarian states, such as China, which routinely blocks all attempts at VPNs out of China. Tor is one such system.


How to connect to Windows RDP and delegate authentication to a (reverse) proxy? Looking for the following setup:

Client connects to Windows RDP server through proxy server. The client is in public network hence can't send username/password for logon. The proxy server in between should authenticate to RDP server and open a session and secure the access to RDP server.

Or how can the client send login information (certificate) securely?

You need to use a RDP reverse proxy, not just a TCP proxy. There are plenty of software providing that functionality (in different forms), free and paid.


Devising encryption schemes and protocols I am wondering how encryption schemes are developed and why certain decisions are made.

For example. I have seen a company hash a string with SHA1 and then RSA encrypt it. Why? I've also seen the hash and plaintext be concatenated and then RSA encrypted.

My (broad) question is how does combining different methodologies impact security?

One could go crazy and add to the above by adding a magic string in between every char in the plaintext, hash every other magic string, etc until you have a really (over-complicated) scheme.

A real example is:

key = hex( rsa( plainText + hex (sha1( plainText ) ) ) )

why choose to do this?

While we're at it why not do

key = hex( rsa( anotherfunc(someOtherFunction(plainText)) + someOtherFunction(plainText) + hex (sha1( plainText ) ) ) )

and go to town...you could combine all sorts of functions.

Why is

key = hex( rsa( plainText + hex (sha1( plainText ) ) ) )

used over

key = hex( rsa( hex (sha1( plainText ) ) ) )

or

my over-complicated example

Cryptographic algorithms are complicated beasts where every single detail matters for security. Unfortunately, cryptographers do not have a simple test which can tell whether a given algorithm is secure or not. It is unknown whether, in a mathematical sense, such a test could exist at all; and, even if it exists, we have not found it yet. We do not even know if secure algorithms can exist in general. Decades of cryptologic research has come up with a lot of partial solutions, such as "security proofs" which reduce some problems to other problems (e.g. a proof that the Rabin cryptosystem cannot be less hard to break than integer factorization -- which does not imply that integer factorization is hard).

So the normal methodology is to have some cryptographer publish a proposal, and let others try to break it and then potentially fix it. When an algorithm has been subject to such external scrutiny for some years and still survives, it is deemed "usable".

The case of RSA is a good illustration. Its mathematical description was first published in 1977, but it was only the core principle, with the modular exponentiation. To turn that into a secure algorithm for asymmetric encryption, or a secure algorithm for digital signatures (not the same thing at all), one must add some other elements, including random bytes, hash functions and behavioural constraints (e.g. whether it is good or not to report a "bad padding" error upon decryption). A number of hastily slapped together proposals turned out to be unsatisfactory. After a long trial-and-error process, RSA (the company) produced PKCS#1 v1.5 in 1993. This standards tells you exactly where each byte goes, including hash functions and random bytes. Although it seems rather sturdy, it turned out, in 1998, to have a weakness which could reveal the private key if the implementation, upon decrypting data, was too talkative about error conditions, when decryption fails.

This prompted new versions of PKCS#1, v2.0 in 1998, v2.1 in 2002, and v2.2 in 2012. What v2.0 describes appear to be robust for encryption; v2.1 extends it for signatures, and v2.2 adds some glue for newer hash functions. Not that a properly implemented PKCS#1 v1.5 would be weak; but the newer versions (called "OAEP and PSS paddings") benefit from partial security proofs (which, by the way, took time to be actually proven; the first published proofs were later found to be erroneous).

This is how algorithms should be designed: with years of effort by people who are specialized in the subject. The lack of reliable test for security means that we have no better way, and even spending 20 years on a single widely-used algorithm does not guarantee that every problem was detected.

In parallel, there are a lot of people, in the computing industry, who do not follow this methodology. Instead of waiting for well-studied algorithms to be turned into standards, they just go ahead and slap together a few primitives, sprinkling hash functions and other elements in a seemingly random way. Their guidance is a few very vague notions of security (often badly misunderstood) and whatever they will find in other people's blog posts.

This is why you will observe, in practice, a lot of "homemade schemes" where some developers just went way too much creative. Almost all of these schemes are weak and breakable, but the exact reason why they fail depends on the context.

Why many developers act that way is a mixture of arrogance and ignorance (often more ignorance than arrogance), and the primary cause is that special property of security: you cannot test for security. This is what makes security, and in particular cryptography, quite alien to most developers: it operates differently than all other fields. When you write a Web site or a graphical application which does 3D rendering or an accounting system, you test for functionality: you check that things work as expected when faced with normal situations. In security, you must test for non-functionality: you must check that things fail as expected when faced with abnormal situations. The virtually infinite set of "abnormal situations" makes the usual Q&A processes utterly ineffective for security.

The best we can do is "spread the word", as this present message tries to do: don't do homemade crypto.

Summary: if you can give simple explanations of why a given assembly of the RSA modular exponentiation and hash functions yields an "obviously secure" algorithm or not, then you are due for a PhD or even a Turing award.


Read memory of a java application I need some starter advice here. Never done Java reverse engineering before, but I needed to somehow read the memory of a running desktop java application. The process communicates with an external server on an encrypted channel and fetches some files. The files as far as I know are Java bytecode meant to extend the functionality of the current application. I would like to know what are in those files, so I could later try to reverse bytecode to program code to get a closer look how it is to change the behavior of the application. Can you suggest a suitable debugging tool or tell me a bit about this methodology?

I usually use the Krakatau (dis)assember https://github.com/Storyyeller/Krakatau for examining and tweaking Java bytecode files.

The only way to get code into a JVM is to implement a class loader. The bytecode that goes into the JVM is, of course, in plaintext. So, disassemble the local classes first, locate the ClassLoader and hook the ClassLoader to dump the bytecode that would be loaded to a file (and possibly, load replacement code if you want).

Good luck, and don't do this in USA, as it is probably a DMCA violation.


PHP: Save e-mail address hashed or plain I've been wondering about something, is it more secure to store an encrypted (hashed with password_hash) email address in the database, or just as plain text? I've google'd this matter and saw that there are people who are for it, and against it.

So here are my thoughts; I think it would give a little more security. Ofcourse it's not THE defense needed, but IF someone ever gets into the database, all he can get are encrypted email addresses. To me, this sounds a tad better than plain text, right?

Also, I don't really see downsides on this one. Maybe the system will just be a bit slower, but security comes first imo.

So let me know what you guys think, hash it and save it, or just plain save it.

Hashing is a one-way function. Encryption can be reversed with a key; hashes cannot. The only time you'd use hashing is if you don't care what the value of something is, you just want to check that it's equal to what the user just typed in. In particular, if you hash the email addresses, you will never be able to send mail to the addresses. Since you want to send mail to the addresses, you cannot hash them.


Wipe free space or take image and wipe entire disk? Read some of the stuff here regarding wiping disks and securely deleting files. From what I've understood, after deleting (not securely) files they become part of the  unallocated(free) space of the HDD. So if I want to securely delete the deleted files
should I wipe the free space only or by keeping this link in mind What's a good secure file deleter
take image of the C drive and then wipe the entire drive and finally restore the image??

Disk: 500GB magnetic platter drive.

OS:   Windows XP

Filesystem: NTFS

Please help

I would recommend you to use something like dban which is a bootable linux distro specialized for exactly that purpose. It might take some time to securely erase your disk.


Message Authentication Codes (MACs) What is the main difference between Message Authentication Codes (MACs) and hash function?

Is there any difference regarding their usage domains?

The major difference between hash and MAC is that anyone can calculate the first, but only those with the secret key can calculate the latter. For example, in the HTTPS protocol, a shared key is established between the server and client, and with that key, a MAC can be calculated on the data transferred. No one else may calculate the MAC themselves and therefore they cannot modified the data without being detected. Suppose HTTPS use SHA256 instead, then anyone can just inject their own data and the corresponding hash themselves. The hash would only be useful to defend against accidental corruption.


Recover key in HMAC-SHA256 message authentication I am working on a demonstration of cookie security, where some important data is passed to the client along with a HMAC-SHA256 digest to prevent modification of the data. I would like to be able to show that using a weak key makes this easy to crack.

To generate the hash and data, here is a simple python script:

import hmac
from hashlib import sha256

message = "This is a long message that might be a little too long"
mkey = "password"
digest = hmac.new(mkey, message, sha256)
print(digest.hexdigest())
print(message.encode('hex'))

It outputs this data:

e3762ae7f3bc6c9f8906e5f1f2cd19e80d3ebd281bdd31119a66adaef33d3b3c
546869732069732061206c6f6e67206d6573736167652074686174206d696768742062652061206c6974746c6520746f6f206c6f6e67

Is there any tool that can help me efficiently crack the key? I could not find a way to do it in hashcat.

I could roll my own dictionary attack, but would rather use something off the shelf if it exists.

If you want to protect the message then you have a serious problem, because it can be easily decoded with:

crypto = "546869732069732061206c6f6e67206d6573736167652074686174206d696768742062652061206c6974746c6520746f6f206c6f6e67"
print crypto
print crypto.decode('hex')

But since you've asked to retrieve the password via dictionary attack, I made a script that decodes the hex to plaintext which is then used as a salt in HMAC along with passwords in dictionary and SHA256 to produce hashes(mimicking the original HMAC function) which are then compared to the targeted hash string:

import hmac
from hashlib import sha256

hashd = 'e3762ae7f3bc6c9f8906e5f1f2cd19e80d3ebd281bdd31119a66adaef33d3b3c'
crypto = '546869732069732061206c6f6e67206d6573736167652074686174206d696768742062652061206c6974746c6520746f6f206c6f6e67'
decrypto = crypto.decode('hex')
keys = open('dictionary.txt').read().split() # Specifiy the path to the dictionary file

def mykey():
   for i in keys:
     digest=hmac.new(i, decrypto, sha256)
     digest.hexdigest()

     if digest.hexdigest()==hashd:
        print 'password:', i
        break

if mykey():
   print mykey()

So if the password is in the dictionary, it will print it out. Tested in python 2.7. Also note that the words have to be one per line in the dictionary for this to work properly.

EDIT: Here is a more flashy version, in case you need it for presentation:

import hmac
from hashlib import sha256
from datetime import datetime
startTime = datetime.now()

hashd = raw_input('SHA256: ')
crypto = raw_input('HEX: ')
decrypto = crypto.decode('hex')
keys = open('dictionary').read().split() # Specifiy the path to the dictionary file

def mykey():
   for i in keys:
      digest=hmac.new(i, decrypto, sha256)
      print digest.hexdigest(), '-', i

      if digest.hexdigest()==hashd:
         print 'Password found:', i
         break
   else:
      print 'Password not in the dictionary.'

if mykey():
   print mykey()

print 'Time Elapsed:', datetime.now() - startTime


Where and how do operating systems save passwords for user accounts? Where do operating systems (e.g. Windows) save their passwords? Do they store them in plain text? Do they use hardware modules such as TPM? Are these methods generally considered secure?

Windows stores its passwords in what is called the Security Accounts Manager database, or SAM database. This is a file that exists in the registry and access to it is tightly controlled whilst windows is running; however, local administrators who can run processes as NT AUTHORITY\SYSTEM can access it - see where does NT store the SAM database?.

As for the hashes used, they are either the LM or NTLM hash. Various attempts have been made to break NTLM; however, LM is known to be broken, so Vista does not use it by default although earlier versions of Windows do. Microsoft also apparently encrypt the database to make it harder to analyse offline.

The key to password security on operating systems is reducing their chance of intercept, so it is also worth studying who and what can access this. In terms of Windows, LSASS, or Local Security Authority Subsystem Service is responsible for verifying and creating user credentials. Thus, any attempt to hook or replace LSASS is an attempt to grab password input.

In terms of the Login screen it used to be possible to redesign it using GINA DLLS - many people did this to support fingerprint authentication, for example. However, custom GINAs are amongst many things quite hard to write and pose a possible security risk, so Microsoft rebuild that in Vista: see the credential provider framework which removes the custom code 1 level away from the GUI objects, which is much safer (Vista did contain improvements, for all people's criticism).

Now, Linux. It's probably better to start with the architecture of Linux authentication - most modern linux distributions use pluggable authentication modules which can be configured for various databases, remote, local etc. These can be configured to be optional, or mandatory, or "one of many options" if you like. The default pam module validates users whose meta data exists in /etc/passwd (so that any program can query it read-only, for example to find the users' home directory) and the passwords are stored separately in /etc/shadow. Directly from wikipedia (shadow password):

  /etc/shadow usually contains the following user information:

  User login name
  salt and hashed password OR a status exception value e.g.:

  $id$salt$encrypted, where $id is the hashing algorithm
  used (On linux, $1$ stands for MD5, $2$ is Blowfish, $5$ is
  SHA-256 and $6$ is SHA-512, see the crypt(3) manpage.
  "NP" or "!" or null - No password, the account has no
  password.
  "LK" or "*" - the account is Locked, user will be unable to log-in
  "!!" - the password has expired

  Days since epoch of last password change
  Days until change allowed
  Days before change required
  Days warning for expiration
  Days before account inactive
  Days since Epoch when account expires
  Reserved

So as you can see, what you can use for your hashing algorithm on Linux is entirely optional. The security of the /etc/shadow database depends entirely on whether you can become root, since the root user is granted access.

Both operating systems essentially hash passwords using a variety of techniques (crypt() in default DES mode I think was one of the first to repeatedly apply a hash to make checking hashes slower) - this is critical, as encrypted passwords could be trivially reversed by finding the encryption key. Clearly, in both cases, the security of the entry of the passwords depends on your ability to penetrate highly privileged areas; thereafter, the passwords are hashed and must be cracked using hash reverse techniques such as rainbow tables, which the hash design is built to counter.


Do file-encrypting software give a false sense of security? I sometimes use a VeraCrypt volume to store personal data (mostly backups from another computer) on a Windows computer I don't own.

But I learned over the years that modern OSes store users' data in a lot of unencrypted locations :

image thumbnails are created and stored somewhere in AppData,
data that's in the RAM can end up in a swap file on the disk,
a lot of softwares save backups of the files they manipulate, often to be able to recover them if a crash occurs.

The only secure setups seem to be : an encrypted external hard drive, which doesn't contain cache folders, or a fully encrypted system, which has become pretty difficult to achieve with UEFI on Windows.

What is the point, then, of softwares like AxCrypt, VeraCrypt or TrueCrypt, which encrypt single files without encrypting the whole system, if the OS leaks enough information to enable anyone to know what's in the encrypted volume ?

When & How to Properly Encrypt

When deciding where and how you want to apply encryption, it is important to consider what sorts of attacks you're actually expecting to prevent and whether or not the data you're encrypting actually needs strong protection in the first place.

This breaks down into three main factors:

Sensitivity of the data. A database of all your account passwords, specifics about your financial or medical histories, and pictures of your genitalia are all certainly in need of some amount of protection. That funny cat meme that you're going to post to Twitter, not so much.
Likely attack vectors. If you want to use encryption to protect your data, it needs to stay protected no matter where it is. This means keeping it encrypted whether it's on your computer, flying across the Internet, or sitting in some sort of cloud backup. This protects against burglars, state/corporate proxies, and cybercriminals, respectively.
Capabilities of likely attackers. Odds are, most of the burglars and cybercriminals who are going to want a look at your data will be opportunists. They won't likely be well-equipped or motivated enough to mess with trying to break or work around at-rest data encryption at all - they'll just move on to the next target. State-level actors or other APTs might not be so stymied, but they may also have other ways to make your life miserable even if they never get your data.

So, take that all together and here's what you do:

All Data At Rest on Your PC & Removable Media
Encrypt your entire hard drive(s). Don't leave anything in the clear. This protects the sensitive data in its primary storage location, as well as any local system caches or page files that it might get leaked to. As a side-effect, all non-sensitive data on the same drives is protected as well. (At least, until you send it somewhere else.)

All Non-Sensitive Data Leaving Your Control
If you're posting it on a public forum or social media, consider it already compromised and move on. If that thought makes you queasy, don't post it.

Sensitive Data That's Traversing the Internet
Make sure proper transport-layer security (not necessarily TLS, but it generally is) is in place to encrypt the connection between your PC and the remote endpoint. Also be sure that you trust the remote endpoint to properly handle and protect whatever data you're sending to it. If you don't, see the next section.

Sensitive Data Going to Someone Else's PC
There's a lot of ways that you might want to pass data to someone else's computer directly. It is also important to recognize that e-mail and cloud storage reside on "someone else's computer". If it's sensitive, and it's leaving your control, this is where tools like encrypted containers and files (herein referred to collectively as "file-level encryption") come in.

Why File-Level Encryption is Important

With file-level encryption, it doesn't matter whether the data is passing the network over a cleartext protocol or sitting on a computer that doesn't have whole-disk encryption. Regardless of where it goes, an encrypted file will always have a non-trivial layer of protection around it in its primary storage location.

This is not to say that the file's contents cannot be exposed while they sit in a clear cache, page file, hibernation file, or RAM. However, accessing these storage locations is slightly more difficult than simply reading the file from primary storage. It also requires a certain amount of luck, as any data stored in those areas is transient by nature.

Ultimately, how other people manage the computers that contain the data you send to them is beyond your control. This is why you shouldn't release control of sensitive data to people you don't trust to properly protect it. If you must release your sensitive data though, file-level encryption is about the best you can do to make sure it stays safe. At the very least (since the remote party could ultimately just decrypt the data and leave it in the clear) you'll be able to say you've done as much as you can.

A Note on Encrypting External Drives

Keeping all data on an encrypted external drive does nothing to protect it, that couldn't be equally accomplished by file-level encryption on an internal drive. As soon as you go to read that data, it'll get caught up in the same cleartext-by-default locations (caches, pagefiles, RAM, etc) that it would if it were stored on the internal drive. This is why you should apply whole-disk encryption to systems that handle sensitive data wherever possible.

On top of this, whenever the external drive is mounted, the decryption key will also land in those same areas. This is why systems handling data that does warrant encryption should never be put to sleep - only shut down or hibernated - and should have (at least) their system drives fully encrypted.


How much does a GET request over HTTPS reveal to an eavesdropper Correct me if I am wrong, according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client. its only after the tunnel is created that the complete GET or POST request is sent. What is initially sent is a stripped down version of a GET/POST request to initiate the SSL.

When the SSL is initiated, as for my knowledge, an evesdropper can only see the destination IP, source IP and the PORT in the TCP/IP packet. Everything else is encrypted. please do correct me again, if I have wrong idea about the same. This is merely a collected set of information to which I require confirmation.

If What I have said so far is correct,

calling the URL: www.websiteurl.com?username=name&password=PASSWORD

Should be perfectly safe as long as only an eavesdropper looking at the packets travelling between server and client is concerned. I know since URLs are logged everywhere in the local computer it can be dangerous. I am not planing to implement a system with this knowledge, but I do need to confirm if I know what I know correctly.

So would it be safe to send sensitive information over GET when using HTTPS after the SSL session is initiated with the server?

This question may have no practical implementation as sending sensitive information over URLs is not needed.

Correct me if I am wrong, according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client. its only after the tunnel is created that the complete GET or POST request is sent.

No, this is not a HTTP CONNECT, it is a TCP connection request. The HTTP CONNECT method is only used if you are connecting over a HTTP proxy and the proxy server's certificate is not trusted by the client browser. This will make future requests travel over the proxy as pure SSL data (encrypted), rather than as HTTP requests (decrypted on the proxy and then reencrypted for the destination journey).

  When the SSL is initiated, as for my knowledge, an evesdropper can only see the destination IP, source IP and the PORT in the TCP/IP packet. Everything else is encrypted. please do correct me again

Almost. They can see source and destination ports and IPs, and if SNI is enabled they can see the destination domain name.

  So would it be safe to send sensitive information over GET when using HTTPS after the SSL session is initiated with the server?

Yes, for these purposes. A MITM would not see the path or query string parameters on the URL, although as you mention it is easy for these to leak in places such as browser history, the logs of any trusted proxy servers (e.g. a proxy in a corporate environment that is trusted by the client machine) or possibly in the referer header.


Why is it called a stateful and a stateless firewall? I'm just wondering about the naming of these firewall behaviours. My basic understanding is that stateful filtering lets inbound traffic to return the outbound response without explicitly specifying the rule, whereas stateless requires that outbound rule to be specified.

I don't get it. Why is requiring explicit rules called stateless and the other called stateful?

You are almost correct. But stateful inspection allows you to have more control above data streams going through the firewall.

A Cybrary article says:

  Stateless firewalls watch network traffic and restrict or block
  packets based on source and destination addresses or other static
  values. They’re not ‘aware’ of traffic patterns or data flows. A
  stateless firewall uses simple rule-sets that do not account for the
  possibility that a packet might be received by the firewall
  ‘pretending’ to be something you asked for.

  A stateless firewall filter, also known as an access control list
  (ACL), does not statefully inspect traffic. Instead, it evaluates
  packet contents statically and does not keep track of the state of
  network connections.

  Stateful firewalls can watch traffic streams from end to end. They are
  aware of communication paths and can implement various IP Security
  (IPsec) functions such as tunnels and encryption. In technical terms,
  this means that stateful firewalls can tell what stage a TCP
  connection is in (open, open sent, synchronized, synchronization
  acknowledge or established). It can tell if the MTU has changed and
  whether packets have fragmented. etc.

They are named as such because they are really doing what the name means.

Stateless: don't remember any state, just filter the current packet passing through according to the rule list.

Stateful:  remember the state of the data stream passed through (what happened in all previous packets) and filter based on the same list as in case of stateless, but filter also based on state information.

The state information stored in the firewall memory allows you to do exactly what you asked before and much more.

You can add a rule that allows passing of the new incoming TCP connection inside (TCP packet marked with a SYN flag) and all established / related traffic inside / outside.

In case of TCP, the client (SRC IP/SRC PORT) sends SYN packet to the server (DST IP/DST PORT) to open the TCP connection. Firewall has a rule that this packet can pass (only new TCP connections to that server). Firewall now remembers the request to open the connection was sent to server (it remembers among others src IP, src port, dst IP, dst port and state of the connection - in this case CONNECT) and now expects only SYN/ACK packet from server side. No other packets of this concrete TCP connection can pass through it (in both directions). Server then sends SYN/ACK, firewall remembers HALF-OPEN state and expects only ACK flagged packet from client. Once the client sends ACK, the state of the connection is changed to CONNECTED and only packets with flag ACK (data) FIN/ACK (close connection) can pass through now. The same is happening during the connection closing procedure - so it is possible to have complete control above the protocol passing through and filter out invalid packets.

For TCP it's a bit hard to explain and understand. ICMP is much easier. There are two basic ICMP packets - ECHO and REPLY.

In case of stateful firewall you can ensure that REPLY can pass the firewall only in case the ECHO was previously sent.

In case of stateless it is possible only to control if ECHO and REPLY can pass through so the server can send REPLY anytime even if it was not asked for it.


Is National Insurance number considered for 2 factor authentication Is National Insurance number considered as something you have for 2 factor authentication as it is unique to each individual?

No, something like National Insurance number is "something you know".

It could be considered as a factor of authentication, however not a very good one because it is often disclosed by an individual.

"Something you have" should be something that can't easily be copied. Ideally a hardware token, however recently mobile phones with authentication via SMS and smart phones with OTP's with sync'd seed keys have been considered to be "something you have", even though the SMS could be intercepted, or the OTP seed shared between devices.

This is a loose definition of the phrase, however it is usually more than adequate for most people's needs. SMS wouldn't be recommended to be used if government snooping is a threat, and OTPs in a phone application should be carefully considered if this is the case.


OAuth2 and Authentication I see a lot of confusion about OAuth2 and Authentication so I created this question in the hope to clear some of the confusion. So, let's talk about the following points :

What is the difference between authentication and authorization?
What is OAuth2 meant to do?
Why is OAuth2 implicit flow insecure for authentication while still secure for authorization? (Tip : access tokens are not bound to a specific client)
What is the difference between OAuth2 implicit flow and Oauth2 authentication code flow and when to use which?
Does OAuth2 authentication code flow work for authentication?
Should you use OpenID instead of OAuth2 for authentication?
Why is google saying that their "OAuth2" framework can be used for both authentication and authorization.

  Google APIs use the OAuth 2.0 protocol for authentication and
  authorization.

https://developers.google.com/identity/protocols/OAuth2

OAuth2 Specification : https://tools.ietf.org/html/rfc6749

1.What is the difference between authentication and authorization?

Authentication is the process, by which a server checks if a user is indeed the user that it claims to be. This is usually done, when the user gives the username and a password, while the server checks these credentials (username, password) with those stored in its database, when the first user created its account.
Authorization is when one entity gives permission to another entity to perform an action. In this case, for instance, it's when a site wants to access data of a user, which are stored and owned in a different website.

2.What is OAuth2 meant to do?

Officially, OAuth2 empowers a user to allow a client website C to access his/her data from a resource server website RS after authentication via an authentication server website AS. This seems quite complex, so to simplify, a common example is when a user signs in a website using his/her facebook account. In that case, the client website and the resource server website are the same (C=RS=the visited website) and the authentication server is facebook (AS=facebook). Note that this was created, so that the C,RS do not learn the password of the user, while being able to authenticate him/her.

3.Why is OAuth2 implicit flow insecure for authentication while still secure for authorization?

The specificity with the implicit flow is the fact that the access token is given to the user-agent to forward to the application. So, it is solely based on the redirect URI. Thus, this flow does not authenticate the identity of the application, since there is no client secret confidentiality (access token exposed to user and applications running in mobile)

4.What is the difference between OAuth2 implicit flow and Oauth2 authentication code flow and when to use which?

As described before, in implicit flow the access token is forwarded to the application by the user-agent. On the other hand, in authorization code flow, the client web server gets first an authorization code (after the Resource Owner / user gave access), then makes a call to the API passing (clientID,secretID) with the authorization code to get the access token. This is done, so that in case of HTTP connections (no SSL encryption), the access token is not accessible to man-in-the-middle (routers,proxies etc.). So, the first one is suitable for mobile applications, while the latter one is suitable for server-side applications.

5.Does OAuth2 authentication code flow work for authentication?

Yes, the authorization code flow also authenticates the user through the authentication server.

6.Should you use OpenID instead of OAuth2 for authentication?

Yes.

OpenID is used for authentication. An example is when we want users to be able to sign in in multiple websites with a single set of credentials (signle-sign on).

OAuth is used for authorization, as desribed before. Note that OAuth can be slightly adjusted (as in the example before, where C=RS) in order to perform (pseudo-)authentication, via authorization. But, if we only want authentication, we can use OpenID.

7.Why is google saying that their "OAuth2" framework can be used for both authentication and authorization.

I guess the real reasons behind this design decision can only be given by the corresponding Google engineers, but I could assume that instead of using both OpenID and OAuth, they selected to use a single protocol for both usages, in order to simplify things. However, be aware of the fact that authentication via OAuth is being done by authenticating someone, through the data he/she possesses. A dull example would be that when I am trying to enter my job's building, I am not asked about my credentials, because my employee card is obviously in my neck. This is how authentication is being made via OAuth, quite simplified. So, you can see that this can make several assumptions that do not always hold under every scenario. And this is the reason that it is generally recommended to use OAuth only for authorization and use OpenID, should you also need to implement authentication.

A nice link describing the various flows of OAuth for reference


Burp Suite change value cookie I'm trying to change the value of a cookie using the Burp option, "Match and Replace". Here is my configuration:

Item:    Request header
Match:   cookieName:.*;
Replace: cookieName:myValue;
Type:    Literal.

Unfortunately, it does not work with this configuration. Do you have any suggestions?

I tried your match-and-replace rule out myself and identified two issues:

Based on RFC6265, the Cookie Header starts with Cookie:, followed by cookieName=cookieValue. This means your rule Match: cookieName:.*; Replace: cookieName:myValue; should instead read Match: cookieName=.*; Replace: cookieName=myValue;
The type should be Regex instead of Literal

This modified rule worked for me:

Item:    Request header
Match:   cookieName=.*;
Replace: cookieName=myValue;
Type:    Regex


Security on a REST Api used from a JS I am developing an application where I provide a JavaScript to my clients (stored on my CDN), and they can load it to their web pages via a script tag. This JavaScript does some checks on the DOM and sends the information to a REST API I provide (no user interaction needed, this is a background task). The clients who introduced the JavasScript into their web pages can login on my website and check the statistics I have collected via the JavaScript file.

I do not have a clear idea on how to make it secure, or even how much secure I can make it, as the only parts involved here are the script I provide and my REST API. No interaction between the back-end of my client and my REST API is required (at the moment, to be reviewed if no security at all can be reached).
I know I can not put any token or credentials on the JavaScript file obviously. The only idea I have is to check the "origin" of the request and validate it agains a whitelist, but I am not sure if even the origin can be tricked (I think it actually can be tricked), so having to maintain a whitelist for not reaching a good level of security seems a waste of time.

Does anybody know how other services (like Google Tag Manager or any other SEO utility) works to prevent intentioned fraud? How I make sure that requests pushed to my API are legitime?

Edit: My current context is that only the JavaScript and the REST API are involved. And that seems impossible to make it secure.
Which steps should I follow in order to make it secure? Involving the back-end of my client and using a public/private key pair looks good, but even in this way, I would need users to be logged in on my client's web site, in order to make the requests to their server secured and not public, right?

Thanks!

You can have an authentication backend, and users have to authenticate first, get a token, and use the token on subsequent requests.

Hopefully only your users will have credentials to your service (the exception being users with weak, leaked passwords), and the only ones able to interact with the API. But you should employ rate-limiting on the backend so bot owners will not brute-force the authentication backend.


Can Network Admin Make changes to site if I've accessed the site in edit mode? I connect to the Internet via a neighbor's wireless router (not a guest connection).

Windows 10: I don't share files or printer. Domain, private, public network: firewall is on. Scan = no issues.

I have a G Suite account to build sites. Site is published. Sharing options are secure. No other authorized users at this point.

Support asked for the URL of site builder in edit mode.

Two days later, many unauthorized changes to published Google site.
Is it possible for admin of neighbor's network to access or edit site if it's in edit mode?

Is it possible for the support person to use URL to access or edit site IF I have the site open in edit mode? Obviously, I can pull up the site in another browser screen, so wondered why support person with the link would be unable to do so.

Attempting to keep up with all the crazy, strange changes is eating my lunch. Need to ID the origin.

A network owner can (but is very unlikely to in a home network) see every byte that goes over their network.  However, the connection to Google Sites is encrypted through TLS (HTTPS). Those bytes would look like meaningless gibberish to them.

It is extremely unlikely that they gained access to your account simply by you connecting through their network, since Google is very good about this type of security.

The URL of a site's edit mode also does not contain sensitive account information. It may identify the account, as it identifies the site, but that is not enough by itself to gain access.

If the support person gained access, they did it with more information than the URL.


WPA/WPA2 networks cracks methods There are some software that states that can crack WPA networks, however that is not an easy task as the initialization code for WPA2 uses a four-way handshake to properly initialize all of the vectors that are used in the actual encrypting. So in order to properly break it you need to sniff the traffic that gets sent back and forth during a session initialization. However, because this is a WiFi it's not uncommon for packets to not be sniffed properly. So you should be aware that you may have to initialize the connection more than one time. Again, see the link I posted.

As for not knowing the carrier frequency there are a few ways to approach the issue. As the link pointed out they suggest getting an antenna. This is the best option when you're doing anything with WiFi. However, if you have reason to believe the access point is on a standard frequency discovering it could be as simple as an App on a smartphone to search for networks. But if you're doing this with any kind of frequency you should get an antenna and look for some guides on how to interact with it; they're all over the place.

Another approach would be to look at the client. Since you asked this question on an RE forum I'm assuming you have access to at least one of the access points so you can attack it from that angle and try to trace what happens when the connection is initiated.

Now If I try to protect my network, bacause neighbours didnt want to make a deal to get one internet account, and also I could not get a key easily, but have to wait like 6 hours.

What software or method have you used that acctually works?

First i would like to suggest that it seems like you forgot to post the link you were talking about, or i just missed it. Apart from that one basic approach, which definitely will work, assumed that you checked the requirements well, would base on exploiting the WPS (Wifi Protected Setup). To give you a short impression of how it works, you have to imagine that WPS offers a way to establish a connection by for example entering the WPS Pin (Aside this there are a bunch of other WPS Methods, like the WPS PBC [Push Button Configuration], WPS UFD [USB Flash Drive] and WPS NFC [Near Field Communication]). For educational purpose it suffices if we take a look at the WPS Pin-Method, take a look here for a documentation on how to connect to a router with WPS.
Wash
Wash is a utility that identifys WPS enabled Access-Points. It can survey from a live interface and will only show access points that support WPS. So as you can see a great tool for this purpose and some kind of derivate of airodump. For the official Wash-Documentation, take a look here.
Reaver
After you checked if the AP provides WPS based connectivity, you could exploit it using it using the Reaver tool, which all in all realizes a Brute-Force-Attack to crack the Pin and as the Pin in most cases does is not longer than about 4 Digits, there are only 10^4 = 10.000 different possibilities to try. Brute-Forcing this should take a couple hours, worst case. For the official Reaver-Documentation,take a look here.
So summarizing what we discussed till here:

Check if WPS is enabled for the target, using Wash-Tool.
Crack the WPS-Pin and use it to connect, because if you got the Pin, even the longest and most complicated WPA/WPA2 password is useless.


Is microcode physically able to mitigate Meltdown? I am aware that there is no microcode fix for Meltdown available (it has already been answered in various questions), and that the only extant microcode patches (IBRS and IPBP) only help with one of the Spectre variants, but I would like to know if a microcode fix for Meltdown is possible and feasible.
Specifically, I am curious whether or not:

Intel's microcode implementation is sufficiently capable to mitigate Meltdown.
Such a mitigation would be possible without an extreme performance hit.
A microcode fix is practical enough that, in the future, one may be released.
There is simply not enough public information to answer this question.

I already know that KPTI is the current "official" fix for Meltdown and that microcode and that new compiler instrumentation partially deal with Spectre. Disclaimer: I have not watched the 34c3 talk which may shed light on the limitations of Intel microcode, but I am aware that it has limitations.

I've seen a satisfactory answer on an LWN thread. Taken from a comment made by jcm:

  I doubt it’s possible in microcode. Let’s look at it:

  Speculative loads. Only thing you could do in microcode is turn off all speculation, or maybe cause every load to be serializing (similar).
  Branch prediction. You could turn off the indirect predictors (but that’s what IBRS does).*
  Permission checking during speculation. You can either turn off speculation or the cache, or kill the TLBs or you’re pretty much out of options.

  You can’t just replace random instructions in microcode, or add complex behavior, for several reasons:

  Not every instruction is microcoded. Fast path instructions don’t even touch the microcode sequencer.
  The patch RAM for the microcode is tiny and can’t carry anything like that kind of patch.
  Complex TLB and branch predictor logic isn’t under direct algorithmic control via microcode, only certain aspects of it are. You can alter behavior, tweak chicken bits, play with control signals...but you can’t add what isn’t already in the design.

  Microcode isn’t magic. It’s there to fix mostly run of the mill complex instructions that don’t behave correctly, or to whack chicken bits, and so on.

* This statement regarding IBRS behavior was disputed in another comment on LWN.


Router - is there anything to "wipe" before selling It's a Linksys WRT1900AC. Beyond resetting the firmware is there anything else I should consider as it's been used in a business. I'm thinking about personally identifiable information from a legal point of view. I would have thought not, but I keep getting people on eBay trying to fraudulently buy it, which made me think.

The only thing a router should store persistently is the settings you have changed. This includes the ESSID (network name), the wireless key, the administrator password, and any other credentials necessary for your use of the system (perhaps RADIUS credentials). A factory reset should clear all this information. Note however that low-end routers typically use cheap solid-state storage which can be problematic when it comes to data persistence. See this for example. Especially considering a router will not support TRIM or SED secure erasure, there will always be a risk that modifications to settings may be recovered via software by a moderately sophisticated attacker.

A router should not store anything that goes through it. On some routers, you can configure them to log DNS requests or save their system log to persistent storage, but this is generally only done if configured explicitly, and the storage target is usually external (e.g. a drive over a network or a USB flash drive). Even modern routers have an extremely limited amount of storage (16 MiB is not unheard of, and it's sometimes as low as 4). Unless your router is special or configured in a particularly problematic way, there is no reason to worry about logs storing sensitive information.

Note that this advice comes only from a technical point of view. From a legal point of view, the proper course of action depends on your jurisdiction and many other variables which may or may not be related to information security. I am not a lawyer and I cannot give legal advice. If you need to be in compliance with a particular privacy-related legal regulation, you should consult one.


Nmap scan giving different result to my iptables configuration I am running a simple webserver on a VPS, the only ports I have open are

80    - for HTTP (webserver)
12345 - an unusual port for SSH connection to administer server.

I wanted to see how my firewall appears to the rest of the internet so I did an nmap scan using the default SYN scan.
It told me port 1935 was open on my server - which I doubt is true, netstat shows nothing is listening on that port either, so I did a "full connect" nmap scan to try and get a more "truthful" result, but nmap is still reporting that port is open, can anyone give any idea why that might be?

$ nmap -sT -Pn  $(dig +short mydomain.com)

Starting Nmap 6.40 ( http://nmap.org ) at 2016-01-31 14:57 NZDT
Nmap scan report for 159.203.197.95
Host is up (0.058s latency).
Not shown: 997 filtered ports
PORT     STATE  SERVICE
80/tcp   open   http
12345    open   unknown
1935/tcp open   rtmp

Nmap done: 1 IP address (1 host up) scanned in 10.18 seconds

My firewall rules
$ sudo iptables -S

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 12345 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

I wanted to see how my firewall appears to the rest of the internet so I did an nmap scan...

Which means that you did not really scan solely your VPS, but that you have checked out the combination of your VPS and your testing system and lots of routers and maybe even firewalls in between. And of course the VPS is only a virtual system on some real hardware which again has a network stack.

This means that what you see might not fully reflect your VPS. It might show up ports as open which are not open on your VPS but gets intercepted somewhere in between. It might show up ports as closed which are actually open at your VPS because some other device/software is filtering the access.


Does anyone provide per-user warrant canary A recent trend is companies publishing warrant canary statements on their website saying something such as:

  We have not been compelled to disclose our private encryption key to any 3rd party

This is a clever way to defeat gag orders that often accompany required disclosure. The companies can't actively tell their customers about the intrusion. If the message is taken down, customers in principle would know that the company has been compromised.

I wondered today: does any company issue such a statement on a per-user basis? Imagine if every day at midnight, Gmail or Dropbox or iCloud sent a note in your inbox stating

  Over the last 24hrs, we have not been compelled to reveal the user data for username to any 3rd party

Does anyone do this? Any reason why not?

I am not a lawyer and this answer is my opinion
I couldn't find any legal authorities confirming or denying this, and I assume you speak about NSL-related canaries (those issued by courts to parties work differently).
My apologies for a long answer but it looks necessary to explain some background to answer the question.
First, National Security Letters (information seeking with gag orders) are authorized by 18 U.S. Code § 2709. The law allows the following:

(1) Prohibition.
— (A)In general.—
If a certification is issued under subparagraph (B) and notice of the
right to judicial review under subsection (d) is provided, no wire or
electronic communication service provider that receives a request
under subsection (b), or officer, employee, or agent thereof, shall
disclose to any person that the Federal Bureau of Investigation has
sought or obtained access to information or records under this section

The prohibition here is very specific, and it is very easy to formulate the canary the way that it does not disclose this.
However the situation with the individual user private key is different since it falls under communication monitoring, and is covered under 18 U.S. Code § 3123. Its (d)(2) contains the following prohibition:

the person owning or leasing the line or other facility to which the
pen register or a trap and trace device is attached or applied, or who
is obligated by the order to provide assistance to the applicant,
not disclose the existence of the pen register or trap and trace device or the existence of the investigation to the listed
subscriber, or to any other person, unless or until otherwise
ordered by the court.

Here the disclosure prohibition is explicit, and disclosing to the user the existence of a monitoring of their communication by means of compromise of their key would be clearly against the law.
Please also see this article if you're interested in the exact legal details how canaries work.
Update: this article confirms the above reason, explaining:

Such a practice would alert users who become targets of investigations
and cause them to withdraw their business from the company, thereby
jeopardizing legitimate inquiries into individuals who pose actual
threats to national security.

and

Granular canaries have the greatest potential  to  compromise
legitimate  national  security  investigations because  they  could
alert  the  target  of  an  investigation of  the government’s search,
prompting that individual  to cease use of the targeted  service,  and
to attempt  to erase  his  or  her  information therefrom. Clearly,
the government has a strong interest in preventing this outcome. Thus,
courts are less likely to find that these canaries are legal and are
more apt to uphold a gag order prohibiting their removal.


How to recover original excel password I know how to remove the password protection from an excel document, but I was wondering if there was a method to recover the original password. I have a document encrypted with a 64 character password and I've been searching for ways to recover it but have found none.

I would recreate the content found here but there really is no need because it is formatted so nicely. Basically, because the password is stored with the document, you can find the password hash pretty easily in a hex editor. From there, you can simply brute force it.


How to listen on all encrypted (SSL/TLS) traffic of a (Windows) system under your control? On one of my Windows machines (so I am admin and basically can do whatever I want with it) I'd like to analyse traffic which obviously is directed to a malware C&C server. The traffic is TLS encrypted and originates from an injected/infected service which I know (so I know the exact executable file which is causing it).

I'm generally looking for the best (and most light weight) approach here. Be it installing something on the Windows machine itself or using some kind of middleware/TLS proxy. Ideally the end result should be a decrypted wireshark compatible package dump.

I'm not only looking for a "light weight" solution because I want to have it as easy as possible but also because the malware I'm dealing with seems quite evasive. I already tried cuckoo and on a cuckoo VM it's not even trying to connect the C&C server. Same on every online "deep analyse" service. But as soon as it runs on bare metal Windows or custom made VMs which try to hide its VM status and has lots of hardware passthrough the C&C connections pop up.

I would know how to go about this if I'd like to listen on browser traffic (How does a Web Security Gateway analyse SSL Encrypted Traffic?) but I fear this will not work because the malware will have a cert hard coded and ignore root certs I install on the system which would be used by a TLS proxy. If my thinking is wrong and such a TLS proxy would definitely work please also let me know.

There's no way to guarantee the ability to listen to all TLS traffic from a given host. As you mention, the malware might not even use the system security store. It also might have a hard-coded certificate (or at least public key) that it is expecting, in which case it will notice any attempt at a man-in-the-middle attack unless you can steal the server's private key (or crack the public key).

You do have a few options, though. Since you're really only interested in cracking traffic from one particular program, this gets somewhat more plausible.

Attempt to reverse engineer the binary and see if there's a hardcoded certificate or key in it. If so, you can attempt to replace this key with the one your MitM uses. However, this will change the binary's fingerprint, so if it attempts to validate its own integrity you'll need to eliminate or patch that check, too.
Find out what crypto library the malware is using, and replace it with a "backdoored" version that logs all traffic to plain text. If it's just using the Windows libraries, you'll need to obtain or create such a backdoored one but it should be possible to force the process to use it (although, again, if it's checking the fingerprint or signature on those binaries then this won't work until you patch that out). If it's using a third-party library such as OpenSSL, you can replace that easily, though again look out for authenticity checks. If it's using statically-linked code, this approach is much trickier but might still be possible by dynamically patching the process image at runtime to replace the TLS code's entry point with a backdoored function (though this will require significant reverse engineering).
Attempt to reverse engineer the malware enough to just patch out the use of TLS, and tell it to send the traffic in plain text instead. The server obviously won't accept this, but you can use an invisible proxy that encrypts the outbound traffic (and decrypts responses) and logs the plain text both ways. Again, beware integrity checks, and also the server might expect a client certificate that you'll need to pull out of the binary.
Attempt to reverse engineer the program enough to tell what it would do from static analysis. This won't tell you what the server would say, but should in theory let you write your own client that the server will trust if that part interests you too. However, any half-competent malware author will include protections and obfuscations to make reverse engineering the binary very hard (this applies to all previous approaches requiring reverse engineering too, of course).