Preventing interaction among web application on a shared hosting account

Methods of Shared Web Application Server Compromise

Pretty much endless. Have a look at the Open Web Application Security Project's 2013 Top 10, (www.owasp.org) just for starters. If you're anything like me, you're already trembling.

Threat and Risk Assessment: Scope

A full threat and risk assessment would also take into account compromise of user authentication data, e.g. cross-site request forgery, because one compromised session could permit unrestricted access to the server if the account is not isolated properly. For example, consider a hacker exploiting a known vulnerability in a web application after having successfully hijacked a valid user's session.

Injury Assessment

What you're asking about is something that is more often considered in the highest-security scenarios: banking, finance, government, military... And in all of those cases servers with high-value assets are almost categorically isolated and not shared. The evaluation of what is high value is often made on the basis of three principles: confidentiality, availability and integrity.

Example of classic industry high-security scenarios

For example, for a bank, all the financial transaction data is highly confidential, very restricted in availability and its integrity is paramount. That's why most banks will isolate their server clusters by application and by relative interactivity. Then they will also make routine redundant backups of the information into geographically disparate locations, on equally secure clusters.

Threat Mitigation

The best methods to prevent server compromise are routine hardening:

the strongest passwords combined with multifactor authentication,
secure-signed kernels and software only, e.g. SELinux
strict controls using a software firewall like iptables defining which applications are allowed to use which ports in what direction and by what users, but also hardware-based firewalls,
active monitoring of the network traffic using a software like Wireshark6,
you can also use [intrusion detection and prevention systems, possibly even two or three such systems at the same time,
if you are safeguarding high-value information that is exposed to high risk (according to your threat and risk assessment), then physical security should also be considered as a fundamental factor (i.e. who has access to the datacentre, how are they cleared for access, how are keys managed),
you can find more information from NIST Special Publication 800-53 -- Anecdotally, I remember hearing a statistic that NASA had only implemented about 65% of these suggested controls by 2014, by virtue of how exhaustive they are.


SSO refers to a type of user experience, not a technology.  SSO is short for "single sign on" and refers to any scenario where a user signs on only once and can access multiple applications that are otherwise independent.

Examples of SSO systems include

Any social login, e.g. when you use Facebook or Google to sign on to StackExchange.
Intranet applications (e.g. your HR web site) that authenticate employees based on NT authentication
Sites using OAuth, which was originally developed for Twitter
Sites using SAML, which is a somewhat older standard
Any .NET site participating in Federated Identity

NT authentication does not have to participate in an SSO.  A standalone Windows computer may also authenticate you using NT authentication.  But in many cases (e.g. within your corporate network), that same authentication mechanism can be utilized by other applications to recognize you, so that once you are signed on to your computer, you are automatically able to use those applications.


What could be the source of various AVG "Exploits" (Rogue Scanner, Fake Video Player, Social Engineering, etc)?

Wrote as a comment first, but it quickly grew up and didn't fit :(

Your verdict shows the website which triggered it - quickprivacycheck.com. Please see http://www.avgthreatlabs.com/us-en/virus-and-malware-information/info/rogue-scanner/ - note that quickprivacycheck.com website is reported as being the #1 site triggering this exploit in last 7 days.

If you don't visit this website yourself, and have no idea what it is, you need to find out which software on your computer visits this website. The possibilities are:

You have some malware/adware installed - this could include software, browser plugins (especially browser toolbars), games etc;
You receive emails with images referring to this website via  tag, and your e-mail client automatically loads the images (this is generally bad idea);
A website you routinely visit is now infected. This is not unusual; you can scan it on virustotal.com (click on URL tab);
A website you routinely visit shows content from a 3rd party website which is infected (ads, news, widgets). This happens more often than above, and even major ad networks could serve malware.

Finally, there is also a possibility that the website is clean, and the verdict is incorrect. This is called "false positive", and also happens once in a while. I do not see any verdict for quickprivacycheck.com in our database (disclamer: I work for Bitdefender), and the site main page returns an empty HTML file, so I can't analyze it. Still there's a possibility which should be accounted for.


Possible security risk with disk encryption key getting swapped to the hard drive

Not every part of the memory can be swapped (or correctly paged) to disk. Proper code dealing with sensitive data like encryption keys will mark the relevant part of the memory so that they will not be paged. This is true for both user-space and kernel-space encryption.

Which means you can find such key in memory but with proper applications you will not find these on disk. And I would think that FileFault on OS X and also dm-crypt and similar stuff on Linux behaves safe in this area.


QR codes contains data that most phones can read when they take a photo.

For example, the following QR code contains a link to your question.

As a human can't easily read a QR code, he requested you to use your phone to help him to read it. The digit sequence you saw was the data he needed.

You are not in danger.


Android Isn't Android
Android rooting is tough to fix due to the nature of Android.  Because Android is open source, each manufacturer (Samsung, Motorola, Nokia, etc) takes the base Android OS and modifies it:

Drivers to work with specific hardware
Custom messaging, call, or system apps
GUI changes to make their phones unique
System backup mechanisms

Then the manufacturer gives it to the Vendor (Spring, Verizon, T-Mobile, etc), and the vendor will make their modifications:

Voice mail
Other backup mechanisms
Over the air update services

By the time you get your phone the original Android OS is twisted into something, almost entirely different than Android.  Take a friend's phone from a different network or provider.  I guarantee the Settings app is different, and there are different GUI changes to it.
Root Exploits
So how does this affect rooting?  Every time Android is added to introduces new attack vectors for vulnerabilities.  If you look up "How to Root Android" you'll find that not every phone is supported by every rooting procedure.  And by "supported" they mean "vulnerable".  A Samsung Galaxy S3 might be rooted with one program, and a Motorola Razr is rooted with another.
Some root exploits work across platforms, some work across Android versions (each version of Android that's released adds new attack vectors).  The Android team most likely fixes root vulnerabilities (this is speculation).  But do those changes get propagated to the manufacturer and/or vendor?  The manufacturer adds so much driver  and GUI code that if a vulnerability is found at that level there's nothing the Android team can do about it.  It would be up to Samsung, for example, to fix it.  Then it would have to push the patch to each Vendor.  It could be a year before the users see the patch, and by then most people have new phones with new software.
Rinse and repeat.
Now too be clear, I'm sure that when Android pushes out a security patch the vendors and manufacturers take it seriously.  Those changes most likely make it in to their final build.  The point I'm trying to make is that there is not a lot of transparency between these stages, and I don't know for sure what actually happens for a patch/version release.

Universal Rooting Procedure for Nexus 7 and Motorola Razr HD by XDA Developers.  Notice how this "Universal" procedure only applies to two devices?


How to make an iPhone app HIPAA compliant?

I can't give you the full answer, but the short version that the lawyer at my previous hospital gave me was:

SSL will protect the data that is being transferred, however, anything that is cached to the SD card/Hard Drive is not encrypted...

So, when looking at this application, you will also have to encrypt what is stored on the phone by the app.  If you have ever plugged an iPhone into your computer (or a friends), you have access to the full set of storage (including the OS), which means anything cached is available if the phone is lost.

I would look carefully at encrypting at least any PKI, PHI or PII that your program provides to the device.

The problem is that even if the program doesn't store data, the web interface can cache data going to and from the device.  This is the part that could cause you problems.


Is taking a screenshot of my VPN settings safe?

Its not a good security practice to share your personal stuff online.
There is no problem in sharing screenshot unless you are sharing your vpn's configuration file.


I would not use Selenium as there is an entire class of scripts called Grease Monkey scripts that automate repetitive user task.  See TamperMonkey for one of many examples.


Windows .NET equivalent to Linux /dev/random

There is no built-in file-like interface to a source of randomness or entropy, if that is what you mean.

Unix-style operating systems such as Linux try to fit everything in a file, but Windows doesn't adhere to that approach and uses a function call instead.

This page has a random device driver to create a file like /dev/random on Windows. I don't know how well that works, and it uses RtlRandom and not CryptGenRandom.


It depends on your definition of firewall, and you're definition of run.

The actual packet interception is done in kernel space, before the packets are seen by any user programs. The network stack is in the kernel, so naturally filtering on that network stack also has to be in the kernel. You could build a userspace network stack, but it's a lot of work with no real benefit, and nobody does that anymore.

So by that definition, all modern firewalls run in kernel space.

Except that there are userspace programs for managing the firewall rules. The word iptables refers sometimes to the "netfilter" component of the kernel, and also a userspace program called iptables for managing netfilter rules. There are similar stories for other OSes.

But it gets even muddier because most modern OSes support the ability to send packets to a usespace tool for inspection, modification, etc. So while the initial interception happens in-kernel, the kernel outsource part fo the firewall tasks to userspace programs.

And even less clear when it comes to what qualifies as a "firewall". From a purist point of view, a firewall runs at layer 3† it can do basic state tracking for TCP and can even scan for FTP port associations, but it's not parsing HTTP requests. That's not to say that a box you've designated as "the firewall" can't do it, though. It's not uncommon to associate a "firewall" device with a transparent HTTP proxy and cause all sorts of headaches for your users in the name of security. This, of course, is definitely not in-kernel. That's not to say that it couldn't be. But nobody does.

†: In addition to iptables, there's also ebtables, which does the same thing but for ethernet frames.


What is required to verify that an x509 cert matches a key?

How can I validate, that the cert certifies exactly that key?

A certificate does not "certify" a key. What you describe is to check if the private key matches the public key in the certificate and thus can be used to prove ownership of the certificate against a third party. And yes, it is enough for this to check that the public key you have in the key pair is exactly the same as the public key of the certificate.

  What happens if a possible attacker, having access to the cert, simply re-writes the pubkey part in it?

In this case the issuers signature of the certificate will not match anymore and the validation of the certificate will fail.


Creating a website to test my scanner that I scripted

Are you sure you need to have an externally hosted website? A lot of the testing I do happens on a virtual machine -- I install a flavor of linux, apache webserver, the software package, and fire away. With a virtual machine, you have the following assurances:

You will not disrupt other people's websites.
You will have access to all logs and all parts of the system.
You will be able to conduct your work privately, a key part of the responsible disclosure process.
You won't piss off your hosting provider or Wordpress.
You don't have to pay money. (Whoo-hoo!)


How are ACK storms created and what's a good mitigation strategy for them?

When a client and a server connect to each other, they know the connection by its source and address IP addresses, and its port numbers (on client and on server). There are two sequence numbers for both directions of the connection flow; their initial values are chosen randomly. Whenever one of the parties sends a packet, that packet may talk about both sequence numbers: a packet from the client may include information about the sequence number for the client-to-server flow (e.g. a "PUSH") but also information about the sequence number for the server-to-client flow (an "ACK").

If the attacker can make it so that the client and the server disagree by a wide margin on both sequence numbers, then a ACK storm may occur. Basically, the client sends a packet to the server with a server-to-client value that the server finds ludicrously off-the-mark. The server responds with a packet which says "dear client, you are sorely mistaken about the current server-to-client sequence number, pray be so kind as to amend your ways". However (that's the nifty point), that packet will also include an ACK from the server which documents the server's notion of the current client-to-server sequence number... that the client will find preposterously invalid. This will prompt the client to respond with a packet that says "dear server, you are sorely mistaken about the current client-to-server sequence number, pray be so kind as to amend your ways". That packet will also contain an ACK. And the loop goes on...

The storm rages until one of the ACK packets is lost, ending the ping-pong match. However, it will start again the next time the client or the server has anything to say, because they are still desynchronized.

ACK storms thus rely on the ability to desynchronize the client and the server for both sequence numbers. This can be done with semi-MitM abilities: e.g., the attacker can observe the packets between client and server, and also inject some fake packets, but not block existing packets. This is the model of "the attacker is on the same LAN, and the switch is in fact a hub (or has been demoted to hub-like behaviour after having been spammed to death with random junk packets from the attacker)". When the attacker sees a connection from client to server, he immediately sends a fake RST packet (as if the client had closed the connection) then a new fake SYN purportedly originating from the client, with the same port numbers, but widely different sequence numbers.

See this presentation for some details.

Defence is relatively easy: either of the systems engaged in a ACK storm can detect that it receives and sends inordinate amounts of error packets for a given connection, and simply drop it. The ACK storm can keep on only as long as both systems are ready to respond an ACK for an ACK; at the first lost packet, the storm ceases. If a storm is detected, then: 1. the system who detects the storm can stop it by refusing to participate to it any longer, and 2. the connection being unsalvageable, it can be unceremoniously dropped.


A four-digit code has 10,000 possible values.  If the users are picking their codes randomly, then the birthday paradox says that it's virtually certain that some of them have the same code.

But assume there are no duplicates.  This generates the second-best-case scenario for an attacker: any given code has a 200 in 10000 chance of being correct, or 2%.  After about 34 tries, there's a 50% chance of having gotten in.

The best-case scenario for an attacker is that users pick memorable codes.  In this case, punching in "1234", "9876", and "5555" is virtually certain to open the lock.


How to sync with multiple authentication services?

If your application is constrained to a single LDAP server and does not have its own pluggable authentication, you will need a directory server with a pluggable back end. This architecture enables a single directory server to access multiple types of account databases/directories and expose them via LDAP. I would recommend OpenLDAP for this purpose.

Since the three products you mention are implementations of LDAP and are generally compliant, you can proxy those services using OpenLDAP's Metadirectory backend.

For services which aren't LDAP-compliant, you can use the Perl/Shell backend. The Java API may be a more stable long-term solution, but you can quickly prototype solutions with Perl by creating a module for OpenLDAP and importing other open-source Perl packages to do the heavy lifting of authentication. This backend also allows executing external binaries via the shell.


Integrate OData pentesting tool to ZAP add-on

ZAP already supports OData in the spider and active scanner, which means that all existing active scan rules (such as SQLi ones) will work with OData:

https://github.com/zaproxy/zap-core-help/wiki/HelpStartConceptsSpider#odata-atom-format
https://github.com/zaproxy/zap-core-help/wiki/HelpUiDialogsOptionsAscaninput#build-in-input-vector-handlers

Having said that I'm sure theres more that can be done, so be very interested to hear of what else your add-on will be able to do :)


Are repeating random patterns weaker than non repeating random patterns?

Here is line #950 of file /etc/john/john.conf, which contains rules for creating passwords to test:

# Try strings of repeated characters.

So I would say that, yes, there is an increased risk at choosing repeated patterns for a password, as some cracking tools do take this possibility into account.

Regardless of that, I would not advice people to do so anyway; if an external attacker may not know that password are made of repeated patterns, an internal person of my organization could be tempted to get unauthorized access to another account. Or information could leak anyway, and an external attacker could know about it. Your first example u7I*u7I*u7I*u7I*u7I*u7I* has only four bytes of entropy, it's very low.

Still, if you had to choose between u7I*u7I*u7I*u7I*u7I*u7I* and u7I*, I guess first solution would still be better, but that's far from ideal.

What about suggesting to users to use a password managing tool instead?


How can I add a MISP STIX feed to LogRhythm?

I figured it out. Basically the version that the Threat Intelligence Manager expects is something like 1.0.1 and the version that MISP supplies is something like 1.1.1. There is no way to adjust the version of the output on MISP, and there is no way to adjust the version of the input on the Threat Intelligence Manager that I can see. What I ended up doing is writing a script which fetches the IoCs from the REST API, parses the file, and stores the IoCs in a text file in LogRhythms feed import folder located at "Program Files\LogRhythm\LogRhythm Job Manager\config\list_import". Then you need to add lists in LogRhythm's Console by going to the list manager and configuring the list to auto-import from the text file with IoCs in "Program Files\LogRhythm\LogRhythm Job Manager\config\list_import".


Is the client's private key is not required?

The TLS key exchange has nothing to do with authentication using client certificates, i.e. it is fully independent from it. This means both RSA key exchange and DH key exchange can be used with or without authentication by client certificates.

Client certificates are requested by the server but only if the server is configured accordingly (usually not the case). Only then the server will issue a CertificateRequest and the client will provide its own certificate and only in this case it needs the matching private key.

In more detail: the certificate is send in clear inside the ClientCertificate message. Additionally the client uses the private key of its certificate to sign the previously exchanged messages and sends this signature inside the CertificateVerify message. This way the client proves that it owns the private key matching the certificate. See TLS 1.2 section 7.4.8 for details.


Where can a virus or other malware "hide" on common PC and Mac hardware?

How about Firewire DMA? Firewire (a.k.a. "IEEE 1394") allows direct memory access by at least some kinds of devices.  People have writte lots of attack tools for lots of devices over the years, so it should be possible to hide in a Firewire device.

To confirm your PCI device hypothesis, it looks like John Heasman implemented a PCI rootkit, which pretty much has all the properties you'd need to write a virus.

Another place: the ACPI BIOS. John Heasman also seems to have implemented an ACPI rootkit.  The presentation gives example code fragments for other evil things.


SSH says Authentication tried for XX with correct key but not from a permitted host

Some more details would be great to go along with this question...

But in the meantime are you aware of the ability to turn off password authentication in ssh?  If you want to make sure the only access to your machine comes from a proper and mutually agreed on ssh key configuration just set the following flags in your sshd_config

 ChallengeResponseAuthentication no
 PasswordAuthentication no
 UserPAM no
 PubkeyAuthentication yes

Then restart the ssh service.

As for the message in the log... have you seen this?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607602

Granted it's not exactly the same as you've described as you note the key isn't in authorized keys at all.  Though might be safe to assume the error message is just poorly worded or is being applied too broadly.

Good luck!


Verifying installers downloaded over HTTPS

An attacker with a Man-in-the-Middle position, able to silently intercept and modify HTTPS traffic (which is infeasible in practice), would indeed be able to serve one user a modified executable with a modified hash and a compromised GPG key.

But if one were to be truly paranoid, then they would not download the GPG key that created the signature via the same connection that they used to download the executable. Instead, you would download the executable, for example, at home, and then download the GPG key in an internet café.

As you can tell, this is not really done in practice, and ususally there is no need to do so. TLS, if configured correctly, is considered secure in practice by today's standards.

So what to do in practice?

In practice, you have several options:

Option 1: Disregard hashes and GPG signatures and trust that the download will be fine.
Option 2: Verify the attached checksum to make sure the download didn't have any errors. This is what I personally do with OS downloads and the likes.
Option 3: Download the GPG key, do gpg --verify and see if everything is okay.
Option 4: Download the executable on one machine, then move to a different location to download the GPG key. Then physically meet with the maintainer to verify the key fingerprint. Then proceed to verify the download.

As you can see, the examples become ever more complex, in order to mitigate ever more ridiculous risks. In the end, you have to choose your own level of paranoia.


Improving Digest Authentication using PBKDF2

PBKDF2 is a burden. That's the whole point. The thousands of iterations, by design, burn up massive amounts of CPU.

Apart from that, your scheme is indeed an upgrade over plain Digest authentication, but it does not fix everything. In particular, what the server stores (the HA1 value) is "password equivalent": if you know this value, you can use it to connect to the server and play the authentication game. This means that if an attacker hacks into the server and steals a copy of the stored "passwords", then he gains immediate access to all accounts (i.e. the attacker transforms a partial read-only peek at the table, e.g. with a SQL injection attack or a mislaid backup tape, into a complete read-write access). That's usually considered as bad. Plain digest authentication already has this problem, because the server must store the password "as is". Your use of PBKDF2 does not fix that.

In any case, I hope that you play this protocol within SSL (HTTPS), because otherwise your connections can just be hijacked. And if you do play the protocol within SSL, then you can use Basic authentication, which will be even simpler for clients, and allows the server to apply PBKDF2 itself, and store the resulting hash which is not password equivalent.


The block size has to match the block size used by the server. Hence specifying 2 won't work, the sample size may be divisible by it, but it won't match the actual block size. Judging by the sample length alone I suspect it is not vulnerable.


Block to record http requests using recorder

You can intercept Facebook and any other website requests using burp or similar other proxy tools.

The error is probably that you didn't add the CA certificate from Burp/Jmeter to your browser trusted list of CA's.

Check this link on how to add Burp CA certificate in Firefox.

Also, you can add client certificates for extra layer of security. But even this can be intercepted in other ways.


Why were hyperlink auditing pings used for DDoS attacks and not any other requests?

There are some potential benefits of using <a ping>, but they are not unique to <a ping>. It is not outside the realm of possibilities that the attackers simply chose any working method to trigger network requests.

<a ping> works when JavaScript is disabled. But in this case the attack started with JavaScript. Even if JavaScript were to be disabled, there are many other ways to trigger a request to an external site, e.g. embedding images and stylesheets.
<a ping> requests are background requests. When the user leaves a page, the ping request will not be aborted. In this case, the attack relies on the page being around in order to send a ping every second, so this is probably not the main reason.
<a ping> requests' response body is ignored; the browser is allowed to immediately end a connection when a response body is sent by the server. This allows the attacker to carry out the attack with a low impact on the data usage, to make it less likely for the user to notice that their network is being abused.
<a ping> responses are not cached, so every ping will result in a request to the server. There are many other cache busting techniques to do so. The fetch API literally has an option to ignore the cache.
<a ping> requests are POST requests (and therefore not cached, see the previous point). This allows the same URL to be used. If random URLs were used (as a cache buster), then these may stand out in access logs. However, being a POST request is already somewhat unusual. Besides, these requests are uniquely identifiable by the "Ping-From" and "Ping-To" request header, as well as the more generic "Origin" header for cross-origin requests.

When I saw your question a few days ago, my first thought is "Why would there be a specific reason for doing so?". In the absence of any other probable answers, I guess that the answer is that there is no unique feature that the method provides. As said before, there are other methods with the above benefits, e.g. CSP violation reports, navigator.sendBeacon, fetch. There is nothing special about <a ping>.

The reason why you think that there may be something special to it is because a security firm posted an article about it, with a catchy headline and interesting write-up. Their final paragraph also mentions that these requests can be filtered, and of course they have a product that does it:

  Fortunately, web site and application operators have some control. If you are not expecting or do not need to receive ping requests to your Web server, block any Web requests that contain “Ping-To” and/or “Ping-From” HTTP headers on the edge devices (Firewall, WAF, etc.). This will stop the ping requests from ever hitting your server. (Note: Imperva DDoS Protection is already updated to prevent ping functionality abuse targeted at your sites.)


If I connect to a website using a cellular network, and change the sim card and connect again with the same phone, will they find its the same phone?

This is not true in general. Your connection is made via HTTP or HTTPS. Both don't carry your IMEI number. Some mobile carriers do transmit ADids, that are somewhat unique. It depends on your carrier wherever this id is generated from your phone number, your IMEI or not at all.

Other HTTP techniques such as cookies, flash cookies, local storage, your browser's cache (list incomplete) can still expose to the website that you're the same visitor.

If your carrier uses adids, than there is not much you can do except for using https on those sites (where it cannot be injected) or a VPN, which itself is an indicator due to the shared IP between sessions. If your carrier does not use adids you can clear your browser from cookies and similar or use it's private browsing mode.


LFI code execution when directory specified

Well, there may be many ways to do something like this.  I agree with the comments regarding doing some research into exactly what an LFI is doing, and looking a bit at RFIs to help understand the implicit differences.

As to your question, the answer would be yes, but strictly theoretical as we have no direct interaction with the application, therefore I do not know if the application is even vulnerable to other vectors that may come into play.

Without giving you the answer, as these types of vulnerable applications are for learning on your own, there are multiple ways to potentially execute PHP via LFI, most involving uploading a file in some way, but that's not nearly always the case.  Some examples: via some sort of stored comments, accessing the page via LFI and having the code execute; via uploading through some sort of file upload functionality and accessing the shell you uploaded via the LFI; via turning your LFI into an RFI (have you tried?); via escaping the command that's causing the file read (your injection point), and running PHP after it, and a plethora of other potentials.

Since you control the cookie and it's reflected directly into the PHP, have you simply tried cleanly closing the statement the cookie gets dumped into, and writing more PHP afterward?  This would be the first thing I would try when a value gets reflected, unmodified, into code in use on the server.

Hopefully this can be an answer 'enough'.  These types of questions are a bit subjective, but this may help.


How to bypass restrictive mac address filtering on home network (not malicious)

All though I think this is not the correct way to solve your problem:

What I would do is get another networking card for your desktop and a router that is also wifi capable.

Get a box that's DD-wrt/open-wrt capable and change the MAC address to the one of your desktop or just get them to insert the MAC address of your router. After that you can just use your own router as WIFI AP and physical internet AP. No you won't be able to discover other devices.

I'm not sure how the auto discovery function works, but I think it will scan devices in the same subnet. Since you are behind another router this will not be case. What you can try is to directly connect to the ip of the fileserver.


Return-to-libc attack with the argument read from registers (EDI/RDI)

What you're looking at is a PLT, which is a way of doing late-bound library imports. The "calling convention" of PLTs isn't standard, but the toolchain usually uses register-based parameter passing for performance, which is why you're seeing edi as the address of the string. The call will go to a stub in the Global Offset Table (GOT) which then calls into the library function.

The answer is yes, you can exploit this with a ret2libc, but not a standard one. You'll need to use a ret-to-plt technique instead, which is described in this paper (PDF). The point is that you use ROP gadgets to massage the registers into containing the right values, which can then call into the PLT.


BitLocker Drive Encryption NOT secure from drive mapping on network

You’re misunderstanding what BitLocker is supposed to protect against. The goal of BitLocker is to protect your data from cold boot attacks (as explained in a Technet blog entry).

When you unlock a volume protected by BitLocker, the system gains access to the keys necessary to decrypt the drive and behaves as if it was a regular drive.

That is necessary to make the system compatible with any and all applications (and drivers) without requiring them to know about BitLocker. (That’s why it’s called transparent disk encryption: applications and drivers don’t see it.)

This means you’re free to share the volume over the network and, if you carelessly apply no kind of ACL restriction on who can access the data, then everyone can access it freely.


Is it okay to store this health data in a public cloud?

Might be OK.  Some due diligence is required, and you might have to hire a statistician, and will need signoff from your legal dept.  Here's the rule:

De-Identified Information
De-identified data (e.g., aggregate statistical data or data stripped of individual identifiers) require no individual privacy protections and are not covered by the Privacy Rule. De-identifying can be conducted through
statistical de-identification --- a properly qualified statistician using accepted analytic techniques concludes the risk is substantially limited that the information might be used, alone or in combination with other reasonably available information, to identify the subject of the information [45 CFR § 164.514(b)]; or the
Safe-harbor method --- a covered entity or its business associate de-identifies information by removing 18 identifiers (Box 2) and the covered entity does not have actual knowledge that the remaining information can be used alone or in combination with other data to identify the subject [45 CFR § 164.514(b)].


SSL inspection is essentially a man-in-the-middle attack done with the approval of the owner of one end of the transaction; Alice thinks she is establishing a secure channel to Bob, but really she is establishing a secure channel to her employer Eve, who reads the traffic, then establishes a secure channel to Bob and passes it on.

In order for this to work, Eve has to generate and sign a fake certificate for Bob and use it to secure the communication with Alice. Eve is able to do this because Alice's computer has Eve listed as a trusted Certificate Authority. (Eve owns Alice's computer, so was able to add herself to that list.)

So, Eve is a trusted CA for Alice's computer. Except it's not actually Eve who's the CA, it's Eve's Cyberoam appliance. And the problem is that Cyberoam appliances all ship with the same default certificate on them, so Alice doesn't just trust Eve's Cyberoam, she trusts all Cyberoams.

This means that an attacker, call him Mallory, can buy a Cyberoam, dismantle it, and use it's fake certificate generator to make certs that Alice will trust. Basically, the work Eve has done to let her do a MITM attack on Alice and Bob's communications can also be used by Mallory to do a MITM attack on them.

To fix this, Eve needs to use a unique certificate on her particular Cyberoam appliance and not the default one it shipped with.

Eve should really have done this when she bought the appliance. Sure, dismantling a Cyberoam is hard, and even with the ability to forge trusted certs, a MITM attack is hard, so it is not a major risk unless Eve expects a determined and targetted attack.

However, generating a unique cert is a 30-second job and she should have done it. It will take Eve a little longer to do it now, since she has to replace the CA on Alice's list.

Lastly, to be fair to Cyberoam, it's not just them that ship with a default cert on their boxes. This is as much Eve's fault as theirs. As a general rule, if you're using SSL inspection, you are deliberately weakening the security of your network, and must take a lot of care doing it.


Is it possible to determine if some given data is not encrypted?

There are a few problems with the assumption that Bitmessage could be used as a kind of "Trojan horse" to introduce illicit content to your machine:

Individual nodes contain a mix of content from other users on the
network.  Therefore it is unlikely that an arbitrary node will have
all of the necessary pieces to reassemble illicit content.
Content is only cached for two days,  after this time the pieces of
content are removed from all nodes.
Bitmessage uses public key cryptography, such that only a recipient
of a message is capable of decrypting it.  Law enforcement should not be able to decipher the content on your machine unless you are the recipient.


How to identify the HTTP methods supported by a web server?

Per RFC2616, the OPTIONS method should return the supported methods. Keyword is should since this isn't always the case. As the prior posts have already pointed out each method needs to be tested separately to be sure.


Ever tried to access your google account over Tor?

Spammers want to e.g. register 1000 email addresses via script over Tor or from the same IP address and then send 1000 spam mails from each. Google doesn’t let them do that, detects automated access, makes them solve captchas or verify their identity by cellphone. Google probably also cries foul by spam mail 17.

So bad guys will use a provider that lets them do their thing with the least hassle. Also they will be unwilling to change provider if the have already scripts for that provider, methods for solving their captchas, etc.


How can I see ISAKMP packets via Wireshark on a client computer?

There are several other VPN protocols apart from IPSec. Specifically Tunnelbear and Cisco AnyConnect always use or can optionally use the OpenVPN protocol, which means you will not see any IPSec traffic in this case.


Making undeterminable containers inside existing file system

Data on hard disk has structure. That's a problem for you:

If your hidden containers don't use encryption, then inspecting the partition contents directly will show your hidden files. Such inspection is customary in forensics analysis, if only to recover parts of old files which have been deleted.
If your hidden containers use encryption, then the corresponding sectors will look random, and this will be suspicious, because "normal" filesystems don't store random data in unused sectors. The partition contents inspection expects finding some old file parts with detectable structure, and your container will show up as a statistical anomaly.

The "hidden volumes" of TrueCrypt solve that problem by being applied on a volume which is explicitly using TrueCrypt, which applies encryption on the whole partition. This allows the hidden volume to disappear into the randomish background.

As for your specific question, this is an allocation issue. If you never modify the outer filesystem, then you could do the following:

Create a sequence of 512 random bytes.
Fill the target partition with copies of that sequence.
Create the "visible" filesystem on it and put your few dummy files.
Unmount the visible filesystem, and scan again the partition: every 512-byte sector which still contains your random sequence is "untouched". You can use these sectors for your hidden container. All you need to do is to find the longest contiguous sequences of untouched sectors and mount them as loopback.

Of course, since the outer filesystem is completely unaware of your devious loopback usage, any modification to that outer filesystem may use some of your sectors: from your point of view, these sectors are for your hidden container, but from the point of view of the outer filesystem, they are free -- and that's by design. Your hidden containers are "hidden" only because nothing in the outer filesystem is aware of them.

(But this still does not solve the issues with statistical analysis, as explained above.)


In general, it's possible for a live CD to boot a computer without leaving any traces. In some cases, this is an important feature of them - forensic imaging discs, for example, could change evidence if they wrote anything to the internal drives (and even then, professional forensic investigators usually copy using a hardware write-blocker if at all possible).

Therefore in this case, your best bet wouldn't be to look for evidence of booting from a live CD, but to look for evidence of changes to the filesystem which seem unexpected - files modified on a date that you were not using the computer (e.g. weekends, for an office PC), or at a time that the computer should have been off. You could also run an undeleter, and see if anything you don't expect to have been deleted shows up.


SSL handshake: what makes it unforgeable?

1) I'm not sure what you mean.  There are numerous reasons a handshake could fail, however it should be noted that generally an untrusted certificate will not result in the handshake failing, but rather an indication of a lack of trust in the connection.  A shared session key can be determined even if the server being connected to is untrusted and fails certificate validation.

2) It could vary by client, but probably just in memory.  Yes, if the session key is stolen from either the client or the server, then the session can be monitored.  This is why it is important that your client machine be secure.  If the attacker controls the server or your client, SSL won't do you any good.  Note, this is actually how some enterprise firewalls work.  They use an SSL certificate on the firewall and then communicate the session key to both the server and the client so that all parties on the line can read the traffic.

