Tuesday, June 16, 2009
The common way of using simple drag and drop within windows explorer does not fit here exactly: - Make sure the assembly does have a strong name. - Open the "command prompt" with administrative priviledges. - Run "explorer /separate" two times. This will open two explorer instances in separate processes. - Use drag and drop to copy the desired assembly from one explorer windows into the "%windir%\assembly-folder" on the second explorer window.
Tuesday, June 16, 2009 6:16:50 PM (GMT Standard Time, UTC+00:00)
 Wednesday, December 12, 2007

Public request for instant-on mechanisms on hardware coming along with decreasing prices on flash memory, tend manufactures to enhance their devices by flash based techniques. Some months ago Erdgeist and Frank Rieger held a nice talk about this trend and security related issues coming along. I like to sensitize by listing some of the main points:

  • Flash buffered hard drives could mean writing back whole main-memory content to flash.
  • Keep in mind that crypto-keys could be contained in memory dumps and so they also could be copied to the flash memory without your intend.
  • Flash memory is accessed via FAT mechanisms. Deleting a file will not delete its information physically; it just deletes an entry in the FAT. So watch out selling your old cards on eBay or be amused buying them :)
  • When a cell dies the current state (0/1) can still be read. So dead memory cards are nice toys for computer forensic investigators.
  • Flash memory cells write-cycles are limited to 10K or 1M times.
  • To avoid that some cells are massively accessed while others do not, manufactures built in algorithms to distribute access to the cells. So sensitive data could be automatically copied and is now spread multiple times on the card without your intention.
  • So before selling used memory, fill the cards with large files of useless data before deletion.
  • Use encryption for sensitive data.

Along with every security related issue: It is not meant to spread paranoia but it doesn't hurt knowing what's possible with our beloved daily gadgets.

 

The complete content can be found here or here.

Wednesday, December 12, 2007 9:36:05 PM (GMT Standard Time, UTC+00:00)
 Friday, December 22, 2006
Our team and ahead Michael and Daniel completed a security analysis on Windows Communication Foundation (WCF) for the Federal Office for Information Security of the German government (BSI). It was done in collaboration with the Developer and Plattform Strategy Group (DPE) at Microsoft Germany and the WCF product team at Microsoft in Redmond. For more information contact the BSI here or read the overview.
Friday, December 22, 2006 2:37:06 PM (GMT Standard Time, UTC+00:00)
 Friday, July 28, 2006
To sign an assembly with a strong name, you must have a public/private key pair. This cryptographic key pair is used during compilation to create a strong-named assembly. You can generate a key pair using the strong name tool "sn.exe" (e.g. "sn -k newkey.snk"). But there is also a programmatic way to do this shown in the following snippet:

/// <summary>
/// Generating a strong name key pair file programmatically
/// </summary>
/// <param name="fileName">Fullname of the keyfile, which will be generated.</param>
/// <param name="keySize">RSA key size. Default is 1024. Range is 384-16384 in 8 bit increments.</param>
private static void CreateKeyPairFile(string fileName, int keySize)
{
    if ((keySize % 8) != 0)
    {
        throw new CryptographicException("Invalid key size. Valid size is 384 to 16384 mod 8.  Default 1024.");
    }

    CspParameters parms = new CspParameters();
    parms.KeyNumber = 2;
    RSACryptoServiceProvider provider = new RSACryptoServiceProvider(keySize, parms);
    byte[] array = provider.ExportCspBlob(!provider.PublicOnly);

    using (FileStream fs = new FileStream(fileName, FileMode.Create, FileAccess.Write))
    {
        fs.Write(array, 0, array.Length);
    }
}

After creating the .snk-file there a three ways to sign an assembly. Via the assembly linker tool "al.exe", via project-properties within visual studio or by using the following attribute in the source code:

[assembly:AssemblyKeyFileAttribute(@"keyfile.snk")]
[assembly:AssemblyDelaySignAttribute(true)]

The latter can be used to turn on/off delay signing the assembly.

Friday, July 28, 2006 4:01:12 PM (GMT Standard Time, UTC+00:00)
 Thursday, May 11, 2006
Coming along with the .NET 2.0 framework it is now possible to set access control lists (ACL) on several windows objects by code. E.g. you can programmatically specify that UserA is given the permission to read/write a FileB. The following classes support getting/setting ACLs on its instances: File, Directory, RegistryKey, FileStream, Mutex, Semaphore and EventWaitHandle. Additional to this it is possible to implement a solution for supporting windows services without any deep digging down the win32 world.

The key to realize this is the "System.Security.AccessControl" namespace. It contains several abstract classes which need to be implemented:
  • "AccesRule" - Used to specify permissions for accessing a windows security object
  • "AuditRule" - Used to specify permissions for auditing a windows security object
  • "NativeObjectSecurity" - Managing the rules
The code realizes a class called "Service" representing a windows service by using derivatives of the above classes:

  • "ServiceRights" as an enumerator for the different flags representing the permissions. E.g. "Start", "Stop", "Pause".
  • "ServiceAccessRule" derived from "System.Security.AccessControl.AccessRule". Specifies a windows account/group and the access permissions which are to be set.
  • "ServiceAuditRule" derived from "System.Security.AccessControl.AuditRule". Specifies a windows account/group and the audit permissions which are to be set.
  • "ServiceSecurity" derived from "System.Security.AccessControl.NativeObjectSecurity".Instances of "ServiceAccessRule" and "ServiceAuditRule" are added to an object of type "ServiceSecurity"

Start using the methods "SetAccessControl" resp. "GetAccessControl". The first one is used to specify a windows service and an instance of "ServiceSecurity". The ACL is now set to the service. The second is used to extract an ACL from a given service.

Users familiar with the Security Descriptor Definition Language (SDDL) are also supported by the two methods "SetSecurityDescriptorSddlForm" and "GetSecurityDescriptorSddlForm"

SetAclOnServices.zip (7.09 KB)

The example uses the windows service "Alerter". Make sure you have the appropriate administrative user rights when running the solution.


Thursday, May 11, 2006 11:51:45 AM (GMT Standard Time, UTC+00:00)
Latest Postings
Tags
History
<March 2010>
SunMonTueWedThuFriSat
28123456
78910111213
14151617181920
21222324252627
28293031123
45678910
License
Except where otherwise noted, content on this site is licensed under Creative Commons Attribution 3.0 Unported License:
Creative Commons Attribution 3.0 Unported License