3) As answered in #1, the lack of authentication of a connection is simply a failure to validate the recipient, it is not a failure of SSL to establish an encrypted tunnel.  You still have a secure connection between you and the third party, the identity of the third party simply can not be validated and is thus untrusted.


Consequences of tampered /etc/ssh/moduli

The /etc/ssh/moduli contains pre-generated group parameters for Diffie-Hellman. A DH key exchange occurs in the early steps of the SSH connection and generates the secret shared key which will be used for encrypting the data. DH works in a given group; technically, a modulus p (a big prime integer) and a generator g: the generator is in the 1..p-1 range, and it should be such that its order is a multiple of a "big enough" prime q. The order k is the smallest non-zero integer such that pk = 1 mod p. Discrete logarithm, and therefore DH, can be broken through with an effort which depends on both p and the largest prime factor of k (which we will call q):

There is a variant of the Number Field Sieve which breaks discrete logarithm if p is not big enough; current record is for a 530-bit prime and it is assumed that 1024-bit primes are still safe [Ed. Not anymore, see various blog posts about Diffie-Hellman dated 2015-10-15.], and 2048-bit primes will be safe for the foreseeable future.
Generic discrete logarithm algorithms apply with cost proportional to the square root of the biggest prime factor of k; so it is important (and sufficient) that k admits a prime factor of at least 200 bits if "100-bit security" is to be achieved.

An attacker who can modify /etc/ssh/moduli could try to replace the nice DH group parameters with other group parameters who look fine but make DH-breaking easier (or even easy) for him. There are mostly two ways to do that:

Choose a prime p and a generator g such that the order k of g is a product of only small prime integers. This can easily be done; for instance, begin by generating a bunch of small primes (say 80 bits each at most); then try random products of such primes: for each product r, compute p = 2r+1 and see if that yields a prime. If it does, then p is such that any generator g modulo that prime will imply weak Diffie-Hellman.
Generate a special prime p such that NFS is faster for that specific p. See this article for some theoretical background.

The /etc/ssh/moduli file does not contain the order of the suggested generator, so you cannot simply verify if that order is prime and matches g. However, you could take p-1 and apply the Elliptic-Curve factorization method on it: this will find all the small prime factors in p-1, and thus allow you to check that the order of g has not been weakened (k is necessarily a divisor or p-1). Thus, weakening of the first kind can be detected (albeit not in a matter of a few seconds). Correspondingly, attackers who do not like risk of exposure (in particular spy agencies) will refrain from using that method.

The second kind of weakening, however, is hard to detect. So one has to assume that an attacker who could somehow corrupt your /etc/ssh/moduli file (e.g. by altering the file as distributed with OpenSSH, through some bribery of OpenSSH developers) could, potentially, have introduced a backdoor allowing him to decrypt your SSH connections at will (SSH connections to your server, since the group parameters are chosen by the server). Since the involved mathematics are not simple, that attacker would, at least, be a competent attacker.

The only good countermeasure is to replace the /etc/ssh/moduli contents with values which you know to be correct and not malicious, by virtue of having generated them yourselves. ssh-keygen can do that (see the man page). You could also do that with some custom code (e.g. with Java's BigInteger class, this is a matter of 50 lines of code at most).

Alternatively, use DSA group parameters (they also work) which were generated as described in Annex A of FIPS 186-4: these are nothing-up-my-sleeve numbers because the candidate values for p are obtained through a deterministic, fully-specified PRNG, which, presumably, cannot be coerced into making a "special prime" which makes NFS easy. It would have been better if OpenSSH developers had used such a verifiable generation method to begin with.


What conditions would make you feel comfortable inputting your SSN?

A previously established trusted channel

In order for a channel to be considered safe, the priority is the user's feeling of trust, it's not sufficient for it to simply be safe. It also needs to be convenient, unless the user is absolutely desperate and locked in.

This pretty much means that you need to reuse a channel that the user already knows and trusts without creating or explaining something new.

The following avenues come to mind:

If all the users have existing accounts in your web system, then submitting SSN in it is just as OK as any other way - they need to trust you anyways, but a proper https website will feel adequate. It may be a bonus if the submitted SSN is not visibly stored, if their user profile only shows a checkbox "Yes, you've submitted your SSN, we've stowed it away someplace secure".
If the users have your mobile application, then they will probably feel secure inputting the data there, since there are no reasonable indicators for them to feel that your approach is less secure than e.g. their email on that device. It's your job to ensure that the submission actually is secure, but it doesn't influence the user impressions directly.

The suggested ways to submit over the phone seem less appropriate to me. Telling your data to an operator (likely minimum wage, possibly offshore) over the phone by itself feels a security risk; it could be argued that however your SSN gets there, those employees shouldn't have access to see it. However, there will be a segment of users, e.g. elderly people, who will prefer this channel anyway to anything digital.

Email with a secure link seems to be the worst option. While your email with that link may be secure, there is no easy way to distinguish that from a phishing operation, so such emails will be (and should be!) mistrusted by definition. The proper way would be an email that informs them to log in to your site in the usual way, and have a personal notification on your site take them to appropriate form when/if they log in.


How can a gmail recipient open email in two different countries, at the same time?

This is usually due to caching proxies being employed either on the recipient end by its ISP or the corporation your recipient is employed at, or by some VPN providers (if that's how the email was accessed), all either trying to save on bandwidth requirements, or otherwise control access to contents.

There are many such products available and solve various aspects of accessing contents on the Internet, so I won't be boring you with details. But they can be considered man in the middle type appliances, and go from mildly annoying to disturbingly alarming in ways they're employed. So even though I can't give any opinion whether this is due to something legit or illegit (your question is rather vague, so speculating on true reasons behind this happening is rather impossible), if such caching proxies are used, that would explain double recipients at the same time but in different geographic locations.

Best course of action would be to notify the intended recipient of your email through other channels, if you have reasons to suspect the latter to be the case and see what they make of it.


WinZip encrypted file vs password protected file

Both are using encryption. They have a bit of a bad reputation, since Excel and WinZip used to use dreadful encryption methods in the past. However, the latest versions of both use AES-128, which the US Government considers strong enough to use for SECRET information. You don't tell us your threat model (what you are protecting and who from) so we can't make any guarantees, but you should be OK with whichever is the most convenient.

However, two important points to note:

I am talking here about Excel's "password to open" option where you can't open the worksheet at all. The "password to modify" option does not encrypt and is trivial to bypass.
Information Security is more than just picking a strong encryption method. You also need to use strong passwords, manage the password exchange process, secure the endpoints, guard against social engineering, etc. etc. etc.


Will CA's revoke a certificate to phishing websites

First of all, this differs for each CA. According to a Technical Support Specialist at GlobalSign:

GlobalSign does not revoke certificate without the permission of the owner. [...] For phishing sites, our vetting team will perform security checks on the domain prior to issuance.

On the other hand, DigiCert has some other rules:

DigiCert revokes certificates for the reasons stated in the DigiCert CPS, including the following:

[...]

DigiCert obtains evidence that the certificate was misused;

DigiCert is made aware that a subscriber has violated one or more of its material obligations under its agreement with DigiCert;

A third party provides information that leads the DigiCert to believe that the code signing certificate is compromised or is being used for suspect code;

Furthermore, a certificate is meant to indicate that you are really connected to the right site. It does not give a judgement about the content or quality of the site. A certificate for fake-paypal.com is valid and correct if you are really connected to fake-paypal.com, even if that site impersonates the real PayPal.
Edit: DigiCert revokes certificates that have been "misused", but what this exactly means is open for interpretation. I think using a certificate for a man-in-the-middle attack is definitely misuse, but I am not sure about using it on a phishing site.


To answer your question about whether it's possible, I will say it is next to impossible to be completely anonymous online. I will address the major issues that lurk outside the realm of technology.

People make mistakes and even the slightest mistake will break the "completeness" of anonymity. Mention the weather or forget to enable your proxy and you're done for.
Behavior can be analyzed (e.g. slang and idioms may locate you).
Behavior can be correlated (e.g when you are home vs online)
You have to connect somehow. Everything between your body and your means of anonymity is exposed.
Some offline threat may out you.

I also have a philosophical objection to the concept of complete anonymity. Any behavioral pattern/tendency - no matter how subtle it is and no matter how many aliases you have - exists. That is your identity and it is out there for all to see. This doesn't just include having a public social presence either. What type of links you click, what sort of things you download, etc. per session may not be able to be easily correlated with other session, but it is still a potentially consistent pattern and you.

For advice on staying anonymous, I direct you to "How do hacking groups register domains remaining anonymous?". The concepts there can be applied to other transactions.


How can I challenge an attacker to reliably identify their hardware?

You may be overthinking the problem.

If you distribute a client to them, you can just query the OS directly. The best route is likely to ask users for their specs and query silently; they are unlikely to put forth the (rather substantial) effort to fabricate data if they don't know you are collecting it.

On Windows, you could query the Win32_VideoController class via WMI to identify their hardware. E.g.,

wmic PATH Win32_VideoController GET *

You could specify Name, PnPDeviceID, or DeviceID instead of * if you want to minimize the amount of data you collect.

Note that while this is a command line utility, WMI is exposed for application use; you do not need to rely on the native utility if you'd rather query directly.

This data is readable by locally-executed applications by default, and WMI permissions are rarely hardened due to their widespread use by regular applications as well as 3rd-party management tools.


Any thoughts on how we can prevent this situation?

1) Fraud is higher with CNP (Card Not Present) transactions, not the least because it's easiest to get away with.  If the purchaser says they never received it and files with the card company, the card company takes their side unless you have a signed slip - which CNP transactions never have.  So for that particular type of fraud, there's little you can do, except evaluate what it costs your business and adjust your prices to compensate.

2) Your processor (Cielo in this case, apparently) should be performing various anti-fraud steps to determine if the transaction is likely to go through or not.  Some processors work harder at this then others, so you may want to look into your alternatives for payment processing.  A processor that puts more effort in at that layer might cost more, but it might also be worth it.  (Disclaimer: I work for a processor, but know nothing at all about Cielo, and don't know if they're likely to be doing a good job for you or not - go forth and research).  These are steps that the processor can take but you really can't, because you don't have access to the same amount of information they build in the aggregate and the level of information they get back from the credit card acquirers.  So it's not a build-it-yourself type of thing.


How can I defend my mail server against ransomware?

To add to Julia's answer, this might sound a little bit cliche, but education is another strong point of defending against malware. Awareness of phishing links, even sending a global email to everyone with basics steps on how to be careful against emails does wonders. Surprising as it may sound, a lot of people don't even know that emails can contain scam or other far worse malicious intrusions. This is from social side.


Help me find the right Security Consultant for the stage our organization is in

Here's some background on the players:

CPA firms. Financial-world focused, they deal with CFOs and regulatory questions. Typically less technical in exchange for more business knowledge and being able to sign off on assurance engagements. Depending on the field you're in, other companies might not play with you if you don't have a letter from one of these. Because of their basic financial assurance, they are also found playing strong in other assurance fields like HIPAA.

The big 4 (down from 8) KPMG, Ernst & Young, PwC, Deloitte Touche. They all have specialist departments focused on IT. Their strength is in great depth and they can call up from around the world. Big doesn't necessarily mean better -- it's a price trade-off. you're paying extra for the insurance of somebody who "cannot fail". I've seen some signs otherwise, but maybe that's personal bitterness: http://www.healthcareitnews.com/news/maine-inks-179m-deal-medicaid-management Go here if your company is so large that you need more than 10 staff to get through your engagement.
The regional players: There are many, and they're filled with people who will go to the big firms or who came from them. Since Sarbanes-Oxley's independence rules, they get a bigger share of the pie. I work for one of the regional players, and regionals play in the Fortune 500 game. Go here if you're looking for expertise at a lower cost than a Big-5 and won't need enough feet on the ground to trample you. Beware that not all of them have deep technical knowledge. Most of them should have appropriate connections to other firms for specific parts of projects. (Say you're in Seattle - I might show up there once or twice, but if I need a lot of hands-on I might send somebody from another firm as part of a network). Shameless promotional pitch: http://bnncpa.com/

Boutique firms Specifically dedicated to IT, they may be useful for better internal development. Some industries will take assurances from a boutique as an outside vendor.

National / International firms Sourcefire, Rapid7 and IOActive fall into this category. They're probably closer in staffing to a larger regional CPA firm. Their customers are technology companies or suitably large IT departments.
Local players The rest of the world fills out this. Smaller shops that cover a specific region and have a more narrow field of experience. Their people probably are more generalized in their experience.

One really good way to get an idea of what's in your area is to take a look at your regional conferences for ISACA. In my case, http://www.isacane.org/events_detail.php?select=257 has a list of players form all of the above categories except the regional CPAs (boy, somebody dropped the ball there?). Besides that, you might also find actual specific recommendations if you poke around this site's chat room.


Does the VPN provider know my dedicated IP?

The VPN provider would already know your IP anyway.  While a VPN ends up hiding your IP from others (because they connect with the endpoint of the VPN), the VPN itself has to actually connect to your IP and knows your IP regardless of if you give them a log.  The log just lets them see what errors you are experiencing.


What can a RAT (Remote Access Trojan) do?

Taken from infosecinstitute.com:

when used for malicious purposes, they are known as a Remote Access Trojan (RAT). They can be used by a malicious user to control the system without the knowledge of the victim. Most of the popular RATs are capable of performing key logging, screen and camera capture, file access, code execution, registry management, password sniffing etc.

Since there are many varieties of RAT's, I suggest you start by reading the article I quoted and later if more information is needed a simple Google search will return a lot of information/research's that are relevant.


Are there any downsides to using Let's Encrypt for a website's SSL certificates?

Let's Encrypt is a Certificate Authority, and they have more or less the same privileges and power of any other existing (and larger) certificate authority in the market.

As of today, the main objective downside of using a Let's Encrypt certificate is compatibility. This is an issue that any new CA faces when approaching the market.

In order for a certificate to be trusted, it must be signed by a certificate that belongs to a trusted CA. In order to be trusted, a CA must have the signing certificate bundled in the browser/OS. A CA that enters the market today, assuming they are approved to the root certificate program of each browser/OS from day 0 (which is impossible), will be included in the current releases of the various browser/OS. However, they won't be able to be included in older (and already released) versions.

In other words, if a CA Foo joins the root program on Day 0 when the Google Chrome version is 48 and Max OSX is 10.7, the Foo CA will not be included (and trusted) in any version of Chrome prior to 48 or Mac OSX prior to 10.7. You can't retroactively trust a CA.

To limit the compatibility issue, Let's Encrypt got their root certificate cross-signed by another older CA (IdenTrust). This means a client that doesn't include LE root certificate can still fallback to IdenTrust and the certificate will be trusted... in an ideal world. In fact, it looks like there are various cases where this is not currently happening (Java, Windows XP, iTunes and other environments). Therefore, that's the major downside of using a Let's Encrypt certificate: a reduced compatibility compared to other older competitors.

Besides compatibility, other possible downsides are essentially related to the issuance policy of Let's Encrypt and their business decisions. Like any other service, they may not offer some features you need.

Here's some notable differences of Let's Encrypt compared to other CAs (I also wrote an article about them):

LE doesn't currently issue wildcard certificates (they will begin issuing wildcard certificates on Jan 2018) LE is now issuing wildcard certificates using the updated ACMEv2 protocol
LE certificates have an expiration of 90 days
LE only issues domain- or DNS-validated certificates (they don't plan to issue OV or EV, hence they only validate ownership and not the entity requesting the certificate)
Current very-restrictive rate limiting † (they will continue to relax the limit while getting closer to the end of the beta)

The points above are not necessarily downsides. However, they are business decisions that may not meet your specific requirements, and in that case they will represent downsides compared to other alternatives.

† the main rate limit is 20 certs per registered domain per week. However this does not restrict the number of renewals you can issue each week.


Why must a ret2libc attack follow the order "system(),exit(),command?

The ret2libc (and return oriented programming (ROP)) technique relies on overwriting the stack to create a new stack frame that calls the system function. This wikipedia article explains stack frames in great detail: https://en.wikipedia.org/wiki/Call_stack#Stack_and_frame_pointers

The stack frame dictates the order the function call and parameters are written:

function address
return address
parameters

So in your example you want to call system() with cmdstring and return to the exit() function when the system() call returns. So you write the following stack frame:

system_addr
exit_addr
cmdstring_addr

If you remove the exit address you change the stack frame to the following:

system_addr
cmdstring_addr
existingdataonstack_aka_junk

So now you're calling system() with a junk address argument and trying to return into your command string once the function completes. Which is why it fails. You can replace the exit() address with other data such as  0x41414141 which will cause a segfault once the system() call completes. Or you could replace it with the address of a pop pop ret location and then write more stack frames underneath. This is now a ROP payload. Here is a basic example of how that would look on the stack:

system_addr
poppopret_addr
cmdstring_addr
printf_addr
exit_addr
addr_of_string_to_printf

This would allow you to print something like You got hacked before exiting.


Distinguish the end-entity cert in a PKCS#7 (P7B) cert chain

CA certificates (V3) always include Basic Constraints certificate extension where isCA attribute is set to True. End-entity certificates either, omit this extension or include extension with isCA attribute set to False. Basic Constraints (RFC 5280 §4.2.1.9) is the most reliable way to differentiate CA and end entity certificates.
Here is an example of Basic Constraints extension for CA certificate in Windows Certificate Viewer:

an example of Basic Constraints extension for end entity certificate in Windows Certificate Viewer:


Horizontal vs vertical authentication bypass

Found the answer:

https://cwe.mitre.org/data/definitions/639.html

  Horizontal escalation of privilege is possible (one user can
  view/modify information of another user).

  Vertical escalation of privilege is possible if the user-controlled
  key is actually a flag that indicates administrator status, allowing
  the attacker to gain administrative access.


Regardless of what is contained in the paper a standard ntp request datagram does contain a timestamp that represents the time the datagram was sent. From page 22 of the RFC:

Origin Timestamp (org): Time at the client when the request departed
for the server, in NTP timestamp format.

The answer to the question "Does ntp leak system time?" is "Yes. A standard ntp installation will leak local time to all of servers that have been configured for time syncronization."

RFC 5905: https://www.ietf.org/rfc/rfc5905.txt

Addendum: As far as the paper goes the reference to NTP is whether NTP skew adjustments affect the timer in question. From the paper

  ICMP timestamps have a fixed frequency of 1 kHz. Their disadvantage is that they are affected by clock adjustments done by the Network Time Protocol (NTP)  [9], which makes estimation of variable clock skew more difficult.


What vulnerabilities do distros categorize as causing a program to "crash, resulting in a denial of service, or possibly execute arbitrary code"?

The label is pretty transparent, but yes, I think you are right in assuming it's mostly memory management problems. These are the most frequent cause of crash, as it will either cause the OS to kill the buggy process, or the program itself to crash trying to process corrupted data.

In most FOSS projects, you will be able to get more details on each vulnerability. When you encounter one, look closer to discover which type of bug it is.


Wrapping system call (in reliable and secure way)

Yes.  You use system call interposition.  One portable method is to use ptrace, though this can introduce a non-trivial performance overhead as it forces a context switch on every system call.  On Solaris, you can use /proc; /proc lets you specify the subset of system calls that you are interested in wrapping, which lets you achieve better performance at the cost of compatibility.

Take a look at Plash, Systrace, and Subterfugue, to see some worked systems that use these sorts of methods.  Also look at Chrome's sandbox, which uses a variety of mechanisms (including seccomp on Linux).


Normally one would need a shell, e.g. when logging in directly on the console, or in single user mode. Install a test system in a virtual machine and try it out?


Is cross site scripting possible with the img alt attribute?

You haven't mentioned how the attribute is quoted, so I've covered all possibilities of attribute quoting. This answer reflects the precondition that double quotes are already stripped as you mentioned in your question.
Yes, if the attribute itself is single quoted or unquoted:

and

are both vulnerable. The first is vulnerable to the following sequence
' onload='alert(&apos;xss&apos;)

so the tag becomes

and the second is vulnerable to this sequence
bar onload=alert('xss')

which will be rendered as

Regarding the attribute being double quoted, as well as restricting or encoding double quote characters (" --> &quot;), you will need to remove or encode the ampersand character (& --> &amp;). From the HTML spec:

Attribute values are a mixture of text and character references, except with the additional restriction that the text cannot contain an ambiguous ampersand
An ambiguous ampersand is a U+0026 AMPERSAND character (&) that is followed by one or more alphanumeric ASCII characters, followed by a ";" (U+003B) character, where these characters do not match any of the names given in the named character references section.

As you cannot guarantee that user controlled data will not contain an "ambiguous ampersand", you should either remove or properly encode this  characters.
Now whether an XSS attack is possible with access to only the & character to escape the attribute value, the answer is probably not.
If the value & is entered as your user data, and the tag becomes

and the &" will probably be interpreted as &amp;" by most browsers, so using this as an attack vector is unlikely.
However, it is best to do things properly when it comes to security, you never know if this escaping faux pas could be turned into something else evil by something such as mXSS.


PCI compliance is a bit complicated. Firstly, with shared hosting, you need the provider you're on to meet all their relevant requirements. See Has anyone achieved PCI compliance on AWS?

Second, whoever has a terminal that is processing cards is responsible being complaint. It sounds like in this circumstance, you're not the processor and don't have an agreement with a credit card company. In that sense, you don't need to be compliant (HUGE caveat following)

However, the person with the terminal does need to be compliant, and everything they use in the process of handling cards (including you as a 3rd party) needs to achieve compliance. Compliance requires active review -- the depth of which depending on the volume of transactions handled.

Most critically, I wonder what circumstance you're in that you would be storing credit card numbers and not actually processing them.

PCI compliance has to do with volume of transactions processed. Smaller volume shops don't have to worry about a lot. Large volume companies are only PCI compliant if they meet all the standards specified and they are signed off on by a PCI council approved auditor. VISA, for example, specifies those as anyone handling 6 million transactions a year.

There's a guide for merchants at https://www.pcisecuritystandards.org/merchants/how_to_be_compliant.php


It's a common method of (SEO) spamming to give fake referrers with the hope of being listed in some place or another, this might explain some of the entries.


Is it easier to get the original password if you have multiple hashes of it, all created with the same hash function?

A pure hash function is deterministic, which means that if you hash any given value, you should always get the same hash out. 5f4dcc3b5aa765d61d8327deb882cf99 is always the MD5 hash of "password". You can try it on different machines, with MD5 implementations written in different languages, and, assuming they are correct implementations, you should always get the same hash from calling md5("password") or the specific language equivalent.

However, that is a really bad property to have in a password storage system. To mix things up, better password storage methods use a salt. In that case, the string being hashed is changed for each record. Instead of everyone who used "password" getting the same output hash, the hash is generated of "password+salt" (or "salt+password", "pass+salt+word", or any other merging. Doesn't matter for this question), so you get a bunch of distinct hashes:

b305cadbb3bce54f3aa59c64fec00dea - passwordsalt
67a1e09bb1f83f5007dc119c14d663aa - saltpassword
9eee04c6cecbc87f7699823f559b820d - passsaltword

As can be seen, there aren't any particular common features in these, even using the MD5 hashing algorithm, which is a bad choice for password storage. (The pair of "b"s at positions 8 and 9 in the first two are just coincidental).

This is because MD5 is implements the "avalanche" effect - the change of a single input bit will cause a significant amount of the output to change (ideally about 50% for various analysis reasons).

All this combined means that even with the short salt used above, the only way to determine that the word "password" is in the three hash inputs is to try out all the possibilities.

This is dependent on the hash function used - you could construct a hash function where adding a similar salt resulted in a similar change to the output (so "passwordsalt" and "passwordsals" only vary by a small amount when hashed), but that isn't typical for hash functions used for password storage.

Furthermore, modern password storage recommendations suggest the use of something like bcrypt or scrypt, both of which generate a strong salt as part of the hash initialisation:

$2a$08$WCUycJKlopCnpbAoYIQBj.wlsQA3iC2QhLOBpMMVZZtSO8hsXP1SW
$2a$08$8s89Oz3AsJ.Dv.HAjIGKC.JdZJwzQUAkSX7Mels1Cc6Zwter.z7NO
$2a$08$r5lrQviZKBDgLS4z8OKVWOnlza16.tLDCqjq8pdQ1wY.iDSldXCFW

All of these are hashes of "password" - and having all three doesn't help you at all.


This is the same as a High Interaction Honeypot idea, but you seem to be asking about embedding honeypot elements in production systems. Even so, I believe that the best practices for honeypots would apply here.

As for your second bullet point, a Data Loss Protection system would seem to be a better way to go. You can monitor, track, and most importantly, prevent data from travelling to areas that it should not.

I use 'bogus accounts' all over my systems, implemented in various ways as a honey-trap. I personally do not believe they hold much value for me, but they are cheap to have, test, and monitor.


First things first, change your password and make sure the new password is secure (10+ characters, a number somewhere other than the last character, a capital somewhere other than the first character, not an iteration on your past password, etc). This is good to do periodically anyway.

GMail has tools for seeking suspicious account activity.  Specifically, look at your recent security events, which should list all of your active logins plus all logins from the last four weeks, including locations and browser fingerprints (e.g. one of them will say "CURRENT DEVICE" to represent your browser right now.  Are there others?).

Be wary about future attempts to obtain your credentials (somebody using your computer while you're logged in, a key logger, malware on your computer, or a phishing attack).


My computer was being remotely controlled by someone. Can find no viruses

There are a large number of remote control utilities.

VNC is just one of them.

Virtual Network Computing is open source so anyone can copy the source and include it as the payload of a trojan that they arrange to have installed on your computer.

Anti Virus software is not necessarily going to see everything. Something that is new or something that is a one off that is created for one job will not have made into yiour anti-virus signature files as yet.

Also, anti-virus software is not going to see the VNC part of the software as a problem.

If someone tricks you into installing some software that included this then they would be able to access your computer at any time.

Closing unused ports is always a good idea, but a trojan will probably be using a commonly used port like port 80 which is used for web browsers and web servers or will search for a unused port that is open. A Trojan that is well written could also only respond on a particular port under certain set conditions to prevent their being found.

If an attacker has had enough time to take over your PC and has made a variety of purchases through your web browser using your credit card details and processed confirmation emails, then they have had enough access and timew to totally compromise your computer.

I would think that there is no effective method of cleaning this up short of Copying all data to a secure external drive, wiping the hard drive and any connected data storage, including cloud storage that may contain re infection software, and reinstalling everything from scratch.

Make sure that any access to the backup drive containing all of you data is done in such a manner that you do not risk re infection.

You will also need to update passwords on any accounts the attacker had access to and replace all of your credit cards.


Ex-contractor published company source code and secrets online

First take screenshots of what you find.  For the data that is yours, you should catalogue that. Personally, I would download it so you have a reference.  You should take screenshots of your own data and avoid data that is not yours.  Make sure you include the URLs.  Document those in a way that a lawyer can understand.  This is likely to become a legal problem, not an IT problem. I say "screenshots" because that is unambiguous and lawyers understand screenshots.

Contact your internal lawyers, plus your communications or media people. You need to get this breach onto their radar.  The lawyers will then need to look into the commercial contract with the contractor, probably via the account management team if you work for a big old company.  No one in senior leadership will want to find out about it from everyone's favourite IDS: Twitter. Your comms / PR teams will need to deal with any messages that come about from this.  Your executive team may need to be involved.  You should get guidance from your CIO unless you are the CIO, in which case I would be inclined to inform people internally.

Engage with your company data protection officer.  That may be the lawyer.  They will decide if the breach is GDPR / ICO notifiable.  You have to do this quickly as you have 72 hours to make the decision from the point you are aware; that includes the weekend  (never go looking for incidents on a Friday…). Your DPO will advise.  If you are the DPO then you might want to engage your company external legal counsel to confirm your decisions.

Once you have looked at the data, you will be able to advice how many data subjects are affected, if any. You will also be able to determine if the data breach affects any of your clients as you may have a contractual obligation to inform them.

Contact the hosting company.  If it's something like GitHub then they may be inclined to play nicely.  You may need to get your lawyers to write to them as officers of the company.

Contact the contractor, ideally via their contracted company, and via the in-house lawyer. Demand they take down what is there.

Now you can start to work out the material impact to your business.  Credentials, keys and other authentication tokens will need to be changed I expect.

Depending on the size of your company, your appetite for risk, and your pocket size, you might want to consider bringing in a forensics-type company to go out hunting for similar data.  Yes I know it's a bit of security theatre, but if you work for a FTSE100 firm then a report with a Big4 audit badge saying "no more issues" is exactly what you need should the midden hit the windmill. (I am amazed at what I see big firms spend on such reports as, of course, the same thing from an internal person is often considered to count for little).

I am not sure about the data that is not yours.  If you start trying to engage with third parties then you are bound to be asked what data you have got from them and they are bound to ask you to confirm that any data you have taken has been deleted.  Personally I'd be inclined to ignore any data that is not mine.  You might want to make a disclosure to whomever you think is the data owner, entirely up to you.

You mention keylog; if you are wondering why an individual might have a keystroke logger on their own PC then well to be generous they might be using it as a simple backup of what they type.  I know people who have done that.

Aside: Finally as a tangential observation, what you have found is not that uncommon.  People store all kinds of junk; for example people link their home data storage to the internet via FTP: we run regular assessments for such data that contains our company strings.


Does this mean that most browsers have fixed the vulnerability?

Yes, this vulnerability was fixed in all browsers about ten years ago. According to John Resig, the JavaScript specification was modified and the behaviour at least in Firefox was changed so that constructors can't be overridden to steal data.

  Is there some table that will let me know which browsers have fixed it?

Generally, no. For some features CanIUse shows which browsers have implemented things. The Chrome Status site is useful to see the state of features in Chrome.

  I could not see my authentication cookie being passed in the request.

I would expect the cookie to be present. Perhaps you are testing this with the latest Chrome, which is more careful with sending cookies to other sites.


Can a Trusted Platform Module be used as a Trojan Horse?

The TPM is a passive device. It will answer to your commands but it will not act on its own - at least if it is compliant to the specification (which obviously does not apply to malicious ones).

The TPM is connected via LPC or SPI. It cannot access your system memory per se. However, as pointed out by Z.T., a malicious TPM may exploit vulnerabilities in the kernel driver and/or the software stack used for communicating with the TPM. That means, code execution by a malicious TPM is plausible. IMHO, I think if you're not a high-value target, an attack is unlikely.

Fortunately, every manufacturer ships their TPM with an Endorsement Key (EK) and an EK certificate. This is an X.509 certificate guaranteeing that your TPM device is genuine. You might want to verify it before installing it to your security-critical machine.

Assuming your TPM is not malicious, it might be less secure. Of course, there is no indication of your device's protection level besides the price, certification (e.g. Common Criteria EAL) and security issues from the past.


Is it okay to just secure (using SSL) the login page, but not the rest of the site?

That's really a question based on the needs of your site and it's users.  SSL provides two main services.  For one, it validates the identity of the server that the user is connecting to for the user.  It also protects the transmission of sensitive information from the user to the server.

If the majority of your site is not sensitive if spoofed and does not require the user to transmit sensitive information, then there is no reason it is necessary to use SSL on the rest of your site.  It is worth noting that if the user is accessing the site via a non-SSL protected page, it is possible for someone to jump in between the user and the website and hijack the session, so the identity of a logged in user should generally not be trusted outside of an SSL connection, but this is also not always a problem, depending on your security needs.

As for your question about when credentials are transmitted, as long as your site is configured correctly, once a session is associated with a user, the credentials should not need to be retransmitted in the clear.  The exact details of how the session is maintained would depend on what approach is being used, but most generate some kind of token or unique identifier upon authentication and transmit that instead.  The identifier then becomes invalid when the session expires.


Can dual NIC Snort machine cause threats to bypass firewall?

Generally speaking, yes, dual homed devices can - and often will - be used to create a pivot point for attackers.

Yet, your sniffing machine would be in a significantly less exposed position as maybe a server in a DMZ. On the other hand, parsing is hard and snort does exactly that; I am not confident to proclaim there are no vulnerabilities in snort. However, as you described, a physical connection is there so it very well could get infected and act as a pivot point into your network.

Besides using iptables to restrict the outbound network traffic of that machine, you might also consider using a data diode to ensure that behavior. Configurations on that machine might very well be changed when the attacker gains root; as simple as iptables -P OUTPUT ACCEPT. A data diode would still hold up any outbound traffic.


How to post comments on websites without being traced back

How much a website knows

Assuming you are browsing on a website without any protection, a website can know a great deal of things about a computer. Further, a great deal of this information is generally stored by the website in some sort of database. Often times, websites will store a great deal of information in order to remember some information about you in the event that you log on or register. I would be shocked if a message board did not at least tie your IP to your post in the event they want to ban it if a lot a spam comes from it. Your IP can be traced back to you by an ISP rather easily. It would be rather difficult, however, for CNN to know exactly who you are, though.

How much and ISP knows

Everything not sent encrypted on a network can be logged by an ISP if they wanted. Basically, we allow ISPs to be a man in the middle so we can do the whole internet thing. They basically, then, can know whatever they want about most internet traffic. And they of course know who you are.

What to do

I cannot tell you what the best method is simply because I doubt one exists. This question: Whats the best way to make my internet traffic anonymous? has some answers that you may want to look at. I personally prefer HTTPSeverywhere as a method of encrypting traffic to help against normal data interception. This, however, depends on the website being secure itself.  Note that proxies and VPNs trade in one level of trust for another. The website will know where the proxy or VPN is located. The proxy or VPN will know where you are located. You are not making yourself impossible to track, just harder. This question: How does Google Maps know where I am, when I'm using a VPN? shows some instances where locations services were able to break through VPNs.


Is it better to use an unsuitable hashing algorithm instead of none at all?

The real answer to your question is simply do not store the passwords there if you cannot properly protect them.

"The system does not support proper password hashing algorithms" is not a valid excuse to compromise the security of your users. Either find a way to properly hash passwords using a strong and properly configured algorithm or do not store them.

But to provide a direct answer to your question: yes, something is better than nothing. SHA-1 or SHA-2 is definitely an improvement over plaintext.

To answer the "then where should the passwords go?" question - Based on the phrasing I am assuming there is a new feature/request for the software that requires the system to store passwords.

If the system cannot properly and securely store passwords (by modern security standards) then I (personally) would reject the request. Intentionally practicing poor security because of legacy system constraints or to appease a  business use case is bad security practice. I would inform whoever made the request that I have two viable options:

We have to completely overhaul the system to one that supports modern security practices (such as proper cryptographic password hashing).
I simply cannot add the new feature/request to the existing system for it would compromise security.


philosophical: restricting the password space increases security

tldr; Restricting the password space does not help against brute force attacks, but may against intelligent attacks, but there is an even better way.

First off, you're asking the right question, but using the wrong terminology here:

  ...the second scheme produces passwords that will likely be more resilient to simple brute force attacks.

(I think you mean intelligent attacks.)

A brute force attack is one that attempts every possible combination without added intelligence. Brute force in your example would be something like:

a, b, c, ... y, z, 0, 1 ... 9,
aa, ab, ac, ... ay, az, a0, a1 ... a9, ba, bb, bc ... 99,
aaa ... 999,
aaaa ... 9999,
aaaaa ... 99999,
aaaaaa ... 999999

Anything other than that would be considered an intelligence strategy. For example, before you try brute force, you may be able to save some time with this strategy:

Attempt only numbers.
Try words found in a dictionary.
Try the top X most popular passwords.
Try combinations of the username or user's initials, current year or last year, etc.
Try brute force.

Your goal, as the creator of your password, is to make sure that the first 4 options always fail to discover your password. In other words, you need to make sure that the only way to discover your password is by brute force, and also make sure that if brute force is used, that it will take a long time before finding your password.  However you do that is up to you, given the constraints of what types of passwords are allowed.

As for your particular question, I would approach it more like a random password generator- it generates one for you, you look at it, and if you believe that it could be guessed with a method other than brute force, you simply generate another random one until you're happy with it. (This would be Scheme 1 with a twist.) If you really wanted to quantify this, you could have your intelligence strategies built and ready to go (all strategies except for brute force). Then you can test them against your randomly generated password and if it is found, you generate another one until all intelligent strategies fail to discover your password. You then would be left with a password which is only discoverable by brute force. Using this method you can achieve better entropy than by restricting the password space in the way you described.

Note: with the password rules you supplied, my twist to Scheme 1 may end up looking somewhat like Scheme 2, however, as the number of allowed characters and password length increases, the Scheme 1 twist should provide more entropy.


Finding my iPhone - Conned through SMS and website

Indeed an unfortunate situation for you and I'm going to save myself the teacher's voice, I guess you learned phishing the hard way.

The next step greatly depends on the authorities you lost the phone in. First, go to the next police station and report your phone stolen. Tell them the story with as much details as possible (e.g. when did you loose it, when did you last locate the phone, where was the phone last located). Take the phone with the info SMS to the police as well (be prepared to leave it there). The message will show the time stamp that is crucial to revert the line of communication in your providers network. That actually is the last step, the authorities will have to try and identify the originating number of that SMS. With that information and with the ID of your iPhone it is possible to triangulate either of the devices. To be honest, I expect that the info SMS did not come from any mobile phone, but was sent from a web service offering a free SMS gateway. Therefore the best and probably only shot is the provider to locate the phone in the mobile network cell. However, more bad news it might be possible that your provider does not cooperate in such cases and/or that the police is overloaded with other crimes so that your theft is not urgent. The more time passes, the less likely it is for you to get your phone back. If you happen to have insurance that covers out-of-house theft, you should take the police report to the insurance company and file an insurance report.


Is it secure to execute MySQL queries on a client device?

SELECT * from uaccounts WHERE username = 'bob

Assuming Bob is only supposed to see the record for Bob then no it is not secure. Bob can pull out the connection parameters from the application and run whatever query he feels like.

Database security is in every implementation I've seen done at the table level. I.e even if you give Bob his own user account for the database he's still going to need select permission on the uaccounts table meaning he can run "SELECT * FROM uaccounts".

The only way to make this secure is to instead of giving Bob select permission on the table create parameterless stored procedures (which Bob would need execute permissions for) that use the logged in user name. And this is usually far more effort than its worth and far too easy to screw up. Not to mention it doesn't really scale. Facebook would not want a separate database username for every user of the site...


'Open course' Information Security Topics

Breezing through the terminology won't help, it might be difficult for them to recall all the terms and they might not truly understand the importance without seeing practical examples. And if it is the first time it will be done, I suspect it should go well, with good review and grades. If they're not CS students, I would say you need to keep it simple. I would go with basics such as:

email security - spamming, phishing, scams;
physical security - dumpster diving, tailgating;
social engineering and how it can be used;
passwords/ passphrases and only high level hashing maybe;
OWASP, STRIDE, CIA triad, AAA (triple a);
browser security - such as how can they know if something they download is secure or not, certificates - not technical details, but basics so they can know if a site is secure, http vs https;
digital signing and encryption (not in depth, maybe its importance and something like caesar cipher they can play with so it will be fun for them, not complex stuff) and so on.

But for each of these topics, I wouldn't stick with the terminology, I would try to show them examples using images/ demos.

If it makes sense, let me know and maybe I can provide help or online resources where you can look for these kinds of topics.

There is a security certification meant to cover the basics, it's called CompTIA Security+. Of course, you don't have to take the certification. But if you look for its requirements, you will find a list of topics that might be of interest for you. It has a wide range of modules, from absolutely zero knowledge to basics for CS people. You don't have to cover the ones that seem more technical, for your purpose. The resources to learn for this certification for sure contain what you need. The best resources I can recommend you are the following:

Dariil Gibson's book - Get Certified Get Ahead,
Professor Messer videos (this one is free),
Pluralsight website - CompTIA Security+ the 501 Path (if your University provided you access to Pluralsight; or if you have Microsoft Student Partner organization at the University they might be able to provide you free access, though I cannot guarantee).

You don't have to cover all of them. I found the videos more easy going, and the Pluralsight ones more structured and concise. If you prefer to read a book, that one should be helpful.


The other possibility to gain keychain content is the $5 wrench. Or, as it's known in the UK, the 50p chocolate bar.


Can someone hack into my Wifi network through my cell phone?

If an attacker has full access to your cell phone, chances are, they can read the Wi-Fi password in plain text and thus get access to your Wi-Fi network.

The exact specifics depend on the OS, the version, etc...


Does blocking all ports make a machine more secure?

First, it might make your system slightly more secure but it does not make it fully secure. In the majority of attacks today the victim unknowingly invites the attacker implicitly into the local network. This is for example done when surfing the web: all content you visit is downloaded to your local system and rendered or executed (depending on the content) there. The same is true for emails - any attachments you open will be opened on your local system. And attached Office documents, PDF, archives etc are typical vectors to infect your system. No firewall which just blocks based on ports will protect you against these most common attacks.

Apart from that you should only block incoming ports for data which are not part of an established connection (initiated from the inside). Otherwise you will simply not be able to surf the web anymore. And websites are not only located on port 80 and 443, so restricting outgoing access to these ports will probably result in over-blocking too. Similar you might need access to other ports like 143, 993, 465 ... to retrieve and send mail (unless you use web based mail). And games or whatever applications you use might also need different outgoing ports.

Depending on what system you use it might the best (most security with less side effects) if you use the systems capabilities. For example if you declare your computer to be inside a public network it will already adjust the firewall accordingly to not allow any incoming connections but allow outgoing connections.


PHP on IIS 7.5 Hacked - How do I find and fix the XSS Injection?

This is not XSS. You got hacked.
You want to check the settings of auto_prepend_file and auto_append_file. This may be in your php.ini or in .htaccess files.
If the attacker had access to the system to the point where he could run arbitrary PHP code, he could have done a lot of worse things. Do find out how the attacker got in if you can, but afterwards, you should get all data off the machine, and wipe and reinstall the entire machine from trusted media. Consider any private keys (e.g. from SSL certificates), passwords, etc. that are stored on the machine compromised (i.e. change passwords, revoke and replace certificates).
Consider the possibility that the attacker hid a backdoor somewhere in your PHP code.  Anywhere. This is actually pretty likely. If you want to copy any of your code to the reinstalled machine, you need to audit all of it (e.g. by comparing it to a known clean copy - pay attention to additional files too) or simply nuke it and reinstall from a clean source. Also check your Wordpress/other CMS database for settings which could allow backdoors.